AI Coding工具中的“subAgent”正从营销词发展为工程抽象，实现上下文、权限、任务和执行的拆分管理。主流工具如Claude Code、Codex、OpenClaw、Gemini CLI均在强化subAgent能力，但设计哲学各异。文章从技术视角解析subAgent的本质、各工具异同及使用选择，强调其通过边界划分解决工程问题，而非简单增加AI数量。不同工具侧重点不同：Claude Code聚焦专家角色配置，Codex强调并行工作流，OpenClaw注重后台session管理，Gemini CLI则将Agent作为工具调用。文章建议根据任务特点选择合适工具，并给出多Agent编程实践建议，指出subAgent是AI Coding工具工程化的基础，未来可能收敛于标准化配置、权限最小化、上下文隔离等能力，推动AI Coding走向多Agent协作环境。

---

截至 2026-05-01，AI Coding 工具里的 “subAgent” 已经不是一个单纯的营销词，而逐渐变成一种工程抽象：把上下文、工具权限、任务边界和并行执行拆开管理。

最近几个主流 AI Coding 工具都在强化 subAgent 能力，比如 Claude Code 的 subagents、OpenAI Codex 的 subagents、OpenClaw 的后台 subagent session、Gemini CLI 的 subagents。

它们看起来都叫 subAgent，但背后的产品哲学并不一样。

这篇文章尝试从技术视角梳理几个问题：

1. 1. subAgent 本质上解决什么问题？
2. 2. Claude Code、Codex、OpenClaw、Gemini CLI 的 subAgent 有什么异同？
3. 3. 实际使用时，应该怎么选？

一、subAgent 解决的不是“多个 AI 聊天”，而是工程边界问题

很多人第一次看到 subAgent，会自然理解成：

一个主 AI，叫几个小 AI 帮它干活。

这个理解没有错，但太浅了。

从工程实现看，subAgent 更重要的是引入了几个边界：

边界	作用
上下文边界	子 Agent 有自己的 context，不污染主会话
工具边界	子 Agent 可以只拿到部分工具权限
任务边界	每个子 Agent 只负责一个明确任务
并行边界	多个任务可以同时跑，而不是顺序等待
责任边界	主 Agent 负责汇总，子 Agent 负责局部执行

这几个边界加起来，才是 subAgent 真正有价值的地方。

举个例子，假设你让 AI 修一个复杂 bug。一个单 Agent 可能会在同一个上下文里同时做这些事：

• • 读代码
• • 猜测 bug 原因
• • 搜索日志
• • 修改实现
• • 跑测试
• • 回看 PR diff
• • 写总结

上下文很快变脏。中间的错误假设、无关文件、失败尝试都会留在主会话里，影响后续判断。

subAgent 的思路是：把这些工作拆出去。

比如：

• • 让一个 subAgent 专门读日志和复现问题
• • 让一个 subAgent 专门看相关代码路径
• • 让一个 subAgent 专门做代码审查
• • 主 Agent 只接收它们的结论，然后决定下一步

这就是 subAgent 的核心价值：不是让 AI 数量变多，而是让复杂任务的上下文和责任被拆开。

二、四个工具的 subAgent 设计哲学

先给一个总览表。

工具	subAgent 的核心定位
Claude Code	可配置的专家角色
Codex	显式并行工作流
OpenClaw	后台运行的 Agent session
Gemini CLI	作为工具暴露的专家 Agent

它们都能做“任务委派”，但侧重点不同。

三、Claude Code：subAgent 是“可治理的专家角色”

Claude Code 的 subAgent 最像一个“预配置专家”。

一个 subAgent 通常包含：

• • 名称
• • 描述
• • system prompt
• • 可用工具
• • 模型配置
• • 权限模式
• • MCP server
• • hooks
• • memory
• • isolation 配置

其中 name 和 description 是核心必填项，其他字段用于进一步收窄工具、模型、权限和运行方式。

Claude Code 的 subAgent 可以放在：

.claude/agents/~/.claude/agents/

也可以通过 CLI 动态传入。

一个典型的 Claude Code subAgent 可能长这样：

---name: code-reviewerdescription: Review code changes for correctness, security, and maintainability.tools: Read, Grep, Globmodel: sonnet---You are a senior code reviewer. Focus on bugs, security issues, regressions, and missing tests.

