多智能体协作

这是 Codeg 的招牌功能。在一段对话内部，你正在使用的智能体——主导智能体——可以把一个自成一体的子任务交给另一个智能体，并把结果融入自己的回答中。Claude Code 可以调用 Codex 来编写测试、请 Grok 更新文档，或启动第二个智能体来审查它自己的工作——每个子智能体都作为自己的实时会话并行运行，而你自始至终无需离开对话。

何必费这个劲？有两个理由。各有所长——每个智能体擅长的事情各不相同，而委派让一项任务能借助多个智能体之力。并行——相互独立的工作片段同时运行，而不是一个接一个；主导智能体把它们扇出，再收集结果。

提出请求最快的方式：输入 @ 并选一个智能体。 这个提及会被理解为一条明确的委派指令，因此它是现有最可靠的触发方式——参见用 @ 提及来委派。

委派的工作原理

当委派开启时，每个有能力的智能体都会获得一项额外的能力：它可以让另一个智能体来执行子任务。流程始终是一样的：

1. 主导智能体进行委派。 它选定一个目标智能体，写下一份完整的任务描述，然后把它交出去。它可以一次性发出多个交接。
2. 一个子智能体运行。 Codeg 会启动该智能体的一个全新会话——它自己的对话，在你的工作文件夹中——并把任务交给它。
3. 主导智能体收集结果。 当子智能体完成后，主导智能体读回它的回答并继续进行：总结、合并，或再次委派。

有两个特性决定了你使用它的方方面面。

子智能体是冷启动的。 它看不到你的对话、你打开的文件，或主导智能体所知道的任何东西——只能看到交给它的任务文本。因此，主导智能体必须把子智能体所需的一切都打包进那份任务里。（关于如何为此撰写，详见下文。）

交接不会阻塞。 委派会立刻返回一个任务句柄，而不是把主导智能体挂起直到工作智能体完成，因此主导智能体可以接连发出多次交接、完成属于自己的那份工作，然后才去收集结果。正是这一点让真正的并行成为可能，而不是一个只是看起来并发的队列——它也是下文多数协作模式背后的机制。

谁能主导，谁能干活。 委派能力以一个额外工具的形式到达智能体，通过 Codeg 内置的 MCP 服务器经由 ACP 交付——因此，只有当一个智能体通过该协议接受 MCP 工具时，它才能主导。有十三个可以，并能发起委派：Claude Code、Codex、Gemini、OpenCode、Cline、Hermes、CodeBuddy、Kimi Code、Grok、Cursor、DeepSeek Harness、Qoder 和 Google Antigravity。OpenClaw 和 Pi 不行——OpenClaw 干脆拒绝 MCP 服务器，而 Pi 则悄悄忽略它们——因此委派工具永远到不了它们那里，它们无法主导。全部十五个仍然可以被委派，这让 OpenClaw 和 Pi 成为完全合格的工作智能体。无论你正在与哪个有能力的智能体对话，它就是主导智能体；无需另外设置什么"编排器"。

有一种情况会让一个本来有能力的智能体失去这项能力：按智能体的让智能体自己处理文件和命令开关会刻意收走委托工具，因为委派会把同一份工作又绕回 Codeg、绕出该智能体自己的沙箱。启用委托下方的面板会点名这条规则当前对哪些智能体成立，因此一次没发生的交接有明确的原因，而不是读起来像悄无声息地失败了。

自定义智能体同样参与其中。 你自己注册的任何 ACP 智能体都和内置智能体一样是有效目标——可以用 @ 提及、可以作为工作智能体启动，并在子智能体配置下拥有自己的标签页。至于它能否主导，遵循与其他所有智能体相同的规则：它需要通过该协议接受 MCP 工具。

开启它

委派默认是关闭的，因此第一步是启用它：

1. 打开设置 → 通用，找到多智能体协同卡片。
2. 打开启用委托，然后按保存。（关闭时，委派工具根本不会提供给任何智能体。）

界面用词与本文用词

应用的中文界面把这项功能叫作"多智能体协同"，开关叫作"启用委托"；本文沿用整套文档统一的"委派"一词。两者指的是同一件事——凡是需要你点击的地方，本文都会给出界面上的原词。

