Cognition / Devin：上下文工程原则
概述
Walden Yan（Cognition，Devin 的开发团队）发表了《Don't Build Multi-Agents》一文，对当前多智能体架构盛行的趋势提出了质疑。文章认为，决定智能体可靠性的核心因素是上下文工程（context engineering），而非智能体数量，并指出粗放式的多智能体设计会系统性地违反让智能体保持可靠所必须遵循的两条原则。
"上下文工程……实际上是构建 AI 智能体的工程师的第一要务。" —— Cognition
两条核心原则
原则一：共享完整上下文——完整的智能体执行轨迹，而非单条消息
当子智能体只收到摘要或一条描述子任务的消息时，它们缺乏上游决策的完整上下文，容易对任务产生误解，导致输出结果与整体工作不符。
示例：一个被要求"开发 Flappy Bird 克隆版"的智能体将任务分解给两个子智能体。子智能体 1 误解了子任务，开发出类似《超级马里奥兄弟》风格的背景；子智能体 2 则开发了一只不像游戏素材的小鸟。编排者最终不得不拼接两段各自出错的结果。
仅仅将原始任务复制给子智能体并不能解决这一问题——在真实的多轮生产系统中，智能体已经进行过工具调用、积累了上下文，并做出了影响子任务解读方式的隐性决策。
原则二：动作隐含决策——决策冲突导致结果劣化
当子智能体在未能看到彼此工作的情况下并行运作时，它们的行动所依赖的假设往往互不兼容。即使每个子智能体单独产出的结果都合理，合并后的结果仍会出现不一致。
示例：两个子智能体独立开发同一 UI 的不同部分，各自选择了不同的视觉风格、组件库和交互模式。单独来看各没有问题，合在一起却完全无法使用。
Yan 认为，这两条原则至关重要，任何违反其中之一的架构都应默认予以排除。
推荐架构
单线程线性智能体（默认方案）
最简单的方案：单个智能体、连续上下文、顺序执行。上下文始终保持完整，因此不存在协调问题。这种方式的效果往往超出大多数团队的预期。
局限：对于规模极大的任务，上下文窗口可能溢出。
基于压缩的扩展方案
对于真正长时运行的任务，引入一个专用的压缩模型，其用途是将历史动作与决策提炼为关键细节、事件与决策记录。这一过程很难做好——Cognition 专门为此微调了一个小模型。
该方案的优势在于：智能体能处理更长的上下文，同时避免多智能体系统的协调问题。局限在于：最终仍会触及上下文上限，而压缩质量直接决定了系统可靠性。
真实智能体设计案例分析
Claude Code 子智能体
截至 2025 年 6 月，Claude Code 会派生子任务，但从不让子智能体与主智能体并行运行。子智能体的职责仅限于回答问题，而非编写代码。原因在于：子智能体缺乏主智能体的完整上下文——它能回答定义明确的问题，却无法安全地做出影响整体代码库的决策。子智能体的优势在于，它们的调查工作不会积累在主智能体的历史记录中，从而延长了主智能体在溢出前的有效上下文长度。
Edit Apply 模型（历史方案）
2024 年，许多编码智能体采用双模型模式：大模型输出描述期望代码变更的 Markdown 说明，小模型据此重写文件。这一设计试图将决策与执行分离，但十分脆弱——由于措辞上的细微歧义，小模型频繁误解大模型的指令。如今，决策与执行更多地由单个模型通过一次动作完成。
多智能体协作（当前状态）
Yan 对 2025 年的多智能体协作持怀疑态度："让多个智能体协同运行只会产生脆弱的系统。决策过于分散，上下文也无法在智能体之间充分共享。"
跨智能体上下文传递问题尚未得到解决。Yan 预计，随着单线程智能体在与人类沟通方面的能力不断提升，同样的通信效率最终也将解锁可靠的多智能体协作。
与其他方案的关系
Cognition 的立场比 Anthropic 的多智能体研究系统更为保守——后者已在广度优先研究任务中成功使用并行子智能体。关键区别在于：
- 研究任务（Anthropic 的用例）：子智能体探索相互独立的方向，依赖关系极少。由于子智能体无需就共享决策进行协调，上下文冲突尚在可控范围内。
- 编码/构建任务（Cognition 的用例）：子智能体必须做出影响共享制品的决策。上下文冲突会造成灾难性后果，因为决策不一致会产生无法使用的输出。
Lance Martin（LangChain）在 open-deep-research 的设计中也体现了这一思路：子智能体仅限于信息收集，不参与决策，目的正是为了规避 Cognition 所描述的协调问题。