多 Agent 如何通过可信共享状态、明确授权和可接续的工作环境，维持跨模型、跨会话的长期协作。
最近使用 AI 的过程中，我越来越关心的，已经不是某一个模型能不能完成任务，而是多个 Agent 怎样一起工作，以及一个任务跨越不同会话、不同模型之后，能不能继续保持连贯。
我现在仍然使用 Magpie 和 Paseo，主要通过 omp 执行长任务和调度子代理。模型渠道以 Bedrock 和 GPT 订阅为主，Kiro 和 Devin 的 Claude 还在尝试。工具和模型都可以调整，但随着任务越来越多，我发现，真正决定协作体验的，是工作状态有没有被妥善保留下来。
之前有一次支付渠道接入，我过了七个小时再回头查看，发现列出的七项任务一项都没有完成，也没有代码和验证结果。AI 一直在查资料、讨论方案，却没有收敛到实际执行，也没有及时说明自己卡在哪里。直到我主动询问，它才重新整理进度并继续推进。
这件事让我开始想，如果一个系统里同时有更多 Agent，我们究竟需要让它们做什么？是安排更多角色、建立更多汇报关系，让每个 Agent 不断向其他 Agent 说明自己在做什么；还是换一种组织方式，让工作本身的变化成为其他 Agent 可以读取的信号？
后来，我想到了一群蚂蚁。
蚂蚁如何完成协作
蚂蚁寻找食物时，并不会先召集同伴开会，也不会逐一点名通知其他蚂蚁：“我准备去那边看看。”它在行动过程中改变环境，留下信息素，其他蚂蚁感知到这些痕迹，再根据自己的位置和周围情况决定下一步行动。
单只蚂蚁并不需要掌握整个蚁群的计划，也不需要知道后来会是谁经过这里。但很多简单的局部行动叠加起来，却能形成寻找食物、调整路径的集体行为。
这种通过环境留下的痕迹间接协调行动的方式，叫作痕迹协作，英文是 stigmergy。蚂蚁的信息素只是其中一种例子；在软件开发中，一份更新过的任务状态、一段已提交的代码、一条附有证据的验证结果，也可以成为后来参与者行动的依据。
我觉得这个视角很适合重新理解多 Agent。我们很容易把熟悉的人类组织照搬进来：设一个负责人，下面分几个小组，再让每个角色定期汇报、等待回复、反复对齐。这样的结构有时确实必要，但如果把每一次状态变化都变成一次对话，Agent 越多，系统也会花越来越多时间交换它本来就可以从环境里读到的信息。
从信息流动重新看多 Agent 协作
我尝试把问题退回到更基本的一层：多个 Agent 想要协作，信息就必须在它们之间流动。
从信息如何被后续参与者获得来看，我把它分成两种主要方式。一种是直接传递：告诉某个 Agent，任务已经进行到哪里，让它接手。另一种是通过共享环境间接传递：把任务、状态、结果和相关依据写到约定的位置，后来的 Agent 根据需要读取。
实际系统可以同时使用这两种方式；区别在于，哪些信息适合由谁主动告诉谁，哪些信息更适合成为环境中可查询的状态。
点对点沟通的成本取决于协作结构。如果每个 Agent 都要和其他所有 Agent 分别同步，可能存在的连接数是 n(n-1)/2：数量翻倍时，连接数大致会变成四倍。但这并不意味着所有多 Agent 系统的实际消息量都会翻四倍，中心协调、分组和按需通信都能改变增长方式。
让我在意的是另一件事：当大量状态依靠定向转述时，发送者需要知道该通知谁，还要处理遗漏、重复和信息版本不一致。实时对话可能要求双方同时参与；即使消息可以异步保存，每个接收方仍然要找到并理解对应的消息。
共享环境提供了另一种可能。一个 Agent 把可复用的结果写下来，其他 Agent 可以在不同时间读取，写入者不必事先知道所有读者是谁。当然，“写一次、多次读取”也不是没有成本：后续读取、维护状态、解决冲突和确认信息是否仍然有效，都需要系统承担。
因此，我所理解的 AI Native 协作，不是彻底取消消息，而是尽量把重复的状态通报移出对话：完成了什么，就更新状态；发现了什么，就留下可以检查的依据；满足下一步条件时，让后续工作能够据此继续。
留下痕迹，还不等于建立可信的环境
蚂蚁的例子很启发人，但不能简单照搬。
信息素会随时间挥发，一条路径也会随着食物情况变化而重新受到强化或逐渐失去吸引力。蚁群依靠自身和环境的作用，让旧信号逐步退场。这个机制并不保证每一条痕迹始终准确，但至少说明，痕迹本身也有生命周期。
Agent 留下的记录通常不会自己消失。一份几天前的交接文档，可能仍然写着“正在构建”，但实际环境早已换了版本；一条“部署完成”的消息，也可能只表示命令执行成功，并不能证明目标环境已经更新。
如果所有 Agent 都把这些记录当成事实，共享环境不仅不能减少混乱，反而会把旧判断传播得更远。
所以，留痕要真正有用，至少要回答几个问题：这是什么时候留下的，依据是什么，适用于哪个项目和环境，现在还能不能验证，下一位接手者应该如何理解它。
代码可以对应提交或文件版本，部署状态可以对应环境和实际版本，验证结论应该能追溯到执行结果。对于会过期的判断，要有明确的有效范围和重新检查的办法。状态的格式也要尽量清晰，让人和 Agent 都能区分“计划执行”“正在进行”“已经完成”与“仍待验证”。
这让我意识到，共享上下文不是把聊天记录堆到一个地方。环境里留下的每一条重要痕迹，都需要能被理解，也需要能接受现实的检验。
状态可以共享，授权仍然需要明确
讨论到这里，还有一个容易被忽略的边界。
任务的进度、代码变更和检查结果，可以作为共享状态供后续 Agent 读取。但涉及授权的时候，情况不一样。授权不仅是一个可以被看到的信息，它还关系到谁同意了什么、允许谁做什么，以及这份许可适用于哪一次行动。
例如，某个任务记录里写着“测试环境已经验证”，可以帮助后续 Agent 了解进度；但这句话本身，并不等于用户已经同意正式发布。同样，过去批准过一次操作，也不能自动推导出以后每一次类似操作都已经获准。
授权当然也可以被记录在共享环境里，供执行者核对；关键是记录必须保留授权主体、对象、范围和有效性，不能把一条普通的公共状态当成许可。需要明确决定的地方，定向确认仍然有价值。
因此，我想取消的不是所有沟通，而是让 Agent 为了同步普通状态反复互发消息。状态可以通过环境流动，需要承担责任的决定则要有清楚、可追溯的确认。
比通信方式更深一层的问题
蚂蚁留痕、共享状态、异步通信，这些概念解释了 Agent 之间怎样传递信息。但继续往下想，我觉得还有一个更有意思的问题。
当模型、会话、角色、任务，甚至执行环境都可以分别替换时，系统如何在没有任何一个会话掌握全部上下文的情况下，依然保持长期一致，并且能够随着工作推进而演进？
一个 Agent 看见的只是当前任务需要的局部信息。它可以结束，也可以被另一个模型替换；会话可能压缩，执行环境也可能变化。系统不能把所有连续性都寄托在某一个永远不结束的主会话里。
这时，真正重要的就变成了：项目的目标和约束放在哪里，哪些状态是当前有效的，决策为什么发生，发生冲突时以什么为准，新参与者如何判断自己接手的是哪个版本的现实。
不同 Agent 不需要始终拥有一份完全相同的上下文，但它们需要能够回到共同认可的依据。它们看到的可以是局部视图，关键状态却不能各说各话。新的发现也不应该只停留在某一次回答里，而要在被验证之后，进入后续工作能够使用的环境。
从这个角度看，通信方式更像是入口。真正要设计的，是状态、记忆、规则和责任如何穿过不同模型与会话继续存在。
从一个长会话，走向可以接续的工作环境
我以前比较偏爱保留一个持续工作的主会话：它掌握目标、拆分任务，再让临时子代理处理边界清楚的工作。这样确实方便，也能减少反复交代背景的成本。
但随着长任务增加，我也开始看到单个会话的局限。有一次排查上下文时，我看到一个支付接入会话的记录文件达到 20MB，两百来个回合涉及大量工具调用，在一小时二十分钟里压缩了十次。文件内容、工具输出和历史对话不断累积，重要信息也越来越容易被埋在过程里。
这让我慢慢调整了思路：主会话可以帮助我组织眼前的工作，但项目的连续性不应该只存在于主会话中。目标、约束、已完成的结果和尚未解决的问题，都应该有自己的位置。
我现在已经把这套方式用到日常工作中：一个任务做完后，可以换窗口、换 Agent、换模型，让后续参与者读取已经留下的项目状态和工作记录，再继续接手。对我来说，这种接续体验已经非常接近无损；但它依赖前一个任务是否留下了足够准确的记录，也不意味着任何环境变化和隐含信息都能自动恢复。
这也是我越来越看重 Magpie 聊天记录的原因。对话保存了当时的提问、判断、纠正和取舍，方便我事后复盘。这篇文章本身，就是从近期聊天记录和记忆条目中找回经历，再结合我现在的想法重新整理出来的。
不过，历史记录与当前状态各有作用。聊天记录适合回顾一个决定是怎样形成的；接手任务时，Agent 更需要先知道现在的目标、有效约束和实际结果，再在必要时追溯历史。否则，只是把一个过长的上下文，换成了另一个更大的上下文。
当组织不再以会话为中心
继续往远处想，多 Agent 带来的变化，也许不只是多了几个可以并行工作的助手。
人类组织的许多结构，是围绕人的注意力、沟通成本和责任分工逐渐形成的。汇报、会议、层级和审批都有其产生的原因，也在解决真实问题。但当参与工作的部分角色变成可以快速创建、替换和并行运行的 Agent，有些原本习以为常的流程，就值得重新审视。
如果工作状态能够在可信的环境中自然流转，许多单纯为了同步进度而存在的沟通，就不必按原来的方式发生。组织的重点可能逐渐从“让每个角色向谁汇报”，转向“让什么状态可见、什么行动可以触发、什么决定必须由谁授权”。
这不意味着人的判断会消失，也不意味着未来不再需要负责人。恰恰相反，当执行者可以被快速替换，目标由谁确定、依据是否可靠、责任在哪里，以及哪些事情必须由人作出决定，都会变得更加重要。
我相信，随着多 Agent 真正进入日常工作，传统组织架构会经历一场深刻变化。现在还很难说最终会长成什么样，但我越来越觉得，值得设计的已经不只是一个个更聪明的 Agent，而是一个能够让不同 Agent 留下成果、理解彼此、持续接力的工作环境。
当窗口、模型和角色都可以改变，而任务的目标、证据和责任仍然能够被找回来，协作才开始摆脱对某一次对话的依赖。
Loading...