它在智能体下一次启动时生效

委派工具是在 Codeg 启动某个智能体时交给它的，而这套工具在该智能体保持连接的整段时间内是固定的。因此一个当前正处于连接状态的对话不会中途获得这项能力。

但这并不要求是一个空白的新对话。任何对话都会在它的智能体下一次启动时获得委派能力——包括一个你已经用了好几周的对话，只要它的连接已经结束、而你重新回到它（比如你重启了 Codeg，或状态显示为已断开）。只有仍然活着的连接才会继续沿用旧的工具集；如果你不想去判断，新建一个对话总是带着它的。

（关闭委派则是立即生效的：无论是否处于连接状态，从那一刻起交接都会被拒绝。）一个 @ 提及在文字上得到了回应、却始终没有子智能体出现，通常就是这个原因。

在组建团队之前，有两个相邻的设置值得了解：

• 最大委托深度——委派可以嵌套多少层。默认是 1：主导智能体可以委派，但子智能体不能再进一步委派。只有当你希望子智能体去组建它们自己的团队时，才提高它（最高到 8）——参见子团队。
• 子智能体配置——每当 Codeg 把某个智能体作为工作智能体启动时所应用的按智能体覆盖项，从而让被委派的会话按你希望的方式配置好再开始。每个智能体各有一个标签页（包括你注册的自定义智能体），其中包含一行模式，以及该智能体所声明的各项选项（例如 Codex 的批准策略和沙箱模式）。这些选项来自对智能体的一次实时探测，因此你选的正是它会接受的。把某一行留在 默认（…） 意味着沿用该智能体自己的默认值；显式选中同一个值则会把它固定下来，即使该智能体日后更改了自己的默认值。

完整的控制界面——包括已完成结果缓存——记录在设置 → 通用。

工作智能体必须准备就绪

子智能体是一个真实智能体的真实会话，因此目标智能体必须已启用、已安装且已登录——就像你自己会启动的那种一样。委派给一个尚未就绪的智能体，那次交接会返回 启动失败；主导智能体会撇下它继续进行。使用智能体和认证与模型介绍了如何让每一个都准备就绪。

用 @ 提及来委派

你随时都可以用普通的文字请求委派，但用 @ 提及点名智能体才是稳妥的做法。这个提及会被识别为一条把该工作委派给该智能体的明确指令——因此一个有能力的主导智能体会把它当作你已经做出的决定，而不是一个它可以斟酌是否照办的建议。

如何插入一个提及。 在 composer 中输入 @。会打开一个选择面板，包含四个分组——文件、智能体、会话、提交——输入内容会跨所有分组过滤。输入智能体名称的几个字母（或它的内部标识，因此 claude_code 能找到 Claude Code），然后从智能体分组中选中它。它会作为一个徽标落入你的消息中。

主导智能体收到的是什么。 该徽标以可读文本的形式传递——@Codex——并附带该智能体的内部标识，正是它告诉主导智能体究竟该指向哪一个智能体，而不必从显示名称去猜。由于可读的名称留在句子里，这个提及同时也是一句普通的话：

@Codex 为 src/auth/login.ts 里的登录流程写集成测试。

有几点值得了解：

• 每个智能体一次提及，各得一个子智能体。 在一条消息中点名多个智能体，每一个都会获得自己的交接、携带属于自己的那部分工作——这正是扇出的基础。
• 紧挨着提及说清工作是什么。 提及决定的是谁，而不是做什么。单写一个 @Grok 只是给了主导智能体一个目标，却没有可发送的内容。把任务和名字写在同一口气里。
• 只有已启用的智能体可被提及——也才够得着。 你在设置 → 智能体中关掉的智能体绝不会出现在选择面板里，而且从 0.22 起，它也会从主导智能体拿到的目标列表中划掉，因此主导智能体自己也无法主动选中它。（已启用但未安装或未登录的智能体仍然可以被点名——但会以 启动失败 返回。）
• 提及是一条强指令，而不是一条硬路由。 Codeg 把提及摆在主导智能体面前，并告诉它一个提及意味着什么；真正调用工具的仍然是主导智能体。实践中，一个有能力的主导智能体会稳定地遵从它，但这并非机械保证——如果一个提及被忽略，通常的原因是该会话中委派并未生效（参见上文的警告）。
• 提及你正在与之对话的那个智能体，是请它启动第二个独立的自身会话，而不只是把活干了——偶尔在需要隔离时有用，通常并非你想要的。

