多智能体架构不必很复杂。Deep Agents 的设计哲学是用正确的抽象（中间件处理管道、工具调用处理调用）把这些模式变成可以自由组合的简单构建块。
构建真正能用的 AI Agent 系统，最有效的方法之一就是把复杂任务拆解给多个专业化的智能体来协作完成。但随之而来的一个棘手问题是：当一个 Agent 执行大量工具调用时，上下文窗口会迅速被中间结果填满，导致模型性能急剧下降。
LangChain 团队新推出的 Deep Agents 框架用两个简洁的核心原语解决了这个问题：subagents（子智能体）用于上下文隔离，skills（技能）用于能力的渐进式披露。
上下文膨胀：Agent 工程的隐形杀手
在 Agent 工程实践中，有一个被广泛观察到但很少被正式讨论的现象：当 Agent 的上下文窗口逐渐填满时，模型完成任务的能力会显著下降。
Chroma 团队将这种现象称为"context rot"（上下文腐化），而 HumanLayer 团队则更形象地把这种高上下文区域叫做"dumb zone"（愚蠢区）。
想象一下这个场景：你的 Agent 需要完成一个复杂的研究任务，过程中进行了几十次网页搜索和文件读取。每一次工具调用的返回结果都会累积在上下文中，很快你就会发现 Agent 开始"犯傻"——它可能会重复之前做过的操作，或者在已经找到答案的情况下继续无意义地搜索。
这不是模型本身的问题，而是架构设计的问题。当上下文被大量中间结果污染时，真正重要的信息反而被淹没了。
Subagents：隔离上下文的专业工人
Subagents 的核心思想非常直观：让子智能体在独立的上下文窗口中运行，主智能体只接收最终结果，而不是过程中的所有中间步骤。
如果子智能体做了 20 次工具调用才得出结论，主智能体只会看到那个结论，而不是那 20 次调用的详细记录。
什么时候应该使用 subagents？以下几种场景特别适合：
•保护上下文- 需要多步骤操作的任务（比如代码库探索）会产生大量中间结果，用 subagent 隔离可以保持主智能体的上下文清爽
•专业分工- 不同团队可以开发专注于不同垂直领域的 subagent，各自有特定的指令和工具集
•多模型协作- subagent 可以使用与主智能体不同的模型，比如用更小的模型来换取更低的延迟
•并行执行- 多个 subagent 可以同时运行，各自完成任务后将结果汇报给主智能体，大幅降低整体延迟
在 Deep Agents 中创建 subagent 非常简单，只需要定义一个字典并传给 create_deep_agent() 函数：
research_subagent = { "name": "research-agent", "description": "深度研究问题并综合发现", "system_prompt": "你是一位优秀的研究员...", "tools": [internet_search], "model": "openai:gpt-4o" }Deep Agents 还内置了一个通用型 subagent，它继承主智能体的所有能力（相同的系统提示、工具和模型），专门用于上下文隔离而不需要特殊行为。
举个例子：主智能体不需要自己做 10 次网页搜索把上下文填满，而是可以把任务委托给通用 subagent，后者在内部完成所有搜索后只返回一个简洁的摘要。
Subagent 的最佳实践
写好描述是关键。主智能体根据 description 来决定调用哪个 subagent，所以描述必须清晰准确。
好的写法："分析财务数据并生成带有置信度评分的投资洞察"
差的写法："做金融相关的事情"
系统提示要详细。包含工具使用指南和输出格式要求，比如明确告诉 subagent 应该如何组织研究结果，需要引用来源，输出要控制在多少字以内来保持上下文整洁。
工具集要精简。只给 subagent 分配它真正需要的工具。一个专门发邮件的 agent 只需要 send_email 和 validate_email，给它加上 web_search、database_query、file_upload 就是在增加不必要的复杂性。
Skills：能力的渐进式披露
Skills 提供了另一种模式来解决上下文膨胀问题。
传统做法是在初始化时就把几十个工具全部塞进 Agent 的上下文，这会占用大量的 token 预算。Skills 的思路是"渐进式披露"：Agent 启动时只能看到技能的名称和描述，只有当它决定需要某个技能时，才会读取完整的指令。
Skills 使用 agentskills.io 规范，结构非常清晰。你只需要在指定目录下创建 SKILL.md 文件，包含 YAML 格式的元数据和 Markdown 格式的详细指令：
--- name: deploy description: 部署到生产环境 version: 1.0.0 --- # 部署到生产环境当用户要求部署时，执行以下步骤：
1. 运行测试：`npm test`
2. 构建应用：`npm run build`
3. 部署到生产：`npm run deploy:prod`
4. 验证部署：检查健康检查端点
这种设计的好处是显而易见的：技能描述会预加载到上下文中（占用很少的 token），而技能的完整内容只在 Agent 决定需要时才加载。这让你可以定义大量的能力而不用担心初始上下文爆炸。
如何选择：Subagents 还是 Skills？
这两种模式各有适用场景，而且完全可以组合使用：
•委托复杂的多步骤工作→ 用 subagents 做上下文隔离
•复用流程或指令→ 用 skills 做渐进式披露
•为特定任务提供专业工具→ subagents + 精简的工具集
•跨多个 Agent 共享能力→ skills，因为它们本质上就是文件
•工具集很大→ 用 skills 避免 token 膨胀
这不是非此即彼的选择。很多系统会同时使用两者：skills 定义流程，subagents 执行复杂的多步骤工作。你的 subagents 甚至可以使用 skills 来有效管理它们自己的上下文窗口。
写在最后
多智能体架构不必很复杂。Deep Agents 的设计哲学是用正确的抽象（中间件处理管道、工具调用处理调用）把这些模式变成可以自由组合的简单构建块。
从 subagents 开始做上下文管理，加入 skills 做渐进式披露，然后在此基础上根据需求扩展。记住核心原则：主智能体的上下文是宝贵资源，要像管理内存一样谨慎管理它。
