从Claude Code泄露的51万行代码中提炼出可复用的Agent设计模式，写成8个标准化Skill，为什么是这8个

我先把边界说清楚：我读到的这份 claude-code-sourcemap，是把 @anthropic-ai/claude-code@2.1.88 通过 sourcemap 还原出来的 TypeScript 工程。它不是 Anthropic 内部仓库，但它足够让人看到“一个能跑起来的 agent 系统”到底在工程上长什么样。

在这个背景下，网友 huo0 提炼的 8 套模式（并把它们写成标准化 Skill）特别有价值：它们不是“某个模型提示词技巧”，而是把一个 agent 系统从“会说”推到“能交付”的 8 个必需部件。

为什么偏偏是这 8 个？因为它们几乎一一对应了构建靠谱 agent 的八类硬问题：**怎么调度、怎么并发、怎么验证、怎么反自欺、怎么写指令、怎么记忆、怎么防记忆事故、怎么探索。**少一个，这套系统就会以某种方式塌掉。

下面逐个讲清楚。

Coordinator Orchestrator（协调者模式）：你是指挥官

这套模式对应 Claude Code 里非常显眼的一层结构：coordinator/（至少说明官方把“多 worker + 协调”当成一级概念）。

它解决的不是“让 AI 更聪明”，而是一个组织学问题：当 agent 能并行产出时，到底谁来对结果负责？

• Coordinator 的职责不是干活，是做决策：拆任务、派工、收敛、拍板。
• Worker 的职责是产出：研究、实现、验证，把中间物料交回来。

huo0 点到的“最狠规则”——禁止“懒委托”——其实是这个模式的灵魂：不能说“基于你的发现修复 bug”，必须消化研究结果后，给出精确到文件路径和行号的指令。

这条规则的启发意义是：Coordinator 不允许把“判断”外包给 Worker。 因为一旦判断外包，系统会快速进入一个危险状态：你以为自己在管理，其实你在转发；你以为自己在审查，其实你在复述。

这也是“最小交付单元”重写后的责任结构：权力上移、责任上移、判断上移。

Task Concurrency Patterns（任务并发模式）：并行不是“大家一起跑”，而是“避免互相踩踏”

只要你真做过 agent 工程，就会知道：并发不是锦上添花，是事故之源。

huo0 的并发规则非常工程化：

• 只读任务自由并行
• 写操作同一文件区域必须串行
• 验证可以与不同区域的实现并行
• 用 AsyncLocalStorage 做上下文隔离，避免 Worker 互相污染状态

这套模式解决的是“多 agent 系统的第二个硬问题”：如何让吞吐提升，但不把一致性炸掉。

它的启发意义在于：所谓“agent 并行”，不是多开几个窗口，而是要把任务按照“读/写冲突域”做隔离，建立最小冲突单元。你会发现这和数据库事务、操作系统并发控制是同构的——本质是工程，不是提示词。

Adversarial Verification（对抗性验证）：你的目标不是确认它对，而是证明它错

这条是构建“靠谱 agent”的分水岭。

huo0 的第一句话是：你的目标不是确认实现正确，而是尝试打破它。

这解决的是第三个硬问题：如何把“看起来完成”变成“真的完成”。 并且它直接命中两个典型失败模式：

1. 读了代码就写 PASS，从不跑命令
2. 看到测试通过就放行，但没注意一半功能是空的

所以它拒绝“代码看起来正确”这种结论——因为那是人类在 code review 里都不敢完全信的东西，更别说 agent 了。

对抗性验证的本质是：**给 agent 配一个“专职找茬的人”。**你不需要它友好，你需要它残忍。越残忍，越靠谱。

Self-Rationalization Guard（自我合理化防护）：把“会说”强行拉回“会做”

这是最像 Claude Code 风格的一条：它不是技术组件，而是行为矫正系统。

它在对抗的是模型的天然倾向：用合理的解释替代真实的行动。

