AI Agent工作流不可靠？控制平面是关键

AI Agent的推理能力越来越强，但模型能力并不等于执行可靠性。一个能写诗、能调试代码的模型，仍可能在调用外部API时选错工具、误读部分响应，或在超时后继续盲目推进。生产环境中的Agent工作流需要一层「控制平面」来约束状态、权限、重试和证据，让每个操作都变得有界、可观测、可恢复。

模型能力不等于执行可靠性

一个能力出众的模型依然可能选择无效工具、误读不完整的响应，或者在外部服务超时后继续执行动作。在生产环境中，把推理和执行权限分开是更稳妥的做法：模型只负责提出动作请求，由确定性的应用逻辑来验证输入、检查权限、记录结果。

原文给出的架构图清晰地表达了这一分工：LLM负责「推理」并输出「动作请求」，随后进入确定性的控制平面，依次完成Schema验证、权限检查、幂等与重试限制、持久化状态日志，最后才触达外部系统或API。这样的分层意味着，即使模型在某个环节「想错了」，控制平面也能在真正执行前拦截。

将工作流状态持久化到提示词之外

对话历史不是持久化的事务日志。把任务标识、当前步骤、已验证的输入、工具输出和完成状态存入数据库或持久化队列，才是可靠的做法。每一次状态转换都应该被显式记录：pending、running、succeeded、failed或awaiting_review。

这样做的好处在于恢复能力。当worker重启时，可以从已记录的状态继续执行，而不是从模型的自然语言描述中「猜测」进度。用散文重建进度，本质上是在用不可靠的媒介承载关键状态，出错只是时间问题。

限制重试次数并让动作幂等

重试能解决临时的网络故障，但无限制的重试会带来重复支付、重复通知或记录重复更新等副作用。原文建议为外部动作分配幂等键，设置尝试次数上限，并采用带抖动的指数退避。对于重试耗尽的作业，应送入死信队列，并保留足够的上下文以便安全恢复。

这一条对涉及支付、消息推送、数据库写入的场景尤为关键。幂等键让「重复执行」在结果层面与「执行一次」等价，而尝试上限则防止系统在故障中持续放大副作用。

幂等键（Idempotency Key） 是客户端为每个逻辑操作生成的唯一标识符（通常是UUID），随请求一并发送给外部服务。服务端记录该键与处理结果，当收到相同键的重复请求时，直接返回首次结果而不重复执行副作用。Stripe的支付API、AWS的部分接口都采用这一机制。对Agent工作流而言，关键是让重试携带同一个幂等键——这样「超时后重试」在结果层面与「一次成功执行」等价。若每次重试都生成新键，幂等保护就完全失效。

带抖动的指数退避（Exponential Backoff with Jitter） 指每次重试的等待时间按指数增长（如1s、2s、4s、8s），并叠加随机抖动，避免大量worker在同一时刻集中重试造成「惊群效应」二次压垮服务。死信队列（Dead Letter Queue） 则用于收纳重试耗尽或无法处理的消息，保留原始上下文供人工排查或后续补偿，防止失败任务无声消失。

在工具边界执行权限检查

提示词里的指令不是授权系统。正确的做法是在工具包装层中，在执行前的最后一刻检查操作者、资源和允许的操作。对于高影响动作，应要求人工审批；在条件允许时，将读能力和写能力分开。每一个决策及其产生的外部标识都要记录在日志中。

这种边界检查的思路，与后端系统中「不信任客户端输入」的安全原则一脉相承。模型在这里扮演的是一个需要被校验的调用方，而不是拥有最终裁决权的系统。

权限检查置于「工具包装层」而非提示词，本质上是策略执行点（Policy Enforcement Point） 与策略决策点（Policy Decision Point） 的分离：模型只提出意图，由确定性代码依据操作者身份、目标资源和动作类型做出允许或拒绝的判定。这与后端「不信任客户端输入」的原则同源——LLM在这里等价于一个不可信调用方。将读写能力分离（如只读工具与写入工具使用不同凭证）可进一步缩小被误用时的爆炸半径；高影响动作要求人工审批，则是在自动化流程中嵌入人在回路（Human-in-the-loop） 的硬性闸门。

衡量结果，而非模型信心

需要跟踪的指标包括完成率、重试次数、各工作流步骤的延迟、工具错误和人工介入次数。定义成功时，要依赖外部事实——比如创建出的工单ID或已确认的数据库记录——而不是Agent自称「已完成」的表述。

这一点容易被忽视：模型输出的「任务完成」只是一种声明，不是证据。以外部可验证事实作为成功标准，才能避免「报告成功但实际失败」的静默故障。

以外部事实定义成功，是区分声明式完成与验证式完成的关键。模型输出的「已完成」属于自述，可能受幻觉或对部分响应的误读影响；而工单ID、数据库记录、支付流水号等外部可验证标识，才是系统状态的客观证据。工程上可把这套思路落实为结果断言（Outcome Assertion）：每个工作流步骤声明其成功的可验证条件，由控制平面在步骤结束后主动查询外部系统核对，而非采信模型返回的自然语言。这样「报告成功但实际失败」的静默故障会在断言处暴露，而不是等到下游用户投诉才被发现。

从最小的可用控制平面开始

不必一开始就搭建完整的队列和审批界面。原文建议从五个基础能力起步：持久化状态、Schema验证、有界重试、权限检查和结构化日志。当实际负载或风险水平提出要求时，再逐步加入队列或审批接口。这种渐进方式让架构与需求保持匹配，同时保证失败始终可见、可恢复。

对于正在将Agent从demo推向生产的团队来说，这层控制平面的价值在于：它不追求让模型更聪明，而是让系统在模型犯错时依然可控。可靠性从来不是模型单方面能给出的承诺，而是整个工程架构共同保障的结果。