同一个 @ 选择面板也用来引用文件、过往会话和提交——参见 composer——而会话提及本身还有一种协作用途，见接续另一个会话未完成的工作。

观看团队工作

委派全程可见——绝不是一个黑箱：

• 在主导智能体的回复中，每次交接都会显示为一张委派中卡片——目标智能体、任务，以及一个实时状态——取代原始的工具调用。这张卡片是一个状态与导航入口：它不会内联打印工作智能体的输出，而是把你指向持有输出的那个会话。
• 一个子智能体面板会收集最新回复中的工作智能体。折叠时，它是一个小小的 子智能体 3 标签；展开时，每一行都会显示智能体、它的任务，以及一个从运行中变为完成（或失败，并附上诸如 启动失败 或 深度超限 的原因）的状态徽标。
• 用查看会话打开任意子智能体，即可实时观看它完整的对话流——与你自己启动它时会看到的对话记录相同。它是一个查看器，不是第二个 composer：你跟随观看，而不驾驶它的回合。从 0.28 起它以侧边抽屉打开，而不再是居中的对话框，主导智能体的对话仍在它背后活着——于是你是在主导智能体继续工作的同时读这个工作智能体，而这正是打开它的全部理由。它还可以层叠：一份子智能体的记录里本身就带着它自己的委派卡片，打开其中一张会嵌套进来，而不是把你正在读的那份埋掉。它也不会再因为开启它的那张卡片滚出视野或你切换标签页而关闭。→ 面板从你工作的旁边滑入
• 智能体自己的子智能体也会展示它们的工作。 当 Claude Code 启动它内部的子智能体时（那是它自己的功能，不是 Codeg 的委派——参见下方的说明），过去只显示运行中…的胶囊现在会带上一段实时活动，流式呈现那个子智能体究竟在做什么。它只在运行期间存在：胶囊一旦落定，就会回到完成后的摘要及其统计信息。
• Grok 的子智能体同样如此。 Grok 不会把 spawn_subagent 子任务做的任何事通过协议转发出来，所以那些子任务过去是名副其实的黑箱——阻塞式的派生在结束之前完全没有任何输出。现在每个子任务都有自己的 Agent 卡片，运行期间持续跳动（工具调用、轮次、上下文占用），把子任务的报告按它本来的 Markdown 渲染，而不是当成终端输出；卡片上还带一个查看子智能体会话，可以只读打开子任务自己的记录，运行中和事后都行——它和其他查看器一样，装在同一个可层叠的抽屉里。这些子会话也不会再作为游离条目出现在会话列表里。实时回合与重新打开的历史，两边待遇一致。
• Codex 的团队同样如此。 Codex 自带一套团队式的子智能体，而一次原生的派生不会产生任何 Codeg 能显示的工具调用——因此在重新打开会话之前，Codex 的子智能体是看不见的。现在每一次派生都是一张以子任务命名的 Agent 胶囊，带着它的线程 id 角标，实时与重开时都在。胶囊会在自己身上写明：它代表的是那次派生——Codex 不再上报后续进展，而一个异步的子任务在胶囊落定之后仍会继续工作。在历史记录里，这些派生过去会读成半千字节的 base64——Codex 的交接内容是一个只有 Codex 能解开的密封信封，所以它会被丢弃而不是打印出来，这张卡片如此，其他任何携带同类信封的 Codex 工具卡片也如此。
• 运行中的工具调用看起来就是运行中。 仍在工作的委托子智能体不会再挂着一个已完成的绿色对勾；而在回合进行到一半才打开的查看器，也能接上已经发起的那次委派，而不是把它漏掉。
• 你依然握有那些至关重要的控制权。 子智能体以你对该智能体的常规权限级别运行，因此当它想运行命令或写入文件时，它的权限提示会出现在它自己的视图内，供你允许或拒绝。多选题也会落在那里。当一个工作智能体正等着你时，它的徽标会显示待批准——这是提示你打开它的信号，因为在你回答之前一切都不会推进。

