多 agent 系统的 harness 装在哪一层？Anthropic cookbook 给了第一份明牌

上次讲 harness 的时候立过一条判断：真正的 harness 不是 agent 视野内的 orchestrator/skill/plugin，是 agent 看不见的边界。 那次是从单 agent 的角度讲的——sandbox、hook、capability 配置在哪、agent 能不能改。结尾留了一个没回答的问题：多 agent 时这条边界怎么变？

很多开发卡在这道坎上。单 agent demo 跑得漂亮，一上真业务就要拆——KYC 不仅查身份证还要查股东穿透，月末关账要拉 ERP 数据再走签批。单 agent 拿再大的上下文也塞不下整条流程，prompt 写到 3000 字就开始混。拆成多 agent 之后，新问题立刻冒出来：API key 还要不要进每个 agent 的 prompt？跨段的 audit log 怎么串？某一段越权调了不该用的工具，怎么提前拦？

本周 Anthropic 把 anthropics/financial-services 仓开源，19k stars 在涨。仓里发了 10 个金融 agent SKU，但 SKU 列表对做通用业务的开发用处不大。值钱的是另一个目录：managed-agent-cookbooks/。每个企业级 agent 一个文件夹，里头是一份明牌答案——把 workflow（agent 协作的骨架） 和 harness（agent 看不见的约束） 物理分两层放，让 harness 在多 agent 跨段时强制一致。

挑 GL Reconciler（总账对账，找差异、回溯根因、走签批）翻一遍。

第一层 workflow：让协作发生

workflow 是 agent 自己看得见、能调用、能选择的协作骨架。cookbook 把它压在三个文件里。

agent.yaml 的派活协议——声明能调用哪些子 agent（callable_agents，preview 能力）、什么事件路由给谁。GL Reconciler 这个 orchestrator 自己不对账，只做"把对账拆成几段、每段交给一个 leaf-worker"。orchestrator 越浅越好（几十行 yaml），不碰业务逻辑。

subagents/*.yaml 里每个 leaf-worker 单一职责到变态的程度——一个 yaml 文件、几百 token、几个工具，只干一件事。但 cookbook 的 GL Reconciler 拆 leaf-worker 不是按业务步骤拆"找差异 / 查原因 / 走签批"——它按 trust tier 拆：reader（接触不可信的外部对账文档、只有 Read/Grep、没有 MCP、没有写权限）/ orchestrator（不接触外部文档、读 + 派活）/ resolver（不接触外部文档、唯一持写权限）。

这一刀比"单一职责"深一层——它是 prompt injection 的物理隔离：恶意 prompt 进 reader 也跑不动，因为 reader 没写、没 MCP、没下游 agent；reader 必须输出符合 output_schema 的结构化 JSON，scripts/validate.py 做长度上限和字符类校验，注入的指令在这一步被砍。orchestrator 拿到的已经是 sanitized 的数据，不再是原始文档。

为什么不直接让单 agent 又读又写又判断？因为 long session 跨业务步骤会出现 context drift，更要命的是混了 trust tier——agent 一旦同时持有不可信输入和写权限，前者污染后者就是直接的安全事故。拆开后每个 leaf-worker 跑完就死，上下文不带进下一段——Unix philosophy 在 LLM 时代的重述：do one thing and do it well，并且只持有干这一件事必需的权限。能力够，注意力不够。注意力的边界就是 leaf-worker 的边界。

steering-examples.json 是事件总线——leaf-worker 干完一段发 handoff_request 事件 → orchestrator 拿到事件 → 决定下一步派给谁：

{"type": "handoff_request",
 "from": "<leaf-worker-slug>",
 "to": "<next-leaf-worker-slug>",
 "payload": {...}}

仓里还有 orchestrate.py 当参考实现——事件循环，谁说 to 字段都不算数。直接 call 等于 leaf-worker 写死了下游存在，明天换段要改三处；事件总线把"谁干"和"干什么"分开，整个 graph 运行时拼出来。

这三件事让多 agent 系统能跑顺。但 agent 自己看得见、用得上的东西——按上次那条判断——不是 harness。

第二层 harness：让协作敢于上 prod

真正画死边界的另一层在 agent.yaml 的另一半声明——单 agent 时这些东西也讲过，但多 agent 时必须跨段一致，单段做得再好、下一段失守就全失守。四件具体：

long session：跨段会话连续，不是每个 leaf-worker 起一个新 session 把上下文又塞一遍。session ID 在 orchestrator 层管理，leaf-worker 看到的只是自己那段的窗口——它甚至不知道前后还有别的 agent 在跑。

per-tool 权限：每段 agent 只拿当前阶段必要的工具。KYC 阶段没有签批工具，签批阶段没有数据库写权限。这件事 cookbook 里写在 agent.yaml 的 callable_agents 之外的 tools_whitelist 里——orchestrator 给 leaf-worker 派活时把工具表也派下去，leaf-worker 想调没在表里的工具一律拒。这跟"agent 自己判断该不该调"是两回事，前者是 5/6 讲过的 hook 形态，后者是 skill 形态。

credential vault：API key 永远不进任何一段 agent 的 prompt——orchestrator 也读不到明文，它拿到的只是一个引用。leaf-worker 执行工具时 vault 把凭证临时注入运行环境，调用完释放。整个流程结束去 audit log 看，每个 API key 用过哪个 endpoint 一清二楚，模型上下文里始终是干净的。

audit log：从 orchestrator 触发到任一 leaf-worker 的每一个 tool call 串成一条调用链。Console 一打开能复盘整个对账流程谁在哪一步调了什么——这件事在单 agent 也有，但多 agent 时不串链就等于断片，三个月后出问题翻日志根本翻不回是哪一段干的。

这四件，单 agent 写漏一两件还能凑合用；多 agent 写漏一件，前面 leaf-worker 拆得再干净，整个系统也没法进 prod。这就是 5/6 那条判断在多 agent 上的真实落点。

照着画一份你自己的 cookbook

不用等 Anthropic 的 Managed Agents API 公测结束。下次写或重构 agent 系统前，把当前那一摊东西按两层各自摆一遍：

• workflow 三件套 是不是分开了——orchestrator / leaf-worker / events？
• harness 四件套 是不是真在 agent 看不见的层——long session / per-tool / vault / audit？哪一件还混在某个 leaf-worker 的 prompt 里？

最便宜的上手方式：clone 仓挑一个跟你业务最近的 cookbook（KYC Screener、Pitch Agent、GL Reconciler 分别对应合规、销售、财务），照着它的 yaml + subagents + harness 配置画一份自己版本。比读十篇 agent 设计文章管用。

留给下次的问题

这份 cookbook 是 5/6 那条判断在多 agent 上的样板，但它没把所有事都摊开。

跨段一致性的真实代价没讲：long session 接力意味着 orchestrator 永远在线、不能用无状态架构；vault 注入 + 释放比直接读 env var 慢一个数量级；audit log 串链的存储和查询，对中等规模的 agent 系统已经不是小钱。这些数字 cookbook 里没给。

更深一层：当某个 leaf-worker 不是 LLM 而是外部 API、人工审批、或上游的另一套系统，harness 怎么穿透过去？vault 能不能 federation？audit log 能不能跨组织串？

这些是 cookbook 没回答、下次值得单独翻的事。今天先把第一层判断接住——harness 在多 agent 时不是 N 个单 agent 的 harness 相加，是必须跨段强制一致的边界。把这层搞清楚，再去想下一道坎。