从上下文工程到协议连接：DeepAgents 与 MCP 的技术耦合与工程逻辑

核心结论：DeepAgents 与 MCP 的组合，解决的不是“Agent 能不能调用工具”的问题，而是“长周期复杂任务中，Agent 如何在有限的上下文预算内，可靠地发现、选择和调用正确的工具”。前者通过虚拟文件系统、子代理隔离和分层压缩机制管理上下文这一稀缺资源，后者通过标准化协议将工具发现从“预加载清单”转变为“按需检索”。两者的协同逻辑，本质上是一套面向上下文稀缺性的资源调度架构。

上下文才是真正的稀缺资源

大语言模型的上下文窗口是一个硬约束。短对话无所谓，但当 Agent 执行长周期任务时，每一轮“调用工具→拿到结果→再思考”都会往历史中追加内容：读了哪些文件、跑了哪些命令、命令输出了多长的日志。几十轮之后，历史轻松膨胀到几十万 Token-1。撞上窗口上限会发生三件事：请求被拒绝、费用飙升、早期任务目标被截断导致 Agent“失忆”。

传统 Agent 框架对这个问题的回应通常是简单的截断或摘要。截断丢失信息，摘要丢失精度。DeepAgents 的设计选择了一条更工程化的路径：它没有重造压缩算法，而是复用了 LangChain 自带的压缩内核（“判阈值→选切点→切分→生成摘要”），自己只在外层加了四件长任务 Agent 真正需要的增强——旧历史落盘可回溯、压缩前先截大参数、超窗时自动兜底、非破坏式压缩保留原始对话-1。

这个设计的工程含义值得细读。它区分了两个不同的问题：“压缩什么”是一个算法问题，“压缩后能不能找回来”是一个架构问题。 DeepAgents 的答案是：压缩掉的消息不是删除，是归档到虚拟文件系统。Agent 需要时可以重新读取原始内容。

虚拟文件系统：上下文的外部化

DeepAgents 提供了一个基于插件的虚拟文件系统，通过 ls、read_file、write_file、edit_file、glob、grep 六个工具向 Agent 暴露-。Agent 可以将中间结果、长文本、代码和数据写入文件系统，而不是全部保留在上下文中。存储后端可以是内存、本地磁盘、LangGraph 状态存储，也可以是复合路由或自定义后端-。

Stripe 的生产实践提供了一个具体的参照。Kai 是 Stripe 用 Deep Agents 在一周内搭出的全员 AI 平台，四个月内用户从 296 涨到超过 5000，周活跃覆盖 83% 员工-29。Kai 是云端生产服务而非本地进程，Stripe 用 S3 搭建了虚拟文件系统，Agent 在处理文档和分析任务时可以跨会话读写引用文件，生成的报告和工件持久化在这层-29。

这个架构选择的技术含义是：上下文窗口从“唯一的工作空间”变成了“当前活跃工作区”，文件系统成为 Agent 的持久化存储层。 当 Agent 需要回顾三天前生成的代码时，它不需要将三天的对话历史全部保留在上下文中，只需要 read_file 读取之前写入的文件。

子代理隔离：上下文的分治策略

DeepAgents 的第二个上下文管理机制是子代理委派。主 Agent 通过内置的 task() 工具将任务委派给子代理，每个子代理在自己的上下文中独立运行，只将最终结果返回主代理-。这实现了上下文的隔离——一个子代理执行过程中产生的中间日志、工具调用记录和错误信息不会“污染”主代理的上下文。

一个研究协调器的参考实现清晰地展示了这种模式：协调器拥有零个自定义工具，它只能通过 task() 工具将工作委派给专业子代理。它不能直接搜索知识库或验证声明，必须通过委派来完成-。这个设计的教育含义在于：主 Agent 的上下文预算被保留给“决策”和“综合”，而非“执行”和“日志”。

在代码实现层面，DeepAgents 通过 create_deep_agent 暴露子代理配置。以下是一个成本优化的子代理配置示例：

from deepagents import create_deep_agent

# 主 Agent 使用强模型负责规划与综合，
# 子代理使用轻量模型负责执行密集型子任务
agent = create_deep_agent(
    model="anthropic:claude-sonnet-5",
    system_prompt="You are a research coordinator. Delegate all research to subagents.",
    subagents=[
        {
            "name": "researcher",
            "description": "Performs in-depth research on a given topic",
            "system_prompt": "You are a thorough researcher. Always cite sources.",
            "model": "anthropic:claude-haiku-4-5",
        },
        {
            "name": "reviewer",
            "description": "Reviews findings for accuracy and completeness",
            "system_prompt": "You are a critical reviewer. Flag unsupported claims.",
        },
    ],
)

这个配置传递了一个关键判断：上下文管理的经济学不仅是Token预算的管理，也是模型成本的管理。 让贵的模型做判断，让便宜的模型做执行，是 DeepAgents 子代理机制在企业场景中最直接的降本手段。

MCP：工具发现从“预加载清单”到“按需检索”

如果 DeepAgents 解决的是“上下文怎么管”，MCP 解决的是“工具怎么接”。MCP 由 Anthropic 在 2024 年底发布，到 2026 年已成为 AI 工具调用的事实标准-43。它的核心架构是一个客户端-服务器模式：MCP 服务器暴露 Tools（可被调用的函数）、Resources（可读取的数据源）和 Prompts（预定义的提示词模板），任何符合规范的客户端都可以调用-43。