被卡住的工作智能体会主动来找你

那个徽标过去是被卡住的子智能体唯一露面的地方——于是一次无人值守的运行可能整个下午都停在那里，而任何地方都没有一句提示。现在，一个正等待权限的子任务会抵达桌面宠物的徽标、它的面板和它的「等待」姿势，面板上的权限卡片可以直接作答；那一行会写明它的父会话并把你跳转过去，因为子任务本身无法作为标签页打开。一个智能体做了委派的待办任务会显示等待输入而不是运行中；而一个正在轮询 get_delegation_status 的智能体会被告知子任务正卡在用户身上，而不是把整段停滞干等完。→ 问题 #447

• 当主导智能体查看它的团队时，你会在对话记录中看到一张紧凑的状态卡片，每个任务一行。对同一任务的重复查看会折叠进那一张卡片，而不会层层堆叠。

子智能体的对话不会把你的侧边栏搞乱，但它们也不会丢失：一个启动过工作智能体的对话会长出一个箭头，用展开子会话即可看到嵌套在下方的子对话——如果某个工作智能体自己也组建了团队，还会递归展开。数小时之后、在子智能体面板早已翻到更新的回复之时，这就是你找回某个工作智能体对话记录的方式。

想让整个团队呈现在一个屏幕上？将会话并排平铺——主导智能体在一个窗格里，它的子智能体在其他窗格里——一次性观看每一份对话记录。

写好一份委派提示词

由于子智能体是冷启动的，委派会青睐具体、自成一体的请求。 你其实是在同时写两样东西：你整体上想要什么，以及足够多的细节，好让主导智能体能向一个陌生人做交代。

好习惯：

• 用 @ 点名智能体。 把某部分工作固定给某个特定智能体的最清晰方式——参见上文。不写的话，主导智能体会自己选一个目标。
• 说明哪些是独立的。 如果任务的各部分互不依赖，就告诉主导智能体——"并行"、"同时"——它便能把它们扇出，而不是按顺序运行。
• 指向真实的东西。 点明文件、路径和确切的结果。主导智能体会把这些原封不动地传给一个看不到你屏幕的子智能体。
• 说清你要拿回什么。 "返回你发现的 bug 列表，附上文件和行号"能给主导智能体一些真正可以融入回答的东西；而"审查一下这个"招来的是一大段散文。

一个开启三方拆分的提示词可能会这样写：

你自己把 src/auth.ts 重构成使用新的 token helper。
同时，@Codex 为登录流程写集成测试，
@Grok 更新 README 里的认证章节。
三件事都完成后，总结一下改了什么。

主导智能体亲自完成重构，把测试委派给 Codex、把文档委派给 Grok，作为两个并行的子智能体，等待两者完成，然后给你一份统一的总结——与此同时，你在子智能体面板中观看三者。

协作模式

委派没有需要配置的编排器，因此一次协作的形态完全由你如何组织请求来决定。少数几种形态几乎涵盖了所有值得做的事：

模式	何时采用	代价
扇出	工作可拆成互不相干的若干片	N 个会话同时运行
接力	每个阶段都需要上一阶段的输出	没有并行；最慢的形态
第二意见	正确性比速度更重要	每次审查多一个会话
评审团	一处改动有风险，且可能以多种方式出错	每个视角一个会话
专才	任务中的某一片更适合另一个智能体	一个会话
切分大范围	横跨众多文件夹或模块的大范围改动	N 个会话，另需处理写入冲突
子团队	任务可以被分解两层	增长很快——先提高深度上限
会话交接	你需要的上下文在一段更早的对话里	一个会话

扇出：相互独立的片段一次性运行

