代理工具的问题及DigitalOcean的Action Gateway如何解决

你构建一个代理，连接几个工具，并在测试用例上运行它。它预约会议、创建工单、更新记录。演示顺利进行。但随后它面对生产流量，一周内你就会看到转录：代理连续十一次调用同一个损坏的端点，虚构了一个不存在的customer_id，并将 40,000 个原始 JSON 令牌粘贴到自身上下文中，直至丢失线索。

工具调用看似已解决，因为单轮基准表明如此：给模型一个干净的工具和一个清晰的请求，它会以高准确率发出格式正确的调用。但代理并不在单轮中运行。它们会在不断变化的 API、流动的状态、即将过期的凭据以及可能具有敌意的输入上运行循环（调用工具、读取结果、决策、再次调用）。τ-bench（Yao 等人，Sierra，2024）在真实的多轮客服任务上测试代理，发现 GPT-4o 在首次尝试时仅完成约 61% 的零售任务和 35% 的航空任务。若要求在同一任务上连续成功八次（即 pass^8 指标，可粗略视为“你会部署这个吗？”），可靠性会降至约 25%。

如果你以前没有连接过工具，这里有一些背景：从模型的角度来看，一个“工具”是一个 JSON 模式（名称、描述和类型化的参数），它被注入到上下文窗口中。模型会发出结构化调用，你的运行时会在真实 API 上执行该调用，然后将原始响应追加回上下文。下面提到的每个问题都出现在这个循环中的某个环节。

本文将按照三类将循环中最常见的断裂方式进行梳理：集成与数据摩擦、执行与可靠性故障、安全与治理风险。每个问题都附有其背后的定量证据、用于定位自身代理的简短诊断以及优先级排序的修复方案。这些修复方案汇聚到一种架构模式上——即代理与其工具之间的受管层，因此后续章节会将DigitalOcean 的 Action Gateway（该层作为托管服务提供，目前处于公开预览）与每种失效模式进行映射，并坦率地说明它能解决什么、不能解决什么。

TL;DR

函数调用准确性并不等同于工作流可靠性。 模型可能在一次轮次中产生有效调用，但在更长的序列中仍可能失败：在 τ-bench 中，GPT-4o 在零售任务上的成功率从一次尝试的约 61% 下降到同一任务需要连续成功八次时的约 25%。
集成失败往往源于模型之外。 生产系统必须将过时的模式、变化的记录、过期的凭证以及超大的 API 响应视为基础设施问题来处理，而不是期望代理自行补偿这些问题。
工具越多可能反而让代理能力下降。 大型目录会占用上下文并使相似功能混淆，而检索一个小而特定于任务的简短列表则能为模型提供更窄且更相关的选择集。
重试需要显式的安全控制。 错误应描述失败情况以及恢复是否安全，同时有限重试、幂等键和最终状态检查可以防止循环和重复写入。
工具输出是不可信的输入。 因为恶意指令可能通过电子邮件、网页、问题或数据库记录注入，因此需要最小权限凭证和每次调用的狭窄范围，以限制提示注入造成的损害。
人工批准应针对后果重大的操作。 有效的审批门户应聚焦于支付、删除、外部通信及其他高风险变更，同时为审查者提供足够的上下文并记录他们的决定。
受管控的中介层能够解决提示无法处理的问题。 集中进行验证、工具发现、凭证经纪、权限管理、审批和审计，能够在代理及其 API 之间形成一致的执行点。
DigitalOcean Action Gateway 提供了此中介层的大部分功能，但并非全部。 它集中管理常用控制并减少目录膨胀，但应用仍需自行处理状态一致性、幂等写入、严格的自定义模式以及语义结果验证。

什么是 DigitalOcean 托管代理？

DigitalOcean 托管代理由两个托管部分组成。一个部分运行您的代理。另一个部分让您的代理能够在其他产品中操作。它目前处于公开预览。