Claude Code 的特点是：它把 subAgent 做成了可复用、可治理、可沉淀的专家角色。

比如团队可以沉淀这些 agent：

• • code-reviewer
• • security-reviewer
• • test-fixer
• • database-migration-reviewer
• • frontend-accessibility-checker

这些 agent 可以跨项目复用，也可以通过项目级配置覆盖用户级配置。

Claude Code 还支持 foreground/background subAgent。foreground 会阻塞主会话，background 可以并发执行。

但它也有边界：普通 subAgent 主要是向主 Agent 汇报结果，它们之间不是天然的多人协作关系。

一句话总结：

Claude Code subAgent 更像“专家角色系统”，适合把团队经验固化成长期可复用的 Agent 配置。

四、Codex：subAgent 是“显式并行执行策略”

Codex 的 subAgent 设计更强调并行工作流。

它不像 Claude Code 那样主要围绕“专家人格库”展开，而是更关注：

• • 哪些任务可以并行？
• • 哪些任务应该交给 worker？
• • 哪些任务适合 explorer？
• • 主 Agent 什么时候等待结果？
• • 多个 Agent 的结果如何汇总？

Codex 里常见的内置角色包括：

角色	适合任务
explorer	快速调查代码库、回答具体代码问题
worker	修改代码、实现功能、修复问题
default	通用任务

Codex 的一个关键原则是：只有用户明确要求时，Codex 才会 spawn subagent。

也就是说，它不是随时自动开一堆 agent，而是更偏“显式编排”。

Codex 当前内置 default、worker、explorer 三类 agent。自定义 agent 使用 TOML 文件，位置通常是：

.codex/agents/~/.codex/agents/

每个自定义 agent 至少需要 name、description、developer_instructions，也可以覆盖模型、reasoning effort、sandbox、MCP 和 skills 等配置。

比如你可以这样使用：

请并行启动几个 agent：1. 一个 explorer 调查认证模块的数据流2. 一个 explorer 查看测试覆盖情况3. 一个 worker 修复登录失败的问题

Codex 很适合这类场景：

• • 大型代码库调研
• • PR review
• • 多模块并行改造
• • 一个 Agent 实现，另一个 Agent 并行验证
• • 多个独立假设同时排查

它的工程味更强：当你让多个 worker 同时改代码时，最好明确文件所有权。

比如：

Worker A 只负责 auth/ 目录。Worker B 只负责 tests/auth/ 目录。不要互相回滚对方改动。

这类约束对于多 Agent 编码非常重要。否则多个 Agent 同时修改同一个文件，很容易互相覆盖。

一句话总结：

Codex subAgent 更像“并行执行框架”，适合把复杂任务拆成多个互不阻塞的执行分支。

五、OpenClaw：subAgent 是“后台 Agent session”

OpenClaw 的 subAgent 设计更偏运行时系统。

它关注的不是“专家角色是否优雅”，而是：

• • 如何启动一个后台 Agent？
• • 如何给它分配队列？
• • 如何查看状态？
• • 如何发消息？
• • 如何停止？
• • 如何控制并发？
• • 如何处理嵌套？

OpenClaw 的 subAgent 更像一个后台 session。

它可以非阻塞运行，主会话不用一直等待。你可以继续做别的事，然后再查看 subAgent 的状态、日志或结果。

这种设计非常适合长任务，比如：

• • 后台跑大规模代码扫描
• • 长时间测试
• • 多个 issue 并行修复
• • 让一个 Agent 持续跟进某个任务
• • 主 Agent 继续做调度和决策

OpenClaw 还提供了比较明显的运维控制能力，比如：

• • 查看 subAgent 信息
• • 查看日志
• • 给 subAgent 发消息
• • kill subAgent
• • 控制并发队列
• • 设置嵌套深度

它的嵌套默认比较克制：maxSpawnDepth 默认是 1，也就是普通 sub-agent 默认不能继续无限扩散；如果要做 orchestrator 模式，可以把深度调到 2。每个 agent session 也有活跃子任务数量上限，默认是 5，用来避免失控 fan-out。

所以 OpenClaw 的 subAgent 更像是：

Agent runtime + session manager + task queue

而不是单纯的“专家 prompt”。

一句话总结：

OpenClaw subAgent 更像“后台任务系统”，适合需要运行时管理、队列控制和长期任务跟踪的多 Agent 工作流。

