从 LLM 到 Multi-Agent：一文搞懂 AI Agent 的本质
从 LLM 到 Multi-Agent：一文搞懂 AI Agent 的本质
当所有人都在谈 AI Agent 时，你真的理解它是什么吗？这篇文章用最直白的方式，帮你厘清 LLM、Agent、Multi-Agent 之间的本质区别，以及普通开发者如何从零开始构建自己的 Agent 团队。
一、LLM ≠ Agent：先破一个误区
很多人把 Claude、GPT 直接叫做 “Agent”，这其实不准确。
LLM（大语言模型）的本质是：给输入，返输出。它没有自主决策能力，没有持久记忆，也不能调用外部工具。你问它一个问题，它回答完就结束了——没有"下一步该干什么"的概念。
Agent = LLM + 三个关键能力：
| 能力 | LLM 裸用 | Agent |
|---|---|---|
| 决策循环 | 一次性回答 | Plan → Execute → Observe → 再决策 |
| 工具调用 | 只能生成文本 | 能读写文件、调 API、执行代码 |
| 上下文管理 | 无状态 | 知道自己做到哪了，下一步该干什么 |
一句话：LLM 是引擎，Agent 是整辆车。引擎不等于车。
二、Claude Code：一个现成的 Single Agent
以 Anthropic 的 Claude Code 为例——它已经是一个完整的 Agent：
- 你说"修复这个 bug"，它会自己规划步骤（读代码 → 定位问题 → 写修复 → 跑测试）
- 它自主决定什么时候读文件、跑命令、调用工具
- 它在任务过程中持续追踪状态，知道做到哪了
但注意：从头到尾，只有"它一个人"在干活。这就是Single Agent。
三、Multi-Agent：从"一个人扛"到"团队协作"
3.1 为什么需要 Multi-Agent？
Single Agent 的问题和一个人干所有事一样：
- Prompt 巨长，容易混乱
- 出了问题不知道是哪个环节
- 无法复用某个能力模块
Multi-Agent 就是把一个大任务拆成多个专职 Agent，各管一段，通过编排协作完成。
3.2 一个真实案例：日志巡检系统
以一个线上日志巡检系统为例，四个 Agent 各司其职：
log-inspector（感知层）→ log-analyst（认知层）→ alert-supervisor（行动层）→ group-reporter（播报层）每个 Agent：
- 输入输出明确：inspector 输出 InspectionResult，analyst 输出 AnalysisReport
- 职责单一：inspector 只管采集，不做分析；analyst 只管分析，不发告警
- 可独立调试：某个环节出问题，直接定位到对应 Agent
- 可跨项目复用：alert-supervisor 可以用在任何需要 Jira 工单 + Lark 通知的场景
3.3 “真” Multi-Agent vs “模拟” Multi-Agent
这里有一个微妙但重要的区别：
| 维度 | 模拟 Multi-Agent | 真 Multi-Agent |
|---|---|---|
| 执行方式 | 单实例，依次切换角色 | 多个独立实例并行运行 |
| 上下文 | 共享同一个上下文 | 各自独立的上下文 |
| 并行能力 | 串行 | 真并行 |
| 通信方式 | 函数调用 / 内存传递 | 消息协议（文件 / API / MCP） |
| 实际收益 | 职责隔离、可调试、可复用 | 以上全部 + 性能并行 |
很多框架（包括用 Claude Code + Skill 文件编排的方案）实际是模拟 Multi-Agent：底层跑的是同一个 LLM 实例，在不同时刻"扮演"不同角色。但它已经拿到了 Multi-Agent 的核心架构收益。
四、如何构建真正的 Multi-Agent 系统
4.1 方法一：多会话 + 共享存储（最简方案）
启动多个 Claude Code 会话，每个会话专注一个角色，通过文件系统或数据库做中间数据交换。
会话A（Inspector）→ 写入 result.json → 会话B（Analyst）读取并分析手动版的 Multi-Agent，但确实是并行的、独立上下文的。
4.2 方法二：编排脚本 + API 并发调用（工程方案）
用一个主进程通过 Anthropic API 并发调用多个 Claude 实例：
Orchestrator（Python/Node 主进程） ├── 实例1：system_prompt = Inspector 角色 ├── 实例2：system_prompt = Analyst 角色 └── 实例3：system_prompt = Supervisor 角色 主进程负责：消息传递、状态管理、结果汇总这是真正的 Multi-Agent——多个独立脑子同时想、互相传话。
4.3 方法三：成熟框架（规模化方案）
| 框架 | 特点 |
|---|---|
| LangGraph | 基于图的 Agent 编排，灵活的状态管理 |
| CrewAI | 角色驱动，类似组建虚拟团队 |
| AutoGen | 微软出品，强调 Agent 间对话 |
| MetaGPT | 模拟软件公司的多角色协作 |
4.4 通信协议
- MCP（Model Context Protocol）：Agent 与外部工具之间的通信标准，Anthropic 主导
- A2A（Agent-to-Agent）：Google 推的 Agent 间通信协议
- 目前业界还没有统一的 Agent 间通信标准，这是一个正在快速演进的领域
五、总结：一张图看懂全局
LLM（Claude 本体） │ 只是一个推理引擎 ▼ Single Agent（如 Claude Code） │ LLM + 决策循环 + 工具调用 + 上下文管理 ▼ 模拟 Multi-Agent（Skill 角色编排） │ 单实例多角色切换，拿到分工收益 ▼ 真 Multi-Agent（多实例并行） │ 独立上下文 + 消息通信 + 真并行 ▼ Multi-Agent 框架（LangGraph / CrewAI / AutoGen） 规模化编排、状态管理、容错机制一句话总结：LLM 是能力底座，Agent 是在底座上构建的自治系统，Multi-Agent 是让多个自治系统协作的架构模式。理解这三层，你就理解了 AI Agent 的全部。
作者注：本文内容来自一次与 Claude 的深度对话，所有概念均经过实际项目验证。如果你也在探索 AI Agent 的构建，欢迎交流。