把工作委派给其他 Agent

当工作可以拆成各自产出结果的部分时，可以让飞书里的主 Agent 委派给其他专家，再汇总 结果。本文说明如何提出可执行的分工、核实委派、继续同一位专家的工作，以及处理失败。

先决定需要哪一种协作

需求	合适的对象	应记录的身份
继续与当前助手讨论	当前 Session 的下一轮对话	当前话题或会话，不要求产生 Task ID
做完一次检查、分析或修改就交付	临时 TaskRun	task_id
同一专家分几轮持续处理一个工作区	持久 Agent Instance	agent_instance_id，以及每次执行的 task_id
调用原生 Agent 自己的子 Agent	由原生 Agent 提供的功能	不自动拥有 amux Task 或 Instance 身份

Profile 是可复用的专家定义，不是某次执行。两次指定 builtin/codex 可以创建两次 独立工作；要继续某个持久专家，需要复用实例 ID。

准备足够明确的分工

主 Agent 需要能使用 amux 委派工具，并能找到可用 Profile。机器人能聊天，不代表它一定 具备这些工具；Profile 的存在也不证明其凭据、工作区和目标机器已准备好。

首次使用时，可以先让主 Agent 列出可用专家，并说明各自能处理什么。正式委派包含：

要素	示例
输入与范围	指定仓库和提交、附上需要检查的差异或文档段落
分工	一位检查正确性，一位检查测试覆盖
允许的操作	只读审阅，先不要修改文件或创建远端记录
交付标准	每条结论包含文件位置、依据和建议
执行环境	使用哪台 Runtime 上的仓库或工作区，是否需要凭据
时间边界	每个子任务的时限；超时后报告已有证据和未完成部分
汇总方式	主 Agent 合并重复项，标明分歧和缺少证据的判断

下面是自然语言请求示例，不是飞书斜杠命令：

@助手 请审阅指定仓库的这次改动。先确认可用专家和仓库位置，再通过 amux 将正确性检查 与测试覆盖检查分别委派给两位专家，只做只读分析。为每位专家明确提供改动范围和材料。 创建后返回各自的任务 ID；完成后合并问题列表，每条附文件依据，并标出未完成项。

Agent 是否按请求使用 amux 工具仍取决于模型、工具和权限。它在文本中写“我让另一个 专家看了”不足以证明委派发生，应核对工具返回的任务或实例 ID。

跟踪一次有边界的委派

通常的可验证流程是：主 Agent 选择 Profile → amux.task_submit 返回 Task ID → 子执行准备与运行 → amux.task_get / amux.task_stream 返回状态与结果 → 主 Agent 汇总。 amux.task_run 是等待结果的同步入口；需要把权限请求上报给主 Agent 时，不能使用这种 阻塞形式，应采用异步提交和查询。

Task 在被选中的 Runtime 上执行。默认工作区是临时目录，并不会自动把父会话的当前 目录、未提交修改、整段飞书话题或所有附件复制过去。审阅仓库时需提供可访问的仓库身份 或目标机器上的路径；使用 git-worktree 时还要满足仓库目录或缓存标识要求。

如何阅读子任务卡

在已绑定的飞书对话中，amux 观察到相关委派后，会为子工作显示独立进度卡，并在原卡上 持续更新。卡片标签使用专家短名和实例或子 Session 的身份片段；Task ID 可能作为启动前 的临时标识。因此，用完整 Task ID 核对记录，比仅凭卡片标题更可靠。

• 主卡显示主 Agent 的活动摘要；子卡的执行过程、模型和结果属于那个子执行。
• 子任务成功后，主 Agent 可能仍在比较结论，不能把一张子卡完成当成整个请求完成。
• 父回答结束也不等于所有子任务都被取消，仍应检查各自状态。
• 子卡的累计用量来自其 Provider 对话；持久专家可能包含之前 TaskRun 的用量，不能把 父子卡数字简单相加作为本次工作的计费结果。
• 没有子卡时，先检查 Task ID 和记录。卡片是展示入口，任务记录才用于确认是否实际创建。

状态和结果分别看什么

状态	读者应该怎么理解
pending / preparing / running 等非终态	工作尚未完成，可能仍在准备资源或执行
waiting_permission	有权限请求需要按该 Task 的策略处理
succeeded	系统记录执行成功，仍需核对报告、补丁或文件是否满足验收要求
failed	执行失败，读取错误与已产生的结果，不应冒充完整交付
cancelled	已取消，不等于已执行过的修改被撤销
timed_out	超过截止时间，检查已完成内容后决定是否重新分工

