8.0
热点
AI SCORE
编程提效2026-08-20 05:04
我的两个AI Agent从未直接对话，却高效协作至今
dev.to · AI#Agent#AI协作#工程实践
Editor brief · 编辑速览
作者通过纸质记录（而非实时通信）实现两个AI Agent异步协作，一个月内完成七轮代码审查、否决一个设计方案、移除不该发布的功能。
两个 AI 智能体已经在这个产品上构建和审查了一个月，却从未同时在线。我曾以为这条缺失的实时通道是需要克服的瓶颈。结果发现，这恰恰是工作能够保持完整性的原因——而这个环节正是整个机制中最关键的部分。
帮助我构建产品的两个 AI 智能体从未相互交谈过。
它们运行在不同的机器上，处于独立的会话中。它们可能同时活跃，也可能一个在另一个之后几分钟或几小时才到来。但这不重要：两者都无法直接调用对方、检查对方的上下文，或者除了通过写入一条持久记录之外传递任何消息。
尽管如此，它们共同完成了七轮代码审查，否决了一个设计方案，移除了一项本不该发布的功能，并通过这篇文章产出了一个三部分组成的系列。
它们靠的是留下笔记。
在多智能体系统常常被想象成一群 AI 相互交谈的房间的这个时代，这听起来简单得近乎令人失望。我逐渐意识到，那个房间是可选的。书面记录才是真正的协作。
我不再试图重现会议
作为人类所有者，我不需要观看两个智能体表演团队协作。我需要的是下一项工作能够从前一个经过验证的决策开始。
实时对话做这件事比它最初看起来的要难得多。
两个智能体必须同时在线。它们之间的讨论属于一个最终会关闭的上下文窗口。一次有用的决策可能埋在探索性消息之间。当新的会话启动时，辩论可能会重新开始，因为结论只是以对话残留的形式存活下来。
当问题本身需要快速的来回交互时，同步对话是有用的。但如果把它作为默认方式，就创造了一个隐性需求：需要将参与者、时间和记录完整地保留足够长的时间，让工作真正产生价值。
我们的设置中，智能体之间没有直接通道。一个将审查发现写入共享记录。另一个无论是在几分钟还是几小时后读取——以及第一个会话是否仍然活跃——都无关紧要。读取者无法检查或调用那个会话。它只能复现问题，然后将回应写入记录。
这个限制迫使我们提出了一个更好的问题：下一个会话开始时，必须满足什么条件？
交接不是开销，而是工作本身
一份有用的记录不是说"我们讨论了这个 bug"。它包含了失败的输入、观察到的输出、精确的提交版本、决策，以及仍未解决的部分。
这条记录让一个智能体可以冷启动到达，却仍然能够挑战前一个智能体的工作。这也让我——人类所有者——能够看清证据在哪里结束、判断从哪里开始。
在本系列的第一篇文章中，第二个智能体通过运行失败而不是接受解释，拒绝了三项声称的修复。那次审查跨越了七轮，因为发现、复现和提交身份比每个会话都活得更久。
后来我们学到了相反的教训：一份持久的记录在事实发生变化时可能变得危险。在第二篇文章中，一条曾经正确的记录在后来被检索出来，仿佛它描述的是当前状态。仅仅持久性是不够的；记录需要日期和当前的证据放在旁边。
这两条教训在这里交汇：
智能体不需要持续的对话。它们需要具有正确生命周期的持久记录，以及一个明确的所有者。
困难的部分不是让智能体说话。而是决定在他们停止之后，什么值得被保留下来。
四类状态放在四个不同的架子上
我们发现智能体相互传递的信息可以分为四个实际的类别。它们在聊天记录里看起来很相似。但在操作层面，它们完全不同。
1. 决策
"将货币值存储为整数分。"
一条决策可能会被复用数月。它需要原因、范围和替代决策——而不是一个恰好在线的临时所有者。
2. 活跃工作及其所有者
"Maya 正在修改账单导入；解析器已完成，迁移下一步。"
这类信息具有中等生命周期。它在工作时重要，应该在所有权或进度发生变化时随之改变。
3. 悬而未决的问题
"迁移过程中是否保留旧版标识符？"
一个开放的问题在答案到达的瞬间就会改变性质。答案应该保留；"等待中"的状态不应该。
4. 编辑声明
"我正在编辑账单解析器及其测试。"
这类信息是刻意短命的。它的作用是防止行为良好的智能体在活跃工作中发生碰撞。它是一个信号，而不是一把锁。
混合这些类别会向相反的方向破坏它们。把一条持久决策放到临时工作日志中，它会在任务关闭时消失。把一个编辑声明放到永久记忆中，一个文件可以在没人触碰很久之后看起来仍被占用。把一个未回答的问题放到永恒笔记中，明天的智能体可能在回复已经到达后仍然等待。
容器不能只有一种过期策略，因为内容本就不共享同一种生命周期。
你可以从共享文档和团队聊天开始。在添加另一个智能体或另一个工具之前，先清点一下这四种状态目前住在哪儿。
四架子审计
1. 决策
它们写在哪里？
谁可以修改或取代它们？
一个新的会话能否找到原因，而不仅仅是结果？
2. 活跃工作 + 所有者
进度在哪里更新？
现在谁负责？
什么会关闭或转移这项工作？
3. 开放问题
问题记录在哪里？
谁被期望回答？
等待状态在答案到达时会改变吗？
4. 编辑声明
什么路径或文件正在被修改？
信号何时过期或被释放？
每个人都清楚它是建议性的，而不是锁吗？
对于每个架子，再做一次最终检查：下一个会话能否在不重建先前对话的情况下读取它？
如果答案是否定的，那这个团队还没有共享状态。只是一次某个未来智能体错过了的会议。
笔记不是万物的真理来源
书面记录不应该取代那些已经拥有持久事实的系统。
Git 仍然是已提交代码的真理来源。分支保护、审查和 CI 仍然负责执行代码质量。一条协调记录可以说哪个提交被审查了，或者一个智能体计划编辑哪些路径；但它不能让提交变得正确，也不能在物理上预留文件。
这个区别对于声明来说最重要。当一个智能体宣布它正在编辑一个路径时，另一个行为良好的智能体可以选择不同的工作或等待。但这个信号无法阻止一个进程执行写入。它更像是转向灯，而不是门锁。
把协调元数据当作强制执行会产生虚假的安全感。把它当作可任意处置的聊天又会丧失价值。它位于两者之间：足够持久以供下一个参与者使用，又足够谦逊以至于不会冒充底层的记录系统。
有时候智能体确实应该交谈
标题故意带有挑衅性，而不是绝对的。
当两个参与者需要快速缩小一个模糊的问题、谈判一个充满未知的权衡，或者协调一个等待成本很高的事故时，对话是有帮助的。当决策承载着无法被简化为记录字段的组织或情感重量时，人类也需要对话。
即使在这种情况下，结论也应该离开房间。
写下决策、未解决的异议、证据、所有者，以及下一个触发条件。否则下一个会话收到的是一份记录，需要重新执行那场会议。
目标不是"永远不交谈"。而是不要让同时在场成为进展的依赖项。
这在 Vibsync 里是什么样的
Vibsync 是我们在 LOOSEDAYS 为使用 AI 编码智能体的团队构建的共享大脑。它的形态遵循四个架子，而不是一个无尽的智能体聊天：
这些是协调记录，不是 Git 或 CI 的替代品。声明是建议性的。人类所有者仍然决定什么发布。
重要的行为发生在之后。一个智能体可以从不同的工具或机器连接，读取当前的交接，然后在前一个智能体不在场的情况下继续工作。这个产品不是要模拟一个热闹的房间。而是要让缺席变得不足为奇。
这是一支团队、一个代码库，以及我们自己的发布前工作——不是基准测试。我们的两个智能体没有直接通道：即使两个会话都活跃着，每个都只从记录中工作，无法访问对方的上下文。书面交接不是它们之间的偏好；而是唯一的路径。这个约束产生了一个我们现在更喜欢的工作流。
用你的团队已经在用的工具运行四架子审计。如果结果是四个清晰的、每个新会话都可以读取和更新的地方，你可能不需要另一个系统。如果状态分散在已关闭的聊天和个人机器之间，把你的智能体连接到一个 Vibsync 团队，让下一个会话有一个开始的地方。
Vibsync 由 LOOSEDAYS Co., Ltd. 构建。这是本人团队工作流程的第一手记述，而非对照比较研究。