agent 缺的不是记忆，是状态

一个客服 agent 帮客户退款。钱其实已经退了，但确认消息在半路超时，agent 没收到。它翻自己的记忆，只看到「我发起了退款」这条记录，于是认定任务没完成，又退了一次。问题不在它记性差，而在它把「记忆」当成了「事实」。InfoWorld 作者 Arjun Mullick 用这个例子点破：agent 缺的不是更多记忆，是可靠状态。

一、发生了什么

Mullick 在 InfoWorld 的文章里，把「记忆」和「状态」严格分开。记忆告诉 agent 过去发生了什么，状态则回答「现在什么是真的」。

他用的退款案例很有代表性：对话记录客户要什么，支付系统记录退款是否真的发生，订单系统记录订单状态，策略和权限记录这个操作是否被允许。每一个事实，都有自己的权威来源。

真正的风险在于，agent 往往只信自己早先的记忆。而状态是会过期的：客户可能中途撤回授权，订单可能已经过了可变更的窗口，权限可能已经变了。更麻烦的是，即便所有检查都通过，操作本身也可能半途失败——这时候需要安全的「重试」，而不是盲目的「再来一次」。

他给出的解法是工程化的：每个关键动作带一个唯一标识，像收据号；接收方识别这个标识，防止同一操作被重复执行；再配合定期对账，把 agent 认为发生的，和系统实际记录的，放在一起比。

二、跟你有什么关系

对正在把 agent 接进交易、审批、合规流程的团队，这是一份必读清单。一个信任自己记忆的 agent，在超时、重试、并发这些边缘情况下，会制造真实世界的错误，而不是「回答错误」这么简单。

对做 agent 基础设施的人，要点是「别让 agent 自己当真相源」。记忆可以帮它理解上下文，但「某件事到底成没成」，必须回到权威系统去查。

对管理者，这改变了「该监控什么」的答案。延迟、成本、准确率都有用，但都告诉你 agent 有没有在过期权限上行动、有没有宣布一笔从未发生的退款。要追踪的是决策本身。

三、怎么用

1. 给每个重要动作加唯一标识。响应丢失时，重试必须复用同一个标识，接收方靠它去重，这是幂等的核心。
2. 动手前先查权威来源。别让 agent 凭记忆判断「任务完成没」，要回到记录这笔事实的系统里确认当前状态。
3. 定期对账。像核对账单一样，把 agent 以为发生的，和系统实际记录的对一遍，不一致就重新检查、回滚或升级给人。

四、三个别信的说法

错误说法：给 agent 更多对话历史，就能解决重试问题。 多塞历史没用。退款超时那一刻，agent 缺的不是上下文，是「这笔退款到底成功没」这个事实，而这只有支付系统知道。

错误说法：加了唯一标识，幂等就自动成立。 单靠带上 ID 不够，接收方必须认识这个 ID，并在去重窗口内拒绝重复执行。标识只是钥匙，门得另一头真的认。

错误说法：监控模型质量就够了。 模型答得再好，也不等于没在过期权限上行动、没重复退款。要追踪的是每个关键决策用了什么信息、查了什么规则、做了什么动作、结果记成了什么。

五、一句话结论

记忆让 agent 记得发生过什么，可靠状态才让它知道现在什么是真的、此刻该不该动手——后者，才是不出错的关键。

信息来源

• Your AI agent needs more than memory. It needs reliable state（InfoWorld，2026 年 10 月）

功能与价格以官方公告为准。本文写于 2026 年 10 月 21 日。