切换主题
为什么你改个小功能都要反复沟通，别人却让 AI 无人值守搞出百万行项目——智能体基建系列
用 AI 编程的日常往往是这样的：提需求，等输出，跑测试，把报错贴回去，再等输出……改一个几十行的小功能，人能来回折腾一上午。可网上那些案例听起来像另一个世界：有人让 AI 无人值守地跑了两周，搞出了一个能编译 Linux 内核的 C 编译器。差距到底在哪？
近期 OpenAI、Anthropic、Stripe 先后公开的工程实践，让我有了些眉目：他们围绕 AI 重建了一套我知之甚少的工程方法。
一、别人到底干了什么：四份官方实践速览
先看案例，每一条都来自一手官方博客：
| 案例 | 干了什么 | 规模 | 成本/投入 | 官方原文 |
|---|---|---|---|---|
| OpenAI Codex 团队 | 5 个月交付约 100 万行代码，1500+ 个 PR 合并，无一行人工编写 | 3 人起步扩到 7 人 | 约手工编写 1/10 的时间 | Harness engineering |
| Anthropic C 编译器 | 16 个 Claude 并行编写 Rust 版 C 编译器，可编译 Linux 6.9（x86/ARM/RISC-V） | 约 10 万行代码、近 2000 次会话 | 20 亿输入 token + 1.4 亿输出 token，总成本约 2 万美元 | Building a C compiler with a team of parallel Claudes |
| Stripe Minions | 一次性端到端 coding agent，每周合并 1000+ 个 PR | 公司内部广泛使用 | 人只审查，不写码 | Minions: Stripe's one-shot, end-to-end coding agents |
| Ralph Loop（ZeroSync） | 无限循环 + 每次全新上下文，3 个月自主开发出完整编程语言 CURSED | 单 agent 串行 | 社区开源实践 | The Ralph Loop: Long-Running AI Agents |
四个案例有一个共同点：他们都把 AI 当成一个需要"接入环境"的团队成员。
二、差距第一层：资源投入
先说最实在的一条：无人值守是要花大价钱的。
Anthropic 的编译器项目在两周内跑完近 2000 次 Claude Code 会话，消耗 20 亿输入 token、产生 1.4 亿输出 token，总成本略低于 2 万美元。OpenAI 那边 5 个月 1500+ 个 PR，团队规模从 3 人扩到 7 人，背后是持续的 Codex 用量。Stripe 每周合并 1000+ 个 PR，同样需要稳定的大规模 agent 调用额度。
对比个人开发者的 coding plan，这个量级高出成千上百倍。有的时候"贫穷限制想象"，如果用量被卡死，无人值守根本不敢尝试——你连"让 AI 放开跑"的机会都没有。先算清账，再决定无人值守适不适合当前项目，是第一条清醒的认知。
三、差距第二层：工程方法
钱花到位只是前提。同样的模型、同样的额度，别人能无人值守，而我还要反复沟通，差距还在下面六条工程方法上。
1. 让环境对 Agent 直接可读
OpenAI 团队的一个关键做法是：让应用程序的 UI、日志和应用指标对 Codex 直接可读。他们把 Chrome DevTools 协议接进智能体运行时，让 Codex 能直接复现错误、验证修复、推理 UI 行为；日志和指标通过本地可观测性堆栈暴露给智能体，Codex 可以用 LogQL 查日志、用 PromQL 查指标。于是"确保服务启动在 800ms 内完成"这种提示变得可行。
对照我的日常：报错靠人肉复制粘贴喂给 AI，反馈回路断在人身上。AI 看不到界面、看不到日志、看不到指标，自然只能靠转述——沟通成本就是这么堆出来的。以后想让 AI 少问看来得先让它能自己看。
2. 渐进式披露，而不是百科全书式 AGENTS.md
OpenAI 团队在情境管理上学到的最早一课是：给 Codex 的是一张地图，而不是一本 1000 页的说明书。他们的 AGENTS.md 只保留约 100 行，当作内容目录，指向仓库里结构化的 docs/ 目录；设计文档、架构文档按域编目，连"这份文档是否过时"都有验证状态。
这背后的逻辑是渐进式披露：智能体从一个小而稳定的切入点开始，被指引下一步去哪看，而不是一开始就被淹没。对照我自己：AGENTS.md 越写越长。百科全书式的指令文件会挤掉任务和代码本身的上下文，让智能体要么错过关键约束，要么针对错误约束优化。当一切都"重要"时，一切都不重要了。
3. 循环清理 AI 垃圾
AI 写代码快，制造垃圾更快：死代码、过期文档、不再准确的注释。这些东西不清理，会持续污染后续每一次的上下文。
OpenAI 的做法是让专职的 doc-gardening 智能体定期扫描不再反映真实代码行为的过时文档，自动发起修复 PR；CI 作业会验证知识库是否被更新、是否交叉链接、结构是否正确。Ralph Loop 里的 fix_plan.md 也是同理：它是动态任务追踪器，边执行边更新，完成后提交版本控制，让"下一步干什么"永远有据可查。
4. 智能体分工
Anthropic 的编译器项目把 16 个 Claude 并行跑起来，靠的是任务锁文件：每个 agent 在 current_tasks/ 里写一个文本文件认领任务，git 的同步机制保证两个 agent 不会抢同一个任务。除了干活的 agent，还有专职维护文档、盯代码质量的专用 agent。
Stripe 的 Minions 同样不是"一个 AI 干所有事"，而是把任务拆成一次性端到端的单元。对照我：只有一个 AI 干所有事，上下文和注意力都是单点瓶颈。一个 agent 干不了的事，一群分工明确的 agent 可能可以。
5. 高质量测试当护栏
无人值守最反直觉的一点是：没有人在旁边盯着，靠什么保证 AI 不把项目改坏？Anthropic 的答案是测试。编译器项目能逼近 Linux 6.9，靠的是测试驱动：写一小段、测一小段、错就改、对了继续。测试是无人监督时唯一能把 agent 拉回正轨的机制。
对照我：测试覆盖不足，AI 改坏了没人知道，只能靠人肉回归。测试不是可选项，它是放手让 AI 干活的前提。
6. Ralph Loop：无限循环 + 每次全新上下文
最后是机制层面的核心：Ralph Loop。它本质上是一个 bash 循环——任务做完立刻接下一个，循环往复。但它的关键设计不是"循环"，而是"每次迭代都开新会话"：
- 读 fix_plan.md，了解当前状态
- 选最重要的任务（Ralph 决定，不是人）
- 拉取相关 spec，按需加载
- 实现改动，一次只做一件事
- 运行测试，测试是护栏
- 更新 fix_plan.md，记录结果
- 提交 git，状态落盘
- 开新会话，用全新上下文继续
为什么要强制新会话？因为上下文会腐烂。一个跑了几小时的长会话，越到后面质量越差，早期内容会挤占有限上下文。每次新会话等于每次都是"满血状态"，配合文件化的状态追踪，AI 既不记得上个会话的细节，也不需要记得——它看文件就知道该干什么。
四、从"反复沟通"到"无人值守"
把上面七条差距收拢成一条路径，转型可以分步走：
先补测试护栏。没有可靠的测试，后面所有步骤都建立在地基上。
再建可读环境。让 AI 能看到 UI、日志、指标，减少人肉转述。
规范知识组织。AGENTS.md 从百科全书改成目录，配合渐进式披露。
建立清理流程。死代码、过期文档定期清，别让 AI 垃圾越积越多。
逐步分工。任务拆开，多个 agent 并行，各自专职。
最后套上 Ralph Loop。让循环机制把前面所有工程纪律自动跑起来。
说到底，无人值守不是"把需求丢给 AI 就跑"，而是把工程纪律从人转移到系统。别人能搞出大项目，不是他们的 AI 更听话，而是他们把 AI 干活的环境、护栏和节奏都修好了。这恰恰是"智能体基建"系列一直在讲的事：与其问 AI 为什么不行，不如先看看给 AI 搭的基建行不行。
如果你觉得文章对你有用，可以关注我获取更多的智能体基建资讯。