我现在很少用一个 AI 从头推完一个项目。
复杂判断交给一个模型。重开发交给另一个。长期运行、低成本验证、定时任务，再交给第三个。能力、价格、额度和工具权限都不一样。人会自然地把它们当成不同工种来用。
这看上去很像给自己临时组了一支小团队。
团队多了，问题也跟着来了。
每个 AI 都能看到一部分材料，也都能给出一套看起来合理的解释。可一个项目只能有一份当前判断：现在要解决什么，哪些方向已经放弃，哪些话只是探索，什么改动必须等人确认。
没有这份共同状态，多个 AI 只是在轮流重新理解项目。
代码项目有一套现成的秩序
代码项目当然也会混乱，但至少有仓库、提交记录、PR、测试和可运行的结果。
新的人或新 Agent 接手时，能看到改了什么，测试有没有过，哪次提交引入了问题。Git 不能替团队做判断，却给判断留下了痕迹。
很多 Agent 协作方法也是从这个世界长出来的。任务拆分、代码审查、测试、回滚、工作区隔离。它们默认项目有一个明确的交付物，最后可以运行、报错或通过验收。
有些工作，交付物并不能解释项目
策略、营销、内容、研究、提案和运营工作常常不一样。
它们最后也会产出方案、文章、PPT 或机制，但这些东西只记录了最后版本。它们很少告诉后来的人：
- 当时为什么从 A 改成 B；
- 为什么一个看上去不错的方向被放弃；
- 哪条信息只是猜测；
- 哪个前提一旦变化，整套方案就该重看。
这类工作的难点，往往发生在执行前。人先要把问题定义出来，再决定边界、取舍和判断标准。很多时候，最有价值的劳动就是这一段。
我把它叫作判断型知识工作。
这不是说写代码的人不判断，也不是说做策略的人不执行。区别只在于：有些项目的核心难点，能被一个可运行的交付物检验；有些项目的核心难点，是在信息不完整时先形成一个足够好的方向。
多模型协作与 Agent 接力，放大了这个缺口
一个 AI 推错方向，人还能在同一段聊天里把它拉回来。
几个 AI 接力时，错误会更安静。后一个 AI 读到一段旧总结，把它当成当前事实；它再生成新的计划；下一个 AI 又把这份计划当成项目共识。
最后没人故意犯错。每一个步骤都很合理。项目却慢慢按一个已经过期的判断往下走。
这也是我最近开始在项目里保留判断记录的原因。它不需要替人做决定，但要把一件事留住：这个判断是谁在什么条件下提出的，什么材料支持它，什么还没有确认，什么情况下应该推翻它。
研究所关心的不是“记忆功能够不够强”。更麻烦的问题是：当多个 AI 都能写、都能总结、都能提出下一步时，人还能不能看见自己的判断是在哪一步被改写的。
人还保留什么
多模型协作不会自动削弱人的作用。它会把人的作用挤到更少、也更关键的位置。
人不必逐行检查每个输出。但人需要保留几件事：
- 项目要解决什么；
- 哪些边界不能碰；
- 哪些推断还不能当事实；
- 哪些结果足以改变原来的判断；
- 最后由谁确认项目可以往下走。
这些事情如果也交给 AI 自己维护，项目会显得很顺。它也会越来越难区分，哪些是你真正决定的，哪些只是某个模型写得足够像决定。
未来人和 AI 的协作，可能不再只是“选一个最强的模型”。更常见的画面是：一个人调度几个不同的智能系统，把它们放进同一个项目里。
到那时，最基础的问题也许是：
> 当三个 AI 都说自己理解了项目，谁能证明它们理解的是同一件事？
这是一个正在发生的协作问题。它还没有一套成熟的非代码工作答案。
研究所备注
这篇来自长期多模型项目协作中的观察，不是一项用户研究结论。文中“判断型知识工作”是研究所暂时使用的工作分类，用来讨论策略、内容、营销、研究、运营和提案等项目如何与 Agent 协作。
我们正在验证什么
这篇文章里的方法，正在通过 FlowGrid 做本地实验：把当前判断、被否定的路径、未验证假设、审核边界和证据来源留在项目中，供下一位人或 AI 核对与接手。
它仍处于验证阶段，不代表已经解决多 Agent 协作。你可以查看代码和使用说明，自己判断它是否适合你的项目。