Don’t Build Multi-Agents | Cognition

这次我们同时看两篇文章，进行对照

Intro

reseach型任务的特点：

• 很难提前预测所需的步骤
• 无法有既定的路线，在探索过程中的思路涌现会带来新的分支

这类任务需要从海量的信息中搜索出关键内容（本质是压缩）

• 串行的单Agent的上下文与工具调用很难支持完成整个任务
• 多Agent系统支持单个Agent用更干净、更充分的上下文窗口去处理分支任务

因此多Agent系统在此类任务中能够呈现惊人的性能提升

缺点是：消耗了更加大量的token、进行了更多轮次的工具调用

但这也是性能提升的核心原因

总结：

• 需要高度并行
• 信息量超过单次上下文窗口
• 需要对接大量复杂工具
• 所有Agent涉及的上下文重叠较小、无复杂依赖关系

这个时候推荐使用多Agent

Architecture

设计一个Research Agent System

采用orchestrator-worker模式

• 主导Agent协调整个流程
• 任务运作交由专门子智能体

用户需求：调研100家2025年美国的AI Agent公司，给出列表

• Lead Agent分析查询、制定策略，生成subagents探索
• subagents迭代使用搜索工具收集信息，并且完成过滤，返回lead agent

• User->System：创建一个Lead Reseacher，进行迭代Process
• Iterative Research Process
• think进行planing，将plan保存到memory中（创建or修改）
• 检索memory，避免plan丢失
• 创建subagents，内部进行独立的搜索与评估
• 返回压缩后的结果
• Lead评估是否足够，否则继续调研

Prompt

多agent相对于单Agent的协调复杂度急剧增加

每个Agent都是由Prompt驱动的，因此需要注意Prompt的一些原则

• 为每一个Agent构建完全相同的提示词+工具做模拟环境测试，理解工作过程
• Lead需要为每个subagent清晰分配任务，防止重复劳动与遗漏
  • 提供明确目标、输出格式、工具、资源使用指南、清晰任务边界
• 根据问题难度自动控制投入的资源（多少个Agent、多少次工具调用）
  • 直接在Lead Agent中的Prompt写明资源分配规则
  • 例如
    • 简单事实查询（xxx家CEO是谁）：1个Agent3-10次Tool Calls
    • 直接对比类任务（比较 Claude 和 Gemini 的企业功能差异）：2-4个Agent，每个Agent负责一个维度，每个Agent需要10-15次Tool Call
    • 复杂研究问题（分析 AI 编程助手市场格局、主要玩家、商业模式、技术趋势和未来机会）：超过10个
• 在Prompt中添加启发式的工具使用原则
  • 正确的工具选择非常重要，MCP带来了海量工具，造成了困难
  • 启发式规则
    • 首先检查所有可用工具
    • 根据用户意图匹配工具
    • 广泛的外部探索搜索网络or优先使用专用工具而非通用工具
  • 优先确保工具描述质量
• Agent本身建议参与优化过程
  • Agent改自己的Prompt、测试工具问题、分析失败案例都很擅长
  • 用Agent来改进Agent的工作环境
• 先广泛搜索再逐步聚焦
  • 通过提示词要求Agent先从简短的、宽泛的查询开始
  • 评估可用信息，缩小范围
  • 抵抗Agent偏好冗长、具体的查询
• 显式引导Agent怎么思考，高效利用thinking token
  • Lead Agent主要思考如何管理任务，subagent主要思考工具怎么交替使用
  • 结构化思考流程
    • 先规划，再调用工具
    • 看完工具结果后再评估、补缺、调整下一步
• 并行工具调用
  • 主智能体并行启动 3-5 个子智能体，而非串行执行
  • 子智能体同时使用 3 个以上工具

评估

Agent达成目的路线完全不确定

早期 · 小样本

早期上升空间巨大，一个提示词调整可能30%到80%

早期构建的时候准备20个真实查询进行测试即可

不要为了构建完整评估体系才开始行动

LLM-AS-JUDGE

