AI Agent 技术全景：从基础原理到多智能体协作
摘要: 从Agent的定义与核心公式（LLM + 工具 + 记忆 + 规划能力）出发，系统阐述了Agent与传统Chatbot在交互模式、行动能力、任务复杂度等维度的本质差异，并划分了从工具增强型到完全自主的五个自主性层级。随后深入拆解了ReAct（推理与行动交替）、Plan-and-Execute（先规划后执行）和Reflection（反思与自我纠正）三种核心推理模式。在此基础上，详细分析了Agent的三级记忆体系（工作记忆、短期记忆、长期记忆）及其技术实现，并系统梳理了Multi-Agent协作的四种模式（顺序、并行、辩论、层级）与四种通信方式（消息传递、共享黑板、函数调用、事件总线）的适用边界与工程挑战。
核心思想
Agent 是一个能自主感知环境、做出决策、执行行动的 AI 系统。它不再是"一问一答"的聊天机器人，而是能主动完成任务的"数字员工"。
1. Agent 基础概念
1.1 什么是 AI Agent？
如果用一句话定义：AI Agent = LLM + 工具 + 记忆 + 规划能力，它把 LLM 的智能从"被动回答"升级为"主动完成复杂任务"。
具备以下四大核心特质：
| 特质 | 说明 |
|---|---|
| 自主性 (Autonomy) | 无须时刻盯着，设定目标后它能自己想办法完成。 |
| 适应性 (Adaptability) | 环境变了（比如网页改版或 API 报错），它能实时调整策略。 |
| 主动性 (Proactivity) | 不只是被动响应指令，它会主动拆解目标并寻找路径。 |
| 社会性 (Sociality) | 它能像人一样，与其他 Agent 或人类进行协作。 |
Agent 的核心循环：
┌──────────────────────────┐
│ │
▼ │
┌───────────────┐ │
│ ① 感知 │ │
│ (Perception) │ │
│ │ │
│ 接收用户输入 │ │
│ 获取环境信息 │ │
│ 读取工具结果 │ │
└───────┬───────┘ │
│ │
▼ │
┌───────────────┐ │
│ ② 推理 │ │
│ (Reasoning) │ │
│ │ │
│ 分析当前状况 │ │
│ 制定行动计划 │ │
│ 决定下一步动作 │ │
└───────┬───────┘ │
│ │
▼ │
┌───────────────┐ │
│ ③ 行动 │ │
│ (Action) │ │
│ │ │
│ 调用工具/函数 │ │
│ 生成回答 │ │
│ 更新内部状态 │ │
└───────┬───────┘ │
│ │
▼ │
┌───────────────┐ │
│ ④ 反馈 │ │
│ (Feedback) │ │
│ │ │
│ 评估行动结果 │ │
│ 判断任务是否 │────── 未完成 ──────┘
│ 完成？ │
└───────┬───────┘
│ 完成
▼
返回最终结果1.2 与 Chatbot 的本质区别
很多人混淆了"好的 Chatbot"和"Agent"。它们的区别是根本性的：
- Chatbot：一问一答，用户推动对话，每步都需要用户指令。
- Agent：目标驱动，自主执行任务，无需用户持续参与。
Chatbot 模式（被动）：
User: "今天天气怎么样？"
Bot: "北京今天晴，25°C"
User: "那适合户外运动吗？"
Bot: "适合。"
User: "能帮我推荐一个地方吗？"
Bot: "朝阳公园不错。"
User: "帮我查一下朝阳公园怎么去"
...
Agent 模式（自主）：
User: "帮我安排一个适合户外运动的周末活动"
Agent:
Step 1: 查天气 → 这周末两天都是晴天，25°C ✓
Step 2: 搜户外运动场所 → 朝阳公园、奥体中心、香山
Step 3: 查交通 → 朝阳公园地铁直达，最方便
Step 4: 查是否需要预约 → 不需要预约，免费开放
Step 5: 生成总结 → "推荐周六去朝阳公园，地铁14号线直达，
不需要预约，天气晴朗，建议上午9点出发..."核心差异对比表：
| 维度 | Chatbot | Agent |
|---|---|---|
| 交互模式 | 一问一答 | 目标驱动，自主执行 |
| 行动能力 | 只能输出文字 | 可调用工具、操作外部系统 |
| 任务复杂度 | 单轮简单任务 需要特别关注上下文管理，信息与向量库检索的RAG ，以及工具调用等 | 多步骤复杂任务 |
| 自主性 | 无，完全依赖用户推动 | 高，自主规划与执行 |
| 记忆 | 通常无，最多上下文窗口 上下文窗口、个性化特征、webSearch、信息与向量检索 均可用来辅助，如 AI 搜索相关业务 | 短期+长期+工作记忆 |
| 错误处理 | 无法自我纠正 | 可反思、重试、调整策略 |
| 类比 | 知识丰富的图书管理员 | 能独立完成项目的实习生 |
1.3 Agent 自主性层级（Autonomy Levels）
并非所有 Agent 都有同等的自主性。我们可以划分一个层级：
Level 0: 无自主性（基础 Chatbot）
├─ 只能按模板回复
└─ 举例：传统客服机器人（如果...那么...）
Level 1: 工具增强型（Tool-Augmented LLM）
├─ 能按需调用工具，但不规划多步骤
└─ 举例："查一下北京天气" → 调用 get_weather → 回答
Level 2: 基础 Agent（单任务自主）
├─ 能自主规划并执行多步骤任务
├─ 有基本错误处理
└─ 举例：自动安排周末活动
Level 3: 高级 Agent（复杂任务自主）
├─ 能处理模糊目标和不确定环境
├─ 动态调整计划、深度学习
└─ 举例：DevIn（编程Agent）、客服Agent
Level 4: 完全自主 Agent
├─ 长期目标驱动，能跨会话持续工作
├─ 自主管理资源和优先级
└─ 举例：目前还不存在（2026年仍是研究目标）2.1 ReAct（Reasoning + Acting）
ReAct 是 2022 年提出的经典 Agent 模式，也是大多数现代 Agent 框架的基础。核心思想：推理和行动交替进行。
ReAct 模式的工作循环：
每次循环包含三步：
┌──────────────────────────────────────────────────────────────┐
│ Thought (思考): "我现在知道了什么？还需要知道什么？" │
│ ↓ │
│ Action (行动): "我需要调用 {工具名}，参数是 {参数}" │
│ ↓ │
│ Observation (观察): "工具返回了 {结果}，这对我的任务意味着什么？│
│ ↓ │
│ (回到 Thought，直到任务完成) │
└──────────────────────────────────────────────────────────────┘一个完整的 ReAct 示例：
任务：找出 2024 年诺贝尔物理学奖得主，并介绍其最重要的贡献。
=== ReAct 循环 ===
Round 1:
Thought: 我需要知道2024年诺贝尔物理学奖得主是谁。
我的知识截止于训练日期，2024年的信息需要外部检索。
Action: search("2024年诺贝尔物理学奖得主")
Observation: 2024年诺贝尔物理学奖授予了John J. Hopfield
和Geoffrey E. Hinton...
Round 2:
Thought: 我知道了得主是Hopfield和Hinton。现在需要
了解他们最重要的贡献。
Action: search("John Hopfield 最重要贡献 物理学")
Observation: John Hopfield发明了Hopfield网络，一种
联想记忆的神经网络模型...
Round 3:
Thought: 还需要查Hinton的贡献。
Action: search("Geoffrey Hinton 最重要贡献 深度学习")
Observation: Geoffrey Hinton被誉为"深度学习之父"，
主要贡献包括反向传播算法、玻尔兹曼机...
Round 4:
Thought: 信息已经足够。我可以整合回答。
Final Answer: 2024年诺贝尔物理学奖授予了约翰·霍普菲尔德
和杰弗里·辛顿，以表彰他们在人工神经网络方面的基础性发现和发明...ReAct 的 Prompt 结构（简化版）：
你是一个能使用工具的智能助手。按以下格式思考和行动：
Thought: 你对当前状况的分析
Action: 工具名称
Action Input: 工具的输入参数（JSON格式）
Observation: [工具执行后，结果会在这里显示]
...（重复 Thought/Action/Observation 直到完成）
Thought: 我已经有足够的信息来回答问题
Final Answer: 给用户的最终答案
可用工具：
- search(query: str): 网络搜索
- calculator(expr: str): 数学计算2.2 Plan-and-Execute（先规划，再执行）
ReAct 是"走一步看一步"，Plan-and-Execute 是"先画地图再出发"。对于复杂的、步骤明确的任务，Plan-and-Execute 更高效。
- ReAct 适合不确定性高的任务，比如在陌生的城市“边走边问”。
- Plan-and-Execute 适合复杂、步骤可预期的任务。
Plan-and-Execute 对比 ReAct
═══════════════════════════════════════════════════════════════════
ReAct（边想边做）: Plan-and-Execute（先规划后执行）:
Step 1: 想 → 做 Phase 1: 制定计划
Step 2: 根据结果想 → 做 ├─ 分析任务
Step 3: 再想 → 做 ├─ 分解为子任务
Step 4: ...直到完成 └─ 输出执行计划
│
适合：不确定性高的任务 ▼
类比：在陌生的城市"边走边问" Phase 2: 执行计划
├─ 子任务1 → 工具调用
├─ 子任务2 → 工具调用
└─ 子任务3 → 工具调用
│
▼
Phase 3: 汇总结果
适合：步骤可预期的任务
类比：在熟悉的城市"先看地图再出发"Plan-and-Execute 完整示例：
任务：写一份关于公司Q3业绩的分析报告
Phase 1 — Planning（LLM 制定计划）：
Plan:
1. 获取Q3财务数据（收入、利润、成本）
2. 获取Q2财务数据（用于环比分析）
3. 获取行业Q3平均水平（用于对比）
4. 计算同比增长率
5. 分析主要增长驱动因素
6. 撰写报告（执行摘要 + 详细分析 + 展望）
Phase 2 — Execution（依次执行）：
Step 1: get_financial_data(quarter="2024-Q3") → {...}
Step 2: get_financial_data(quarter="2024-Q2") → {...}
Step 3: get_industry_avg(quarter="2024-Q3") → {...}
Step 4: calculate(yoy_growth) → 15.3%
Step 5: analyze_growth_drivers(data) → "AI产品线增长显著..."
Step 6: 综合以上信息，生成报告
Phase 3 — Aggregation（汇总输出）：
"执行摘要：Q3收入同比增长15.3%，主要得益于AI产品线
的快速增长。利润率提升2个百分点..."为避免 Plan-and-Execute 执行后偏离任务目标，需要添加一个 Replan 模块：
2.3 Reflection / Self-Correction（反思与自我纠正）
好的 Agent 不是一次就做对的，它会检查自己的工作并修正错误。
Reflection 模式
═══════════════════════════════════════════════════════════════════
┌────────────────────────────────────────────────────────────┐
│ 主循环 │
│ │
│ Generate (生成) ──> Reflect (反思) ──> 够好了吗？ │
│ ▲ │ │
│ │ ┌────┴────┐ │
│ │ 是 否 │
│ │ │ │ │
│ │ ▼ ▼ │
│ │ 输出 Revise (修改) │
│ │ │ │
│ └────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────┘Reflection 的两种实现方式：
方式一：自反思（Self-Reflection）
同一个 LLM 检查自己的输出：
Generate: "根据公司政策，年假为3天..."
Reflect: "等等，我引用的似乎是2023年的旧版手册。
我应该查看最新版本。"
Action: search("2024年最新年假政策")
Revise: "根据2024年最新政策，年假为5天..."
方式二：外部评判（External Critic）
用一个独立的 LLM 或规则来评估：
Generate (LLM-1): "建议投资股票A、B、C..."
Critic (LLM-2): "这个建议缺乏风险评估，没有考虑
投资者的风险承受能力。"
Revise (LLM-1): "在投资前，请先评估您的风险承受能力。
股票A：低风险，适合...股票B：高风险..."Reflection 的价值：
- 减少幻觉：自我检查能捕获明显的事实错误
- 提高完整性：检查是否回答了问题的所有方面
- 改善格式：检查输出是否符合要求的格式
3. Agent 记忆（Memory）
缺乏记忆的 Agent 如同每次醒来便遗忘过往之人——每轮对话皆从头开始，无从沉淀经验、持续成长。
3.1 Agent 记忆的类型与层级
| 层级 | 范围 | 生命周期 | 类比 |
|---|---|---|---|
| 工作记忆 (Working Memory) | 当前对话的即时状态 | 一次会话 | 人的"当下正在想的事" 好比草稿纸上的计算 |
| 短期记忆 (Short-term Memory) | 最近几次对话的内容 | 数天~数周 | 人的"最近发生的事" 好比日记本 |
| 长期记忆 (Long-term Memory) | 所有历史交互和知识 | 永久 | 人的"知识和经验" 好比图书馆 |
3.2 工作记忆（Working Memory）
工作记忆是 Agent 在当前任务中的"临时记事本"——任务完成即丢弃。
工作记忆 = {
"task": "安排周末户外活动",
"current_step": 3, ← 当前执行到第几步
"findings": { ← 已获取的信息
"weather": {"sat": "晴 25°C", "sun": "多云 23°C"},
"venues": ["朝阳公园", "奥体中心", "香山"],
"transport": {"朝阳公园": "地铁14号线"}
},
"plan": [ ← 剩余计划步骤
"查预约要求",
"最终推荐"
],
"errors": [] ← 遇到的错误
}工作记忆的实现方式：
| 方式 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 消息历史 | 把之前的 Thought/Action/Observation 保留在上下文中 | 最简单 | 无限增长，浪费 token |
| Scratchpad | 在 System Prompt 中维护一个"记事本"区域，只保存关键信息 | 节省 token | 需要设计更新逻辑 |
| 结构化状态 | 用 JSON 对象维护 Agent 状态，每步更新 | 清晰可解析 | 需要 LLM 输出结构化更新 |
3.3 短期记忆（Short-term Memory）
短期记忆让 Agent 记住最近的对话，跨会话保持连续。
短期记忆的存储与检索：
存储（每次对话结束后）：
对话记录 ──> 摘要化 ──> 存入短期记忆库
│
▼
例: "用户在讨论Python学习计划，提到已掌握基础语法，
想学习Web框架。偏好通过项目实践学习。"
检索（每次新对话开始时）：
用户打开新对话 ──> 查询记忆库: "关于这个用户最近的交互"
│
▼
┌──────────────────────────────────┐
│ 上下文注入: │
│ "你之前和用户讨论过Python学习， │
│ 他/她已掌握基础语法，想学习 │
│ Web框架，偏好项目实践。" │
└──────────────────────────────────┘
实现技术：向量数据库 + Embedding
- 每条记忆生成 Embedding
- 新对话时用当前问题检索最相关的历史记忆
- Top-K 相关记忆注入到新的对话上下文中3.4 长期记忆（Long-term Memory）
长期记忆是 Agent 的"终身知识库"——用户偏好、领域知识、经验教训。
长期记忆的三个子类：
1. 语义记忆 (Semantic Memory)
│ 事实性知识
│
├─ 用户信息: "用户张三是后端工程师，用PyCharm"
├─ 偏好设置: "用户偏好简洁回答，不需要emoji"
├─ 领域知识: "公司代码规范要求用TypeScript严格模式"
└─ 常驻知识: "OpenAI API key的结构是sk-..."
2. 情节记忆 (Episodic Memory)
│ 过去的交互经历
│
├─ "上周三用户问过Python性能优化，使用了多线程方案"
├─ "用户对Numpy的答案表示满意，但对Pandas的回答有纠正"
└─ "用户在上次对话中提到项目截止日期是3月15日"
3. 程序性记忆 (Procedural Memory)
│ 怎么做事的经验
│
├─ "代码审查时应先检查架构，再检查细节"
├─ "处理用户投诉时先共情，再提供解决方案"
└─ "搜索知识库应该先用BM25初筛，再向量精排"长期记忆的技术实现：
┌──────────────────┐
│ Memory Manager │ ← 记忆管理器（核心组件）
└────────┬─────────┘
│
┌──────┼──────────┐
▼ ▼ ▼
┌────────┐ ┌──────┐ ┌──────────┐
│ 写入 │ │ 检索 │ │ 整合 │
└───┬────┘ └──┬───┘ └─────┬────┘
│ │ │
▼ ▼ ▼
重要信息 当前查询 将检索到的
持久化 在记忆中 记忆注入当前上下文
(离线) 找到相关
信息(在线)
写入流程：
1. 判断当前交互是否有"记忆价值"（不是所有对话都需要记住）
2. 提取关键信息：用户偏好、事实、情感标记
3. 生成记忆的 Embedding 向量
4. 存入向量数据库（语义记忆）+ 时间序列数据库（情节记忆）
检索流程：
1. 用户发起新对话/新任务
2. 用当前查询+用户ID检索相关记忆
3. Reranking 排序（时间近的、情感强的加权）
4. 注入到 LLM 上下文："关于这个用户，你记得..."3.5 记忆管理的关键挑战
| 挑战 | 说明 | 缓解方法 |
|---|---|---|
| 记忆膨胀 | 随时间积累太多记忆，检索变慢且噪音增多 | 定期清理，重要性评分，过期淘汰 |
| 记忆冲突 | 用户改变偏好，新旧记忆矛盾 | 版本标记，新记忆覆盖旧记忆 |
| 隐私 | 记忆含敏感信息，安全风险大 | 本地存储加密，用户可删除 |
| 幻觉记忆 | LLM 可能将虚构内容写入记忆 | 关键记忆需人工确认 |
| 跨会话一致性 | 不同会话可能有不同的 Agent 实例 | 集中式记忆服务 |
4. Multi-Agent（多智能体协作）
一个 Agent 能做的事有限。当任务足够复杂时，需要多个 Agent 分工协作——就像公司不是一个员工，而是一个团队。
4.1 为什么需要 Multi-Agent？
单 Agent 的局限性 vs Multi-Agent 的优势
单 Agent:
┌──────────┐
│ 一个大脑 │ → 认知负载过重 → 顾此失彼
│ 做所有事 │ → 功能耦合 → 难以优化
│ 看一个角度│ → 单一视角 → 容易出错
└──────────┘
Multi-Agent:
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ 研究员│ │ 分析家│ │ 作家 │ │ 审查者│
│ 收集 │ │ 分析 │ │ 撰写 │ │ 检查 │
│ 信息 │ │ 数据 │ │ 报告 │ │ 质量 │
└──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘
│ │ │ │
└────────┴────────┴────────┘
协同工作Multi-Agent 的核心优势：
| 优势 | 说明 |
|---|---|
| 分而治之 | 每个 Agent 专注一个子任务，降低个体认知负载 |
| 多视角 | 不同 Agent 带来不同视角，减少盲点 |
| 专业化 | 每个 Agent 可以有不同的 System Prompt、工具、知识库 |
| 鲁棒性 | 一个 Agent 出错不影响整体（需要设计容错） |
| 可扩展 | 增加新 Agent 即可扩展新能力 |
4.2 协作模式
4.2.1 顺序协作（Sequential）
Agent A 完成后，把结果交给 Agent B，像流水线一样。
原始需求 ──> Agent 研究 ──> Agent 分析 ──> Agent 写作 ──> 最终输出
(收集资料) (分析数据) (撰写报告)
适用场景：步骤之间有明确前后依赖的任务
优点：逻辑清晰、易于调试
缺点：慢（必须等前一步完成）、一旦某步出错后面全错4.2.2 并行协作（Parallel）
多个 Agent 同时工作，最后汇总（Map-Reduce）。
原始需求
│
├──> Agent A: 从员工手册找信息 ──┐
├──> Agent B: 从OA系统找信息 ──┤
├──> Agent C: 从FAQ找信息 ──┼──> 汇总 Agent ──> 最终输出
└──> Agent D: 从公告找信息 ──┘ (融合结果)
适用场景：独立子任务、多源信息收集
优点：快（并行执行）
缺点：汇总 Agent 需要处理可能冲突的信息4.2.3 辩论协作（Debate）
多个 Agent 对同一问题给出不同答案，通过辩论选出最佳方案。
问题: "应该用微服务还是单体架构？"
Round 1 — 陈述立场：
Agent A: "用微服务，因为...（3个理由）"
Agent B: "用单体，因为...（3个理由）"
Round 2 — 反驳：
Agent A: "你的第一个论点有漏洞，因为..."
Agent B: "你忽略了微服务的运维成本..."
Round 3 — 修正与共识：
Agent A: "我同意运维成本是个问题，可以考虑折中方案..."
Agent B: "折中方案可以考虑模块化单体..."
裁判 Agent:
"综合考虑，建议采用模块化单体架构，保留未来拆分微服务的可能性..."
适用场景：有争议的决策、需要严谨推理的问题
优点：多角度审视，减少偏见
缺点：慢、消耗更多 token4.2.4 层级协作（Hierarchical / Orchestrator+Worker）
一个"主管" Agent 分配任务给多个"工人" Agent，这是最常用且最灵活的协作模式。
Orchestrator + Worker 层级架构
═══════════════════════════════════════════════════════════════════
┌──────────────────┐
│ Orchestrator │
│ (编排者/主管) │
│ │
│ 职责: │
│ • 分析任务 │
│ • 制定计划 │
│ • 分配给 Worker │
│ • 监控进度 │
│ • 汇总结果 │
└────────┬─────────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Worker A │ │ Worker B │ │ Worker C │
│ (搜索员) │ │ (分析师) │ │ (写作员) │
│ │ │ │ │ │
│ 工具: │ │ 工具: │ │ 工具: │
│ web_search │ │ calculator │ │ word_export│
│ doc_search │ │ chart_gen │ │ email_send │
└────────────┘ └────────────┘ └────────────┘Orchestrator 的工作流程示例：
任务：写一份关于AI行业2025趋势的研究报告
Orchestrator 的思考：
这个任务可以分解为：调研 → 分析 → 撰写
需要 3 个 Worker。
Orchestrator → Worker A (研究员):
"请搜索2025年AI行业的最新趋势，包括但不限于：
1. 大模型技术进展
2. AI应用落地情况
3. 投融资趋势
4. 政策法规变化
请返回结构化的调研摘要。"
Worker A 返回后...
Orchestrator → Worker B (分析师):
"这是调研数据，请做以下分析：
1. 识别 3~5 个最显著的趋势
2. 预测各趋势的发展方向
3. 列出关键数据支撑"
Worker B 返回后...
Orchestrator → Worker C (写作员):
"这是研究和分析结果，请撰写一份专业的行业研究报告。
格式要求：执行摘要 + 趋势分析 + 展望建议"
Worker C 返回后...
Orchestrator: 审核报告质量 → 修正小问题 → 提交给用户4.3 Agent 间通信
Agent 之间的通信是构建多智能体系统（Multi-Agent System）的核心。Agent 通常通过统一的通信协议、消息队列或共享知识库进行交互，实现任务委派与协同。
Agent 之间如何"说话"？有几种通信方式：
| 通信方式 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 消息传递 | Agent A 输出自然语言消息给 Agent B | 最灵活，类人交流 | 无结构化，可能歧义 |
| 共享黑板 | 所有 Agent 读写一个共享数据结构 | 适合多对多协作 | 需要并发控制 |
| 函数调用 | Agent B 作为 Agent A 的一个"工具"出现 | 结构化，可类型检查 | 耦合度高 |
| 事件总线 | Agent 发布/订阅事件 | 松耦合，可扩展 | 调试困难 |
四种方式不是平行的——它们适合完全不同的场景。选错通信方式会导致系统脆弱、调试噩梦或性能瓶颈。下面逐一分析每种方式的适用边界和典型坑。
4.3.1 消息传递（Message Passing）
这是最"原生"的方式：Agent A 把自己的输出作为自然语言文本发给 Agent B，Agent B 把它当作 user message 来理解和处理。
Agent A → "根据分析，建议关注三个方向：新能源、AI 医疗、低空经济"
│
Agent B ← 把这行文本当成用户指令，理解后继续工作什么时候用：
- 上下游任务本身只有自然语言这个接口能承载（比如 A 做完研究，B 撰写报告——研究报告天然就是文本）
- 需要 Agent B 对上游结果做自由理解和二次加工，而不是机械地解析结构化字段
- 团队是不同供应商/不同模型组成的异构 Agent——只有自然语言是通用「协议」
什么时候不该用：
- 需要精确的数值、状态码、决策结果传递——自然语言的歧义会在这里被放大
- 关键路径上的 Agent 链——上游的一句话歧义会导致下游全线偏差
核心坑：歧义传播与截断。A 说"Q3 表现一般"——B 怎么理解"一般"？是差还是中等？此外，A 的输出如果很长，B 的上下文窗口可能装不下，需要人为截断或摘要，这又引入了一轮信息损失。
4.3.2 共享黑板（Blackboard）
所有 Agent 共享同一个结构化数据结构（通常是 JSON 或 Key-Value Store），Agent 可以读写这个结构的任意字段。类似于多个厨师共用同一份点菜单——谁完成了就把自己的结果填进去，谁被阻塞了就看谁还没填。
黑板状态（任何 Agent 都能读写的共享结构）：
json
{
"task": "Q3 行业分析报告",
"status": "in-progress",
"research_done": true,
"research_findings": "新能源增长 15%、AI 医疗融资活跃 ...",
"draft_written": false,
"chart_generated": false,
"errors": []
}什么时候用：
- 多对多协作——研究 Agent、写作 Agent、图表 Agent 需要读彼此成果（写作需要看研究结论，图表需要看写作中的数据）
- 需要状态追踪——知道任务到哪一步了，哪些子任务已完成、哪些阻塞了
- 结果需要汇总到一处——最终报告由多个 Agent 的输出拼装而成
什么时候不该用：
- 两个 Agent 之间有严格的顺序依赖（A 的完整结果必须给 B）——这时消息传递更直接
- 黑板本身成为瓶颈，所有 Agent 排队读写
核心坑：不需要用 Redis 和锁。实践中大多数 Agent 黑板复杂度远低于数据库——通常是内存 JSON 或简单 Key-Value Store。真正容易出现的问题是字段命名打架：Agent A 写入 research_findings，Agent B 以为字段叫 findings，结果读到空值继续跑——系统看起来一切正常，其实数据根本没传过去。
4.3.3 函数调用（Tool-as-Agent / Function Calling）
这是最"硬"的方式：Agent A 把 Agent B 注册为自己的一个 Tool（函数），调用方式和调用搜索引擎 API、数据库查询完全相同——输入参数结构化，返回结果结构化。
Agent A（规划者）调用 Agent B（计算器）：
typescript
function_call("calculate_roi", {
"investment": 1000000,
"returns": 1500000
})
→ 返回：{"roi": "50%", "payback_months": 14}Function Calling JSON Schema：
json
{
"name": "calculate_roi",
"description": "计算投资回报率",
"parameters": {
"type": "object",
"properties": {
"investment": {"type": "number", "description": "投资金额"},
"returns": {"type": "number", "description": "回报金额"}
},
"required": ["investment", "returns"]
}
}什么时候用：
- Agent B 的任务是确定性计算或结构性操作——查数据库、算数学、调 API
- 需要类型校验——输入输出格式可以事先定义，不会出现字段名猜谜
- 主从关系明确——A 是规划者/编排者，B 是执行者/工具，不存在双向对话
什么时候不该用：
- Agent B 需要根据上下文做创意性判断和自由推理——函数调用的入参出参太死板，会把开放性任务压扁到 Schema 里
- 耦合：A 必须知道 B 的接口细节（参数定义、返回字段），换一个供应商的 B 就得改代码
核心坑：把需要创意或自由判断的任务强行塞进结构化 Schema——比如让写作 Agent 返回 {"title": "...", "body": "...", "tone_score": 0.8}。Schema 一多、字段一复杂，模型就频繁触发格式错误，调试比消息传递痛苦十倍。
4.3.4 事件总线（Event Bus / Pub-Sub）
Agent 发布事件到总线，所有订阅了该事件的 Agent 都会收到通知，自行决定是否处理。这是一种「广播后等待自愿者」的模式——不像消息传递那样一对一，不像黑板那样被动读写。
Agent A 发布事件： "research_completed"，附带研究成果
│
Event Bus ─┼──→ Agent B (写作员) 收到 → "有人做完了研究，我该开始写报告了"
│
└──→ Agent C (审核员) 收到 → "有新内容产出，我该检查一下"什么时候用：
- Agent 数量多且动态扩展——新增一个翻译 Agent，它只需要订阅
report_completed事件，不改任何现有代码 - 松耦合是刚需——发布者不知道也不应该知道谁会消费这个事件
- 需要异步处理——发布事件后不管，消费方自己决定何时处理
什么时候不该用：
- 只有 2-3 个 Agent 的简单协作——事件总线是杀鸡用牛刀
- 确定性要求高：你不知道谁会处理、什么时候处理、处理完了没有——调试时溯源极其困难
- 需要返回值：事件总线本身不具备 request-response 能力，需要额外机制
核心坑：调试成本。事件跑飞了、没人处理、处理了两次、顺序出错了——看日志要看多个 Agent 的时间线交叉比对。此外，没有「请求-响应」模式：Agent A 想知道自己的事件是否被正确处理了，需要额外的确认机制。
4.3.5 选型建议
场景驱动的选型：
两个 Agent，A 产结果 B 加工？
→ 消息传递（最简单，最直接）
多个 Agent 需要协作完成同一份产物？
→ 共享黑板（天然支持多对多状态共享）
B 是 A 的确定性工具（查 API / 算数据 / 格式转换）？
→ 函数调用（结构化、可校验、无歧义）
N 个 Agent 动态组合、希望低耦合和可扩展？
→ 事件总线（但要做好心理准备：调试会很痛苦）
小规模协作（2-3 Agent）？
→ 消息传递就够了，不要引入黑板或事件总线的复杂度
异构 Agent 跨组织协作？？
→ 消息传递（自然语言是唯一的通用协议）。也可以考虑 A2A 协议（见 [[6-2-Agent协议]]）共享黑板模式
═══════════════════════════════════════════════════════════════════
┌───────────────────────────────────────┐
│ 共享黑板 │
│ │
│ { │
│ "task": "Q3 报告", │
│ "status": "analyzing", │
│ "findings": { │
│ "revenue": "增长15%", │
│ "cost": "控制良好" │
│ }, │
│ "pending_tasks": [ │
│ "写复盘分析", │
│ "画趋势图" │
│ ] │
│ } │
└───┬───────────┬───────────┬───────────┘
│ │ │
┌───────▼──┐ ┌────▼─────┐ ┌─▼──────────┐
│ Agent A │ │ Agent B │ │ Agent C │
│ (数据) │ │ (分析) │ │ (图表) │
└──────────┘ └──────────┘ └────────────┘4.4 Multi-Agent 的工程挑战
| 挑战 | 描述 | 缓解方法 |
|---|---|---|
| 编排复杂度 | 多个 Agent 的协调和调度 | 使用成熟的编排框架（LangGraph/AutoGen） |
| 成本 | 每个 Agent 都消耗 LLM 调用 | 小模型做简单任务，大模型做关键任务 |
| 延迟 | 多轮通信增加耗时 | 并行化、使用异步通信 |
| 一致性问题 | 多个 Agent 可能产出矛盾结果 | 设置冲突解决机制（投票/优先级） |
| 错误传播 | 上游 Agent 的错误被下游放大 | 添加验证 Agent 把关 |
| "人多嘴杂" | Agent 太多可能降低效率而不是提升 | 严格控制 Agent 数量（一般 3~5 个为宜） |
5. 总结
Agent 标志着 LLM 应用从"对话工具"向"智能助手"的关键跃迁。以下是 Agent 核心概念的精炼总结：
═══════════════════════════════════════════════════════════════════
概念 一句话总结
──────────────────────────────────────────────────────────────
Agent 定义 LLM + 工具 + 记忆 + 规划 = 能自主完成任务的 AI
ReAct 每一步都"边想边做"，是大多数Agent的基础
Plan-and-Execute 先制定完整计划再执行，适合步骤可预期的任务
Reflection 生成后自我检查并修正，减少错误和幻觉
工作记忆 当前任务中的临时信息，任务结束即丢弃
短期记忆 跨会话的最近交互历史
长期记忆 用户偏好、知识、经验的永久存储
Multi-Agent 多Agent分工协作，处理单个Agent无法完成的复杂任务
Orchestrator+Worker 最常用的协作模式：主管分配任务，工人执行关键要点：
- Agent 与 Chatbot 的本质区别是自主性——Agent 能自主规划、执行、反思。
- ReAct 是最基础的 Agent 模式，Plan-and-Execute 和 Reflection 分别解决规划和质检问题。
- 记忆是 Agent 的灵魂——没有记忆的 Agent 永远在"重新开始"。
- Multi-Agent 不是"越多越好"——3~5 个专业 Agent 通常比 10 个通用 Agent 效果好。
- 每增加一个 Agent 就增加一份成本和复杂度，设计时需要权衡。