这周掘金一篇 Agent 技术连载讲到具体场景：团餐客服值班，AI 接手时把对话压成一句「团餐因页面缓存少了两杯，后端已查明修改记录」。听起来顺，但同时改了三个状态——猜测升级为原因，旧报告被当作当前事实，「我来查」变成「查完了」。值得企业 IT 注意：大多数 Agent 项目卡在落地，不是模型不够聪明，是状态管理没做对。

这是什么

作者在做《从工单开始，做一个 AI Agent》系列，本篇核心是把聊天信息分成三类：人员报告（reported）、待验证假设（hypothesis）、待办（todo，认领≠完成）。每条强制带「来源消息 ID」和「所属问题」，凭空结论会被拒收。

状态变更走 SQLite 原子事务：旧项 superseded、依赖它的下游 stale、新项插入，单写锁失败直接交回调用方，不假装支持高并发。还引入两个版本号——话题版本（原始消息更新位置）和调查视图版本（确认过几次变更）。基于旧版本提交操作会被显式拒绝，不让旧操作覆盖新状态。

这套设计叫 Investigation Board，核心判断是：对话不能被压成自然语言摘要，必须保留可追溯的结构化状态。

行业怎么看

支持者认为这戳中了 Agent 落地最真实的卡点。在客服、外包、项目管理等「值班型」业务里，跨班次状态丢失是普遍问题——对话记录在，但可追溯的状态不在，AI 接手时只能凭摘要重猜。

也有反对意见。第一，示例只做了「数量」和「口味」两个问题分类，是演示用的简化，真实业务问题维度往往几十个，靠人工标注不现实；第二，作者自己也承认这套设计不是真正的 Event Sourcing（事件溯源，记录所有状态变更的设计模式），也不解决高并发，企业把它当万能解药会失望。更广的质疑是：状态管理是必要条件，不是充分条件——即使 Agent 记清了事实，如果它不会用、不被允许用，业务问题依然无解。这也是 Gartner 等机构反复提醒的：AI 项目失败的主因从来不是模型能力，而是治理与价值证明。

对普通人的影响

对企业 IT：打算采购或自建 AI 客服的企业，验收时该问一个问题——「跨班次、跨坐席的状态怎么交接？」对方回答「我们有上下文记忆」基本可以判定还没真正落地。

对个人职场：AI 暂时不会「替代」做运营、客服、项目管理的人，但它会放大本来就有清晰交接流程的岗位；流程模糊的，会先被 AI 搞得比以前更乱。

对消费市场：消费者短期内不会突然感受到 AI 客服变好——大多数企业的 Agent 还在「能回答」阶段，「能记清」是下一阶段的入场券。