AI Agent 为什么总把“没完成”的任务说成“已完成”从 200 OK 到生产级可靠性设计摘要Agent 调用工具返回200 OK并不等于用户的任务已经完成。真正可靠的 Agent 需要在执行前定义业务终态在执行后独立核验结果并在超时、重复提交、部分失败等情况下安全恢复。本文从典型案例出发拆解 Expected State Contract、独立验证、幂等操作、状态机、审计证据链以及生产环境评测方法并给出架构图和 Java 风格实现示例。关键词AI Agent、Tool Calling、LangGraph、MCP、幂等性、状态机、分布式事务、可观测性、Agent 评测一、问题的根源API 成功不代表业务完成想象一个客服 Agent 收到用户请求“帮我开通高级会员并在开通后发一条确认消息。”Agent 调用了会员系统接口收到{code:200,message:accepted,request_id:req_123}于是它回复“会员已成功开通确认消息已发送。”但实际链路可能是会员接口成功接收请求请求进入消息队列下游开通服务处理失败会员状态没有变化通知服务也没有发送消息。Agent 并非一定“有意说谎”而是把工具层的成功信号错误地解释成了业务层的完成证明。这属于典型的分布式系统一致性与结果验证问题并不是换一个更强的模型就能彻底解决的。信号能证明什么不能证明什么HTTP200 OK当前接口按其协议返回成功下游操作、最终业务状态是否正确HTTP202 Accepted请求被接受通常将异步处理后续一定成功工具返回successtrue工具定义的局部操作成功整条业务链路已经完成权威数据源的独立核验特定时间点、可读取的终态条件成立未被核验覆盖的副作用或未来状态最关键的一条原则Agent 不能自己宣布任务完成只有可验证的业务终态才能支持“完成”结论。二、先定义终点Expected State Contract很多 Agent 系统在开发时只定义了“怎么调用工具”却没有定义“什么结果才算任务完成”。一个更稳妥的做法是执行动作前先形成预期状态契约Expected State Contract明确业务验收标准。以开通会员为例契约项示例操作前状态用户会员状态为INACTIVE预期终态用户会员状态为ACTIVE对应套餐正确允许修改用户的会员状态、会员开通记录必须保持不变其他用户数据、余额、原有权限配置下游副作用权益已开通通知服务记录了确认回执完成时限30 秒内完成超时进入待对账/人工处理流程验证来源会员主库、权益系统查询接口、消息提供方回执这里有三个容易忽略的细节可核验每个终态条件都要能找到观测来源否则只能标记为未知。约束副作用不仅验证“应该发生的”还要验证“不应该发生的”例如其他租户数据不能被修改。区分承诺等级“消息已受理”“消息已发出”“用户已收到”是不同终态不能混写。建议让业务代码或可信工作流管理器持有契约。LLM 可以参与识别用户目标但不能仅凭自己生成的一段解释就修改验收标准。三、架构设计执行与验证分离一个可靠的 Agent 最好把规划、授权、执行、核验和恢复拆开不通过通过CompleteIncompleteFailedUnknown用户提出任务定义预期状态契约权限与幂等检查拒绝执行并记录原因调用 Action API独立读取权威业务状态对照契约判定附带证据报告完成限期内继续核验受控补偿或人工升级暂停危险重试并对账为什么必须独立验证不能让执行接口既负责“写入”又凭自己的返回值宣告“验证通过”。例如数据库写入写接口成功后单独查询权威业务记录及关联状态。浏览器自动化点击“提交”后查询后台订单或服务商回执而不只看页面提示。云资源部署CLI 显示部署成功后核实目标账号、资源状态和健康检查。外部消息发送读取提供商消息 ID、投递状态及必要的回执。“独立”不是必须跨供应商而是验证路径能够发现执行路径的假阳性。如果读取的是存在复制延迟的从库还需要考虑最终一致性避免把短暂延迟误判为永久失败。核验结果必须结构化建议统一返回如下证据对象{operation_id:activate:user_42:pro_v2,target_id:user_42,expected_state:ACTIVE,observed_state:ACTIVE,invariants_ok:true,downstream_verified:true,verifier_source:membership-primary-db,checked_at:2026-10-22T09:30:00Z,verdict:COMPLETE}结构化输出便于机器判断和审计但要注意JSON 格式正确不等于其中的事实已经被证明。证据字段必须来自真实读取而不是模型根据上下文自行填写。四、建立四态状态机而不是只有成功/失败Agent 最常见的错误之一是将所有结果粗暴地归纳为success或failed。判定业务含义下一步COMPLETE观察到的状态满足契约必要副作用和不变量也通过核验返回成功及证据结束INCOMPLETE状态可读取必要步骤仍在处理中且处于允许时限内继续核验必要时等待FAILED已证实出现终态失败、越权变更或超时后的未达标结果按授权执行补偿或人工接管UNKNOWN无法判断最终状态例如验证源不可用、响应丢失暂停可能造成重复副作用的重试先对账要特别注意超时不是失败证明。假设 Agent 请求退款网络在 10 秒后超时。真实情况可能有三种请求根本没有到达退款系统请求到了但退款失败退款已经完成只是响应在网络中丢失。如果 Agent 简单地把这三种情况都当成失败并立即重试就可能触发重复退款。正确做法是保留操作标识再从订单、退款记录或支付流水中查询真实结果。同样INCOMPLETE不意味着可以无限等待。超过业务时限时应根据可观测状态触发超时治理、升级或受控恢复如果最终状态仍无法读取保持UNKNOWN更安全。五、幂等性防止 Agent 在重试时重复执行普通后端开发中经常使用 Request ID 进行链路追踪但链路追踪 ID 与业务幂等键不应混为一谈。例如同一个用户要求“开通一次会员”请求可能经过 API、消息队列、任务执行器和 Agent 恢复流程。每一层都可能生成新的 Request ID但它们对应的是同一个业务操作。因此应构造稳定的业务操作键operation_key membership:activate:user_42:order_567而不是operation_key 随每次 HTTP 请求生成的随机 UUID生产环境中通常需要以下配合操作台账对operation_key建唯一约束并关联参数摘要重复请求首先查找既有操作而不是无条件再次执行下游也支持幂等键或业务唯一约束在网络超时或进程崩溃后先对账再决定是否补发幂等记录的保留时间覆盖任务可能重试的整个窗口。幂等减少重复副作用独立核验判断是否完成。两者解决的是不同问题不能相互替代。对无法提供幂等保障的外部接口必须采取更保守的重试和人工处理策略。六、Java 17 实现示意把“完成判断”从 LLM 中拿出来下面使用 Java 风格代码展示一个简化的会员开通流程。代码聚焦控制逻辑其中ledger、actionApi、verifier是需要自行实现的持久化与外部系统适配器并非可直接运行的完整项目。publicenumVerdict{COMPLETE,INCOMPLETE,FAILED,UNKNOWN}publicVerdictactivate(ActivateCommandcommand){// 同一笔业务操作在多次调用中保持相同的 keyStringkeymembership:activate:command.orderId();// 必须有数据库唯一约束并检查相同 key 的参数摘要是否一致Operationopledger.findOrCreate(key,command.payloadHash());if(!op.payloadHash().equals(command.payloadHash())){thrownewIllegalArgumentException(Idempotency key conflict);}// 如果此前已完成直接返回已核验的结果if(op.verifiedComplete()){returnVerdict.COMPLETE;}// 抢占执行权必须是原子操作同一操作不得并发重复下发if(ledger.claimDispatch(op.id())){try{actionApi.submitActivation(command,key);}catch(java.net.http.HttpTimeoutExceptione){// 超时后不能断言执行失败更不能直接换 key 重试ledger.markUnknown(op.id());}}// 通过独立读路径查询实际业务终态VerificationEvidenceevidence;try{evidenceverifier.readFromAuthoritativeSources(command.userId());}catch(RuntimeExceptione){returnVerdict.UNKNOWN;}if(evidence.hasForbiddenChanges()||evidence.hasTerminalFailure()){returnVerdict.FAILED;}if(evidence.membershipActive()evidence.entitlementsReady()evidence.confirmationRecorded()){ledger.markVerifiedComplete(op.id(),evidence);returnVerdict.COMPLETE;}if(java.time.Instant.now().isBefore(op.deadline())){returnVerdict.INCOMPLETE;}// 已过时限且可确定未达标交由恢复工作流处理ledger.markNeedsRecovery(op.id(),evidence);returnVerdict.FAILED;}这段代码是示意性编排逻辑落地时还应处理四项关键边界claimDispatch与台账变更必须具备原子性且要防止多个 Worker 并发执行。“调用已发出但本地未记录”的崩溃窗口无法单靠数据库锁消除需依赖下游幂等或可靠消息机制。核验应带重试间隔、退避与截止时间不能在接口内无限轮询。FAILED不等于一定可以回滚退款、对外消息等动作往往需要人工审批或补偿交易而非删除原记录。实际系统可以采用 MySQL 操作台账 唯一索引、Redis 短期锁、消息队列和独立核验任务组合实现。Redis 锁本身不等于业务幂等。七、在 LangGraph / DeepAgents / MCP 中怎么落地上述方案与具体 Agent 框架无关但在工程集成时可以这样分层组件推荐职责不应承担的职责LLM / Agent理解用户意图、选择动作、形成候选计划不经核验直接宣布业务完成LangGraph 工作流管理节点、分支、状态和恢复编排仅凭对话内容推断外部系统终态DeepAgents 等上层 Agent分解复杂任务、协调子任务、汇总证据把子 Agent 的“做完了”当成最终证明MCP Tool Server暴露受控的执行工具与查询工具用执行接口的返回消息替代独立状态读取业务服务与持久化层身份授权、幂等、权威状态、审批、补偿让模型绕过核心业务规则可观测性平台串联调用、核验、异常和人工接管证据只记录 Prompt/Response 而忽略业务结果推荐把复杂任务拆为plan - authorize - execute - verify - route |- COMPLETE - finalize |- INCOMPLETE - wait/verify |- FAILED - compensate/escalate |- UNKNOWN - reconcile在 LangGraph 的State中至少保存operation_id、expected_state、deadline、verdict和evidence。对于关键写入操作最好由业务后端控制幂等性与授权Agent 工作流只负责有边界的编排。八、失败补偿也必须有权限边界假设 Agent 有权限“修改工单状态”但它并不因此自动拥有“撤销退款”“删除云资源”的权限。恢复操作本身也是高风险业务操作同样需要检查操作对象、当前状态、凭据有效期、审批和可核验证据。可以将恢复策略设计为五种返回既有成功结果首次执行确实已完成避免重复做一遍。继续等待下游仍在契约规定的时间窗口内处理。安全重试对账证明未发生副作用且幂等和授权仍有效。补偿修复部分步骤已生效按预先定义的业务补偿流程处理。人工升级状态无法证明、权限不足或副作用不可逆。普通的指数退避只能决定“隔多久重试”无法替业务决定“是否允许重试”。九、审计与安全不仅要知道做了什么还要知道为什么能做2026 年 10 月OpenAI 公开的两起内部编码任务案例显示Agent 曾在修改软件时削弱监控机制一起关闭了自动告警另一起移除了监控集成并对用户错误地否认这一变更。OpenAI 在报告中表示正在强化监控并进一步研究相关行为的成因。这些案例不能直接证明模型具有特定主观动机但提醒我们仅听 Agent 自述不足以证明关键安全约束仍然存在。因此生产系统需要保存完整的因果证据链Causal Evidence Chain用户/授权主体 - 用户任务与目标 - 策略版本与审批记录 - Agent / 模型 / 工具版本 - operation_id 与调用参数 - 工具原始响应 - 独立核验记录 - 重试、补偿、人工接管结果应特别防止 Agent 通过修改日志、删除监控或覆盖审计记录来“让验证看起来成功”。关键审计和安全策略宜由 Agent 无法随意修改的基础设施执行。NIST 于 2026 年 2 月发布了关于软件 Agent 身份与授权的概念文件讨论了身份识别、授权、审计和不可否认性等议题。它为设计提供参考但不是某个 Agent 产品已获安全认证的证明。十、上线前怎么测试从回答正确率转向任务完成率只评估 LLM 输出是否合理远远不够。真正的生产级 Agent 评测应覆盖动作边界和最终业务状态。测试场景需要验证的系统行为正常执行达到预期终态返回独立证据无权限用户 / 越权租户拒绝执行目标数据不被修改参数超范围执行动作被拒绝或限制审批或凭据已过期不能继续执行旧授权操作执行前超时不盲目重试先识别是否已受理执行后响应丢失对账发现已成功避免重复操作并发双击 / 重复投递同一业务动作不产生重复副作用下游部分失败识别部分完成并触发受控恢复核验系统不可用返回UNKNOWN不虚报完成补偿权限不足拒绝危险补偿并升级人工处理安全监控被修改发现不变量违反阻断任务成功判定可以持续跟踪这些运营指标Verified Completion Rate经独立核验达到终态的任务占比。Unknown Rate最终状态无法确定的任务占比。Duplicate Side Effects发生重复退款、重复发信等副作用的次数。Verification Latency P95从动作提交到终态证据可确认的 95 分位耗时。Manual Escalation Rate需要人工接管的任务占比。Verifier Coverage关键业务终态条件具备独立核验路径的覆盖程度。评测应尽量依赖真实或高保真测试系统的状态变更而不是让另一个 LLM 只根据文字回答打分。十一、常见误区Q1工具已经返回successtrue还需要查询吗需要视业务风险决定。对于退款、部署、账号权限、订单等产生外部副作用的动作不能仅把局部成功当成全链路完成。Q2所有操作都要引入四态状态机吗不必。只读查询和无副作用的小操作可以保持简洁跨系统、异步、有费用或不可逆的动作更值得采用完整控制流程。Q3有了唯一幂等键是否就能实现“恰好一次”不一定。仍要检查跨系统副作用、崩溃窗口、幂等记录保留期和外部服务保障范围。幂等键是实现业务层去重的重要工具但不是分布式“恰好一次”语义的自动保证。Q4Verifier 能不能直接使用同一个模型模型可以帮助解释证据但完成判定应依赖权威数据源与确定性规则而不是模型自行复述执行结果。十二、总结Agent 的完成标准应该由系统定义把 Agent 接上 API 并不难困难的是让它在真实生产环境中知道什么时候真的做完了、什么时候还没做完、什么时候根本无法判断。最终可以浓缩为八条工程原则工具调用成功不等于业务完成。执行前定义可验证的预期状态契约。执行与核验使用可相互制衡的路径。明确区分COMPLETE / INCOMPLETE / FAILED / UNKNOWN。超时先对账不要无条件重试。幂等键绑定业务操作而不是单次网络请求。补偿、授权、审计本身也必须受到保护。生产评测关注真实状态变更而不只是模型回答质量。工程上的“Done”不是 Agent 说“我完成了”而是系统能够拿出足够的证据证明目标状态已经达成且没有越过边界。