外观
基于 LLM 的 Agent
基于 LLM 的 Agent（智能体）是以大语言模型为"大脑"，通过"感知 → 规划 → 行动 → 观察"循环，自主调用工具、使用记忆、完成任务闭环的系统。如果说 ChatGPT 让大模型学会"说话"，Agent 就是让大模型学会"干活"——订机票、写代码、操作浏览器、管理数据。它是 2024 年后大模型应用最重要的演进方向，也被称为"从聊天到干活"的下一站。
一、Agent 是什么：四个组件缺一不可
| 组件 | 作用 | 典型实现 |
|---|---|---|
| 大脑（LLM） | 理解目标、做决策、生成行动计划 | GPT-4o、Claude、DeepSeek 等任意强模型 |
| 工具（Tools） | 让模型接触外部世界（检索、代码、API、浏览器） | function calling、MCP、代码解释器、浏览器操作 |
| 记忆（Memory） | 短期：当前任务上下文；长期：跨会话的经验与知识 | 对话历史、向量库、文件系统 |
| 循环（Loop） | 反复"思考-行动-观察"直到任务完成 | ReAct、Plan-and-Execute、反思 |
一句话：Agent = LLM 大脑 + 工具手脚 + 记忆库存 + 循环驱动。其中"工具"经常是一套 RAG 检索（见 RAG：检索增强生成）或外部 API。
一句话记住 Agent 的本质：它把"模型的判断力"与"程序的确定性"绑在一起——判断错了有护栏兜底，程序执行错了有日志追责。
初学者常把 Agent 与"长提示词"混淆。区别在于：提示工程是"静态"的——把指令与示例一次性塞进上下文，模型一次生成；Agent 是"动态"的——模型在循环中反复决策，每次行动都改变下一次的输入（工具结果、记忆更新）。一个可操作的判断标准：如果任务可以在一次生成内完成，不需要工具与环境反馈，那就是提示工程问题；如果任务需要多步、依赖外部状态、可能中途失败并重试，那就是 Agent 问题。当然两者是连续谱：简单的 ReAct 循环也可以看作"带工具的多轮提示"。这个边界也决定了学习顺序：先把提示做好（见 提示工程），再引入工具与循环。
循环示意：
while 任务未完成:
思考(Thought): 根据当前状态决定下一步
行动(Action): 调用工具 / 生成内容
观察(Observation): 读工具返回 / 环境反馈
记忆(Update): 把关键信息写回短期/长期记忆二、ReAct 模式：推理与行动交错
ReAct（Reasoning + Acting）是 Agent 最核心的运作模式，由 Yao et al. 在 2022 年提出（论文见参考资料）。它的精髓是让模型把"推理轨迹"和"工具调用"交错输出——想一步、做一步、看一步：
Thought 1: 我需要查询北京的天气，先调用天气工具。
Action 1: weather_search(城市="北京")
Observation 1: {"温度": 25, "天气": "晴"}
Thought 2: 得到天气后，再生成穿衣建议。
Action 2: 回答用户："北京今天 25 度、晴天，建议穿薄外套。"ReAct 的价值：推理让行动有依据，观察让推理有反馈。相比"一口气生成答案"，ReAct 显著提升了需要多步依赖的复杂任务成功率；同时推理轨迹天然可审计（每一步为什么这样做都有据可查）。
ReAct 之后，研究社区沿两个方向推进：一是"先计划后执行"（Plan-and-Execute 类），把长任务分解成可验证的子计划，降低循环中的迷失概率；二是"事后反思"（Reflexion 类），让模型根据失败反馈改写自己的行动策略。前者适合结构化任务，后者适合试错型任务（写代码、解数学题）。两者都可以与 ReAct 组合成更健壮的循环，取舍决定了 Agent 是"步步惊心"还是"稳扎稳打"，更详细的对比见 提示工程实践。
三、工具调用：function calling 与 MCP
1. Function Calling：让模型"指挥"函数
2023 年 6 月，OpenAI 在 API 中加入 function calling：把可用函数的 JSON Schema 传给模型，模型输出"该调用哪个函数、参数是什么"的结构化 JSON，由宿主程序执行并把结果回传给模型：
可用工具: [
{name: "get_weather", 参数: {city: string}},
{name: "book_flight", 参数: {from, to, date}}
]
模型输出: {"name": "book_flight", "arguments": {"from":"北京","to":"上海","date":"2025-06-01"}}Function calling 让"模型 + 任意 API"成为标准能力：查库存、发邮件、调数据库、操作企业内部系统。它的工程要点（结构化输出、参数校验、失败重试）见 提示工程实践。
2. MCP：把工具标准化
2024 年 11 月，Anthropic 开源 Model Context Protocol（MCP），目标是成为"AI 应用的 USB-C 接口"：定义统一协议，让任何模型框架都能以同样方式接入文件系统、数据库、浏览器、开发工具。MCP 的 host-client-server 模型：
模型框架 (Host) ←MCP协议→ MCP Client ↔ MCP Server（暴露资源/工具/提示）MCP 解决了工具生态的碎片化问题：开发者写一个 MCP server，即可被任意 Agent 框架复用。截至 2025 年，MCP 已成为开源 Agent 工具接入的事实标准。
工具化的下一个问题是谁来保证"工具可靠"。工具的 Schema 写错、参数校验缺失、返回格式漂移，都会让 Agent 的下一步决策建立在错误输入上。工程实践给出的答案有三层：一是"Schema 即契约"——工具描述要精确到每个参数的含义、类型与示例；二是"输出校验"——模型生成的调用参数先过校验再执行；三是"失败语义"——工具要返回结构化的错误码而不是随意文本。这三层合起来，就是 常见陷阱与反模式 中"工具滥用"与"无效调用"两坑的正面解法。
四、记忆：短期与长期
| 记忆类型 | 载体 | 生命周期 | 用途 |
|---|---|---|---|
| 短期（工作记忆） | 对话历史、上下文窗口 | 单次任务 | 保持当前任务状态与目标 |
| 长期（知识/经验） | 向量库、数据库、文件 | 跨会话 | 记住用户偏好、历史决策、积累经验 |
| 技能记忆 | 提示模板、工具用法 | 长期 | 复用已验证的解题套路 |
短期记忆受 上下文与长文本 限制，需要摘要/压缩；长期记忆通常用向量检索（RAG 的思路）实现——Agent 的长期记忆本质上就是"把 RAG 用作 Agent 的记忆库"。记忆与检索机制的底层见 RAG：检索增强生成。
Agent 记忆最常见的失效不是"记不住"，而是"记错与混淆"：短期记忆被无关信息挤占（上下文窗口塞满日志），长期记忆检索到不相关的旧经验（向量检索漂移），记忆更新覆盖了重要信息。工程上要给记忆设计"写入审计"与"回滚"——每条写入都有来源与时间戳，必要时能撤销。把记忆当作"需要版本管理的数据库"而非"对话草稿本"，是生产级 Agent 的必修课。
记忆还有一个"合规"维度常被忽视：长期记忆会累积用户的个人信息（偏好、病史、工作内容），一旦泄露或被不当使用，风险远高于单轮对话。设计记忆系统时至少要回答：存了什么、谁有权读、保留多久、如何删除。欧盟 GDPR 的"被遗忘权"与中国的个人信息保护法都直接约束这类场景。把记忆当作"受保护的数据库"来设计，而不是"对话缓存"，是生产级 Agent 的底线要求。合规框架见 安全与风险。
五、规划与反思
单靠 ReAct 的"走一步看一步"在长任务上容易迷失，业界演化出更结构化的规划：
| 策略 | 做法 | 适用 |
|---|---|---|
| CoT / ReAct | 推理与行动交错 | 通用任务（见 提示工程） |
| Plan-and-Execute | 先生成完整计划，再逐步执行 | 多步骤、子任务清晰 |
| 反思（Reflection） | 行动后自我评估、修正 | 写作、编码、反复迭代类任务 |
| 树搜索 / 多路采样 | 同时探索多条路径择优 | 高价值、错误代价高 |
让 Agent"多思考"不是免费的。规划层级的每一步推理都消耗 token 与时间：一个带完整规划+反思循环的 Agent，单任务 token 消耗可能是"直接回答"的 10~50 倍。工程上需要"按任务分级"：简单问题走"直接回答"（零规划），中等任务走"一次规划+执行"，复杂任务才上"规划+反思+重试"。分级的关键是任务的错误代价：写一封邮件出错成本低，可以直接答；删数据库出错成本高，必须先规划、再审阅、再执行。这种"成本感知的自主度"设计，是 Agent 工程里比"更强模型"更立竿见影的优化点。相关成本控制技巧见 常见陷阱与反模式。
Agent 的本质是"程序化推理"
规划能力越强的模型，Agent 越可靠——这就是为什么 o1 类推理模型 出现后 Agent 能力集体跃升。Agent 的上限 = 模型推理能力 × 工具质量 × 记忆管理。
六、多 Agent 协作：让 Agent 分工
多 Agent 系统把不同角色（PM、程序员、测试、评审）各配一个 Agent，通过消息协作完成复杂工程任务：
产品经理Agent ──需求──> 架构师Agent ──设计──> 开发Agent ──代码──> 测试Agent
▲ │
└────────────────────── 缺陷反馈与迭代 <────────────────────────┘| 框架 | 特点 |
|---|---|
| AutoGPT | 最早的自治 Agent（2023.3），单 Agent 自主拆解任务 |
| BabyAGI | 任务队列 + 执行 + 记忆，最小可玩原型 |
| MetaGPT | 多角色协作，模拟软件公司 SOP（2023.6） |
| ChatDev | 虚拟软件公司，对话式流水线开发 |
| OpenAI Swarm / Agent SDK | 轻量多 Agent 编排 |
| 商用产品 | Manus（通用 Agent）、Devin（软件工程师）、Operator（浏览器操作） |
注意：多 Agent 不是银弹——每多一个 Agent 就多一份错误传播与成本；很多任务"单 Agent + 好工具"反而更稳。多 Agent 的价值在"角色分工明确、接口清晰"的场景（如软件工程、内容生产流水线）。
多 Agent 的另一个"隐性成本"是协调开销：角色之间要传递状态、同步认知、仲裁冲突。实验表明，Agent 数量超过 3~5 个后，协作收益往往被通信与错误传播抵消。更实用的模式是"分层"：一个"主管 Agent"负责任务分解与结果验收，若干"执行 Agent"各自完成子任务，必要时再设"评审 Agent"。这种"少而精"的层级结构，比"平级大乱斗"稳定得多。框架支持方面，LangGraph 的图式编排与 OpenAI Agent SDK 的层级模型都比较适合这种设计（见 框架与工具选型）。
七、代表案例
| 案例 | 时间 | 定位 | 启示 |
|---|---|---|---|
| AutoGPT | 2023.3 | 自主任务拆解的开源 Agent | 引爆 Agent 概念，但稳定性差、成本失控，印证"单靠循环不够" |
| MetaGPT | 2023.6 | 多角色软件公司 | SOP 结构化降低多 Agent 协作熵 |
| Devin | 2024.3 | AI 软件工程师 | 长任务 + 编码工具链 + 云端环境，SWE-bench 当时大幅领先 |
| OpenAI Operator | 2025.1 | 浏览器操作 Agent | 把 Agent 接入真实网页，付费墙/验证码成为新障碍 |
| Manus | 2025.3 | 通用自主 Agent | 异步云端执行，证明"任务委托"商业模式 |
共同规律：成功的 Agent 都是"模型 × 环境 × 工具链 × 评测"四件套，缺一不可——只换大脑（模型）不做工程，Agent 不会变强。
代表案例还给出另一个教训——"快与稳的节奏"：AutoGPT 用最短时间引爆概念，却因稳定性与成本迅速退潮；Devin 与 Manus 收敛了任务边界与执行环境，才把 Agent 推到"可用"。这背后是 Agent 特有的"产品化陷阱"——演示视频里的"一键完成"背后，往往是数十次重试、人工干预与固定环境。评估一个 Agent 产品，别只看宣传的完成率，要问三个问题：在多大比例的真实输入上跑通？失败时是优雅降级还是静默出错？单位任务成本是多少？这三个问题的答案，才决定 Agent 能否从"演示品"变成"生产力"。
八、风险：提示注入、失控与成本
Agent 有工具、有权限、能自主行动，风险比纯对话大一个量级：
| 风险 | 表现 | 缓解 |
|---|---|---|
| 提示注入 | 网页/文档里藏恶意指令，诱导 Agent 执行 | 工具参数校验、内容与指令隔离、最小权限 |
| 工具滥用 | Agent 误调高成本/有副作用 API | 权限白名单、人审闸门（human-in-the-loop） |
| 失控与不可预期 | 长循环中偏离目标、自我强化错误 | 步数上限、预算上限、断点续跑、沙箱隔离 |
| 成本爆炸 | 循环 token 消耗、API 调用 | 路由（简单任务走小模型）、预算熔断 |
| 数据泄露 | Agent 把私有数据发给外部工具 | 出网审计、脱敏、日志留痕 |
提示注入是最独特的 Agent 风险：攻击者通过 Agent 读取的网页/文档注入指令，让 Agent 变成攻击者的工具。防御细节与安全基线见 安全与风险 与 常见陷阱与反模式。
别让 Agent 有"万能钥匙"
给 Agent 的权限应该是"完成任务所需的最小集合"，并全程记录行动日志。任何一个能自主调用 API 的 Agent 都应有：预算上限、步数上限、沙箱、审计日志——四条缺一不可。
九、Agent 的系统工程与评测
1. 工程分层：Agent 不止是一个循环
| 层 | 职责 | 关键问题 |
|---|---|---|
| 循环引擎 | 驱动"思考-行动-观察"直到终止 | 终止条件、步数上限、重试策略 |
| 工具注册 | 把函数、API、MCP server 暴露给模型 | Schema 准确、参数校验、幂等 |
| 状态管理 | 维护对话历史、记忆、中间产物 | 长任务上下文压缩、状态快照 |
| 可观测性 | 记录每一步推理与工具调用 | 审计日志、断点续跑、回放 |
2. ReAct 提示模板示例
可用工具：
- search(query)：联网搜索，返回网页摘要列表
- calc(expr)：执行数学计算
- read_url(url)：抓取网页正文
输出格式：严格按以下三步循环：
Thought: <当前判断>
Action: <工具名>(参数)
Observation: <工具返回>
直到无需再调用工具时，输出：
Answer: <最终回答>模板工程化的更多模式见 提示工程实践。
3. 工具定义的 JSON Schema
{
"name": "book_flight",
"description": "预订航班（必须校验日期格式与舱位）",
"parameters": {
"type": "object",
"properties": {
"from": {"type": "string", "description": "出发城市"},
"to": {"type": "string", "description": "到达城市"},
"date": {"type": "string", "description": "日期 YYYY-MM-DD"}
},
"required": ["from", "to", "date"]
}
}4. Agent 评测：四类指标缺一不可
| 类别 | 指标 | 说明 |
|---|---|---|
| 任务完成 | 完成率、成功率、质量分 | 用真实/仿真任务集度量 |
| 工具使用 | 调用正确率、参数错误率、无效调用率 | 暴露工具 Schema 质量问题 |
| 成本效率 | token 消耗、步数、API 费用 | 长循环会失控，必须设预算 |
| 安全 | 越狱成功率、权限越界、数据泄露 | 见上文风险节 |
5. 状态管理与长任务的工程细节
生产级 Agent 与演示级 Agent 的最大差距在状态管理。演示级 Agent 把所有历史塞进上下文，任务一长就"忘事"或"爆上下文"；生产级 Agent 需要：①结构化的任务状态（目标、子任务、已完成/失败清单）保存在外部，而不是依赖模型记忆；②上下文分层——高频的工作记忆放窗口，低频的长时记忆进向量库（见 RAG：检索增强生成）；③断点续跑——进程崩溃后能从未完成步骤恢复；④幂等工具——同一个工具调用重复执行不产生副作用（这是 Agent 工程里最常见的坑）。这些工程细节决定了 Agent 能否从"demo 能跑"走到"生产可靠"，更完整的工程清单见 常见陷阱与反模式。
5. 代表框架对比
| 框架 | 特点 | 适合 |
|---|---|---|
| LangGraph | 图式编排，细粒度控制循环 | 复杂工作流、企业级 |
| AutoGen | 多 Agent 对话式协作 | 研究原型 |
| OpenAI Agent SDK | 轻量、官方生态 | 快速接入 GPT 系列 |
| Claude Code / Cursor | 终端/IDE 内 Agent | 软件开发助手 |
| Dify / 低代码平台 | 可视化编排 + RAG | 业务人员搭应用 |
框架选型的完整方法论见 框架与工具选型；RAG 作为 Agent 的记忆库见 RAG 实战。
Agent 落地的一条主线
从"单轮问答"到"单 Agent + 工具"再到"多 Agent 协作"，每走一步都要重新评估收益与失控风险。多数业务价值来自第二步；第三步只在分工清晰时才值得。术语对照见 术语表。
十、与另一套 Agent 手册的边界
本手册（《大模型手册》）与本系列另一套 《Agent Harness 手册》 的边界如下：
| 主题 | 归属 |
|---|---|
| LLM 大脑：推理、提示、对齐、幻觉 | 《大模型手册》（本页及 concepts 各页） |
| Agent 的认知模式：ReAct、规划、反思、记忆架构 | 本页（案例视角）+ 大模型手册概念页 |
| Harness（运行外壳）：执行循环引擎、权限沙箱、生命周期管理、可观测性、并发调度 | 《Agent Harness 手册》 |
| 工具协议（MCP）、函数调用规范 | 本页介绍 + Harness 手册的工程实现 |
| 多 Agent 编排框架、部署运维 | 《Agent Harness 手册》 |
简单说：本页回答"Agent 的大脑能做什么、怎么做决策"；Harness 手册回答"Agent 的躯干怎么安全可靠地执行"。读者如要搭建生产级 Agent 系统，请把本页与 Harness 手册合起来读。
最后给一个"什么时候读哪本"的建议：如果你在做原型验证、评估"模型能不能当大脑"，读本页就够；如果你要把它跑成 7×24 的生产服务（并发、权限、可观测性、回滚），请转去读《Agent Harness 手册》。两册合读，才能既懂大脑、又懂躯干。
十一、Agent 的落地与未来
1. Agent 的商业化场景
| 场景 | 形态 | 价值 | 成熟度 |
|---|---|---|---|
| 客服 / 售前 | 检索 + 工单 + 话术 | 7×24 响应 | 高 |
| 软件开发 | 代码生成 + 自测 + 修复 | 效率提升数倍 | 中高 |
| 数据与分析 | 自然语言查数 + 出报表 | 人人可分析 | 中 |
| 个人助理 | 日程、邮件、差旅委托 | 节省事务时间 | 中 |
| 企业流程自动化 | 审批、对账、风控 | 替代 RPA 场景 | 中低 |
| 研究助手 | 文献检索 + 实验分析 | 加速研究 | 早期 |
2. 从原型到生产的检查清单
- [ ] 任务边界清晰（什么不做、做到哪一步）
- [ ] 工具白名单与最小权限
- [ ] 步数上限、token 预算、超时熔断
- [ ] 全链路日志与回放（出问题可追溯）
- [ ] 人工审批闸门（高风险动作）
- [ ] 评测集（任务完成率、成本、安全）
- [ ] 灰度上线与回滚机制
3. Agent 的未来趋势
- 推理模型加持：o1 类"慢思考"大幅提升 Agent 的规划与纠错能力（见 前沿进展）；
- 协议标准化：MCP 之后，工具、身份、权限的标准化协议将持续收敛；
- 从单任务到多任务：Agent 从"完成一次任务"走向"管理长期目标"；
- 多模态感知：看懂屏幕、听懂会议的 Agent 打开新场景（见 多模态大模型）。
4. 常见误区与反模式
| 误区 | 正确姿势 |
|---|---|
| 把复杂任务全交给 Agent | 拆解 + 人审闸门 |
| 给满权限"效率优先" | 最小权限 + 审计 |
| 无限循环不设上限 | 步数/预算双熔断 |
| 只测能力不测成本 | 成本指标进评测 |
| 忽视提示注入 | 内容与指令隔离、参数校验 |
5. 高频问题速答
| 问题 | 速答 |
|---|---|
| Agent 和 RAG 什么关系？ | RAG 是 Agent 的一种工具/记忆（见 RAG：检索增强生成） |
| 单 Agent 还是多 Agent？ | 多数先单 Agent + 工具，分工明确再上多 Agent |
| function calling 和 MCP 区别？ | FC 是接口能力，MCP 是标准化协议 |
| Agent 什么时候会失控？ | 无上限 + 大权限 + 长循环，三缺一不可免 |
| 怎么评测 Agent？ | 完成率 + 工具正确率 + 成本 + 安全四件套 |
| 和 Harness 手册怎么分工？ | 本页讲大脑与认知，Harness 讲执行外壳 |
一句话记住 Agent 落地
Agent 的价值 = 任务价值 × 成功率 − 成本 − 风险。先挑"规则清晰、反馈快、可回滚"的任务，把评测与护栏做扎实，再逐步扩大自主度。
Agent 的最终衡量标准不是"能做什么"，而是"可靠地做什么"——把成功率与成本一起写进验收条件。
十二、Agent 的关键论文与框架资源
1. 关键论文速览
| 论文 / 工作 | 年份 | 一句话贡献 |
|---|---|---|
| ReAct | 2022 | 推理与行动交错的奠基范式 |
| Toolformer | 2023 | 模型自学使用工具 |
| HuggingGPT | 2023 | 用 LLM 编排多模型任务 |
| Reflexion | 2023 | 语言反馈驱动的自我改进 |
| SWE-bench | 2023 | 真实软件工程任务基准 |
| AgentBench | 2023 | 跨环境 Agent 评测 |
| MCP 协议 | 2024 | 工具接入标准化 |
2. 评测基准
| 基准 | 场景 | 说明 |
|---|---|---|
| SWE-bench | 软件工程 | 真实 GitHub issue 修复 |
| AgentBench | 多环境 | OS、数据库、网页等 |
| GAIA | 通用助手 | 现实任务集 |
| τ-bench | 工具调用 | 工具使用准确性 |
3. 框架与工具资源
| 框架 | 特点 | 上手难度 |
|---|---|---|
| LangGraph | 图式编排，生产级 | 中 |
| AutoGen | 多 Agent 对话 | 低 |
| CrewAI | 角色化多 Agent | 低 |
| OpenAI Agent SDK | 官方轻量 | 低 |
| Claude Code | 终端编码 Agent | 低 |
| Dify | 可视化 + RAG + Agent | 极低 |
对初学者的行动建议：先别急着搭多 Agent。推荐的入门路径是：①用现成 API + function calling 做一个"单 Agent + 三个工具"的最小系统（如查天气、查日历、发邮件）；②加上 ReAct 循环与日志，观察每一步的决策质量；③引入记忆与评测集，量化完成率与成本；④最后才尝试多 Agent 与 MCP。这条路径每一步都有明确的可验证产出，也正好覆盖从提示到部署的知识闭环。Agent 的能力来自循环与工具的设计，而不只是模型的选择——先动手，认知会快得多。
十三、Agent 的伦理与责任
1. 责任归属问题
Agent 自主行动时，"谁对结果负责"变得模糊：
| 环节 | 责任主体 | 建议 |
|---|---|---|
| 指令理解 | 使用者 | 明确任务边界 |
| 工具调用 | 开发者 | 最小权限 + 审计 |
| 最终输出 | 部署方 | 人审闸门 + 纠错机制 |
| 数据使用 | 部署方 | 隐私与合规评估 |
2. 失控与误用风险
- 越权操作：Agent 在无授权下访问敏感系统；
- 提示注入：外部内容诱导 Agent 执行恶意指令；
- 放大错误：错误决策被自动执行并扩散（如批量发信、删数据）；
- 欺诈滥用：深度伪造、自动化社工。
3. 负责任部署的原则
- 默认最小权限：给 Agent 的权限永远小于所需上限；
- 人审高风险动作：删除、支付、对外发布必须人工确认；
- 全程可追溯：每步推理、工具调用、参数都留日志；
- 失败默认安全：超时/异常时停止而不是继续；
- 持续评测：把安全指标纳入 Agent 评测集（见 评估实战）。
4. 一个思想实验：什么时候不建 Agent
负责任也包括"克制"。当一个任务满足以下任意一条时，优先考虑不用 Agent：①任务失败代价极高且不可回滚（医疗、金融决策）；②任务定义模糊，连人都说不清"成功长什么样"；③外部依赖不稳定（第三方 API 随时变）；④已有稳定的传统流程，Agent 只是"听起来更酷"。Agent 的自主性是把双刃剑：它能放大你的执行能力，也能放大你的失误。稳妥的做法是"渐进自主"——先人工审核每一步，再放权到部分步骤，最后才在评测与护栏齐备后全自主。这条路径也呼应了本页反复强调的"最小权限、全程可审计、失败默认安全"三原则。
Agent 不是"甩锅工具"
把任务交给 Agent 不意味着把责任交给 Agent。部署方必须能回答：它做了什么、为什么这么做、出错了谁能拦。三个问题答不上来，就不要让 Agent 直接面对用户或生产系统。
又及：评估一个 Agent 团队是否成熟，可以看它是否把"失败案例复盘"当作固定流程——Agent 的进步来自对失败的系统性归因，而不是对成功的一再重复。
十四、延伸阅读
- 提示工程——Agent 推理与规划的提示基础
- RAG：检索增强生成——Agent 长期记忆与知识工具
- 安全与风险——提示注入与 Agent 安全
- 提示工程实践——function calling 与结构化输出工程
- RAG 实战——Agent 记忆库搭建
- 常见陷阱与反模式——Agent 失控与成本陷阱
- 前沿进展——Agent 与工具使用的研究趋势
参考资料
- Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models（2022）——ReAct 论文（arXiv）
- Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools（2023）——Toolformer 论文（arXiv）
- OpenAI. Function calling and other API updates（2023.6）——function calling 官方发布
- Anthropic. Model Context Protocol 官方文档——MCP 协议文档
- Significant-Gravitas. AutoGPT 开源仓库——AutoGPT 代码库
- MetaGPT 开源仓库——MetaGPT 代码库
- Cognition. Introducing Devin（2024.3）——Devin 官方发布
- OWASP. Top 10 for Large Language Model Applications——LLM 应用安全风险清单