Harness Runtime 运行代理。 您可以直接使用您已有的代理，无需修改：Claude Code、Codex、OpenCode、Hermes、一个 LangGraph 应用，或您自己的 OCI 镜像。每次运行都会获得一个带有 shell、编码沙盒和浏览器的独立 Firecracker 微型虚拟机，平台会在会话之间保持工作区和对话。您可以暂停、恢复、检查点并分叉会话，按计划或通过 webhook 运行，并设置权限策略，决定哪些操作自行运行，哪些需要人工干预，哪些被拒绝。只有在会话实际执行工作时才会产生费用。

Action Gateway 决定代理在其他系统中可以执行哪些操作。 它是一个托管的 MCP 端点，位于 16,000+ 个工具之前：包括 GitHub、Jira、Stripe、PagerDuty、Notion、Postgres 等的连接器，DigitalOcean 维护的工具如网页搜索、网页获取和浏览器自动化，以及您自己注册的任何 MCP 服务器。凭证存储在 DigitalOcean Secrets Manager 中，并在执行时附加，因此代理永不会持有它们。工具发现、权限、审批、重试和追踪均在此层完成，这就是本文其余部分反复提及它的原因。

简单来说：您的代理在虚拟机上的托管沙盒中运行（Harness Runtime），它在运行之间保存文件和对话，并且可以暂停、恢复、检查点和分叉。

当代理需要在其他系统中执行操作时，例如打开拉取请求或搜索网页，它不会直接调用 GitHub 或搜索 API。而是向 Action Gateway 发起请求，后者会找到合适的工具，检查您的权限策略，从 Secrets Manager 获取凭证并附加，执行调用，记录日志并返回结果。代理永不会看到密钥。模型来自推理引擎，文件和状态来自存储，业务记录来自数据服务；Signals（即将推出）将收集每次运行的轨迹。

图片的要点在于，代理只有一条通往外部世界的路径，且该路径经过 Action Gateway。这一单一路径正是本文其余部分所主张的受管控层，也是为什么针对 schema 漂移、重试循环、凭证泄漏和缺失审批的修复只需应用一次，而无需为每个代理单独处理。

集成与数据摩擦

本节中的问题都不是模型推理失误造成的。这些故障源于把概率调用方连接到为确定性客户端设计的 API：合同会漂移，数据会变动，凭证会过期，响应格式不匹配。

模式漂移：他人 API 的缓存副本

你提供给模型的工具 schema 是一个快照，通常在部署时获取；MCP 能推送工具列表更新，但多数部署会固定定义后继续前进。快照背后的 API 仍在变化。当提供方重命名字段、收紧枚举或移动端点时，模型仍会根据旧合同发出调用，每次调用都会瞬间完全失败；严格的 schema 不匹配没有渐进式降级。

如果这听起来像是个边缘情况，请考虑即使是为标准化 Agent 工具而设计的协议也无法保持自身模式的稳定。模型上下文协议（MCP）在其 2025-03-26 版本中发布了授权框架和 JSON-RPC 批处理。三个月后，2025-06-18 版本直接取消了批处理，并将 MCP 服务器从发放令牌的授权服务器重新分类为纯 OAuth 资源服务器，这两项都是破坏性变更。锁定三月规范的客户端无法与仅支持六月规范的服务器通信。这正是标准机构自身在公开谨慎地前进。你集成的中位数 SaaS API 变化更快，却发布得更少。

状态同步：在快照上操作

代理通过工具调用读取状态，这意味着它对世界的认识是一系列时间点的快照。在读取与写入之间，系统已经发生变化。它在两轮前获取的库存数量在下单时已经过时。另一个进程关闭了代理即将更新的工单。有人在循环过程中编辑了该记录。

传统软件通过事务、乐观锁以及围绕冲突检测的重试机制来处理这个问题。代理大多则是直接忽略。模型本身没有失效机制；其上下文窗口中的一个事实，无论是刚获取的一秒前还是一百轮前，看起来同样正确。这就是 τ-bench 通过比较最终数据库状态与目标状态来评估代理，而不是对对话进行打分的原因之一：代理说它做了什么以及系统实际状态显示的内容经常不一致。

认证瓶颈：循环中的每用户凭证

