https://x.com/lingxi/status/2094493172516966781 看看这篇文章

这篇《Grok Bot for Engineering》讲的核心，是让 Agent 替你管理 coding agents，而不只是替你写代码。 作者 Lingxi Li 描述的工作方式： 他按领域配了 5 个工程 bot，分别负责移动端、桌面端、基础设施、Android、harness。工程 bot 接任务后，再创建 Cursor cloud agents 去执行，自己负责跟进、验收、催返工。 比如改一个 iOS 界面，不是等 coding agent 说“改好了”就结束，而是要求它跑模拟器、交前后截图，再由 Grok Bot 看图核对。不符合要求就继续追问、返工；运行卡住了，就检查执行记录、尝试解除阻塞。需要特殊环境时，也能把任务派到自己的 Mac 等私有 worker 上。 我觉得最值得看的有三个点。 第一，闭环比并发数量重要。 任务描述里同时写清“做什么”和“拿什么证明完成”。截图、测试、CI、审查结果都成为下一步行动的依据。管理 bot 不只是分发任务，还承担验收和纠偏。 第二，把任务状态放到上下文之外。 他们用共享 Notion 数据库记录任务，每 30 分钟检查 PR 的安全问题、CI 和冲突，有问题就重新推进；通过后再启动代码审查。审查置信度高且影响范围小的 PR 自动合并，其他交给人。 这不是让模型拥有无限记忆，而是靠持久化状态和周期性检查，让任务跨越多轮上下文继续推进。 第三，让复盘结果进入共享规则。 还有一个不写代码的运营 bot Jenny，负责 onboarding、每日对齐和事故复盘。某个 bot 犯错后，Jenny 分析原因、更新 playbook，再通知其他工程 bot。 这种设计有明确的 bot 间交流和工作流，属于真正的多 Agent 编排，不只是把多个 coding agent 并排开起来。 文章也有需要打折看的地方。 作者称自己从手动管理 15 个 cloud agents，扩展到由 bot 团队同时管理 200 多个；还提到某成员一个月交付 2,000 多个 PR。这些都是作者自述，文章没有提供成本、返工率、线上缺陷率、PR 大小等对照，不能直接等同于工程效率提升多少倍。 “每天开会非常有效”“代码质量达到我的标准”也主要是个人经验，不是消融实验结论。文中倒是明确提醒：P0 模式每 5 分钟检查一次执行进度，会很快烧掉大量 token。 我的判断：最有参考价值的不是“模拟一个公司，给 bot 起名字开会”，而是这套具体机制——按领域分工、外置任务状态、基于证据验收、失败自动返工、按风险交还人类。 如果要复现，先做一个管理 bot 带一个 coding agent，把“接任务→执行→交证据→验收→返工或交人”跑通，比直接堆 5 个角色、200 个并发更值得。