DeepSeek Harness 实战子 Agent 与 Agent Teams——让另一个 AI成为你的承包商系列导航概念 / 教程 / 架构 / 插件 / 编码实战 / 框架对比 / 会话日志 / Headless·CI / 自定义工具 / 模型适配 / Web 协同 / 安全沙箱 /本文子 Agent 与 Agent Teams/ 二次开发前面我们讲的都是一个主 Agent在你工作区里单打独斗它读文件、跑命令、调工具。但真实复杂任务往往不是一个人能搞定的——你需要分工。DSH 最让我兴奋的能力藏在一个反直觉的设计里它把另一个 Agent 产品比如 Claude Code、Codex也抽象成了 Provider。也就是说你的主 Agent 可以把一个子任务委派给跑在 Claude Code 上的子 Agent而 Claude Code 在 DSH 眼里只是一个 providersubagent-claude-code。这打开了一扇门异构智能体运行时Heterogeneous Agent Runtime——父 Agent 和子 Agent 不一定共用一套 Harness它们可以是完全不同的产品通过各自的 SDK/协议被统一编排。这一篇我们就把子代理和多 Agent 团队讲透有哪些 provider、委派怎么发生、one-shot 委派有哪些坑、并发子 Agent 会踩什么雷、以及这到底意味着什么。一、先破除一个误解不是只有 DeepSeek 有 Sub-Agent很多人看到DSH 支持子 Agent下意识以为哦它自己也能派小弟。没错但远远不止。真正有意思的是DSH 把 Sub-Agent 本身也抽象成了Provider提供方。目前官方仓库里已经存在的子代理 Provider 包括spawn-in-process进程内派生fork-in-process进程内分叉带父上下文ACP任意 Agent Client Protocol 智能体dsh-sdk另一个 DSH 实例codexOpenAI Codexclaude-codeAnthropic Claude Code也就是说一个 DSH 主 Agent 可以把任务委派给另一个 DeepSeek Agent同门真正的 Claude Code真正的 Codex其中claude-code会调用官方 Claude Agent SDKcodex会启动codex app-server --stdio创建一个临时 Codex 线程执行任务。父 Agent 和子 Agent 不一定共用一套 Harness——这就是所谓的异构智能体运行时。二、子代理 Provider 全家福更具体地说rc.7 的包清单里一共 ship 了 7 个子代理 Provider社区基于仓库实测确认。上面列的 6 个加上 ACP 类里细分出的full peer harness over stdio JSON-RPC基本覆盖了你能想到的所有形态spawn-in-process在父进程内派生一个子 Agent但看不到父的任何历史。fork-in-process同样进程内但以父已完成的多轮为种子启动带着上下文。ACP任何遵循 Agent Client Protocol 的外部智能体都能当子 Agent。dsh-sdk一个完整的对等 DSH 实例通过 stdio JSON-RPC 通信。codex通过codex app-server --stdio调起每次跑一个临时线程。claude-code通过官方 Claude Agent SDK 调起。其余归在 ACP/对等 harness 类里本质都是外部可委派的执行体。这串列表说明一件事DSH 把谁来当手做成了可插拔的插槽。你今天用 in-process 省事明天接 Codex 用它的强项后天接 Claude Code 用它的生态——上层编排逻辑几乎不变。三、RC.8 的关键变化子代理变成 Profile Bundle2026-08 的 RC.8 大更新把子代理的接入方式升级了Claude Code 和 Codex 被正式打包成Profile Bundle预设包按需安装后就能作为子代理灵活调用。安装后父 Agent 看到的不再是底层细节而是两个稳定的工具名subagent_codexsubagent_claude_code调用流程分两阶段父 Agent 决策判断要不要委派、委派给哪个工具。DSH 运行时接手注册适配器、启动进程、管理后台 job、处理取消、收集结果。关键点在于Provider 配置绑定了一个固定的providerName和toolName。模型看到的是稳定工具subagent_codex、subagent_claude_code而实际运行时由 host 选定。这层稳定接口 可变后端的抽象正是编排层该有的样子——模型不用关心codex 内部怎么跑只管调用 subagent_codex。四、委派怎么发生从一句话到一次调用在对话里委派通常是你或主 Agent 触发subagent或类似入口发起的。比如主 Agent 觉得这部分前端活儿交给 Claude Code 更合适它就调用subagent_claude_code把子任务文本传过去。调用流以 codex 为例父 Agent 调 subagent_codex → DSH 启动 Codex app-server → 创建一个临时 thread线程 → 启动一个 turn轮次 → 等待 turn/completed → 把最终答案返回给父 AgentClaude Code 那边略不同它走官方 Claude Agent SDK启动一个兼容的 CLI发一条 query返回结果。两者都是父 Agent 调一个工具 → 工具背后拉起一个独立 Agent → 拿回最终答案。RC.7 起这些子代理任务还接入了Job Panel你可以在界面里直接看它们的执行过程、状态、结果。这让多 Agent 协作从黑盒变成了看得见、管得着的面板操作。五、子代理是承包商拿任务、干完、交答案理解子代理的最佳比喻是承包商contractor它拿到一个自包含self-contained的任务——一段清楚的指令、一个工作目录。它在自己的上下文里干活不共享父 Agent 的对话流。它只返回完成后的答案不把中间过程全塞回父 Agent。以claude-codeprovider 为例它的inheritsParentContext: false——也就是说子 Agent 收到的是任务文本 工作目录不是父的对话历史、人设persona或工具过滤tool filter。它像个被叫来干一票的专家不参加你之前的闲聊干完交活走人。这种设计的好处是上下文隔离父 Agent 不会被子 Agent 的海量中间过程淹没子 Agent 也不会被父的无关历史带偏。代价是子 Agent 不知道来龙去脉——所以你派任务时要把必要背景写进任务文本本身别指望它应该知道之前聊过什么。六、one-shot vs continuable委派的两副面孔子代理委派分两类one-shot一次性派一个任务拿一个最终答案结束。当前rc.8主要就是这种。continable可续子 Agent 可以有持续会话、共享记忆。这是更进阶的形态rc.8 还在演进。one-shot 委派还支持几个可选参数但必须由 provider 显式声明支持否则会响亮地失败而不是静默降级outputSchema要求子 Agent 按指定结构返回。depthLimit限制委派深度防止子 Agent 又派子 Agent 套娃。toolFilter限制子 Agent 能用哪些工具。persona给子 Agent 指定人设。这条不支持就响亮失败的设计很关键——它避免你以为配置了 outputSchema 结果模型根本没遵守的暗坑。DSH 选择让你立刻知道这个 provider 不支持你要的特性而不是默默忽略。七、为什么这叫异构智能体运行时把视野拉高一点。传统多 Agent 框架子 Agent 通常和父 Agent 跑在同一套系统里比如都是 LangGraph 节点、都是某框架的 Agent 实例。DSH 不一样它的子 Agent 可以是完全另一家的产品。我们之前那个架构图可以这么画DeepSeek Harness │ Main Agent / Session ├────────────┼────────────┐ │ │ │ ▼ ▼ ▼ DSH Agent Claude Code Codex │ │ │ DSH Harness Claude Harness Codex Harness父和子不必共用一套 Harness。DSH 调 Claude Code 走的是 Claude Agent SDK调 Codex 走的是 Codex App Server。这就产生了一个常被纠正的误区多 Agent 通信 ≠ 必须用 A2AAgent-to-Agent协议。DSH 调 Claude Code 用的是 Claude 的 SDK调 Codex 用的是 Codex 的 App Server——没有强制套一个统一的多 Agent 协议。异构二字的价值在于你不用为了用上某家的强项就把整个系统迁到那家。主框架是 DSH需要 Claude Code 的强项就委派给它需要 Codex 的强项就委派给它——各取所长互不绑架。八、rc.8 的局限one-shot 还不是持久团队讲完亮点必须讲清当前的边界免得你以为多 Agent 团队已经成熟。rc.8 的委派仍是one-shot每次子 Agent 启动都会新建进程、临时线程、新 turn没有持久会话、没有共享内存、没有统一的超时/回滚。具体来说取消和进程清理是支持的但副作用side-effects不会自动回滚——子 Agent 改了文件就是改了不会因为任务取消而撤销。并发子 Agent 可能冲突多个子 Agent 同时改同一个文件时会互相踩。DSH 目前不自动做文件锁或合并。没有跨子 Agent 的长期记忆每个子 Agent 都是独立的、用完即走。所以现阶段把 DSH 当一群 Agent 长期协作的团队还为时过早。它更适合父 Agent 拆解任务、按需委派一次性子任务的形态。期待未来 rc 版本补齐持久会话、共享记忆、统一回滚——但今天要用得按 one-shot 的边界来设计任务。九、reportDelivery子 Agent 如何叫醒父任务RC.8 还加了一个机制叫reportDelivery子代理完成任务后可以实时反馈结果并自动唤醒父任务。这在长链任务里很有用。比如父 Agent 派了三个并行的子 Agent 去查三个数据库传统做法是父 Agent 傻等有了 reportDelivery每个子 Agent 一有结果就回传、并唤醒挂起的父任务父任务能边收边汇总不用干等最慢那个。这把多 Agent 协作从派出去、等回来升级成了派出去、边回边汇。对需要整合多源信息的长任务比如同时检索多个系统、并行跑多组测试能明显缩短整体周期。十、Job Panel把子 Agent 管起来我们 Web UI 那篇提过 Job Panel这里从多 Agent 视角再讲一次。从 RC.7 起子代理任务接入了 Job Panel你可以在界面里看每个子 Agent 的执行状态跑着、完成、失败。看它的进度和中间产出部分 provider 支持。必要时干预取消某个卡住的子任务。这让多 Agent 编排变成可观测、可干预的工程实践而不是赌运气。你能在面板里发现某个子 Agent 卡住了及时取消重派而不是整个任务卡死。对团队把多 Agent 当生产工具这一步至关重要。十一、in-process 两兄弟spawn vs fork回到进程内的两个 provider区别很微妙但重要spawn-in-process子 Agent看不到父的任何历史。它是张白纸只凭你给的任务文本干活。适合独立、无上下文依赖的子任务。fork-in-process子 Agent以父已完成的多轮为种子启动。它带着父的上下文适合需要理解来龙去脉的子任务。选型口诀任务自包含、怕上下文污染 → spawn任务需要背景、怕信息缺失 → fork。两者都在同一进程内省去跨进程通信开销适合高频、轻量的子任务拆分。但要记住进程内共享内存并发写同一文件同样会冲突别因为它们快就忽略隔离。十二、ACP Provider把任意外部 Agent 当子代理ACPprovider 值得单拎出来说因为它最开放任何遵循 Agent Client Protocol 的外部智能体都能当 DSH 的子 Agent。这意味着 DSH 的编排能力不局限于官方列的那几个 provider。只要某个 Agent 实现了 ACP不管是别的框架写的、还是你自研的就能被 DSH 委派。这把多 Agent 生态从官方支持列表扩展成了协议兼容即可。结合我们 Web UI/ACP 那篇讲的——ACP 是开放协议DSH 既可以是 ACP 服务端被别人调也可以是 ACP 客户端调别人。这种双向开放是它做编排层的底气。十三、非交互权限让子 Agent 在无人看管时也能跑子 Agent 跑起来有个现实问题它要执行操作谁来审批DSH 有专门的子代理非交互权限仓库提交里有2026-08-15-product-subagent-noninteractive-permissions的记录。简单说子 Agent 在委派场景下走的是非交互的权限策略——它的操作按预设策略自动裁决而不是弹窗问人也没人可问它是被父 Agent 自动派出的。RC.8 里 Codex 还加了非交互权限模式和多实例并行能力进一步强化任务拆分。这对父 Agent 自动派一打子 Agent 并行干活的场景很关键——如果每个子 Agent 都等着人点审批自动化就断了。所以非交互权限是多 Agent 自动化能成立的前提之一。十四、实战让主 Agent 把前端活儿派给 Claude Code给个具体场景把前面串起来。假设你用 DSH 主 Agent 在做全栈功能其中把组件改成 TS 强类型这个子任务你更信 Claude Code 在这块的手感。流程你装好subagent-claude-code这个 Profile BundleRC.8 的接法。主 Agent 判断前端 TS 化适合委派调用subagent_claude_code任务文本写清“在src/components下把所有组件改成 TypeScript 强类型保留现有行为跑通 tsc”。DSH 启动 Claude Agent SDK在当前工作区里跑这个子任务。子 Agent 改完、跑通 tsc把改了哪些文件、tsc 结果作为最终答案返回。父 Agent 拿到结果继续做它自己的后端部分。注意第 3 步的当前工作区——子 Agent 是在父的 workspace 里干活的所以它能直接改你的文件。这也意味着隔离靠的是上下文隔离看不到父历史不是文件系统隔离它照样能碰工作区文件。所以并发派多个子 Agent 改同一片文件照样会冲突。十五、实战用 Codex 做一次性评测子任务另一个场景你想用 Codex 的强项比如某种特定语言的修复做一次性任务。装subagent-codexProfile Bundle。主 Agent 调subagent_codex任务“修复test/parse.test.js里失败的用例只改测试逻辑不改源码”。DSH 启动codex app-server --stdio开一个临时 thread跑一个 turn。turn 完成结果回传父 Agent临时 thread 随之销毁。整个过程父 Agent 不持有 Codex 的会话状态——下次再调又是新 thread。这正印证了 rc.8 的 one-shot 边界没有持久会话、没有共享记忆。所以你每次派 Codex都要把任务写自包含别指望它记得上次。十六、并发子 Agent 的冲突雷区这是 one-shot 时代最该警惕的坑单列一节。当你并行派多个子 Agent且它们都工作在同一工作区且可能碰同一批文件时子 Agent A 改了utils.ts。子 Agent B同时跑也改了utils.ts。两者基于各自的快照改最后一个写回的覆盖前一个——前一个的改动丢了且没有任何报错提示。DSH 当前不自动做文件锁/合并。所以设计多 Agent 任务时务必做文件/目录级隔离让不同子 Agent 负责不同目录、不同文件从源头避免冲突。这是多 Agent 编排当前最实用的工程纪律比任何炫酷特性都重要。十七、副作用不回滚委派要幂等且可重跑另一个边界子 Agent 的副作用不会因任务取消而回滚。它改了文件、发了请求取消任务也不会撤销。这要求你把子任务设计成幂等、可重跑万一取消或失败重派一次不会造成更糟的结果。比如往数据库插一条记录这种副作用重派可能插两条——所以这类任务要么加去重要么别交给可能中途取消的子 Agent。把取消 ≠ 撤销刻进多 Agent 任务设计能省无数 debugging。十八、和多 Agent 框架的本质差异横向对比传统多 Agent 框架AutoGen、CrewAI 等的子 Agent 通常跑在同一套运行时里共享内存/消息总线。DSH 的独特点是异构——子 Agent 可以是另一家产品通过 SDK/协议被编排。这带来的最大不同是你不必为了用某家强项而整体迁移。主框架是 DSH需要谁就委派给谁。这在各家模型/Agent 各有所长的当下特别实用——没有一家通吃那就用编排把各家拼起来。DSH 在这里的定位更像Agent 界的编排层/调度层而不是又一个多 Agent 框架。十九、给团队的落地建议如果团队想用好多 Agent给几条务实建议任务要自包含派出去的子任务背景写全别依赖它应该知道。做文件级隔离不同子 Agent 负责不同目录避免并发写冲突。任务幂等可重跑副作用任务加去重应对取消不回滚。控制委派深度用depthLimit防套娃别让子 Agent 无限派子 Agent。非交互权限预设好子 Agent 跑时没人点审批提前声明它能做什么。用 Job Panel 盯执行别派出去就不管面板里看状态、及时干预。这些纪律是把多 Agent从炫技变成可生产的稳定协作的关键。二十、一句话总结子代理的本质如果只留一句DSH 的子代理机制是把另一个 Agent哪怕是别家产品抽象成可被统一编排的 Provider——你派任务、它干活、交答案上下文隔离、接口稳定而当前的边界one-shot、无持久记忆、副作用不回滚、并发会冲突也提醒你它现在是能干的承包商还不是能长期共事的团队成员。二十一、下一篇预告本篇把多 Agent 协作讲透了。最后一篇二次开发我们回到动手改框架怎么用 cordis.yml 做配置叠加、怎么用ctx.plugin/ctx.effect/ctx.on/ctx.waterfall写插件、怎么defineTool写工具、怎么自定义预设、怎么编译运行、怎么给官方贡献。那是把 DSH 真正变成你自己的框架的入口。二十二、上下文隔离的深度解析我们说过子 Agent 是承包商但隔离到什么程度值得讲细。以claude-code为例inheritsParentContext: false意味着子 Agent 拿到的是任务文本 工作目录而不是这三样父的对话历史、父的 persona、父的 tool filter。为什么这么设计两个理由防污染父 Agent 之前几千轮的历史对当前子任务可能是噪音。隔离让子 Agent 专注任务本身。防泄露/降成本不把父的整套上下文可能含敏感信息透传给别家产品的子 Agent既是安全考量也省 token。但代价是信息缺失——你派任务时必须把必要背景写进任务文本。一个常见错误是“帮我修这个 bug你应该记得我们之前讨论的架构”——子 Agent 不记得。正确写法是把相关上下文文件、约束、之前的结论直接写进任务。把子 Agent 当第一次接手这活的外包而不是读了我所有聊天记录的同事。二十三、persona 与 toolFilter 的实战用法one-shot 委派支持的persona和toolFilter是精细化控制子 Agent 的两把刀persona给子 Agent 指定人设/角色。比如你是个严谨的安全审计员只报告问题不修改代码。这让同一个 provider 能扮演不同角色适应不同子任务。toolFilter限制子 Agent 能用哪些工具。比如派去做只读分析的子 Agentfilter 掉写文件/执行命令的工具只留读和搜索。这既是安全最小权限也是防跑偏别让它顺手改了不该改的。但要注意这两个参数必须 provider 显式声明支持否则响亮失败。所以别假设我传了 persona 它就遵守——先确认目标 provider 支持再依赖它。这正是 DSH 不支持就明确报错哲学在多 Agent 里的体现。二十四、depthLimit防套娃的护栏多 Agent 编排最容易失控的一幕是套娃父 Agent 派子 Agent子 Agent 又派孙 Agent孙 Agent 再派……层级无限深你既看不住也付不起。depthLimit就是这道护栏限制委派深度。比如设depthLimit: 1子 Agent 就不能再派子 Agent 了。结合派出去的子任务要自包含depthLimit 把无限递归的 Agent 树压成可控深度的任务树。实操建议日常委派设一个 modest 的 depthLimit比如 1~2除非你明确需要多层拆解。让编排保持扁平可观测比深不见底的 Agent 递归稳得多。二十五、outputSchema让子 Agent 结果可被程序消费outputSchema让子 Agent 按指定结构返回结果而不是一段自由文本。这在父 Agent 要把子结果喂给下一步逻辑时极有价值比如派子 Agent “提取这个 PR 的改动文件列表”用 outputSchema 要求返回{files: string[], risk: low|mid|high}。父 Agent 拿到的是结构化数据能直接判断、路由不用再从自然语言里解析。同样outputSchema 需 provider 支持。当前 one-shot 时代不是所有子代理 provider 都支持结构化输出——确认后再用。一旦能用它把多 Agent 协作从自然语言接力升级成结构化数据管道是迈向可靠编排的关键一步。二十六、子代理与成本计费怎么算成本这块容易糊涂。核心事实每个子 Agent 都是独立的模型调用各自独立计费。父 Agent 调subagent_claude_code背后是 Claude 的模型账单调subagent_codex是 Codex 的账单in-process 的 DSH 子 Agent走的是你配置的 DSH 模型。所以多 Agent 编排的账单 父 Agent 的调用 每个子 Agent 的调用之和。委派越多、子 Agent 越多账单叠加越快。几个省钱纪律不是所有子任务都值得委派——轻量活父 Agent 自己干了别为显得高级而派。控制并发数量别一窝蜂派几十个子 Agent既烧钱也可能冲突。子任务自包含、目标明确减少派出去发现不对、重派的浪费。多 Agent 是能力放大器也是账单放大器。用得好效率翻倍用不好成本翻倍。二十七、子 Agent 的沙箱与权限子 Agent 在自己的运行时里也有自己的权限/沙箱体系。比如 Claude Code 子 Agent 跑在 Claude 的 harness 里遵循 Claude 的权限模型Codex 子 Agent 跑在 Codex 的 app-server 里遵循 Codex 的。这意味着子 Agent 的安全边界由它的宿主运行时决定不自动继承父的 DSH 沙箱。你给父 DSH 配了 workspace-write不代表子 Agent 也只在工作区里——Codex/Claude 有它们自己的 confinement 规则。这对安全很重要委派给别家子 Agent 时要去看那家的权限模型别假设父的沙箱罩住了子。跨产品委派安全边界要单独评估。结合我们安全篇讲的沙箱只管文件系统效果跨 Agent 的边界更得自己心里有数。二十八、调试多 Agent从日志看委派链多 Agent 出问题时怎么查答案是会话日志我们会话日志篇讲过这里用上。因为所有调用含子 Agent 委派都写进不可变日志你能看到完整的委派链父哪一轮调了subagent_codex、传了什么任务、子 Agent 跑了什么、回了什么。排查时子 Agent 结果不对展开那次委派看任务文本是不是自包含、背景够不够。子 Agent 没动静看是不是卡在它的非交互权限裁决、或它的宿主运行时报错。并发冲突日志里能看到两个子 Agent 几乎同时写了同一文件。日志是多 Agent 的黑匣子。这也是为什么我们反复强调会话日志是真相——在多 Agent 这种复杂度下没有日志你基本瞎调试。二十九、异构运行的延迟与可靠性把子 Agent 派到别家产品引入了新的工程变量延迟和可靠性取决于外部运行时。调 Claude Code 走 SDK多一跳网络/进程开销。调 Codex 走 app-server启线程、启 turn有冷启动成本。外部服务不稳限流、超时子 Agent 就失败。所以设计多 Agent 任务时要为子 Agent 失败做预案父 Agent 该有重试/降级逻辑子 Agent 挂了自己兜底或换 provider。别把关键路径 100% 押在外部子 Agent 必成功上。异构带来灵活也带来对外部依赖的脆弱性——这是编排者必须管理的。三十、何时该用子代理、何时不该给个决策指南避免为用而用该用子代理子任务自包含、目标清晰。某家子 Agent 在该领域明显更强用其所长。需要并行处理多份独立工作且文件隔离。想把不可信/易崩的活隔离在子 Agent 里崩了不影响父。不该用子代理任务太轻父自己干更快更省。任务强依赖父的全程上下文隔离反而丢信息。多个子任务会碰同一文件并发冲突。成本敏感付不起叠加的模型账单。一句话子代理是分工工具不是炫技标配。该分才分。三十一、自己写一个子代理 Provider进阶一点你能不能自己写一个子代理 Provider答案是能——因为 Provider 是插件“一切皆插件”。你实现一个符合约定的可委派执行体比如接你自研的某个 Agent、或某个内部系统注册成 subagent provider父 Agent 就能委派给它。具体实现涉及ctx的插件机制和 ACP 协议细节下一篇二次开发会展开。这里只点出可能性多 Agent 的边界不是官方列表定的是你用插件能力扩展的。今天官方给了 7 个明天你加第 8 个接你们内部系统完全可行。这正是开放架构的红利。三十二、和 A2A 协议的对比澄清再澄清一个误区很多人以为多 Agent 通信必须用 A2AAgent-to-Agent协议。DSH 的实例说明不一定。DSH 调 Claude Code用的是 Claude Agent SDK调 Codex用的是 Codex App Server。这些都不是某个统一的A2A 标准协议而是各家自己的集成方式。DSH 把这种异构成员统一抽象成 Provider对外暴露稳定的subagent_*工具。所以多 Agent的实现路径有两条要么大家都说同一种 A2A 语言标准化要么由一个编排层用各家的原生方式把大家串起来DSH 路线。DSH 选了后者——更务实因为它不要求所有成员先统一标准。理解这点你就不会纠结DSH 怎么不实现 A2A因为它用更灵活的 Provider 抽象绕过了这个前提。三十三、多 Agent 的失败模式汇总把多 Agent 常见的坑汇总成一张表方便排雷失败模式表现根因对策上下文缺失子 Agent 答非所问任务不自包含写全背景并发写冲突改动丢失无报错多子 Agent 碰同文件文件级隔离副作用不回滚取消后改动残留one-shot 边界任务幂等可重跑套娃失控账单/复杂度爆炸无 depthLimit设深度护栏外部依赖挂子 Agent 失败宿主运行时不稳父做重试/降级权限错配子 Agent 被拦非交互权限没配预设策略结果难消费父解析自然语言累没用 outputSchema要求结构化返回这张表基本覆盖了 90% 的多 Agent 实操坑。用前扫一遍能省大量调试。三十四、最后的提醒多 Agent 很诱人但请记住 rc.8 的诚实边界它是能干的承包商还不是能长期共事的团队。今天用它做父拆解、按需委派一次性子任务价值巨大想把它当一群 Agent 持久协作的有机体还为时过早。尊重这个边界你就能既享受异构编排的红利又不掉进以为成熟的坑。三十五、子代理与Agent 作为新运行时层把视野再拉高一层。业界开始有人论断Agent 正在成为软件架构里新的一层runtime layer——就像当年容器、函数计算成为新层一样。DSH 的子代理机制是这个论断的绝佳注脚。为什么因为 Codex、Claude Code 现在不再是你直接用的工具而是被封装成可调用 Agent成为上层编排的零件。调用关系从人调工具变成了Agent 调 Agent。组合粒度变细了模型调用 → 工具调用 → Agent 调用这最后一级Agent 调用正是 DSH 子代理所处的位置。这个论断的启示是未来架构师的活会越来越多地包括怎么调度、编排、管控一群 Agent。而 DSH 这类把 Agent 当可编排零件的框架正是为这个时代准备的基建。你现在学多 Agent 编排学的不是一个框架的用法而是下一代软件架构的调度思维。三十六、团队规模与多 Agent 的匹配多 Agent 不是团队越大越该用匹配关系有点反直觉个人/小团队先把单 Agent 用透偶尔用 in-process 子 Agent 做轻量拆分即可。别为了多 Agent而多 Agent。中型团队开始出现专长分工——前端活派 Claude Code、特定语言修复派 Codex、常规活父 Agent 自己干。这时多 Agent 开始有真实收益。大型/平台团队可能演进到编排层 多个专长 Agent 服务甚至自建子 Agent Provider 接内部系统。这时 DSH 的开放 Provider 抽象价值最大。所以多 Agent 是随组织复杂度自然长出来的能力不是一开始就要铺满的架构。别被炫酷误导按团队实际分工需求来。过早上多 Agent管理成本可能超过收益。三十七、本篇一句话收尾如果只留一句给离开本篇的你DSH 的子代理是把另一个 AI哪怕是别家产品“变成你随叫随到的承包商——它能干的活很惊艳但它现在的形态是一次性外援而非长期队友”尊重这个边界你才能既用出异构编排的巧又不掉进并发与成本的坑。三十八、给本篇的实战 checklist离开本篇前把多 Agent 的落地纪律压成一份 checklist照着用子任务自包含背景写全不依赖父历史。不同子 Agent 负责不同目录/文件避免并发写冲突。子任务幂等可重跑应对取消不回滚。设depthLimit防套娃保持编排扁平可观测。能用outputSchema就用让结果可程序消费。非交互权限预设好子 Agent 跑时没人点审批。看 Job Panel 盯执行卡住及时干预。为子 Agent 失败做预案父重试/降级别 100% 押外部。成本心里有数委派叠加的账单自己算过。跨产品委派单独评估子 Agent 的安全边界。这份清单比任何多 Agent 很牛的宣传都实在。逐条对齐多 Agent 才是生产力不是事故源。三十九、子代理的未来演进展望最后看向未来。从 rc.7 到 rc.8子代理的演进速度很快从能委派到打包成 Profile Bundle 安装到非交互权限 并行 reportDelivery。按这个节奏可以合理期待后续版本补齐当前边界持久会话/共享记忆子 Agent 之间、父子之间能共享长期上下文从承包商变队友。统一超时/回滚取消子 Agent 能回滚其副作用并发冲突有自动协调。更丰富的 Provider 生态官方和社区会贡献更多子代理 Provider覆盖更多专长 Agent。更深的编排原语除了委派可能出现会合join扇出扇入scatter-gather等编排模式。但这些是未来时。今天用 DSH 做多 Agent请基于 rc.8 的 one-shot 边界来设计——把期待放在将来会更强把方案落在现在能稳。这才是和生产级 Agent 打交道的正确姿态。四十、临别一句掏心话用多 Agent 最忌为了证明框架牛而硬上。我见过太多 demo 把派二十个子 Agent 并行跑得花团锦簇落到真实项目却因并发冲突、成本失控、调试无门而翻车。多 Agent 是放大器——放大你的工程纪律也放大你的混乱。先把单 Agent 的日志、权限、成本玩透再让外援入伙顺序别反。结语子 Agent 与 Agent Teams是 DSH 区别于单 Agent 玩具的关键跃迁。它用 Provider 抽象把另一个 Agent含别家产品“变成可统一编排的承包商用 Job Panel 把多 Agent 协作变得可观测用 reportDelivery 把派出去等回来升级成边回边汇”。它让我们提前触摸到一个正在成形的现实Agent 正成为软件架构里新的一层而会不会编排一群 Agent会越来越像会不会调度服务一样是工程师的基本功。下一篇我们钻进二次开发亲手把框架改成自己的。但 rc.8 的边界one-shot、无持久记忆、副作用不回滚、并发会冲突也诚实地告诉我们它现在是能干的承包商还不是能长期共事的团队——用对它的形态它极有价值误当成熟团队用会踩坑。如果这篇帮你理清了怎么让 Agent 叫外援点个关注。实战系列持续更新概念 / 教程 / 架构 / 插件 / 编码 / 框架对比 / 会话日志 / Headless / 自定义工具 / 模型适配 / Web 协同 / 安全沙箱 /多 Agent/ 二次开发。你用多 Agent 编排过什么好玩的任务评论区聊聊。把外援当承包商用稳当队友用等未来。本文基于 deepseek-ai/deepseek-harness 官方仓库packages/subagent、packages/experimental/agent-team 等、社区分析besthub、dev.to、CSDN、ITBear 等整理截至 2026-08。rc.8 仍为开发者预览子代理行为以你安装版本为准。 DeepSeek Harness 实战：子 Agent 与 Agent Teams——让“另一个 AI“成为你的承包商
DeepSeek Harness 实战子 Agent 与 Agent Teams——让另一个 AI成为你的承包商系列导航概念 / 教程 / 架构 / 插件 / 编码实战 / 框架对比 / 会话日志 / Headless·CI / 自定义工具 / 模型适配 / Web 协同 / 安全沙箱 /本文子 Agent 与 Agent Teams/ 二次开发前面我们讲的都是一个主 Agent在你工作区里单打独斗它读文件、跑命令、调工具。但真实复杂任务往往不是一个人能搞定的——你需要分工。DSH 最让我兴奋的能力藏在一个反直觉的设计里它把另一个 Agent 产品比如 Claude Code、Codex也抽象成了 Provider。也就是说你的主 Agent 可以把一个子任务委派给跑在 Claude Code 上的子 Agent而 Claude Code 在 DSH 眼里只是一个 providersubagent-claude-code。这打开了一扇门异构智能体运行时Heterogeneous Agent Runtime——父 Agent 和子 Agent 不一定共用一套 Harness它们可以是完全不同的产品通过各自的 SDK/协议被统一编排。这一篇我们就把子代理和多 Agent 团队讲透有哪些 provider、委派怎么发生、one-shot 委派有哪些坑、并发子 Agent 会踩什么雷、以及这到底意味着什么。一、先破除一个误解不是只有 DeepSeek 有 Sub-Agent很多人看到DSH 支持子 Agent下意识以为哦它自己也能派小弟。没错但远远不止。真正有意思的是DSH 把 Sub-Agent 本身也抽象成了Provider提供方。目前官方仓库里已经存在的子代理 Provider 包括spawn-in-process进程内派生fork-in-process进程内分叉带父上下文ACP任意 Agent Client Protocol 智能体dsh-sdk另一个 DSH 实例codexOpenAI Codexclaude-codeAnthropic Claude Code也就是说一个 DSH 主 Agent 可以把任务委派给另一个 DeepSeek Agent同门真正的 Claude Code真正的 Codex其中claude-code会调用官方 Claude Agent SDKcodex会启动codex app-server --stdio创建一个临时 Codex 线程执行任务。父 Agent 和子 Agent 不一定共用一套 Harness——这就是所谓的异构智能体运行时。二、子代理 Provider 全家福更具体地说rc.7 的包清单里一共 ship 了 7 个子代理 Provider社区基于仓库实测确认。上面列的 6 个加上 ACP 类里细分出的full peer harness over stdio JSON-RPC基本覆盖了你能想到的所有形态spawn-in-process在父进程内派生一个子 Agent但看不到父的任何历史。fork-in-process同样进程内但以父已完成的多轮为种子启动带着上下文。ACP任何遵循 Agent Client Protocol 的外部智能体都能当子 Agent。dsh-sdk一个完整的对等 DSH 实例通过 stdio JSON-RPC 通信。codex通过codex app-server --stdio调起每次跑一个临时线程。claude-code通过官方 Claude Agent SDK 调起。其余归在 ACP/对等 harness 类里本质都是外部可委派的执行体。这串列表说明一件事DSH 把谁来当手做成了可插拔的插槽。你今天用 in-process 省事明天接 Codex 用它的强项后天接 Claude Code 用它的生态——上层编排逻辑几乎不变。三、RC.8 的关键变化子代理变成 Profile Bundle2026-08 的 RC.8 大更新把子代理的接入方式升级了Claude Code 和 Codex 被正式打包成Profile Bundle预设包按需安装后就能作为子代理灵活调用。安装后父 Agent 看到的不再是底层细节而是两个稳定的工具名subagent_codexsubagent_claude_code调用流程分两阶段父 Agent 决策判断要不要委派、委派给哪个工具。DSH 运行时接手注册适配器、启动进程、管理后台 job、处理取消、收集结果。关键点在于Provider 配置绑定了一个固定的providerName和toolName。模型看到的是稳定工具subagent_codex、subagent_claude_code而实际运行时由 host 选定。这层稳定接口 可变后端的抽象正是编排层该有的样子——模型不用关心codex 内部怎么跑只管调用 subagent_codex。四、委派怎么发生从一句话到一次调用在对话里委派通常是你或主 Agent 触发subagent或类似入口发起的。比如主 Agent 觉得这部分前端活儿交给 Claude Code 更合适它就调用subagent_claude_code把子任务文本传过去。调用流以 codex 为例父 Agent 调 subagent_codex → DSH 启动 Codex app-server → 创建一个临时 thread线程 → 启动一个 turn轮次 → 等待 turn/completed → 把最终答案返回给父 AgentClaude Code 那边略不同它走官方 Claude Agent SDK启动一个兼容的 CLI发一条 query返回结果。两者都是父 Agent 调一个工具 → 工具背后拉起一个独立 Agent → 拿回最终答案。RC.7 起这些子代理任务还接入了Job Panel你可以在界面里直接看它们的执行过程、状态、结果。这让多 Agent 协作从黑盒变成了看得见、管得着的面板操作。五、子代理是承包商拿任务、干完、交答案理解子代理的最佳比喻是承包商contractor它拿到一个自包含self-contained的任务——一段清楚的指令、一个工作目录。它在自己的上下文里干活不共享父 Agent 的对话流。它只返回完成后的答案不把中间过程全塞回父 Agent。以claude-codeprovider 为例它的inheritsParentContext: false——也就是说子 Agent 收到的是任务文本 工作目录不是父的对话历史、人设persona或工具过滤tool filter。它像个被叫来干一票的专家不参加你之前的闲聊干完交活走人。这种设计的好处是上下文隔离父 Agent 不会被子 Agent 的海量中间过程淹没子 Agent 也不会被父的无关历史带偏。代价是子 Agent 不知道来龙去脉——所以你派任务时要把必要背景写进任务文本本身别指望它应该知道之前聊过什么。六、one-shot vs continuable委派的两副面孔子代理委派分两类one-shot一次性派一个任务拿一个最终答案结束。当前rc.8主要就是这种。continable可续子 Agent 可以有持续会话、共享记忆。这是更进阶的形态rc.8 还在演进。one-shot 委派还支持几个可选参数但必须由 provider 显式声明支持否则会响亮地失败而不是静默降级outputSchema要求子 Agent 按指定结构返回。depthLimit限制委派深度防止子 Agent 又派子 Agent 套娃。toolFilter限制子 Agent 能用哪些工具。persona给子 Agent 指定人设。这条不支持就响亮失败的设计很关键——它避免你以为配置了 outputSchema 结果模型根本没遵守的暗坑。DSH 选择让你立刻知道这个 provider 不支持你要的特性而不是默默忽略。七、为什么这叫异构智能体运行时把视野拉高一点。传统多 Agent 框架子 Agent 通常和父 Agent 跑在同一套系统里比如都是 LangGraph 节点、都是某框架的 Agent 实例。DSH 不一样它的子 Agent 可以是完全另一家的产品。我们之前那个架构图可以这么画DeepSeek Harness │ Main Agent / Session ├────────────┼────────────┐ │ │ │ ▼ ▼ ▼ DSH Agent Claude Code Codex │ │ │ DSH Harness Claude Harness Codex Harness父和子不必共用一套 Harness。DSH 调 Claude Code 走的是 Claude Agent SDK调 Codex 走的是 Codex App Server。这就产生了一个常被纠正的误区多 Agent 通信 ≠ 必须用 A2AAgent-to-Agent协议。DSH 调 Claude Code 用的是 Claude 的 SDK调 Codex 用的是 Codex 的 App Server——没有强制套一个统一的多 Agent 协议。异构二字的价值在于你不用为了用上某家的强项就把整个系统迁到那家。主框架是 DSH需要 Claude Code 的强项就委派给它需要 Codex 的强项就委派给它——各取所长互不绑架。八、rc.8 的局限one-shot 还不是持久团队讲完亮点必须讲清当前的边界免得你以为多 Agent 团队已经成熟。rc.8 的委派仍是one-shot每次子 Agent 启动都会新建进程、临时线程、新 turn没有持久会话、没有共享内存、没有统一的超时/回滚。具体来说取消和进程清理是支持的但副作用side-effects不会自动回滚——子 Agent 改了文件就是改了不会因为任务取消而撤销。并发子 Agent 可能冲突多个子 Agent 同时改同一个文件时会互相踩。DSH 目前不自动做文件锁或合并。没有跨子 Agent 的长期记忆每个子 Agent 都是独立的、用完即走。所以现阶段把 DSH 当一群 Agent 长期协作的团队还为时过早。它更适合父 Agent 拆解任务、按需委派一次性子任务的形态。期待未来 rc 版本补齐持久会话、共享记忆、统一回滚——但今天要用得按 one-shot 的边界来设计任务。九、reportDelivery子 Agent 如何叫醒父任务RC.8 还加了一个机制叫reportDelivery子代理完成任务后可以实时反馈结果并自动唤醒父任务。这在长链任务里很有用。比如父 Agent 派了三个并行的子 Agent 去查三个数据库传统做法是父 Agent 傻等有了 reportDelivery每个子 Agent 一有结果就回传、并唤醒挂起的父任务父任务能边收边汇总不用干等最慢那个。这把多 Agent 协作从派出去、等回来升级成了派出去、边回边汇。对需要整合多源信息的长任务比如同时检索多个系统、并行跑多组测试能明显缩短整体周期。十、Job Panel把子 Agent 管起来我们 Web UI 那篇提过 Job Panel这里从多 Agent 视角再讲一次。从 RC.7 起子代理任务接入了 Job Panel你可以在界面里看每个子 Agent 的执行状态跑着、完成、失败。看它的进度和中间产出部分 provider 支持。必要时干预取消某个卡住的子任务。这让多 Agent 编排变成可观测、可干预的工程实践而不是赌运气。你能在面板里发现某个子 Agent 卡住了及时取消重派而不是整个任务卡死。对团队把多 Agent 当生产工具这一步至关重要。十一、in-process 两兄弟spawn vs fork回到进程内的两个 provider区别很微妙但重要spawn-in-process子 Agent看不到父的任何历史。它是张白纸只凭你给的任务文本干活。适合独立、无上下文依赖的子任务。fork-in-process子 Agent以父已完成的多轮为种子启动。它带着父的上下文适合需要理解来龙去脉的子任务。选型口诀任务自包含、怕上下文污染 → spawn任务需要背景、怕信息缺失 → fork。两者都在同一进程内省去跨进程通信开销适合高频、轻量的子任务拆分。但要记住进程内共享内存并发写同一文件同样会冲突别因为它们快就忽略隔离。十二、ACP Provider把任意外部 Agent 当子代理ACPprovider 值得单拎出来说因为它最开放任何遵循 Agent Client Protocol 的外部智能体都能当 DSH 的子 Agent。这意味着 DSH 的编排能力不局限于官方列的那几个 provider。只要某个 Agent 实现了 ACP不管是别的框架写的、还是你自研的就能被 DSH 委派。这把多 Agent 生态从官方支持列表扩展成了协议兼容即可。结合我们 Web UI/ACP 那篇讲的——ACP 是开放协议DSH 既可以是 ACP 服务端被别人调也可以是 ACP 客户端调别人。这种双向开放是它做编排层的底气。十三、非交互权限让子 Agent 在无人看管时也能跑子 Agent 跑起来有个现实问题它要执行操作谁来审批DSH 有专门的子代理非交互权限仓库提交里有2026-08-15-product-subagent-noninteractive-permissions的记录。简单说子 Agent 在委派场景下走的是非交互的权限策略——它的操作按预设策略自动裁决而不是弹窗问人也没人可问它是被父 Agent 自动派出的。RC.8 里 Codex 还加了非交互权限模式和多实例并行能力进一步强化任务拆分。这对父 Agent 自动派一打子 Agent 并行干活的场景很关键——如果每个子 Agent 都等着人点审批自动化就断了。所以非交互权限是多 Agent 自动化能成立的前提之一。十四、实战让主 Agent 把前端活儿派给 Claude Code给个具体场景把前面串起来。假设你用 DSH 主 Agent 在做全栈功能其中把组件改成 TS 强类型这个子任务你更信 Claude Code 在这块的手感。流程你装好subagent-claude-code这个 Profile BundleRC.8 的接法。主 Agent 判断前端 TS 化适合委派调用subagent_claude_code任务文本写清“在src/components下把所有组件改成 TypeScript 强类型保留现有行为跑通 tsc”。DSH 启动 Claude Agent SDK在当前工作区里跑这个子任务。子 Agent 改完、跑通 tsc把改了哪些文件、tsc 结果作为最终答案返回。父 Agent 拿到结果继续做它自己的后端部分。注意第 3 步的当前工作区——子 Agent 是在父的 workspace 里干活的所以它能直接改你的文件。这也意味着隔离靠的是上下文隔离看不到父历史不是文件系统隔离它照样能碰工作区文件。所以并发派多个子 Agent 改同一片文件照样会冲突。十五、实战用 Codex 做一次性评测子任务另一个场景你想用 Codex 的强项比如某种特定语言的修复做一次性任务。装subagent-codexProfile Bundle。主 Agent 调subagent_codex任务“修复test/parse.test.js里失败的用例只改测试逻辑不改源码”。DSH 启动codex app-server --stdio开一个临时 thread跑一个 turn。turn 完成结果回传父 Agent临时 thread 随之销毁。整个过程父 Agent 不持有 Codex 的会话状态——下次再调又是新 thread。这正印证了 rc.8 的 one-shot 边界没有持久会话、没有共享记忆。所以你每次派 Codex都要把任务写自包含别指望它记得上次。十六、并发子 Agent 的冲突雷区这是 one-shot 时代最该警惕的坑单列一节。当你并行派多个子 Agent且它们都工作在同一工作区且可能碰同一批文件时子 Agent A 改了utils.ts。子 Agent B同时跑也改了utils.ts。两者基于各自的快照改最后一个写回的覆盖前一个——前一个的改动丢了且没有任何报错提示。DSH 当前不自动做文件锁/合并。所以设计多 Agent 任务时务必做文件/目录级隔离让不同子 Agent 负责不同目录、不同文件从源头避免冲突。这是多 Agent 编排当前最实用的工程纪律比任何炫酷特性都重要。十七、副作用不回滚委派要幂等且可重跑另一个边界子 Agent 的副作用不会因任务取消而回滚。它改了文件、发了请求取消任务也不会撤销。这要求你把子任务设计成幂等、可重跑万一取消或失败重派一次不会造成更糟的结果。比如往数据库插一条记录这种副作用重派可能插两条——所以这类任务要么加去重要么别交给可能中途取消的子 Agent。把取消 ≠ 撤销刻进多 Agent 任务设计能省无数 debugging。十八、和多 Agent 框架的本质差异横向对比传统多 Agent 框架AutoGen、CrewAI 等的子 Agent 通常跑在同一套运行时里共享内存/消息总线。DSH 的独特点是异构——子 Agent 可以是另一家产品通过 SDK/协议被编排。这带来的最大不同是你不必为了用某家强项而整体迁移。主框架是 DSH需要谁就委派给谁。这在各家模型/Agent 各有所长的当下特别实用——没有一家通吃那就用编排把各家拼起来。DSH 在这里的定位更像Agent 界的编排层/调度层而不是又一个多 Agent 框架。十九、给团队的落地建议如果团队想用好多 Agent给几条务实建议任务要自包含派出去的子任务背景写全别依赖它应该知道。做文件级隔离不同子 Agent 负责不同目录避免并发写冲突。任务幂等可重跑副作用任务加去重应对取消不回滚。控制委派深度用depthLimit防套娃别让子 Agent 无限派子 Agent。非交互权限预设好子 Agent 跑时没人点审批提前声明它能做什么。用 Job Panel 盯执行别派出去就不管面板里看状态、及时干预。这些纪律是把多 Agent从炫技变成可生产的稳定协作的关键。二十、一句话总结子代理的本质如果只留一句DSH 的子代理机制是把另一个 Agent哪怕是别家产品抽象成可被统一编排的 Provider——你派任务、它干活、交答案上下文隔离、接口稳定而当前的边界one-shot、无持久记忆、副作用不回滚、并发会冲突也提醒你它现在是能干的承包商还不是能长期共事的团队成员。二十一、下一篇预告本篇把多 Agent 协作讲透了。最后一篇二次开发我们回到动手改框架怎么用 cordis.yml 做配置叠加、怎么用ctx.plugin/ctx.effect/ctx.on/ctx.waterfall写插件、怎么defineTool写工具、怎么自定义预设、怎么编译运行、怎么给官方贡献。那是把 DSH 真正变成你自己的框架的入口。二十二、上下文隔离的深度解析我们说过子 Agent 是承包商但隔离到什么程度值得讲细。以claude-code为例inheritsParentContext: false意味着子 Agent 拿到的是任务文本 工作目录而不是这三样父的对话历史、父的 persona、父的 tool filter。为什么这么设计两个理由防污染父 Agent 之前几千轮的历史对当前子任务可能是噪音。隔离让子 Agent 专注任务本身。防泄露/降成本不把父的整套上下文可能含敏感信息透传给别家产品的子 Agent既是安全考量也省 token。但代价是信息缺失——你派任务时必须把必要背景写进任务文本。一个常见错误是“帮我修这个 bug你应该记得我们之前讨论的架构”——子 Agent 不记得。正确写法是把相关上下文文件、约束、之前的结论直接写进任务。把子 Agent 当第一次接手这活的外包而不是读了我所有聊天记录的同事。二十三、persona 与 toolFilter 的实战用法one-shot 委派支持的persona和toolFilter是精细化控制子 Agent 的两把刀persona给子 Agent 指定人设/角色。比如你是个严谨的安全审计员只报告问题不修改代码。这让同一个 provider 能扮演不同角色适应不同子任务。toolFilter限制子 Agent 能用哪些工具。比如派去做只读分析的子 Agentfilter 掉写文件/执行命令的工具只留读和搜索。这既是安全最小权限也是防跑偏别让它顺手改了不该改的。但要注意这两个参数必须 provider 显式声明支持否则响亮失败。所以别假设我传了 persona 它就遵守——先确认目标 provider 支持再依赖它。这正是 DSH 不支持就明确报错哲学在多 Agent 里的体现。二十四、depthLimit防套娃的护栏多 Agent 编排最容易失控的一幕是套娃父 Agent 派子 Agent子 Agent 又派孙 Agent孙 Agent 再派……层级无限深你既看不住也付不起。depthLimit就是这道护栏限制委派深度。比如设depthLimit: 1子 Agent 就不能再派子 Agent 了。结合派出去的子任务要自包含depthLimit 把无限递归的 Agent 树压成可控深度的任务树。实操建议日常委派设一个 modest 的 depthLimit比如 1~2除非你明确需要多层拆解。让编排保持扁平可观测比深不见底的 Agent 递归稳得多。二十五、outputSchema让子 Agent 结果可被程序消费outputSchema让子 Agent 按指定结构返回结果而不是一段自由文本。这在父 Agent 要把子结果喂给下一步逻辑时极有价值比如派子 Agent “提取这个 PR 的改动文件列表”用 outputSchema 要求返回{files: string[], risk: low|mid|high}。父 Agent 拿到的是结构化数据能直接判断、路由不用再从自然语言里解析。同样outputSchema 需 provider 支持。当前 one-shot 时代不是所有子代理 provider 都支持结构化输出——确认后再用。一旦能用它把多 Agent 协作从自然语言接力升级成结构化数据管道是迈向可靠编排的关键一步。二十六、子代理与成本计费怎么算成本这块容易糊涂。核心事实每个子 Agent 都是独立的模型调用各自独立计费。父 Agent 调subagent_claude_code背后是 Claude 的模型账单调subagent_codex是 Codex 的账单in-process 的 DSH 子 Agent走的是你配置的 DSH 模型。所以多 Agent 编排的账单 父 Agent 的调用 每个子 Agent 的调用之和。委派越多、子 Agent 越多账单叠加越快。几个省钱纪律不是所有子任务都值得委派——轻量活父 Agent 自己干了别为显得高级而派。控制并发数量别一窝蜂派几十个子 Agent既烧钱也可能冲突。子任务自包含、目标明确减少派出去发现不对、重派的浪费。多 Agent 是能力放大器也是账单放大器。用得好效率翻倍用不好成本翻倍。二十七、子 Agent 的沙箱与权限子 Agent 在自己的运行时里也有自己的权限/沙箱体系。比如 Claude Code 子 Agent 跑在 Claude 的 harness 里遵循 Claude 的权限模型Codex 子 Agent 跑在 Codex 的 app-server 里遵循 Codex 的。这意味着子 Agent 的安全边界由它的宿主运行时决定不自动继承父的 DSH 沙箱。你给父 DSH 配了 workspace-write不代表子 Agent 也只在工作区里——Codex/Claude 有它们自己的 confinement 规则。这对安全很重要委派给别家子 Agent 时要去看那家的权限模型别假设父的沙箱罩住了子。跨产品委派安全边界要单独评估。结合我们安全篇讲的沙箱只管文件系统效果跨 Agent 的边界更得自己心里有数。二十八、调试多 Agent从日志看委派链多 Agent 出问题时怎么查答案是会话日志我们会话日志篇讲过这里用上。因为所有调用含子 Agent 委派都写进不可变日志你能看到完整的委派链父哪一轮调了subagent_codex、传了什么任务、子 Agent 跑了什么、回了什么。排查时子 Agent 结果不对展开那次委派看任务文本是不是自包含、背景够不够。子 Agent 没动静看是不是卡在它的非交互权限裁决、或它的宿主运行时报错。并发冲突日志里能看到两个子 Agent 几乎同时写了同一文件。日志是多 Agent 的黑匣子。这也是为什么我们反复强调会话日志是真相——在多 Agent 这种复杂度下没有日志你基本瞎调试。二十九、异构运行的延迟与可靠性把子 Agent 派到别家产品引入了新的工程变量延迟和可靠性取决于外部运行时。调 Claude Code 走 SDK多一跳网络/进程开销。调 Codex 走 app-server启线程、启 turn有冷启动成本。外部服务不稳限流、超时子 Agent 就失败。所以设计多 Agent 任务时要为子 Agent 失败做预案父 Agent 该有重试/降级逻辑子 Agent 挂了自己兜底或换 provider。别把关键路径 100% 押在外部子 Agent 必成功上。异构带来灵活也带来对外部依赖的脆弱性——这是编排者必须管理的。三十、何时该用子代理、何时不该给个决策指南避免为用而用该用子代理子任务自包含、目标清晰。某家子 Agent 在该领域明显更强用其所长。需要并行处理多份独立工作且文件隔离。想把不可信/易崩的活隔离在子 Agent 里崩了不影响父。不该用子代理任务太轻父自己干更快更省。任务强依赖父的全程上下文隔离反而丢信息。多个子任务会碰同一文件并发冲突。成本敏感付不起叠加的模型账单。一句话子代理是分工工具不是炫技标配。该分才分。三十一、自己写一个子代理 Provider进阶一点你能不能自己写一个子代理 Provider答案是能——因为 Provider 是插件“一切皆插件”。你实现一个符合约定的可委派执行体比如接你自研的某个 Agent、或某个内部系统注册成 subagent provider父 Agent 就能委派给它。具体实现涉及ctx的插件机制和 ACP 协议细节下一篇二次开发会展开。这里只点出可能性多 Agent 的边界不是官方列表定的是你用插件能力扩展的。今天官方给了 7 个明天你加第 8 个接你们内部系统完全可行。这正是开放架构的红利。三十二、和 A2A 协议的对比澄清再澄清一个误区很多人以为多 Agent 通信必须用 A2AAgent-to-Agent协议。DSH 的实例说明不一定。DSH 调 Claude Code用的是 Claude Agent SDK调 Codex用的是 Codex App Server。这些都不是某个统一的A2A 标准协议而是各家自己的集成方式。DSH 把这种异构成员统一抽象成 Provider对外暴露稳定的subagent_*工具。所以多 Agent的实现路径有两条要么大家都说同一种 A2A 语言标准化要么由一个编排层用各家的原生方式把大家串起来DSH 路线。DSH 选了后者——更务实因为它不要求所有成员先统一标准。理解这点你就不会纠结DSH 怎么不实现 A2A因为它用更灵活的 Provider 抽象绕过了这个前提。三十三、多 Agent 的失败模式汇总把多 Agent 常见的坑汇总成一张表方便排雷失败模式表现根因对策上下文缺失子 Agent 答非所问任务不自包含写全背景并发写冲突改动丢失无报错多子 Agent 碰同文件文件级隔离副作用不回滚取消后改动残留one-shot 边界任务幂等可重跑套娃失控账单/复杂度爆炸无 depthLimit设深度护栏外部依赖挂子 Agent 失败宿主运行时不稳父做重试/降级权限错配子 Agent 被拦非交互权限没配预设策略结果难消费父解析自然语言累没用 outputSchema要求结构化返回这张表基本覆盖了 90% 的多 Agent 实操坑。用前扫一遍能省大量调试。三十四、最后的提醒多 Agent 很诱人但请记住 rc.8 的诚实边界它是能干的承包商还不是能长期共事的团队。今天用它做父拆解、按需委派一次性子任务价值巨大想把它当一群 Agent 持久协作的有机体还为时过早。尊重这个边界你就能既享受异构编排的红利又不掉进以为成熟的坑。三十五、子代理与Agent 作为新运行时层把视野再拉高一层。业界开始有人论断Agent 正在成为软件架构里新的一层runtime layer——就像当年容器、函数计算成为新层一样。DSH 的子代理机制是这个论断的绝佳注脚。为什么因为 Codex、Claude Code 现在不再是你直接用的工具而是被封装成可调用 Agent成为上层编排的零件。调用关系从人调工具变成了Agent 调 Agent。组合粒度变细了模型调用 → 工具调用 → Agent 调用这最后一级Agent 调用正是 DSH 子代理所处的位置。这个论断的启示是未来架构师的活会越来越多地包括怎么调度、编排、管控一群 Agent。而 DSH 这类把 Agent 当可编排零件的框架正是为这个时代准备的基建。你现在学多 Agent 编排学的不是一个框架的用法而是下一代软件架构的调度思维。三十六、团队规模与多 Agent 的匹配多 Agent 不是团队越大越该用匹配关系有点反直觉个人/小团队先把单 Agent 用透偶尔用 in-process 子 Agent 做轻量拆分即可。别为了多 Agent而多 Agent。中型团队开始出现专长分工——前端活派 Claude Code、特定语言修复派 Codex、常规活父 Agent 自己干。这时多 Agent 开始有真实收益。大型/平台团队可能演进到编排层 多个专长 Agent 服务甚至自建子 Agent Provider 接内部系统。这时 DSH 的开放 Provider 抽象价值最大。所以多 Agent 是随组织复杂度自然长出来的能力不是一开始就要铺满的架构。别被炫酷误导按团队实际分工需求来。过早上多 Agent管理成本可能超过收益。三十七、本篇一句话收尾如果只留一句给离开本篇的你DSH 的子代理是把另一个 AI哪怕是别家产品“变成你随叫随到的承包商——它能干的活很惊艳但它现在的形态是一次性外援而非长期队友”尊重这个边界你才能既用出异构编排的巧又不掉进并发与成本的坑。三十八、给本篇的实战 checklist离开本篇前把多 Agent 的落地纪律压成一份 checklist照着用子任务自包含背景写全不依赖父历史。不同子 Agent 负责不同目录/文件避免并发写冲突。子任务幂等可重跑应对取消不回滚。设depthLimit防套娃保持编排扁平可观测。能用outputSchema就用让结果可程序消费。非交互权限预设好子 Agent 跑时没人点审批。看 Job Panel 盯执行卡住及时干预。为子 Agent 失败做预案父重试/降级别 100% 押外部。成本心里有数委派叠加的账单自己算过。跨产品委派单独评估子 Agent 的安全边界。这份清单比任何多 Agent 很牛的宣传都实在。逐条对齐多 Agent 才是生产力不是事故源。三十九、子代理的未来演进展望最后看向未来。从 rc.7 到 rc.8子代理的演进速度很快从能委派到打包成 Profile Bundle 安装到非交互权限 并行 reportDelivery。按这个节奏可以合理期待后续版本补齐当前边界持久会话/共享记忆子 Agent 之间、父子之间能共享长期上下文从承包商变队友。统一超时/回滚取消子 Agent 能回滚其副作用并发冲突有自动协调。更丰富的 Provider 生态官方和社区会贡献更多子代理 Provider覆盖更多专长 Agent。更深的编排原语除了委派可能出现会合join扇出扇入scatter-gather等编排模式。但这些是未来时。今天用 DSH 做多 Agent请基于 rc.8 的 one-shot 边界来设计——把期待放在将来会更强把方案落在现在能稳。这才是和生产级 Agent 打交道的正确姿态。四十、临别一句掏心话用多 Agent 最忌为了证明框架牛而硬上。我见过太多 demo 把派二十个子 Agent 并行跑得花团锦簇落到真实项目却因并发冲突、成本失控、调试无门而翻车。多 Agent 是放大器——放大你的工程纪律也放大你的混乱。先把单 Agent 的日志、权限、成本玩透再让外援入伙顺序别反。结语子 Agent 与 Agent Teams是 DSH 区别于单 Agent 玩具的关键跃迁。它用 Provider 抽象把另一个 Agent含别家产品“变成可统一编排的承包商用 Job Panel 把多 Agent 协作变得可观测用 reportDelivery 把派出去等回来升级成边回边汇”。它让我们提前触摸到一个正在成形的现实Agent 正成为软件架构里新的一层而会不会编排一群 Agent会越来越像会不会调度服务一样是工程师的基本功。下一篇我们钻进二次开发亲手把框架改成自己的。但 rc.8 的边界one-shot、无持久记忆、副作用不回滚、并发会冲突也诚实地告诉我们它现在是能干的承包商还不是能长期共事的团队——用对它的形态它极有价值误当成熟团队用会踩坑。如果这篇帮你理清了怎么让 Agent 叫外援点个关注。实战系列持续更新概念 / 教程 / 架构 / 插件 / 编码 / 框架对比 / 会话日志 / Headless / 自定义工具 / 模型适配 / Web 协同 / 安全沙箱 /多 Agent/ 二次开发。你用多 Agent 编排过什么好玩的任务评论区聊聊。把外援当承包商用稳当队友用等未来。本文基于 deepseek-ai/deepseek-harness 官方仓库packages/subagent、packages/experimental/agent-team 等、社区分析besthub、dev.to、CSDN、ITBear 等整理截至 2026-08。rc.8 仍为开发者预览子代理行为以你安装版本为准。