这篇文章是我和 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 这条链路补齐，让我能更轻松、更稳定地把事情交出去。
至于那句最朴素的愿望——“尽量少磨损”——我现在觉得它不是愿望，它应该是系统的非功能需求。只要我还在写代码、还在被告警叫醒、还在玩桌游和做饭，这个需求就永远成立。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。