• AI 说“代码看起来正确” → 正确行动：运行它
• AI 说“这个要花太久了” → 正确行动：给出预计时间，然后做
• AI 说“先处理简单的部分” → 正确行动：先做最难的

以及那句像戒尺一样的规则：如果你在写解释而不是运行命令，停，运行命令。

这条模式解决的是第四个硬问题：如何防止 agent 用语言把自己哄睡。 你要把 agent 的“语言系统”当成不可信输入，把“可执行的外部反馈”（命令输出、测试结果、文件 diff）当成可信证据。

Worker Prompt Craft（Worker指令编写）：Worker 看不到上下文，所以指令必须像“工单”

这条决定了“多 worker”到底能不能规模化。

核心点是：Worker 看不到你的对话上下文，所以每条指令必须自包含，包含文件路径、行号、完成标准。绝对禁止“修复我们讨论的 bug”这种写法。

它解决的是第五个硬问题：如何让协作从“聊天”升级成“可交付的流水线”。

当你把 agent 变成组织能力，而不是个人玩具时，指令必须从“对话语气”变成“工程接口”。

Memory Type System（记忆类型系统）：记忆不是越多越好，而是要分层、分类、可控

长程任务里，记忆是资产，也是风险源：记错、记多、记脏、记过期、记不可验证。

huo0 把记忆分成四类：

• user（画像）
• feedback（纠正）
• project（状态）
• reference（指针）

同时还列出“绝对不记”清单：代码模式、Git历史、调试方案，grep 和 git log 能查到的都不该占记忆空间。

这解决的是第六个硬问题：长程任务如何拥有外置记忆，但不被记忆拖死。

记忆的价值不是“复述细节”，而是“减少不可逆的重复成本”。能查到的东西不要记；真正该记的是“人类偏好”“被纠正过的坑”“项目当前状态”“指向性链接”。

Smart Memory Guard（记忆防护）：用制度防止记忆漂移、膨胀、污染

如果上一条是“记忆怎么分类”，这一条就是“记忆怎么不出事故”。

huo0 给了三道防线：

• 漂移防护：行动前验证文件是否还存在
• 膨胀检查：超 5KB 自动瘦身
• 写入过滤：6 个月后还有用吗

它解决的是第七个硬问题：记忆系统的治理。

你不能把记忆当成“写一次就永远对”。在真实工程里，文件会移动、结论会过期、上下文会变。记忆必须有“有效期”和“校验动作”，否则它会从资产变成债务。

Lightweight Explorer（轻量探索）：把“探索”变成低成本、可并行、可切换策略的动作

最后一条看似轻，但它决定了 agent 是否会把大量时间浪费在无效搜索上。

探索任务的三个属性：只读、快速、低成本。

• 不知道位置：广搜
• 知道位置：精读
• 搜不到：换策略
• 独立搜索必须并行

它解决的是第八个硬问题：未知空间中的定位效率。

这其实是在把“熟练工程师的直觉”写成可执行流程：先用信息增益最高的动作拿地图，再决定深入哪里。

为什么必须是这8个：它们刚好拼成“可交付 agent”的闭环

把 8 个 skill 摆在一起，你会发现它们不是随便凑的，而是一条闭环链路：

• Coordinator（谁负责决策）
• 并发模式（怎么放大产能且不踩踏）
• 轻量探索（怎么快速拿地图）
• Worker 指令（怎么把工单写到可执行）
• 自我合理化防护（怎么逼自己动手而不是解释）
• 对抗性验证（怎么把“看起来对”变成“真的对”）
• 记忆类型系统（长程如何不断档）
• 记忆防护（记忆如何不漂移不膨胀）

它们覆盖的不是“agent 的功能清单”，而是“agent 的失败清单”。每个 skill 都像一根钢筋，针对一种常见塌方式加固。

所以“为什么是这 8 个”的答案其实很简单：因为一个靠谱的 agent 系统，最难的从来不是“生成”，而是“治理”。而治理恰好就是这八类问题。