当前默认 Task 时限为 30 分钟，timeout_seconds 从接受任务起计算，包括准备和 Agent 启动。显式配置更短时限时，也要给资源准备留出时间。默认返回摘要；需要完整证据时再 读取事件或详细结果，完整文本也可能因大小限制截断，并提供继续获取的线索。

处理权限、停止和失败

子任务权限策略控制的是权限请求的处理：默认的 policy-allow 自动处理符合规则的请求， 不保证逐项向人确认；deny-all 拒绝请求， escalate-to-main 将请求上报，由主流程通过任务工具响应。策略不会赋予文件系统权限、 绕过隔离、补上缺失凭据，也不能当作只读沙箱。

不要把在飞书里对主回答发送 /interrupt 当成“所有子任务已经取消”。需要停掉明确的 子工作时，让主 Agent 对对应 Task ID 使用 amux.task_cancel 并返回最终状态。取消只 处理该执行，已经写入的文件或外部系统变化仍需另行检查。

某个子任务失败后，可以先取回错误和已有证据，只重做缺失部分。结果验收时检查文件 所在的 Runtime 与工作区；子工作生成的补丁不会因为完成就自动合并到你的主分支，也 不能仅凭一段“已修改”说明判断父工作区已改变。

运维者可使用以下只读命令核对：

amux task show <task-id>
amux task logs <task-id>

让同一位专家继续工作

需要分几轮处理同一环境时，明确要求建立持久 Agent Instance，并保留实例 ID。例如：

请用持久专家完成第一轮审阅，返回实例 ID、这次的任务 ID 和主要发现。等我补充约束后， 继续使用同一个实例，不要重新创建另一个同名专家。

工具	何时使用	是否启动新工作
amux.instance_spawn	第一次创建持久专家	启动初次工作，返回稳定实例身份
amux.instance_followup	让已有实例继续处理明确的新要求	是，产生新的 TaskRun，保留原生对话历史
amux.instance_send	暂存补充消息，供以后唤醒时读取	否，只进入信箱，在之后的任务提示前交付
amux.instance_steer	纠正实例此刻正在做的工作	否，加入当前执行；没有执行在跑时回落到信箱（delivery=mailbox）
amux.instance_wait	等待实例当前执行结束或等待超时	否；结果仍通过 Task 工具获取
amux.instance_interrupt	取消实例当前所属的执行	保留实例和可恢复环境，不删除实例身份

追问可写：“继续使用实例 <agent_instance_id>，根据刚补充的约束重新评估第二个风险， 并返回新的 Task ID。”只有换成 instance_followup 等真正的执行入口才会唤醒工作； instance_send 成功不代表它已经开始回答。instance_steer 返回 delivery=mailbox 后， 用 instance_followup 继续：信箱里的纠正会先送达，新的提示里不要重复它。

instance_wait 的等待超时也不等于 Task 超时或取消。等待结束后，按对应 Task ID 使用 amux.task_get 或 amux.task_stream 查询结果。

实例会回到已经记录的 Runtime，保留可恢复的 Provider 历史和环境；这不是跨机器自动 故障转移承诺。实例的 active / idle / archived 与某次 Task 的成功或失败是不同 状态，查询时不要混用。

常见问题

现象	核对或修复
声称已委派，但找不到任务	请主 Agent 返回真实工具结果和 Task / Instance ID，区分原生子 Agent
子任务找不到仓库或文件	给出目标 Runtime 可访问的路径、仓库和明确输入，检查工作区策略
子任务一直等授权	查询 waiting_permission 和权限 ID；检查主流程是否能响应上报请求
同一专家似乎忘记上次工作	是否复用了实例 ID，还是仅重新选择相同 Profile
发了实例消息却没有回答	是否只调用了 instance_send；需要 instance_followup 才启动新任务
主 Agent 已停止，子任务仍在运行	单独取消指定 Task，并核对其最终状态
所有子卡成功但没有最终结论	要求主 Agent 获取各自结果、处理分歧并完成汇总

其他飞书机器人属于另一种接入，不等于本机安装的 Profile。外部 Bot 发现和新委派要求 当前群的有效绑定，不能据此跨群发现机器人。产品对象见Agent 概念， 权限、工作区与完整工具参数见 Task 模型、 Task 操作指南和 MCP 参考。