生产级 Agent 的 MCP 执行边界

TL;DR — MCP 让 Agent 接工具更标准，但它不会自动让工具执行变安全。生产级 Agent 还需要 runtime 边界：工具作用域、审批门、沙箱执行、步骤上限、网络规则、审计日志，以及在 loop 失控前刹车的机制。MCP 是连接层，执行边界是运行层。

MCP execution boundaries 会越来越重要，因为现在接工具已经不是最难的事了。真正麻烦的是：工具接上以后，Agent 到底能做什么，不能做什么，做到哪里必须停下来。

MCP 的价值很明确。它让 Agent 用标准方式发现工具、调用工具、拿回结果。MCP 官方介绍把它定义成连接 AI 应用和外部系统的协议，MCP tools 规范则说明 server 如何把可执行能力暴露给 client。

这很好，但还不够。

生产事故很少是“Agent 看不到工具”。更常见的是：Agent 看到了太多工具，调用了不该调用的工具，重复调用同一个工具，碰了不需要碰的数据，或者把代码跑在了不该跑的地方。

MCP 解决连接，不解决控制

更准确地说，MCP 是连接层。Server 暴露 tools，client 发现 tools，Agent 决定要不要调用，server 执行并返回结果。

这比每个 Agent 都手写一套工具集成干净得多。一个 MCP server 可以服务 IDE、桌面助手、内部应用和 hosted agent，不用到处复制粘贴。

但执行控制在更下面一层。

层级	它回答什么问题	它不回答什么问题
Function calling	模型如何请求一次工具调用	当前任务到底该暴露哪些工具
MCP	工具如何被打包、发现和调用	高风险操作应该在哪里执行
Runtime boundary	这次调用能碰什么、花多少、重复几次、改什么	Agent 应该追求哪个业务目标
Observability	这次运行到底发生了什么	下一次工具调用是否天然安全

我审 Agent 架构时也会这么拆。MCP 告诉我工具是怎么接进来的，runtime 边界告诉我工具被用坏以后系统能不能扛住。

如果你想先看协议层和模型层的区别，可以读 MCP vs Function Calling。这篇接着往下讲：工具已经接上以后，生产系统还缺什么。

生产 Agent 需要的 5 条边界

最容易犯的错，是把“工具权限”看成一个开关：Agent 要么有 GitHub 工具，要么没有；要么有 shell，要么没有。

这个粒度太粗了。

一个修 bug 的 Agent 可能需要读文件、跑测试、开 PR，但它大概率不需要删仓库、直接 push 到 main、读 billing 表，或者调用所有内部 admin API。一个处理客服工单的 Agent 可能需要读 CRM，但不该有退款权限。

我通常用 5 条边界来检查工具型 Agent。

边界	好的默认值	缺失后的问题
Tool scope	当前任务只加载必要工具	模型在一堆工具里瞎选
Execution scope	高风险执行放进沙箱或一次性 workspace	生成代码碰到 host 或共享状态
Network scope	默认禁网，需要时 allowlist	工具调用外传数据或下载未知代码
Mutation scope	写入、删除、付款、部署需要审批	建议直接变成不可逆操作
Loop scope	限制步骤、时间和预算	Agent 卡住后一直调用工具烧钱

你会发现，真正属于 MCP 本身的问题其实只有一小部分。其他都是 runtime 问题。

Tool Scope：不要把所有工具都塞给每个 Agent

最被低估的 Agent 安全手段，是让工具列表变短。

工具面太大有两个坏处。第一，schema 会吃掉 token。第二，模型更容易选到“语法上能用，但任务上不该用”的工具。

OpenAI Agents SDK 的工具文档现在也把工具选择看成 runtime 问题，而不是一个静态列表。文档里区分了 hosted tools、local runtime tools、function tools、agents as tools 和 hosted MCP tools，也提到了 tool search，让大工具面可以延迟加载，只在需要时进入上下文。

这个方向是对的：不要把整个公司工具目录一次性丢给模型。

一个很朴素的模式是这样：

