对于 AI Agent 的思考
这篇文章是我和 Chatgpt 一起写的。我的观察是：Chatgpt 逻辑能力很强，但是中文表达实在是太怪了，不知道跟谁学的中文。
凌晨的告警把我从床上拎起来的时候，我就知道今晚的结局了：告警会有用，但是日志会很垃圾。屏幕上 CPU 的峰值像一根针，扎破了系统“看起来还行”的气泡；而我盯着那堆复盘不了的 log，心里又记了一笔——可用性不是靠祈祷堆出来的。
也是从那一刻起，更让我确定了一件事：我现在做的其实不是“用 AI 写更多代码”，而是用 AI 把自己 scale 起来。先把我从执行者的位置挪出来，变成指挥、验收、并且负责迭代这个系统的人，然后再去尝试用这个系统来 scale 别人。
这篇随笔就从这个主题说起。我把多代理开起来，花费 token，感受到仿佛造物主的乐趣。然后紧接着就撞上项目的“隐含知识墙”，又被迫把评估、汇报、记忆这些“看起来不性感的东西”一件件捡起来。中间穿插感冒、做饭、桌游、换编辑器——它们不是偏题，它们是我这套系统真正的约束条件：我只有一个大脑，一天只有 24 小时，而且真的会累。
初尝 scale 的甜蜜点
这天，我把 opencode 的 multi-agent 模式真正用起来了：五个 agent 同时改五个问题。那两小时的体验很像我第一次跑通 6.824 的第一个作业：本地跑起来一个分布式的 MapReduce 系统——日志刷得飞快，任务被同时推进，我的生产力从“手工耕作”变成了“机械化收割”。
在这个过程里，我的 Codex Plus plan 的每周 token 限制也第一次如此迅速地被用完了。
并行这件事很容易让人上瘾，因为它让人感觉太好了：不需要一直盯着，我甚至能短暂地相信自己已经摆脱了瓶颈。但并行的代价也很直白：成本线性，且错误会被放大。如果一开始方向错了，多代理不是“多条路试试”，而是“五辆车一起开进沟里”。
所以我对“自治”的定义，很快就从一句口号变成了三个具体的目标——我把它写得像 SLI：
- 尽量少来打扰我（降低中断的成本）
- 它尽量多工作（提高有效产出）
- 尽可能提升可靠性（不要偏航、不要闪退、不要把我拖进返工的泥潭）
这三个目标后来反复出现，成了 LegionMind 所有设计决策的北极星。
瓶颈是我自己
把执行工作尽量丢给 agent 之后，人类的理性和欲望就成为了推进工作的瓶颈。
我的工作流大概是这样的：开发、日常安排、思考与输出——我最多同时稳态运行两三个上下文。超出这个范围，我的调度就会失灵，疲惫会像内存泄漏一样慢慢堆起来。多代理系统并没有消除这个问题，它只是把“执行负担”挪走了，但上下文管理、验收、决策，还是得我来，而且因为 AI 做执行真的很快，因此其他方面的负担变得更重了。
后来我开始更诚实地看待“工作日志”这件事，才有了这个 2026 工作日志。我在里面也提过，写它不是为了未来回忆细节，而是为了把上下文从脑子里卸载出来。记录本身就是一次思维链条的整理，像把内存里的脏页做整理后刷回磁盘。
我甚至发现，日志如果变成“必须坐下来写三十分钟”的仪式，就会让人恐惧；一恐惧，就会停更；停更几天，就越积越多，最后更难写。系统设计再漂亮，落到人的习惯上，还是会被现实击穿。有关这点，我还在探索，下面还是言归正传，谈谈 AI 吧。
“隐含知识墙”，当我们给 AI 下达指令时，我们在期待什么？
当我真正把 agent 推进到复杂项目里——尤其是那种 monorepo、跨多个 package 的项目——一个典型事故出现得非常快：
我让 agent 参考某个类似的实现（比如 vendor-okx）去接入一个新模块。结果它不仅学到了正确的写法，也学走了过时的实践：对于我自己的案例来说，这个过时的实践是把账户流写进了一个已经不用的入口。对我来说，这是“项目早就演进过的常识”；对一个新 agent 来说，这些演进是不可见的。
那一刻我意识到：agent 的“学习”更像是从可见样本做拟合，而不是从组织记忆里理解历史。它并不知道什么是“现在的标准”。
于是“外置大脑”从锦上添花变成了必需品。但外置大脑也有一个残酷的代价：维护它本身会消耗注意力，而注意力正是我最缺的资源。
我曾经尝试用一组 AGENT.md 做项目记忆，但很快就碰到难点：怎么区分什么是噪音、什么是值得固化的经验？这不是文档写作的问题，这是评估问题——你必须知道什么会导致 agent 翻车、什么能显著提高它的通过率，才值得写进“记忆”。
当我们给 AI 下达指令的时候，我们究竟在期待什么？把这层结构整理成一个“指令/知识分层”的框图，就会得到如下结果：
┌────────────────────────────┐
│ ① 本次任务指令（你能说清的） │
├────────────────────────────┤
│ ② 项目技术决策/局部最佳实践 │ ← 最容易“隐含”，也最容易翻车
├────────────────────────────┤
│ ③ 领域背景（问题是什么） │
├────────────────────────────┤
│ ④ 工程常识/风格偏好/经验积淀 │
├────────────────────────────┤
│ ⑤ 世界背景知识 │
└────────────────────────────┘
在一次对话里，真正能清晰传达给 AI 的，只有最上面那层。
结论是：上下文越小、指令越清晰、历史包袱越少，AI 越容易高质量完成。隐含背景越多，越容易出现“莫名其妙的活”。
这也是 LegionMind 诞生的原因。不要求下达指令的人“能写出一个完美的 prompt”，而是要把第二层的隐含知识，变成可以被加载、可以被复用的东西。
意图对齐 + 分层验证
目前版本的 LegionMind 会强制要求 Agent 根据用户指令，收集项目相关信息，写成一份详尽的 RFC 式的文档，力求在一开始最大程度地对齐用户需求。原因很简单：
当 multi-agent 系统开始翻车，人类的第一反应往往是：写更长的 RFC、做更严格的 review，把风险压到最前面。人和 AI 的协作会被推回一种近似瀑布流的形态：线性推进、灵活性差，不过要命的是：给我带来的心智负担会比较大。
人类的组织如何做到让上层决策者不用被信息淹没呢？人类的决策者如何做到让属下放手去做呢？对次 CZ 有一些思考
本质上就是：
- 意图对齐：让 agent 不偏航
- 分层验证：让错误尽早暴露，且可以轻易回滚，而不是最后才发现方向错了
这不是空话。我给它配了一个“生产流水线”式的流程图，用来约束自己和 agent 的交互方式：
┌──────────┐
│ Intent │ 目标/约束/不做什么
└────┬─────┘
│
┌────▼─────┐
│ Plan │ 拆解、里程碑、假设
└────┬─────┘
│
┌────▼─────┐
│ Execute │ 写代码/改配置/生成文档
└────┬─────┘
│
┌─────────▼─────────┐
│ Verify │ 分层验证（越便宜越先跑）
│ - build/lint/test │
│ - e2e/bench │
│ - model eval │
│ - human review │
└─────────┬─────────┘
│
┌────▼─────┐
│ Report │ 结论 + 证据 + 风险
└────┬─────┘
│
┌────▼─────┐
│ Memory │ 固化“值得记”的差异点
└────┬─────┘
└──(反馈回 Intent/Plan：形成闭环)
这个流程的关键不是“更复杂”，而是把验证前移、把反馈变成闭环。它能对抗两种最常见的损耗：
- 方向错了还持续并行推进（token 大出血）
- 方向对了但细节不可靠，导致反复返工（心力磨损）
评估的两套语言：pass@k 和 pass^k
有一篇有关如何评估 AI Agent 的表现的文章，对我很有启发。
使用 AI 来完成任务的时候，一般来说分为做两种完全不同工作类型：
- 能力探索型：不在乎一次就对，只想知道“它有没有可能做到”。这时关注的是
pass@k——k 次尝试里至少成功一次。 - 生产回归型：不接受“偶尔可以”，需要“每次都可靠”。这时关注的是
pass^k——k 次尝试必须全部成功。
同一个系统，在不同阶段应该用不同指标说话。能力探索阶段可以少说多听，让 AI Agent 充分发挥它丰富博学的世界背景知识；回归阶段我们必须盯住一致性。
┌────────────────┐
│ Human Eval │ 人看设计/风险/边界条件（最贵）
├────────────────┤
│ Model Eval │ rubric/对齐/一致性检查（中等）
├────────────────┤
│ Static / Tool │ build/lint/unit/e2e（最便宜）
└────────────────┘
原则很简单：能用工具判断的，尽量减少认知消耗。
“汇报接口”是被低估的工程问题
前面章节谈的都是“怎么让 agent 做事”。除此之外的另一个重点是“怎么让我低成本验收”。这部分我还在思考之中，不过有一些间简单的想法，可以顺便在这里谈谈。
核心的想法在于：AI 的汇报不能停留在平铺的 Markdown 和代码 diff。在人类组织里，下属汇报往往需要 PPT，甚至需要一个中层做“昂贵的传声筒”，把复杂信息压缩成可决策的结论、证据和风险。
那么 AI 的 report 应该是什么？
一个非常具体的想法：每一条结论都应该 link 一个 artifact。比如：
- “这个功能已完成” → 链接到 e2e 测试报告、关键 diff、复现实验脚本
- “这个选择更好” → 链接到 benchmark 对比、日志证据、配置变更
- “这里有风险” → 链接到已知不确定性列表、回滚方案
甚至可以有一个专门的 Citation Agent：它不写代码，它只做一件事——把结论和证据绑在一起。
汇报接口变好，人类才能更放心，自治才真正成立。否则 agent 写代码的能力再厉害，我也还是要把大量精力花在“读它写的东西、猜它到底做了什么”上面——这和我想要的“少磨损”是冲突的。
工程化迭代
到了二月，Chatgpt codex 5.3 发布了，体验上确实让人感觉非常聪明。我也因此有了一个担忧：把 workflow 规定得太死，会不会反而浪费了 AI 的潜力？
LegionMind 一直以来在尝试的是：给定一个确定的框架、给定一个领域中比较成熟的 SOP(上面的 3、4 层)，让 Agents 在给定的轨道里跑，减少偏航。但当模型更聪明时，也许更合理的方式是——我只给目标、约束、评估机制，让它自己设计最合适的路径。
这也意味着另一件事必须发生：我得用更科学的方式比较不同版本系统的表现，而不是凭感觉说“这版更聪明”。
于是“benchmark”在我脑子里从一个念头变成了刚需：我需要一套复杂编码任务的回归测试，用同一组任务去量化：
pass@k（能力探索）pass^k（生产可靠）- 成本（token/时间）
- 返工率（人类介入次数、修改轮次）
- 覆盖面（跨项目、跨 package 时的稳定性）
只有这样，我才能真的“迭代系统”，而不是“迭代心情”。
有关这方面的事情，我接下来会做两件事：
- 考察市面上的 LLM Coding benchmark 看看有没有什么可以直接拿来用的。
- 根据我们的实际场景，设计一套 benchmark （LLM 面试题）让不同版本的 LLM 和 Legion 来完成任务。甚至可以做一个 360 环评。
8. 里程碑
有一个晚上，我使用这套 LegionMind 系统终于把一个横跨多个 project 的 http-proxy 任务终于做通了。过程并不优雅，甚至触及了当前系统的极限——subagent 偶尔闪退，跨 package 的上下文让多代理协作变得脆弱。
但结果是一个我很在意的里程碑：我基本可以脱离编码了。多数情况下，我只需要留下少量对设计文档的 review comment。
这样的变化让我感到非常舒适：从键盘执行者变成审阅者、决策者、系统迭代者。也就是我一开始说的：把自己 scale 起来。
与此同时，我也更愿意承认一条现实原则：不要做容易被海浪拍死的轮子。我发现某个能力平台本身在演进（比如 opencode 已经在做某些 bridge 能做的事），宁愿先 hold 住，也要把精力投到“会随着海面上升一起上升”的系统层能力上——评估、记忆、汇报、可靠性。
我和 AI Agent 的互相驯化
写到这里，我发现这一个多月里，我和 AI agent 其实在互相驯化：
- 我驯化它：用 SOP、验证、汇报接口，把它从“会写代码的模型”推向“可交付的系统”。
- 它驯化我：逼我承认人的瓶颈、承认评估的重要、承认组织与流程才是问题的核心。
如果要把这段经历压缩成几句话，我现在大概相信：
- 自治不是聪明就够了，是少打扰、多产出、可验证。
- 最昂贵的不是 token，是返工和注意力泄漏。
- 隐含知识比代码更容易让 agent 翻车。外置大脑必须有，但必须可维护。
- 验证要分层，目标要分阶段：先 pass@k，再 pass^k。
- AI 的汇报接口必须工程化：结论要带证据，最好能一键指向 artifact。
- 当模型变强，流程可能要放权给 AI；但放权的前提是你有 benchmark。
接下来我大概会继续做两件事：一是把 benchmark 体系搭起来，让“迭代 legion/多代理系统”变成一件可度量的事；二是把 report/citation/artifact 这条链路补齐，让我能更轻松、更稳定地把事情交出去。
至于那句最朴素的愿望——“尽量少磨损”——我现在觉得它不是愿望，它应该是系统的非功能需求。只要我还在写代码、还在被告警叫醒、还在玩桌游和做饭，这个需求就永远成立。