上下文灾难有救了，Claude Sub-Agent的隐藏功能，99%的开发者还没发现

Claude Code中的Sub Agents是专门化的AI助手，可以被调用来处理特定类型的任务。它们通过提供具有自定义系统提示、工具和独立上下文窗口的任务特定配置，从而实现更高效的问题解决。—Anthropic

Sub Agents的出现解决了当前AI编程的一个最重要的问题：通过“角色化”和“隔离化”，解决了“单体通用型AI”在复杂、多阶段开发任务中的“上下文失控”和“目标不确定性”问题。这对于用AI开发大型项目的用户，具有重大意义。

传统AI编程的困境

您有没有遇到过这样的情况？正在用AI助手开发项目，前面已经讨论了文档编写、架构设计、代码实现等一大堆内容，结果代码出了个小bug，您让AI修复，它却莫名其妙地重写了整个模块，导致后面越改越错，甚至不得不回滚。这不是现在的模型不够聪明，而是传统AI编程工具的根本缺陷，让一个AI承担所有工作任务。就像盖房子您只聘请一个工程师，让人家既要拌水泥又要焊接钢筋，还要负责电路设计，结果可想而知，难免忙中出错。

上下文混乱的真实代价

从"上下文管理混乱"到"上下文精确隔离"

过去，我们试图在一个巨大的房间里（单一上下文窗口）整理所有的工具和材料，结果必然是混乱的。Sub Agents的做法是： 不再整理那个大房间，而是直接建立多个独立的、功能专一的"工作室"。

• 测试工作室 (Testing Agent)：这里只有测试框架、断言库和待测代码。它看不到也不关心项目的整体架构或文档。当您把bug信息扔进这个工作室，它的唯一目标就是让测试通过。
• 架构工作室 (Architect Agent)：这里只有项目蓝图、设计模式和高阶需求。它甚至没有修改代码的"工具"（权限），所以它永远不会"越俎代庖"去写代码。

这种隔离 (Isolation) 机制，从根本上杜绝了"上下文污染"。

从"角色混淆"到"角色焊定"

过去的AI就像一个什么都懂一点，但没有职业操守的"通才"。你让他当测试员，他干着干着就想去做架构师的活。Sub Agents的做法是： 为每个AI代理"焊定"一个不可动摇的职业角色。这个角色由三样东西共同定义：

• 系统提示 (System Prompt): "你是一个只负责编写和修复测试的专家，绝不触碰业务逻辑。"，这是它的职业信条。
• 可用工具 (Tools): 只给它运行测试和读写测试文件的权限。这是它的工具箱，想干别的也没工具。
• 独立上下文 (Separate Context): 它的记忆里只有和测试相关的事情。这是它的专业领域知识。

这确保了AI的行为是可预测和可靠的。您不再需要"提醒"它，因为它的"DNA"决定了它只能做什么。

从"人机对话"到"人领导的AI团队"

这改变了开发者与AI的协作方式。

• 过去：您像一个监工，不断地对一个全能但混乱的工人下达指令、纠正偏差。
• 现在：您可以像一个项目经理或技术总监，将任务清晰地委派 (Delegate) 给手下的专家团队。您说"Debug Agents，修复这个"，它就去执行测试任务；您说"架构Agents，评估这个方案"，它就给出架构建议。

快速上手：创建您的第一个Sub Agent

使用Sub Agents非常简单。您只需要运行/agents命令，选择"Create New Agent"，然后描述这个代理的用途和使用场景。系统会自动生成基础配置，您也可以手动调整。比如创建一个测试专家代理，描述为"专门运行测试并修复失败用例"，选择相应的工具权限，保存后就可以使用了。整个过程不超过几分钟，但带来的效率提升是显著的。

文件存储：项目级与用户级的灵活管理

Sub Agents以Markdown文件形式存储，支持两种级别：项目级（.claude/agents/）和用户级（~/.claude/agents/）。项目级代理只在当前项目中可用，适合特定项目的专门需求；用户级代理可以跨项目使用，适合通用的开发任务。当名称冲突时，项目级代理优先级更高，这样您可以为特定项目定制专门的代理行为。

