做后端久了的人，多半有个条件反射：怕请求失败。

500、503、超时、连接被掐断，这些都看得见：告警会响，仪表盘会变红，重试会启动，工程师顺着链路查下去。

AI Agent 带来的是一种更难受的情况：万一什么都没失败呢？

设想一个处理退款的企业级 Agent。凭证合法，退款接口调对了，鉴权授权都过，接口返回 HTTP 200 OK，交易按设计一分不差地走完。

只不过，钱退给了另一个客户。

所有仪表盘可能还是绿的：没抛异常，鉴权没问题，没有服务不可用，也没有恶意载荷。技术上干得漂亮，业务结果却是错的。Agent 从「回答问题」走到「动手做事」之后，这大概是最危险的一类失败。

「成功」一直被当成一件事

传统监控给的是几层熟悉的信号：网络层，请求到没到服务；接口层，是不是返回 2xx；应用层，数据库有没有更新。

确定性软件用这些信号够用，因为该执行哪个操作，是开发者写死的。

Agent 把这个前提改了。开发者可能只暴露 lookupCustomer()、issueRefund()、cancelOrder() 这几个工具，调哪个、什么时候调、参数填什么，交给模型自己拿主意。

于是多出一层成功：这一步，是不是用户真正想要的那一步？200 OK 回答不了。

传输成功、执行成功、意图成功，是三个不同的问题

传输成功、执行成功、意图成功，是三个不同的问题

坑一：接口照着 Agent 的要求，一步不差地做完了

用户说：「把最近那笔重复扣款退了。」Agent 捞出五笔交易，其中两笔很像，它挑了 TX-18491，而真正的重复扣款是 TX-18419。

{
  "transactionId": "TX-18491",
  "amount": 2500
}

校验全过，用户有权限，支付服务照单执行，返回成功。

接口这边没有失败可言，客户那边却被动错了。这不需要提示词注入，也不需要越权，就是一次理解偏差外加一次完全合法的写操作。Agent 越靠近核心业务系统，这个区别越要命。

坑二：一次成功的操作，被重试了一遍

Agent 调 POST /refund，服务已经处理完，偏偏响应因网络超时丢了。Agent 判断退款大概没成，又来一次。第二次同样成功。

模型没产生幻觉，服务也没宕机，毛病在于它分不清「操作失败」和「操作成了，只是回执没送到」。

分布式系统被这个问题折磨多年：AWS 的架构最佳实践建议把写操作做成幂等，让重试不产生重复副作用；Stripe 的幂等键也是这个用途。Agent 没让老问题消失，只是让它更容易发作。千里之堤，溃于蚁穴，自动重试就是那处蚁穴。

坑三：每一步都成功，流程却是错的

再看一个账号注销的 Agent：取消订阅、吊销 API key、删文件、开最后一张发票、关账号，五个工具调用全部返回成功。

但假设公司规定，删文件之前必须先把合规归档导出。Agent 跳过了这一步。

技术上五步全中，业务上流程违规。一条绿色的调用链，证明不了流程是对的。

坑四：它本来就有这个权限

NIST 把身份与授权列为 Agent 权限的核心关切，OWASP 也把过度代理权（Excessive Agency）列为主要风险。

但有个微妙的问题：有权限不等于合适。

设想 Agent 拥有 restartProductionService() 的合法权限，凭证有效，操作人有授权。可现在真的该重启吗？是不是正在发布？另一起故障处理完了吗？它拿到的是不是过期的监控数据？

身份回答「谁在做」，授权回答「能做什么」。Agent 系统还得再回答一句：这件被允许的事，放在当下该不该发生。

缺的那层：意图与结果闸门

Agent 要执行有后果的动作，推理和写操作之间得加一层。别让模型当自己动作对不对的最终裁判，系统应该在关键动作前后，跑一套确定性的前置条件与后置条件检查。

用户 / 业务目标
      ↓
   AI Agent
      ↓
 意图 + 策略闸门
      ↓
   工具网关
      ↓
   业务接口
      ↓
   结果校验

拿退款来说，确定性检查先确认：这笔交易属于已认证的客户、金额可退、原因码有效、审批阈值已满足。

执行之后，后置条件再验证：退款记录确实存在、挂在预期的那笔交易上、金额与审批一致、账本里对得上。

这么一来，正确性就不再压在提示词上了。

别只认请求 ID，要认业务意图

传统可观测性给我们 request_id、trace_id、span_id，还原技术执行过程很顺手。自主流程还需要另一个标识：intent_id。

请求 ID 问的是：这是哪个 HTTP 请求？意图 ID 问的是：这串请求想满足现实里的哪个目标？一个意图可以派生出很多技术请求。

Intent: REFUND_DUPLICATE_CHARGE_8472

Request 1: lookup transaction
Request 2: validate duplicate
Request 3: issue refund
Request 4: update CRM
Request 5: notify customer