用 FastMCP 框架，一个 MCP 服务器的实现可以非常简洁：

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("deploy-tools")

@mcp.tool()
def scale_deployment(service: str, replicas: int) -> str:
    """Scale a Kubernetes deployment to the specified number of replicas.

    Args:
        service: Name of the deployment to scale
        replicas: Target number of replicas
    """
    import subprocess
    result = subprocess.run(
        ["kubectl", "scale", "deployment", service, f"--replicas={replicas}"],
        capture_output=True, text=True
    )
    return f"Scaled {service} to {replicas} replicas: {result.stdout.strip()}"

这个 20 行的服务器将 kubectl scale 的能力标准化为一个 MCP 工具。任何支持 MCP 的 Agent 客户端——Claude、GPT、Gemini——都可以通过统一协议调用它，不需要为每个模型编写定制集成代码-43。

但 MCP 在企业场景中的真正价值不在于“写一次到处用”，而在于工具发现策略。Stripe 的 Kai 平台需要驾驭 500 多个内部 MCP 工具。把所有工具定义全部塞进上下文是不可能的——仅工具的结构定义就可能占掉数万 Token。Kai 的解法是技能驱动动态加载：每个技能封装一件事的完成方式，技能的 allowedTools 列表驱动工具按需拉起，上下文只装当次任务需要的东西-29。

这个模式的工程含义是：MCP 提供的是“工具可以被发现”的标准化接口，而“何时发现、发现多少”的策略由上层框架决定。 DeepAgents 的技能系统恰好承担了这层策略。

集成架构：DeepAgents 作为编排层，MCP 作为能力层

两者的集成逻辑可以用一句话概括：DeepAgents 是上下文的管理者，MCP 是工具的提供者。Agent 在需要工具时，通过 MCP 协议发现和调用；工具返回的结果，由 DeepAgents 决定是保留在上下文中还是写入文件系统。

一个企业级智能运维系统的参考架构展示了这种集成方式。诊断 Agent 基于 DeepAgents 负责根因分析

from deepagents import DeepAgent, AgentConfig, MemoryConfig
from deepagents.tools import ToolRegistry

class EnterpriseDeepAgent:
    def __init__(self, agent_name: str, system_prompt: str, tools: list):
        self.memory = MemoryConfig(
            type="vector",
            embedding_model="text-embedding-3-small",
            vector_store_path=f"./memory/{agent_name}"
        )
        self.config = AgentConfig(
            max_iterations=15,
            plan_reflect_interval=3,  # 每3步自我反思
            token_budget=8000,
            memory=self.memory
        )
        self.agent = DeepAgent(
            name=agent_name,
            system_prompt=system_prompt,
            tools=ToolRegistry(tools),
            config=self.config
        )
        self.agent.enable_checkpoint(path=f"./checkpoints/{agent_name}")

    async def run(self, task: str, context: dict = None) -> dict:
        result = await self.agent.invoke(
            input=task,
            context=context or {},
            include_plan=True,
            include_reflections=True
        )
        return {
            "final_answer": result.final_output,
            "plan_trace": result.plan_steps,
            "tool_calls": result.tool_call_log,
        }

max_iterations=15 限制了 Agent 的推理步数，防止无限循环消耗 Token；token_budget=8000 设定了上下文的硬预算；plan_reflect_interval=3 让 Agent 每三步做一次自我反思，相当于在上下文管理中插入检查点-25。

生产部署的关键约束

Stripe 的实践揭示了一个容易被低估的工程细节：技能的 frontmatter 有 1024 字符限制，团队发现前沿模型在技能超过 150 个时性能开始下降-29。这意味着技能数量的增长不是线性的——每增加一个技能，Agent 的选择负担会增加，误选概率会上升。

这个约束对架构设计的影响是结构性的。一个可行的策略是分层技能：基础 Agent 携带一组覆盖导航、文档和基础数据查询的通用技能，专业团队维护自己的领域技能，通过 allowedTools 的隔离机制控制加载范围-29。

另一个约束来自安全层面。MCP 规范明确要求：服务器不得使用表单模式请求密码、API 密钥等敏感信息，必须使用 URL 模式处理此类交互-。MCP 客户端必须验证令牌的受众声明，只接受专为自己签发的令牌-。这些要求在企业部署中不是可选的加固步骤，而是信任模型的组成部分。

工程判断力的边界

DeepAgents 与 MCP 的组合提供了一套可运行的起点架构：上下文由虚拟文件系统和压缩中间件管理，工具由 MCP 协议标准化接入，子代理提供上下文隔离和能力分工。但这套架构的有效性取决于一个无法通过文档获得的能力——判断“什么内容应该写入文件、什么应该保留在上下文、什么应该在压缩时归档”的工程直觉。

一个具体的例子：当 Agent 读取一份 5000 行的配置文件时，应该将完整内容写入文件系统并在上下文中只保留摘要，还是直接将内容放入上下文以便后续推理？前者的风险是 Agent 可能“忘记”文件里有什么，后者的风险是单次读取就消耗了数千 Token。这个判断没有标准答案，取决于任务的性质、后续推理的需求和上下文预算的紧张程度。

Stripe 的 Kai 平台将 Deep Agents 定位为“解决所有非 Stripe 问题的基座”，让团队专注解决“Stripe 问题”-29。这个定位的潜台词是：框架解决的是通用的上下文管理和工具接入问题，但领域判断——什么工具在什么条件下应该被调用、什么结果应该被信任——仍然需要由理解业务的人来定义。