第一步：定义代理名称与能力 (Define Name & Capabilities)

首先，您需要给代理起一个独一无二的名称，这是它的唯一标识符(ID)，也是您日后调用它的“名字”。名字应该简洁且能反映其功能。

• 代理名称 (Agent Name): requirements-analyst

第二步：撰写系统提示词 (Write the System Prompt)

系统提示词是代理的“灵魂”和“行动纲领”。它用自然语言定义了代理的角色、目标、工作流程和所有必须遵守的规则。一个好的提示词是确保代理表现符合预期的关键。

接下来是至关重要的一步：选择工具 (Select Tools)。这一步决定了您的代理“能做什么”和“不能做什么”，是其角色和安全性的基础。它现在默认是全选，在使用时建议您仔细看一下。

• 工具权限 (Tool Permissions): 对于一个只负责审查代码的代理，我们不希望它有修改文件或执行命令的权限。因此，我们应该只授予它读取文件(Read File Access)的权限。这样就从根本上杜绝了它“越界”修改代码的可能，确保了它的专注和安全。

第三步：教授调用指令 (Teach the Invocation Command)

最后一步是告诉Claude Code如何以及何时使用这个新代理。这就像是为它设定一个“唤醒词”或“触发指令”。当您的请求匹配这个模式时，Claude Code就会智能地将任务委派给它。

• 如何使用 (How to Use):

> 使用 requirements-analyst 代理为我定义 [功能想法] 的需求。

通过这三个步骤——定义名称与能力、撰写核心指令、教授调用方式——您就完成了一个专家代理的完整定义。保存后，这个code-reviewer便成为了您AI团队中随时待命的一员。当您需要审查代码时，只需一声令下，这位“专家”就会立刻上岗，提供专注而高质量的服务。

显式调用：精确控制的灵活性

有时候您需要精确控制使用哪个代理。比如"用代码审查代理检查我的最新修改"，或者"让调试代理分析这个测试失败"。这种显式调用方式让您可以根据具体情况选择最合适的专家，而不依赖系统的自动判断。特别是在复杂场景下，这种精确控制能力非常有价值。

链式调用：复杂工作流的优雅解决方案

对于复杂任务，您可以链式调用多个Sub Agent。比如"先用代码分析代理找出性能问题，然后用优化代理修复它们"。这种协作模式让不同专家按顺序处理复杂任务，每个代理都专注于自己最擅长的部分。结果是更高的准确性和更好的最终质量。

性能考量：效率与延迟的平衡

Sub Agents在提高上下文效率的同时，也带来了一些延迟。每次调用新代理时，它需要从零开始收集必要的上下文信息。不过这种延迟是值得的，因为专业化的代理能够更准确地完成任务，减少了来回修正的时间成本。而且独立的上下文让主对话保持清晰，支持更长时间的开发会话。

写在最后

这次Claude code的更新并非简单地追求更快的代码生成速度，而是关乎于“控制权”与“创造力”的回归。过去，我们像一个疲惫的监工，不断地纠正一个全能但混乱的AI工人的错误；而现在，我们成为了AI专家团队的“架构师”与“指挥官”，将我们的精力从繁琐的微观管理中解放出来，重新聚焦于最高层次的战略思考、创新设计和复杂问题的决策。 这不仅仅是工具的进化，更是开发者自身角色的一次深刻演进：我们不再是AI的“指令工”，而是驾驭AI、放大自身智慧的“领导者”。

文章中三个Sub Agent的系统提示词是我根据上一篇文章《上下文工程难吗？试下Claude Code写入Kiro的Spec，自动搞定上下文》 Kiro的System Prompt改写而来。本周我会分享在我的Agent开发交流群中，欢迎您来一起讨论！

另外我发现了一个宝藏级的GitHub仓库，里面汇集了大量为Sub Agent量身定制的System Prompt，覆盖了UI/UX设计、深度调试、数据库管理等多个专业领域，地址我分享在这里，https://github.com/wshobson/agents 感兴趣的朋友可以去试一下。

文章来自公众号“Al修猫Prompt”