主力形态。把互不重叠的工作拆开，让每一片同时运行——正是这种形态让整个功能值回票价，因为交接不会阻塞主导智能体。

@Codex 为 src/auth/login.ts 写集成测试。
@Grok 更新 docs/auth.md，与新的 token 流程保持一致。
@OpenCode 补上 src/auth/types.ts 里缺失的类型标注。
每一项都用一句话汇报结果。

也给主导智能体分一份活，它就会在工作智能体忙碌的同时一起产出。唯一的要求是真正的独立性：会碰到同一批文件的片段，应当放进接力或一个 worktree。

接力：把结果沿着链条往下传

当第二阶段需要第一阶段的产出时——设计，然后实现，再测试——按顺序提出各个阶段，主导智能体就会在开始下一个之前等待上一个。

先让 @Grok 读一遍 src/api/，写一份迁移到 v2 客户端的简短方案。
方案回来后，把它原文交给 @Codex 去实现，
再让 @Claude Code 审查 diff。

难点在于冷启动：链条上的每个工作智能体都是陌生人，所以主导智能体必须把上一步的结果带进下一份任务里，而不能只是指一指。值得把这一点明说出来——"把那份计划原文放进你交给 Codex 的任务中"——因为第二阶段从未收到第一阶段输出的接力，正是这种形态最常见的失望来源。这里没有任何东西是并行的，因此只在依赖关系真实存在时才用它。

第二意见：一个来建，另一个来审

让主导智能体完成工作，然后把对它的审查委派给一个不同的智能体。冷启动正是关键：审查者从未见过产出这处改动的推理过程，因此它无法被说服，而是从代码而非叙述中重新推导出问题。

修掉 src/queue/worker.ts 里的竞态。
跑通之后，@Codex 审查这份 diff——把目标、我改动过的文件，
以及要重点看什么都告诉它：丢失唤醒、重复处理、错误路径。
然后处理值得处理的问题，并告诉我改了什么。

这就是下文的教程，也是最值得封装成技能的模式。

评审团：多位审查者，各自不同的视角

对于一处可能以多种方式出错的改动，单个审查者就是单点故障。把同一份 diff 发给多个智能体，并给每一个不同的视角——在这里视角胜过冗余，因为三份雷同的审查大多只是彼此附和。

认证重构我做完了。把 diff 并行发给三位审查者，各自侧重不同：
@Codex——正确性与边界情况。
@Grok——安全性：token 处理、时序、有什么会泄漏到日志里。
@OpenCode——这套公开 API 对调用方来说读起来还合理吗？
然后汇总：有哪些问题是不止一位提到的？

一定要明确要求汇总。不然你拿到的是三份需要自己读的审查报告——而那正是你原本想委派出去的大部分工作。

专才：留住主导智能体，借用一项长处

继续与你喜欢的智能体保持对话，只把更适合别人的那一片委派出去——它擅长的某门语言、一次棘手的重构、一遍文档梳理。主导智能体保有上下文与思路；专才拿到的是一份范围狭窄、界定清楚的活。

这个重构你继续推进，但 src-tauri/src/bridge.rs 里的 Rust FFI 那层
比较绕——@Codex 只负责那一个文件，改完汇报它改了什么。

切分大范围：每个文件夹一个工作智能体

对于一次大范围的机械式改动，把每个工作智能体指向不同的文件夹或模块。一次交接可以携带它自己的工作目录，因此工作智能体不必都待在主导智能体的文件夹里。

把整个应用里的 `useSession` hook 改名为 `useConversation`。
按区域拆开并行执行：src/ 下每个顶层文件夹交给一个智能体，
各自汇报自己改动过的文件。

两个工作智能体编辑同一个文件会打架，而且谁都不知道对方存在。凡是切片可能重叠之处，就给每个工作智能体它自己的 git worktree——同一仓库的独立检出——事后再合并。子智能体不会自动获得一个隔离的 worktree。

当这些切片大到值得分开验收时，待办任务是更合适的形态：一个切片一条任务，每条天然隔离，每条在你读过之后各自落地。委派适合最终汇成一个答案的工作；任务则适合分成好几份分别落地的工作。

