AI Agent全栈架构

主题

从单 Agent 到多 Agent ​

1. 先从一个最常见的场景开始 ​

你有没有试过让同一个助手同时帮你做几件事：查一下上周聊过的项目、改一下明天会议提醒、再顺手回一封语气正式的邮件？

一开始它都能办。你只需要把任务说清楚，它自己会判断要先查记忆、再写提醒、最后组织语言。但渐渐地，你开始加更多规则：涉及敏感内容要先做安全校验；客户邮件要用特定语气；如果提到旧项目，必须优先查长期记忆而不是瞎编。

终于有一天，你发现它开始“顾此失彼”：该查的资料没查，该温柔的回复变得生硬，该走校验流程的环节被跳过了。问题不是它变笨了，而是你把太多不同性质的判断，塞进了同一个大脑。

这就是从单 Agent 走向多 Agent 的典型过程。

2. 单 Agent 是怎么工作的 ​

先把「单 Agent」想成一个总负责人。

用户的话先交给这一个 Agent，它负责做全部判断：

  1. 理解用户在问什么
  2. 判断需不需要调用工具
  3. 如果需要，自己去调工具
  4. 拿到结果后，决定下一步
  5. 最后生成回复

代码层面，它通常长这样：

typescript
import { createAgent, tool } from "langchain";
import * as z from "zod";

const searchMemory = tool(
  async ({ query }) => `用户上周提到的项目是「数据同步优化」`,
  {
    name: "search_memory",
    description: "从历史记忆中搜索信息",
    schema: z.object({ query: z.string() }),
  },
);

const createReminder = tool(
  async ({ title, time }) => `已创建提醒：${time} ${title}`,
  {
    name: "create_reminder",
    description: "创建提醒事项",
    schema: z.object({ title: z.string(), time: z.string() }),
  },
);

const agent = createAgent({
  model: "openai:gpt-4.1-mini",
  tools: [searchMemory, createReminder],
  systemPrompt: "你是一个任务助手，回答要自然、简洁。",
});

const result = await agent.invoke({
  messages: [
    {
      role: "user",
      content: "提醒我明天上午十点开会，再告诉我上周那个项目叫什么。",
    },
  ],
});

console.log(result.messages.at(-1)?.content);

这套结构很好理解。所有事情都交给一个 Agent，它像一个“总控台”：既负责理解意图，也负责决定工具，还负责把最终结果说出来。刚开始做项目时，这种方式最省事。

3. 为什么很多项目一开始都应该先用单 Agent ​

新手最容易犯的错误，是还没把需求做清楚，就先把系统拆得很复杂。

如果你的系统目前只做这些：

  • 陪用户聊天
  • 查历史记忆
  • 写提醒事项
  • 偶尔查天气

那单 Agent 完全够用。原因很直接：

第一，链路短。 用户发消息后，通常只需要一两次工具调用就能结束。

第二，状态少。 大部分信息都能放在当前对话上下文里，不需要跨步骤保存中间状态。

第三，开发成本低。 只要维护一个 Agent 的角色、Prompt 和工具列表。

第四，排查容易。 输出不对时，只需检查一个 Agent 的 Prompt、输入、工具结果和模型回复。

这个阶段的结构大致是：

txt
用户请求
  -> 单 Agent
      -> 判断意图
      -> 调用记忆工具
      -> 调用日程工具
      -> 生成回复

4. 单 Agent 从什么时候开始吃力 ​

单 Agent 不是不能做复杂事，而是事情一多，它会越来越像一个什么都要管的全能员工。

如果继续往下加需求：

  • 消息先要做安全检查
  • 然后判断是聊天、记忆写入还是日程请求
  • 提到旧话题要先查长期记忆
  • 涉及提醒要走日程写入
  • 敏感话题要切换特殊回复策略

问题就出现了：

问题 1：职责太多。 一个 Agent 同时承担分类、路由、安全判断、工具调度、最终回复生成。Prompt 越来越长，工具越来越多。

问题 2：知识太杂。 它既要知道怎么安抚情绪，又要知道怎么查记忆，还要知道什么时候写日程。每一类任务的规则堆在一起，模型更容易判断失误。

