05_Claude Code之Agent（智能体）系统：从Subagents到多智能体团队

05 Claude Code之Agent智能体系统从Subagents到多智能体团队Claude Code 的智能体能力分为三个层次内置子代理、自定义 Subagents、Agent Teams。本文深度解析每个层次的设计理念、使用场景和最佳实践提供真实的生产力数据重构任务从4小时缩短到1.5小时并详细讲解 Test-time Compute 的批评者-行动者框架。掌握这套分层体系让 Claude Code 从单点工具升级为真正的并行开发引擎。关键字Claude Code Agent、Subagents、Agent Teams、多智能体协作、Test-time Compute、并行开发、上下文隔离、任务分解标签Claude Code多智能体Agent TeamsSubagents并行开发AI协作智能体编程写在前面当我第一次接触 Agent Teams 的概念时第一反应是听起来很炫实际有什么用然后有一次做大型重构任务代码库里有 20 多个模块需要同步更新接口签名。单个 Claude 实例做这件事不是不行而是又慢又容易出错——做到第 15 个模块时前面的细节已经开始模糊了。尝试用 Agent Teams 之后5 个 Claude 实例同时工作一个分析依赖关系生成计划四个各负责 5-6 个模块。这次任务从预估的 4 小时变成了 1.5 小时更重要的是每个实例的上下文都很干净错误率明显更低。智能体系统不是 “cool feature”是解决特定规模问题的工程工具。一、智能体系统全景Claude Code 的智能体能力分三个层次 | Claude Code 智能体系统 | | | | [层次三Agent Teams] | | 多实例并行协作 | | 共享任务列表 直接消息通信 | | 适合大规模并行任务 | | | | [层次二Subagents] | | 主上下文调用的从属智能体 | | 独立上下文结果汇报 | | 适合保持主上下文清洁 | | | | [层次一内置子代理] | | Explore快速文件搜索 | | Plan只读分析 | | 系统自动调用 | | | 从下往上能力越来越强复杂度也越来越高。二、内置子代理你每天都在用但没注意Claude Code 有两个内置的子代理会在日常使用中自动调用Explore 子代理基于 Haiku 模型触发时机需要快速搜索文件、查找函数定义特点速度快、成本低专门用于文件系统探索效果你让 Claude “找一下项目里所有的 TODO 注释”背后就是 Explore 在工作Plan 子代理只读模式触发时机Plan Mode 下分析任务特点只读访问不能修改任何文件效果在执行前提供安全的沙盒分析这两个是系统自动调度的无需手动配置。三、自定义 Subagents除了内置子代理你可以创建自己的专用子代理。配置文件放在.claude/agents/目录# .claude/agents/security-auditor.ymlname:security-auditordescription:专门进行安全审计检查代码中的安全漏洞、敏感信息泄露、权限问题model:claude-sonnet-4-6allowed-tools:-Read-Grep-Bash(grep-r*)-Bash(git log*)system-prompt:|你是一个资深安全工程师专门进行代码安全审计。 审查重点 1. OWASP Top 10 漏洞 2. 硬编码密钥/密码 3. SQL注入和XSS风险 4. 认证授权缺陷 5. 依赖包已知漏洞输出格式严重性Critical/High/Medium/Low 位置 修复建议 只报告实际问题不要误报宁可漏报不要误报。使用方式# 在会话中调用自定义子代理用 security-auditor 审查 src/auth/ 目录# 或者通过 CLIclaude--agentsecurity-auditor审查整个项目的安全问题子代理完成工作后只把结果摘要返回给主会话主上下文不会被大量中间过程填充。这是保持主上下文清洁的核心机制。四、Agent Teams多智能体并行协作Agent Teams 是实验性功能也是 Claude Code 最有野心的特性之一。启用方式// ~/.claude/settings.json 或 .claude/settings.json{env:{CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS:1}}或者临时启用exportCLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS1claudeAgent Teams 的核心架构------------------ | Team Lead | ← 你交互的主实例 | (主Claude) | ← 负责协调和分配任务 ------------------ | | 创建团队分配任务 | ------------------------ | | | | ----------------------------- |Queue1 ||Queue2 ||Queue3 ||Queue4 | |队友1 ||队友2 ||队友3 ||队友4 | ----------------------------- 独立上下文 独立上下文 独立上下文 独立上下文 所有队友共享任务列表可直接互发消息创建团队的对话你: 需要给项目添加完整的日志系统涉及前端、后端、数据库和监控四个部分 请创建一个4人团队并行处理 Claude: 我来创建一个4人团队来处理日志系统 - 队友1前端日志集成React组件错误边界和用户行为追踪 - 队友2后端日志框架结构化日志、请求追踪、性能指标 - 队友3数据库查询日志慢查询、事务日志 - 队友4监控集成Prometheus指标导出、告警规则 是否创建这个团队[确认/调整]Claude 会建议团队结构你确认后开始执行。Subagents vs Agent Teams如何选择这两种方式很容易混淆用一个决策框架来区分任务特征 | -- 任务结果只需要汇总 → 使用 Subagents | 例读取10个文件总结关键信息 | -- 任务需要并行修改代码 → 使用 Agent Teams | 例重构10个模块各自独立但需要协调接口 | -- 任务需要讨论和审查 → 使用 Agent Teams | 例一个实现一个审查互相交流 | -- 主上下文需要保持干净 → 使用 Subagents 例在主任务中调用安全审查不想被冗长报告填充维度SubagentsAgent Teams上下文子代理结果汇总到主上下文每个队友完全独立上下文通信只向主代理报告队友间可直接通信Token 成本较低随队友数量线性增长文件冲突不存在需要明确划分文件边界适用规模中等复杂任务大型并行任务五、Test-time Compute用质量换时间Test-time Compute 是一个有点学术的叫法实际含义是让多个 Claude 实例独立处理同一个问题然后比较或综合结果。最实用的应用场景是代码审查# 会话A实现功能claude-nimpl实现用户权限管理模块# 会话B审查功能用全新的上下文没有实现时的先入为主claude-nreview审查 feature/auth 分支的实现找出潜在问题为什么不用同一个 Claude 做实现审查因为实现者会对自己的代码有认知偏差——知道我是按什么思路写的会下意识跳过某些检查。用独立的新鲜上下文审查能发现更多真实问题。这本质上是多智能体强化学习中批评者-行动者框架的工程化应用。六、Agent Teams 最佳实践从实际使用中总结的关键经验1. 明确文件边界避免冲突# 好的任务分配按文件/目录划分 队友1: src/frontend/ 队友2: src/backend/api/ 队友3: src/backend/services/ 队友4: src/database/ # 不好的任务分配按功能划分多个队友会改同一文件 队友1: 添加缓存功能可能改多个层 队友2: 优化数据库查询可能改相同服务2. 团队规模控制在 3-5 人超过 5 个队友协调开销会超过并行收益。经验值简单并行任务2-3 人中等复杂任务4-5 人单任务研究审查2 人一写一审3. 先做研究任务再做并行实现错误顺序 直接让5个队友并行写代码 → 架构不一致需要大量重工 正确顺序 1. 派1个队友做全面分析不修改文件 2. 团队领导整合分析结果制定统一接口规范 3. 4个队友按规范并行实现4. 使用 Hooks 强制质量门{hooks:{TeammateIdle:[{hooks:[{type:command,command:.claude/hooks/validate-teammate-output.sh}]}]}}总结Claude Code 的智能体系统是分层设计的内置子代理自动调度日用透明自定义 Subagents专业化隔离保护主上下文Agent Teams真正的并行协作解决规模问题关键原则不要因为功能存在而使用它要因为问题适合而使用它。单实例能搞定的任务不需要 Agent Teams。但当任务规模超过单上下文能高质量处理的边界时智能体系统就是工程级解法。