• 事实准确性（主张是否与来源一致？）
• 引用准确性（引用的来源是否支持主张？）
• 完整性（是否涵盖所有要求方面？）
• 来源质量（是否优先使用一手资料而非低质量的二手资料？）
• 工具效率（是否以合理次数使用正确工具？）

Antropic发现单一提示词输出0.0-1.0分数or正负分类

与人工判断的一致性最高

当存在明确答案的时候，使用LLM评测非常有效

只需要判断与答案是否一致即可

Human Eval

人工测试能够帮助发现一些偏差，因此必不可少

人类似乎更喜欢SEO优化得到的内容，而不是一些个人博客

因此可以通过这个偏好去调整提示词

Production reliability

• Agent错误

  • 需要做持续化执行，存到本地，防止错误重新开始
  • 中断点恢复，根据持续化的存储结果继续工作
  • Agent参与错误处理：告诉错误信息，让模型更换路线
  • 确定性的保护措施：失败后自动retry、定期做check

• 调试：Agent中间路径不确定

  • full production tracing（完整的生产追踪）
    • 传统指标：延迟、错误率、CPU、内存
    • 结构化信息：决策记录、工具记录、任务分派记录、失败记录、重试记录

• 部署

  • 新版本代码部署的时候很难逐步替换旧版本代码（智能体可能正在运行）
  • rainbow deployments：新旧版本同时运行，但是新来的流量导入到新版本，直到旧版本Agent没有调用

• 同步

  • Lead Agent需要等待所有subagent完成任务
  • asynchronous execution
    • Lead边接受边调整方向，必要时动态创建
  • 但确实会更难协调、容易冲突

Avoid

基于cognition.ai这一篇文章

常见的多Agent范式如图，但是这种架构非常脆弱

任务：抄袭一个《Flappy Bird》

• 子任务1：构建一个带有绿色管道和碰撞箱的动态游戏背景
• 子任务2：构建一只可以上下移动的小鸟

结果

• 子任务1：建一个看起来像《超级马里奥兄弟》的背景
• 子任务2：构建了不像游戏素材的鸟

最终Lead Agent将错误内容完成合并

这个问题并不能通过简单的将原始任务中的上下文完全塞给subagent解决

注意，对话是多轮的，subagent需要自己去调用工具

任何细节差异都可能带来对任务不同的理解

Principle

• Principle1：完整的上下文轨迹必须共享

• Principle2：行动隐含决策

Agent的所有行动中自然包含了丰富的信息，若造成丢失则很有可能带来错误积累

MultiAgent并不能保证上述两个原则

最简单的方式只有：单线程的线性智能体

但是上一篇文章也提到了，单智能体会受限于上下文窗口的限制，性能也会触碰瓶颈

但我们显然可以通过压缩，尽量去保证上下文连续性

• 引入一个专门用来压缩上下文的LLM

因此：能不使用MultiAgent，就不要使用

需要衡量场景的可靠性是否大于并行性

Applying the Principles

如果无法完成两个原则的落实，则必须要考虑：

• 谨慎地决定哪些工作可以拆出去，哪些不能拆

例如：

• Claude Code设计的subagent只用来回答问题
  • 暗示：调查型任务可以拆出去，决策型/执行型任务要谨慎拆出去
• Edit Apply Models：大模型负责“决定怎么改”，小模型负责“实际应用修改”
  • 这种架构实际上非常高危：只要解释里有轻微歧义，小模型就可能误解并改错
  • 建议：同一模型先决定怎么改，然后顺着上下文直接完成修改
  • 暗示：不要把一个高度依赖上下文的决策链切成两个互相误解的环节
  • 除非提供非常详细的指导
• Multi-Agents：如果仍然需要并行性，则需要解决Agent之间及时沟通的问题
  • cross-agent context-passing（跨Agent上下文传递）目前能力一般
  • 建议：长期看好，短期不建议作为生产级默认架构

但是这些建议是跟随时代变化的

context engineering：系统性地设计、构建和优化提供给语言模型的所有上下文信息，目的是引导模型产生更准确、更可控的输出

