第 7 课：目标、计划与协作：单兵到军团

一句话版：一个人干不完的大任务，就让一支「智能体军团」来干——**目标（goal）**持久记录「为什么干」，**计划（plan）**落成可对账的协作状态，**后台任务（tasks）与待办（todo）**跟踪进度，**子智能体（subagent）领走各自的子任务，再用工作流（workflow）**脚本把大家编排成有序的流水线：从单兵作战，到军团协同。

---

1. 用户故事：一个大任务，怎么拆给一支军团

想象你是 DSH 的使用者，交给它一个大任务：「把公司的代码库从旧框架迁移到新框架」。这个任务太大，一个智能体一口气做完会乱——它需要先拆解、再分工、边做边对账。整个过程可以分成六步：

1. 立目标（goal）：先明确「完成迁移」这个总目标，让它持久保存下来——即使会话中断、重启，智能体也知道自己要往哪去。
2. 做计划（plan）：在 Plan Mode 里把大任务拆成阶段：调研现状 → 设计迁移方案 → 批量改写 → 审查回归。每一步都写进协作状态，人和智能体随时能对账「现在进行到哪一步」。
3. 列待办（todo）：把每个阶段再拆成一条条可勾选的清单，比如「列出所有用到旧 API 的文件」「为每个文件生成迁移改动」。
4. 派后台任务（tasks）：把耗时的活（比如全库扫描、批量编译）丢到后台跑，主智能体不用干等，随时可以观察进度、取消任务，或等它发来完成通知。
5. 委派子智能体（subagent）：把「调研现状」交给调研员、「批量改写」交给程序员、「审查结果」交给审查员——每个子智能体领走一个子任务，各干各的。
6. 用工作流（workflow）编排：写一个脚本把上面这些子智能体串成流水线：先调研、再编码、后审查，各阶段还能并行推进，结果统一汇总回编排器。

下图就是这场「军团作战」的鸟瞰：编排器（主智能体或 workflow）向下委派，目标、计划、任务、待办像一条横贯始终的轨道，子智能体各司其职，最后结果汇总回来。

下面我们逐个认识这六个能力家族——它们都来自 DSH 源码里真实的包（package），每一个都有明确的职责和挂载点。

---

2. 目标与计划：让「要做什么」有据可查、能续跑

2.1 goal：持久化的同会话目标

源码仓库 packages/goal/README.zh.md 对它的定义只有一段话，却非常关键：

agent 会话的持久目标状态，独立于消费它的面向模型工具与续行策略。goal 状态是所属会话日志的一部分；消费方依赖 dsh-goal，绝不依赖具体的 agent loop（智能体循环）。

拆开看有三个要点：

• 持久化：goal 是「会话的持久目标状态」，不是模型脑子里临时记住的一句话。它属于会话日志的一部分——还记得第一章的「运行可重建」吗？日志即真相，目标作为日志的一部分，同样可以恢复、可以回放。
• 独立于消费方：goal 状态和「怎么用它」是分开的。消费它的可以是面向模型的工具（tool-goal，让模型读取和更新目标）、面向用户的命令（command-goal，让你在命令行或界面里查看目标），以及续行策略（goal-round-driver，负责「同会话目标续行」）。
• 不依赖具体循环：消费方只依赖 dsh-goal 这个能力接口，绝不绑定某一种具体的智能体循环实现——这正是第二章讲过的「接缝」：能力定义、提供方、消费者三者分离，任何一端都能单独替换。

goal 家族由四个包组成：

goal 和「续跑」的关系：为什么目标要持久化？因为智能体跑长任务时，会话可能会中断、被恢复、被 fork。只要「要达成什么」作为日志的一部分持久存在，那么无论从哪个检查点重建会话，智能体都知道自己为什么在这里、下一步该往哪走——这就是「续跑」的根基。

2.2 plan：落日志的协作状态

packages/plan/README.zh.md 同样一句话点破本质：

Plan mode 是按 agent（智能体）记录的协作状态，而不是通用模式注册表或能力 seam。

