简介《AI Agent综述》是由斯坦福李飞飞教授与微软研究院合作者共同撰写的英文综述PDF面向人工智能研究者、AGI方向学习者及多模态应用开发者系统梳理了Agent AI的原理、架构与应用前景。该综述将“Agent AI”定义为一类可感知视觉、语言及环境数据并产生具身行动的交互式系统指出基于基础模型构建智能体、嵌入物理与虚拟环境可实现对用户动作、人类行为、环境对象、音频表达及集体情感的感知与响应是迈向人工通用智能的一条重要路径。资源为1个PDF文件约50.51MB内容涵盖引言、研究背景、方法论、多模态交互案例与未来展望等完整章节。已有6683人学习下载既可作为Agent和多模态AI领域的框架性参考也适合论文精读、课题调研、技术汇报时引用原始出处。1. 先看懂这份综述的分量AI Agent 为什么成了大模型的最终落点提到 AI Agent 综述先别把它当成一篇「论文摘要汇总」。真正值得读的 Agent 综述解决的是这样一个问题大模型单独用只是「问答工具」一旦给它接上规划、记忆和工具调用它就从一个「会说话的模型」变成一个「能办事的实习生」。这个转变就是 Agent 与 Chatbot 的分水岭。业界流传颇广的那份 Agent 综述把这条技术路线拆成了三层架构、四类能力、五类风险和一套评估框架内容并不深奥但把「能做」和「能落地」之间的鸿沟讲得很实在。这篇笔记不替你做文献导读而是按综述的骨架把每一条核心结论翻译成可复现的工程动作——适合正在做智能体应用的开发者也适合想评估这个方向值不值得投入的技术负责人。2. 综述里的三层架构认知、记忆与行动分别对应什么工程组件大多数 Agent 综述都会把智能体拆成三层认知层规划与决策、记忆层短期与长期、行动层工具与执行。这个分层不是学术摆设它直接对应你代码里要写的模块。认知层决定 Agent 怎么拆解任务记忆层决定 Agent 记得什么、忘掉什么行动层决定 Agent 能不能真正改文件、查数据库、调接口。三层里任何一层瘸腿整体表现都会断崖式下跌。2.1 认知层规划、反思与任务分解这是 Agent 和 Chatbot 的分水岭你可以只用 prompt 就让模型「想一想再回答」但那是 Chatbot 级别的「假规划」。真正的 Agent 规划是把一个高层目标拆成可执行的多步动作并且在每步执行后根据反馈决定下一步走还是回头。综述里反复提到的 ReAct 模式推理 行动交替就是最轻量的实现方式模型先输出推理过程再输出一个工具调用拿到结果后继续推理直到任务完成。工程上的第一次分化也发生在这让模型把任务拆成步骤列表Plan-then-Execute还是让模型边做边想ReAct两者的取舍很清晰模式优点缺点适用场景Plan-then-Execute路径可预期方便人工审查环境变化后计划失效流程固定的批处理任务ReAct 循环适应动态环境步数不可控token 消耗大需要探索的任务两种结合先给计划执行中动态修订实现复杂度高多步骤真实业务我一般建议从 ReAct 起步。原因很实际它不要求你提前设计完备的任务 DAG只要给模型一个工具清单它自己会试错。等你的任务类型收敛了、工具稳定了再改成 Plan-then-Execute 也不迟。反思机制是另一个容易遗漏的组件。综述里的 Self-Reflection 说的是让模型在失败后总结原因再重试。工程上对应的是「如果上一步工具调用报错把报错信息拼进上下文让模型看到错误并调整策略」。这一步看着简单但对成功率的影响经常超过换一个大一档的模型。2.2 记忆层短期上下文与长期向量库如何协同参数该往哪调Agent 的短期记忆就是当前会话的上下文窗口它先天有两个问题容量有限、且不分轻重。窗口被日志和中间结果塞满时Agent 会「忘记」最初的任务目标。长期记忆则是把重要信息放到外部存储常见的是向量数据库按需取回。综述里对应的是记忆的写入、检索与遗忘三类机制。写入的工程决策哪些内容进长期记忆全量写入会让检索信噪比急剧下降。常见做法是让模型先对一段对话做摘要只把摘要向量化入库。这个过程可以用一个简单的 LLM 调用完成也可以用专门的摘要链路。注意摘要本身也会丢信息所以要保留原文 ID 作为溯源。检索的工程决策向量召回后默认取 top_k 个片段塞进上下文。top_k 不是越大越好我见过很多翻车现场是把 top_k 从 3 调到 10结果无关片段占了窗口、模型被带偏。相似度阈值比 top_k 更关键——低于阈值的片段宁可丢弃也别注入。两类阈值需要分开调召回阈值决定哪些片段值得看0.35 起步按业务场景调相关性阈值决定注入前是否二次筛选0.55 起步宁可空召回也不滥召回遗忘机制常被忽视。保质期超过 90 天的记忆、已经被撤回的文档、用户明确要求删除的内容都应该从库里清理。别偷懒不做时间一长你会得到一个大杂烩式的记忆库检索质量掉得没眼看好。2.3 行动层工具调用、代码执行与 RAG让 Agent 脱离「只会说不会做」行动层是 Agent 和普通聊天应用最大的区别。综述对这一层的核心结论是Agent 的能力边界由工具决定不由模型决定。也就是说你给 Agent 配了数据库查询工具它才能查库配了代码执行沙箱它才能算数。模型的角色变成「决定用哪个工具 生成工具入参」。工具调用的工程实现有两代做法。第一代是让模型输出一个特定格式的 JSON你解析后自己路由到具体函数。第二代是各家大模型 API 普遍支持的函数调用Function/Tool Calling模型在生成文本的同时输出结构化的工具调用请求由运行时负责调度。后者的解析成功率显著更高建议新项目直接选用支持这种方式的模型服务。代码执行器是 Agent 工具箱里最特殊的一员。它既能做算术也能跑数据分析、生成图表但它是双刃剑执行的代码可能有副作用读写文件、发请求。综述对这类工具的建议是「最小权限 沙箱隔离」。我自己做数据类 Agent 时把代码执行环境放到独立容器里只暴露必要的数据目录网络默认不可达需要联网的工具单独审批。这道隔离墙要不要做、做到多严直接决定你的 Agent 能不能从 Demo 走到生产。RAG 在这里的定位也值得说明它本质上是给 Agent 挂了一个「读文档」的工具。区别在于RAG 只是把检索结果塞进上下文Agent 还多了「决定哪些文档值得检索」的主动性。所以评测 Agent 时别拿纯 RAG 的指标来打分它们考的不是同一件事。3. 把综述读成工程方案从一个最小闭环到多智能体协作的落地路径前面把架构讲透了这一章解决的是最实际的问题从哪里开始写代码综述不会给你代码但它会反复强调「最小可行闭环」的价值。我建议你也这么做——先用一个能跑的循环把端到端链路打通再逐步加记忆、加工具、加多智能体协作。不要一上来就铺大架构那是最容易翻车的开始方式。3.1 先跑通最小闭环一个不绑定具体厂商接口的 ReAct 循环下面这段代码是不依赖任何特定模型服务商的抽象实现核心是把「思考-调用-观察」这个循环写清楚。你只需要实现llm_respond函数把自家模型服务的请求封装进去即可。# minimal_agent.py # 最小 ReAct Agent 循环思考 - 工具调用 - 观察结果 - 再思考 import json from typing import Callable, Dict, List def agent_loop( llm_respond: Callable, # 封装了模型调用传入消息列表返回文本 task: str, tools: Dict[str, Callable], function_schema: List[dict], # 工具描述格式按模型服务的要求来 max_rounds: int 6, temperature: float 0.2, ) - str: 返回最终答案文本。max_rounds 是硬性上限防止死循环。 messages [ {role: system, content: ( 你是一个任务执行助手。你需要通过调用工具完成任务。 每次回复要么输出最终答案要么输出一个工具调用。 )}, {role: user, content: task} ] for _ in range(max_rounds): # 请求模型出招可能直接给答案也可能要调用工具 response llm_respond( messagesmessages, toolsfunction_schema, temperaturetemperature, ) tool_calls response.get(tool_calls) if not tool_calls: # 模型没有要求调用工具视为给出最终答案 return response[content] # 把模型的回复追加进历史让上下文连续 messages.append({ role: assistant, content: response[content], tool_calls: tool_calls, }) # 逐个执行工具调用并把结果以 tool 角色回填 for call in tool_calls: fn_name call[function][name] fn_args json.loads(call[function][arguments]) print(f[tool] {fn_name} {fn_args}) if fn_name not in tools: result f错误未找到工具 {fn_name} else: result tools[fn_name](**fn_args) messages.append({ role: tool, tool_call_id: call[id], content: str(result), }) # 超限未收敛返回当前上下文里的最后一条模型输出 return messages[-1][content]这段代码的逻辑线其实就三条。第一条是消息历史里同时包含 assistant 和 tool 两类角色模型每轮都能看到自己上一次调用工具的入参与出参这是决策连贯性的基础。第二条是每次循环都检查tool_calls一旦模型不再请求工具就认为是收敛但是要注意模型可能因为上下文太长而提前放弃调用工具直接给一个不完整的答案——这需要靠日志里「收敛轮数」这个指标去发现。第三条是max_rounds这个硬上限它是最重要的保险丝没有它任何一次返回格式异常都会演变成 token 烧穿成本。temperature参数值得单独说。Agent 循环里建议固定到 0.1 到 0.2不是因为它让输出更「正确」而是因为工具入参的 JSON 格式稳定性对温度极其敏感温度每高一截解析失败率就明显涨一截。等你把循环逻辑调稳了再单独放开温度去做创意型任务也不迟。llm_respond的函数签名也可以说明一下。我刻意只在代码里声明了messages、tools、temperature三个参数因为不同模型服务商对工具调用的字段命名不同有的是tools有的是functions返回结构也略有差异。用一个包装函数把它们统一掉后续切换模型服务时只改这一个函数其余逻辑不动这是架构上的隔离点别偷懒省掉。3.2 多智能体协作两种主流通信机制的实现取舍跑通单 Agent 后下一步通常是「一个 Agent 不够用」——有的任务需要查资料、写代码、做质检同时进行单 Agent 串行做太慢。这时就要引入多智能体协作。综述对这一块的重点不是「Agent 数量越多越强」而是三种协作拓扑各自适合什么任务# 多智能体协作的三种拓扑示意伪代码风格 # 方式一顺序传递 def sequential_pipeline(agents, task): result task for agent in agents: result agent(result) return result # 方式二黑板共享 def blackboard_mode(agents, shared_blackboard, rounds3): for _ in range(rounds): for agent in agents: entry agent(shared_blackboard.read_all()) shared_blackboard.write(entry) return shared_blackboard.read_all() # 方式三编排者模式 def orchestrator_mode(planner, workers, task): plan planner(task) # 编排者拆解任务 results [] for item in plan[subtasks]: results.append(workers[item[assignee]](item)) return plan[aggregate](results)顺序传递最直观A 做完交给 B但不能并行而且前面环节的错误会被直线放大。黑板模式适合大家往同一个共享区写结果适合头脑风暴和评审类任务缺点是共享区的数据会越来越庞杂Agent 读取时要自己过滤噪音。编排者模式是生产环境里最常用的一个规划 Agent 负责拆任务和分配多个执行 Agent 并行干活最后汇总。它的好处是每个角色职责单一、出问题好定位坏处是规划 Agent 一旦拆错任务下面全部白干。通信机制上三种模式都绕不开「消息要结构化」。别让 Agent 之间传递长段自由文本那样接收方难以准确提取信息。业界常见的做法是定义固定的消息结构发送方 ID、接收方 ID、消息类型、内容正文、关联的任务 ID。这套结构看着简单但能救你于水火——排查问题时靠任务 ID 一拉全链路比翻聊天记录高效得多。3.3 从零组装与现成编排框架什么规模选什么框架选型是每个新项目都会纠缠的问题。我给出一个按规模判断的经验任务步骤少于 5 个、工具只有两三个不要用框架手写循环足够任务步骤 5 到 20 个、工具中等规模用轻量编排框架把精力留给工具实现任务步骤几十个、有完整的状态和历史记录需求上重型编排框架或自研调度层我对新项目的默认建议是「先手写一版最小闭环」。这不是情怀而是因为框架会替你做很多决策当你没跑过基线时你分不清问题是出在框架配置上还是自己的 prompt 上。跑通之后再迁移到框架你手里有对照基线迁移质量一目了然。4. 评估 Agent 不能只看「能跑」效率、成本、稳定性三本账要一起算综述里的评估章节是很多人跳着读的部分但它恰恰是和钱最相关的。Agent 和传统软件有一个本质区别同一套代码每次运行的路径都不一样——模型的输出有随机性。这意味着你不能靠「跑通一次」来验收必须有统计意义上的评测方法。4.1 评测指标怎么设才不过拟合成功率、路径效率与鲁棒性Agent 评测的第一层指标是任务完成率。给定 50 个任务让 Agent 各跑 3 遍统计完全成功的比例。关键在于「任务成功」的判断标准要预先定义是输出格式正确就算成功还是要校验输出内容与真实答案一致后者更严格需要你准备标注好的答案集。第二层指标是路径效率。两个 Agent 都完成了任务一个用了 4 轮、8000 token另一个用了 9 轮、23000 token效果有差距吗用户感受到的「聪明程度」很大程度上由后者决定。建议统计两个指标平均轮数超过 10 轮的任务往往不是 Agent 笨是工具设计有问题token 消耗 / 任务这个指标直接对应账单也是后续调优的方向标第三层是鲁棒性。同一个任务跑 5 次结果是否一致我在实际项目里见过成功率 90% 的 Agent但失败的 10% 全部集中在某类格式输入上——这种隐藏的脆弱性只有按类别拆分统计才能发现。组一个评测集时别只按难度分还要按输入类型分短文本、长文本、含特殊字符、超长数字、空值等。4.2 成本控制token 预算、重试上限与并发三个开关Agent 的成本是 Chatbot 的几十倍这是很多人都没有心理准备的事。原因在于 Agent 的每一轮循环都要把整个历史上下文重新发送给模型轮数一多token 消耗成倍放大。成本控制的第一道阀门就是上面代码里的max_rounds第二道阀门是重试策略——模型服务偶发超时或解析失败时重试是必要的但必须设上限。# cost_guard.py # 控制 Agent 调用成本的三个小工具预算、重试、并发限流 import time class CostGuard: def __init__(self, max_tokens_per_task: int, max_retries: int 2): self.max_tokens max_tokens_per_task self.max_retries max_retries def with_retry(self, func, *args, **kwargs): 带重试上限的调用封装超过上限就抛错不无限重试 for attempt in range(self.max_retries 1): try: return func(*args, **kwargs) except Exception as e: if attempt self.max_retries: raise wait 2 ** attempt # 指数退避1s, 2s print(f[retry] attempt{attempt} wait{wait}s err{e}) time.sleep(wait) def check_budget(self, used_tokens: int) - bool: 预算不够就提前终止任务比硬跑完省得多 if used_tokens self.max_tokens: print(f[budget] used{used_tokens} exceed{self.max_tokens}) return False return True这段代码里最有价值的是前两个方法背后的理念与其依赖模型「自己知道该停了」不如在系统层面做硬性约束。重试用指数退避而不是固定间隔是为了在模型服务侧压力大时避免加重拥堵。预算检查不放循环开头而是放在每次调用后是为了允许「至少完成一步再判定」——如果任务只差一步就能完成硬终止确实可惜可以在预算耗尽前给模型一个「简要总结现状」的最后机会。成本控制还有个容易被忽略的杠杆缓存。同样的工具调用入参如果反复出现例如每天查询同一个报表值得做一层结果缓存。但缓存只对纯函数式工具有效对有副作用的工具如发送邮件、创建工单绝对不能缓存否则会出生产事故。4.3 可观测性trace_id、日志回放与链路追踪很多 Agent 项目死在「没法调试」。传统后端可以单步断点调试Agent 的推理过程是黑匣子你只知道它最后给了什么答案不知道它中间为什么选了那条路。所以可观测性要从第一天就做进去不能等上线了再补。最基础的实践是给每次任务分配一个trace_id所有日志带上它。日志里至少记录三件事每一轮的完整消息快照、每个工具调用的入参与出参、每一轮的 token 消耗。这三样东西合在一起你才能复现一次完整的任务执行过程。更进一步的做法是把消息快照存成 JSON Lines 格式配合简单的回放脚本可以在本地把之前的执行路径一步步重放这对定位问题非常有帮助。{trace_id: task_00001, round: 3, event: tool_call, tool: search_docs, args: {query: 退款政策}, tokens: 1250} {trace_id: task_00001, round: 3, event: tool_result, output: 共找到 3 篇相关文档, tokens: 0} {trace_id: task_00001, round: 4, event: model_reply, content: 根据文档退款政策是…, tokens: 483}日志回放脚本的核心很简单读 log 文件、按trace_id分组、按时序打印事件。这不需要专门的链路追踪系统但要有意识地按统一 schema 写日志。一旦日志格式混乱出问题时你会花两三倍的时间在「拼凑现场」上而不是在「修 bug」上。5. Agent 落地避坑从循环失控到上下文污染的五个血泪现场只看架构和代码你会觉得 Agent 离生产只有一步之遥。实际上从「能跑 Demo」到「能上线」中间隔着一串真实的坑。这些坑大多不是模型能力问题而是工程细节问题。每一类坑都有可复现的表现、明确的成因和对应的解法。5.1 Agent 死循环不收敛现象、原因与熔断三件套现象任务日志显示模型在反复调用同一个工具入参只有细微变化甚至完全相同轮数一路上涨到max_rounds也没给出答案。原因有两种一是模型确实在探索尝试想换参数找到解法二是工具返回的结果没有让模型获得新信息它被困在原地。第二种更隐蔽常见于工具返回了空字符串或把异常吞掉只返回「成功」的情况。解决第一件套是熔断机制也就是前面代码里的max_rounds一定不能省第二件套是「无进展终止」记录最近两轮的观察结果如果完全相同直接终止并输出中间结论第三件套是让工具如实返回错误信息工具失败就该返回失败原因不要吞异常。工程师最容易偷懒的就是「工具返回空值」——看似无害实际是决策黑盒后面排查成本极高。5.2 向量记忆召回污染决策现象、原因与双阈值过滤现象Agent 突然在回答里引用了一条和当前任务无关的历史信息或者被一条相似但语义相反的记忆误导。原因向量检索只看语义相似度不看时间、不看来源可信度、不看是否与当前任务域一致。示例用户上一周问过「如何配置公网 IP」这一周在问「内网安全策略」两条内容在向量空间里距离很近旧内容被错误召回并注入上下文。解决至少加两道过滤。第一道是相似度阈值低于阈值的片段直接丢弃第二道是业务规则过滤例如按领域标签、时间窗过滤。还有一道更高阶的做法是在注入前让模型做一次「相关性判断」——但这引入额外成本建议先看前两道过滤的效果再决定要不要上。5.3 工具调用格式频繁解析失败现象、原因与 Schema 收敛现象模型输出的工具调用 JSON 偶尔出现字段名拼写错误、缺失必填参数、参数类型不符解析器直接报错。原因工具函数的 schema 设计不合理比如参数太多、命名含糊、必填项过多模型在生成时出错率就高。特别是snake_case和camelCase混用、枚举值不规范都会增加生成难度。解决工具设计遵循「少参数、短描述、枚举收敛」三原则。每个工具的参数尽量控制在 5 个以内必填参数只留真正不可推导的能从上下文推断的就别让模型传枚举值用allowed_values明确列出。另外一个有用的做法把常见的错误复写到系统 prompt 里作为 negative examples——「不要这样做」的示例往往比「要这样做」更有约束力。5.4 上下文被日志和中间结果塞爆现象、原因与摘要分层现象任务执行到中段模型开始答非所问或者忘记最初的任务要求。打开日志一看消息历史里塞满了大段工具原始输出有的工具把整份 CSV 或整段日志文本都返回来。原因工具输出直接拼进了下一轮上下文没有任何收敛处理。模型面对几千行文本时注意力会被噪音拖垮早期的关键指令被挤出有效注意力范围。解决三层收敛。第一层在工具侧大输出截断默认截断到 500 字符并在返回内容末尾附加「内容过长原始数据可在附件中查看」之类的说明。第二层在模型侧设定每轮注入的 token 预算上限超出的内容由摘要替代。第三层在记忆侧关键信息数字、结论、决策单独写入长期记忆而不是全量留在上下文中。5.5 多智能体互相踢皮球现象、原因与关键节点兜底现象A Agent 说「这个信息需要 B 提供」B Agent 说「这属于 C 的职责」任务卡在中间没有任何一个智能体真正推进。原因多智能体系统里没有明确的任务终局判定机制也没有人负责兜底。每个 Agent 只对自己的子任务负责不管全局状态。解决在设计阶段就要回答三个问题任务最终由谁交付失败时谁负责向上报错有没有一个「关键路径之外」的兜底机制我习惯引入一个调度角色或主持人 Agent它的职责不是干活而是监控进度、判定「是否需要人工介入」。这种调度角色在代码上只多几十行但能避免绝大多数踢皮球场景。更进一步的方案是在关键节点设置超时——超过 2 轮没有实质推进就暂停当前路线并换一个策略。6. 进阶验证把综述里的评估框架变成你自己的回归基线当你手头已经有了能跑的任务闭环和日志下一步是把验证工作制度化。我建议你建一个「固定任务回归集」它不需要很大20 个有代表性的任务即可但要覆盖你的典型业务类型。每次改 prompt、换模型、加工具之前跑一遍回归集并记录三项数据完成率、平均轮数、平均 token 消耗。没有这个基线你所有的改动都是在盲调。一个实用的进阶做法是「双基线对照」。第一份基线用固定 prompt 和固定参数跑出来的历史成绩第二份基线用你当前最新的代码跑出来的成绩。每次调整拿这两份成绩对比一目了然。如果改了 prompt 之后任务完成率掉了 5 个点但轮数少了 3 轮这个 trade-off 是否值得接受需要你来决策——但至少决策有了依据。另一个值得做的验证是「逐渐剥离测试」。当整套 Agent 系统表现不佳时别急着调 prompt先做减法把记忆关掉看看是不是检索污染把工具数量减半看看是不是选择困难把多智能体降级成单 Agent看看是不是协调开销大于收益。这套方法论在综述里对应的是消融实验但在工程语境里它同样好用——它不是学术工具而是帮你定位瓶颈的实用流程。先说一个我自己的教训早期做某跨平台系统的 Agent 时我花了大量时间调 prompt最后发现瓶颈根本在工具返回结果太慢——模型等的不是推理时间而是 HTTP 超时。那一刻我意识到Agent 调试最忌讳的就是「哪里不行调哪里」而要用数据定位。从那以后我的习惯改成先看日志里的耗时分布和 token 分布再决定动哪一层。希望这套方法对你也有用祝你的 Agent 早日从 Demo 走到生产。本文还有配套的精品资源点击获取