我的 AI 智能体从未互相交谈过——这正是它有效的原因
帮我构建产品的两个 AI 智能体（agent）从未互相交谈过。
一次都没有。
它们运行在不同的机器上，各自处于独立的会话中。它们可能同时在线，也可能一个比另一个晚几分钟甚至几小时才出现。这些都不重要：两者都无法直接调用对方，无法查看对方的上下文，唯一能传递消息的方式，就是写一条持久化记录。
尽管如此，它们仍然一起完成了七轮代码审查，否决了一个设计方案，删掉了一个本不该发布的功能，并且——连同这篇文章——产出了一个三篇文章的系列。
它们靠留便签做到了这一切。
这听起来几乎简单得令人失望，尤其是当下人们常把多智能体系统想象成一屋子 AI 在互相交谈。但我越来越觉得，那个房间并不是必需的。书面记录才是协作本身。
我放弃了复刻会议
作为人类负责人，我并不需要看着两个智能体表演团队协作。我需要的是，下一份工作能够从上一次经过验证的决定开始。
实时对话让这件事比看上去难得多。
两个智能体必须同时在线。它们的讨论发生在一个最终会关闭的上下文窗口里。一个有用的决定，可能被淹没在大量探索性消息之中。等新会话开始时，辩论往往又重新来一遍，因为结论只是以对话残留的形式存留着。
当问题本身需要快速来回沟通时，同步对话确实有用。但如果把它当作默认方式，就隐藏了一个要求：参与者、时间点和对话记录都要保存得足够久，工作才有意义。
我们的设置里，智能体之间没有直接通道。一个智能体把审查结论写到共享记录中。另一个智能体是几分钟后还是几小时后才读到，甚至第一个会话是否还活跃，都无关紧要。读的那一方无法查看或调用那个会话，只能靠自己复现问题，再把答复写回记录。
这个限制反而逼出了一个更好的问题：下一个会话开始时，哪些条件必须已经成立？
交接不是额外负担，交接本身就是工作
一份有用的记录不会写“我们讨论了那个 bug”。它应该包含失败的输入、观察到的输出、具体的提交（commit）、当时的决策，以及还有什么问题悬而未决。
有了这样的记录，新来的智能体哪怕毫无上下文，也能接手工作，甚至对前一个智能体的成果提出质疑。同时，它也让作为人类负责人的我能看清楚：哪些判断有证据支撑，哪些只是主观决定。
本系列第一篇文章里，第二个智能体没有轻信前一个智能体的解释，而是直接复现失败，以此否掉了三个所谓的“修复”。这个审查能跨过七个回合依然站得住，靠的就是每轮的发现、复现结果和提交标识都没有随会话结束而消失。
然后我们又学到了相反的教训：当事实变了，一份长期保存的记录反而可能变成危险品。第二篇文章里那个案例就是如此——一条曾经正确的记录，后来被检索出来时，却被当成了对现状的描述。光有持久化还不够，记录旁边还得有日期和最新证据。
这两条教训在这里汇合：
智能体之间不需要持续的对话。它们需要的是生命周期合适、归属清晰的持久化记录。
难点不在于让智能体开口说话，而在于决定它们停下来之后，哪些东西值得留下来。
四类状态，四种存放方式
我们发现，智能体之间传递的信息可以分成四类。它们在聊天记录里看起来差不多，但在实际操作层面完全是两回事。
1. 决策
“金额一律以整数分存储。”
一条决策可能会被反复使用好几个月。它需要附上原因、适用范围，以及被它取代的旧决策——而不是指望一个碰巧在线的临时负责人。
2. 进行中的工作和负责人
“Maya 正在改账单导入模块；解析器已经写完，接下来做数据迁移。”
这类信息生命周期中等。只要工作还在进行，它就有意义；负责人或进度一旦变化，它也应该跟着更新。
3. 待解问题
“迁移期间还要保留旧的标识符吗？”
待解问题的性质在答案出现的那一刻就变了。答案应该留下来，“等待中”这个状态则不应该。
4. 编辑声明
“我正在编辑账单解析器及其测试。”
这是刻意做成短命的。它的职责是让守规矩的代理在干活的时候不互相撞车。它只是个信号，不是一把锁。
把这几类状态混在一起，它们会朝相反的方向各自坏掉：把长期决策写进临时工作日志，任务一关，决策就跟着没了；把编辑声明塞进永久记忆，文件明明已经没人碰了，却还像被占着一样；把没人回答的问题记在一张永不过期的笔记里，明天就算答复已经到了，代理可能还在傻等。
容器没法只设一套过期策略，因为里面的东西寿命各不相同。
四层货架盘点法
你可以从一个共享文档加一个团队聊天开始。在添加新的代理或工具之前，先盘点一下这四类状态如今都存放在哪里。
THE FOUR-SHELF AUDIT
1. DECISIONS
Where are they written?
Who may change or supersede them?
Can a fresh session find the reason, not only the outcome?
2. ACTIVE WORK + OWNER
Where is progress updated?
Who is responsible now?
What closes or transfers the work?
3. OPEN QUESTIONS
Where is the question recorded?
Who is expected to answer?
Does the waiting state change when an answer arrives?
4. EDIT CLAIMS
What path or file is being touched?
When does the signal expire or get released?
Is everyone clear that it is advisory, not a lock?
对每一层货架，最后再加一道检查：下一次会话能不能不靠重建之前的对话，就直接读懂这份记录？
如果答案是「不能」，那这个团队还没有共享状态，有的只是将来某位代理缺席的一场会议。
笔记不是所有东西的事实来源
书面记录不应该取代那些本来就负责保存持久事实的系统。
Git 仍然是已提交代码的事实来源。分支保护、代码评审和 CI 继续负责把关代码质量。协调记录可以写明哪个提交被评审过、代理打算改动哪些路径，但它既不能让提交变正确，也没法真正把文件预留住。
这个区别在处理“声明”时最为关键。当一个智能体声明自己正在编辑某个路径时，另一个守规矩的智能体可以选择做别的事，或者等一等。但这个信号并不能阻止进程写入——它更像转向灯，而不是门锁。
把协调元数据当成强制执行手段，会带来虚假的安全感；把它当成可有可无的闲聊，又浪费了它的价值。它应该处在两者之间：足够持久，让下一个参与者能读到；足够克制，不去冒充底层那个权威记录系统。
有时候智能体也该聊聊
这个标题是故意写得有挑衅意味，并不是绝对原则。
当两个参与者需要快速缩小模糊问题的范围、在有太多未知数的前提下协商取舍，或者协调一个等待成本很高的事故时，对话是有用的。当决策承载着无法简化成记录字段的组织或情感分量时，人类同样需要对话。
但即便如此，对话的成果也要能带出“会议室”。
把决定、未解决的反对意见、证据、负责人和下一个触发条件都写下来。否则下一个会话拿到的只是一份聊天记录，等于把这场会重新开一遍。
目标不是“绝不交谈”，而是：不要让“同时在线”成为进展的前提。
这在 Vibsync 里长什么样
Vibsync 是我们在 LOOSEDAYS 为使用 AI 编码智能体的团队搭建的“共享大脑”。它的形态是这四个分区，而不是一条永远聊不完的智能体对话流：
- memories：保存决策和可复用的知识；
- tasks：承载进行中的工作和归属；
- async questions：把“等待回答”变成“已回答”；
- path claims：标记智能体正在改哪里，并且可以释放。
这些是协调记录，不是 Git 或 CI 的替代品。声明只是建议性的，最终发布什么仍由人类负责人决定。
更重要的是之后发生的事情。一个智能体可以从另一台机器或另一个工具连进来，读取当前的交接状态，在之前那个智能体不在场的情况下继续干活。这个产品不是想模拟一个热闹的聊天室，而是想让“缺席”变得不再让人意外。
这是一个团队、一套代码库，做的是我们自己的预发布工作——不是基准测试。两个代理之间没有直接通道：即使两个会话同时运行，每个代理也只能基于已有记录工作，无法读取对方的上下文。书面交接不是它们之间的偏好选项，而是唯一路径。正是这条约束，催生出了一种我们现在更愿意采用的工作方式。
用团队现有的工具跑一次“四层审计”（Four-Shelf Audit）。如果结果是有四个明确的位置，每个新会话都能读取和更新，那你可能并不需要另一套系统。如果状态散落在封闭的聊天和个人设备之间，就把代理接入同一个 Vibsync 团队，给下一个会话一个可以开始的地方。
Vibsync 由 LOOSEDAYS 有限公司打造。本文是对这个团队工作流程的第一手记录，不是对照实验。