AI Agent 知识体系
从 Agent 概念边界、Agentic Loop、ReAct/Plan-Execute、单 vs 多 Agent，到 Tool Calling、RAG、Memory、MCP、LangGraph 的完整知识地图。
AI Agent 知识体系
从「会调 LLM」到「能编排生产级 Agent 系统」的完整知识地图。先搞清楚「什么是 Agent、什么不是」，再谈怎么搭。
核心模块
graph LR
A[Agent 基础] --> B[Tool Calling]
A --> C[RAG]
A --> D[Memory]
B --> E[MCP]
C --> E
D --> F[Multi-Agent]
E --> F
F --> G[LangGraph]
F --> H[评测与可观测]
| 模块 | 解决什么问题 | 对应文章 |
|---|---|---|
| Agent 基础 | Agent 是什么、Agentic Loop、与 LLM/Chatbot 的区别 | 本篇 |
| Tool Calling | 让模型调用外部工具/API 的机制与可靠性 | Function Calling |
| RAG | 检索增强生成，把外部知识喂给模型 | RAG |
| Memory | 短期/长期记忆、会话状态管理 | 上下文工程与记忆 |
| MCP | 工具标准化的协议，统一工具接入 | MCP |
| Multi-Agent | 多角色协作、Supervisor 路由、HITL | LangGraph |
| LangGraph | 把 Agent 建模成显式状态图 | LangGraph |
| 评测与可观测 | 离线集 / 在线指标 / trace | 评测与可观测 |
一、Agent 和 Chatbot 的本质区别（一面送分 + 钓鱼题）
一句话：本质区别 = 自主决策 + 行动闭环。
- Chatbot：输入 → LLM → 文本，被动问答，一次往返结束。
- Agent：输入 → 推理 → 决定调工具 → 执行 → 观察结果 → 再决策 → 循环直到完成。
判断标准就一条：有没有多步自主决策 + 反馈闭环。
三个「不算 Agent」的边界（面试官爱钓鱼）
| 说法 | 为什么不算 Agent |
|---|---|
| ChatBot + 插件 | 插件由固定规则触发（关键词路由），只是「带工具的 Bot」；要由模型在多步推理中自主选择工具与参数并形成闭环才是 Agent |
| RAG + Chat | 单次检索→回答只是「增强型 Chat」；有多轮检索策略（查不到改写查询、拆子问题、交叉验证）才带 Agent 特征 |
| Prompt Chain | Chain 拓扑是工程侧固定的；Agent 是运行时动态选路、靠 Observation 更新状态 |
二、Agentic Loop 与终止条件
User Input → [Think → Act → Observe] × N → Final Output
举个真实例子：用户「退掉上周五买的书」→ Think（查订单）→ Act（call getOrders）→ Observe（{已发货}）→ Think（查退货政策）→ Act（getReturnPolicy）→ Observe → Act（createReturn）→ 收尾回复。
终止条件（三选一，必答）
- 达到最大步数（如 10 轮，硬阈值）
- 模型输出终止信号
- 任务完成标志
⚠️ 生产环境的答案必须包含硬阈值和防死循环。只答「模型判断完成」会被追问「那模型一直调工具怎么办」——这正是区分「会搭 Demo」和「上过生产」的地方。
工程三坑
- 上下文爆炸：工具结果每轮都塞 context 很快爆 → 结果做摘要/截断
- 工具失败处理：让模型看到错误后自己决定重试/换策略/降级，而不是裸抛异常
- 防死循环：加硬阈值（迭代次数上限 + 超时双兜底）
三、ReAct vs Plan-and-Execute
| 维度 | ReAct（边想边干） | Plan-and-Execute（先想好再干） |
|---|---|---|
| 流程 | 推理 ↔ 行动交替 | 先出完整计划再逐步执行 |
| 优势 | 灵活、能根据反馈调整 | 全局可控、可预测、省 token |
| 劣势 | 容易跑偏、步数不可控、烧钱 | 计划固化、不适应变化 |
| 适合 | 用户意图模糊需探索 | 步骤明确、依赖清晰的确定任务 |
工业界最常用 = 混合：大步骤用 Plan-and-Execute 规划，子步骤内部用 ReAct。
真实案例：一个订单查询 Agent 用纯 ReAct，查完顺手「了解」用户全部历史订单，3 步任务跑 12 轮——后来改成「意图明确走 Plan、模糊走 ReAct」。
四、单 Agent vs 多 Agent（2026 趋势）
- 单 Agent 优势：简单、延迟低、成本低、模型看全上下文做全局判断；劣势：上下文易爆、长上下文丢早期信息、一个 prompt 塞所有职责变屎山。
- 多 Agent / Router 优势：上下文隔离、子任务单独调优/换模型、可并行、可观测（哪步错了清楚）；劣势：每次多一步网络往返延迟高、token 成倍涨、路由本身可能错。
趋势判断（2026 重要观点）：业界正从「花式多 Agent」回归「单个强 Agent + 好工具 + 好的上下文工程」（Claude Code / Cursor / Cline 都是这个范式）。如果你的项目用多 Agent，必须能回答「相比单 Agent 的实质收益是什么」。
四种多 Agent 模式对照（必背）
| 模式 | 路由方式 | 成本 | 何时用 | 避免用 |
|---|---|---|---|---|
| Supervisor 主管 | 中央节点每轮多一次 LLM 路由调用 | 每轮 +1 次 | ≥5 个专家、入站任务分类清晰 | 延迟预算紧 |
| Swarm 群 | Agent 直接互相 handoff，省一次往返 | 摊销 | 2-3 个 Agent、交接上下文丰富 | 要频繁加新 Agent |
| Hierarchical 分层 | 每层 LLM 调用 | 逐层 | 团队套团队（subgraph） | 内层 <3 节点 |
| Network 网络 | 每个 agent 都看全局消息 | O(N) token | 3-4 个完全数据驱动 | >6 个先分区 |
一句话选型轴：延迟预算、路由决策复杂度、团队可扩展性。
五、什么场景「不该」用 Agent（反向题）
固定流程/简单规则能搞定、低延迟要求、成本敏感、高精度标准化问答、单工具调用 → 单 Agent 甚至不用 Agent。
一句话定调：Agent 的自主性是双刃剑——给太多不可预期，给太少退化成 Chatbot，工程核心是设计安全自主边界。