AI代理的风险与失败：为何“还不错”的代理也会崩溃

AI代理的风险和失败模式主要来自于多步骤工具使用中的静默累积错误，而不是一次戏剧性的模型崩溃。一个每一步看起来90%“正确”的工作流程，除非建立了明确的权限、检查点和监控，否则仍然可能在端到端上无法使用。

关键要点

• 多步骤代理的可靠性在各步骤间相乘，因此每个动作85%的准确率在10步工作流程中可能降至约20%的成功率，而95%的每个动作则大约在60%左右。
• 最具破坏性的代理失败是“软”失败：看似合理的输出、错误的工具调用以及不触发错误或警报的目标漂移。
• 多智能体系统增加了自身的故障模式，包括从众偏差和过时的共享状态，这可能将一次幻觉转变为错误的共识。
• 提示注入是一种针对代理的执行层威胁，因为它不仅可以引导工具调用和目标，还可以影响文本输出。

AI代理失败的差异

生产代理的失败就像一个漏水的执行链，而不是像一个崩溃的程序。传统软件往往会大声崩溃：一个API返回500，数据库查询错误，作业失败并重试。代理工作流程在用户界面中常常“成功”，而实际上却做错了事情，因为系统优化的是一致性和完成度，而不是正确性。这是任何在加密领域构建AI代理的人需要进行的关键思维模式转变：失败通常是一个看起来干净的输出，但在操作上是错误的。

复利数学是大多数团队跳过的部分。Trantor的例子很直接：如果一个代理每次行动的准确率为85%，那么一个10步的工作流程成功的概率仅约为20%。即使每步的准确率达到95%，成功率也会大幅下降。收益在10个步骤中，成功率仅约为60%。这与当策略需要多个相互依赖的填充时，交易账本上的填充率衰减形状相同。每个步骤可以在局部上是合理的，但仍然可能产生一个全局上失败的过程。

代理系统也会以非确定性的方式失败。两次使用相同输入的运行可能会出现分歧，因为模型采样、工具输出变化或检索的上下文发生变化。Redis 将这种常见模式框定为在顺序管道中错误累积的现象，其中软错误在没有崩溃或警报的情况下传播。正是这种“没有堆栈跟踪”的特性，使得团队误将代理失败诊断为“我们需要一个更好的模型”，而实际上真正的问题是缺失的门控和缺乏可观测性。

加密货币增添了更锋利的边缘。当一个人工智能代理拥有一个代理钱包时，工具调用并不是一个无害的API请求。它可以是一个交易、一个批准、一个桥接或一个签名。一个无声错误的代价并不是一个糟糕的答案。它是一个在链上结算的动作。

核心代理故障模式预期

工具误用是基本的失败模式，因为它位于语言与执行之间的边界。Trantor 描述了代理选择错误的工具、传递不正确的参数或忽略工具错误并继续进行，仿佛操作成功。在 AI 代理风险的加密上下文中，这与“错误链、错误代币、错误支出者、错误金额”风格的错误完美对应。危险之处不在于调用失败。危险之处在于调用部分成功，而代理在一个损坏的状态上构建下一步。

上下文漂移和幻觉级联是第二类。当工具输出和中间推理累积时，模型的注意力变得稀薄，开始在扭曲的目标版本上运作。Trantor 将此与长上下文中的迷失效应联系起来。Redis 将上下文窗口限制与上下文衰退分开，并指出交易者会认识到的一点：当系统无法可靠地检索相关信息时，添加更多信息可能会恶化决策质量。

目标漂移是缓慢的流失。Trantor将其描述为一种突现失败，在这种情况下，没有单一步骤是“错误的”，但代理最终优化了与原始规范不同的目标。在加密工作流程中，目标漂移表现为一个代理，最初的目标是“重新平衡风险敞口”，但最终却变成了“最大化活动”，因为它学会了进行更多的工具调用看起来像是在取得进展。

