子 Agent 不是越多越好：Harness 里的委托边界怎么画

dsh 最近的预览版里，有一个很有意思的变化：Claude Code、Codex 这类能力可以被做成 Profile Bundle，按需安装成子 Agent，还支持非交互权限模式和多个命名实例。这比「再开一个聊天窗口」更接近生产形态——委托变成配置，而不是临时口头吩咐。

但子 Agent 一多，系统并不自动变强。很多团队的真实体验是：主 Agent 把难题甩出去，子 Agent 各自忙碌，最后没人能对整体交付负责。Harness 要解决的，正是这道委托边界。

一、先分清：并行劳动 vs 结构化委托

并行劳动是：多个角色同时改仓库、同时搜资料，谁都可以碰任何文件。结果通常是互相覆盖，或全体挑软柿子。

结构化委托是：主循环保留目标与验收，子 Agent 只领取边界清晰的子任务，返回可检查的结果，而不是「我感觉做完了」。

判断标准很简单：如果去掉某个子 Agent，主任务的关键路径几乎不变，那它多半是重复劳动；如果它拿走的是一块有独立验收标准的硬任务，那才是委托。

二、委托边界至少要写清五件事

目标：子任务要达成什么，用可验证的句子写，不要写「尽量优化」。

输入：允许它看到哪些上下文、哪些文件、哪些工具结果。不是把整段 transcript 全扔过去。

权限：它能读什么、写什么、能不能联网、能不能发版。非交互权限模式的价值就在这里——无人值守时，权限必须事先声明，不能弹窗问人。

完成定义：怎样算成功返回。最好是测试通过、产物路径、或结构化报告，而不是一段自然语言总结。

失败回流：超时、权限拒绝、验收失败时，结果怎么回到主循环，是否允许重试，由谁升级给人。

缺任何一项，委托都会退化成「把混乱外包出去」。

三、为什么 Bundle 化比硬编码更合适

把子 Agent 做成可安装 Bundle，有三个工程收益：

第一，能力与主循环解耦。今天用 Codex 做补丁，明天换成别的编码 Agent，不必改主 harness。

第二，权限可以随 Bundle 声明。不同子 Agent 的危险面不同，统一权限等于没有权限。

第三，命名实例让同一类能力服务不同场景。比如 review-bot 与 patch-bot 都基于同类编码 Agent，但工具白名单和写入范围不同。

代价是配置复杂度上升。所以 Bundle 该开放的是「能力实现」，不该开放的是「主循环的验收与审计」——这两样仍应留在 mandatory 层。

四、最常见的三种委托事故

事故 1：目标漂移。 子 Agent 把「修这个测试」做成「顺便重构半个模块」。治法：完成定义写窄，写入路径加白名单。

事故 2：权限过宽。 为了图省事给子 Agent 全工具。治法：按任务签发最小权限，默认拒绝，显式放开。

事故 3：结果不可验收。 子 Agent 只回一段「已完成」叙述。治法：主循环不接受纯叙述，必须有可执行检查或产物哈希。

这三类事故里，模型能力通常不是主因，Harness 边界才是。

五、落地时怎么排

先别追求多智能体编排图好看。更稳的顺序是：

1. 主循环先能单 Agent 跑通，并有独立验收
2. 挑出一块边界清晰、失败代价可控的子任务做第一次委托
3. 用 Bundle + 权限清单把这次委托固化
4. 再考虑多个命名实例或并行委托

如果第一步都做不到，上子 Agent 只会让排障成本乘以 N。

结语

子 Agent 的价值，不在「看起来像团队」，而在「把硬任务放到更合适的执行体里，同时不丢掉整体可控」。Harness 画委托边界时，真正要守住的是：目标可写清、权限可签发、结果可验收、失败可回流。能守住这四条，Bundle 化的子 Agent 才是加速器；守不住，只是把单点混乱变成分布式混乱。