• 按 agent 记录：plan 状态挂在某个智能体身上，记录「这个智能体当前在计划什么、计划到哪一步」——它跟着智能体走，而不是一个全局的模式开关。
• 不是通用模式注册表：它不是用来切换全局模式的注册表，也不是一个可替换的能力接缝，它就是一份协作状态：编排器（或用户）和智能体之间靠它对齐「接下来要做什么、边界在哪里」。
• 落日志：plan 的每一步（包括步骤边界）都会刷写进会话日志，所以计划的演化同样有据可查，可以被审查、被恢复、被 fork。

一句话记住分工：goal 回答「为什么干」，plan 回答「怎么干、干到哪」。

---

3. 后台任务与待办：进度从哪里来

3.1 jobs：长时间运行工具的后台协议

packages/jobs/README.zh.md 这样描述这个家族：

本家族为长时间运行的工具提供一套按所有者隔离的后台任务协议，用于观察、取消、等待和完成通知。

• 长时间运行的工具：全库扫描、批量编译、远程请求……这些耗时的工具调用不能堵住智能体的主循环，于是被放进后台。
• 按所有者隔离：每个任务都属于创建它的那个智能体，别的智能体不能随便干预——这是「各自负责」的纪律保证。
• 四项能力：观察（看进度与快照）、取消（不想要了就停掉）、等待（阻塞到任务结束再继续）、完成通知（干完了主动告诉你）。

家族构成：jobs/ 定义任务注册表和生命周期约定（ctx.jobs），jobs-local/ 提供进程本地的注册表实现，tool-jobs/ 把任务控制和完成通知公开给模型（注册到 ctx.tools）。

值得注意的是，tool-jobs 是一个与任务种类无关（kind-agnostic）的后台作业控制器：后台 bash 命令、终端 terminal_send、后台子智能体，全都通过同一组 job_output / job_list / job_kill 三个工具来读取、列举和终止。生产方各自扩展 JobKindMap 声明自己的 id 命名空间，模型侧看到的却始终是同一套接口（来源：docs/tool-catalog.zh.md）。

3.2 todo：会话自己的待办清单

packages/todo/README.zh.md 是这样定位它的：

面向模型的 todo 能力。它是单一产品包，因为一个 agent（智能体）会话拥有该列表；不存在可替换的提供方约定。

• 一个会话拥有一份列表：todo 不是全局共享的，它就是当前这个智能体会话的清单。
• 面向模型：模型可以读取、新增、勾选、清理这些条目。
• 与 plan 的分工：plan 是「路线图」（怎么走），todo 是「清单」（当前做到哪、还剩什么）。你可以一边看着 plan 知道整体节奏，一边勾选 todo 确认每一步都完成了。

---

4. 委派：从「一个人干」到「一支军团」

4.1 三种委派姿势：spawn、fork、外部提供方

packages/subagent/README.zh.md 开宗明义：

本家族允许一个 agent（智能体）将工作委派给子 agent。多个具名提供方可在同一上下文中共存。

这个家族里的关键包如下：

三种姿势的记忆法：

• spawn：全新实例。子 agent 从零开始，不知道父会话发生了什么，你给它一份自包含的提示词它就开始干。适合完全独立的子任务（比如「调研某个目录里有哪些文件」）。
• fork：继承前缀。子 agent 从父 agent 已完成的历史记录启动，天然带着上下文。适合需要「接着聊」的延续性任务（比如「基于我上面的分析，继续写实现」）。
• 外部委派：进程外的智能体。通过 ACP 协议、Codex、Claude Code 或 DSH SDK 启动「真·别人家的智能体」，把活外包出去，结果再传回来。

4.2 委派之后：通信与控制

委派不是「撒手不管」，配套还有一整套控制工具：

• tool-subagent/：向模型公开委派操作（发起委派）；
• tool-subagent-control/：向模型公开子级消息发送和列举操作（给子级派新活、查看当前有哪些子级）；
• tool-subagent-report/：提供从子级到父级的报告通道（子级干完活怎么把结果交回来）。

另外子 agent 支持后台运行：你可以让一个子 agent 在后台慢慢干，期间继续做自己的事，之后再通过消息通道给它追加工作——这就是源码文档里说的「可续跑的后台子 agent」。

---

5. workflow：脚本驱动的多 agent 编排