人类只需授权一次应用后就可以离开。而代理代表特定用户在多个服务之间进行数十次调用时，需要在可能超过其最初获取的访问令牌生命周期的循环每一步都拥有有效且范围恰当的凭证。再把这一点乘以每用户凭证：代表用户 X 的代理 A 不得复用为用户 Y 签发的令牌；刷新流程必须在无人干预的情况下在循环中间进行；为某一服务签发的令牌也不得被重放到另一服务。

正是这一点促使 MCP 规范现在要求客户端实现 RFC 8707 资源指示器（每个令牌请求必须标明令牌所针对的确切服务器），以专门阻止令牌流入本不该授权的服务而导致的混淆代理攻击。2025 年 6 月的认证改革之所以存在，正是因为早期的模型——每个 MCP 服务器自行签发令牌——在代理所创造的多用户、多服务场景下崩溃了。大多数团队都是通过痛苦的方式才意识到这种复杂性：他们起初在环境变量中使用一个共享的 API 密钥，但只要出现第二个用户或第二个服务，凭证管理就会瞬间失效。

载荷不匹配：模型上下文中的机器数据

REST API 会返回一切：分页元数据、嵌套对象、非规范化的 ID，以及任务永远不会用到的字段。应用程序代码会在任何人为其付费之前先把无关字段丢掉。而模型则需要为其接收到的每个令牌付出代价——无论是金钱、延迟还是注意力。

注意力成本是让人感到意外的一点。 LongFuncEval（Kate 等人，IBM Research，2025）测试了模型在工具响应从 10K 增长到 80K tokens 时提取答案的能力：GPT-4o 的准确度下降了 7%，而其他强模型的准确度最高下降了 91%。数据就在上下文中；模型已经无法可靠地找到它。

Anthropic 工程团队在其使用 MCP 的代码执行文章中量化了累积浪费：一个代表性的多工具工作流，在将完整的工具定义和原始中间结果通过模型传递时消耗了约 150,000 个 tokens。重构后，让代理在数据进入上下文前进行过滤，相同的工作流仅需约 2,000 个 tokens，降幅达 98.7%。这些冗余不仅昂贵，而且构成了工作负载的大部分。

执行和可靠性故障

这就是模型自身判断发挥作用的地方。即使集成正常工作，代理仍需选择正确的工具，提供正确的参数，并在调用失败时做出合理的响应；而这些环节各自都有其典型的失效方式。

错误的工具选择：工具越多，选择越差

直觉上认为工具越多，代理能力越强。实际测量结果却恰恰相反。RAG-MCP（Gan 和 Sun，2025）在可用 MCP 工具池不断增长的情况下对工具选择进行压力测试，并观察到基准准确度降至 13.62%；在向模型提问前检索语义相关的简短列表使准确度恢复到 43.13%。LongFuncEval 从另一个角度发现了同样的趋势：将工具目录从 8K 增至 120K tokens 的定义，导致调用准确度根据模型不同下降了 7.59% 到 85.58% 不等，伴随着目录的扩大，出现了幻觉函数名。

机制其实很平凡。相似的工具容易混淆。search_issues, list_issues, query_issues, and get_issue 来自四个不同的服务器汇入同一个上下文窗口，而模型在这些选项中的选择是基于对描述的软性概率判断，而每个描述都是由从未见过其他三个描述的人编写的。没有任何机制能保证选中的选项是正确的，而在工具数量超过四十时，这种情况经常发生。

参数猜测：缺失参数的合理值

当所需参数既不在对话中，也无法从之前的工具结果中推导出来时，正确的做法是询问。相反，模型倾向用一些看似合理的内容填充该槽位：一个占位符电子邮件、一个取整的日期、或者从工具描述中的示例中匹配出的 ID 模式。伯克利函数调用排行榜（Patil 等人，2025）通过一个“缺失参数”类别直接测试这一点，在这种类别中，模型应当识别出关键信息缺失并请求澄清，而不是做出假设。这是基准中较难的类别之一，当被猜测的参数是金额或账户时，这种失败就会转化为错误收费的客户。