子团队：让工作智能体组建它自己的团队

把最大委托深度提到 1 以上，子智能体就能继续往下委派：主导智能体按领域拆分工作，每个领域负责人再拆一次。当一项任务确实可以分解两层时它很有用——例如一次横跨若干服务的迁移，每个服务各有自己的代码、测试和文档。

请把它当作一个刻意的选择。每增加一层都会成倍放大同时在飞的会话数，以及随之而来的令牌开销；每一层交接都是又一次需要为之撰写的冷启动，因此越往深走，指令就越被稀释。深度 2 已经覆盖了几乎所有真实场景。

接续另一个会话未完成的工作

你需要的上下文往往在昨天的某段对话里。用 @ 提及它——从会话分组中选取——主导智能体便能读到那个会话的标题、智能体、工作区、状态和最近的消息，然后依据所见采取行动，包括把后续工作委派出去。

和 @智能体 提及一样，这现在也被读作一条明确的指令：点名一个会话，意味着你是在刻意指向它，因此主导智能体无需被告知就会去查阅它，你提及几个会话它就查几次。

@[昨天的会话] 在迁移做到一半时卡住了。
读一下它已经完成的部分，然后让 @Codex 把剩下的文件做完。

这一项需要在设置 → 通用中打开获取会话信息（默认已开启）——参见设置参考。它是只读的：主导智能体从旧会话中获知情况，但不会恢复它。

何时不要委派

对某些工作而言，委派是错误的工具，而认清这一点比上面任何一种模式都更省时间：

• 任何需要来回沟通的事。 工作智能体拿到一份任务、返回一个结果；没有第二个回合可供澄清。需要反复迭代的工作属于你的主导智能体，或者属于你自己。
• 界定含糊的工作。 一个只拿到模糊交代的陌生人，产出的也是模糊的东西。如果你无法用几行说清目标和交付物，委派只是把含糊挪到了你看不见的地方。
• 细小、迅速的改动。 启动一个会话、冷启动它、再读回结果，代价高于一处两行的改动所值。
• 对同一批文件的并行编辑。 改用接力，或者一人一个 worktree。

把工作流程变成一个技能

委派完全由你如何向主导智能体发出提示来驱动——没有需要配置的编排器，因此一个多智能体工作流程其实只是一套好的指令。一旦你敲定了一个中意的，就把它保存为一个技能，下次用一个 /command 就能调用它。

一个技能就是一个小小的 Markdown 文件（SKILL.md），包含一个名称、一段描述，以及一段智能体在你调用它时会遵循的指令正文。一个编码了跨智能体工作流程的技能，只不过是告诉主导智能体去委派——例如一个 build-with-review 技能：

---
name: build-with-review
description: 实现一处改动，然后让另一个智能体来审查它。
---

# 构建并跨智能体审查

当用户调用这个技能时：

1. 自己实现所请求的改动。
2. 改动可用之后，**把审查委派给另一个智能体**——把 diff、目标和你改动过
   的文件交给另一个智能体（比如 Codex 或 Grok），请它找出 bug、遗漏的
   边界情况和不清晰的代码。它看不到这段对话，所以要把它需要的一切都写进去。
3. 读回审查意见，处理值得处理的部分，然后同时总结你改了什么，以及审查者
   指出了什么。

在设置 → 技能下撰写它，为主导智能体——也就是你将对其调用它的那个——启用它，然后在 composer 中输入 /（如果主导智能体是 Codex，则输入 $）来触发它。工作智能体不需要任何特别之处；它们只是执行主导智能体交给它们的任务。→ 技能 全面介绍了撰写和启用。

与智能体自带的子智能体不同

有些智能体自带它们自己的子智能体功能，会启动更多同一个智能体的副本来并行处理工作——而好几个现成的技能，包括 Codeg 内置的 Experts 技能包中的若干个，就是为驱动那个而编写的。Codeg 的多智能体协作是另一回事：它跨智能体类型进行委派，一个模型调用另一个模型。一个谈论"subagents"却从不点名另一个智能体的技能，用的是智能体自己的机制，而不是 Codeg 的委派。