人话：什么样的上下文最有可能让我们的模型产生期望的行为

Anthropic — Effective context engineering for AI agents

Context Engineering vs. Prompt Engineering

• 提示词工程：为LLM编写和组织指令文本
• 上下文工程：在LLM推理过程中，迭代优化Prompt（或是信息）的策略集合

由于LLM工程的复杂化，静态的提示词编写显然不能满足需求

Agent在循环过程中必然会不断产生对下一轮有用的信息，这些信息需要被及时优化

上下文工程贯穿了整个推理过程，动态维护了人类指令、历史对话、工具返回结果、外部检索，筛选出最能提升当前任务成功率的最优信息组合

Why context engineering is important to building capable agents

• 上下文衰减：大海捞针benchmark已经证明，上下文窗口中token越多，模型从上下文中准确回忆信息的能力确实会下降
  • 不同模型会有不同表现，但都客观存在衰减
  • 以及节省上下文能够节省成本

Transformer的Attention架构决定了注意力是平方级别

配对关系在长上下文自然会被稀释

训练数据中短序列也会比长序列更常见。尽管有RoPE（将32K放缩到4K），但是带来了位置模糊感

上下文衰减是渐变的而非断崖的

The anatomy of effective context

如何找到最优上下文的构成要素？

System Prompts

系统提示词既不能特别细致，也不能特别抽象，需要找到刚好能稳定引导智能体行为的高度

• Too Specific：在提示词中硬编码复杂脆弱的逻辑
• Too Vague：提供模糊笼统的高层指令

希望提示词是：既要足够具体以有效引导行为，又要足够灵活，为模型提供强有力的启发式指导

• 如果用户意图是 A，就问 3 个问题；如果是 B，就不要问；如果满足 5/7 个条件，就调用某工具……
  • 提示词中含有过于复杂的逻辑、业务流程
  • 真实场景一旦略有偏离，模型就容易误判
• 你是客服助手，要友好地解决客户问题，必要时升级给人工

核心原则：不要把 Agent 当成处理流程的程序，也不要把它当成充分理解业务的人。

好的提示词应该是一份清晰的岗位说明书+操作原则

• 身份
• 目标
• 边界
• 可用资源
• 决策标准
• 输出格式
• 少量例子

过于具体：

1如果用户问订单状态，先调用 A 工具。
2如果 A 工具失败，调用 B 工具。
3如果用户说“没收到”，判断是否超过 3 天。
4如果超过 3 天并且地区是美国，执行流程 X。
5如果地区是加拿大，执行流程 Y。
6……

过于模糊：

1你是一个客服助手。请友好、专业地帮助用户解决问题。

Just Right：

 1你是电商客服助手，负责帮助用户处理订单状态、配送、退款和商品咨询。
 2
 3目标：
 4尽快理解用户问题，使用可用工具核实事实，并给出清晰、可执行的下一步。
 5
 6工作原则：
 7- 在给出结论前，先确认订单、配送或政策信息。
 8- 如果信息不足，最多提出 1-2 个必要问题。
 9- 多个方案都可行时，优先选择对用户成本最低、成功率最高的方案。
10- 遇到政策例外、支付争议或安全风险时，升级给人工。
11- 回复应简洁、明确，避免暴露内部流程。

提示词可以组成不同的部分<background_information> 、 <instructions> 、 ## Tool guidance 、 ## Output description

• 追求用最少的信息完整勾勒出预期的行为模式（但不代表简短）

• 先用一个精简提示测试最优模型，根据失败模式继续优化

其实这里的意思就是不要希望穷尽所有可能分支

留一部分判断力给模型即可

你需要充分考虑实际业务需求，对于确定的内容可以写明应该先……再……

Tools

工具必须通过返回 token 高效的信息以及鼓励高效的智能体行为

确保人类也看得懂，明确在什么情况应该使用什么工具

建议为工具提供示例，但不要塞入大量边缘案例（试图穷尽规则）

应该精心挑选一组多样化、具有代表性的示例，有效展现智能体的预期行为

示例用于为模型补充说明工具可以达到什么样的效果

