Goose 中的 Agent 协作模式全解析：Agent、Subagent 与 Multi-Agent 的概念与选型指南

Agent、Subagent、Multi-Agent——这些术语在 AI 编程社区里被频繁抛出，但很少有人真正讲清楚它们的区别。本文以开源 AI Agent 项目 Goose 为背景，用一个完整的"为 Web 应用添加暗色模式"示例贯穿三种协作模式，并结合仓库源码说明每种模式在 Goose 中的落地形态与适用场景，帮助你根据任务复杂度正确选型。

先看结论：三种模式一句话速览

在展开细节之前，先给出一段 TL;DR，方便你快速建立整体心智模型：

• Agent（单一智能体）：一个自主行动的参与者，把你的目标接下后端到端跑完，全程不需要队友、不需要交接。
• Subagent（子智能体）：主 Agent 扮演"编排者"角色，把工作拆分并委派给它所控制的多个子 Agent。主 Agent 掌控流程、顺序与协同。
• Multi-Agent（多智能体）：两个或更多"平级"的主 Agent，各自独立行动，但可以相互协作、协商或交换结果。没有谁是"老板"。

类比人类协作方式：Agent 像一个人单干整张工单，Subagent 像技术负责人带队拆解任务，Multi-Agent 则像两个对等同事在 Slack 上你来我往地讨论直到方案成型。

Agent：单兵作战模式（Solo Hero Mode）

概念与工作方式

Agent 是自主行动者，本质上是你的"一人军队"。 你把任务交给一个 Agent——例如 Goose——它读取仓库、修改 CSS 与主题、运行测试、最后开出 Pull Request，从开始到结束全程自理。

以"给应用添加暗色模式"为例：你只需说一句"给应用加暗色模式"，Agent 会自己完成整条链路。中途如果某个环节出错（例如它忘记在设置菜单里更新切换开关），它必须自己回溯并修复，没有队友可以分担。

这种模式对应 Goose 中主会话（main session）的默认工作方式：Agent 在同一个会话里连续调用工具、自我纠错直至任务完成。

适用场景

• 任务小而自洽，你信任单个 AI 能独立负责到底；
• 任务链路明确、无需多人多视角参与。

从仓库源码看，单一 Agent 的核心执行循环集中在 crates/goose/src/agents/agent.rs，配合会话管理（session）与工具执行框架完成端到端任务。

Subagent：编排者带队的协作模式（Orchestrator With a Crew）

概念与工作方式

Subagent 模式下，你仍然只有一个"主" Agent，但它不再事必躬亲，而是扮演技术负责人（tech lead），把工作拆解并委派给多个专职子 Agent：

• "设计师 Agent，创建暗色模式的配色板。"
• "前端 Agent，把所有 UI 组件应用上这套配色。"
• "QA Agent，运行视觉回归测试。"

这些子 Agent 可以并行工作（设计师做配色时前端同步改样式），也可以串行执行（前端必须等设计师先完成）。主 Agent 负责让一切保持在轨道上：收集各子 Agent 的结果并拼装成最终交付物。

Goose 中的 Subagent 实现原理

在 Goose 仓库中，subagent 的能力并非概念层面的空谈，而是有明确的工程实现支撑。

任务执行入口位于 crates/goose/src/agents/subagent_handler.rs，其中 run_subagent_task 负责在独立上下文中执行子任务；任务配置定义在 crates/goose/src/agents/subagent_task_config.rs，其 TaskConfig 结构携带 provider、模型配置、父会话 ID、父工作目录、扩展列表与最大轮次等完整依赖：

• 默认最大轮次（max_turns）为 25，对应源码常量 DEFAULT_SUBAGENT_MAX_TURNS: usize = 25；
• 该默认值可通过环境变量 GOOSE_SUBAGENT_MAX_TURNS 覆盖，实现位于 TaskConfig::new 中；
• 默认超时 5 分钟；子 Agent 一旦失败或超时，主会话不会收到该子任务的输出（并行场景下则只返回成功子任务的结果）。

委派工具由 summon 平台扩展提供（crates/goose/src/agents/platform_extensions/summon.rs）：

• delegate(source, ...)：把任务作为子 Agent 运行，等待其返回结果；传入 async: true 时转为后台异步任务；
• load(source)：把某份内容载入自身上下文；对后台任务可用 load(source: "task_id") 等待完成、peek: true 查看进度、cancel: true 取消任务。

子 Agent 的系统提示词模板位于 crates/goose/src/prompts/subagent_system.md，其中明确约束了子 Agent 的行为特征：独立性（在授权范围内自行决策与执行工具）、专注性（只处理主 Agent 分配的任务）、效率性（精简工具调用）、有界运行（受轮次与超时限制），以及一条关键安全约束——子 Agent 无法再派生子 Agent，防止无限递归。

如何用自然语言启用 Subagent