type ToolPolicy = {
  taskType: "code-review" | "customer-support" | "data-analysis";
  allowedTools: string[];
  writeRequiresApproval: boolean;
  maxToolCalls: number;
};

const policies: Record<ToolPolicy["taskType"], ToolPolicy> = {
  "code-review": {
    taskType: "code-review",
    allowedTools: ["repo.read", "tests.run", "pull_request.comment"],
    writeRequiresApproval: true,
    maxToolCalls: 25,
  },
  "customer-support": {
    taskType: "customer-support",
    allowedTools: ["ticket.read", "crm.read", "docs.search"],
    writeRequiresApproval: true,
    maxToolCalls: 12,
  },
  "data-analysis": {
    taskType: "data-analysis",
    allowedTools: ["file.read", "python.run", "chart.render"],
    writeRequiresApproval: false,
    maxToolCalls: 20,
  },
};

export function allowedForTask(taskType: ToolPolicy["taskType"]) {
  return policies[taskType].allowedTools;
}

这段代码本身不复杂，重点也不在代码。重点是：工具暴露应该是每个任务的 policy 决策，而不是给每个 session 都挂一堆 server。

Execution Scope：Shell 不是普通工具

有些工具只是读取信息。搜文档、读文件、查工单。这些也需要权限控制，但破坏半径相对有限。

另一些工具会执行代码。

这条线非常关键。只要 Agent 能跑 shell、Python、浏览器自动化，或者能改仓库文件，你管理的就不只是模型行为，而是一个会修改真实环境的进程。

OpenAI Agents SDK 的工具文档把 local runtime tools 和 hosted tools 分开，也说明 hosted code execution 会跑在 sandboxed environment 里。这个区分很重要：执行应该发生在受控环境里，而不是和你的 secret、部署凭证、生产访问权限待在同一台可信主机上。

更稳的默认做法是：

• 只读工具可以靠近应用运行，但要做访问控制
• 代码执行进 sandbox
• 文件改动放进一次性 workspace
• 外部网络默认关闭，必要时 allowlist
• 持久凭证不要挂进执行环境

这也是为什么 自主 Agent 需要安全沙箱 不是一个边缘安全话题。沙箱就是工具执行变得可控的地方。

Mutation Scope：读和写要分开管

Agent 读一个 GitHub issue 然后总结，很有用。Agent 关闭 issue、推 commit、更新部署、给客户发邮件，也很有用。但这已经是完全不同的风险等级了。

把 mutation 单独看成一层权限。

生产系统里可以这么分：

动作类型	例子	默认策略
Read	搜文档、列 issue、看日志	在任务作用域内允许
Compute	跑测试、分析文件、渲染图表	允许，但放进 sandbox
Draft	生成 patch、写回复草稿	允许，但保持 staged
Mutate	push commit、更新工单、发邮件	需要审批或明确 policy
Irreversible	删除数据、扣款、部署生产	必须人工确认

这里最有意思的是 draft。Agent 应该能在审批前做很多事：准备 patch、解释 diff、写客户回复、生成迁移计划。审批应该卡在 staged work 变成外部状态的那一刻。

这样系统才不会变成每一步都弹窗，也不会把危险操作白给出去。

Loop Scope：会用工具的 Agent 必须有刹车

行业正在从 prompt 走向 loop，这个方向没错。Agent 只有能 plan、act、observe、retry，才会真正有用。

难看的部分是：带工具的 loop 很容易烧钱。

它通常不是爆炸式失败，而是很小的卡顿：

• 测试命令因为同一个原因一直失败
• Agent 来回改同一个文件
• 搜索工具返回噪音，Agent 继续搜
• MCP server 报错，Agent 试图再调另一个工具补救
• 模型不收窄任务，反而要求更多工具

这些都不戏剧化，但会消耗时间、token 和外部 API 配额。

每个 Agent loop 都需要硬刹车：

type LoopBudget = {
  maxSteps: number;
  maxToolCalls: number;
  maxWallClockMs: number;
  maxConsecutiveFailures: number;
};

