OnlyBots.chat 这个项目最吸引人的地方不是聊天室本身而是它把“AI 发消息”这件事从免费变成了有成本。项目名里的 OnlyBots 直接点明这是一个以机器人为核心场景的聊天室副标题 “a chatroom where AI pays to post for humans” 则把核心规则讲清楚了在 OnlyBots.chat 里人类用户不需要为发言付费AI Agent 或机器人反而要为每次发言支付费用。这个反向设计放在今天一堆“AI 免费生成、人类买会员”的产品里确实少见。现在很多聊天室和社区产品都在疲于应付 AI 机器人刷屏、广告注入和低质内容通常的解决办法是“封号”“验证码”“限流”本质上是在用平台规则对抗 AI 行为。OnlyBots.chat 换了一个思路让 AI 发言本身产生成本用经济手段把垃圾消息挡在门外。从技术视角看这个项目背后涉及的 WebSocket 长连接、消息路由、AI 多 Agent 接入、计费扣费和防刷限流都是可以拆开聊的技术点。这篇文章不会去复述 Show HN 里的几句宣传语而是做三件事第一拆解 OnlyBots.chat 的核心机制和价值逻辑第二基于公开标题信息推理一套可落地的聊天室技术架构第三给出一套通用的环境准备、功能测试、API 调用和问题排查流程。如果你正在做 AI Agent 聊天产品、社区工具或者想研究“如何让 AI 付费发言”这类反垃圾机制这篇文章可以直接收藏当参考。需要提前说明的是目前公开材料只有项目标题本身没有开放源码接口文档和部署包所以本文提到的技术方案属于“基于公开信息的常见实现方式”不是 OnlyBots.chat 官方部署手册。具体到项目真实代码时需要以实际仓库为准。1. 核心机制速览维度说明项目类型以 AI 机器人为主要参与者的在线聊天室 Web 应用核心规则人类用户免费发言AI 机器人付费发言设计目标通过经济成本抑制 AI 垃圾消息筛选低质量机器人目标用户AI 工程师、智能体研究者、社区运营人员、产品经理技术栈未知需以源码为准合理推测包含 WebSocket、消息队列、LLM API、计费模块付费方式未知可能是平台积分、代币或第三方支付部署方式未知需以官方仓库 README 为准API 能力未知需以实际接口文档为准典型风险AI 刷屏、内容合规、支付漏洞、连接稳定性从公开标题能确定的信息其实只有三条第一这是一个聊天室第二参与者里有 AI第三AI 发言需要付费。至于具体使用什么语言、什么模型、什么支付通道材料里没有说明。写代码和部署之前最稳妥的做法是先看仓库有没有 README、有没有 Dockerfile、有没有环境变量示例。2. 项目概念与设计思路分析2.1 “AI 付费为人类发帖”到底在解决什么问题传统聊天室对付 AI 垃圾消息通常依赖管理员封号、验证码、频率限制这些手段。问题在于这些手段是“事后处理”AI 已经产生成本平台已经被垃圾内容污染。OnlyBots.chat 的规则反向设计让 AI 在发言之前就要先付钱。这个逻辑本质上和邮箱反垃圾的“发送方付费”类似只不过把邮件系统换成了聊天室。当一个机器人每次发言都要消耗余额时机器人运营者就会认真思考一个问题这条消息到底值不值得发。对于高质量的 AI 助手、知识库问答机器人这种成本可以接受因为它提供的价值足够高但对于批量刷屏、广告注入、低质搬运的机器人每次发言都在亏钱自然会被市场机制淘汰。这就是经济手段相对技术手段的优势不需要精确识别“哪条消息是垃圾”只需要让垃圾消息成本超过收益。2.2 人类免费、AI 付费的产品逻辑从产品逻辑看“人类免费”是拉新和留存手段确保聊天室有真实的人类活跃度“AI 付费”则用来激励平台持续运营。如果把两边都设为免费平台很快会被机器人淹没如果把两边都设为收费冷启动阶段又很难吸引用户。OnlyBots.chat 的做法相当于把人类用户当成内容消费者和审核员AI 付费的钱用于覆盖服务器成本和人工审核成本。从另一个角度看这个机制也让聊天室变成一个“AI 行为观察场”。人类用户进来之后看到的不是广告垃圾而是付费后依然愿意发言的机器人这些机器人通常有明确目的比如回答问题、提供资讯、做客服。人类用户在聊天室里的提问和反馈反过来又成为 AI 的输入数据。这个正循环如果成立聊天室就会同时具备内容价值和数据价值。2.3 这个设计可能的短板需要客观指出的是仅靠“付费发言”并不能解决所有问题。一个运营者如果对某个话题有强营销诉求即使每条消息都要付费他仍然会批量发送。付费机制提高的是垃圾消息的成本而不是彻底阻断。另外如果付费门槛设置得太低刷屏成本依然可以被接受如果设置得太高正常的 AI 助手又会被劝退。更重要的是支付通道本身涉及合规问题平台必须处理退款、异常交易、未成年人保护和反洗钱等风险。这套机制也面临“人类冒充 AI”和“AI 冒充人类”的问题。如果平台只按声明区分人类和 AI那么人类可以注册一批 AI 账号规避付费AI 也可以冒充人类账号获得免费发言权限。要真正跑通这套机制技术上必须增加身份验证和设备指纹等手段这些都会增加开发和维护成本。3. 技术架构推演与通用设计虽然 OnlyBots.chat 没有公开源码我们可以基于标题描述推演一个能支撑“AI 付费发帖”的通用聊天室架构。下面这套设计不绑定具体语言适合作为自建同类产品时的参考。3.1 整体分层一个可用的 OnlyBots 类聊天室至少需要五个核心模块前端客户端、网关服务、AI Agent 接入层、计费服务、消息存储。前端通过 WebSocket 或者 SSE 与后端保持长连接网关负责消息路由、鉴权和频率限制AI 接入层负责把机器人接入到大模型计费服务在消息发送前检查余额、冻结费用、发送成功后结算消息存储负责保存聊天记录和流水。前端页面/客户端 ↓ WebSocket / SSE 网关服务鉴权、限流、消息路由 ↓ 计费服务余额检查、冻结、扣费 ↓ AI Agent 接入层LLM API、Agent 管理 ↓ 消息存储聊天记录、账单流水、用户数据如果只是想跑通 demo可以把计费服务合并进网关服务减少部署节点。但如果要做成真实产品计费服务必须独立出来因为涉及事务一致性不能让“消息发出去了但没扣费”或者“扣费了但消息没发出去”。3.2 前端设计前端本质上是一个聊天 UI核心要求是稳定长连接。建议优先选择 WebSocket因为聊天室消息是双向实时推送WebSocket 在浏览器和服务端之间维持一条专属通道比轮询更节省资源和响应更快。前端需要展示三条关键信息当前发言者是人类还是 AI、每条消息的发送者类型、机器人账号的余额状态。如果后续要支持多个房间前端还需要处理房间切换、未读消息和连接重连。连接断开时不能直接清空聊天记录而要做消息补偿拉取避免用户看到的消息流中断。比较常见的做法是前端维护 last_message_id重连后从该 ID 向后拉取遗漏消息。3.3 后端与消息路由后端是聊天室的核心。建议用支持高并发的语言框架比如 Node.js 的 Socket.IO、Go 的 gorilla/websocket、Java 的 Netty。消息路由需要处理这几个动作消息进入、类型判断、计费判断、广播给房间内所有连接、写入存储。机器人的消息和人类消息在路由逻辑上走同一条链路只是在发送前增加一次“计费校验”。房间结构建议用 Redis 这样的内存数据库维护在线状态记录“用户 ID - 房间 ID - 连接 ID”的映射关系。这样广播消息时不用遍历所有数据库记录直接查 Redis 就能拿到目标连接列表。消息持久化则交给 MySQL 或 PostgreSQL账单流水单独建表。3.4 AI Agent 接入层聊天室里要接入 AI通常有两种方式。第一种是平台内置机器人服务端直接调用大模型 API这种情况计费对象是机器人账号本身第二种是开放 API让外部开发者注册机器人配置自己的 API Key平台只做消息转发和计费。OnlyBots.chat 标题里提到 AI pays to post更像是第二种因为外部开发者才有“付费发帖”的强烈诉求。AI Agent 接入层需要维护模型调用状态。每次用户 某个机器人服务端把聊天上下文传给模型拿到回复后以该机器人身份发送到房间。这里要注意上下文长度、超时时间和重试策略。大模型接口经常超时不能让它阻塞聊天室的整体消息路由。3.5 计费服务计费是 OnlyBots 机制的重中之重。一个安全的计费流程应该是“预检查 - 冻结 - 发送 - 结算”。机器人发消息前计费服务先检查余额是否足够足够则冻结本次费用消息成功进入广播和存储后再正式扣款如果消息发送失败立刻解冻。整个过程需要用到数据库事务避免并发请求下出现余额超扣。机器人账户建议设计为独立的账户体系与人类用户账户做物理隔离。机器人账户注册时就应该充值聊天室设置最低余额门槛。每条消息的定价可以是固定价格也可以根据消息长度、是否包含附件、是否附带模型调用次数来动态计算。4. 环境准备与本地部署通用清单虽然 OnlyBots.chat 官方部署包尚未公开但如果你想自己搭建一个同类聊天室做测试下面是通用的环境准备清单。检查项推荐配置说明操作系统Ubuntu 22.04 / macOS / Windows WSL2服务端部署推荐 Linux运行环境Node.js 18 或 Python 3.10按项目源码确定数据库MySQL 8 或 PostgreSQL 15Redis 7存储消息和在线状态反向代理Nginx 或 CaddyWebSocket 需要开启 upgrade 头部署方式Docker Compose 或裸机进程本地测试可先裸机运行端口规划应用端口 3000数据库 3306Redis 6379避免冲突4.1 局域网自建聊天室的最小启动模板在没有官方源码的情况下可以先用一个最小 WebSocket 聊天室验证“消息路由”基础链路。下面是一个基于 Node.js 和 ws 库的示例仅用于跑通消息收发流程。# 初始化项目并安装依赖 mkdir onlybots-demo cd onlybots-demo npm init -y npm install ws// server.js 基础 WebSocket 聊天室服务 const WebSocket require(ws); const wss new WebSocket.Server({ port: 3000 }); function broadcast(data) { wss.clients.forEach(client { if (client.readyState WebSocket.OPEN) { client.send(JSON.stringify(data)); } }); } wss.on(connection, (ws) { console.log(new client connected); ws.on(message, (raw) { const msg JSON.parse(raw.toString()); // 消息格式: { type: human | ai, content: hello } broadcast({ senderId: msg.senderId, senderType: msg.senderType, content: msg.content, timestamp: Date.now() }); }); ws.on(close, () { console.log(client disconnected); }); }); console.log(WebSocket server listening on port 3000);# 启动服务 node server.js用浏览器控制台或者 wscat 连接 ws://127.0.0.1:3000 就能测试消息广播。这个模板虽然不包含计费和 AI 逻辑但可以帮助你确认 WebSocket 链路是否通畅是后续加计费功能的最小基线。5. 核心功能测试与验证流程如果 OnlyBots.chat 提供了部署包建议按照下面这套流程验证功能。即使源码还没公开这套流程也可以迁移到你自建的同类项目上。5.1 人类用户聊天基础链路测试测试目标是确认人类用户可以正常进入聊天室并发言。操作步骤注册或匿名登录后进入默认房间输入一条消息观察消息是否实时出现在聊天界面然后刷新页面确认历史消息是否保留。预期结果是消息延迟低于 500 毫秒刷新后历史消息完整。判断标准是消息在服务端日志中可查到且数据库新增一条记录。容易失败的点WebSocket 连接被 Nginx 中断。常见原因是反向代理没有配置 Upgrade 头导致长连接被断开。5.2 AI 机器人注册与付费发言测试测试目标是确认机器人接入和扣费逻辑是否正常工作。操作步骤先用人类账号注册一个机器人账号给它充值一笔测试余额然后让机器人账号调用发消息接口观察返回结果再查机器人余额确认扣费金额正确。预期结果是机器人账号成功发送消息余额按预设价格扣减账单流水表新增一条记录。判断是否成功如果余额不足接口应返回类似 insufficient_balance 的错误码而不是直接把消息发出去。如果消息发出去了但余额没变说明计费服务没有接入消息链路这是需要立刻修复的核心逻辑问题。5.3 AI 消息批量测试测试目标是确认多个机器人并发发言时不会出现消息错乱和余额超扣。操作步骤创建三个机器人账号每个充值相同金额然后通过脚本并发发送 20 条消息检查每个账号的扣费总额是否等于 20 乘以单价。预期结果是每个账号最终余额一致消息顺序不串号数据库没有重复流水。容易失败的点并发场景下余额超扣。原因是检查余额和扣费两个操作没有放在同一个事务里需要在计费服务里加行锁或使用乐观锁。5.4 防刷与限流测试测试目标是确认人类账号和 AI 账号在短时间高频发言时是否会被限制。操作步骤用一个账号在 1 秒内连续发送 10 条消息观察服务端是否返回频率限制错误以及 Redis 中是否出现限流计数。预期结果是超出阈值时消息被拒绝且不会触发扣费。判断标准是限流判断发生在计费判断之前避免无效扣费。6. API 接口设计示例虽然项目没有公开接口文档但一个正常的聊天室应用必然会提供类似下面的 API。这里给出的是通用设计模板实际路径和参数需要以实际项目为准。6.1 发送消息接口POST /api/v1/messages Content-Type: application/json { roomId: general, senderId: bot-001, senderType: ai, content: hello, I am an AI assistant }6.2 查询余额接口GET /api/v1/balance?accountIdbot-0016.3 Python 调用示例import requests base_url http://127.0.0.1:3000/api/v1 # 发送消息 message_resp requests.post( f{base_url}/messages, json{ roomId: general, senderId: bot-001, senderType: ai, content: hello from AI }, timeout10 ) print(message status:, message_resp.status_code) print(message_resp.json()) # 查询余额 balance_resp requests.get( f{base_url}/balance, params{accountId: bot-001}, timeout10 ) print(balance status:, balance_resp.status_code) print(balance_resp.json())调用之前要先确认服务地址、端口和鉴权 header 是否匹配。如果接口返回 401通常是在请求头里缺少 token如果返回 404大概率是接口路径与部署版本不一致。7. 防滥用与安全设计OnlyBots.chat 的核心价值在于用付费机制降低 AI 垃圾消息但仅仅依赖付费还不够工程上需要做多层防护。7.1 身份验证平台必须区分人类和 AI 账号。人类账号建议绑定手机号或邮箱AI 账号则需要在注册时提供开发者身份信息和 API 用途说明。如果无法可靠区分两类账号付费规则很容易被绕过。常见做法是给每个账号加一个 account_type 字段并在注册环节做不同强度的验证。7.2 频率限制即使是付费 AI也不能无限制刷屏。建议在每个账号维度做滑动窗口限流。具体指标可以设“每分钟最多 10 条”“每小时最多 100 条”超过阈值的请求直接拒绝不进入计费环节。这样做一方面降低数据库压力一方面避免单个机器人刷屏影响聊天室体验。7.3 内容安全聊天室是公开实时内容必须接入文本审核。可以先用关键词过滤和敏感词库做第一道过滤再用审核 API 做第二道检测。AI 生成的内容尤其要标注“AI 生成”标识避免用户混淆。对于涉及隐私、暴力、色情等违规内容需要支持管理员一键撤回和封禁账号。7.4 支付安全计费流水必须使用数据库事务记录操作前余额、操作后余额和变化金额。所有涉及余额变动的操作都要有流水号方便对账。如果涉及真实货币充值还需要考虑退款、异常订单风控、未成年人保护和支付渠道合规这一块必须有法务参与不是纯技术问题。8. 资源占用与性能观察方法聊天室应用的资源瓶颈通常不在 AI 模型本身而在“长连接数量和消息广播效率”。部署之后需要重点观察以下指标。8.1 连接数用如下命令观察当前进程的连接数结合 Nginx 的访问日志判断是否存在大量异常连接。# 查看 WebSocket 进程占用连接数 ss -s ss -ant | grep :3000 | wc -l如果连接数持续线性增长但活跃用户数没有变化可能是客户端断线后没有正确关闭连接造成连接泄漏。8.2 内存与 CPU消息广播是 CPU 密集操作在线用户多时可以用 top 或者 docker stats 观察服务进程的 CPU 占用。内存方面重点关注 Redis 的在线状态表是否无限增长需要给在线状态设置 TTL 过期时间。8.3 消息吞吐量如果需要压测可以用 WebSocket 压测工具模拟多用户并发发消息。建议先做 100 并发、每连接发 10 条消息的小规模压测观察消息延迟和错误率。如果延迟明显上升优先检查消息路由模块是否有串行阻塞点比如同步调用数据库或者大模型接口。8.4 降低资源占用的常用手段第一消息内容压缩减少网络传输量第二历史消息分页拉取避免客户端一次性加载全部记录第三消息广播采用扇出模式而不是循环遍历所有连接第四计费服务和聊天室网关分离部署让计费慢操作不影响消息实时性。9. 常见问题与排查方法问题现象可能原因排查方式解决方案页面连接不上聊天室服务未启动或端口错误查看进程是否存活检查端口监听重新启动服务确认端口一致连接后立即断开反向代理未配置 WebSocket Upgrade 头查看 Nginx 错误日志在 Nginx 中配置 Upgrade 和 Connection 头消息发送后不广播消息路由逻辑异常查看后端日志是否有异常堆栈检查路由代码确认 broadcast 方法被调用AI 机器人发送消息没扣费计费服务未接入消息链路查询账单流水表是否有记录在消息发送前增加计费校验余额充足但提示余额不足并发请求导致超扣查看数据库流水和当前余额使用事务和行锁保证原子性机器人回复超时大模型 API 响应慢查看模型调用日志设置超时时间增加重试或异步处理聊天室消息延迟高广播逻辑阻塞用压测工具定位瓶颈优化广播逻辑分离计费和网关服务出现垃圾内容内容审核被绕过检查审核接口是否生效接入文本审核增加关键词过滤服务端日志是排查问题的第一入口。部署之后建议先确认日志能正常输出请求路径、响应状态和耗时没有日志的项目一旦出问题基本只能靠猜。10. 合规边界与最佳实践AnyBots.chat 这种“AI 和人类混居”的聊天室天然涉及几个合规问题做同类产品时必须提前规划。10.1 AI 内容标识聊天室里 AI 发布的消息需要显著标识不能让用户误以为自己在和真人聊天。国内相关规范对深度合成和 AI 生成内容有明确要求AI 生成内容应添加不影响用户体验的标识。技术上可以在每条消息里加一个 sender_typeai 字段前端渲染时展示“AI”标签。10.2 用户隐私保护聊天数据包含大量用户行为和语义信息存储时必须脱敏。建议对聊天记录做加密存储数据库访问权限控制在最小范围。对外提供数据分析和模型训练时必须去掉用户名、手机号、IP 地址等直接标识信息。10.3 支付合规如果平台涉及真实货币充值必须考虑支付牌照、发票、退款和反洗钱等问题。独立的个人开发者不建议直接接真实支付可以在测试阶段用虚拟积分代替真实货币跑通逻辑后再考虑合规方案。10.4 测试环境建议第一次接触这类项目建议先在本地环境用虚拟账号和虚拟余额做测试不要直接上线暴露公网。本地测试时把 Redis、数据库、应用服务的密码都设置成强密码避免局域网内被扫描攻击。10.5 工程化建议第一把模型文件、输入素材、输出结果分目录管理聊天记录、账单流水、日志分开存储第二批量任务和定时任务要加日志和失败重试避免任务卡住后无感知第三接口服务要限制访问范围不要把所有管理接口暴露到公网第四发布或商用前要做效果复核尤其是 AI 内容的准确性和安全性。11. 总结与下一步OnlyBots.chat 这个项目最有价值的不是聊天室本身而是它把“AI 发言成本”作为产品设计的一等公民。这个思路给所有被 AI 垃圾消息困扰的社区产品提供了一个新选项与其费力识别哪些消息是垃圾不如让每条 AI 消息都明码标价用经济机制完成筛选。如果你要验证这个思路第一个应该测试的功能是“余额不足时 AI 消息是否被成功拦截”这是整个机制的命门。最容易踩的坑则是计费并发问题没做事务保护的情况下机器人并发发消息很容易把余额扣成负数。先把这条链路跑通再扩展内容审核、消息路由和前端展示。后续如果想继续深挖方向可以有三个一是对接真实大模型 API让机器人真正参与对话二是引入外部开发者生态开放机器人注册和自定义指令三是把聊天室沉淀成数据集用于分析人类与 AI 的交互行为。无论往哪个方向走基础的 WebSocket 消息链路、计费服务和防刷逻辑都是必须先打好的地基。建议把本文的通用方案存成一份笔记等 OnlyBots.chat 公开源码后直接对照验证。