Goose 支持自主创建子 Agent：在默认的自治（autonomous）权限模式下，只要它判断拆分子任务对你更有利，就会自动派生子 Agent，并不总需要你显式要求。你可以通过自然语言指示主 Agent 委派任务，例如：

1. 请求专职帮助："Use a code reviewer to analyze this function for security issues"
2. 引用特定 recipe："Use the 'security-auditor' recipe to scan this endpoint"
3. 并行跑多个任务："Create three HTML templates simultaneously"
4. 委派复杂调研："Research quantum computing developments and summarize findings"
5. 控制扩展访问："Create a subagent with only the developer extension to refactor the code"

子 Agent 可以串行或并行运行。Goose 会根据你的措辞推断执行方式：

类型	说明	触发关键词	示例
串行（默认）	任务一个接一个执行	"first...then"、"after"	"First analyze the code, then generate documentation"
并行	任务同时执行	"parallel"、"simultaneously"、"at the same time"、"concurrently"	"Create three HTML templates in parallel"

实时监控子 Agent 活动

子 Agent 执行期间，你能实时看到它的工具调用：

• goose Desktop：子 Agent 的工具调用以会话内可展开区块呈现，包含调用的工具名、传入参数与工具输出结果。
• goose CLI：工具调用内联展示，并带可视指示器标明工具名与提供该工具的扩展，格式形如：

[subagent:16] text_editor | developer

其中 subagent:16 是子 Agent 标识符，text_editor 是工具名，developer 是提供工具的扩展。

三种派生子 Agent 的方式

方式一：直接提示（Direct Prompts）。用一句自然语言临时派生子 Agent，主 Agent 根据请求自动完成配置。例如提示"并行使用 2 个子 Agent 分别创建 hello.html 与 goodbye.html"，工具会返回带 execution_summary（总任务数、成功数、失败数与耗时）和逐任务 task_results 的结构化结果：

{
  "execution_summary": {
    "total_tasks": 2,
    "successful_tasks": 2,
    "failed_tasks": 0,
    "execution_time_seconds": 16.2
  },
  "task_results": [
    { "task_id": "create_hello_html", "status": "success", "result": "Successfully created hello.html with Hello World content" },
    { "task_id": "create_goodbye_html", "status": "success", "result": "Successfully created goodbye.html with Goodbye World content" }
  ]
}

方式二：通过 Recipe 定义。Recipe 文件把子 Agent 的指令、扩展和行为沉淀为可复用配置。一个典型的 code-reviewer.yaml：

id: code-reviewer
version: 1.0.0
title: "Code Review Assistant"
description: "Specialized subagent for code quality and security analysis"
instructions: |
  You are a code review assistant. Analyze code and provide feedback on:
  - Code quality and readability
  - Security vulnerabilities
  - Performance issues
  - Best practices adherence
activities:
  - Analyze code structure
  - Check for security issues
  - Review performance patterns
extensions:
  - type: builtin
    name: developer
    display_name: Developer
    timeout: 300
    bundled: true
parameters:
  - key: focus_area
    input_type: string
    requirement: optional
    description: "Specific area to focus on (security, performance, readability, etc.)"
    default: "general"
prompt: |
  Please review the following code focusing on {{focus_area}} aspects.
  Provide specific, actionable feedback with examples.

把 recipe 放到 Goose 可发现的位置：设置 GOOSE_RECIPE_PATH 环境变量指向 recipe 目录，或直接放在当前工作目录。之后用 Use the "code-reviewer" recipe to analyze the authentication feature I implemented 即可让 Goose 依此派生专职子 Agent。

方式三：外部 Subagent。你甚至可以引入其他平台/供应商的 AI Agent（如 Codex、Claude Code），将它们以 MCP server 方式接入 Goose，从而把工作流编排进更广泛的生态。以 Codex 为例，在 goose 配置文件（如 ~/.config/goose/config.yaml）中注册外部 subagent：

subagent:
  args:
  - mcp-server
  bundled: true
  cmd: codex
  description: OpenAI Codex CLI Subagent
  enabled: true
  env_keys:
  - OPENAI_API_KEY
  envs: {}
  name: subagent
  timeout: 300
  type: stdio

再结合外部工具自身配置（如 ~/.codex/config.toml 设置 approval_policy = "never" 避免弹审批、[sandbox] mode = "workspace-write" 授予写权限），然后用一句话调用："Use the codex subagent to analyze my codebase structure and identify the main components"。

关键默认参数与安全约束

下表汇总了子 Agent 的默认配置及覆盖途径（更完整的说明见 Subagents 指南）：

参数	默认值	如何定制
最大轮次（Max Turns）	25	自然语言描述、设置 GOOSE_SUBAGENT_MAX_TURNS，或在 recipe 的 settings.max_turns 中配置
超时（Timeout）	5 分钟	在提示中请求更长超时，如 "with 20-minute timeout"
扩展（Extensions）	继承自主会话	在提示中指定子 Agent 可用扩展
返回模式（Return Mode）	完整信息回传主会话	提示中说明要摘要还是细节