问题 3：排查变难。 结果不对时，很难立刻判断是分类错了、工具选错了、记忆没取对，还是最后生成回复时把信息说乱了。

问题 4：流程变长。 有些请求不再是一问一答，而是多步骤流程：先做安全检查，再做意图判断，再决定是否查记忆，再决定是否写入外部系统，最后才生成回复。

到了这个阶段，继续让一个 Agent 全包，代码还能写，但系统会越来越别扭。

这里要分清两件事：

  • 流程本身变复杂了：最先出现的是编排和状态管理问题。比如步骤怎么排序，中间结果怎么保存，某一步失败后从哪里继续。
  • 职责是否真的需要拆开：如果只是流程长了一点，但仍然可以由一个 Agent 清楚处理，那未必需要立刻上多 Agent。先把工作流和状态管理理顺，问题往往已经解决一大半。

5. 多 Agent 不是更高级，而是开始分工 ​

很多人第一次听到“多 Agent”，会误以为重点是“让系统更聪明”。其实更准确的说法是：多 Agent 的重点是分工。

还是刚才那套需求，如果改成多 Agent，可以拆成这样：

  • 一个 router agent：判断消息属于哪一类任务
  • 一个 memory agent：专门处理记忆检索和写入
  • 一个 schedule agent：专门处理日程和提醒
  • 一个 reply agent：负责最后的回复输出

这时每个 Agent 只管自己最擅长的一部分。拆开后，最大的变化不是“每个 Agent 都更强”，而是系统结构变清楚了：谁负责分类、谁负责查历史、谁负责写外部系统、谁负责面向用户说话。

用户请求先进入路由节点，再被分发给不同专职 Agent。处理完后，结果汇总回来。多 Agent 更像是把一个大而全的总负责人，拆成几个职责明确的小角色。

不过不要理解得太绝对。当单 Agent 变重时，常见的演进方向之一确实是多 Agent。但不是所有复杂问题都必须拆成多个独立 Agent。有些项目只是工具变多了，或者流程变长了，这时先做更清晰的工作流编排、工具分组、上下文裁剪，也可能够用。

所以这一节想说明的是：

  • 当职责明显混在一起时，可以考虑多 Agent
  • 当问题主要是流程长、状态多时，先把编排问题解决清楚

6. 怎么判断该停在单 Agent，还是进入多 Agent ​

这里不讲抽象判断，直接看工程里的几个信号。

先用单 Agent 更合适的情况：

  • 工具数量不多，通常在 3 到 5 个以内
  • 大多数请求能在一轮内处理完
  • 没有特别复杂的状态流转
  • 当前最重要的目标是先把产品跑起来

开始考虑多 Agent 的情况：

  • 一个 Agent 的 Prompt 已经越来越长
  • 工具越来越多，模型经常选错工具
  • 一条请求经常要经过多个阶段
  • 不同类型任务混在一起，代码越来越难维护
  • 你需要单独观察某一个角色或某一类任务的表现

这不是二选一的价值判断，而是系统规模变化后的自然结果。

单 Agent 更像一个“全能助手”。多 Agent 更像一个“分工明确的小团队”。项目早期，先把全能助手做好，通常更稳。项目长到一定阶段，再把它拆成团队，才有意义。

7. 一句话总结 ​

单 Agent 是绝大多数项目的最佳起点；只有当职责混杂、流程变长、排查困难时，才需要把它拆成职责明确的多 Agent 团队。

下一步我们会继续把边界讲清楚：

  • LangChain 主要负责把「单个 Agent + 多工具」这条主线搭起来
  • LangGraph 更适合承接「多 Agent + 状态流转 + 多步骤流程」这类系统问题

8. 参考资料 ​

  1. LangChain 官方文档. LangChain Agents and Tools. https://python.langchain.com/
  2. LangGraph 官方文档. LangGraph Multi-Agent Workflows. https://langchain-ai.github.io/langgraph/
  3. Anthropic. Building effective agents. https://www.anthropic.com/engineering/building-effective-agents

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构