编码 Agent 更靠谱的 5 层护栏：Cole Medin 11 条清单的落地版

护栏 3：/compact 是记忆漏斗，交接文才是重启方式

Cole 的第 3 条和第 7 条其实讲的是同一件事：长对话累积的偏差和幻觉，靠"重新开一段对话"比"继续在原对话里挣扎"更省事。

/compact 前后对比：约 90% 的具体细节丢失，且模型不会告诉你丢了什么，只会自信地重构。图片来源：Cole Medin / YouTube（视频约 4 分 20 秒）

这里有条实证：/compact 之后，大约只有 10% 的具体细节被保留下来。他视频里给的例子——"这个函数在 URL 坏了的时候会返回什么"、"路由的精确前缀"、"哪些测试其实存在"——这些都是压缩摘要抓不住的，但恰好是让接下来的实现不出错的关键。更麻烦的是模型不会告诉你它丢了什么，它会自信地重构一个版本继续往下走。

同样的逻辑也适用于"污染对话"：Agent 一旦开始连续犯错，切换到更大的模型不会救你——原对话里的错误模式已经作为"上下文"被下一步预测继承了。大模型是预测机器，它看到前面五步都是错的，最可能预测的第六步也是错的，哪怕它现在换成了 Opus。

所以正确的动作不是 /compact，也不是升模，而是写一份交接文，重开一段对话。交接文可以直接抄这个骨架：

## Handoff: <任务简称>

## 目标
一句话：这个任务最终要交付什么。

## 已完成
- 具体做了什么（引用 commit hash / 文件路径 / 测试名）
- 关键决策点：为什么选了 A 不选 B

## 未完成
- 还剩什么、按什么顺序做

## 已知陷阱
- 试过但走不通的路（避免下一段对话再踩）
- 环境里的暗雷（例如"pnpm test 会启动 mock server，端口 3001 冲突要先 kill"）

## 需要保留的字面量
- 具体的类型定义、错误消息原文、外部 API 的确切 shape
（这一段是 /compact 会丢的东西，必须显式列出）

最后这一段是关键。/compact 会丢的正是这些"具体字面量"——精确的类型、原始报错、外部接口的确切 shape。你手写的时候会知道要留下它们，压缩算法不会。

护栏 4：并发和迭代的两个反直觉硬边界

Cole 的第 6 条和第 10 条是同一类："你以为多多益善的地方，其实要设上限"。

Cole 自己账户的 /usage 输出：39% 的周额度消耗来自"同时开 4 个以上会话"的时段。图片来源：Cole Medin / YouTube（视频约 10 分 32 秒）

第一个硬边界是并发子 Agent 的上限。Claude Code 的 /usage 会告诉你额度到底花在哪儿了。Cole 自己的账户上，39% 的额度是"同时开着 4 个以上会话"时烧掉的——不是这些会话都在干重要的事，而是并行开销本身在吃 token。这里还有一个更容易踩的坑：Claude Code 在你没明确要求的情况下，会自动 spawn 好几个 subagent 去"做深入研究"。如果你的 prompt 是"帮我分析一下这个仓库"，很可能它已经在你不知道的情况下起了十来个 subagent。

限并发比想象中重要。国内做 AI 编码工具集成的团队，尤其是把 Claude API 转卖或者做企业版的，几乎都在 rate limit 上被打过。原因不是用户滥用，而是默认行为里的"并行 fan-out"过于激进。给自己团队的实用规则：主 Agent 只做一件事时不允许 spawn subagent；需要 fan-out 的场景（例如跨仓库搜索）明确指定 subagent 数量上限，别放任它自己决定。

第二个硬边界是迭代次数。Cole 引用的那份研究强制编码 Agent 迭代 10-20 次，结果 85% 的场合里，最后一次迭代之前的版本反而更好。这里发生的事是"讨好性优化"：大模型倾向于满足用户的请求，你说"再改改让它完美"，它就一定会找出点东西来改——哪怕改了之后更差。这是所谓的 sycophancy，实测在国内几家主流大模型上都能复现。

给自己一条硬线：同一段代码，同一个 Agent，最多迭代 3 次。超过这个数还不满意，说明问题在设计不在实现——回到规划阶段，或者干脆按护栏 5 那样，起一段新对话让另一个身份来审。

护栏 5：作者不能审自己

第 9 条是最短也最狠的一条：永远不要让作者审核作品。

这条为什么值得单列一层？因为它是前面 4 层护栏都护不住的地方。规则、钩子、交接文、迭代上限，全部是"帮 Agent 少犯错"的机制；作者审自己是"确认 Agent 有没有犯错"的机制，前者是过程质量，后者是终局质量，两回事。

作者身份的 Agent 会在实现过程中累积假设——它选择了某个技术路线、忽略了某个 edge case、用某种方式解读了模糊需求。让它自己回头审，它会自动补全这些假设，把"我以为的"当"事实"再看一遍，然后告诉你"没问题"。这个偏差不是模型能力问题，是位置问题：站在实现者位置上就看不到实现者的盲区。

落地非常简单：写完之后开一段新对话，把这次改动作为 diff 或 handoff 提交给它，让它以"reviewer"身份看。评审 Agent 的启动 prompt 我常用这个：

你是这段代码的独立评审员。你没有参与它的实现，只能看到 diff 和实现者留下的 handoff。
你的任务不是找语法错，而是找：
1. Handoff 里没提到、但代码里暗含的假设（"这里默认输入是 UTF-8"这类）
2. Edge case 覆盖：null / 空数组 / 超长输入 / 并发调用 / 权限不足
3. 实现和 handoff 声称的目标是否一致
4. 有没有绕过测试或断言的"就地修复"痕迹
每一条都要给出 diff 的具体行号。不要总结，不要夸奖，只列问题。

关键在于最后一句"不要总结、不要夸奖"。默认状态下 LLM 的评审会有大量礼貌性总结，那些内容让报告看着更"完整"，但对决策没用，还稀释了真问题的信号。

收尾：验证是系统，不是补丁

Cole 的最后一条是把这整套护栏拉回起点：在写第一行代码之前，先把验证框架规划好。

不是"实现完了记得加单元测试"，而是从需求开始就想清楚：什么样的输出算对？Agent 自查用哪些工具？集成测试怎么组织？我要在哪一步亲自跑一遍？我希望 Agent 在哪些边界情况上主动打上问号？

如果这套东西是在实现完了之后才补的，它就永远只是"补丁"。作者会围绕已经写好的实现去凑测试，Agent 会围绕通过测试去改代码，绕不回"最初到底要什么"。而把验证框架前置到规划阶段，前面五层护栏才有意义——规则文件里写的是它，钩子里跑的是它，交接文里保留的是它，评审 Agent 依据的还是它。

11 条建议里最容易被当成套话的一条，其实是把整套东西串起来的骨头。这也是为什么我不建议把这 11 条当清单来记——把它拆成 5 层护栏加 1 根骨头，你才会知道自己下一步该修哪一层。