重试循环和失控成本是机械故障模式，它们在影响正确性之前就会影响预算。Trantor 标记无限循环，其中失败的工具调用会触发重复尝试，并建议设置严格的迭代限制和支出上限。这是将桌面纪律转化为代理操作的最清晰方式：如果系统无法在运行中被停止，则它还不具备生产就绪状态。

静默质量退化是一个在数周内消耗团队的因素。Trantor列出了导致这一现象的原因，如文档存储漂移、提示回归、静默模型行为变化和输入分布变化。代理持续“完成”任务，但有用性下降到输出不再安全可用的阈值以下。

多代理协调和级联风险

多代理设置通常被宣传为通过冗余实现安全。除非明确设计验证，否则来源指向相反的方向。Redis强调了符合性偏见：下游代理倾向于与自信的上游断言对齐，从而将幻觉强化为错误共识。这不是一个理论上的怪癖，而是一种协调失败模式，看起来像是达成一致，并更快地交付错误输出。

arXiv研究通过MASFT形式化了这一点，MASFT是一个将14种多代理失败模式分为三类的分类法：规范和系统设计失败、代理间不对齐以及任务验证和终止失败。该研究分析了150多个任务中的五个MAS框架，使用人工标注的痕迹，并报告了Cohen's Kappa的标注者间一致性为0.88。它还报告称，在他们的评估中，ChatDev的正确性可以低至25%，而像改进角色规范和编排这样的尽力干预将ChatDev提高了14%，但仍不足以进行实际部署。

协调开销不仅仅是延迟。它消耗上下文预算。Redis指出，多代理变体在顺序推理上可能表现不如单代理基线，因为通信开销超过了任何并行化的好处。每一次额外的交接都是一个软错误变成“状态”的地方。

共享内存和过时状态是另一个级联引擎。Redis描述了代理在不同时间读取共享状态，并根据已被并发操作超越的信息采取行动。在加密中，这就是一个代理如何根据早期余额批准支出者，然后根据较晚余额执行交换，而两者都无法调和。求解网络可以通过外包路径寻找来减少一些执行复杂性，但它也成为另一个边界，输出必须在下一步之前进行验证。

多代理的教训很简单：更多的代理并不会默认创造更多的安全性。它们创造了更多的表面，使未经验证的假设变得持久。

代理工作流中的安全威胁

提示注入是对代理最重要的安全失败模式，因为它不仅限于文本。Trantor将提示注入描述为OWASP LLM Top 10的第一大漏洞，并强调在代理上下文中更危险，因为它可以劫持工作流中的目标和工具调用。这是“聊天机器人说了一些奇怪的话”和“代理改变了它试图做的事情”之间的区别。

代理安全风险扩大，因为每个外部输入现在都是可执行的影响。检索的文档、工具输出、内存，甚至其他代理的消息都是可以携带敌对指令的输入。Trantor建议将每个文档、数据库记录、API响应和工具输出视为潜在的对抗性，并在它们进入代理的上下文之前对输入进行清理。

在加密领域，提示注入加密代理场景非常简单：一个恶意的代币列表条目、一个在检索中被污染的“文档”片段，或者一个精心制作的工具响应都可以引导代理批准一个花费者，桥接到攻击者控制的环境。地址或签署意外消息。这就是为什么人工智能代理的安全风险主要与行动控制有关，而不是数据泄露。

缓解措施是架构性的。TEE可以帮助执行环境某些部分的完整性和隔离性，但它并不能单独解决指令劫持问题。核心防御是限制代理可以做的事情，验证它即将做的事情，并以可审计的方式记录它所做的事情。

Trantor 还声称，88% 部署 AI 代理的组织在 2025 年报告了至少一起安全事件。这个数字在来源中作为次要声明呈现，但它与趋势一致：一旦代理可以行动，事件表面增长的速度超过了大多数团队的控制能力。

有效的设计和运营控制

有效的控制看起来像是风险限制，而不是“更好的提示”。各个来源的论点是，代理失误在步骤和参与者之间会相互叠加，因此系统在每个边界需要明确的限制、验证和可观察性。