在源码层面，超时对应外部配置里的 timeout: 300（秒），而 delegate 工具也支持 max_turns 参数覆盖 recipe 与全局默认值，校验逻辑要求其不小于 1。

安全约束方面，子 Agent 有受限的工具访问权限，以防止干扰主会话：

• 允许的操作：扩展发现（了解可用工具）、资源读取（列出已启用扩展的资源）、以及使用 recipe 指定或从父会话继承的扩展工具；
• 受限的操作：禁止再派生子 Agent（防止无限递归）、禁止启停或修改扩展（避免与主会话冲突）、禁止创建/修改/删除定时任务（防止干扰父工作流）。

实战案例：一次真实的混合编排

仓库中的 Orchestrating 6 Subagents 博客 记录了一次把 6 个子 Agent 编排成"随叫随到的开发小队"的真实经历：后端开发、前端开发、冲突解决工程师、文档作者、API 示例策划与测试工程师各司其职。其经验要点非常值得借鉴：

• 混合编排：让依赖前置结果的子 Agent 串行执行（后端 → 冲突解决 → 前端 UI），而彼此独立的子 Agent 并行执行（README、API 集合、测试套件三者只依赖核心应用已存在）；
• 显式调大超时：默认超时 5 分钟，该案例在提示中要求 "Set the time out to 9 minutes"；
• 先规划后并行的教训：让 5 个并行子 Agent 各自独立重做 UI 组件时，每个都带来自己对"儿童友好"的不同理解，结果风格四分五裂——因为它们彼此不知道对方的方案。改为先派生一个子 Agent 产出统一设计计划，再让 4 个子 Agent 并行执行该计划后，效果显著改善。

对应地，Using Subagents 教程 也给出了更完整的分角色编排范式：Planner 定义产品范围 → Project Manager 拆解任务并分配 → Architect 定技术栈 → 前后端并行实现 → QA 测试 → Tech Writer 写文档。

Multi-Agent：多主脑对话模式

概念与工作方式

Multi-Agent 与 Subagent 的本质区别在于：没有单一编排者。你拥有多个平级的主 Agent，各自带着独立的目标或视角相互沟通。它们不需要处理同一份任务——有时只是运行在同一环境中，当工作范围交叠时自然协作。

回到暗色模式示例：

• 开发 Agent 熟悉代码库，能实现 UI 改动；
• UX 研究 Agent 了解用户如何使用主题、无障碍访问需要考量什么。

两者协同：UX Agent 说明最佳实践、边界情况与用户痛点，开发 Agent 实现并回传确认反馈。它们甚至可以运行在不同系统上——例如你的开发 Agent 调用托管在别处的外部设计 Agent（Goose 的外部 subagent 机制，即把 Codex 等作为 MCP server 接入，正是通向这种跨系统 Agent 协作的桥梁）。

在 Goose 语境中，Multi-Agent 的形态通常表现为：多个 Goose 实例（或 Goose 与其他 Agent 工具）各自维护独立会话，通过共享文件、MCP 服务器或任务交接进行协作，任一 Agent 都可运行自己的编排逻辑。

适用场景

• 任务本身需要多个大脑或多重视角参与讨论、协商与权衡；
• 各方观点需要碰撞后才能收敛（例如"实现"与"用户体验/无障碍规范"之间的拉锯）；
• 没有单一 Agent 适合拥有全局控制权，或各 Agent 分属不同信任域/不同宿主系统。

选型决策：什么场景用哪种

模式	何时选择
Agent	小而自洽的任务，你信任单个 AI 独立负责端到端交付
Subagent	复杂任务，需要"分而治之"且有人（主 Agent）统筹监督
Multi-Agent	需要多个大脑/视角进行协商协作，结果依赖讨论与妥协

选择的核心逻辑，与人类组织工作并无二致——在速度与准确性之间找到最佳平衡点：

• 任务链路短、错误可自我修复 → 单一 Agent 最高效；
• 任务可拆分、子任务存在依赖关系或共享规范风险 → Subagent 编排（注意：并行子 Agent 缺少共享计划时容易各自为政，串行适合"前一步是后一步前提"的场景，并行适合相互独立或已有一份统一计划的任务）；
• 涉及不同专业视角、需要协商或跨系统调用 → Multi-Agent。

延伸阅读

• Subagents 完整指南：内置/外部子 Agent、Recipe 配置、扩展控制与安全约束细节
• Using Subagents 动手教程：以"AI BriefMe"应用为例，演练 Planner、PM、Architect 到 QA、Tech Writer 的完整团队编排
• Orchestrating 6 Subagents 实战博客：一次真实项目的混合串并行编排经验与踩坑复盘
• Subagent 任务执行入口 与 任务配置默认参数：源码级了解子 Agent 生命周期与轮次/超时语义
• subagent 系统提示模板：子 Agent 行为约束的第一手定义