过期上下文：一种奇怪的新型协调错误

I最近写到，上下文对于AI代理至关重要，但仅有上下文是不够的。代理还需要共享状态。 我反复强调的部分是过期上下文。 在普通软件中，我们已经知道这个问题。我们有过期缓存、过期读取、版本、事务、锁、失效、乐观写入、冲突解决。这并不罕见。 但在代理系统中，我们常常将上下文仅仅视为一个提示。 一个代理在时间T读取世界，然后思考30秒、2分钟或20分钟。在此期间，世界可能发生变化。 另一个代理编辑文件。一个人更改了需求。工具结果到达。文档被更新。 第一个代理可能对此毫不知情。它可以针对一个不再存在的世界生成一个非常连贯的答案。 这实际上不是一个模型智能问题。一个掌握旧信息的聪明人也可能犯错。 人类拥有微弱但有效的实时信号。我们看到光标、Slack消息、Git状态、评论，有人说“等等，我正在修改那部分。” 我们通常在最终输出存在之前进行协调。代理通常在输出存在之后进行协调。 它们写入文件、打开PR、更改记录或返回一段文本。到那时，它们可能已经花费了大量令牌基于过时的假设进行工作。 也许缺失的原语是一种代理间的存在信号。不是像绿色圆点那样的存在，而是结构化信号，比如：“我读取了文件X的版本12。”“我计划编辑文档Y。”“我在等待这个工具调用。”“这个答案依赖于假设Z。” 这些信号不需要是庞大的自然语言日志。它们可以是小事件。 然后一个同步层可以做些平凡但有用的事情。警告代理它读取的数据已更改。暂停写入。要求它重新读取。将冲突的编辑放入队列。向人类展示的不仅是最终答案，还有代理当前认为自己正在做什么。 我不认为每次读取都需要加锁。那可能过于沉重。其中很多可以乐观进行。读取版本。针对你读取的版本进行写入。如果版本发生了变化，让冲突可见。 对于长时间运行的任务，订阅代理接触过的对象上的变化。重要的是，代理不应该在无人知晓的情况下秘密地活在过去的版本中。 这也改变了我对公司上下文的思考。一个只会回答问题的公司大脑就像一个图书馆。有用，但不够。 公司不仅仅是存储的知识。它还包括正在被更改、接受、拒绝、纠正以及当前依赖的事情。代理需要参与这个实时过程。 也许第一个实用版本非常简单。每个对象都有一个版本。每个代理声明它读取了什么以及它计划写入什么。每次写入都说明它是基于哪个版本的。当其他代理依赖的某个内容发生变化时，它们会收到过期通知。仅此一项就能消除很多奇怪的覆盖和令牌浪费。 我不认为这是为了让代理在某种科幻意义上变得自主。这比那无聊多了。如果我们要运行多个代理，它们需要一种方式不相互盲目。否则每个对话都成为一个带有自己过去的小岛。这在演示中可能还行。但我认为在实际工作中不行。