多智能体协作，先解决共享状态覆盖

多个 AI Agent 能各自完成任务，不代表它们放在一起就能可靠协作。作者在数月的多 Agent 系统开发后，把问题指向了共享状态：两个 Agent 同时读写同一份上下文，可能没有任何报错，却悄悄丢掉其中一个的成果。

作者为此开发了协调层 Network-AI，主张把状态修改统一纳入提议、校验、提交的流程。对准备让多个 Agent 并行干活的程序员，这篇文章最有用的提醒是：模型能力之外，还得处理并发写入；但它对自家方案的效果证明仍然有限。

Agent 都能干活，为什么协作还会丢结果

LangChain 提供链式调用，AutoGen 提供对话机制，CrewAI 提供角色组织。作者认为，这些框架擅长组织单个 Agent 的能力，但多个 Agent 共享状态时，还需要专门的协调机制。

原文用一个时间线说明「丢失更新」：后提交的结果覆盖了先提交的结果，即使后者依据的是过期数据。

Timeline of a Production Bug:
0ms:  Agent A reads shared context (version: 1)
5ms:  Agent B reads shared context (version: 1)  
10ms: Agent A writes new context (version: 2)
15ms: Agent B writes context (based on v1) → OVERWRITES Agent A
Result: Agent A's work is silently lost. No error thrown.

要看的是 15ms 那一行：Agent B 依据 v1 生成结果，却覆盖了 Agent A 已写入的 version: 2。

这不是模型回答得够不够准确的问题。两个 Agent 都可能完成了自己的任务，只是写入顺序让其中一份成果消失了。

作者称，这是多 Agent 生产系统的「第一大故障模式」。不过，原文没有给出故障统计、样本规模或具体事故记录，应该把它理解为作者的经验判断。

把写入统一收口，协调层负责什么

作者开发的 Network-AI 位于 Agent 框架和共享状态之间。它的核心设计是：所有状态修改都经过 propose → validate → commit，也就是先提出修改，再检查冲突，最后提交。

下面这段代码展示了接入方式：

// 直接写入可能造成冲突：
sharedState.set("context", agentResult); // DANGEROUS

// Network-AI 将操作变为原子操作：
await networkAI.propose("context", agentResult);
// 校验并发提议
// 自动解决冲突
// 原子提交

要关注 await networkAI.propose("context", agentResult)：Agent 不再直接覆盖共享值，而是把修改交给协调层处理。

作者宣称，Network-AI 提供原子状态更新，避免部分写入和静默覆盖；支持 14 个框架或集成对象，列举了 LangChain、AutoGen、CrewAI、MCP、A2A 和 OpenAI Swarm。它还提供按 Agent 设置的 Token 预算、基于角色的权限控制，以及记录操作主体和时间的完整审计轨迹。项目采用 MIT license 开源。

这些能力覆盖了协作中的不同问题：预算限制成本，权限限制谁能操作什么，审计帮助追查过程。它们有价值，但不能互相替代。记录了覆盖过程，并不等于阻止了覆盖。

我的判断

把共享状态当成独立的工程问题处理，这个方向是对的。 模型再强，也不能仅靠生成质量保证并发写入的正确性。

但原文把「原子提交」和「自动解决冲突」放得很近，容易让读者误以为前者自然保证后者。原子性保证一次修改完整发生或不发生；两次完整写入仍然可能互相覆盖。要阻止过期结果覆盖新结果，还需要版本校验、锁或其他明确的并发控制规则。

更难的是业务冲突。两个 Agent 分别修改不同字段，可能可以合并；如果它们对同一个决策给出了相反结论，协调层依据什么选择？原文没有说明冲突算法、失败后的处理方式，以及是否需要业务方提供合并规则。

和数据库事务、乐观锁、串行任务队列相比，独立协调层的吸引力在于统一入口，减少跨框架协作时的重复接线。不过，作者没有提供这些替代方案的对照数据，也没有给出性能测试、故障恢复测试或详细生产案例。「框架不如协调层重要」可以作为架构提醒，不能据此认定 Network-AI 已经解决了所有共享状态问题。

能拿来做什么

• 在 Node 多 Agent 服务中，先找出所有共享上下文的写入口，检查是否存在「读取旧值、计算结果、直接覆盖」的流程，再决定是否需要引入协调层。
• 让两个任务读取同一版本，并刻意安排它们先后提交，验证后提交者会被拒绝、重试、合并，还是直接覆盖；检查最终内容，不能只看接口有没有报错。
• 如果多个 Agent 会修改同一份需求、计划或代码任务状态，先定义冲突规则，再评估工具。试用 Network-AI 时，应重点核实 networkAI.propose() 的冲突行为、权限边界和审计记录是否满足这些规则。