松散的模式会使问题更糟。每个被简单类型为 string 的参数、每个没有文档化默认值的可选字段、每个缺失的枚举都在邀请模型进行即兴发挥。只有在有东西强制执行时，模式才会起作用，但一个被强制执行的模式（受限解码，或在调用离开之前拒绝无效调用的运行时）是模型无法通过说话来规避的唯一一种输入验证形式。

无限重试循环：模糊的错误会引发重复

当工具调用失败时，错误文本会进入上下文，模型决定下一步该做什么。给它这个：

{ "error": "Request failed", "code": 500 }

而且没有什么可推理的。重试看起来和其他任何做法一样合理，于是模型会一直重试——使用相同的工具、相同的参数、遇到相同的失败——直到达到轮次限制或预算上限为止。大多数失控代理的转录都呈现这种形式，根本原因通常是一条面向拥有日志访问权限的开发者的错误信息，却被交给了一无所获的模型。

同样的失败，只要携带可操作的负载，就会打破循环：

{
  "error": "invalid_parameter",
  "detail": "'region' must be one of: nyc1, nyc3, sfo3, ams3. Received: 'us-east-1'.",
  "retryable": false
}

现在模型可以纠正论点，选择不同的工具，或将问题呈现给用户。可辨识且可操作的错误编写成本低，能够带来比列表中几乎任何其他东西更高的可靠性。

Duplicate writes: a timeout isn’t a failure

重试问题有一种更棘手的变体。当退款请求超时时，支付提供方可能已经完成了退款，尽管响应从未到达代理。重新发起该请求会导致客户被两次退款。同样的歧义笼罩在每一次写入操作中：工单可能被提交两次，邮件可能被发送两次，订单可能被下两次，而整个过程的转录看起来仍然合理。

解决办法正是支付 API 多年前采用的方案：在每次写入操作中加入幂等键，以便下游系统能够识别重复请求并返回原始结果，而不是再次执行。当提供方提供状态检查时，应在重试前验证结果，而不是直接假设失败。

Multi-step workflows stack partial completion on top. A support flow that refunds the payment, updates the order, and notifies the customer can die between steps two and three. Restarting from the top repeats the refund; resuming blind leaves the systems disagreeing with each other. Record which steps completed, make each step safe to replay, and define compensating actions for the ones that can be reversed. Rate limits sharpen all of this: a burst of 429s can drive enough model-initiated retries to exhaust a quota, so honor Retry-After, back off exponentially with a bound, and never retry a write whose outcome is unknown.

Silent failures: HTTP 200, wrong shape

The most expensive failures return success. The API responds 200 with an empty result set where the agent expected records, or a schema variant it hasn’t seen, or a soft error wrapped in a success envelope ("status": "ok", "results": null). The model, seeing no error, treats the payload as the answer and builds the next three actions on top of it.

This is why serious agent benchmarks stopped trusting transcripts. τ-bench and BFCL both moved to state-based evaluation (checking the actual backend state after execution) because an agent’s narration of success and the system’s ground truth come apart in ways response-level checks can’t catch. Your production monitoring needs the same skepticism: a completed agent run tells you nothing until you’ve verified what it actually changed.

这些故障的累积效应在 GPT-4o 在零售任务上的 τ-bench 可靠性曲线中可见（pass^1 直接报告；k=2 到 k=8 的值来自论文的可靠性图，因而有波浪号）：

全部成功所需的试验次数 (k)	pass^k
1	61.2%
2	~49%
4	~37%
8	~25%

每种单独的失效模式可能只会让单次运行的准确率下降几个百分点。在生产环境中反复运行相同任务时，这种不一致性会累积，就像抛硬币一样，甚至更糟。

安全与治理风险

这些风险在性质上有所不同：前两节会让你损失准确率和金钱，而这一节会让你损失数据，且攻击者是有意图的。下面的三个问题相互关联——注入提供了切入点，权限设定了影响范围，缺失的审批门槛移除了最后的检查。

提示注入：每个工具输出均不可信

