我们的 AI 团队遇到了沟通问题（解决方案来自1995年）

Source: Dev.to

请提供您想要翻译的正文内容，我将为您翻译成简体中文并保持原有的格式、Markdown 语法以及技术术语不变。

概览

我们组建了三个 AI 团队：

• Engineering – 设计并构建。
• Web Ops – 编写并发布。
• QA – 测试并验证。

每个团队都有自己的代码库，在各自的会话中运行，并拥有自己的负责人。在一次会话中，各角色都很活跃——进行计划、批评、构建、审查——同时在共享的上下文中协作，并实时相互挑战。

当 Engineering 完成一个功能并需要 Web Ops 为其撰写文档时，我们发现 没有机制 能让一个团队向另一个团队传达“有工作给你”，而不需要用户手动传递信息。实际上，我们已经形成了信息孤岛。

当有三支团队时，问题并不明显

• 只有一支团队时，沟通不是问题——所有事情都在同一个会话中完成。
• 有两支团队时，你可以在脑中记住交接。
• 有三支团队时，用户就成了信息总线，而总线会忘记。

真正的失效模式不是消息被丢失，而是 看不见的 丢失消息。工程团队发布了功能，Web Ops 却毫不知情，博客变得陈旧，却没有人注意到，因为没有系统跟踪应该发生的事情。

大家都在做的事

我们调查了主要的多代理框架——AutoGen、CrewAI、LangGraph、MetaGPT。每一个都假设代理始终在运行。

学术文献更有帮助。Confluent 对多代理架构的分析指出了黑板模式：一个共享空间，代理在其中发布和检索信息，且没有直接通信。代理自主决定是否对所读取的内容采取行动。

这很契合，但我们找到的所有实现都假设有守护进程、经纪人或发布‑订阅——代理实时监听事件。我们的代理在会话之间不运行。

为什么标准建议不适用

我们的代理是 基于会话 的：它们仅在用户启动 Claude Code 会话时存在。会话之间没有任何运行——没有进程、没有守护进程、没有监听器。

文献强烈推荐面向事件的多代理系统架构。Confluent、HiveMQ、AWS——都说事件可以降低连接复杂度、实现实时响应，并通过发布‑订阅解耦代理。

这些都是真的，但在这里并不相关。你不能向不存在的进程发送事件，也无法为每天只运行几次会话的三个团队合理化使用消息中间件。

会话启动时轮询 是该模型的正确模式。并不是因为它比事件更好——而是因为在代理是短暂存在时，这是唯一可行的办法。可以把它想象成你到办公室后检查收件箱；如果你每天早上都打开邮件，就不需要推送通知。

Microsoft 自己的多代理参考架构指出，基于消息的模式会引入“管理关联 ID、幂等性、消息顺序和工作流状态的复杂性”。在我们的模型中，这些开销毫无收益。

Source: …

修复来自 1995 年

Daniel J. Bernstein 在 1995 年设计了 Maildir，旨在在文件系统上安全地投递电子邮件，即使在写入过程中系统崩溃，也不会出现锁、损坏或丢失。 他的解决方案是使用三个目录

tmp/   — 正在写入的消息（消费者永不读取）
new/   — 已投递但尚未查看
cur/   — 已查看并处理

协议

1. 将完整的消息写入 tmp/。
2. 写入完成后，将其重命名为 new/（原子重命名）。
3. 消费者从 new/ 读取文件并将其移动到 cur/。

Bernstein 的两字箴言：“无锁”。

我们把 “email” 换成 “dispatch”，把 “mail server” 换成 “team inbox”：

~/.team/dispatch/
  engineering/
    tmp/
    new/
    cur/
  web_ops/
    tmp/
    new/
    cur/
  qa/
    tmp/
    new/
    cur/

Engineering 向 web_ops/tmp/ 写入一个调度文件，然后将其重命名为 web_ops/new/。下次 Web Ops 启动会话时，Dana 会检查 web_ops/new/，读取该文件，将其移动到 cur/，并创建本地跟踪工单。

