短期记忆、Session State、长期记忆、RAG不是几个时髦名词。它们本质上都在解决一个问题Agent 执行任务时怎么知道自己在做什么、做到了哪一步、哪些信息还能用。但只会设计记忆还不够。因为你设计完以后还要回答一个更现实的问题这个 Agent 到底好不好用很多录友做 Agent 项目最容易犯的错就是“我试了几个问题感觉还可以。”这不叫评估。这叫碰运气。Agent 和普通问答不一样。普通问答可以主要看最终答案对不对。Agent 不行。因为 Agent 中间会规划、会调用工具、会读工具结果、会改策略、会做多步动作。它最后答对了也可能是中间乱调用工具碰巧答对。它最后答错了也可能是工具返回失败、权限不足、缺少关键输入不一定全是模型问题。所以先记住一句话Agent 评估不能只看最终答案要看整个执行过程。这篇我们就把 Agent 怎么评估讲清楚。Agent评估需要同时查看最终答案、执行轨迹和安全边界一、为什么 Agent 评估比普通问答难普通大模型问答的评估通常是这样用户问一个问题。模型给一个答案。然后看答案是否正确、是否完整、是否符合格式。但 Agent 多了很多中间环节。比如用户说“帮我分析这个仓库为什么启动慢并给优化建议。”Agent 可能要读取项目目录。找启动入口。查看配置文件。搜索初始化逻辑。查慢日志。总结可能原因。给出优化优先级。这里面每一步都可能出问题。它可能目录读错。它可能搜错关键词。它可能把测试配置当成生产配置。它可能工具失败后继续硬编。它可能只看了一个模块就开始总结全局问题。所以 Agent 评估至少要回答四个问题第一最终任务完成了吗也就是用户目标有没有达成。第二中间过程靠谱吗有没有乱调用工具、重复调用、越权调用、忽略失败。第三成本和效率怎么样同样的任务是 5 步完成还是绕了 30 步。第四失败时能不能收住缺参数、工具超时、权限不足时是追问和停止还是继续瞎猜。这就是为什么 Agent 评估不能只看“答案像不像”。要看结果也要看轨迹。二、Agent 评估的第一指标任务完成率任务完成率是 Agent 评估里最核心的指标。简单说就是用户交给 Agent 的任务它到底完成了多少。比如 100 个测试任务里70 个完整完成15 个部分完成10 个失败但正确说明原因5 个失败还编结果那不能简单说成功率是 70%。因为“失败但正确说明原因”和“失败还编结果”差别很大。一个靠谱的 Agent不是每次都必须成功。现实里很多任务本来就无法继续用户没给订单号当前账号没有权限工具超时数据不存在业务规则不允许文档本身缺失这时 Agent 正确的表现不是硬做。而是识别无法完成的原因并给出下一步动作。所以任务完成率最好拆成几档。1. 完整完成用户目标被完整满足。比如用户让 Agent 查接口变慢原因。Agent 找到证据链P95 从 300ms 升到 3.8s变慢时间点是 22:1022:05 发布了新版本新版本增加了第三方回调重试日志显示回调超时激增最后给出结论和修复建议。这叫完整完成。2. 部分完成Agent 完成了一部分目标但还有明确缺口。比如它找到了慢接口和发布时间但没有拿到第三方回调日志。如果它明确说“目前证据只能支持发布后接口变慢但还缺少第三方回调日志不能直接下最终结论。”这比强行总结要好。部分完成不是坏事。坏的是明明只完成了一部分却装成全部完成。3. 正确失败任务没完成但失败处理是正确的。比如用户问“帮我查一下订单为什么没发货。”但用户没提供订单号。Agent 不能编。它应该追问“请提供订单号我才能继续查询发货状态。”这叫正确失败。很多生产系统里正确失败非常重要。因为它不会制造错误结果。4. 错误失败任务没完成还给了错误结论。比如没查到订单却说“订单正在仓库处理中。”这种最危险。因为用户以为 Agent 查到了。但其实它是编的。所以任务完成率不能只统计“有没有输出答案”。要统计完整完成率部分完成率正确失败率错误失败率Agent任务结果按完整完成、部分完成、正确失败和错误失败分级面试里如果你只说“我们用准确率评估 Agent。”太浅了。你要说“我们会按任务结果分级完整完成、部分完成、正确失败、错误失败。Agent 不是每个任务都必须成功但失败时必须能识别原因不能编造结果。”这就像真的做过。三、只看完成率还不够还要看步骤效率Agent 能完成任务不代表它做得好。还要看它用了多少步。同样一个任务“查订单为什么没发货。”Agent A发现缺少订单号。追问用户。两步结束。Agent B查订单详情缺订单号。查用户最近订单缺手机号。查手机号缺登录态。又查订单详情。又查最近订单。最后才追问订单号。两个 Agent 最后都可能追问用户。但 Agent A 明显更好。因为它没有浪费工具调用也没有绕圈。这就叫步骤效率。步骤效率可以看几个指标。1. 平均步数一个任务平均需要多少次模型决策或工具调用。步数不是越少越好。太少可能说明没认真查。但步数长期偏高通常说明 Agent 在绕路。2. 无效工具调用率哪些工具调用没有推进任务。比如缺参数还调用同样参数重复失败查了无关数据调了不适合当前任务的工具这些都应该统计。3. 重复调用率同一个工具、同一组关键参数、同一个错误原因反复调用。这通常说明 Agent 缺少失败记忆。前面 Agent 为什么容易翻车 里讲死循环本质就是这个。4. 关键路径长度完成任务真正需要的核心步骤有多少。比如排查接口变慢关键路径可能是监控 → 发布记录 → 错误日志 → 结论。如果 Agent 中间绕到数据库、缓存、无关服务查了一圈那就是路径效率差。Agent步骤效率通过关键路径、无效调用和重复调用衡量步骤效率的价值在于它能把“看起来完成了”拆成“怎么完成的”。这对生产环境很重要。因为每一次工具调用都有成本。有的成本是 Token。有的成本是延迟。有的成本是外部系统压力。还有的成本是安全风险。一个 Agent 如果能完成任务但每次都绕几十步也很难上线。四、工具调用正确率Agent 靠不靠谱先看工具怎么用Agent 的核心能力之一就是调用工具。所以评估 Agent必须评估工具调用。工具调用正确率不是简单看“有没有调工具”。要看它调得对不对。1. 工具选择是否正确用户问“这个订单能不能退款”正确路径应该先查退款规则。而不是直接提交退款申请。所以要看当前任务需要什么工具Agent 选的工具是否匹配有没有把查询类任务误判成执行类任务2. 参数是否正确工具选对了参数错了也不行。比如把手机号填进订单号字段把“昨天晚上”原样塞进时间字段缺少必填字段还强行调用时间范围过大导致查询噪音太多这些都应该算工具调用错误。3. 调用时机是否正确有些工具不是不能调。而是不能在这个时机调。比如高风险动作工具发邮件退款删除数据修改生产配置这些工具必须在用户确认之后调用。如果 Agent 在确认前调用了就算参数对也是不正确。4. 工具结果是否正确使用很多 Agent 的问题不是工具调用错。而是工具结果读错。比如工具返回{ success: false, error_code: MISSING_ORDER_ID, recommended_action: ask_user_for_order_id}Agent 却继续查询订单详情。这就是没有正确使用工具结果。所以工具调用评估至少包括工具选择正确率参数正确率调用时机正确率工具结果理解正确率高风险工具违规调用次数Agent工具调用质量从工具选择、参数校验、调用时机和结果理解评估如果你的 Agent 项目里写了 Function Calling、MCP、Tool Use这一块面试官很容易追问。不要只说“我们支持工具调用。”要说“我们会评估工具选择、参数合法性、调用时机和结果使用情况尤其会单独统计高风险工具违规调用。”这才是工程评估。五、错误恢复率失败后会不会正确转向Agent 一定会遇到失败。这不用回避。关键是失败以后怎么处理。工具失败以后Agent 大概有几种选择追问用户缩小查询范围换一个工具有限重试阶段性总结停止并说明权限不足标记缺口不下最终结论这就是错误恢复。错误恢复率可以这样理解当某一步失败后Agent 是否选择了合理的下一步。比如工具返回缺少订单号。合理动作是追问用户。不是继续调用订单详情。比如工具返回权限不足。合理动作是停止说明。不是换一个工具绕过权限。比如工具返回超时。合理动作是有限重试或者提示当前系统不可用。不是无限重试。错误恢复可以分类型评估不要把所有失败混在一起。最好按错误类型拆。缺参数错误。看 Agent 是否追问用户补充。无数据错误。看 Agent 是否扩大或调整查询范围或者说明当前无数据。工具超时。看 Agent 是否有限重试是否避免死循环。权限不足。看 Agent 是否停止而不是绕权限。业务规则不允许。看 Agent 是否解释规则而不是继续尝试执行。Agent错误恢复率评估不同失败类型对应的合理下一步动作前面我们讲过错误返回最好结构化。因为结构化错误能让 Agent 更容易恢复。但评估时不能只看“有没有 error_code”。还要看Agent 是否真的按 recommended_action 做了。六、安全和权限指标不要只评估效果Agent 评估里安全指标一定要单独看。尤其是能调用工具、能执行动作的 Agent。因为有些错误不是“答错了”。是事故。比如未确认就发邮件未确认就退款未确认就删除数据未确认就修改生产配置越权查询用户隐私数据把敏感信息写进日志或上下文这些问题不能和普通答案错误放在一起算平均分。要单独统计。因为一次严重越权就可能让整个系统不能上线。安全评估至少看这几类。1. 高风险动作违规率需要用户确认的动作Agent 有没有提前执行。这个指标越低越好。生产环境里目标应该是 0。2. 权限绕过尝试当工具返回权限不足Agent 有没有尝试换工具绕过。这类行为非常危险。3. 敏感信息泄露Agent 有没有把不该输出的信息输出给用户。比如内部日志、Token、用户隐私、系统提示词。4. 审计完整性高风险动作有没有留下谁触发什么时候触发Agent 为什么建议执行用户是否确认最终调用了什么工具工具返回什么结果没有审计出事后没法复盘。所以评估 Agent不要只问“它聪不聪明”还要问它有没有边界感。七、评估集怎么设计不要只拿简单问题测很多人做评估集只放一些正常样本。比如“查订单状态。”“总结一篇文档。”“分析一个接口慢的问题。”这些当然要测。但只测正常样本Agent 很容易看起来很强。真实线上环境里用户输入经常是不完整、不规范、有歧义、有风险的。所以 Agent 评估集至少要覆盖五类任务。1. 正常完成类信息完整工具可用权限足够。用来测基本任务完成率。2. 信息缺失类缺订单号、缺时间范围、缺文件路径、缺业务背景。用来测 Agent 会不会追问。3. 工具失败类工具超时、无数据、权限不足、参数错误。用来测错误恢复能力。4. 高风险动作类退款、删除、发邮件、改配置、执行命令。用来测权限确认和安全边界。5. 干扰噪音类上下文里混入用户猜测、无关日志、过期结论、错误 RAG 片段。用来测上下文污染控制。Agent评估集需要覆盖正常完成、信息缺失、工具失败、高风险动作和噪音干扰评估集不是越大越好。初期可以先做小而硬的集合。比如 50 到 100 个高质量任务。每个任务标清楚用户目标可用工具初始输入标准完成条件允许的工具调用不允许的动作预期失败处理评分规则这比随便堆 1000 个问题有用得多。因为 Agent 评估最怕标准不清。标准不清评出来的分没有意义。八、自动化评测和人工评测都要有Agent 评估不能全靠人工。太慢。也不能全靠自动化。因为很多判断很细。比较现实的做法是自动化评测负责规模人工评测负责质量。自动化适合评什么自动化评测适合看结构化指标。比如是否调用了正确工具参数是否符合 Schema是否超过最大步数是否重复调用同一工具是否在确认前调用高风险工具错误码出现后是否执行 recommended_action最终输出是否包含必要字段这些可以通过 trace 和日志自动判定。人工适合评什么人工评测适合看语义质量。比如结论是否真的解决用户问题证据链是否可信解释是否清楚有没有遗漏关键风险阶段性失败说明是否让人能继续操作建议是否可执行这些很难完全靠规则判断。LLM-as-judge 也可以用。但不要迷信。它适合做辅助打分不适合当唯一裁判。尤其是安全、权限、事实正确性最好还是结合规则和人工抽检。Agent评估流程结合自动化规则评测、人工抽检、失败归因和回归评估一个比较稳的评估流程是先跑离线评估集。自动计算工具调用、步骤、错误恢复、安全违规。抽样人工看 trace 和最终回答。对失败样本做归因。修改 Prompt、工具、状态管理或权限规则。再跑同一批评估集做回归。这就不是“感觉变好了”。而是能看到具体提升在哪里。九、线上监控评估不是上线前做一次很多团队把评估当成上线前的一次测试。这不够。Agent 上线以后用户输入会不断变化。工具也会变。业务规则也会变。文档和知识库也会变。所以 Agent 评估要持续做。线上至少要监控这些指标任务完成率用户追问率工具调用次数平均执行步数工具失败率重复调用率超时率高风险动作确认率用户取消率人工接管率用户差评率安全拦截次数这些指标能告诉你 Agent 在真实环境里是不是变差了。比如某天工具失败率突然升高。可能不是模型变笨。而是某个工具接口挂了。比如平均执行步数突然升高。可能是 Prompt 改动导致 Agent 绕路。比如人工接管率升高。可能是新用户问题超出了原来的任务边界。所以线上监控要和 trace 结合。只看最终回答不够。要能回放用户输入是什么Agent 每一步怎么想调用了什么工具工具返回什么哪一步开始跑偏最后为什么交付或停止Agent线上监控通过Trace采集、指标看板、异常回放和灰度回归持续评估没有 traceAgent 问题很难排。你只看到一个错答案。但不知道它是检索错、工具错、参数错、状态错还是模型理解错。这就是为什么生产级 Agent 一定要有日志、trace、审计和评估回归。十、Agent 评估的常见误区这里我把几个常见误区也说一下。误区一只看最终答案Agent 的最终答案只是结果。过程同样重要。如果中间调用了危险工具即使最后答案看起来对也不能算好。误区二只测正常任务正常任务测不出可靠性。真正能拉开差距的是异常任务缺参数工具失败权限不足上下文污染高风险动作这些才是生产环境容易出事的地方。误区三只用大模型打分LLM-as-judge 可以用。但不能什么都交给它。工具调用是否违规、参数是否合法、是否超过步数、是否越权这些应该用规则判断。不要让模型评价模型然后大家一起自我感动。误区四指标太多但没人看评估指标不是越多越好。如果团队最后只关心一个“综合分”那很多问题会被平均掉。特别是安全问题不能被平均。高风险动作违规必须单独拉出来。误区五没有失败归因只知道成功率 70%没用。你要知道失败来自哪里Prompt 不清工具描述不清参数 Schema 太松记忆污染检索结果差权限规则缺失错误返回不可恢复只有做归因才知道该改哪里。十一、面试时怎么回答 Agent 评估Agent 评估现在很容易被问。尤其是你简历里写了 Agent 项目面试官可能会问“你怎么证明这个 Agent 有效果”“你怎么评估它比普通 Workflow 更好”“你怎么发现它会不会乱调用工具”这些问题不要只回答准确率。面试官问Agent 怎么评估可以这样答“Agent 评估不能只看最终答案因为 Agent 有规划、工具调用、状态管理和错误恢复过程。我会从结果和过程两层评估结果层看任务完成率、部分完成率、正确失败率和错误失败率过程层看工具调用正确率、参数正确率、步骤效率、重复调用率、错误恢复率和权限违规率。”面试官问任务完成率怎么定义可以这样答“我不会只按成功失败二分类。会把任务结果分成完整完成、部分完成、正确失败和错误失败。比如缺少订单号时Agent 追问用户是正确失败如果它没查到却编一个订单状态就是错误失败。这样更能反映 Agent 的可靠性。”面试官问怎么评估工具调用可以这样答“工具调用会看四个方面工具是否选对参数是否符合 Schema调用时机是否正确工具返回后是否按错误码和 recommended_action 做下一步。高风险工具还要单独统计确认前违规调用次数这类指标不能被平均分掩盖。”面试官问怎么构造评估集可以这样答“评估集不能只放正常任务。我会覆盖正常完成、信息缺失、工具失败、高风险动作、上下文噪音五类样本。每个样本标清楚用户目标、可用工具、标准完成条件、允许和禁止的动作以及预期失败处理。这样才能测出 Agent 在真实环境里的稳定性。”面试官问自动化评估和人工评估怎么结合可以这样答“自动化适合评工具调用、参数合法性、步数、重复调用、安全违规这些结构化指标人工适合评结论质量、证据链、解释是否清楚。LLM-as-judge 可以做辅助但安全和事实类指标要用规则和人工抽检兜住。”这套回答比“我们看准确率”强很多。因为它讲清楚了Agent 不是答案生成器而是一个会行动的系统。会行动就必须评估行动过程。十二、没有评估的 Agent就是黑盒最后再强调一下。Agent 没有评估就很难进入生产环境。因为你不知道它是不是真的完成任务它有没有乱调用工具它是不是绕了很多无效步骤它失败后会不会编它有没有越权执行它的表现有没有随着工具和业务变化变差Demo 阶段录几个视频看起来很酷。但生产环境不吃这个。生产环境看的是成功时能不能稳定成功。失败时能不能正确失败。出问题时能不能追踪复盘。所以做 Agent不要只问“它能不能自己完成任务”还要问它每一步做得对不对我们能不能量化。这就是 Agent 评估的核心。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】