多智能体协作总掉链子？答案是把计划写进文件

一位既是两个孩子的父亲、又是AI工程师的开发者，在业余时间用一支AI智能体团队制作面向幼儿的舒缓视频。他的经验揭示了一个多智能体系统里容易被忽视却极其关键的问题：当计划只存在于聊天上下文里，智能体会悄悄遗忘细节。 而他最终的解决办法，用他自己的话说，无聊得出奇——把计划写成文件。

一个业余项目暴露的真实痛点

这位开发者的初衷很朴素：市面上给幼儿看的内容太吵、太快，节奏刺激。他想给自己的两个孩子做点不一样的东西——慢节奏的歌、柔和的色彩，固定三个角色（一只毛毡刺猬、一只兔子和一只小鸭子）。

他没有手工制作动画，而是搭建了一支小型AI智能体团队，每个智能体只负责一件事：

• 一个负责规划故事节拍（story beats）
• 一个负责生成静态图像
• 一个在花钱把图转成视频之前检查每一张静态图
• 一个负责把片段拼接成成片

这种"单一职责"的拆分本身是合理的多智能体设计，但真正的麻烦出现在它们如何共享计划上。

把计划放在聊天里，是最初的错误

项目最初几周，整个计划都"活"在对话上下文中。作者直言这是个错误。

问题的根源在于大语言模型的工作方式：智能体会对旧消息做摘要，并在这个过程中悄悄丢掉细节。 结果就是一系列诡异的"漂移"：

• 一只本不该出现的第二只兔子突然出现在架子上
• 被明令禁止的道具又回来了
• 场景顺序在两次会话之间自己重写了

更致命的是发现时机——他往往是在已经付费生成视频之后才注意到这些错误，而视频生成恰恰是整个流程里最烧钱的环节。换句话说，上下文遗忘不只是质量问题，而是直接转化成了金钱损失。

这实际上点出了当前多智能体系统的一个共性缺陷：聊天上下文不是可靠的状态存储。 它会被截断、被摘要、被重新解释，无法作为长期项目的"事实来源"。

大语言模型处理长对话时，并非无限制地保留所有历史消息。当上下文长度接近模型的处理窗口上限（context window limit）时，系统通常会自动对早期消息进行压缩或摘要（summarization），以腾出空间容纳新内容。这个过程本质上是一种有损压缩：摘要会保留主题和大意，但会丢掉细节——比如"架子上只能有一只兔子"或"禁止出现气球道具"这类具体约束。多智能体场景下问题更为严重，因为每个智能体都有自己独立的上下文窗口，它们读取的"历史"可能各不相同，导致不同智能体对同一计划产生不同理解，最终呈现出"漂移"效果。这种现象在业界通常称为"上下文漂移"（context drift）或"指令遗忘"（instruction forgetting），是目前基于LLM的长周期任务系统的主要工程挑战之一。

无聊但有效的解法：让文件成为契约

作者的修复方案没有任何炫技成分。现在，每一集视频都配有几个"无聊的文件"：

• 角色是谁、长什么样
• 场景的先后顺序
• 屏幕上允许出现什么、禁止出现什么
• QA智能体在每一张静态图上运行的检查清单

核心规则只有一句：智能体读文件，不读聊天。聊天用来交流，文件才是契约（the files are the contract）。

这一转变带来了几个立竿见影的改善：

QA变得可执行。 检查智能体现在能说出"架子上的那只兔子必须消失"这样明确的指令，而不是含糊的"这感觉不太对"。判断标准从主观感受变成了对照文件的客观校验。

卡点前移到便宜的环节。 任何静态图必须先匹配文件，才能进入昂贵的视频生成阶段。错误在花钱之前就被拦下。

新智能体即插即用。 一个新加入的智能体只要读文件就能立刻进入状态，不需要回滚40条聊天记录去理解上下文。

这种做法在软件工程中有一个对应的概念——"单一事实来源"（Single Source of Truth，SSOT）。传统软件开发中，配置文件、数据库 schema 或 API 合同（contract）承担着这个角色：所有模块都从同一个权威来源读取规则，而非各自维护一份副本。作者把计划写成文件，实质上是把这一成熟的工程原则移植到了AI智能体协作中。与之相近的概念还有"基础设施即代码"（Infrastructure as Code）的思路：把原本存在于人脑或口头沟通中的约定，显式编码为可版本控制、可审查、可回滚的文本文件。对于AI系统，文件还有额外的优势：它不会因模型的采样随机性而被重新解释，每次读取得到的内容完全一致，具有确定性。

对多智能体工程的启示

这个案例虽然来自一个业余的儿童视频项目，但它揭示的原则对任何长周期、多智能体协作都适用。

状态与对话分离。 把"计划"和"沟通"分开，是避免上下文漂移的关键。对话天然是短暂、有损的；而项目的约束条件需要一个持久、无损、可校验的载体。

约束要可校验，而非可感受。 把"允许/禁止"清单显式写下来，让QA环节从模糊判断变成清单核对，这本质上是给智能体系统引入了确定性的"单元测试"。

在最便宜的环节设卡。 作者把校验放在图像阶段而非视频阶段，本质是一种成本感知的流程设计——越贵的操作，前置校验越要严格。

作者最后抛出了一个值得所有从业者思考的问题：如果你在一个长期项目上运行多个智能体，你把计划存在哪里？是文件、数据库，还是干脆信任聊天记忆？

从他踩过的坑来看，答案已经很清楚——不要相信聊天记忆。 给你的智能体团队一份可读、可校验、持久化的"契约"，往往比任何复杂的记忆机制都更可靠。

作者提到的"在最便宜的环节设卡"，呼应了软件质量保证领域的一个经典原则：缺陷发现越晚，修复成本越高。在传统软件中这被称为"左移测试"（Shift-Left Testing）——把测试和验证尽可能前置到开发流程的早期阶段。在AI生成流水线中，同样的逻辑意味着：文本校验 < 图像校验 < 视频生成，越靠后的环节单位成本越高，因此前一阶段未发现的错误会在下一阶段以更高价格被放大。作者把QA环节固定在静态图阶段，正是把这一原则显式化。对于任何涉及API调用费用、云计算资源或外部服务的AI流水线，识别各环节的相对成本并在低成本节点部署检查逻辑，是控制整体运营成本的基础工程实践。