而不是告诉模型什么情况应该用什么

Context retrieval and agentic search

如何在运行时动态检索上下文

转生为Agent高手(一)Anthropic - Building Effective Agents | BiribiriBird

这篇文章以及探讨了workflow和agent，其中将agent定义为：LLM能够在循环中自主使用工具

随着LLM性能上升，业界趋近于这一范式

对于检索，之前基本是基于嵌入方法做推理前的检索

由于逐渐开始关注agent的自主性，越来越多团队通过即时上下文策略来增强这些检索

• 不再像嵌入方法一样对整个相关数据做预处理，维护轻量级的标识符
  • 文件路径、URL……agent只需要知道数据在哪
• 模型通过工具动态加载、引用数据到上下文
  • head、tail

与人类认知相符：不会记忆整个信息库，而是根据外部组织、索引方式进行检索

文件夹层级结构、命名约定和时间戳，能够帮助人类和智能体理解如何以及何时利用信息

• test/test_xxx.py和src/xxx.py本身就暗示了用途

Agent应该自主进行检索，渐进式揭示上下文

• Agent探索发现上下文，每次交互产生影响下一步的上下文
  • 文件大小：暗示复杂度
  • 命名约定：暗示用途
  • 时间戳：暗示相关性
• Agent逐层理解，保留必要信息，利用笔记策略持久化信息

减少上下文浪费、动态适应环境，渐进式加载上下文好处确实很多

代价是探索带来的时延，需要多轮工具调用：查看目录、搜索、打开文件、筛选、再搜索……

非常依赖工程设计，需要对工具文档进行良好的设计与规范

因此设计的核心是：设计一个能让 Agent 有效探索的信息环境

为了平衡效率

• 一部分信息可以提前放入上下文，用来提高启动速度。
• 一部分信息动态加载披露

CLAUDE.MD会预先放入上下文，提供项目规则、约定、重要说明

glob、grep 等工具让模型可以在运行时搜索文件、定位代码、按需读取内容

这种组合方式更加平衡

• 内容变化慢（法律、金融……）：材料相对稳定，适合混合策略
• 内容变化快（代码、实验日志）：材料变化多，适合更多的自主探索

自主探索的设计同样基于最小可行原则：

• 根据必要信息、少量高价值工具先做
• 根据失败补充规则增加、索引、缓存、自动化流程

总结：

• 好的Agent按需探索环境
• 纯自主探索成本高、容易跑偏，更好的方案是混合模式：关键上下文预加载 + 工具驱动的实时探索

long-horizon tasks

对于长周期的任务，我们需要保证token数量不能超过最大的上下文窗口

并且上下文需要保持连贯性、上下文感知和目标导向行为

虽然可以等待技术更新，上下文窗口变得更大

但是追求性能的条件下，上下文污染和信息相关性问题的困扰必须要解决

提供了以下几种方案

Compaction

压缩是最首要的手段：在接近上限时，对当前内容进行总结

以总结内容为基础，重新启动新的窗口

Claude Code通过接受消息历史记录，总结提取最关键的信息：

• 架构决策
• 未解决的bug
• 实现细节

需要丢弃冗余的工具输出、消息

新窗口只保留压缩后的上下文+最近访问的一些文件

压缩的艺术在于取舍。过度压缩会丢失一些细节（但可能到后期才能显示关键）

因此有一个常用的指标：召回率

确保压缩提示能捕捉到追踪数据中的每一条相关信息，然后通过消除冗余内容来迭代提升精确度

比较简单的做法就是：清空掉工具调用与结果

如果模型已经看过结果并且利用过了，那其实就不需要再看一遍。

Structured note-taking

结构化笔记（或称为记忆），定期将笔记持久化存储到上下文窗口之外的技术

一些信息被压缩时，不如直接丢到文件里，后续如果要使用再加载回来就好

对于长期的任务计划、进度，最好是保存到文件里，这样非常可控

记录当前计划走到哪一步了，也能明确知道下一步要做什么，目标是什么

在上下文压缩后，读取永久化记忆确保了上下文的连续性

