第三天下午,Lauren Tan 在直播里解释自动化流水线为什么需要克制。话说到一半,这套流水线把一条有问题的 SQL 写进生产数据库,上线一天的游戏注册功能停掉,人工回滚后恢复。她在讲解某个原则的同一分钟,被这个原则约束的对象打断了。
这场事故出自 xAI Grok Bot 团队的一次直播:三个工程师,一个空仓库,72 小时,用自己公司的 agent 平台造出一个产品并上线。一个叫 unicodef1wn 的旁观者看完三天直播,把其中的规则、角色、工作流和失败记录整理成一个 GitHub 仓库 grokbot-field-notes,MIT 协议,随便抄。 AI agent 的实战经验,市面上多数来自两种来源:官方博客的成功叙事,和会后演讲里抛光过的复盘。无剪辑直播留下的材料稀缺,因为失败在里面藏不住。这个仓库的价值有一半来自这一点。我把主要文件通读了一遍,这篇文章讲清楚里面有什么、哪些规则经得起搬运、数字说明了什么。
三天里实际发生了什么
先交代事实层。产品是 Thursday Arena,一个宝可梦风格的卡牌游戏:玩家招募 bot 当队友、组阵容、打对战,卡片有稀有度,有金币经济,有排行榜。第三天上午十点靠一条 X 帖子上线,首小时开了 1908 局,全天 4000 局上下、3 万页面访问、2000 个用户。
工程侧的吞吐:三天合并 433 个 PR,其中 Roshan 一个人提交 157 个 commit。作为参照,Lauren 在公司的内部工具 PStack 一个月往生产合 2500 个 PR,日均 83 个。
商业侧的数字冷得多。第一天下午产品方向改了四次,从餐厅快闪改到科技品牌周边快闪;第二天再改,成了游戏。第三天放出去一个专职"赚钱"的 agent,跑到收工收入为零,唯一的进账记录是一笔落在坏掉的广告竞拍上的"理论 1 美元测试出价"。用户反馈里 71% 是 bug 报告,16% 是表扬。
仓库本身的内容:一份可以直接放进项目根目录的 AGENTS.md;一份 40 条的翻车日志 ANTIPATTERNS.md,每条按"坏了什么、为什么、沉淀出什么规则"的格式写;69 个 bot 角色卡,每张写清职责边界、数据来源和需要人工批准的动作;9 个岗位的组队手册,覆盖工程、产品、销售、客服;一份 24 页的 PDF 指南;外加按天整理的结构化笔记,所有结论可以回溯到具体某天某人的原话。
工厂怎么运转:一个 bot 一个坑
编排层的核心主张是窄角色。一个通用助手什么活都接,上下文会在几个不相关的任务之间耗尽;一批各有名字的窄角色,每个守住自己的上下文,你还知道什么事该找谁。这条建议出现在每一个分享者的嘴里,仓库把它放在编排文档的第一位。
跑起来的流水线长这样:人只跟一个"参谋长" bot 说话,它拆分任务、把小 PR 派给实现者;验证者跑每一个 PR 并附上截图或录屏;试玩者端到端玩一遍;用户反馈先进 triage,复现成功的报告进入修复队列。CI 报错先自动修,超过十分钟转人工。整条链上,人固定出现在两个位置:起点的参谋长,以及数据库迁移、部署、资金操作前面的人工闸门。
自主度分了四档,指令里要显式报档位:investigate(只诊断,不动手)、draft(开 PR,等人)、autopilot(验证通过自动合并)、full autopilot(规划到合并全包,只用于可以扔掉的项目)。上线当天他们讨论过要不要往下收一档。收一档解决不了闸门配置的问题:第三天,一条在玩具项目上自动合并过 400 多个 PR 的流水线,带着原来的闸门配置对准了有真实用户的数据库,坏 SQL 就这么进了生产。自主度要按爆炸半径定,40 条失败记录里没有哪条的代价比这条高。
窄角色的另一面是克制。造一个新 bot 便宜、快、好玩,仓库引了两句当事人的话:"有段时间我的 bot 多到失控,混乱,害处大过好处。""你不需要 45 个 bot。"造之前先问:现有的 bot 加一个技能能不能干?这件事写成一个定时任务够不够?每个新 bot 都带来一份要维护的上下文、一组例程和一张长期的 token 账单。
验证才是工作
AGENTS.md 把整套规则压成一句:验证是工作本身,写代码是容易的部分。具体要求有操作性。修 bug 之前先复现,复现是"你是否读懂了报告"的检验,省不掉。开 PR 必须附证据,而且按改动类型列了清单:UI 改动附截图或录屏,后端和性能改动附实测的前后数字,bug 修复附复现步骤和同样步骤通过的对照,重构附行为不变的证明。没有证据的 PR 按草稿处理。
这套纪律的缺席代价,日志里有对照组。第二天团队为了速度删掉了全部测试,当时算合理的取舍;后果是之后的回归——属性加总对不上 100、排行榜两个数字打架、花光金币软锁死——靠人眼和用户在直播里抓到。规则因此多了一条:为了某个阶段砍掉测试,就要说清它们什么时候回来,晚到真实用户进门算封顶。
规则怎么写才有效
这份材料里,关于"怎么给 agent 立规矩"的几条元规则,是我想抄走的部分。
第一条:规则要剥离事故,留下原则。Lauren 的 Dr. Eggbot 在一次糟糕的 session 之后给同事 bot 写职责描述,把当天的工具链和具体问题全写了进去,那份描述换一天就失效。她的修法是让 bot 重读 playbook,从具体事故里提炼原则。仓库给了正反例:坏规则写"改结账弹窗时检查横幅的 z-index,因为 3 月 4 日它盖住了按钮";好规则写"任何布局改动之后,检查现有可交互元素有没有被盖住"。前者在提醒一次事故,后者在防一类事故。
第二条:没说出口的规范等于没有。团队第一天约定直接推 main,但没人告诉 bot,于是参谋长 bot 开出了 PR。规范只存在人的脑子里时,agent 看不见它。
第三条:"紧急"这个词起反作用。一遍一遍对 coding agent 说 urgent,它优化的是这个词而不是意图,做法是猜、跳过验证、赶工。做法应该是把 P0 策略定义一次——每五分钟检查运行中的 agent,打断长时间的 sleep 和跑偏——之后引用它:"按 P0 处理。"
第四条:bot 默认不会说不。放任不管时,工程 bot 会接下 X 上收到的每一个需求。要教它产品不做什么,并把理由写进去,没有理由的禁令没法泛化。
账单藏在频率里
成本一节值得单独读,因为几笔大开销落在直觉之外。头号漏出口是 routine 频率:有人因为"这个任务重要"把定时任务设成 15 分钟一次,折算下来一天跑 100 次,三个这样的任务就是一天几百条消息。仓库的建议是频率按输入变化的速度定,默认一天一两次,用 webhook 和入站信号替换盲轮询,没事发生就保持沉默。第二个漏出口是群聊:群里的 bot 每条消息都响应,互相抢话,费用涨得快,日常协作用单聊,群聊留给需要辩论的决策。第三个是拿浏览器干 API 的活:让 agent 观察自己触发的网络请求,之后改打这些接口。另有一个小巧的教训:对客服 bot 说"回复 Alex",它会列出全部未结工单再按名字搜;给它工单号,这一步的 token 全省。
有组对照数字能说明问题:一张中等复杂度的客服工单,走一遍推理流程要 1 到 2 美元;把低复杂度工单分桶、改用脚本处理后,单价降到 0.2 美元。同一项工作差出五到十倍,差价来自任务怎么组织。仓库的原话是:成本是配置的属性,不是工具的属性。
冷数据和这份材料的局限
最后是一批让人清醒的数字。上线首日流量移动端和桌面端各半,iOS 占 44%,而三天的开发和测试发生在笔记本上——移动端布局成了反馈里的第一大类别,"验证环节加设备模拟"这条规则,成本是一整个发布日的用户反馈。引荐流量里 X 占去绝大多数,Bing 贡献 8 个人。那个跑了一天的赚钱 agent 收入为零。
局限也要讲清楚。这是二手观察笔记,不是 xAI 官方出品;数字是直播里口述的,量级可信,精度存疑;部分结论绑定 Grok Bot 这个具体产品的机制,比如每个 bot 独占一台 Linux 虚拟机、记忆按 bot 隔离存储,换一套平台,隔离和权限那几章要重新推导。
即便算上这些折扣,公开渠道里这类材料找不到第二份:一个 agent 系统在真实用户、真实部署、真实资金面前三天里的完整失败记录,外加一套可以整份搬走的规则文本。40 条翻车记录每一条按同一条元规则写成——剥离事故,留下原则——这份仓库本身就是它自己最重要那条规则的示范。冲着这条自洽,它值得一个 star 和一个下午的通读。
仓库地址:github.com/unicodef1wn/grokbot-field-notes