当代理共享状态时，一切都会崩溃

老化的数据库选择

一家公司建立了一名客户支持代理。它将观察结果存储在数据库、Postgres、Mongo、Redis 中，无论团队已经运行什么。几个月后，另一个团队构建了一个帐户健康代理。有人将它们连接起来，因为人们厌倦了在工具之间复制粘贴上下文。该连接（一个共享数据库表）意外地变成了多代理共享状态。

三个代理现在共享有关客户帐户的状态：入站支持、健康评分和续订建议。

支持代理处理沮丧的客户并存储：“客户表达了对定价的不满，正在考虑替代方案。”健康评分代理读取此信息后，会降级该帐户。续订代理读取降级分数，生成并发送折扣报价。一切都在几分钟之内。循环中没有人。

支持人员的最初观察是错误的。客户对账单错误而不是定价感到沮丧。但是 LLM 介导的记忆提取将交互压缩为误导性的摘要，并且该摘要通过共享状态作为基本事实进行传播。

每一步都进行检索。失败在于写入。系统中没有任何东西可以检测到最初的观察是否不忠实于其来源，或者追踪从错误写入到错误操作的因果链。

为什么单代理系统掩盖了问题

当一个代理写入一个内存存储时，写入损坏会缓慢降低质量。特工总结了一个稍有错误的观察结果。它覆盖实体属性。它存储矛盾的事实。系统仍然有效。它只是逐渐变得不那么可靠。内存层永远不会受到指责，因为故障模式看起来像 LLM 问题。

这就是今天几乎每个人都在的地方。疼痛是潜伏的。没有人能回答基本问题：代理学到了什么，何时、从何来源学到的内容是否与上周存储的内容相矛盾。但系统并没有明显崩溃。信任在不知不觉中被侵蚀。

多个代理会带来什么变化

当代理 A 写入代理 B 读取并执行操作的观察结果时，会出现不同的故障拓扑。

矛盾放大。 两个代理存储来自不同交互的关于同一实体的冲突事实。第三个代理到达采取行动并查看检索层表面的任何事实，但它们之间没有裁决依据。如果没有带有时间戳和源属性的仅附加观察日志，就没有法医路径来理解矛盾。

静默覆盖级联。 代理 A 更新记录。代理 B 在过时的读取上进行操作，写入自己的更新，隐式恢复代理 A 的更改。在可变数据库中，这几乎是无法检测到的。在具有哈希链接观察值的仅附加日志中，这在结构上是不可能的。

**信任边界崩溃。**共享状态意味着每个代理都信任对方的写入。但代理具有不同的功能、提示上下文和错误配置文件。专门的财务分析代理和通用支持代理可能不应该对同一实体状态具有相同的写入权限。在没有谁可以写什么的架构限制的平面数据库中，他们会这样做。

四个阶段

该行业正在沿着可预测的轨迹发展。

1.“只需使用 Postgres”（或仅使用 markdown 文件）

Manus、Claude Code 和 OpenClaw 都使用纯文本文件来存储。趋同进化，而不是共享的剧本。当团队访问数据库时，内存会固定到现有的任何内容上：RAG 通过 Postgres 与 pgvector、用于会话状态的 Redis、Pinecone 中的嵌入。任一路径都适用于简单的用例。心理模型是代理需要记住东西、文件或数据库存储东西、解决问题。

2.检索优化

Mem0、Zep 和 MemPalace 等产品承认代理需要专用的内存抽象，但将问题归咎于检索质量。如何在正确的时间将正确的上下文输入提示中。这解决了开发人员已经感受到的问题：糟糕的回忆、臃肿的上下文窗口、不相关的检索。但此阶段未审核写入路径。法学硕士提取的任何内容都被视为基本事实。

这个阶段将在未来一两年占据主导地位，因为检索疼痛是明显的。开发人员会注意到代理何时忘记或检索到错误的内容。写入损坏难以辨认。代理在不良状态下自信地采取行动，直到下游后果浮出水面之前，没有人意识到。

3.信任危机

当代理从低风险助理转变为高风险参与者、管理资金、制定采购决策、处理合规工作流程、在数天或数周内自主运营时，就会出现这种情况。问题从“特工是否取回了正确的东西？”转变了。 “我能否证明代理知道什么、何时知道以及该知识是否合法？”

代理对损坏的内存状态采取行动的引人注目的故障将迫使这种转变。企业买家将要求审计跟踪。金融和医疗保健领域的监管机构将需要确定性的来源。

4. 分歧