模型无法可靠地区分指令和数据。工具返回的任何内容（网页、电子邮件正文、GitHub issue、数据库行）都会进入与系统提示相同的上下文窗口；该窗口中用声称为指令的文本有一定概率被当作指令处理。攻击者不需要访问你的代理。他们只需能够访问代理所读取的任何内容。

AgentDojo（Debenedetti 等人，ETH Zurich，NeurIPS 2024）在 629 个安全测试用例中进行了测量：在工具输出中植入的简单“重要消息”注入在 47.69% 的情况下实现了对 GPT-4o 的恶意目标。在基准的 Slack 套件中，攻击者控制了代理所读取的大部分内容，攻击成功率达到 92%。这不仅局限于基准测试。2025 年 5 月，Invariant Labs 演示了：在公开 GitHub 仓库中提交的恶意 issue 可以引导连接到官方 GitHub MCP 服务器的代理读取用户的私有仓库，并在公开的拉取请求中发布其内容。服务器按设计运行；漏洞在于架构——它允许单个代理在同一会话中结合攻击者可读取的 issue、私有数据和写入权限。

Simon Willison 的 “lethal trifecta” 是判断何时会变得灾难性的最直观方式：一个同时具备访问私有数据、接触不可信内容以及对外通信能力的代理，可能被诱导外泄它能读取的任何信息。只要去掉其中任意一项，该外泄攻击就会失效。粗糙连接的生产代理往往具备这三项。

过度权限：为一把钥匙配整串钥匙

注入决定攻击者是否能够操控你的代理。权限决定这种操控的价值。而这就是部署通常最薄弱的环节：需要只读一张表的代理却使用了能够写入所有表的密钥。文档摘要工具拥有删除权限。支持代理的 GitHub 令牌在组织层级拥有管理员权限，这是因为当时手头正好有这个令牌。

OWASP LLM 应用前十名将此列为 LLM06:2025 过度代理，其典型示例是一个仅需 SELECT 的扩展，却连接到同时拥有 UPDATE、INSERT 和 DELETE 权限的身份。过度权限在代理系统中之所以独具危险性，在于它会放大本页上的其他所有风险。针对只读密钥的幻觉参数会导致调用失败；同样的幻觉作用于具备写入能力的密钥则会造成数据丢失。范围缩减也是唯一的确定性防御手段：评估文本的防护栏可能被欺骗，但没有删除权限的凭证无论如何也无法删除数据，哪怕注入的指令再怎么说服人。

缺乏人机回环：橡皮图章或路障

大家都同意高风险操作（付款、删除、外部邮件、任何不可逆的行为）应得到人工批准。几乎没有人能设计出经得起实际使用考验的审批闸门，因为设计空间在两端都是陷阱。审批过严，审核者每天要看到四十个提示，逐渐不再阅读，凭肌肉记忆点击批准；审计记录显示有人参与，但实际上并没有。审批过松，或把批准变成未记录的 Slack 点赞，则闸门既无防护也无记录。

硬性要求并不光鲜：通过风险范围划分，使只有真正重要的操作才会打断人；审批请求中提供足够的上下文，以便审阅者能够实际评估它（将会发生什么变化，代表谁，是否可逆）；以及将审批与操作关联的审计轨迹。为每个代理和每个工具手动实现这一点的团队，往往只能得到要么是橡皮图章，要么是被过度限制而无用的代理。

与其他两类一样，缓解措施是结构层面的，而不是提示层面的：限定凭证能做什么，限定代理可能做什么，并记录它做了什么。

Which of these is actually your problem?

在寻求修复之前，先确定你正面对的是哪种故障。如果你的代理上个月还能工作，而现在出现 malformed-call 错误，则说明存在 schema drift。如果在添加工具或任务变长时故障激增，你就处于选择和上下文领域：统计你的工具数量，并测量故障时的平均上下文大小。如果运行因预算耗尽并重复相同调用而结束，请阅读工具返回的错误文本，并询问模型是否能够根据它采取行动。如果客户报告双重退款或重复票据，则你的写操作不能安全地重试。此外，如果你的代理在持有真实凭证时接触不可信内容（网页、电子邮件和票据均算），那么无论是否已经出问题，你都存在安全暴露。审计凭证能够做什么，而不是代理应该做什么。