Sub-agent architectures

子Agent是一个独立、干净的新Agent，不受到之前上下文的影响

与其让单个Agent吃掉一堆上下文，不如就新开一个Agent深入工作，想用多少就用多少

并且只返回最后的结果摘要，完全不会污染上下文

• 详细的搜索上下文被隔离在子代理内部

• 主代理则专注于综合和分析结果

What

Workflow和Agent的差异还是很大的

Antropic将其都归纳为一个Agentic Systems

• Workflow：由代码决定每一步应该做什么，LLM只是其中的一环
• Agent：LLM自主决定每一步应该做什么

When and When Not

Timing

Antropic并不建议什么情况下都去做一个复杂的Agentic System

应该先尝试最简单的方案，再逐渐增加复杂度

• 质量上升的同时，成本、延迟也会逐渐上升

决策顺序

• 第一层：单次LLM调用
  • 多数应用 retrieval and in-context examples就足够了
• 第二层：Workflow
  • 任务步骤多、且明确、可预期
• 第三层：Agents
  • 任务需要灵活决策
  • 任务没有固定路径，需要动态决定每一步
  • 成本上升、难以预测、响应慢

帮我调研某个市场，找出潜在客户，比较竞品，并输出进入策略。

复杂度是需要有收益的

Frameworks

当简单的方案足够解决问题时，复杂的框架可能会带来不必要的复杂性

能够通过LLM API直接实现，就尽量不要做太多事情

使用框架应该确保能够理解底层代码

Building Blocks, Workflows, and Agents

从简单的组合工作流到自主智能体

Block

定义为一个能够调用外部能力的最小单元

augmented LLM = LLM + 增强能力

• 检索能力
• 工具调用
• 记忆读写

或者说是一个增强的LLM，The Augmented LLM

不管是workflow还是agent，都需要其作为最小单元进行组成

Block并不等于Agent。取决于外层组织方式

• 总结这篇文章：系统让LLM检索文章内容并且总结（Block）
• 完成调研：LLM需要先决定要查询资料、整理资料、总结分析，在这个基础上开始决定查什么资料、调用什么、多轮分析给出完整报告（Agent）

总结一下：

• 裸 LLM：只根据 prompt 输出文本
• 增强型 LLM：可以检索、调用工具、使用记忆
• Workflow：把多个增强型 LLM 调用按固定结构组织起来
• Agent：让增强型 LLM 在循环中自主规划、调用工具、根据反馈调整

• 增强LLM：针对当前任务，自己决定需要检索什么、调用什么……完成单次任务
• Agent：具备任务流程基本的控制权，能够决定整个任务如何继续推进

构建这样的LLM需要：

• 明确LLM工具集，应该接近任务本身，不要给无关的工具
• LLM工具接口简要、清晰、文档明确

例如：MCP

后文提到的所有workflow和agent，每次LLM调用都默认是带有检索、工具、记忆能力的augmented LLM

Workflow

workflow并不是简单地多次调用模型

每次模型调用都应该有清晰的输入、职责、可用能力

提供五种workflow设计模式

Workflow1: Prompt Chaining

最简单的workflow，数据沿着链条通过每一个LLM的prompt

任务能够被切分为顺序的一系列步骤

每个LLM处理前一个LLM的输出

可以在任意步骤之间添加一个Gate，保证任务正常流动

具备以下特点的任务常使用此workflow

• 任务可以轻松且清晰地分解为固定子任务
• 能够通过让LLM每次处理更简单的子任务，以延迟换取更高的准确性

任务示例

• 生成营销文案，然后将其翻译成另一种语言。
• 撰写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档。

Workflow2: Routing

在纯Chain的基础上增加了一些分支结构

显然有时候单份提示词并不能充分完成一个任务

或许我们可以对任务进行分类，不同类型任务使用不同提示词完成

• 按任务类型进行分类：使用不同提示词
• 按任务难度进行分类：使用不同模型节约成本

Workflow3: Parallelization

• 如果能将任务拆分成独立的子任务
• 希望获取同一任务的多样化输出结果（投票）