5.1 由模型编写的编排工作流

packages/workflow/README.zh.md 一句话概括：

本家族通过 subagent 运行由模型编写的编排工作流，并将通用工具与固定策略工具公开给模型。

拆开看有三个关键词：

• 由模型编写：编排脚本不是人写死的流程，而是模型（或你）写下的一段编排逻辑——告诉系统「先做什么、再做什么、哪些可以并行」。
• 通过 subagent 运行：脚本里的「干活的人」都是子智能体。脚本可以定义阶段（比如「调研」「编码」「审查」），同一阶段里多个子智能体并行推进，互不阻塞，这正是「军团」的形态。
• 通用工具与固定策略工具：脚本既可以使用通用编排能力（如启动一个 agent、把一批任务走完流水线、把多个并行任务的结果汇齐），也可以使用固定策略的工具——例如 tool-ralph/：每次都用全新 agent 跑固定流程的 Ralph 工作流，适合「每轮都不带旧记忆、只靠共享工作区」的迭代式任务。

技术细节：工作流脚本运行在独立的 worker thread 里，与宿主事件循环隔离；但仓库文档明确强调，这不构成安全边界——它只是运行方式上的隔离，安全边界仍由沙箱与审批负责（见第 4 课）。

家族构成：workflow/ 定义工作流执行和生命周期事件（ctx.workflowEngine），workflow-worker-thread/ 在线程中运行脚本，tool-workflow/ 向模型公开通用工作流执行，tool-ralph/ 公开固定的 Ralph 工作流。

5.2 subagent 与 workflow 的分工

• subagent = 单个「人手」：领一个子任务，干完交差。适合一对一的委派。
• workflow = 整个「项目管理脚本」：负责把很多人手排成流水线、决定先后与并行。适合一对多、多阶段的编排。
• 实践中两者常常叠加使用：workflow 脚本里启动子智能体的调用，底层走的就是 subagent 的提供方——workflow 是总指挥，subagent 是士兵。

---

6. 与前两章的关系：把两条线接起来

• 第一章（DSH 初识）：智能体框架的基本思想 一课讲过「多智能体编排」——一个任务拆给多个智能体，一个负责调研、一个负责写代码、一个负责审查，框架负责编排它们。本课就是把这个思想落实成 DSH 里真实的六个能力家族：goal、plan、tasks、todo、subagent、workflow。第一章是「愿景」，这一课是「零件清单」。
• 第二章（论文研读）：Cordis 论文的核心是「组件」与时空可组合性——系统的一切都是可组合、可替换的组件。本课的每个能力家族恰恰就是组件：它们注册在 ctx 上下文的各个键上，遵循「能力定义 / 提供方 / 消费者」的接缝结构。最典型的例子就是 subagent：多个具名提供方（spawn、fork、ACP、Codex、Claude Code、dsh-sdk）在同一个 ctx.subagents 键下共存，想换一种委派方式就换一个提供方——这正是「换插座」式的可替换性。

---

关键点回顾

这一课信息量不小，记住这五句话就够了：

1. 目标 goal：持久化的同会话目标，是会话日志的一部分——有它才有「续跑」，且消费方不依赖具体 agent loop。
2. 计划 plan：按 agent 记录的协作状态，不是全局模式开关；每一步落日志，可对账、可恢复。
3. 后台任务 tasks + 待办 todo：tasks 为长时间运行的工具提供按所有者隔离的协议（观察、取消、等待、完成通知）；todo 是会话自己拥有的可勾选清单。
4. 委派 subagent：spawn 全新实例、fork 继承父会话历史、外部提供方（ACP、Codex、Claude Code、dsh-sdk）把活外包给进程外智能体；委派后还有控制工具与报告通道。
5. 工作流 workflow：模型编写的编排脚本，通过 subagent 分阶段并行运行，另配固定策略工具（Ralph）——它们全部是注册在 ctx 上的可替换组件。

🚀 下一课（第 7 课）我们讲「自我演化：智能体改造自己」。你会发现，正是本课的「接缝式组件 + 可替换提供方」让智能体能在运行中检查、挂载和卸载自己的能力——从指挥一支军团，到改造自己的装备。