Multi-Agents

发表于

Don’t Build Multi-Agents

Cognition
构建长期运行的AI智能体系统，需要解决“可靠性”问题：

  1. 上下文丢失、过长
  2. 状态混乱
  3. 错误累积

例如，Multi-Agent思路需要构建规划Agent、解释Agent、执行Agent、SOP Agent。
然而，如果仅仅使用两个独立Agent，其生成结果会更加独立、隔绝，而不是相关联。
整体大于局部。局部的完整性不能保证整体的一致性。

Shared Data

Principle 1: Share context, and share full agent traces, not just individual messages.

我们希望通过共享上下文解决一致性问题，但是不行。
Agent1和Agent2都是基于自己对Shared Data的理解工作，而不知道对方在做什么。
因此我们需要共享Traces，让一个Agent（例如解释Agent）对另一个Agent（例如执行Agent）进行Revision校正。
可是，只有垂直矫正，水平的Agent（多个执行Agents）之间仍然不知道对方在做什么。

Actions mean desisons

Principle 2: Actions carry implicit decisions, and conflicting decisions carry bad results.

每个Agent的行为都必须基于同样的预期结果，而不能基于不清楚、有歧义的预期结果；否则整体很难保持风格统一。

Single-threaded Linear Agent

鉴于上面两条，作者选择使用单Agent线性解决问题。
然而，这样做容易产生context windows overflow上下文溢出（因为线性Agent其实就是不断附带上一次的上下文进行下一次chat）。
我们引入总结压缩LLM解决上下文问题。

Claude Code设计模式

Calude Code的智能体有两个特点：

  1. 主Agent与子Agent不会并行运行
  2. 子Agent只回答简单问题，而不会编写代码
    这样做有几个优点
  • 避免上下文冲突：子Agent不包括主Agent的上下文，只回答清晰、具体的问题。
  • 节省上下文：子Agent的操作也不保存在主Agent的上下文中。他们是解耦合的。

How we built our multi-agent research system

How we built our multi-agent research system
三种AI模式：

  1. Chat AI
  2. Single Agent
  3. Multiple Agents
    Multi-Agents的优势在于回答开放、不确定的问题。传统的单Agent不适合研究，而多Agent并行搜索，最终总结出来的信息压缩性更强。

The essence of search is compression.

Anthropic团队区分了两种模式：

  1. 垂直模式：容易并行处理的任务，Leader Agent与多个Sub Agent交互
  2. 水平模式：不容易并行的任务、需要上下文共享的任务、Agent依赖强的任务，如编程，Leader Agent一步一步执行Sub stage

Agent模式的token使用量是Chat模式的4倍；而Multi-Agent则是Chat模式的15倍。
Multi-Agent让token用量增加，因此更可能解决问题。同时也带来的高成本。

Prompt Engineering

  1. Think like your agents.
  2. Teach the orchestartor how to delegate.
    例如，子问题如何划分？怎么确定它就是任务的最小可执行单元？
    可以使用 明确预期结果-example输出格式-可用资源tools-任务边界不要做什么 这一套指令。
  3. Scale effort to query complexity.
    为prompt嵌入scaling rules，明确指出简单-中等-复杂任务分别分配多少subagents。这一条主要是做减法，对简单任务指定少agent，节省成本。
  4. Tool design and selection are critical.
    Tool Description要够好，否则Agent可能不会调用需要的MCP工具。
  5. Let agents improve themselves.
    使用tool-testing agent，让agent改进失败的prompt和流程、重写工具描述等。
  6. Start wide, then narrow down.
    这一条是因为Agent自己的搜索词写的比较AI，太长了，返回的结果很少。需要提示AI使用宽泛的提示词，然后再窄化范围精确搜索。
  7. Guide the thinking process.
    这一步是打印日志，让AI把思考过程打成标记、大纲、ToDoList，这样方便修改。
  8. Parallel tool calling transforms speed and performance.
    主Agent平行分派任务给子Agent；子Agent并行调用Tools。

Eval Agents

Multi-Agents的过程可能每一次都不同，因此不能使用传统的评估方法。

  1. 小样本评估。不要等到测试用例足够多才开始测试，边测试边修改效果更好。
  2. LLM评估。给出判断标准（事实/引用准确性、完整性、来源质量、多余/无效工具调用…），让LLM量化评估（0.0~1.0打分）
  3. 人工检查遗漏。如AI是不是只使用SEO靠前的，而不是权威的网站。

需要注意，Multi-Agents会产生涌现(Emergent Behaviors)，对Leader Agent的改动会影响Sub Agent。

Multi-Agent框架最好考虑下面几个方面：

  1. 工作分工（规划、解释、执行、自愈、总结）
  2. 问题如何分割成子问题（确定可执行标准）
  3. 效率（时间预期、工具调用次数限制、Scaling rules）

Production challenges

  1. Agent有状态，重构Agent影响很大，最好加上自愈Agent、错误处理系统。
    此外还可以加上check point，一步一步来，失败了从这一步开始重新生成；而不是丢失上下文从头开始。
  2. Agent的错误是“复利”的，前面错了会导致最后错得离谱。

Debugging

监控Agent的决策模式和交互结构，做到生产级追踪，更能系统性诊断和解决问题。

Deploy

使用彩虹部署。旧会话分配到旧机器上，逐渐分配流量到新机器上，渐进替代，减少prompt改动的影响。

Sync and Block

Leader Agent并行地分配任务给Sub tasks，但是实际上是以最后一个执行完的Sub Agent为准进行信息交互。这会造成等待与阻塞。但是如果Sub Agent分别处理每一个Sub Agent，又会出现上下文不共享的问题，局部扰乱整体。