最近研究 Agent 的执行逻辑，我发现有一个问题特别容易在演示阶段被忽略。 很多 Agent 看起来非常聪明，知道怎么规划任务、调用工具、读取结果，甚至还… · @UPing123zzz · TwKit

@UPing123zzz

最近研究 Agent 的执行逻辑，我发现有一个问题特别容易在演示阶段被忽略。 很多 Agent 看起来非常聪明，知道怎么规划任务、调用工具、读取结果，甚至还能在失败以后自动重试。 但如果它执行的是会改变外部系统状态的操作，自动重试这件事就没那么简单了。 举个例子，假设有一个自动发布视频的 Agent，它已经把视频成功提交给平台，但由于网络问题，没有收到接口返回的成功消息。 Agent 看到请求超时，以为发布失败了，于是又执行了一遍。 最后客户打开后台，发现同一条视频被发布了两次。 更麻烦的是，类似问题还可能出现在订单创建、账单生成、邮件发送和客户数据修改等场景里。 这个问题的关键在于，调用失败和业务操作失败，并不一定是同一件事。 客户端没有收到回复，不代表服务端没有完成操作。Agent 如果不能判断执行状态，就可能越修越乱。 这也是我最近越来越重视幂等性、任务状态和错误恢复的原因。 比如在创建任务时使用稳定的任务标识，让后端识别重复请求；遇到超时，先查询任务是否已经执行，而不是马上重新发起；如果流程已经完成一半，就保存中间状态，从合适的位置继续。 当然，这些都需要对应的系统支持，不是让大模型记住不要重复操作就够了。 我发现 AI Agent 开发里有很多这类问题，模型能力越强，越容易让人忽略传统软件工程里的经验。 因为模型通常会表现得非常积极，调用失败了，它会说我再试一次。工具返回异常，它会尝试换一种方法。一个方案不行，它还会继续找新的办法。 这种能力对检索、研究和代码调试很有帮助。但面对支付、发布、删除等操作，过于积极也可能制造新的事故。 所以以后看一个 Agent 产品，我想知道的不只是它能完成多少任务。 还包括执行过程中断了怎么办，操作结果怎么确认，用户能不能撤销，以及系统是否有足够完整的记录来判断发生了什么。 AI 可以让软件变得更加主动，但这种主动性必须受到工程规则的约束。 否则你的 Agent 可能特别勤奋，最后却要安排一群人帮它处理重复执行的问题。

曝光 167 · 评论 2 · 点赞 1 · 书签 2