简介《Agent AI: Surveying the Horizons of Multimodal Interaction》是李飞飞Li Fei-Fei等参与撰写的人工智能领域前沿综述面向研究者、工程师与学生系统梳理Agent AI这一面向多模态交互与具身智能的研究方向。资源以单个PDF文件形式提供大小约50.96MB内容为完整英文论文原文适合需要深入理解智能代理如何基于大模型在物理与虚拟环境中感知、决策和行动的学习者。该综述提出“Agent AI”概念强调其作为通往通用人工智能AGI的潜在路径并给出了跨现实训练框架通过生成式AI与多源独立数据训练基础模型使其能处理视觉、语言、音频及环境状态等多模态输入并生成有意义的具身动作。预览内容还涉及多智能体系统、人机交互、机器人学等交叉领域并讨论了缓解大模型幻觉等关键问题。目前已有422人浏览学习文件结构精简便于直接阅读和标注。对跟踪多模态AI与智能体研究前沿的读者而言这是一份高价值的一手文献。1. Agent AI 不是又一个聊天机器人李飞飞那篇综述到底在定义什么Agent AI 这个词最近频繁出现在技术圈从开发者大会到团队周会都在聊。李飞飞团队挂名的那篇《Agent AI: Surveying the Horizons of Multimodal Interaction》综述把这个概念从“又一个聊天机器人”拉回到系统工程视角智能体不是模型本身而是模型 工具 记忆 行动循环的组合。它能解决的核心问题是——让大模型从“回答你问题”变成“替你干活”而且是跨模态地干活看得见屏幕截图、听得见语音指令、能操作工具、能调用外部系统。适合谁读正在做 AI Agent 开发、想从 0 到 1 搭建智能体的后端工程师和算法工程师以及需要给团队选型定方向的技术负责人。这篇综述最大的价值不是给了现成代码而是给了你一个判断标准什么算 Agent、什么只是 Chatbot 套壳。2. 拆解 Agent AI 综述的三层内核多模态输入、行动接口与记忆结构2.1 为什么 Agent AI 必须绑定多模态只看文字文本的 agent 不叫 agent李飞飞团队在综述里反复强调一个点Agent AI 的输入端不能只有文本。传统 Chatbot 的工作方式是“用户打字 → 模型生成文字回复”整个过程信息只走了一个文本通道。而 Agent AI 面向的是真实世界环境用户可能丢过来一张截图让你提取里面的表格可能发一段语音让你安排日程可能打开一个软件界面让你帮忙操作这些输入天然就是多模态的。我最早搭建 agent 时犯过一个错误以为把 GPT-4V 或者 Qwen-VL 接上就算多模态了。实际上多模态输入只是第一层真正的 Agent AI 需要把图像、音频、文本统一编码成模型能理解的 token 序列然后让模型在同一套推理框架里决策。综述里给了一个很关键的区分多模态模型Multimodal Model是感知层Agent AI 是在感知层之上叠加了行动层。你让模型“看到”屏幕截图只是第一步让模型根据截图“点击某个按钮”才是 Agent 的行为。很多团队卡在第一步就是因为把感知当成了全部。这里引出一个实际选型问题如果你做的是纯文本客服机器人不需要硬上多模态 Agent如果你的任务是“截图 → 提取信息 → 填进系统”那就必须走 Agent AI 路线。综述给的方法是分两层看待感知层负责把多模态输入转成结构化信息行动层负责决策和执行两层之间用统一的接口连接。我一般会把感知层的输出写成 JSON传给行动层做工具调用这样模型即使换掉接口也不用改。2.2 行动接口是 Agent AI 的灵魂从工具调用到具身动作的抽象层李飞飞团队在综述里定义了 Agent AI 区别于其他 AI 系统的核心能力行动接口Action Interface。这个接口的含义很广可以是调用一个 API、执行一段代码、操作一个软件界面也可以是物理世界里的机械臂动作。关键在于这些行动要被抽象成统一格式让模型能以“选择行动 → 执行行动 → 观察结果”的闭环来工作。实际工程里最常见的行动接口就是工具调用Function Calling / Tool Use。我给你一个建议不要给模型裸奔一个 Python 函数而是给模型一个结构化的工具描述。OpenAI 的 function calling、Anthropic 的 tool use、Ollama 本地模型的 tools 字段底层都是同一套逻辑——模型不是真的执行代码而是输出一个结构化的调用意图由你的程序去执行。我在搭建 agent 时一般把工具描述写成这样的格式工具名、工具功能一句话描述、参数名与类型、参数必填与否、参数说明、返回值格式这个格式看着简单但调参空间很大。描述里写不写“返回值为 JSON 字符串”会直接影响模型对返回结果的解析方式参数名用file_path还是path也会影响模型的选择准确性。综述里提出的抽象层理念落到工程上就是这一套工具协议的设计。更高级的行动接口是“具身”Embodied层面的。综述里举了机器人和 VR 环境的例子模型直接输出关节角度或移动指令这在仿真环境和工业控制里很有前景。国内做工业方向的同行可能会关注“AI Agent 与 PLC 编程”这个方向这本质上也是行动接口的具身化——模型通过结构化指令驱动 PLC 执行程序。这套思路和软件工具调用完全同构只是执行端不同。2.3 综述里的三层记忆结构短期上下文、工作记忆与长期知识库Agent AI 记忆这块综述给了一个比 RAG 更完整的框架工作记忆Working Memory、情景记忆Episodic Memory和语义记忆Semantic Memory。我把它映射到工程上就是三段式上下文窗口、会话状态存储、向量数据库。很多 agent 搭建教程只说“用向量库存历史消息”这太粗糙了。我自己的实践是分成三个独立模块短期上下文模型输入 prompt 里携带的最近 N 轮对话长度为几千 token用来保持当前任务的连贯性。工作记忆一个 JSON 文件或者 Redis 里的结构化状态记录 agent 当前在执行什么任务、已经完成了哪些步骤、哪些工具的结果还没处理。模型每次行动后都更新这个状态。长期知识向量数据库比如 Chroma、FAISS、Milvus存储的历史项目文档、用户偏好、过往错误教训在需要时检索注入。这三个层级的核心区别是生命周期。短期上下文在一次请求里就销毁工作记忆跟随任务存活长期知识跨任务永久保存。问题往往出在人们只做了第一层和第三层忽略了第二层结果 agent 执行一个多步骤任务时干到第三步就忘了第一步的结果只能把上下文不断撑大去硬扛最终 token 爆炸。3. 从 0 到 1 搭建最小 Agent AILangChain Ollama 的骨架工程3.1 环境准备与模型选型为什么先用本地模型跑通搭建 Agent AI 第一步是选模型和框架。如果你在国内环境做开发不打算依赖海外 API又需要可复现的工程基线我建议先用 Ollama 跑本地开源模型把整条链路跑通再根据效果决定要不要上更大规模的模型服务。Ollama 支持 llama3、qwen2.5、glm4 等主流开源模型对工具调用的支持也越来越好是练手的最小成本方案。框架层面LangChain 仍然是生态最全的选择。虽然很多人抱怨它抽象层太多但对于从 0 到 1 搭建 agent 的开发者LangChain 的 AgentExecutor、create_react_agent 这些组件能把最麻烦的 ReAct 循环封装好让你先专注于工具和业务逻辑。Spring AI 也适合 Java 技术栈的团队但如果你只是想快速验证 Agent AI 的核心概念Python LangChain 是效率最高的路径。安装命令很简单但要注意版本兼容性。我遇到过langchain主包和langchain-community版本不匹配导致的导入错误所以建议一次性装齐再测pip install langchain langchain-openai langchain-community ollama chromadb逻辑说明这一条命令装的是四个关键部件——langchain是框架核心langchain-openai是模型调用协议层因为 Ollama 兼容 OpenAI API 格式langchain-community提供了社区维护的工具集成chromadb是做长期记忆用的向量库。参数说明如果你用 Java 技术栈可以把langchain替换成spring-ai的 starter但模型协议部分仍然走 OpenAI 兼容接口。装完执行ollama pull qwen2.5:7b拉取本地模型7B 参数在 16G 内存的机器上跑得动效果在工具调用场景里够用。3.2 核心代码ReAct 循环、工具注册与记忆注入最小 Agent AI 骨架不需要自己写 ReAct 循环LangChain 已经封装好了。但你要理解这个循环的四个环节模型根据当前状态推理 → 输出要调用的工具名和参数 → 你的程序执行工具 → 把结果送回给模型继续推理直到模型认为任务完成。我把这套最小工程写成下面这段可以直接在 Jupyter 或脚本文件里跑# agent_core.py # 最小 Agent AI 骨架用 Ollama 本地模型驱动 ReAct 循环 import json from langchain_openai import ChatOpenAI from langchain.agents import create_react_agent, AgentExecutor from langchain.tools import Tool from langchain_core.prompts import PromptTemplate # 1. 通过 OpenAI 兼容协议连接 Ollama 本地模型 llm ChatOpenAI( base_urlhttp://localhost:11434/v1, # Ollama 的本地服务地址 modelqwen2.5:7b, # 本地模型名用 ollama list 确认 temperature0.2, # 低温度减少随机性保证工具调用稳定 ) # 2. 定义一个最简单的计算器工具 def calculator(expression: str) - str: 计算一个数学表达式的值比如 1 2 * 3 try: return str(eval(expression, {__builtins__: {}}, {})) except Exception as e: return f计算出错: {e} calc_tool Tool( namecalculator, description当需要做数学计算时使用输入一个数学表达式字符串返回计算结果。, funccalculator, ) # 3. 注册工具列表实际项目里可以有多个工具 tools [calc_tool] # 4. ReAct 提示词模板这是模型理解工作方式的唯一通道 prompt PromptTemplate.from_template( 你是一个能调用工具的 AI 助手你的目标是完成任务而不是聊天。 可用工具 {tools} 工具名称列表{tool_names} 任务{input} 思考过程一步一步分析需要工具就调用不需要就直接回答。 执行时按以下格式输出 Action: 工具名称 Action Input: 传给工具的 JSON 格式参数 Observation: 工具返回结果 ... 最终回答当任务完成时给出给用户的最终结果。 {agent_scratchpad} ) # 5. 组装 agent 并赋予记忆能力 agent create_react_agent(llmllm, toolstools, promptprompt) executor AgentExecutor( agentagent, toolstools, verboseTrue, # 打印中间过程方便调试 max_iterations5, # 防止死循环的关键参数见下文 ) # 6. 执行任务 result executor.invoke({input: 帮我算一下 (15 7) * 3 的结果然后告诉我公式。}) print(result[output])参数说明temperature0.2是工具调用场景的推荐值不是越低越好也不是越高越好。太低的温度接近 0会让模型总是选择同一个工具路径缺乏探索超过 0.5 模型可能跳过工具直接瞎回答。max_iterations5是 ReAct 循环的安全阀实际生产里我一般设 8~10但调试阶段从 5 开始避免模型陷入无限循环烧光你的本地资源。逻辑说明代码里最关键的部分是第三步的 Tool 定义。description字段直接决定模型会不会正确调用工具。你把它写成“输入一个数学表达式字符串”比写成“计算工具”要精确得多因为模型是根据描述做匹配的。第五步的提示词模板我做了三个层面的设计告诉模型“目标是完成任务而不是聊天”防止它多话、给出格式要求Action/Action Input/Observation 三段式、注入 agent_scratchpad这是 LangChain 自动填充的历史步骤不需要你手动维护。3.3 把“行动接口”落地成三个真实工具计算器、读写文件和 HTTP 请求一个真正的 Agent AI 最少应该有三个工具计算能力、文件读写能力、外部数据获取能力。这三个覆盖了大多数任务场景。我扩展一下上面的代码做成一个可复用的工具包# tools.py # 三个基础工具的注册模板 import json import urllib.request from pathlib import Path from langchain.tools import Tool def calculator(expression: str) - str: 安全计算表达式只允许数字和四则运算符 allowed set(0123456789-*/(). ) if not all(c in allowed for c in expression): return 错误包含不允许的字符 return str(eval(expression, {__builtins__: {}}, {})) def write_file(file_path: str, content: str) - str: 把内容写入指定文件如果文件不存在则自动创建。参数为JSON格式例如 {file_path: a.txt, content: hello} data json.loads(content) p Path(data[file_path]) p.parent.mkdir(parentsTrue, exist_okTrue) p.write_text(data[content], encodingutf-8) return f文件已写入: {p} def http_get(url: str) - str: 发起HTTP GET请求返回响应体文字。只支持 http/https 协议 try: with urllib.request.urlopen(url, timeout10) as resp: return resp.read().decode(utf-8)[:2000] except Exception as e: return f请求失败: {e} tools [ Tool(namecalculator, funccalculator, description数学计算工具输入一个算术表达式字符串返回数值结果。), Tool(namewrite_file, funcwrite_file, description文件写入工具输入为JSON格式字符串包含file_path和content两个字段。), Tool(namehttp_get, funchttp_get, descriptionHTTP请求工具输入一个URL字符串返回响应内容的前2000个字符。), ]逻辑说明这里三个工具代表了行动接口的三种类型——纯计算无副作用、状态修改写文件、外部交互HTTP 请求。生产环境里你还会加数据库查询、消息推送等但模式是一样的。注意write_file的输入是 JSON 字符串而不是多个参数这是因为模型输出工具参数时只有一个字符串槽位用 JSON 结构可以承载复杂参数。这是我踩坑后养成的习惯复杂工具一律收一个 JSON 字符串参数解析失败时把错误信息返回给模型让它重新构造比多参数传参稳定得多。参数说明http_get返回内容截断到 2000 字符是刻意为之。模型上下文窗口有限一次返回 10 万字符的网页后面所有推理都会变慢甚至让模型找不到重点。我一般限制工具返回体在 2000 字符以内超出时告诉模型“内容过长已截断如需特定部分请用其他工具提取”。这个细节在综述里对应的是“工具结果需要压缩与选择性注入”本质上是行动接口的带宽管理。4. Agent AI 的关键参数配置让智能体从“玩具”变“工具”4.1 模型温度、top_p 与 max_tokens 的协同设法不是随便填的搭建 Agent AI 的早期大多数人的模型参数是从 Chat 场景直接迁过来的这是第一个翻车点。Chat 场景追求多样性和自然语气温度设 0.8 没问题Agent 场景追求稳定执行工具调用温度过高会让模型在“该不该调用工具”之间反复横跳甚至自己编造工具返回值。我一般推荐的组合是temperature0.1~0.3、top_p0.9、max_tokens根据任务复杂度设 2048 或 4096。不要同时把 temperature 和 top_p 都调得很高这是常见的参数设置误区——两者都是控制随机性的叠加使用会让输出变得不可控。OpenAI 官方文档也明确说过建议只调其中一个Agent 场景下我优先锁定 temperature 0.2top_p 保持默认 0.9 不动。max_tokens容易被忽略。如果你只给模型 512 token 的生成上限它可能在 Action Input 写到一半就被截断输出一个残缺的 JSON整个工具调用链路立刻崩掉。实测经验输出包含工具调用参数时至少留 1024 token给模型足够空间把参数写完、把分析逻辑表达完整。本地模型如 qwen2.5:7b 的上下文窗口通常有 32K足够支撑多轮 ReAct 循环但要记得在 Ollama 里通过num_ctx设置否则默认只有 2K 上下文。这个坑太隐蔽了很多人在 LangChain 侧怎么调都不行结果问题出在底层引擎的上下文窗口没开大。4.2 ReAct 循环的迭代上限与停止条件max_iterations 与 early_stoppingReAct 循环最大的风险是死循环。模型调一个工具得到结果不满意再调一次再不满意技术上可以无限循环下去。LangChain 给的参数是max_iterations和early_stopping_method但很多人不理解第二个参数到底干了什么。executor AgentExecutor( agentagent, toolstools, max_iterations8, early_stopping_methodgenerate, # 循环超限时让模型直接生成最终回答 return_intermediate_stepsTrue, # 保存每一轮的工具调用记录供排错用 )参数说明early_stopping_method有两个选项。generate表示循环达到上限时强制让模型基于已有信息生成最终答案none表示直接截断报错。生产环境我建议用generate因为大多数死循环是因为工具返回了模型不理解的结果此时生成一个基于部分信息的回答比抛给用户一个 Exception 要体面得多。return_intermediate_stepsTrue是调试期的救命配置它把每一轮的思考过程和工具返回值都记录下来配合verboseTrue你能完整看到模型是怎么一步步走到死循环里的。还有一类情况是模型认为任务已经完成但它“完成”的标准和你的期待不一致。比如模型调完计算器得到结果按理说应该直接输出答案但它又调用了一次计算器去验证这就是迭代次数白消耗。解决方式是在提示词里写死“计算完成后直接给出最终结果不要重复调用同一工具验证”。不要指望模型自己学会这件事你必须在模板里显式约束。4.3 工具描述是黑盒玄学怎么写工具描述让模型不瞎调这是我花了最久才想明白的参数。模型对工具的认知 100% 来自description字段函数名、参数名都只是辅助。同一个工具描述写得好模型精准调用写得烂模型东试西试最后放弃。我踩过的坑可以总结成三条经验。第一描述里必须说清楚“什么情况下用”和“什么情况下不用”。比如计算器工具的描述写“当需要做数学计算时使用”就比“一个计算工具”强很多因为模型能建立触发条件。第二复杂参数必须给格式示例。我上面写的write_file工具描述里直接附了{file_path: a.txt, content: hello}这个 JSON 示例模型的调用准确率从不到 50% 提到 90% 以上。第三描述要写“不做什么”。HTTP 工具描述里写“只支持 http/https 协议”模型就不会尝试传一个file://路径进去。这些约束不是代码层拦截的是让模型在决策阶段就不往错的方向想。一个更隐蔽的玄学是工具顺序。LangChain 注册工具列表时顺序会影响模型的优先选择。如果 calculator 在 write_file 前面模型在模糊场景下更倾向选 calculator。这个没有理论依据但实测多次都这样。所以工具列表的顺序要按“被调用频率从高到低”排列而不是按功能从简到繁。4.4 记忆窗口大小与向量检索的命中率取舍上下文不是越长越好语境记忆窗口这个参数很多初学者往大了设以为 128K 上下文全塞进去效果一定好。实际这是把“上下文长度”和“有用信息密度”混为一谈了。模型注意力有衰减塞进 90K token 的历史对话真正引导当下决策的信息可能只有其中 3K。工程上我一般这样做分档。短期上下文保留最近 10~20 轮对话用 LangChain 的ConversationBufferWindowMemory控制工作记忆单独存成一个状态字典不走上下文只在关键节点注入长期知识走向量检索每次请求只注入与当前任务最相关的 3~5 条记忆片段。这个设计来自综述里三层记忆结构的启发落地效果比全量塞上下文好很多。向量检索的命中率问题也值得细说。用 Chroma 存历史交互记录时检索结果按相似度排序取 top_k这个 top_k 到底取多少是经验值。取太少相关记忆没被召回取太多无关噪声干扰模型判断。我测试下来的基准是任务明确的工具调用场景 top_k3 最好开放式问答场景 top_k5 比较稳。另外向量检索对中文内容有时候不稳定如果发现检索结果明显不相关可以退回用关键词最相似度BM25或两者加权混合。这套“混合检索”是当前 AI Agent 开发里防止记忆模块翻车的标准做法。5. Agent AI 搭建避坑五个高频翻车现场与排查路径5.1 工具返回的是 JSON 字符串模型却当成 Python 对象去解析现象ReAct 循环运行到第二轮直接报TypeError: str object is not subscriptable日志显示模型试图用result[status]访问一个字符串的下标。原因工具返回给模型的是 JSON 字符串但模型在下一轮推理时产生幻觉认为自己拿到的是已解析的对象。更本质的原因是工具返回值里没有提示“这是一个字符串请先解析”。模型不知道程序端做了序列化它只看到{status: ok}和{status: ok}在文本层长得差不多。解决在工具返回值的开头加一个明确前缀。比如RETURN_JSON: {status: ok}并且在提示词里写死“工具返回RETURN_JSON:前缀后的内容才是可解析的 JSON”。这个前缀是给模型看的信标比在代码里 try/except 解析更有效。代码层面也要兜底用json.loads时捕获异常把原始字符串返回给模型让它自己再读一遍。5.2 模型陷入“思考-调用-报错”死循环日志刷几百行现象max_iterations设了 8模型在 3 轮内就用完了。日志显示模型反复调用同一个工具得到错误后再换一个说法继续调永远不给最终回答。原因工具返回的错误信息不够具体模型不知道下一步该怎么修正。比如 HTTP 工具返回请求失败模型完全不知道是超时、DNS 解析失败还是 404无法做出有效调整。另一个常见原因是工具的输入格式太严格模型已经尽力构造了还是差一点对不上。解决把错误信息写得足够详细让模型有资料可以推理。HTTP 工具失败时返回请求失败: [错误类型] [错误详情] [建议检查 URL 是否完整]。同时在工具入口做一次归一化处理帮模型把常见的参数格式错误修正后重试一次。比如文件路径缺/就自动补上JSON 参数里用了单引号就尝试替换成双引号再解析。这两招合起来死循环率能下降 70% 以上。5.3 本地模型不按格式输出Action 字段乱写现象使用 qwen2.5:7b 或类似的开源本地模型时模型输出经常是自然语言而不是规定的Action:/Action Input:格式。模型说“好的我来调用计算器”但就是不输出结构化的调用指令。原因中小规模开源模型的指令遵循能力弱尤其 ReAct 格式是英文结构模型对中文提示词里的英文格式指令理解不够。这是模型能力瓶颈不是你的代码问题。我对比过同一套提示词qwen2.5:7b 的格式遵循率约 70%而 14B 或 32B 参数版本能到 90% 以上。解决三管齐下。一是升级模型至少用 qwen2.5:14b 或更高的版本跑 Agent 任务二是在提示词里加一个少样本示例给出完整的 Action/Action Input/Observation 样例比单纯描述格式有效得多三是代码层面做鲁棒解析用正则匹配从模型输出里提取可能的 Action 段即使模型混着自然语言写也能兜住。这三层缺一不可我见过有人在提示词上磨半天最后发现换个大模型全解决了。5.4 上下文越滚越长早轮的工具结果被截断导致“失忆”现象多步骤任务执行到第 6 步时模型突然要求重新提供第 1 步计算出来的数值明明那个结果就在历史上下文里。更糟的是长任务后半段的工具调用开始出现重复调用或自相矛盾。原因本地模型的实际上下文窗口远小于模板宣称的数值。Ollama 默认num_ctx只有 2048qwen2.5:7b 虽然支持 32K但你不设置就是 2K。LangChain 侧把完整对话历史放入 prompt一旦超过 2K早期内容被静默截断模型自然“失忆”。解决启动 Ollama 时显式修改num_ctx。ollama run qwen2.5:7b --num-ctx 16384或者在代码里通过模型参数传入。同时把工作记忆模块真正用起来每个工具执行后把核心结果写入一个状态字典下一轮 prompt 只注入最终状态不注入完整的工具原始输出。这样即使历史被截断关键数据也不会丢。这是 Agent 工程和 Chat 工程最本质的区别Agent 必须维护自己的状态不能依赖对话历史的完整性。5.5 工具并发调用顺序错乱先写文件再读文件反而读到旧内容现象让 Agent “把数据写入 config.json然后读出来确认”结果是先执行的读操作读到了旧文件后执行的写操作才落盘。verboseTrue打印的执行顺序和代码逻辑明显不符。原因LangChain 的 AgentExecutor 在某些实现里会并行执行无依赖关系的工具调用或者工具函数内部有异步逻辑没有正确 await。模型输出的指令顺序不代表程序执行顺序两者之间缺少依赖约束。解决给有依赖关系的工具调用建立显式状态锁。我的做法是在工作记忆里维护一个“依赖标记”当写文件工具执行后标记config.json: written读文件工具启动时先查这个标记没读到标记就等待或重试。更实用的方案是把这种“写后读”合并成一个复合工具程序层保证顺序不让模型参与跨工具依赖管理。模型负责意图程序负责顺序这是 Agent 工程的一个基本原则。6. 用“最小可验收任务”验证 Agent AI三个进阶测试与评估清单6.1 任务一跨工具编排测试给 Agent 一个需要连续使用多个工具才能完成的任务比如“访问指定的 URL 获取 JSON 数据提取其中数值字段计算平均值后写入 result.txt”。这个任务恰好覆盖 HTTP 获取、计算、文件写入三种工具能验证工具的编排能力。我一般看三个点。第一是 Agent 是否按合理顺序调用工具而非随机打乱第二是遇到中间结果不符合预期时能否自我修正第三是最终文件内容是否与手动计算一致。这个任务跑通意味着你的 Agent AI 具备最基本的“干活”能力。6.2 任务二错误恢复测试故意让某个工具先失败一次比如让 HTTP 工具请求一个不存在的域名看 Agent 如何处理。合格的表现是Agent 识别到失败检查错误信息更换策略比如换一个备用地址或者明确告知用户任务无法完成——而不是反复重试同一操作直到耗尽迭代上限。错误恢复能力是 Agent AI 和脚本的分水岭。脚本遇到错误只会抛异常Agent 应该能基于错误信息推理出下一步该做什么。这个测试没有标准答案但你要在日志里能看到模型的重新规划轨迹而不是同一个 tool call 重复 N 遍。6.3 任务三长会话记忆测试连续给 Agent 派发三个独立的小任务中间穿插一些不相关对话然后问它“最早那个任务的输出数据是什么”。正确做法是从工作记忆或长期记忆里把数据取出来而不是凭空说“我记不清了”。这个测试暴露的是记忆模块的真实效果我整理了一份可以直接复用的评估清单测试项通过标准失败排查方向工具选择准确率10 次任务中 8 次选对工具检查工具描述是否明确、是否有少样本示例工具参数构造正确率10 次任务中 9 次无需人工修正简化参数结构、描述里附 JSON 示例ReAct 循环收敛率所有任务在 max_iterations 内结束检查错误信息是否具体、模型是否太小记忆回取准确率跨任务信息 5 次中 4 次正确回取检查向量检索 top_k 与混合检索策略错误恢复成功率人为故障后 Agent 能更换策略继续给工具返回更详细的错误上下文这套清单我每次给新项目做基线评估都会跑一遍成本不高但能暴露 80% 的工程问题。把量化指标定出来你才能真正判断一篇综述里的理念有没有在自己的工程里落地。最后说个我的习惯我搭 Agent AI 的头两周不急着加复杂工具、不优化 prompt 花哨程度只把上面三个测试任务反复跑。每次改一个参数跑一遍清单记录数值变化。这个笨办法帮我避开了很多后面才爆的雷——尤其是工具描述和上下文窗口这两个黑匣子不通过测试你是感觉不到它们在暗中拖后腿的。Agent AI 这个东西框架代码半天就能写完真正值钱的是你摸清了自己这套模型、工具和记忆结构之间的脾气。希望这份拆解和踩坑记录能帮你少走一段弯路。本文还有配套的精品资源点击获取