What to do about it

大致按优先级排序：

首先修复你的错误消息。 具有类型和可操作性的错误，带有 retryable 标志，能够消除重试循环，几乎不产生成本。
使写操作可安全重试。 每次写操作使用幂等键，记录已完成步骤，在任何重复之前验证最终状态。
收紧每个 schema。 使用枚举而非字符串，必填字段标记为必填，禁止可猜测的槽位。这是你的输入验证。
精简工具列表。 暴露任务所需的工具，而非服务器随带的四十个工具。如果目录确实很大，则使用基于检索的选择（参考 RAG-MCP）。
在载荷进入上下文之前进行过滤。 将 API 响应投射到仅与任务相关的字段；Anthropic 的 150K 到 2K 的结果表明其中有多少余地。
按用户将凭证范围限制为最小权限。 除非需要写操作，否则为只读；短期受众绑定的令牌；永不使用共享密钥。

将所有工具输出视为不可信。 在可能的情况下打破致命的三重奏：对于给定的代理，放弃私有数据访问、不可信内容或外部通信中的其一。

仅对不可逆的操作进行门控，使用携带上下文并留下记录的批准。

列表中的几乎所有内容都是中介而非代理逻辑：验证、转换、凭证代理、授权、过滤和批准，所有这些都位于代理及其调用的 API 之间。

这些都不是提示工程或模型选择。手动为每个工具和每个代理构建这一层是缓慢且重复的工作，团队往往会略有不同地实现它，这就是为什么生态系统正在将其整合到基础设施中的原因：每个代理操作都必须通过的网关。

操作网关如何解决 Agentic Tooling 的问题

操作网关是 DigitalOcean 对该网关的版本，作为托管服务提供。它是 DigitalOcean 托管代理的一半，该服务目前正在公开预览中，面向所有用户；另一半是 harness 运行时，它在隔离的 Firecracker microVM 中运行代理本身，并与 harnesses 如 Claude Code、Codex CLI、OpenCode、LangGraph 和 Hermes 一起工作（两者如何协同工作）。操作网关是负责管理这些代理如何与外部世界交互的部分：一个单一的 MCP 端点，面向 GitHub、Jira、Notion、Linear、Postgres 以及超过 16,000 种工具，其中身份验证、权限、批准和审计控制统一管理。任何使用 MCP 的客户端都可以调用它（Claude Code、Codex 和 Cursor 获得一级支持），并且您可以在其后注册您自己的 MCP 服务器。

Action Gateway 基于 凭证代理，这是一种为特定目的管理凭证的过程。它是一种确保凭证仅用于预期目的且不用于其他目的的方式。在产品文档中，这相当于连接模型：连接授权提供方账户给行为体，会话在工具运行时解析它。

简单来说，凭证在执行时解析，并且仅在一次调用后存在，随后被丢弃。令牌永不会到达代理、沙箱或最终用户，刷新令牌始终锁定在 DigitalOcean Secrets Manager 中。每次调用仅请求其所需的范围，且受您为每个连接设定的上限限制。不存在凭证缓存，因此轮换和撤销会在下一次调用时立即生效，没有滞后窗口；不可达的密钥会直接失败关闭，而不是回退。每次访问都会按引用进行审计，而不会按值。

以下设计选择直接影响上述的工具选择和上下文问题：网关根本不会将工具目录加载到模型的上下文中。它恰好暴露了三个元工具。action_search 按使用场景查找工具，action_invoke 最多可以并行运行十个工具，action_code 在临时沙箱中执行 Python。下面的演练不会使用最后那个工具，但它是 Anthropic 代码执行模式所需的基础构建块，因为它使代理能够在代码中处理数据，并仅将结果返回给模型。

