简介李飞飞等人合著的 Agent AI 综述中文翻译稿面向关注大模型、多模态与具身智能的 AI 研究者和工程师为快速理解智能体如何走向通用人工智能AGI提供一份全景式参考。PDF 共 1 个文件、30.93MB已有 2176 人学习。内容系统梳理了 Agent AI 的核心定义与体系架构围绕 LLM、VLM 等大型基础模型如何赋予智能体感知与行动能力展开重点分析了游戏 NPC、机器人多模态操作、医疗辅助诊断等典型场景并讨论了数据隐私保护、模型偏见、决策可解释性以及跨领域融合等关键挑战也展望了虚拟现实与模拟场景中的智能体交互前景。借助这份中文归纳读者无需逐页啃读英文原版论文即可把握 Agent AI 在具身智能与多模态交互方面的发展脉络建立完整知识框架同时了解通往 AGI 路径上的技术瓶颈、伦理议题和未来趋势尤其适合作为该方向的快速入门与论文导读材料。1. Agent AI 是什么从「聊得好」到「做得到」一个对话框里的应用答得再流畅也只是把文字还给你而一份题为 Agent AI 的综述讨论的是让多模态交互真正「做事」——看图像、听语音、操作界面、挪动物体、在环境反馈里修正自己。这两年很多人把大模型接上几个 API 就叫 Agent但把这份综述读进去之后你会发现多模态 Agent 的门槛不在「接口多」而在「闭环稳」模型说它已经把红色杯子放好了你怎么确认它真的放了、放对了这个确认动作才是工程难点。这篇笔记把综述里的框架拆成工程语言感知层选型、行动空间设计、记忆与规划机制、以及最容易翻车的评估环节。适合两类人想从聊天应用往「能操作环境」方向升级的开发者以及已经在做仿真或具身项目、想找到自己系统短板在哪的工程师。下面按「原理 → 最小实现 → 参数 → 踩坑 → 验证」推进案例来自我自己的模拟项目经验不依赖特定厂商的封闭方案。2. 多模态交互的底层逻辑感知、理解与行动的三角关系2.1 感知层视觉编码不是「看一眼」而是「看得准、量得对」感知层是 Agent AI 区别于纯文本 Agent 的第一道门槛。文本输入是已经符号化的信息模型只需要理解语义而图像、视频、深度图这些数据需要先被转成结构化的「场景描述」决策层才有东西可用。综述里把感知能力分成两个层次识别这是什么和定位它在哪、多大、和周围物体什么关系。只做识别不做定位Agent 就会出现「知道桌上有杯子但伸手抓了个空」的尴尬。工程上常见的感知方案有三类各有适用边界方案典型输出优点短板适用场景端到端多模态底座自然语言描述、常识问答语义强、少标注空间定位弱、输出不可控场景理解、任务规划检测模型 属性分类目标框、类别、颜色等属性定位准、成本低语义弱、需预定义类别表抓取、UI 操作、巡检深度/点云 语义融合3D 位置、位姿、物体关系可直接驱动机器人数据难标、算力高机械臂、移动机器人我一般会优先选第二类做「执行前置」再用第一类做「全局理解」检测模型负责告诉决策层哪里有杯子多模态底座负责理解「把红色杯子放到蓝色盘子旁边」这句话在地图上的语义。两者输出合并后决策层的输入既有稳定的坐标又有丰富的语义而不是让一个模型同时干两件容易打架的事。感知层有三个参数决定了下游决策质量值得单独调。第一个是输入分辨率不是越高越好我实测过把整张高分辨率图像直接喂给多模态底座推理慢不说小物体反而因为缩放而丢掉细节常见做法是先检测出物体区域再把区域裁剪放大后送去做属性识别这一步通常能让颜色、文字等属性的识别准确率提升好几个点。第二个是关键帧采样策略主要影响视频输入固定间隔采样在动作快的场景会漏关键状态改成「状态变化触发采样」更稳。第三个是兴趣区域ROI裁剪范围范围太大噪声多太小漏目标我习惯用检测框外扩 20% 作为 ROI。2.2 理解与决策层大模型在 Agent 里到底是大脑还是嘴多模态底座把场景翻译成语言和坐标之后真正的决策发生在理解层。这里先要破除一个误区大模型在 Agent 里不只是「说话的人」。它的输出要通过约束被解析成结构化的动作指令所以「它怎么想」直接决定「它怎么做」。实践中有两条决策路线区别在于要不要让模型先暴露推理过程。第一条是直接输出动作single-shot模型根据当前场景和用户意图一次性输出一个动作和参数。优点是延迟低、链路简单缺点是复杂任务里容易漏中间步骤。第二条是先推理后规划plan-then-execute模型先输出对任务的理解、子目标列表再逐个生成动作。综述里反复强调的思维链在这个场景的真正价值不是「变聪明」而是给了工程人员一个可观测的中间产物——任务失败时你能看清是「理解错了」还是「执行错了」。无论走哪条路线动作空间都要先定义清楚。我在项目里会把动作定义成固定的结构包含动作名、必填参数、可选参数、前置条件四部分然后用系统提示词把这份动作表塞给模型要求输出严格按表来。这么做有两个好处一是模型的输出可以直接过参数校验非法动作在执行前就被拦下二是后续如果要接强化学习或模仿学习这份动作表就是现成的动作空间描述。决策层值得先调的参数有三个temperature 一般调到 0.2 以下减少随机抖动top_p 配合 temperature 一起收避免模型在动作选择上「发散」还有输出约束的严格程度是否强制结构化输出、是否开启格式校验。如果模型频繁输出非法动作先别急着换模型把正确示例写进提示词往往更有效——少写「不许输出 X」多写「正确的输出长这样」。2.3 行动与反馈闭环是 Agent 和聊天机器人的分水岭感知和理解做得再好没有行动与反馈闭环就还是一个会说话的识别系统。综述里把 Agent 定义的核心落在「交互」二字Agent 的动作会改变环境环境的反馈又回到 Agent形成下一轮决策的依据。这也是为什么评测一个 Agent 不能只看它说的话要看它改动的状态。执行动作的方式决定了反馈信号的类型。我用一张表总结四类常见的执行与反馈组合执行体动作示例返回的反馈反馈质量代码/API 调用操作数据库、发送请求返回码、报错信息高结构化UI 自动化点击、输入、滚动截图、控件树中需解析仿真环境物体抓取、导航状态向量、图像、是否碰撞高可量化实体机器人机械臂移动、底盘运动传感器读数、是否超时低噪声大反馈质量直接决定 Agent 自我纠错的能力。文本友好的场景模型看一眼报错信息就知道怎么改但视觉主导的场景比如机械臂抓取失败光有文字反馈「failed」是不够的模型得能看到物体是不是被撞偏了。所以我的习惯是无论执行体是什么执行后都强制做一次「再感知」把执行前后的状态对比写进上下文而不是让模型自己脑补。这一步相当于给 Agent 装了后悔药发现状态没变或变错了可以重新规划而不是顺着幻觉继续往下走。3. 把综述读成工程一个最小 Agent AI 系统的搭建路线3.1 先定义行动空间再谈「智能」如果只能从这份综述里带走一个原则我会选这个先定义环境允许的动作集合再让模型在这个集合里做决策。很多翻车现场根源不是模型不够聪明而是动作空间没收敛——模型输出了一百种动作环境只支持十种剩下的全靠重试兜底。行动空间定义的产出是一张动作清单表每一行代表环境真正支持的一个原子动作。以我在模拟项目里做的桌面整理任务为例动作表长这样动作必填参数可选参数成功判定备注pick物体ID抓取点、姿态物体被拿起且未掉落执行后重新检测物体位置place目标区域ID摆放姿态物体落到位且稳定区域 ID 来自感知层输出move_to目标坐标避障路径底盘到达目标范围坐标使用全局坐标系confirm任务ID—返回确认信息不改变环境用于反问定义动作表时有三个细节容易被忽略。第一每个动作必须配「成功判定」标准它直接决定反馈信号怎么写没有判定的动作等于没有反馈。第二参数要定义成感知层能填的格式比如「物体ID」必须是前一帧检测结果里真实存在的 ID不能是模型瞎编的名字。第三预留一个 confirm确认动作让 Agent 在不确定时可以反问用户这个动作能把错误率降一个量级。动作表定好后把它以结构化的形式写进系统提示词。我在第 2 章提过提示词里的动作说明要「给正例」比如合法的动作是 pick 物体ID 抓取点。示例写多了模型的输出格式错误会明显减少。这一步花半小时能省下后面无数轮的解析重试。3.2 搭「感知 → 决策 → 行动 → 校验」的最小回路行动空间定义好就可以搭最小系统了。我通常用不到两百行的代码把闭环串起来核心是下面这个主循环。注意这里用伪代码风格感知和执行器都做了抽象接入你自己的环境时只需要替换三个函数体。import json def perceive(obs): 感知: 把环境观测转成结构化场景, 返回物体列表 # 常见做法: 检测模型出框 - 多模态底座补属性 - 合并输出 # 返回格式建议: [{id: obj_01, type: cup, color: red, # bbox: [x1, y1, x2, y2], pose: [...]}, ...] def decide(task, scene, memory): 决策: 让模型基于当前场景生成一个合法动作 # 常见做法: 拼 prompt - 模型输出 - 按动作表 schema 解析 # 返回格式: {action: pick, params: {object_id: obj_01}} def execute(action, env): 行动: 把动作交给执行体, 返回反馈 # 模拟器 / 代码执行器 / UI 驱动接口选一 def validate(action, schema): 校验: 白名单 参数合法性检查 # 检查动作名是否在表里、参数是否齐全、ID 是否存在于当前场景 scene perceive(env.reset()) for step in range(max_steps): action decide(task, scene, memory) if not validate(action, ACTION_SCHEMA): memory.append(非法动作, 已拦截) continue feedback execute(action, env) scene_new perceive(env.observe()) # 执行后必须重新感知 ok check_change(scene, scene_new, task) # 状态差分校验 memory.append(f{step}: {action[name]} - {ok}) if ok: break scene scene_new这段代码的核心不是循环而是三个容易被新手跳过的函数。validate 在模型输出进环境之前做拦截拦截成本几乎为零而让环境去执行非法参数的代价可能是一次崩溃或一次误操作。check_change 比较执行前后的场景判断状态是否真的变了、是否朝目标方向变化——这是防止模型幻觉的最后一层保险模型嘴上说成功不算数环境状态说了才算。scene_new 强制我们在每次动作后刷新感知而不是复用旧帧否则视觉反馈的时效性就没了。主循环里最值得调的参数是 max_steps。给太小复杂任务跑不完给太大Agent 容易在错误路径上空转十几步。我一般先用任务拆解出的子目标数量乘以 3 做初值再根据实际成功率微调。另一个习惯是给每个动作记录执行耗时超时的动作直接判定失败并触发再规划这比干等反馈要实用得多。提示max_steps 不是越大越好。它只是兜底死循环真正控制效率的是再规划触发条件见第 4 章。3.3 给闭环加一层「状态校验器」主循环跑通之后下一个投入点是把「状态校验」从一层薄薄的函数变成独立模块。原因很简单感知有噪声、执行有误差、模型有幻觉三者叠加后靠「肉眼对比前后两张图」的校验方式很快会失效。状态校验器要做三件事格式校验、一致性校验、目标达成度校验。格式校验检查动作参数是否合法物体 ID 是否存在、坐标是否越界、区域是否可达它挡掉的是执行前的低级错误。一致性校验检查执行后的场景是否「说得通」物体列表里出现了执行前不存在的 ID或者两个物体的位置重叠说明感知或执行大概率出了问题要停下来重做。目标达成度校验是最后一环它把用户意图转成可计算的判定条件例如「红色杯子与蓝色杯子位置互换」转成「两个物体的中心坐标互换且误差小于阈值」。这一步做好Agent 的「成功」就不是模型自述而是可审计的状态结果。4. 记忆、规划与工具调用三个决定上限的机制4.1 记忆上下文窗口装不下完整人生任何一份谈 Agent 的综述都会把记忆单独拎出来原因是它决定了 Agent 能不能从「每次从零开始」进化为「越用越懂环境」。我的切身体会记忆不是堆 token而是分层。不分层的后果很直接——任务跑到第 20 步单次决策延迟翻几倍token 消耗让人肉疼。第一层是短期记忆指最近几轮的感知结果、动作和反馈直接放上下文。这里要做「瘦身」而不是全留感知层输出的物体列表可能很长和当前任务无关的物体只留 ID不进上下文。第二层是工作记忆指当前任务的中间状态——已经完成的子目标、剩余步骤、当前物体位置。这一层建议用结构化记录而不是自然语言因为它要支持出问题时的状态复原。第三层是长期记忆横跨多次会话常见做法是向量化存储加摘要任务开始前用检索把相关经验拉回上下文。记忆层级存什么放哪生命周期短期记忆最近几轮感知、动作、反馈的精简版主上下文每轮更新工作记忆子目标进度、当前状态、剩余步骤独立结构化对象任务结束清空长期记忆带摘要的历史经验、任务场景标签向量库 标签索引跨任务持久长期记忆有两个参数最影响效果。一个是检索数量 top_k太小相关经验漏掉太大噪声挤占上下文。我习惯先设 3 到 5观察 Agent 是否重复踩同一个坑再调整。另一个是相似度阈值阈值太严检索为空太松则把无关经历当成经验用。另外长期记忆里必须带时间戳和任务场景标签否则检索到的经验可能来自一个完全不同的任务类型反而误导决策。这些经验我会定期人工复核别让错误的旧经验在向量库里「长住」。4.2 规划把大任务拆成可执行的小步规划层解决的是「任务太长、一次决策做不完」的问题。直接把整个任务塞给模型让它一口气输出全部动作序列在步骤少于五步的简单任务里可行一旦任务超过十步一次生成的计划几乎必然在某一步出错而且错了之后整个序列作废。更稳的做法是分层规划上层模型只生成子目标列表下层模型针对当前子目标生成具体动作每完成一个子目标回到上层重新同步进度。实践中我用三种规划模式对应不同任务复杂度模式做法适用任务主要风险单步决策每步选一个动作走一步看一步子目标少于 5 个、反馈快缺乏全局视野推理-动作循环推理 → 动作 → 观察 → 再推理反馈可读、需中途修正token 消耗大分层规划上层拆子目标下层执行动作长任务、多目标层间信息丢失不管用哪种模式都必须定义「再规划触发条件」。我的经验是三个信号之一出现就重新规划执行超时某动作超过预估耗时的三倍、状态停滞连续两次动作后场景无变化、以及校验失败动作执行了但离目标更远。很多 Agent 死在「一条道走到黑」就是缺了再规划这个闸门。闸门逻辑放在主循环里每步检查一次开销极低收益却很大。4.3 工具调用多模态输入如何变成结构化参数工具调用是 Agent AI 落地的最后一公里模型决定要「移动物体」但它得说清楚移动哪个、移到哪里参数才能驱动执行体。这里最常见的坑是坐标系的语义错位——感知层输出的是图像像素坐标执行层要的是环境全局坐标模型如果没有被告知坐标系定义会在两个坐标系之间「编」出一个值看着合理实际无效。我的处理方式分四步。第一步在系统提示词里写明每个动作参数的来源和坐标系注明「位置参数只能来自感知层输出的物体位置禁止自行估算」。第二步要求模型输出时引用感知层给出的物体 ID而不是重新描述物体「那个红色的杯子」要映射成 obj_03。第三步输出后做格式校验坐标越界、ID 不存在等直接重试重试次数设上限我一般设三次。第四步对失败的工具调用做归因记录是参数格式错、坐标系错还是模型根本没理解工具用途。这一步的数据积累多了你会比任何公开指标都清楚自己系统的短板在哪。注意物体 ID 必须来自感知层输出禁止模型自行编造。ID 校验通过了才算有效参数否则整个动作视为非法。5. 多模态 Agent 排查指南五个我踩过的坑5.1 现象一模型说「完成」了环境里什么都没发生现象Agent 返回「任务完成」但检查环境状态发现物体根本没动或者只执行了第一步就声称全部完成。视觉主导的任务里特别常见因为模型只能「看到」初始帧后续步骤全是脑补。原因上下文里缺少执行后的状态反馈模型用推理补全了「应该发生」的结果而不是「实际发生」的结果任务的成败只用单次决策判断没有分步校验。解决执行后强制重新感知把执行前后状态对比作为成功判定的唯一依据。我在第 3 章说的 check_change 就是为了治这个病。再补一招在系统提示词里显式声明「你没有执行能力只能基于反馈判断结果」断了模型「觉得自己做了」的念想。5.2 现象二换个角度就认不出目标现象同一个物体正面能识别侧面或光线暗一点就漏检桌面整理任务里杯子换个位置就找不到了。原因感知层用了单视角端到端识别缺乏多视角信息训练数据里正视角占比过高模型没学会视角不变性。解决把感知改成「检测 ROI 再识别」两段式先检测候选框再对候选框做多角度裁剪识别有条件就采集多视角数据做增量训练。对固定场景如桌面、工位还可以加一个「场景基准图」机制任务开始前记录初始状态之后每次感知与基准图做差分物体新出现、消失或移动都会被捕捉这比每次都全量识别稳得多。5.3 现象三规划器进入死循环现象Agent 反复执行同一个动作比如不停地 pick 物体但每次校验都失败然后继续 pick直到撞上最大步数上限。原因反馈信号区分度不够模型无法判断「为什么失败」于是采取最保守的重试策略或者校验函数没把「状态没变」判定为失败。解决给循环检测单独加逻辑。用一个哈希记录最近 N 步的动作和场景状态摘要发现重复就强制切换成「重新感知 → 换动作」模式。同时把「连续两次动作后场景无变化」加入再规划触发条件。有个细节不要把「动作相同」直接判定死循环要结合状态哈希——如果环境状态在变重复动作可能是合理的渐近逼近。5.4 现象四上下文越跑越大延迟线性飙升现象任务跑到第 20 步单次决策从 2 秒涨到 8 秒token 消耗读数让人肉疼。短任务没感觉长任务尤其明显。原因每步的感知结果、动作、反馈全量追加到上下文没有任何压缩窗口再大也扛不住几十轮多模态输入。解决分层记忆加摘要压缩。感知层输出只保留与当前任务相关的物体条目每完成一个子目标把该子目标的轨迹压缩成三行摘要移出主上下文历史细节进向量库只在需要时检索。调优经验是主上下文里始终放「当前场景精简版 当前子目标 最近三步轨迹」其余全部外置。5.5 现象五指标好看现场翻车现象离线评测成功率很好看一换没见过的初始布局立刻掉一大截。模拟环境的随机种子一直没换过模型把「背答案」当成了「会做」。原因评测集的初始状态分布太窄模型和感知器都过拟合到了固定布局评测时用了与训练时相同的随机种子环境根本没有多样性。解决建立多元化评测集至少覆盖多种初始布局、多种光照、多种干扰物配置。每次评测随机打乱布局固定随机种子只能用于回归复现不能用于最终验收。另一位同事 A同学 的做法更彻底评测脚本和开发脚本分开维护评测前谁都不能看布局生成方式避免无意识的对答案。6. 从跑通到可信评估方法与两个进阶技巧6.1 建一个属于自己的回归测试集公开指标是别人的回归测试集必须是你自己的。我维护了一份几十个任务的测试清单每个任务定义了初始布局、动作空间、成功判定标准。每次改模型或提示词我都会用这份清单跑一遍记录三个指标任务成功率、平均步数、非法动作率。成功率衡量「做不做得到」平均步数衡量「效率」非法动作率衡量「输出纪律」。这三个指标一个都不能少——很多系统成功率很高但平均步数离谱说明是靠瞎试撞出来的。回归测试集不需要大但要稳。每次跑完把失败的案例截图存档下次改完提示词先看这些旧失败案例过没过再去看新指标的涨跌。这个习惯能帮你区分「真的变强了」和「换了一批题变简单了」。6.2 技巧一给 Agent 装一个「后悔药」——动作级回滚多模态 Agent 一旦接上真实执行体最贵的成本就是错误动作的后果。给 Agent 一个可撤回的动作接口是我做过性价比最高的投资。做法是在执行层给动作分两类可逆动作如移动、排列和不可逆动作如删除、发送。可逆动作在执行前记录环境快照失败或校验不通过时调用回滚恢复不可逆动作则强制走确认流程让用户点头后再执行。这个设计同时服务两个目的安全兜底和排查效率。跑仿真时我把快照频率调高几乎每一轮都留恢复点复盘失败路径时能精确回到出错的那一步而不是从头再来。回滚接口的代价是额外存储但对 Debug 的加速是几倍的。6.3 技巧二用「状态差分」代替模型自述最后一个我想强调的习惯也是我做多模态 Agent 项目最重要的一条纪律永远不要用模型的自述判断成败要用环境状态的前后差分来判断。这听起来像常识但赶进度时最容易破例——「我看一眼输出感觉它应该成功了吧」。破例的后果往往是下游任务顺着错误状态继续跑错误被放大十倍最后排查半天才发现根子在五步之前。我现在会在每个动作的校验函数里断言三条状态变了、朝目标方向变、变化幅度合理。三条同时满足才算成功任何一条不满足都走再规划而不是继续。这个习惯帮我拦下过无数次「看起来成功、实际翻车」的案例也让我对自己系统能力边界的判断准确了很多。希望这个状态差分的习惯也能帮你在自己的 Agent 项目里少踩几个坑。本文还有配套的精品资源点击获取
区域求和原理与工程实践)
