多个人和多个AI共同工作，谁来维持同一个事实版本？

Geoffrey Chen

《AI进入工作之后》· 第一季“从回答问题到参与工作”· 第九篇

一个团队同时使用几个AI系统。研究代理搜集市场资料，写作代理生成报告，编程代理实现网站，项目助理整理会议并更新任务。不同成员还在自己的对话中讨论方案。

星期一，会议决定产品在十月发布。项目助理把日期写入会议摘要，但正式计划仍然保留九月。星期二，写作代理读取摘要，新闻稿写成十月；编程代理读取项目文件，倒计时页面仍按九月计算。星期三，另一名同事在聊天中说“发布日期还没有最终确定”，他的AI又把状态改写成待定。

每个系统都根据自己看到的材料作出了合理回答。团队却同时拥有三个“事实”：九月、十月和待定。

问题不在于哪个AI记忆力较差，而在于组织没有规定：哪个记录具有权威，谁能够改变它，改变后怎样通知所有相关工作流。

AI越多，产生文本和局部状态的速度越快。如果每段对话、每份摘要和每个代理都可以形成自己的事实版本，所谓协作会迅速变成平行现实。

共同工作需要的不是所有人知道一切

一个组织从来不依赖每个人掌握全部信息。财务人员、工程师、作者和管理者各自知道不同部分，通过文件、会议、审批和系统让工作连接起来。

AI加入以后，这种分工继续存在。一个代理可能只处理客户支持，另一个只看代码，第三个负责公开资料。它们不需要共享全部上下文，过度共享还会造成隐私、噪声和权限风险。

真正需要共享的是与协作有关的状态：任务目标、正式决定、当前版本、责任人、依赖关系和变更记录。

Google关于生产级多代理上下文架构的说明，强调把持久状态与模型每次看到的工作上下文分开，并在代理交接时明确传递所需信息。不同代理应获得最小必要上下文，交接记录还要避免让接收者误以为前一个代理的行动是自己完成的。Google Developers Blog：《Architecting efficient context-aware multi-agent framework for production》

这揭示了多代理协作的基本结构：共享事实不等于共享全部对话；协作需要的是经过选择、带有身份和状态的交接。

“单一事实来源”不是只保存一份文件

人们常说系统需要“single source of truth”，容易把它理解成把所有材料放进一个数据库。

但文件集中并不能自动消除冲突。一个文件夹里可以同时有旧版本、新草稿、未经批准的摘要和正式决定。真正的单一事实来源，是组织为某类问题指定一个具有权威的记录，并规定其变更程序。

例如：

  • 发布日期以批准后的项目计划为准；
  • 客户地址以客户主数据系统为准；
  • 网站正文以版本库中的已发布文件为准；
  • 法律要求以当前有效的法律和官方指南为准；
  • 尚未决定的问题在问题登记表中保持“开放”，不能由会议摘要擅自填补。

不同问题可以有不同权威系统。没有必要建立一个包罗万象的“总数据库”，但必须能回答“关于这件事，哪个记录说了算”。

单一事实来源也不意味着只有一个解释。团队可以对同一数据产生不同分析，AI也可以提出不同方案。需要统一的是基础状态和证据，而不是消灭合理争论。

多代理系统会放大交接错误

Anthropic在多代理研究系统的工程总结中描述了一种“协调者—执行者”结构：主代理分解问题，多个子代理并行搜索，最后由主代理综合。该系统在适合并行探索的研究任务上有明显优势，也带来协调复杂度、重复劳动、状态一致性和错误传播问题。Anthropic：《How we built our multi-agent research system》

子代理通常不会把全部搜索过程交给主代理，而是压缩成摘要。压缩是必要的，否则主代理的上下文会被细节填满。但压缩也会丢失信息：限制条件、来源质量和不确定性可能在交接时消失。

如果一个代理写“研究显示效果显著”，下一个代理未必知道样本只有二十人；如果一个代码代理写“测试通过”，协调者未必知道只运行了单元测试，没有运行集成测试；如果一个会议代理写“团队同意”，接收系统未必知道那只是讨论倾向。

因此，代理交接不能只有结论。至少还应包含：

  • 完成了什么任务；
  • 使用了哪些来源和版本；
  • 哪些是事实，哪些是推断；
  • 哪些检查已经执行；
  • 哪些问题仍未解决；
  • 结果可以用于什么，不可以用于什么。