在本教程中 DigitalOcean 托管代理动手演练，在实时预览会话中运行，对“创建 GitHub 拉取请求并合并它”的搜索返回了五个 GitHub 工具的评分短列表，而不是完整的目录转储。

要亲自尝试，Action Gateway 快速入门将 Claude Code 或 Codex 连接到网关并进行首次工具调用，而 Harness Runtime 快速入门则通过一条命令在托管沙箱中启动一个代理。您可以通过以下教程了解更多关于凭证代理的信息以及如何使用 DigitalOcean Managed Agents：

从搜索到恢复的网关调用

以下是如何在创建并合并 PR 任务中使用 action_search 和 action_invoke，按照上述教程的演练进行组合。代理会向 action_search 请求用于创建和合并拉取请求的工具，并获得评分后的五个工具短名单。它选择创建 PR 工具并调用 action_invoke。用户尚未连接 GitHub，因此调用不会返回裸露的 401 错误，而是返回一个结构化的失败：错误类、retriable 标志、refresh_auth 恢复提示以及包含验证码的登录链接。代理会呈现该链接，用户授权后，工作流恢复。在重试时，网关通过 Secrets Manager 解析 GitHub 凭证并在执行时附加；该令牌仅在该单次调用期间存在，随后被丢弃，模型永不会看到它。

将此 transcript 与上述失败模式进行对比：上下文中没有工具目录，没有针对不可操作错误的重试循环，对话中没有可被窃取的凭证，以及代理能够在无需人工调试的情况下从中恢复的授权中断。

与本文所述的故障模式对应：

问题	Action Gateway 如何解决
身份验证瓶颈	凭证通过 Secrets Manager 代理，在执行时解析，并且仅在单次调用期间存在后被丢弃。由于没有凭证缓存，轮换或撤销将在下次调用时生效，且无法访问的密钥会直接失败。基于每个用户的 OAuth 确保一个用户的访问不会出现在另一个用户的会话中。
通过提示注入进行的凭证盗窃	令牌永不会到达代理、沙箱或最终用户；在 Managed Agents 沙箱内，客户端配置根本不携带任何 bearer token。即使有注入的指令也无法外泄一个本来就不存在的令牌。
过度权限	每次调用仅请求其所需的权限范围，且受您每个连接设定的上限限制，再叠加中央每项服务的策略控制。权限是按次定义的，而不是继承自随手可得的密钥。
错误的工具选择和上下文臃肿	工具目录不会进入上下文。代理通过 `action_search` 检索任务的评分短列表，这与 RAG-MCP 测量的检索方法相同，使选择准确率提高了三倍以上。
无限重试循环	故障会以结构化形式返回，包含错误类别、一个 `retriable` 标志以及一个 `recovery_hint`（身份验证失败时会返回 `refresh_auth` 并附带登录链接，而不仅仅是一个裸露的 401）。自动重试在每个工具级别受到限制，仅在工具配置允许的情况下进行重播（只读操作或提供商的幂等密钥），但您自行注册的写入工具仍然需要幂等密钥或其他保证以确保重播是安全的。
载荷不匹配和参数错误	调用验证和修复可减少错误的调用，而输出视图在结果到达模型之前，仅保留选定的字段。

缺少人工介入环节审批是声明式的：你在会话的工具策略中定义智能体可以自主执行哪些操作（allow）、哪些需要人工签批（ask）、哪些会被直接拦截（deny），而不必为每个智能体、每个工具手工搭建一套审批流程。缺乏审计追踪所有操作都流经单一的受管控节点，审计控制集中于此；每一次调用都有迹可循，这些追踪数据会在权限文档坦率地指出了两个限制：网关工具的权限执行在送达沙箱的策略中被标记为尽力而为，因此应将权限块视为代理工具路径上的防护栏，而不是网络边界；并且，网关工具上的 ask 规则要求客户端能够完成网关的审批流程（客户端回答的 MCP 引发，或人工在重试前解决的待批准），否则客户端将看到调用失败。为常规工具设置显式的 allow 规则，对后果较大的工具保留 ask 规则，并使用您实际部署的适配器验证行为。

关于此主题的常见问题？

