第 14 章 · 子智能体、编排与隔离

本篇目标：把复杂任务拆给多个 Agent，且不让它们互相踩。 社区 单 Agent 的 Harness 是配置，十个 Agent 的 Harness 是编排平台。

14.1 DSH 的派活工具箱

原文 内置 4 个派活工具 + 3 个后台管理工具：

原文 引用程序员鱼皮的选择建议，可直接当口诀：

独立任务用 subagent 就够了；需要子 Agent 了解前文用 subagent_fork；多个任务并行交给 workflow；同一目标想让不同 Agent 反复迭代审视用 ralph。

ralph 的典型场景：代码审查、安全审计、方案评估——这些任务的价值恰恰来自「换一双眼睛」，共享上下文反而会继承同样的盲点。

官方 架构层对应 subsystems/subagent、subsystems/workflow、subsystems/agent-team；原文提到 list_agents 等后台三件套，实际以本机 --dump-config 与 tool catalog 为准。

14.2 实战：每日竞品简报

原文 架构：

定时任务（每天 09:00 触发）
  → 恢复原 Session，注入一条 follow-up 消息
  → 主 Agent 派活给子 Agent（并行）
       ├─ A：抓竞品 A 官网 + changelog，最近 7 天，每条一句话摘要 + 原文链接
       ├─ B：抓竞品 B 官方博客 + GitHub Releases
       └─ C：web_search 行业新闻，过滤无关项
  → 主 Agent 汇总 → briefs/YYYY-MM-DD.md（日期/竞品/更新摘要/影响判断 四列）

派活提示词的关键约束 原文：

用 subagent 并行派三个子任务，每个子任务用 subagent（独立上下文，不要 fork）：
...
每个子任务完成后，把结果直接返回，不要互相引用，也不要等对方。

为什么不用 fork？ 三个抓取任务彼此独立，父会话里关于「昨天做了什么」的历史对它们全是噪音，还会挤占各自的上下文预算。独立上下文是一种资源隔离，不只是信息隔离。

什么时候用 fork？ 需要子 Agent 理解「前文已经决定了什么」——例如基于刚确认的方案去写测试、去审查刚生成的 diff。

定时指令 原文：

每天早上 9 点（Asia/Shanghai），执行竞品简报流程：
派三个子 Agent 分别抓取竞品 A、B 的更新动态和行业新闻，
汇总后写入 briefs/YYYY-MM-DD.md，格式为「日期 / 竞品 / 更新摘要 / 影响判断」四列。
写入后用 ask_user_question 问我是否需要补充跟进。

配套核对动作 原文：去侧栏「自动化任务」页面确认频率是「每日」而非「仅一次」、确认时区是显式 IANA 而不是浏览器上报值。

⚠️ 第 06 章已强调：投递不保证恰好一次，且子 Agent 看不见定时任务（schedule_* 已被 deny）。生产用法必须让主 Agent 先做幂等检查。

14.3 内置定时任务 vs dsh-automation 插件

原文 对照表：

原文判断：内置定时任务 + 子 Agent 已覆盖 80% 场景。想要真正的「后台独立 Agent」（全新根 Agent + Session）才上插件。

原文 明确「不支持」的操作：暂停任务（无开关，不需要就删、需要就重建）、每次运行新建 Session、跨会话转交工作流、自动调度仅存在于旧日志的提醒。

14.4 Agent Teams：长期协作

原文 安装命令：

dsh plugin --profile web add @nanmicoder/dsh-agent-teams@latest

用法示例：

创建 3 个成员 Agent，分别负责三个方向：
- 前端 Agent：页面结构、交互逻辑、响应式、明显前端问题
- 代码质量 Agent：项目结构、依赖管理、可维护性
- 安全 Agent：敏感信息泄露、依赖风险、明显安全隐患

Captain 队长负责汇总；团队做完一次任务后不会马上消失，可继续复用。

原文 限制：一个 Captain 同时只能带一个活跃团队；团队状态默认存在当前工作区、不会自动同步到其他电脑；多个 DSH 进程同时操作同一团队可能状态冲突。另提到 WebGL 降级问题与 frontend 成员相关。

官方 架构文档补充：Agent Teams 为 root Session 启用时增加 task policy 与 shared task board；普通 subagent 控制负责 identity、messaging、discovery、interruption、inbox waiting。

14.5 通用编排：六种拓扑与状态契约

脱离 DSH，多 Agent 编排常见的六种拓扑（与 FDE-Wiki 专题二的框架对齐）：

状态契约是编排里最容易被跳过、也最致命的一块。每两个 Agent 之间必须写清：

判据 18：并行 Agent 共享同一份可变文件状态，是多 Agent 系统的头号失败模式。解法是 git worktree / 独立工作区——每个 Agent 一棵独立工作树与分支，零共享可变状态。社区 Claude Code 的 WorktreeCreate / WorktreeRemove hooks 正是为此设计。

14.6 本章产出与验收

核心产出：一条三路并行的实际流水线（含状态契约表、幂等检查、失败语义），以及一份 worktree 隔离验证记录。

验收点：

• 能说出 subagent 与 subagent_fork 的取舍依据，而不只是背定义
• 能解释 ralph 为什么适合代码审查
• 能为一对 Agent 写出完整状态契约（六个字段齐全）
• 能说明「投递不保证恰好一次」在业务层的补偿写法
• 能用自己的话讲清 worktree 解决了什么共享状态问题

延伸阅读