这与人类团队的专业交接没有本质不同，只是AI能够以更高速度制造更多交接，错误也更容易扩散。

共同事实需要来源关系

当一条信息从原始文件进入摘要，再进入报告，最后进入网站，人需要知道它从哪里来、经过了哪些变换。

万维网联盟的PROV标准用“实体、活动和代理者”等关系表达数据与产物的来源：某个结果由什么活动产生，使用了什么输入，与哪些参与者有关。W3C：《PROV-O: The PROV Ontology》

日常团队不一定需要实现完整本体，但可以采用同样的思想。每个重要产物至少保留：源文件、生成或修改者、时间、工具、批准状态和上一个版本。

这样，当网站日期错误时，团队不只是改掉页面，而能追溯错误来自旧计划、摘要误写还是代理读取了错误分支。纠错因此可以回到源头，而不是在每个下游产物里反复打补丁。

来源关系还有助于避免AI内容自我循环。一个AI生成的摘要被存入知识库，后来另一个AI把它当作独立来源，再生成新的报告。如果没有来源标记，组织可能误以为多个文件相互印证，实际都来自同一次未经核实的生成。

人与AI之间也需要明确写入权

如果所有代理都能直接修改正式状态，单一事实来源很快会失去意义。

较合理的权限可以分层：

  • 研究代理可以提出候选事实并附来源；
  • 写作代理可以在草稿中使用已批准事实；
  • 项目代理可以建议状态变更；
  • 只有指定角色能够批准预算、日期和对外承诺；
  • 正式变更自动通知依赖它的系统和负责人。

这不是对AI的不信任，而是任何多人系统都需要的配置管理。人类员工也不能因为参加一次讨论，就有权修改所有正式记录。

美国国家标准与技术研究院的AI风险管理框架要求组织明确人机配置中的角色、责任和沟通线，并由领导层承担部署风险决定。NIST AI Resource Center：《AI RMF Core》

在多AI团队中，角色不能只写成“AI负责研究，人负责监督”。还要具体说明谁可以创建候选记录、谁能改变正式状态、谁负责解决冲突、谁在错误发生时通知下游。

会议和聊天应该保存什么

聊天适合探索，会议适合形成共同理解，但两者都不应自动成为正式事实。

一份有用的会议记录应区分：

  • 讨论过的想法；
  • 已确认的事实；
  • 作出的决定；
  • 决定者与批准时间；
  • 尚未决定的问题；
  • 需要更新的正式系统。

AI可以从转录中提取这些候选项，但不应仅凭语气判断“大家同意”。会议结束时由主持人或责任人确认决定，再写入权威记录，才完成从对话到组织事实的转换。

同样，个人与AI讨论产生的新想法，可以进入提案或草稿，却不能直接覆盖团队已经批准的版本。探索空间与执行空间需要分开。

冲突不是系统故障，无法处理冲突才是

即使架构良好，事实冲突仍会发生。不同来源可能更新时间不同，人也可能确实改变决定。

可靠系统不应假装所有内容天然一致，而应把冲突暴露出来：两个有效文件给出不同日期时停止生成；新决定尚未批准时保持待定；资料来源不清时要求补充，而不是由模型选择最顺畅的版本。

解决冲突需要指定的责任人和规则。技术系统可以检测差异，却不能总是决定哪个现实应当成立。发布日期冲突最终可能需要项目负责人决定；法律解释冲突需要合格专业人员判断；数据冲突需要回到采集和治理过程。

结论：共同事实是一项持续维护的工作

多个人和多个AI可以显著扩展团队能力：并行研究、快速生成、自动执行和跨领域协作都因此成为可能。但参与者越多，局部上下文越容易分裂，摘要越容易丢失限定，错误越容易被其他系统当成既定事实。

单一事实版本不会由最聪明的AI自动产生。它需要组织明确：哪个系统保存什么，哪些记录具有权威，谁能修改，变更怎样传播，冲突由谁解决。

因此，答案不是让一个AI掌握所有全貌，而是建立一套任何参与者都必须遵守的事实结构：

AI可以发现、提取、比较和建议；正式事实必须有来源、状态、版本和有权批准的人。

团队不需要所有人记住同样的内容，也不需要所有AI共享全部对话。它需要的是，当不同工作重新汇合时，大家能够回到同一个可以核查的现实。

维持共同事实不是资料整理的后台小事。它是多人和多AI真正能够共同工作的基础设施。

主要资料

继续阅读：浏览《AI进入工作之后》系列文章

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。