子代理分工——不同任务交给不同 Agent
一个 Agent 解决不了所有问题
默认的 Agent 模式什么都做——写代码、查文档、跑命令、做审查。但在大型项目中，把所有任务交给同一个 Agent 会导致两个问题：
- 上下文窗口被浪费：写代码时不需要加载审查规范，审查时不需要加载代码库结构
- 提示词互相干扰：一个 Agent 兼顾多个角色，提示词越长越容易冲突
解决方案是把不同角色拆成不同的 SubAgent。
最常用的 CodeReview Agent
在日常开发中，使用频率最高的是 CodeReview Agent。每次完成代码修改后，触发代码审查，Agent 会加载编码规范和审查 Checklist，对本次修改的代码进行专业审查。它的核心是发现问题，不是做风格检查。
Qoder 内置 SubAgent
Qoder 内置了多个专用 SubAgent，分别对应不同的任务场景：
浏览器智能体
用途：打开浏览器预览页面、截图、做端到端验证
这是 Web 开发最常用的子代理。当你修改了前端代码需要验证效果时，可以让 AI 自动打开浏览器执行测试验证。比如：
- 修改了一个表单组件，让 AI 打开页面验证交互是否正常
- 重构了页面布局，让 AI 截图对比前后效果
- 调试某个功能，让 AI 打开浏览器并执行操作步骤来复现问题
触发方式：在聊天中输入 /browser 或通过 Agent 工具调用
Ultra Review 智能体
用途：审查代码质量、检查规范遵循情况
触发 /ultra-review 后，Agent 会加载编码规范和审查 Checklist，对代码变更进行专业审查。和普通 CodeReview 不同，Ultra Review 做了更深度的分析，能发现更隐蔽的逻辑漏洞。
规划智能体
用途：规划执行计划，生成 TodoList，保存进度
触发 /plan 后，Agent 会分析任务复杂度，分解为可执行的步骤，生成 TodoList 跟踪进度。适合大型重构或跨模块改造任务。
Computer Use 智能体用途有限，日常开发中较少用到。
各 Agent 上下文对比
四个 Agent 的上下文需求完全不同：
| Agent | 需要什么上下文 | 不需要什么上下文 |
|---|---|---|
| 浏览器智能体 | 页面 URL、测试步骤 | 代码结构、设计模式 |
| Ultra Review | 编码规范、审查 Checklist | 业务需求、用户故事 |
| 规划智能体 | 任务描述、项目概览 | 代码实现细节 |
上下文隔离是拆分 SubAgent 的核心原则。 每个 Agent 只加载它需要的上下文，不浪费窗口、不互相干扰。
什么时候该建新的 SubAgent
判断标准很简单：如果一个任务需要的上下文跟其他任务差异很大，就应该拆成独立的 SubAgent。
- 需要不同的规则集 → 拆
- 需要不同的工具集 → 拆
- 需要不同的系统提示词 → 拆
- 只是在同一规则下做不同的操作 → 不用拆
案例：创建一个发布打包智能体
接下来用一个真实案例展示如何创建自定义 SubAgent。
场景描述
假设你有一个产品，包含 Desktop 客户端、Web 前端、后台组件三个子项目。每次发版需要依次编译这三个项目，然后打包、生成安装包、上传 OSS、写发布日志。这是一个固定流程，每次发版都要跑一遍。
这个场景完全符合"该拆"的判断标准：
| 判断条件 | 评估 |
|---|---|
| 需要不同的规则集 | 构建环境 vs 编码规范 |
| 需要不同的工具集 | dotnet/pnpm/NSIS/OSS CLI |
| 重复执行频率高 | 每次发版 |
| 有智能决策空间 | 版本升级判断、报错分析 |
| 上下文独立 | 不需要代码库知识 |
6 条中满足 5 条，明确该拆。
创建方式
在项目目录下创建 .qoder/agents/release-publisher.md。
markdown
---
name: release-publisher
description: 发布打包专家，负责编译多个子项目、生成安装包、上传OSS并编写发布日志
tools: Bash, Read, Write, Glob, Grep
mcpServers:
- github
---
# 角色定义
你是发布打包专家，负责从编译到发布的完整流程。
## 发布流程
1. 确认当前状态（版本号、分支、未提交变更）
2. 编译 Desktop 客户端
3. 编译 Web 前端
4. 编译后台组件
5. 全量打包
6. 编译安装包
7. 基于 Git 提交生成发布日志
8. 上传 OSS
9. Git Tag
## 错误处理
编译失败时分析根因：编译错误定位文件修复，依赖失败重试一次，环境问题上报。
## 约束
- 每完成一步输出进度标记
- 版本号从 csproj 的 <Version> 标签读取
- 发布日志基于实际提交记录生成使用方式
创建完成后，在聊天中输入自然语言即可自动触发：
发版 v1.2.3，这次修了几个 Bug
模型会根据 description 自动匹配并调度 release-publisher 智能体，然后按 9 步流程依次执行。你也可以手动输入 /release-publisher 来指定调用。
为什么脚本 + Agent 是更好的组合
这个案例用到了项目已有的 package.ps1 和 build-nsi-installer.ps1。Agent 不替代 这些脚本，而是在它们之上加一层智能编排：
| 能力 | 脚本 | Agent |
|---|---|---|
| 执行构建命令 | ✅ | ✅（调用脚本） |
| 跨项目编排 | ❌ 各脚本独立 | ✅ 统一调度 |
| 错误诊断 | ❌ 直接退出 | ✅ 分析根因+修复建议 |
| 版本智能决策 | ❌ | ✅ 根据提交范围判断 |
| 发布日志 | ❌ 手动写 | ✅ AI 从 Git log 生成 |
| OSS 上传 | ❌ | ✅ |
脚本负责"执行"，Agent 负责"判断"。
案例：创建一个网站部署智能体
场景描述
你写了一本书《Qoder从入门到精通》，内容全部是 Markdown 文件，想把它发布为网站。每次修改内容后需要：
- 同步所有章节到 Vitepress 项目
- 修补图片路径（书籍的 Markdown 中图片用绝对路径引用，网站需要改为相对路径）
- 构建生成静态 HTML
- 打包上传到服务器
- 解压到站点目录
这是一个固定流程、完全跟编码无关、而且需要反复执行的任务——每次更新书籍内容都要跑一遍。完全符合"该拆"的标准。
判断分析
| 判断条件 | 评估 |
|---|---|
| 需要不同的规则集 | 构建环境 vs 编码规范 |
| 需要不同的工具集 | Node.js/PowerShell/HTTP API |
| 重复执行频率高 | 每次更新内容 |
| 有智能决策空间 | 构建失败异常处理、路径修补校验 |
| 上下文独立 | 不需要代码库知识 |
6 条中满足 5 条，明确该拆。
创建方式
在项目目录下创建 .qoder/agents/bt-deployer.md：
markdown
---
name: bt-deployer
description: 宝塔面板部署专家，负责构建 Vitepress 网站并部署到 qoder.jibao.com
tools: Bash, Read, Write, Glob, Grep
---
# 角色定义
你是 BT 面板部署专家，负责将书籍 Markdown 内容构建为网站并部署。
## 部署流程
1. 同步书籍内容（复制各章节到 Vitepress 项目）
2. 修补图片路径（img 标签、Markdown 引用、API 等）
3. 构建 Vitepress 静态网站
4. 打包为 zip
5. 通过 BT API 上传到服务器
6. 解压到站点目录
## 脚本资源
部署逻辑封装在 Node.js 脚本中：
- `scripts/deploy-bt.js` — 主流程编排
- `scripts/bt-api.js` — 宝塔面板 API 封装
- `scripts/sync.cjs` — 内容同步与路径修补
## 约束
- 部署前确认 npm install 已执行
- 上传解压过程中不要中断脚本 + API 的组合
这个案例与前一个 release-publisher 的差异在于：前者的工具集是本地 CLI（dotnet/pnpm/NSIS），后者是远程 HTTP API（宝塔面板的文件上传、解压、站点管理接口）。
| 能力 | 纯脚本 | Agent + 脚本 |
|---|---|---|
| 执行构建 | ✅ | ✅（调用 npm run build） |
| 文件上传 | ❌ 手动 | ✅ BT API 自动上传 |
| 错误处理 | ❌ 直接退出 | ✅ 分析失败原因并修复 |
| 路径修补 | ❌ 手动处理 | ✅ 自动处理图片路径兼容 |
| 一键触发 | ❌ 多步操作 | ✅ 一条命令或自然语言 |
这展示了 SubAgent 的灵活性——同一个"固定流程编排"模式，可以适配完全不同的工具集。
使用方式
创建完成后，只需一句话即可触发完整部署：
@bt-deployer 帮我部署网站到 qoder.jibao.com
模型会自动调度 bt-deployer 智能体，依次执行 6 步流程。你也可以直接运行脚本：
bash
cd qoder-website && npm run deploy真实案例：Growth AIOS 的多 Agent 分工
Growth AIOS（[AiAgent.Integration](file:///d:/DEV/CODE/Automator/Components/AiAgent.Integration)）是一个低代码 AI 自动化编排平台，纯本地部署，72+ 内置自动化节点。
Growth AIOS 的产品中有一个核心模块 AiAgent.Integration，它本身就是按照 SubAgent 分工思想构建的。这个模块负责让 AI 理解用户需求、自动设计和创建工作流，内部实现了多个专业子代理。
┌─ AiAgent.Integration 模块 ─────────────────────┐
│ │
│ AgentModeProvider（plan/execute 双模式切换） │
│ ├─ Plan Mode：需求解析 + 流程设计 │
│ └─ Execute Mode：执行已批准的工作流 │
│ │
│ 6 步规划流水线 │
│ ├─ Step 1: RequirementParser Agent │
│ │ └─ 将自然语言需求解析为结构化描述 │
│ ├─ Step 2: SkeletonSelector Agent │
│ │ └─ 从结构化描述生成控制骨架（流程图） │
│ ├─ Step 3: NodeSelector Agent │
│ │ └─ 将骨架映射到具体节点（Function Call） │
│ ├─ Step 4: TopologyAssembler（纯代码） │
│ │ └─ 组装 DAG 拓扑结构 │
│ ├─ Step 5: ParamFiller（纯代码） │
│ │ └─ 填充节点参数和引用链 │
│ └─ Step 6: CanvasBuilder（纯代码） │
│ └─ 生成 Canvas JSON + 注册工作流 │
│ │
│ 工具系统（按 Agent 类型分发） │
│ ├─ AgentCliTool — CLI 节点查询 │
│ ├─ AgentWorkflowTool — 工作流定义管理 │
│ ├─ AgentVarVaultTool — 变量存储 │
│ └─ AgentFileTool — 文件操作 │
│ │
│ Skills 知识库（Agent 运行时加载） │
│ ├─ workflow-design-guide — 工作流设计规范 │
│ ├─ coderunner-framework — 代码运行器框架 │
│ ├─ node-usage-patterns — 节点使用模式 │
│ ├─ plan-validation-rules — 规划校验规则 │
│ ├─ category-usage-guide — 分类使用指南 │
│ └─ ...更多 │
│ │
│ 评估与纠错系统 │
│ ├─ EvalCheck — 输出校验（文本级 + DTO 级） │
│ ├─ InteractionModeSelector — 重试/降级/回退决策 │
│ ├─ PlanningCheckpoint — 断点持久化 │
│ └─ ContextCompressor — 上下文压缩防膨胀 │
└───────────────────────────────────────────────────┘它和 Qoder SubAgent 的对应关系
| Qoder SubAgent 概念 | Growth AIOS 的实现 |
|---|---|
| 子代理（不同角色） | RequirementParser / SkeletonSelector / NodeSelector 等独立 Agent |
| 上下文隔离 | 每个 Agent 有不同的 System Prompt 和工具集 |
| 工具权限控制 | IAgentToolProvider 按 AgentType 分发工具 |
| Skills 知识库 | 8 个 Skill 文档，Agent 运行时自动加载 |
| Plan 模式 | 规划流水线 + InteractionModeSelector 决策是否回退 |
| 自动化执行 | Execute Mode — 批准后自动执行，不需要用户确认 |
核心设计差异
Growth AIOS 的 Agent 系统是在自己的产品内部实现的，底层架构与 Qoder 不同：
| 维度 | Qoder | Growth AIOS |
|---|---|---|
| 运行位置 | IDE 插件 | 自研产品运行时 |
| Agent 驱动 | 内置模型 + Skill | IAgentSubAgentProvider 接口 + 自定义管道 |
| 输出校验 | 无内置 | EvalCheck 校验系统（重试→降级→回退三级） |
| 记忆机制 | Memory | PlanningCheckpointStore 断点持久化 |
| 工具扩展 | Tool 注册 | 按 AgentType 分发 + DTO 校验 |
一个例子
用户在 Growth AIOS 中描述需求：
"每天 8 点从 FTP 下载昨天的销售报表，转成 Excel 发给老板邮箱"
底层 Agent 流水线自动执行：
- RequirementParser 解析出操作对象（FTP 文件）、动作（下载→转换→发送）、流程特征（定时）
- SkeletonSelector 设计控制骨架：定时触发器 → 下载 → 格式转换 → 发邮件 → 结束
- NodeSelector 选型：FTPDownload 节点 + ExcelConvert 节点 + EmailSender 节点
- 纯代码步骤 自动完成拓扑组装、参数填充、Canvas 注册
整个过程涉及多个 Agent 配合，但用户看到的只有一个需求输入。
小结
Growth AIOS 的 AiAgent.Integration 证明了一件事：SubAgent 分工思想不限于 IDE 工具，它可以嵌入任何产品的 Agent 体系中。 核心模式是一致的：上下文隔离 + 角色分工 + 工具权限控制。如果你自己的产品需要集成 AI 能力，可以参考这个模式——不需要自己从零设计，这套方案已经在产品中经过验证。
检查表：Agent 分工决策
- [ ] 当前 Agent 的上下文窗口经常不够用吗？
- [ ] 不同任务的提示词是否有冲突？
- [ ] 是否有工具集使用权限的差异？
- [ ] 子 Agent 的职责是否单一、可描述？
- [ ] 子 Agent 的触发场景是否明确？
- [ ] 是否需要独立的历史记录/会话隔离？
如果以上问题超过 3 个回答"是"，就应该考虑拆分 SubAgent。