六、Gemini CLI：subAgent 是“Agent as Tool”

Gemini CLI 的 subAgent 设计很有特点：它更接近 agent-as-tool。

也就是说，subAgent 会作为一个工具暴露给主 Agent。主 Agent 在需要时调用这个工具。

Gemini CLI 有内置 subAgent，比如：

• • codebase_investigator
• • cli_help
• • generalist
• • 实验性的 browser_agent

同时也支持自定义本地 agent 文件，通常放在：

.gemini/agents/~/.gemini/agents/

它和 Claude Code 一样，也支持通过 Markdown + YAML frontmatter 描述 agent。

Gemini CLI 的自定义 agent 可以声明 kind: local，并通过 tools 收窄工具范围；远程 subAgent 则使用 kind: remote，通过 A2A agent card 接入远程 agent。

但 Gemini CLI 的抽象更像：

主 Agent 拥有一组工具，其中某些工具本身就是 Agent。

这带来一个好处：工具边界比较清晰。

主 Agent 可以判断什么时候调用 codebase_investigator，也可以通过 @subagent 显式调用某个 agent。

Gemini CLI 还有一个很值得关注的方向：remote subagents / A2A。也就是 subAgent 不一定只在本地进程中，它可以通过 Agent-to-Agent 协议连接远程 Agent。

这让 Gemini CLI 的多 Agent 设计天然适合跨进程、跨服务协作。

一句话总结：

Gemini CLI subAgent 更像“可被主 Agent 调用的专家工具”，并且在远程 Agent 协作上留了很大空间。

七、四者对比：同样叫 subAgent，抽象层不同

把它们放在一起看，会发现差异很明显。

维度	Claude Code	Codex	OpenClaw	Gemini CLI
核心抽象	专家角色	并行工作流	后台 session	Agent 工具
配置方式	Markdown + YAML	TOML / 内置角色 / 调度 API	运行时配置 + session 管理	Markdown + YAML
触发方式	自动或显式调用	偏显式 spawn	显式后台启动	自动或 @agent
主要优势	可复用、可治理	并行探索和实现	运行时管理强	工具化和远程协作
典型场景	code review、安全审查、测试修复	多分支调研、并行实现	后台长任务、队列管理	专家工具调用、A2A 协作
协作方式	主要回报给主 Agent	主 Agent 编排汇总	主 session 管理多个后台 session	主 Agent 调用子 Agent 工具
成本特点	中等	取决于并行数量	取决于后台 session 数	取决于工具调用次数

如果用一句话区分：

• • Claude Code：把专家沉淀下来
• • Codex：把任务并行拆出去
• • OpenClaw：把 Agent 当后台任务管起来
• • Gemini CLI：把 Agent 当工具调用起来

八、先和 Agent teams 划清边界

这里需要先划清一个边界：Claude Code 的 Agent teams 是更上层的多 Agent 协作形态，而本篇讨论的 subAgent 仍然是“单会话内的任务委派”。

前者关注的是队员之间如何直接通信、如何共享任务看板、如何做横向协作；后者关注的是如何把某个局部任务拆给一个专门的专家去完成。

如果你已经读过我上一篇关于 Claude Code Agent teams 的文章，可以把本文理解为它的前置概念补充：Agent teams 讨论的是“多个 Agent 怎么协作”，而本文讨论的是“不同工具如何定义和调用 subAgent”。

九、不同场景怎么选？

可以用一个简单判断标准：任务越明确，越适合轻量 subAgent；任务越长、越需要运行时管理，越适合后台 session；任务越依赖远程协作，越适合 agent-as-tool 或 A2A。

Claude Code subAgent

如果你希望把团队经验沉淀成可复用角色，优先考虑 Claude Code subAgent。

典型场景：

• • code review
• • security review
• • test fixer
• • database migration reviewer
• • frontend accessibility checker

请让 code-reviewer 检查这次改动有没有 bug。

Codex subAgent

如果你要把一个复杂任务拆成多个并行分支，优先考虑 Codex subAgent。

典型场景：

• • 多个 explorer 并行读不同模块
• • 一个 worker 改实现，另一个 worker 补测试
• • 一个 agent 实现，另一个 agent 并行 review
• • 多个假设同时排查

请并行启动两个 explorer：一个调查订单状态流转，一个调查支付回调链路。最后由主 agent 汇总结论。