行业分裂。路径A：现有数据库添加代理原语。 Postgres 获得了观察日志记录和实体解析的扩展。 Supabase 或 PlanetScale 提供了“代理内存”产品层。这捕获了许多信任要求适中的用例。

路径 B：专门构建的代理状态基础设施，用于跨信任边界操作、维护长期运行的自治状态或需要加密来源的代理。关键的不变量（仅附加、散列链接、模式约束、确定性实体解析）是无法可靠地改造为数据库扩展的架构承诺。

这是代理系统充分发挥潜力的途径。能够信任自己的状态、追踪自己的推理并与其他代理进行协调而不会发生无声损坏的代理在质量上比在尽力而为内存上运行的代理更有能力。

写入完整性并不是事后附加的安全功能。它是使自主操作成为可能的基础。

多代理系统实际上是如何构建的

大多数不会被设计为多代理系统。他们会繁殖。

以人类为中心的轮辐式是当前的主导模式。一个主要代理面向用户并将子任务委托给专门代理。共享状态是主要代理的上下文窗口。写入完整性风险较低。但这种拓扑有一个硬性上限：集线器代理存在瓶颈，无法在长时间运行的工作流中维护上下文。这映射到阶段 1 和阶段 2：“仅使用 Postgres”或检索层工作正常，因为一个代理控制状态。

管道代理其次。每个代理处理并丰富工作项目的顺序切换。领导资格审查、公司研究、外展起草、会议安排。书写完整性从这里开始变得重要。如果研究代理存储了不正确的公司数据，则每个下游代理都会校准错误。这是团队开始从第二阶段滑入第三阶段的地方：检索仍然有效，但信任危机正在表面之下形成。

具有共享上下文的事件驱动代理如下。多个代理从共享环境（CRM、代码库、通信渠道）订阅事件，维护自己的观点，并将观察结果写回公共存储。没有协调者。这是完整的第三阶段：来自具有不同解释框架的代理的并发写入，没有协调器来捕获矛盾，并且写入完整性变得真正危险。

具有长期运行状态的持久自治代理是最终状态。代理持续运行，维护不断发展的世界模型，定期与其他代理或共享真理存储同步。上下文窗口不能充当内存。这些代理需要具有真正完整性保证的持久存储。这是第四阶段：分叉。您的基础设施要么是为此而构建的，要么不是。

一个关键的矛盾是，当共享状态风险较小时，许多开发人员会选择拓扑一和拓扑二进行存储。他们选择已有的数据库并添加一个记忆表。当他们达到拓扑三和四时，架构承诺就已经融入其中。从可变状态迁移到仅附加状态并不是库交换。这是一个重新架构。

重要的集成表面

获胜的架构可能不是“替换您的数据库”，而是“位于您的代理和数据库之间”。

代理将观察结果写入写入完整性层：仅附加、模式约束、来源跟踪。该层管理代理可读状态。开发人员现有的数据库仍然是业务数据、客户记录、交易、产品目录的记录系统。但是代理生成的状态、观察、推论、实体解决方案、决策都存在于专门构建的层中。

在实践中，这两层相互通信。代理从 Postgres 读取客户记录，运行分析，并将其观察结果（运行状况评分、流失风险、建议操作）写入写入完整性层，并引用源记录。第二个代理查询完整性层以获取有关该客户的所有观察结果，获取具有来源的一致快照，并对其采取行动。如果出现问题，您可以追踪链条：哪个代理在何时、基于哪个源数据编写了哪些内容。业务数据库永远不会受到代理生成的状态的污染，并且代理层永远不会忘记其观察结果的来源。

“人类编写的业务数据”和“代理编写的观察状态”之间的区别是为什么需要新数据层的最清晰框架。你不会替换他们的数据库。您正在为代理开始自主写入之前不存在的数据类别添加一个层。

我正在构建什么

这就是 Neotoma 所做的。仅附加观察结果。哈希链接的出处。架构约束写入。确定性实体解析。代理编写的每项观察结果从第一天起都是可追踪、可审计且一致的。

我一直在通过它运行我自己的代理堆栈。多个代理（电子邮件分类、任务管理、财务、内容规划）都向同一家商店写信。多代理共享状态问题对我来说并不是假设的。当一个代理的提取与另一个代理的提取相矛盾时，或者当陈旧的读取产生针对不良状态的下游操作时，我每周都会遇到这种情况。

等待采用写入完整性的成本并不是可以稍后偿还的技术债务。这是您的审计历史记录中的空白。迁移之前的一切都是黑匣子。这种差距是永久性的。

要点