教程：由团队构建并经过审查的功能

把它们组合起来——一个小功能，由一个智能体实现、由另一个智能体审查：

1. 启用委派。 设置 → 通用 → 多智能体协同 → 启用委托 → 保存。
2. 让两个智能体都准备就绪。 确保你的主导智能体和你将把审查委派给的那个都已各自启用并登录——参见使用智能体。
3. 开启会话。 在项目文件夹中用你的主导智能体开启一个对话。如果你原本想用的那个对话已经处于连接状态，就用一个新的——这是拿到你刚刚启用的委派工具最稳妥的方式。
4. 把工作和审查一起提出来。 例如：

   在 src/share/Dialog.tsx 的分享对话框里加一个"复制链接"按钮。
   做好之后，@Codex 审查一下：把 diff、目标和你改动过的文件交给它，
   请它检查 bug 和边界情况。
   然后处理它的反馈，并告诉我改了什么。

5. 跟随进展。 当主导智能体完成编码时，审查子智能体会出现在子智能体面板中。打开它，观看 Codex 阅读更改，并批准它弹出的任何权限提示——当它被你卡住时，徽标会显示等待批准。
6. 让它收敛。 主导智能体读回审查意见，采纳值得采纳的部分，然后返回一个完成的、经过审查的更改。
7. 审阅并提交。 在更改标签页中查看 diff，满意时就提交——整个 git 工作流程就在那里。

经常这样做？把第 4 步封装成一个技能（见上文），它就变成了一个单命令工作流程。

值得了解

• @ 是可靠的触发方式。 普通文字可行，提及更好——Codeg 会告诉主导智能体：点名一个智能体就是把工作委派给它的指令。
• 启用委派会在智能体下一次启动时到达它。 不限于空白的新对话——任何对话在它的智能体重新连接后都会获得这项能力。只有此刻正处于连接状态的对话才会沿用旧的工具集，而这正是一个提及看似被忽略时最常见的原因。
• 默认只有一层深。 如果你希望子智能体也能依次委派，就提高最大委托深度。
• 子智能体共享你的文件夹。 工作智能体在主导智能体的工作目录中运行，除非主导智能体给它另一个——它不会自动获得自己的 git worktree。若要实现真正的隔离，请在 worktree 中、作为待办任务（那里每个任务都有一个），或以无头自动化的方式运行并行工作。
• 每次交接都是一次性的。 工作智能体拿到一份任务、返回一个结果；没法为了追问而恢复它。再问一次，你得到的是一个全新的会话。
• 结束回合不会停下工作智能体。 如果主导智能体在某个子智能体仍在运行时收尾，那个子智能体会继续跑下去——打开它的会话即可看到它是怎么收场的。取消主导智能体则会停下它们：取消会级联到它启动的每一个工作智能体。
• 结果存放在工作智能体的会话里。 主导智能体只在自己的会话运行期间把已完成的输出保留在内存中。一旦那个会话结束，完整的对话记录依然在子智能体自己的对话里——从侧边栏中父对话上的折叠箭头即可到达。
• 每个子智能体都是一个完整的会话。 它有自己的令牌开销和自己的对话记录——委派会成倍增加正在完成的工作，用量也随之成倍增加。
• OpenClaw 和 Pi 只能作为工作智能体。 两者都不接受通过 ACP 传递的 MCP 工具——也就是委派工具的交付方式——因此它到不了它们那里。两者作为工作智能体都没问题，但无法主导。
• 你自己的智能体也算数。 一个自定义 ACP 智能体是完全对等的队友——可以提及它、委派给它、为它设置工作默认值。

后续步骤

• 使用智能体——启用并登录你将编入团队的智能体。
• 自定义智能体——把你自己的智能体加进可委派的名单中。
• 设置 → 通用——委派开关、深度上限，以及按智能体的工作默认设置。
• 技能——把一个委派工作流程封装成一个可复用的 /command。
• Git 与 Worktree——给并行的工作智能体各自隔离的检出，避免它们相互碰撞。
• 工作区——把主导智能体和它的子智能体平铺，一次性观看它们全部。