第 3 个请求超时时，系统可以先问一句：意图
REFUND_DUPLICATE_CHARGE_8472 是不是已经产生过退款，别急着再发一次。幂等性的价值就在这里。

「语义成功」得把后置条件写死

Agent 工具通常只描述它做什么，不讲业务意义上「干成了」长什么样。更强的契约要把前置条件、幂等要求和后置条件都写清楚。

tool: issue_refund

preconditions:
  - transaction belongs to authenticated customer
  - transaction is refundable
  - amount <= remaining refundable amount

execution:
  idempotency_required: true

postconditions:
  - refund record exists
  - refund amount equals approved amount
  - refund reference is reconciled in ledger

别让 Agent 自己给自己判卷

有个省事的做法：让 Agent 干完，再问自己一句成了没有，然后继续往下走。对高影响操作来说这招很虚：它一开始理解错了意图，回头评价自己的动作，很可能把同一个误解再复述一遍。让 Agent 自己给自己签字，说白了就是掩耳盗铃。

有后果的流程，结果验证必须来自外部证据：数据库状态、账本状态、接口回执、策略引擎、独立的校验器，或者人工审批。

Agent 可以解读这些信号，但不该自己充当事实的来源。

可观测性要从「请求」挪到「结果」

设想一块仪表盘：退款接口可用率 99.99%，Agent 工具调用成功率 98.7%，平均延迟 320 毫秒，看着相当漂亮。可它未必在统计这些：退款退错对象、重复退款、违反策略的退款、结果没验证、被人手工回滚。

团队该盯的是结果指标：verified_outcome_rate、duplicate_action_rate、
postcondition_failure_rate、human_override_rate、
intent_reconciliation_rate、ambiguous_outcome_rate。

更有意义的 SLO 是：99.95% 的有后果意图带着已验证的结果完成，且没有重复副作用，这和接口可用率完全是两码事。草萤有耀终非火，荷露虽团岂是珠，一片绿灯不等于事情办对了。

Agent 该从意图走到已验证的结果

能直接抄的一套流程

用户说：「把我那笔重复的订单取消并退款。」更稳的走法是这样：

• 建一个持久化意图：CANCEL_DUPLICATE_ORDER_9821
• 找出候选订单，确定性核对：同一客户、重复 SKU、金额一致、处于可取消状态
• 把要改的订单和金额先摆给用户看清楚，策略要求确认的就走确认
• 用意图 ID 执行取消，再用同一意图执行退款
• 校验订单状态 == CANCELLED、退款状态 == CONFIRMED、金额正确
• 标记意图 COMPLETED，才跟用户说「搞定」

「搞定」得由系统拿出证据证明后置条件成立才能说出口，不能因为模型觉得自己挺有把握。

安全团队也该管这事

听着像可靠性工程，确实也是个安全问题：OWASP 关于过度代理权的指南，关心的是功能、权限、自主性给过头会造成什么损害；NIST 2026 年的汇总分析也指出，既有网络安全实践依然有效，但需要改造。

一个合法的动作照样可能危险。安全不能只问这次调用有没有鉴权、有没有授权、格式对不对，还得问：动作跟用户意图一致吗、当下安全吗、是不是只执行了一次、有没有独立验证过。

我上生产会用的这套路

• 显式意图：给用户真正的目标建持久化标识
• 最小权限工具：只暴露用得上的能力
• 确定性前置条件：业务规则放在模型外面校验
• 幂等执行：能做成幂等的重试都做成幂等
• 独立后置验证：证明预期状态真存在
• 结果级可审计：意图、推理、执行、最终状态串成一条线

这套东西看着不复杂，及之而后知，履之而后艰，真落生产才知道深浅。走通后手上就有一条更硬的链：

意图 → 策略 → 动作 → 回执 → 验证 → 结果。

未来的 Agent 接口，是一份能力契约

面向人的软件，接口回答的是「开放了哪些操作」；面向 Agent 的接口还得回答「这是个什么动作、风险多高、可不可逆、要不要确认、靠什么做幂等、拿什么证明算完成」。这样一来，接口就成了一份能力契约，不再只是薄薄一层增删改查：模型出智能，接口出确定性保证。

最后一句

我们正花大力气让 Agent 更聪明：推理更强、上下文更长、工具更多、自主性更高。可一旦它能在生产系统上动手，最难的问题就变了，真正的难题在后面：拿什么证明，它刚才干的，就是我们想让它干的那件事？

最危险的失败可能不抛异常，可能不触发告警，可能看上去完全不像一次安全事件。

HTTP/1.1 200 OK

接口成功了，Agent 也成功了，业务还是亏了。

能上生产的 Agentic AI，需要比「工具调用成功」更硬的东西：被验证过的结果。

原文链接：
https://hackernoon.com/the-most-dangerous-ai-agent-failure-might-return-200-ok