Claude Code最新放出的子代理（Sub Agent）功能，让单个AI会话能同时跑多个专职助手。实测中，一个代码审查子代理独立完成任务后，主会话的上下文窗口几乎零污染——这对被长对话搞崩过项目的开发者来说，相当于从合租公寓搬进了独栋别墅。
子代理是什么：给AI配了独立工位
Claude Code的主会话像项目经理，子代理则是按技能招的专员。每个子代理自带三件事：独立的上下文窗口、专属系统提示词、受限的工具权限。
原文档打了个比方：主会话是"总经理"，子代理是"团队成员"。总经理派活，专员干完交报告，不往会议室白板上乱画。这个设计的精妙在于，探索性任务（比如翻遍整个代码库找漏洞）不会把主会话的上下文撑爆。
具体能限制到什么程度？代码审查代理可以只开"只读"权限，写代码的代理才给"写入/编辑"权限。最小权限原则从网络安全领域搬进了AI协作。
为什么需要：三个真实痛点
上下文保护是头号需求。让AI分析一个十万行代码的项目，传统做法是全部塞进对话历史，结果没聊几句就触发上下文截断。子代理把脏活累活揽走，只返给主会话一份摘要。
专业化是第二个钩子。代码审查、测试生成、安全分析，每种任务需要不同的"人格"。代码审查员要挑剔，测试工程师要周全，安全审计要 paranoid（偏执）——这些角色用同一套系统提示词很难兼顾。
权限管控解决的是信任问题。Anthropic 的工程师在文档里没明说，但这个设计明显在回应企业客户的担忧：让AI自动改生产代码？先给它戴个只读手铐看看表现。
复用性则是长期主义。一个配置好的子代理存成文件，所有项目都能调用。个人配置扔在 ~/.claude/agents/，项目专属配置放在 .claude/agents/，粒度控制到文件夹级别。
怎么用：两条路径，一种格式
Claude Code内置了一批子代理，用户不用管，系统根据任务类型自动委派。想查看或手动调用，命令行输 /agents 会弹出交互菜单。
创建自定义代理有两种方式。懒人路线：在 /agents 菜单里选"Create new agent" → "Generate with Claude"，用自然语言描述需求，比如"从可读性、性能、最佳实践三个维度分析代码并提改进建议"，然后勾选权限、选模型、保存。
极客路线：直接写Markdown文件。文件结构很简单——顶部是YAML frontmatter定义元数据，下面是系统提示词正文。文档示例里，一个代码审查代理的配置包括：名称、描述、模型选择、工具权限列表、以及详细的角色设定。
验证配置是否生效也有两条路。会话外跑 claude agents 看全局列表，会话内敲 /agents 看当前可用的。项目级代理会覆盖个人级同名配置，这个优先级规则没写在显眼位置，但实测如此。
一个值得玩味的细节
文档在"内置子代理"章节特意强调：用户不需要直接调用它们，系统会自动选择。这个"自动委派"的机制没展开讲，但结合Anthropic最近强调的"AI系统自主性"，子代理很可能是Claude Code向多智能体系统演进的伏笔。
目前子代理的模型选择还局限在Claude家族内部（Sonnet、Haiku等），工具权限也是预设清单勾选。但架构上已经留好了扩展接口——Markdown配置文件的格式，本质上是在定义一个可插拔的Agent协议。
有开发者在Hacker News上反馈，用子代理跑代码审查后，主会话的可用上下文长度从经常告警变成了游刃有余。这个数据点来自社区，官方没给基准测试，但"上下文零污染"的设计目标确实击中了RAG（检索增强生成）之外的另一条技术路线。
Claude Code的子代理功能目前处于公开测试阶段，配置文件的字段列表还在迭代。如果你已经用上了，一个值得观察的问题是：当你的子代理配置超过10个，/agents 菜单的交互效率会不会成为新瓶颈？
热门跟贴