Agent EngineeringAgent 工作流实践8 min
SubAgent 不是越多越好
多 Agent 系统的关键不是数量，而是边界、调度成本和结果汇总质量。
SubAgentMulti-AgentWorkflow
很多人第一次接触 SubAgent，会自然地想把所有任务都拆出去。
这很危险。SubAgent 不是越多越好，多 Agent 系统真正困难的地方不是并发，而是边界、调度成本和结果汇总。
什么时候适合拆 SubAgent
我会优先拆三类任务：
- 边界清晰：输入输出明确，不需要频繁来回确认
- 可以并行：多个任务之间没有强依赖
- 结果可验证：子任务完成后能被主 Agent 或工具检查
比如代码库调研、资料搜集、竞品页面分析、独立模块实现，都比较适合拆。
什么时候不该拆
下面这些任务不适合随便拆：
- 架构决策还不清楚
- 文件写入范围高度重叠
- 任务之间有强顺序依赖
- 需要持续和用户对齐
- 成败判断依赖全局上下文
这类任务如果硬拆，会制造更多协调成本。
主 Agent 的职责
多 Agent 系统里，主 Agent 不应该只是转发消息。
主 Agent 应该负责：
- 判断任务是否值得拆
- 设计子任务边界
- 控制每个子 Agent 的工具权限
- 汇总结果并消除冲突
- 做最终验证和交付说明
也就是说，主 Agent 更像调度者和责任人，而不是一个消息路由器。
子 Agent 的职责
子 Agent 应该窄而深。
一个好的子任务应该能用一句话说清楚：
你负责什么，不负责什么，最终交付什么。
如果这个边界说不清楚，说明任务还不适合拆。
多 Agent 的真实成本
多 Agent 会带来几个成本：
- 上下文复制成本
- 指令对齐成本
- 结果冲突成本
- 汇总判断成本
- 工具权限风险
只有当并行收益明显高于这些成本时，SubAgent 才值得用。
我在 OpenClaw 里的倾向
我更倾向于做少量高质量专业 Agent，而不是堆一堆模糊角色。
比如：
- 产品经理 Agent：调研、需求拆解、文档输出
- 设计 Agent：视觉探索、素材生成、风格建议
- 工程 Agent：代码修改、测试、提交说明
- 搜索 Agent：网页检索、资料归纳、来源整理
每个 Agent 都应该有清楚的工具边界和输出格式。
判断标准
我会用一个简单标准判断是否要拆：
如果拆出去能让主流程更快、更清楚、更可验证，就拆。 如果拆出去只是显得系统更复杂，就不要拆。
SubAgent 的价值不是数量，而是让复杂任务被更稳定地完成。