export function shouldStop(run: {
  steps: number;
  toolCalls: number;
  startedAt: number;
  consecutiveFailures: number;
}, budget: LoopBudget) {
  const elapsed = Date.now() - run.startedAt;

  return (
    run.steps >= budget.maxSteps ||
    run.toolCalls >= budget.maxToolCalls ||
    elapsed >= budget.maxWallClockMs ||
    run.consecutiveFailures >= budget.maxConsecutiveFailures
  );
}

这类 guard 不酷，但凌晨两点 Agent 卡住的时候，它会很值钱。

如果你已经读过 生产级 AI Agent 为什么需要 Runtime 层，这里就是 runtime 最具体的落点之一。刹车应该长在 runtime 里。

Audit Scope：跑完之后要讲得清楚

没有审计日志的工具执行，很难建立信任。

生产 Agent 一旦开始行动，迟早会有人问：

• 它调用了哪个工具？
• 传了什么参数？
• 看到了哪些数据？
• 工具返回了什么？
• 哪条 policy 放行了这次调用？
• 有没有人工审批？
• loop 为什么停了？

如果答案只有“模型决定的”，这个系统还没准备好。

有用的 audit log 不只是原始文本，而应该围绕一次 run 结构化：

字段	为什么重要
run ID	把所有步骤串回同一个任务
tool name	看清用了哪个能力
arguments hash	不暴露 secret，也能追踪敏感输入
policy decision	解释 allow、deny 或 approval
sandbox ID	复现或检查执行上下文
token and time cost	排查预算问题
stop reason	知道任务是完成、失败，还是撞到限制

这就是 observability 变成产品质量的地方。开发者能检查发生了什么，才敢给 Agent 更多权限。

上线前的检查清单

在把一个 MCP-heavy agent 放给用户或内部团队之前，先问这些问题。

问题	好答案
这类任务加载哪些工具？	只加载工作流需要的工具
Agent 能跑代码吗？	可以，但只能在 sandbox 里跑
Agent 能访问外网吗？	默认禁止，或只走 allowlist
Agent 能改外部系统吗？	只能 staged draft，或走审批门
loop 怎么停？	步数、时间、失败次数和预算都有上限
记录什么日志？	工具调用、policy 决策、成本、stop reason
崩溃后怎么办？	状态可恢复，或者干净失败

不太舒服但很真实的一点是：如果这些问题答不上来，你的 MCP 集成还是 demo。它可能很精致，也用了正确的协议，但缺少生产 Agent 真正需要的运行层。

FAQ

MCP 自己会提供执行边界吗？

不会。MCP 标准化的是工具如何暴露和调用。沙箱、审批门、网络规则、预算、审计日志这些执行边界，属于 runtime 职责。

Tool search 能让 MCP 变安全吗？

Tool search 可以缩小模型看到的工具面，对 token 成本和工具选择都有帮助。但它不能替代 sandbox、权限检查、mutation 审批和 loop 上限。

每次 MCP 工具调用都要人工审批吗？

不用。只读和低风险计算可以在任务作用域内自动执行。审批应该卡在 mutation 边界，比如写入、删除、付款、生产部署和对外消息。

MCP 在生产 Agent 里最大的风险是什么？

最大的风险是把“工具连接”误以为“工具控制”。Agent 一旦能调用共享工具、运行代码或修改外部状态，runtime 就必须限制每个任务能碰什么、能跑多久。

SandBase 在这个架构里处在哪一层？

SandBase 关注的是 agent infrastructure layer，也就是 Agent workflow 下面那层：tool execution、sandboxing、model access、runtime policy 和 operational visibility 如何一起工作。

Key Takeaways

• MCP 是工具连接层，不是生产 Agent 的完整控制平面。
• 生产 Agent 需要围绕工具作用域、沙箱、网络访问、mutation、loop budget 和审计日志设计执行边界。
• 最稳的系统会按任务暴露更少工具，并把高风险执行放进一次性环境。
• 人工审批应该卡在 mutation 边界，而不是每个无害的读取和计算步骤。
• 只要 Agent 能在 loop 里调用工具，runtime 就必须有刹车，也必须记录为什么停下来。