1. 什么是代理工具？

代理工具是指赋予语言模型对外部函数（API、数据库、搜索、代码执行）的访问权限，使其能够调用这些函数来在世界上采取行动，而不仅仅是描述它。从模型的角度来看，每个工具都是上下文窗口中的一个 JSON 模式；模型会发出结构化调用，运行时执行该调用，并将结果反馈回去。当该循环反复运行时，模型会在每次结果后决定下一步行动，由此得到的就是代理。

2. 如果模型在函数调用基准测试中表现良好，为什么在生产环境中会失败？

因为单轮基准测试仅衡量模型是否能够从一个干净的 schema 中产生一次格式正确的调用，而生产环境则衡量模型是否能够在底层系统不断变化的情况下完成多步骤任务。τ-bench使差距变得具体：GPT-4o 在单次尝试中完成了约 61% 的零售任务，但连续八次成功的概率（pass^8）降至约 25%。

3. 代理在开始挑错工具之前能处理多少工具？

没有固定数量，但随着目录的增长，准确率会下降。RAG-MCP 显示，基准工具选择准确率在规模扩大时降至 13.62%，而在模型获得检索到的短名单而非完整列表时恢复至 43.13%；而 LongFuncEval 测量显示，随着工具定义从 8K 增至 120K tokens，调用准确率下降高达 85.58%。实际经验法则是仅暴露任务所需的少量工具，并在目录较大时采用检索而非枚举的方式。

4. 更好的系统提示能否修复提示注入？

不。模型无法可靠地区分指令和数据，因此工具返回的任何文本都有可能被遵循。AgentDojo 测量显示，简单注入在 GPT-4o 上成功的概率为 47.69%，而在攻击者控制了代理所读取内容大部分的测试套件中成功率达到 92%。有效的防御措施是结构性的：将工具输出视为不可信，限制凭证范围使被劫持的代理能力有限，并避免在同一个代理中同时包含私有数据、不可信内容和外部写入访问权限（Willison’s “致命三重奏”）。

5. DigitalOcean Action 网关与 MCP 有何不同？

MCP 是一种协议：它标准化了客户端如何发现并调用服务器上的工具。网关是位于代理与这些服务器之间的基础设施，它补充了协议未覆盖的内容，例如凭证代理、每次调用的范围限定、审批门槛、重试以及审计跟踪。Action Gateway 本身也是一个 MCP 端点，因此任何 MCP 客户端都可以与其通信，但它前置了数以万计的目录工具以及您注册的任何 MCP 服务器，并对所有通过的调用进行治理和授权。Action Gateway 文档介绍了会话、参与者、连接、工具策略以及 SDK。

结论

本文所述的失效模式可分为三类：集成与数据摩擦、执行与可靠性故障，以及安全与治理风险。每类都有可测量的证据作为支撑，从 τ-bench 的可靠性曲线到 AgentDojo 的注入率，且大量证据指向模型之外。这些是集成故障，它们的修复发生在代理与其 API 之间的层面，而非在提示词中。

如果这篇文章只让你记住一件事，那就记住这套诊断方法：细读工具返回的错误文本，清点你有多少工具，审查你的凭据实际能做什么。行动手册的前三项（可操作的错误提示、幂等写入、严格的 Schema）成本极低，无论你之后还采纳什么别的方案，都可以先把它们收入囊中。至于其余几项，就要看中间层是自己搭建还是直接购买了。如果你想评估托管方案，DigitalOcean Managed Agents 现已面向所有用户开启公开预览，Action Gateway 和 Harness Runtime 均配有官方文档。可以先从 Action Gateway 快速入门入手，再按照 Action Gateway 实战教程一步步操作，在自己的智能体技术栈上完整跑一遍从搜索到恢复的流程。关于 Harness Runtime 的生命周期特性，可参阅《别再花钱重建 AI 智能体：用 Harness Runtime 把它分叉出来》。Harness Runtime 示例与你能构建什么两个页面展示了这两项服务分别面向的工作负载，发布说明则持续记录预览期间的各项变更。