OpenClaw subAgent

如果任务需要长期后台运行、状态查看、日志追踪、并发队列或 kill/send 这类运维控制，优先考虑 OpenClaw subAgent。

典型场景：

• • 后台跑全仓库扫描
• • 同时处理多个 issue
• • 长时间测试和日志跟踪
• • 主会话继续调度，后台 agent 持续执行

启动一个后台 subagent 跑全量测试，并在完成后汇报失败用例摘要。

Gemini CLI subAgent

如果你更希望把专家 agent 当成工具来调用，或者希望连接远程 Agent，Gemini CLI 的 subAgent/A2A 思路更合适。

典型场景：

• • 主 Agent 自动调用 codebase_investigator
• • 用 @subagent 显式指定专家
• • 将远程 agent 作为能力接入 CLI
• • 把浏览器、代码库分析、CLI 帮助拆成独立 agent 工具

十、多 Agent 编程的几个实践建议

1. 不要为了“多”而多

多 Agent 最大的问题是协调成本。

如果任务本来就是线性的，比如：

读一个文件 -> 改一行代码 -> 跑一个测试

这时开多个 Agent 只会浪费 token。

多 Agent 适合的是“可以并行探索”的任务。

2. 明确文件所有权

如果多个 Agent 要改代码，一定要提前说清楚谁负责哪些文件。

比如：

Agent A 只负责 src/auth/。Agent B 只负责 tests/auth/。Agent C 只负责文档，不改实现代码。

否则多个 Agent 同时改同一个文件，容易产生冲突。

3. 主 Agent 要做收敛，不要只做转发

多 Agent 的价值不只是并行跑任务，而是最后要有一个高质量综合判断。

主 Agent 应该做这些事：

• • 比较各 Agent 的结论
• • 找出冲突点
• • 判断证据质量
• • 决定最终方案
• • 控制后续修改范围

否则多 Agent 只是把噪声放大。

4. 权限要尽量收窄

不要默认给所有 subAgent 全量工具权限。

比如 code reviewer 可能只需要：

• • Read
• • Grep
• • Glob

不一定需要 Bash，也不一定需要写文件权限。

测试修复 Agent 可能需要：

• • Read
• • Edit
• • Bash

数据库审查 Agent 可能只应该有只读权限。

subAgent 的一个重要价值就是权限隔离。如果所有 Agent 都拿全权限，这个价值就被削弱了。

5. 长任务更适合后台 session

如果任务会跑很久，比如：

• • 全仓库扫描
• • 大规模测试
• • 多模块迁移
• • 多 issue 并行处理

这类任务更适合 OpenClaw 这种后台 session 模型。

如果只是一次性问答或局部审查，用普通 subAgent 更轻。

十一、我的判断：subAgent 会成为 AI Coding 工具的基础设施

从这些工具的设计可以看到一个趋势：

AI Coding 正在从“单个聪明助手”走向“可编排的 Agent 系统”。

过去我们主要关心：

这个模型会不会写代码？

现在更需要关心：

这个系统能不能拆任务？能不能隔离上下文？能不能控制权限？能不能并行执行？能不能汇总结论？能不能处理多个 Agent 之间的边界？

这也是为什么 subAgent 重要。

它不是一个简单功能，而是 AI Coding 工具走向工程化的基础抽象。

不同工具现在走了不同路线：

• • Claude Code 在做专家角色
• • Codex 在做显式并行编排
• • OpenClaw 在做后台 session 和运行时管理
• • Gemini CLI 在做 agent-as-tool 和远程 Agent 协作

短期看，这些设计会继续分化。

长期看，它们可能会收敛到几个共同能力：

1. 1. Agent 配置标准化
2. 2. 工具权限最小化
3. 3. 上下文隔离
4. 4. 多 Agent 通信
5. 5. 任务队列和状态管理
6. 6. 可观测性和成本控制
7. 7. 人类审批与质量门禁

即将到来的 AI Coding 工具，可能不再只是一个聊天框，而是一个由多个专业 Agent 组成的工程协作环境。

假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。

接下来告诉你一条最快的邪修路线，

3个月即可成为模型大师，薪资直接起飞。

阶段1:大模型基础

阶段2:RAG应用开发工程

阶段3:大模型Agent应用架构

阶段4:大模型微调与私有化部署

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