那么我们可以并行化

• 独立子任务
  • 一个LLM处理查询
  • 一个LLM处理安全审核与防护
• Voting
  • 使用多个不同提示进行code review
  • 多个提示词不同方面or不同阈值做评估

Workflow4: Orchestrator-workers

似乎就是Planner

当子任务无法预先定义的时候，我们可以考虑设置一个Orchestrator做分工

Orchestrator：管弦乐演奏家；管弦乐编曲家

可以理解为编排器、指挥、协调器

与并行化最大的区别：子任务由协调器根据具体输入动态确定

• 对多个文件进行复杂修改
  • 需要分工出不同线路对不同文件单独做不同修改
• 从多个来源做信息搜集

这里会觉得像Agent？

但是仍然是定死了先编排，再分工

Agent可以自己决定使用哪一套workflow与任务安排

Workflow5: Evaluator-optimizer

似乎就是Reflection

一个 LLM 调用生成响应，而另一个则在循环中提供评估和反馈

• 拥有明确的评估标准，迭代可以带来价值优化
  • 人类能为LLM输出提供反馈
  • LLM能通过人类反馈进行打磨提升

满足这两个条件，就可以考虑让模型做评估优化

• 文学翻译：LLM不断发现细微之处进行改进
• 多轮搜索：LLM决定是否继续搜索

Agent

• Step1：根据人类指令或互动讨论开始工作
• Step2：自主规划，开始运作（必要时返回给人类）
• Step3：执行过程中，必须从每个步骤处获取真实情况（工具调用结果or代码执行结果），评估进展
  • 在检查点or障碍处进行暂停，询问人类
• 任务完后终止，或设置停止条件（例如最大迭代次数）

何时使用：

• 难以预测步骤数量
• 无法硬编码固定路径
• 开放问题

同时：Agent高度自主，因此最好在沙盒中，设置防护措施

防止错误累积

核心：基于环境反馈循环使用工具

因此工具集和文档的设计至关重要

Summary

Combining and Customizing

其实不需要过度在意所谓的规范，应该根据实际场景使用具体范式

关键：衡量性能与实现

只有能切实改善结果时，才会增加系统复杂性

Principles

从简单的提示词开始，通过全面评估进行优化

遵守三项原则

• 简洁性
• 透明度：展示智能体的规划步骤
• 把工具设计成模型容易理解、容易正确使用、容易从错误中恢复的形式
  • 一定要方便调试

Appendix

Customer support

与客户交互天然适合使用Agent，非常推荐从chatbot升级到agent

• 客服：天然是聊天界面
• agent 比普通 chatbot 多了工具能力

同时agent通过与客户交互过程中了解用户需求，明确动作

• 对于客户数据、订单历史记录和知识库文章
  • 可以通过工具调用进行获取，获取信息后作为上下文
  • 但这里的操作比较松弛
• 对于退款、更新工单等写操作
  • 非常危险，需要由业务代码进行校验
  • 应当设计一个代码接口（内部需要进行非常严格的参数校验，必须由程序化代码来保证权限、规则、确定性和审计）
  • 最后暴露给模型的一般是一个函数接口

并且该类任务容易获取是否成功：通过客户反馈

Coding Agent

• 代码方案可以设计测试代码检验
• 通过测试结果反馈迭代
• 问题定义明确
• 输出指令可以客观衡量

Tool

对于工具集文档的书写非常重要，甚至比任务提示词更重要

这里可以称为：Agent-Computer Interface

• 降低认知负荷
  • 让模型在输出格式化结果前，有足够的token进行思考
  • 避免复杂格式限制
    • json里写代码需要对换行、双引号进行痛苦转义
• ACI接口要让人类都能看得懂
  • 清晰的边界、对待初级程序员
• 防呆设计（例如CPU的防呆卡槽会让你无法装反CPU）
  • 从工具的底层逻辑和参数设计上，让模型“根本没有犯错的机会”
  • 例如：模型不擅长相对路径，那就要求模型全部输出绝对路径