没有中间人、没有数据库、没有网络——只有文件和目录。

重要的设计决策

派遣是通知，而不是对话

自然的冲动是添加回复、线程、确认等。跨团队协作的研究警告称，“把 Jira 当作唯一的跨团队沟通渠道”会扼杀实际的协作。派遣仅仅是说“有工作给你”。讨论在用户在场的实时环境中进行。

所有内容都保存在文件中

派遣是带有 YAML 前置数据的 Markdown 文件。下面是第一个正式的示例：

---
from: engineering
to: web_ops
priority: normal
status: pending
created: 2026-01-31
related_bead: _skills-73r
---

（派遣的正文随后以 Markdown 编写。）

通过利用无锁、基于文件系统的黑板，我们将三个相互独立、基于会话的 AI 团队转变为一个协同工作流，而没有增加运行时复杂性。

更新简历技能的网站

所有 6 位 Web Ops 团队成员现在都有基础的简历技能。网站应当反映这些新能力。

验收标准

博客文章或网站更新，提及新技能。

元数据（文件名）

文件名编码了元数据：

2026-01-31T14-30-00Z_normal_engineering_update-site.md

• 时间戳
• 优先级
• 来源
• slug

你可以 ls 收件箱并在不解析 YAML 的情况下进行分流。

过程指南

• 不重新指派。 “烫手山芋式所有权”——工单在团队之间来回弹跳——是一种已知的反模式。调度是一种请求；接收方决定是否接受。如果错误，删除并正确路由。

• 节奏触发，而非 cron。 团队在表格中定义循环调度。负责人在会话开始时检查表格并发送到期的调度。无需调度器；三个团队不需要额外的基础设施。

独立验证

在调研时，我们发现了 agent-message-queue，一个独立实现了几乎相同设计的开源项目：

.agent-mail/
  agents/
    claude/
      inbox/{tmp,new,cur}/
      outbox/sent/

• 相同的 Maildir 生命周期。
• 相同的文件系统介质。
• 相同的结构化 front‑matter。

他们加入了确认和线程功能——这些是我们在规模上刻意排除的。未事先了解的情况下收敛到相同架构，是一个强有力的验证信号。

我们交付的内容

调度协议已上线。/team 技能：

1. 启动时检查所有收件箱。
2. 显示一行摘要。

每个团队负责人在会话开始时轮询自己的收件箱。第一个真实的调度——工程团队请求 Web Ops 更新网站以支持新简历技能——顺利通过系统。

实现细节（无代码，无服务）：

• 每个团队 3 个目录（共 9 个）。
• 一个 YAML front‑matter 格式。
• 一个文件名约定。
• 在 /team 技能中的会话启动轮询。
• TEAM.md 中的节奏触发表。

协议本身即是实现。

我们学到的经验

• 正确的架构已有 30 年历史。 调研现代多代理框架、事件驱动系统和互操作协议时，指向了 qmail 时代的文件系统模式。有时最好的技术已经解决了你的确切问题。

• 约束驱动良好设计。 “我们的代理不会在会话之间运行”看似限制，却消除了复杂性：没有 broker、没有 pub‑sub、没有守护进程。

• 不要构建对话。 添加回复看似自然，但研究表明工单系统的对话常常死掉。单向通知加上必要时的实时讨论效果更好。

• 独立收敛是最强验证。 在设计协议后才发现 agent-message-queue——相同的架构、相同的模式、相同的介质——比任何基准测试都更具说服力。

• 简单不等于微不足道。 九个目录和一个命名约定很简单，但设计借鉴了黑板架构、Maildir 规范、跨团队协作研究以及文件系统 IPC 模式。简洁需要对问题有深刻理解。

协议已有 30 年历史；问题却是全新。它依然有效。

Peter 负责设计，Neo 提出挑战（“消息顺序？”——文件名中的时间戳），Reba 验证了研究，Dana 完成交付。触发本文的调度是系统中第一次通过的调度。

这些技能已开源。