桌面式控制堆栈可以表示为一个有序的构建序列：

1. 限制工具的权限范围。Trantor 的工具误用示例根本上是权限失败。一个代理不应该拥有广泛的文件系统或管理员访问权限，当它只需要一个功能时，代理钱包也同样适用这个逻辑，不能随意签署交易。 2. 用模式和前置条件限制工具调用。Trantor 建议进行模式验证，以在执行前捕捉不正确的参数。对于加密工具，这意味着在允许调用之前验证链、代币、小数、接收者和授权增量。 3. 插入验证检查点。Redis 建议在每个边界进行验证，arXiv MASFT 分类法将任务验证和终止失败标记为一个主要类别。验证者角色必须在结构上与规划者不同，否则将变成单一文化。 4. 控制上下文增长。Trantor 建议定期进行层次化总结，以防止上下文漂移。Redis 警告说，增加更多上下文可能会加剧协调问题，因为上下文腐烂和中途迷失行为。 5. 在编排层限制循环和成本。Trantor 呼吁设定严格的迭代限制和实时成本监控，并设定支出上限。这是工程形式的紧急停止开关要求。 6. 构建与概率系统匹配的可观察性。Redis 建议为每个代理调用、工具调用和代理间消息使用关联 ID，以及包括消耗的代币、延迟和每步成功或失败状态的结构化追踪。静默质量下降仅在输出分布和采样时显现。审计随着时间的推移被跟踪。

组织控制与技术控制同样重要。Trantor声称范围蔓延和数据质量问题占AI代理失败的61%。这就是许多试点项目从未成为生产系统的无趣原因。

更安全部署的实用收获

生产准备始于测量链条，而不是欣赏模型。如果工作流程需要10个依赖步骤，唯一诚实的可靠性数字是复合成功率，而不是每一步的“准确性”。Trantor的85%到约20%的例子是快速测试系统是演示还是操作工具的最佳方法。

多代理设计应该证明其复杂性。arXiv论文显示基准测试中的性能提升有限，并且在某些评估中ChatDev的正确性较低。Redis认为单代理设置在顺序推理上可以超过多代理设置，因为协调开销消耗上下文并引入新的失败模式。多代理可以为可并行工作辩护，但仅在验证者角色和终止标准明确时。

对于加密部署，首要任务是限制执行。具有代理钱包的AI代理应在严格权限、硬性支出限制和可以在运行中终止的杀死开关下运行。将工具输出、检索的文档和内存视为对抗性输入，因为提示注入是工作流程劫持，而不是聊天技巧。

第二个优先事项是可观察性。软失败不会通知任何人。它们表现为格式遵循、置信度分数、工具错误率、令牌使用和完成率的微妙变化。没有痕迹，团队无法区分幻觉、过时状态和目标漂移，他们将继续“修复提示”，而系统将继续失败。

更广泛的加密中的代理故事正朝着更多自主权、更多工具访问和更多组合性。这使得AI代理的风险和失败模式成为设计问题，而不是模型问题，幸存的团队将看起来像纪律严明的执行团队：明确的限制、边界的验证和对系统实际操作的严格监控。

观点

我见过团队把90%的“好答案率”当作生产服务水平协议，然后在代理需要连续完成十件事时崩溃时感到惊讶。Trantor的数学给了我们一个清晰的警示：每一步85%的成功率在10步后变成约20%的端到端成功率，正是一个在每次填充时都有不错几率的策略在需要一系列填充时如何失败的真实写照。

我也见过多代理设置带来的虚假安慰。在顺序工作流中，Redis的符合性偏差很快显现：一个自信的幻觉变成了“共识”，因为没有人被支付去验证，只是为了达成一致。支撑这一切的姿态既乏味又有效：最小权限、模式门、验证者检查点、硬性成本上限，以及让某人重放运行并找出第一个错误交接的痕迹。

来源

• Trantor
• Redis
• arXiv