AI AGENT · 智能体 / 工具调用
AI Agent速查
从 ReAct 模式、Function Calling 到 MCP 协议、记忆机制与多智能体协作，再到可观测、沙箱与评估的工程落地，AI Agent 的 46 条核心要点一张表收齐，随查随用。
46个要点
9大板块
∞持续更新
📖 速查表
点击展开各小节
🤖 Agent 基础
| 名称 | 说明 | 要点 |
|---|---|---|
| Agent 四要素 | LLM（大脑）+ Planning（规划）+ Tools（工具）+ Memory（记忆），缺一不可 | 没有工具只是聊天机器人，没有记忆无法完成跨轮任务 四位一体 |
| ReAct 模式 | 思考 → 行动 → 观察 循环：先推理该做什么，再调用工具，根据观察结果决定下一步 | 最通用也最好上手的模式；缺点是步数多、token 消耗大 推理行动循环 |
| Plan-and-Execute | 规划器先拆解生成完整任务计划，执行器逐步执行，支持执行中重规划修正 | 适合复杂多步任务，LLM 调用次数比逐步 ReAct 更省 先规划后执行 |
| Reflexion 自我反思 | 任务失败或结果不佳时，让模型生成语言化的反思总结，存入记忆供下一轮尝试改进 | 对代码与推理类任务提升明显，代价是额外的反思轮次开销 失败复盘 |
| 停止条件 | 显式定义终止条件：任务完成标记、最大步数、预算耗尽、连续失败上限 | 不设最大步数必然死循环烧钱，生产环境必须硬性限制 强制上限 |
🛠️ 工具调用
工具是 Agent 的手脚：定义质量决定模型会不会用、用得准不准，执行安全决定会不会闯祸。
| 名称 | 说明 | 要点 |
|---|---|---|
| Function Calling 流程 | 定义工具 → 模型决定调用 → 解析参数 → 代码侧执行 → 结果回传 → 模型继续推理或总结 | 模型输出的只是结构化「调用意图」，真正执行永远在你的代码里 意图由模型，执行靠代码 |
| JSON Schema 要点 | name 用清晰的动词短语，description 写清「何时该用我」，parameters 描述类型与 required | description 的质量直接决定模型选工具的准确率，值得反复打磨 描述即提示词 |
| 并行与串行 | 相互独立的调用（如同时查三个城市天气）可并行；有依赖关系的调用必须等待前序结果 | 解析 tool_calls 数组并发执行，端到端延迟显著下降 并行提速 |
| 错误处理与重试 | 工具执行失败应把错误信息作为观察结果返回给模型，让它决定重试、换工具还是放弃 | 重试要加指数退避与最大次数；不要抛异常打断会话 错误也是观察 |
| 工具集设计 | 工具数量控制在 10~20 个以内，功能相近的合并，参数层级避免过深嵌套 | 工具越多模型选择越容易混淆，宁可少而精 少即是多 |
🔌 MCP 协议
| 名称 | 说明 | 要点 |
|---|---|---|
| MCP 是什么 | Model Context Protocol，Anthropic 于 2024 年开源的开放协议，标准化 AI 应用连接外部工具与数据源的方式 | 被称作 AI 应用的「USB-C 接口」，已被主流 IDE 与客户端广泛支持 开放标准 |
| 三角色分工 | Host（宿主应用，如 IDE/桌面客户端）、Client（宿主内的连接器，与 Server 一一对应）、Server（提供工具与数据的服务端） | 一个 Host 可同时挂载多个 Server，架构思路类似 LSP 类 LSP 架构 |
| 常见 MCP Server | Filesystem（文件读写）、数据库（SQL 查询）、浏览器自动化（如 Playwright）、Web 搜索、Git 仓库等 | 官方维护参考实现，社区生态已覆盖主流 SaaS 与基础设施 生态复用 |
| 三大原语 | Tools（模型可调用的函数）、Resources（应用可读取的数据）、Prompts（预置的提示词模板） | Tools 由模型决定调用，Resources 由应用侧控制读取，权限边界不同 权责分离 |
| 与 Function Calling 关系 | MCP 解决工具的「发现、接入与分发」，Function Calling 是模型层的「调用」能力，两者互补 | 服务方按 MCP 实现一次，即可被所有支持协议的模型与客户端使用 一次接入多方复用 |
🧠 记忆机制
| 名称 | 说明 | 要点 |
|---|---|---|
| 短期 vs 长期 | 短期记忆即当前会话的上下文窗口，会话结束即清空；长期记忆外置到向量库等存储，跨会话持久化 | 上下文窗口是「草稿纸」，长期记忆才是「笔记本」 外置存储 |
| 对话摘要压缩 | 把较早的对话轮次用 LLM 压缩成摘要，原文只保留最近若干轮，上下文超限时自动触发 | 可节省大半 token，代价是丢失部分早期细节；关键事实要单独落库 摘要旧轮保留新轮 |
| 记忆检索要点 | 向量相似度召回 Top-K 相关记忆注入上下文，配合去重、时间衰减与重要性打分 | 本质是 RAG 思想：检索质量决定回答质量，噪声记忆反而有害 检索式记忆 |
| 记忆写入时机 | 会话结束蒸馏写入、重要事实即时写入、或定期批量整理归档 | 全量存储成本高且噪声大，要有「值得记」的过滤门槛 写入有门槛 |
👥 多智能体协作
| 名称 | 说明 | 要点 |
|---|---|---|
| 主从模式（Supervisor） | 编排者 Agent 接收任务并分派给各专职 Agent，再汇总各自结果 | 结构清晰、易调试易追责，是生产环境最常用的模式 首选模式 |
| 流水线模式 | Agent 按固定顺序接力：需求分析 → 编码 → 评审 → 文档，每站只管一段 | 职责边界清晰，但上游错误会被下游逐级放大 分工接力 |
| 辩论模式 | 多个 Agent 各自给出方案后互相批判，再由裁判角色做出最终裁决 | 推理类任务质量更高，但 token 成本成倍增长 质量换成本 |
| 群聊模式 | 多个 Agent 在共享上下文中自由发言，由管理员 Agent 或发言规则控制轮次 | 灵活但容易跑题发散，需要硬性发言上限与终止条件 自由但易发散 |
| 框架一句话定位 | AutoGen 对话驱动多智能体；CrewAI 角色分工式团队协作；LangGraph 图结构状态机编排 | 按控制粒度选型：LangGraph 最灵活但学习曲线最陡 按需选型 |
| 成本与风险 | 多智能体的 token 消耗常是单 Agent 的数倍到数十倍，Agent 间传递的错误还会累积放大 | 先把单 Agent 和工具做好，确有必要再引入多智能体 能单勿多 |
🏗️ 工程落地
| 名称 | 说明 | 要点 |
|---|---|---|
| 全链路 Tracing | 每步的输入输出、工具调用、token 与耗时全部留痕（如 LangSmith / Langfuse） | 没有 Tracing 的 Agent 调试等于盲猜，生产上线前必接 生产必接 |
| Token 与成本看板 | 按用户、会话、Agent 维度统计 token 用量与调用次数，折算为成本可视化 | 给单会话设预算告警，异常消耗（如死循环）第一时间熔断 预算告警 |
| 沙箱与权限控制 | 代码执行、文件写入等高风险操作放进容器等沙箱，危险动作加人工确认环节 | 最小权限原则：默认只读，写操作逐步放开并全程审计 最小权限 |
| 失败降级策略 | 模型超时或异常时降级到备用模型、固定话术兜底或转人工处理 | 核心业务必须有「Agent 不可用时怎么办」的预案 有备无患 |
| 评估（Eval）思路 | 构建测试集做回归评估：任务完成率、平均步数、成本、延迟；代码类任务可用测试通过率判分 | LLM-as-Judge 打分 + 人工抽样校准，每次改提示词都跑一遍 量化迭代 |
⚖️ 工作流 vs Agent
| 维度 | 说明 | 选型要点 |
|---|---|---|
| Workflow 工作流 | 预先编排好流程，LLM 在固定路径的节点上执行，路径由代码决定 | 输出确定可审，适合审核、工单、内容生成等高稳定场景 确定性优先 |
| Agent 智能体 | LLM 自主决定步骤与工具使用，路径在运行时动态生成 | 适合开放式任务（调研、编程、分析），结果具有概率性 灵活性优先 |
| 确定性对比 | Workflow 输出可预期可回放；Agent 同样输入两次执行路径可能不同 | 合规、金融、医疗等强监管场景优先 Workflow 强监管慎用 Agent |
| 成本对比 | Workflow 的 token 消耗线性可预估；Agent 循环步数不受控，成本波动大 | 两类都要设最大步数与预算上限兜底 预算封顶 |
| 选型建议 | 先问「固定流程能不能解决」，能解决就上 Workflow；只有真正需要动态决策时再引入 Agent | 生产系统多为混合形态：主流程用 Workflow，局部难点嵌 Agent 混合架构 |
🧰 MCP 实操要点
协议概念见上方「MCP 协议」，这里讲落地运维：Server 怎么选、权限怎么收、日志与兜底怎么留，接入前逐条对照。
| 要点 | 说明 | 落地建议 |
|---|---|---|
| Server 选型 | 优先选官方或社区维护活跃的实现：看最近提交频率、issue 响应速度与文档完整度，停更项目再好用也别上生产 | 维护活跃度优先 先查最近提交 |
| 最小权限 | 只开启业务需要的工具与资源范围：文件 Server 只挂工作目录，数据库 Server 用只读账号，绝不默认全开 | 按需开启 + 只读起步 权限宁小勿大 |
| 调用日志全记录 | 每次工具调用的 Server、工具名、参数、返回与耗时全部落日志，出问题可回放定位、可审计追责 | 参数 + 结果 + 耗时 全留痕 日志即证据 |
| 超时与重试上限 | 为每个 Server 设连接与调用超时，重试限定次数；一个 Server 卡死会阻塞整个会话、白烧 token | 超时 + 重试上限 必设 卡死即熔断 |
| Server 复用共建 | 同类能力团队内只维护一套公共 Server（如统一的数据库、Web 搜索 Server），各项目挂载复用，避免重复实现、重复鉴权与重复审计 | 一套 Server 全团队共用 沉淀为基础设施 |
| 密钥不进模型上下文 | Server 凭据只配在进程侧（环境变量 / KMS），绝不通过提示词或工具参数传给模型——上下文可能被注入诱导，也可能随日志外泄 | 凭据只留在 Server 侧 防注入防外泄 |
🧪 Agent 评估用例设计
评估思路见「工程落地」，这里落到用例设计：分几层、每层多少条、怎么判分，照此搭一套可持续回归的评估集。
| 评估项 | 用例设计 | 判分与要点 |
|---|---|---|
| 单工具调用正确率 | 为每个高频工具出 10~20 条「输入 → 期望调用的工具与参数」断言用例 | 参数逐字段比对，先保单步选对再谈多步 地基指标 |
| 多步任务完成率 | 设计 20~30 条端到端场景题，预先写清可判定的完成标准（产物存在且内容合规、答案含指定要素） | 只看终态是否达标，不纠结路径 终态判分 |
| 幻觉率抽检 | 从结果中抽样：把答案里的事实性主张逐条与工具返回、检索资料比对，标注无中生有的比例 | 无出处主张单独统计 人工抽样比对 |
| 成本与步数统计 | 每条用例记录平均步数、token 与耗时作为基线；回归时超基线阈值即预警 | 步数暴涨多为死循环或选错工具 基线对照 |
| 回归集随版本更新 | 换模型、改提示词、升级 MCP Server 前后全量重跑；线上新踩的坑沉淀为新增用例 | 用例库只增不删 改一处跑一遍 |