子代理与任务委托

一个 Agent 能干的事，终究受一个上下文窗口、一份注意力所限。复杂的任务需要拆解，拆出去的部分最好由独立的 Agent 承担，带着自己的上下文、自己的工具集去完成，再把结果交回来。dsh 把这件事做成了第 6 章讲过的能力接缝，ctx.subagents，一个委托接口加上一批形态悬殊的提供者。本章看这个接缝如何跨越进程、会话甚至产品的边界。

先看接口约定了什么。主 Agent 通过面向模型的委托工具发起一次委托，请求里带任务内容，也可以带输出格式约束、工具过滤、人设说明。服务在启动前先核对所选提供者是否支持请求里用到的每一项能力，不支持就当场报错，明确到能力名，绝不会接下任务再悄悄降级。任务完成后，结果作为工具结果回到主 Agent 的周期里，进入日志，继续第 5 章那个循环。

提供者的形态是这个接缝最精彩的部分。进程内提供者在同一个进程里组装一个子 Agent，子代理有自己的专属作用域和工具集，与第 8 章的机制无缝衔接。fork 提供者从当前会话日志分叉出一条新的日志副本，子代理带着完整的任务前文出发，省去重新交代的成本。再往外跨，ACP 提供者把任务委托给另一个产品里的 Agent，两边通过自动化协议对话，甚至还有直接对接其他厂商 Agent 产品的提供者。一个运行时把别家的 Agent 当作自己的一种外设，这是接缝设计能走到的最远处。

与 shell 接缝的单执行者约定不同，子代理接缝允许多个提供者同时注册，按名字选用。委托工具会为每个提供者呈现一个对应的模型侧工具，模型在发起委托时点名要哪一种。这个差异不是任意为之。shell 只有一个执行世界，选一个是自然语义。委托的世界天然多元，今天的任务适合 fork 一个带前文的副本，明天的任务适合丢给某个专精的外部 Agent，共存才是自然语义。

委托关系本身也是耐久事实。子代理的出生记录在会话存储里，父子谱系与委托深度随之确立，深度上限防止无限套娃。子代理还可以续聊，第一次委托结束后，主 Agent 能再次唤醒同一个子代理继续上次的对话，不必每次都从零介绍背景。这些编排能力同样由接缝的服务侧持有，而不是散在各提供者里。

安全性在这里也有交代。委托请求里的工具过滤把第 8 章的作用域机制延伸了一层，子代理拿到的工具集是父代理明确划定的子集。人设与输出约束在启动时就核对，防止任务半途才发现提供者不支持。可以说，第 6 到第 8 章建立的所有机制，在这个最复杂的接缝上全部复用了。

委托生态还有两个耐久件。一个是子代理目录，当前会话里出生过的子代理都在册，主代理随时可以列出它们、查看状态、再次唤醒，这份名册同样从会话存储读出。另一个是回报通道，子代理在长任务里不必憋到结束才说话，它可以通过一个专属的回报工具把阶段进展送回父代理的收件箱。两个设计都在回答同一个问题，委托出去的任务如何保持可感可控。经验丰富的人知道，多代理系统失控时，子代理通常仍在按指令干活，真正的裂缝在于父代理对飞行中的孩子一无所知。

多代理协作的形态在这里是开放式的。dsh 仓库的示例里有一种被社区称为 Ralph 的工作流，主代理把一个大任务拆成队列，逐个委托给干净的子代理，自己只负责验收与调度。这并非框架的内建功能，只是接缝与续聊能力组合出的一种用法。接缝设计到位时，高层模式由使用者发明，框架不需要预先批准。

到这里，动态与静态的拼图都齐了。下一章把十章内容拼回一张全景图，并回答那个最终的问题，这套设计里哪些模式值得带回你自己的系统。