On this page
很多人在长期使用 AI 之后，可能都会遇到一种相似的感觉：
刚开始它对任务理解得很清楚，但随着工作时间变长，回答似乎会逐渐变乱。
这种现象在很多场景里都会出现：
- 和有记忆能力的聊天 AI 长期交流时，一个已经解决的问题，又被重新当成开放问题；
- 用 Work 模式长时间处理文档和文件，它偶尔会继续按照早期方案工作；
- 用 Codex、OpenCode 一类工具持续开发一个项目，AI 又开始引用已经废弃的实现。
后来我逐渐意识到，其中有一类问题并不是 AI 单纯“记不住”，而是：
它掌握的信息，和现实中的最新情况已经不一致了。
AI 不是直接面对现实，而是推断现实
AI 的“智能”很容易让人产生一种错觉。
因为它能够自然地说话、理解要求、回应问题，我们会下意识地按照人与人交流的方式去理解它：
“这件事情我之前已经告诉过你了，你应该知道。”
但模型和人之间有一个很重要的区别。这个区别并不只是聪明程度，而在于：
人可以持续感知现实，而模型本身并不能天然知道当前世界正在发生什么。
一台电脑正在运行，我们看到电源灯亮着，就会知道它至少还在通电。
这些信息，人可以通过感知直接获得。但大语言模型本身并不能直接知道这些事情。
它也不知道电脑现在是否正常运行，除非我们通过文字、图片告诉它，或者它能够调用工具主动查询。
模型对现实的认识，来自它当前获得的上下文，而不是持续感知本身。所以，一旦现实发生了变化，而这个变化没有及时反映到它能看到的信息里，问题就开始出现了。
上下文和现实，是怎么开始错位的
长期使用 AI 时，我觉得最常见的问题大致可以分成两类。
- 历史过期：AI 看到了旧信息，但没有意识到它已经失效，推断为事实；
- 外环断裂：现实发生了变化，但新的结果根本没有进入 AI 的上下文。
一个是旧的信息没有退出，一个是新的事实没有进入。
1. 历史过期：历史记录还在，但当前事实已经变了
一个任务持续得越久，上下文里积累的信息就越多。
比如：
- 开关最开始是打开的，后来又被关闭；
- 一开始采用方案 A，后来改成方案 B；
- 项目最初放在旧目录，之后计划迁移，最后已经完成迁移。
于是它真正面对的问题不只是有没有记住，而是这些信息里，哪些现在还有效？
即使 AI 本身具备调用工具、读取文件或查询系统状态的能力，它也不一定每次都会重新验证。
如果上下文里已经存在一个看起来足够确定的结论，它可能直接沿用这个结论继续推理，而不是再次调用工具确认。
2. 外环断裂：人做了事情，但结果没有回到 AI 的上下文里
另一类问题，是任务中有一部分动作发生在 AI 之外。
我习惯把这部分理解成“外环”。
AI 给出了三个解决方案。
我们离开对话，自己去完成操作。
最终采用了方案 C，问题也已经解决。
对于人来说，这件事情已经结束了。
但如果没有再回来告诉 AI，那么它可能仍然只知道：
- 曾经出现过这个问题；
- 讨论过几个方案；
- 最终结果未知。
也就是说：
现实已经向前走了一步，但 AI 的上下文停在了原来的位置。
这种情况在实际工作里非常常见：
- AI 给出建议或命令，但实际操作由人在外部完成；
- AI 参与分析，但最终决策发生在对话之外。
只要这些动作发生在 AI 的视野之外，而结果又没有回写，就会形成一个明显的断点。
Agent 也需要知道“现在是什么情况”
当然，这个问题在 AI Agent 的架构设计上已经有所考虑。
一个 Agent 在运行时，通常不会只依赖从头到尾的聊天记录。它还会维护一份 State，也就是一份“现在是什么情况”的记录。
比如一个 Agent 在执行任务时，可能需要持续知道：
- 当前任务做到哪一步；
- 上一步工具调用有没有成功；
- 哪些子任务已经完成；
- 下一步准备做什么。
这和“记忆”并不完全是一回事。为了便于理解，可以把它想象成一块持续更新的“当前情况看板”。
所以一个能够持续工作的 Agent，通常会不断读取环境、执行动作、获得结果，再更新自己对当前情况的认识。
从这个角度看，Agent 本身就在尝试解决“只知道历史，不知道现在”的问题。
Agent 知道的“现在”也是有限的
虽然现在很多 Agent 在架构上已经会维护自己的 State，但这个 State 并不是无限的。
Agent 能维护哪些状态，通常由它的运行框架、工具能力，以及开发者为这个场景设计的规则共同决定。
那也就是说，只要 State 是被设计出来的，它就一定有边界。
一个通用 Coding Agent，可能会比较关注：
- 当前修改了哪些文件；
- 测试有没有通过。
一个运维 Agent，可能会更关注：
- 服务状态是否正常；
- 日志有没有报错，当前配置是什么。
这些状态对 Agent 完成任务当然很重要，但它们只能覆盖系统设计时已经考虑到的那一部分问题。
而当我们把一个通用 Agent 拿到具体工作里使用时，往往还会出现很多只属于当前场景的状态。
比如：
- 这个方向我们已经不再推进；
- 这个方案虽然能实现，但当前项目决定不采用；
- 这个任务已经外部系统解决；
- 这份文档还保留着，但已经不再代表当前标准。
这些信息未必包含在 Agent 原本设计的 State 中，因为平台无法预先穷举所有具体场景。
因此，通用 Agent 负责维护通用状态，而具体项目里独有的状态，仍然需要我们自己补充。
长期和 AI 协作，我现在会做三件事
对普通用户来说，不需要建立复杂机制，我现在主要会做三件事。
1. 定期让 AI 重新读取当前事实
如果一个 AI 已经持续操作某个项目目录、代码仓库或文档很长时间，不要默认它对当前情况的理解一直准确。
可以主动让它重新检查：
- 当前代码；
- 当前目录；
- 当前配置；
- 当前说明文档；
- 当前运行状态。
简单说，就是让它重新“看一眼现在”，比如，我现在会用类似这样的提示词（根据不同场景会有所调整）：
基于当前真实环境重新检查一次，不要直接沿用历史对话中的判断。请重新读取当前代码、配置、文档和运行状态，识别其中已经过期、冲突或前后不一致的信息，并以当前可验证的事实为准，整理一份最新状态
2. 人在外部完成操作后，把结果明确回写
只要有一部分动作发生在 AI 的视野之外，就最好把结果重新告诉它。
比如：
- 已经部署完成；
- 方案 B 已经废弃；
- 当前以这个目录为准。
这些信息看起来很简单，但它们承担的是一个很重要的作用：
把现实中已经发生的变化，重新带回 AI 的上下文。
补充最新事实：刚才的操作已经由我在外部完成，结果如下：
已完成：XXX
最终采用：XXX
已废弃 / 不再考虑：XXX
当前状态：XXX
后续请以这些最新事实为准。
3. 把历史过程和当前情况分开
历史记录当然值得保留，它能帮助我们回顾过程和理解决策。
但对于长期任务，最好另外有一个明确的地方，用来记录：
现在到底是什么情况。
它可以是：
- README；
- 当前决策记录；
- 项目进展页。
形式并不重要，真正重要的是建立一个明确约定：
如果需要确认当前事实，应该优先去哪里看。
这样历史信息仍然可以完整保留，但 AI 不需要每一次都从所有历史讨论中重新猜测现在的状态。
记住过去，不等于知道现在
过去讨论 AI 长期协作时，我们经常会关注它能不能记住更多东西。
上下文窗口有多大、记忆能保存多久、过去的对话能不能重新找回来，这些当然都重要。
但长期协作还有另一个同样重要的问题：
记忆回答“过去发生过什么”，状态回答“现在是什么样”。
所以长期和 AI 协作，我们真正要维护的不只是它记住了什么，还包括它现在认为什么是真的。
很多时候，真正缺的不是更多记忆，而是那一次——再看一眼。