AI智能体测评从28分到85分：新手可用的Agent提分实战指南

AI智能体（Agent）测评成绩差，大概是新手做Agent项目时最让人崩溃的事：你花了一晚上调好提示词，第二天跑测评，任务完成率还是30%，工具调用的错误日志摞了一屏，多轮对话甚至会在第五轮突然开始胡言乱语。我前两年做一个内部智能体项目时也是这个状态，拿着自测通过的Demo去跑标准评测集，预期80分，结果28分。这篇指南就是我从28分磨到85分的过程复盘，不绕理论，只讲新手能直接上手的排查思路和操作，适合正在被各类Agent基准测试折磨的开发者和产品同学。

1. 别急着改代码，先搞明白测评到底在给你打什么分

拿到一个惨淡的分数，很多人的第一反应是"我的提示词不行"或者"模型不够聪明"，然后开始无脑调参。其实测评和考试一样，你得先知道考纲是什么，才能知道该复习哪里。Agent测评看起来是个总分数，背后往往是一整套复杂的评分维度，每一条的权重和失败原因都天差地别。

1.1 一个典型翻车场景：自测没问题，一跑基准就崩

我给你描述一个我见过太多次的画面：开发者在调试环境里手动输入了几条测试数据，Agent回答得挺好，甚至还能正确调用工具。于是拍着胸脯说"我这个Agent可以了"，结果一上标准评测集，得分不到四成。

为什么自测和正式评测差异这么大？因为自测时你是"带着答案找问题"：你心里清楚这个Agent能做到什么程度，会下意识绕开它不擅长的输入；而正式评测集里的任务往往覆盖了很多你根本没想到的边界场景——用户一句话夹带三个要求、工具返回空结果、上一轮信息被这一轮打断。我在某平台上跑通第一个Agent时，自测的10个用例全过，正式集200个用例直接挂了140个，就是因为我从来没测过"工具返回异常时Agent应该怎么办"这类场景。

所以拿到低分的第一步不是改代码，而是打开评测日志，一条一条看失败样例。把失败原因粗分成三类：没理解任务、格式不对、推理中途断掉。你会发现大量分数其实消耗在某个特定类型上，集中解决那一个点，分数就能有肉眼可见的提升。

1.2 分数拆解：完成率、工具调用准确率、连贯性、效率

我习惯把Agent测评分数拆成四个维度来看，先列个表格，你对照自己的评测报告去填：

我以前拿到评测报告只看总分，后来发现同一个总分排在末尾的人，失败原因可能有本质区别：有人是完成率低，有人是工具调用错，混合在一起看只会让你觉得"这也不行那也不行"，不知道先修哪个。

我的建议是，先把失败样例按上面四类打标签，统计每一类的占比。哪类占比超过三成，就先啃哪类。比如我之前那个项目，工具调用准确率拉低了大约一半分数，那我后来一周都在做工具描述和参数校验的优化，总分的提升就非常快。

1.3 通用基准与业务评测集的差异，以及新手最容易掉进去的坑

还有一个容易被忽略的问题：你拿来做测评的到底是什么？现在市面上有公开的通用Agent基准，也有针对具体业务自建的评测集。通用基准考的是模型在开放任务上的通用能力，比如指令遵循、推理、多步规划；业务评测集考的是你场景里的规则和工具，比如"必须校验手机号格式"、"超时必须重试一次"。

新手容易掉进去的坑是把通用基准的分数当作"Agent本身的好坏"，忽视了业务评测集里那些硬性规则。我见过一个同学在通用基准上跑得不错，但一到业务评测就崩，原因非常简单：评测规则要求输出JSON格式，Agent却按自然语言回答。这不是模型不行，是你的提示词和评测标准不匹配。

实操时要先做一件事：读懂评分细则。是规则判分（比如正则匹配字段、工具调用日志比对）还是用大模型当裁判打分？如果是规则判分，那就好办，把Agent的输出格式往评分脚本的预期上靠；如果大模型当裁判，它的打分还受裁判Prompt的影响，你得连裁判Prompt一起看。我当时就吃过亏：评分裁判把"工具调用成功但是参数冗余"判成"严重失误"，后来才发现裁判Prompt里写着"只要出现错误调用就判失败"，这类细节不看细则根本发现不了。

2. 先把"地基"打牢：环境、模型与调用配置

先给你一个容易扎心的结论：测评分数差，有时候不是Agent逻辑的问题，而是环境复现和调用配置的问题。你换了一台机器、换了一个依赖版本、换了一个请求参数，结果可能就差出二十分。新手总觉得这些事跟"智能"没关系，恰恰相反，它们是不确定环境下最大的误差来源。

2.1 环境依赖与版本锁定：为什么复现不了别人的分数

我最早调Agent时，在本地环境跑一遍，拿到85分，很兴奋。结果第二天在统一的测评环境里跑，只剩52分。当时第一反应是"测评环境有问题"，排查了一整天，最后发现是本地装的某个Agent编排库是开发版，而测评环境用的是稳定版，消息格式的解析行为变了。

这种问题在Agent项目里特别常见，因为Agent的链路很长：模型服务、编排框架、工具调用接口、参数校验层，每一层都有自己的版本和默认行为。稍微有一点不一致，Agent拿到的上下文就不一样，输出自然也不一样。

实操建议很朴素但很有效：把测评环境固定成一个镜像，依赖用锁定版本，包括Python版本、主要库的精确版本，尽量少用"大于等于"这种范围。然后在同一个镜像里跑一次基准，把分数和时间记录下来，作为"基线"。以后每次改动，都在这个基线上做对比。没有稳定基线的情况下谈提分，就像没有尺子量身高，改进再多也说不出效果。

2.2 模型选型：别急着上大模型，先看任务是否匹配

新手选模型有个通病：哪个榜单分高用哪个，完全不看自己的任务类型。实际上，Agent测评里"工具调用准确率"和"多轮稳定性"往往取决于模型和工具链的配合程度，不是单看模型的对话能力。有些大模型推理很强，但函数调用格式经常出问题；有些模型更克制，反而在结构化输出上更稳。

我的经验是，不要一上来就迷信最强的模型，先用当前项目里的100条典型测评样例，在两三个模型上各跑一轮，对比分数和成本。选型标准不是"分最高"，而是"在这项业务上分高且成本可控"。做工具调用的场景，一定要关注模型对结构化输出的贴合度，比如能不能稳定返回一个合法的JSON参数块。

另外还得提醒一句：模型服务的版本也在变。同一个模型服务商调整接口参数后，Agent的调用成功率可能一夜之间变化。所以你的Agent调用层最好对模型接口做一层封装，至少留一个版本字段，方便以后回溯是哪次升级带来的分数波动。

2.3 几个直接影响测评分数的调用参数：温度、最大Token、重试、超时

就算模型选对了，请求层面的几个参数也能轻松拉开差距，而且这还是一些人从来不调的。先说温度。温度太高，输出就花哨，但不稳定；温度太低，输出稳定但可能呆板。对Agent工具调用和规则型任务，建议温度设在0到0.2之间。我在某次工具调用任务上做过对比，温度从0.7降到0.1，工具参数格式出错的概率直接降了一半。

再说最大Token。很多新手没意识到，输出长度不够会导致Agent回答写到一半被截断，而截断会被测评规则判成"未完成任务"。流程复杂一点的规划型任务，建议把最大Token调到输出上限的80%以上，宁可多给一点，也不要让它在关键步骤上戛然而止。

重试和超时往往是批量运行评测时的隐形杀手。如果你用脚本批量跑测评，并发太高导致接口限流，请求超时后没有重试，几十条用例同时失败，分数虚低一大截。正确姿势是：调用层加指数退避重试，比如第一次失败等1秒、第二次等2秒、第三次等4秒，最多重试3次；同时把超时时间设到比模型平均响应时间宽裕一些，避免把"慢"误判成"失败"。我在一次批量测试中加了重试机制后，分数从64分回到了73分，而那段时间我根本没有动过任何提示词。

3. 提示词与任务设计：Agent翻车频率最高的地方

如果环境配置没问题、模型也稳定，测评分数还很惨，那十有八九问题出在提示词和任务设计上。这是新手最熟悉、也最容易凭感觉乱调的地方。你要知道，提示词不是为了"让模型说出漂亮话"，而是为了让模型稳定完成测评里规定的那几个动作。

3.1 指令模糊的代价：写"测评友好版"提示词的三个技巧

给我印象很深的一个案例：某同学给Agent的指令是"处理用户反馈"，结果Agent一下返回了长篇大论，一下只回复"已处理"，完全看模型心情。问题就出在指令含糊，既没有说清楚输入是什么，也没有定义输出长什么样，更没说失败时怎么办。

所谓"测评友好版"提示词，至少要包含三件事：角色和任务边界、输入和输出格式、处理条件和异常规则。我习惯用一个很朴素的模板：

code复制你是【某系统】的智能助手，负责完成如下任务：
【任务描述，一句话说清目标】

你会收到用户输入：【输入字段说明】
请先判断是否满足执行条件，如果不满足，回复缺少的信息。

输出要求：
1. 必须严格按照以下JSON格式输出：{"action": "...", "params": {...}}
2. 如果任务无法完成，必须输出 {"action": "explain", "params": {"reason": "..."}}
3. 不要输出任何JSON之外的文字。

这里的关键是"不要输出任何JSON之外的文字"，因为很多评分脚本只解析纯JSON，多一个标点都可能判错。给一两个示例也一样重要，示例能让模型快速对齐你预期的格式，比你在提示词里强调十遍"格式要正确"都管用。

3.2 把大任务拆成子任务：ReAct与Plan-and-Execute思路

新手常犯的另一个错误，是让Agent一个"thinking"就完成一个多步骤复杂任务，比如"帮我查一下最近订单并统计金额，然后生成报表"。这种任务放在人类身上也需要好几个动作，让模型一步做完，大概率会漏步骤。

这里我的建议不是让你用什么高大上框架，而是理解两个朴素思路：ReAct模式是"思考→行动→观察→再思考"，模型每走一步都根据工具返回的新信息调整下一步；Plan-and-Execute模式是先让模型列出完整计划，再逐步执行。对测评任务来说，后者往往更稳，因为计划阶段能提前暴露"这个任务根本不能执行"的情况，避免模型走弯路。

实操上不需要动架构，在提示词里写一句"如果任务有多个步骤，请先列出步骤计划，然后逐步执行，每完成一步就检查一次结果"就能起效。你会发现Agent在工具调用任务上的动作明显有序很多。我在某个数据查询任务上加了这句之后，计划遗漏率下降了三分之一。

3.3 边界条件要写明白：超时、拒绝回答、歧义消解

很多测评任务里都藏着"坑"，这些坑不在正常流程中，而在异常情况下。比如用户给了一个不存在的订单号，比如用户一句话里有歧义，比如工具返回的数据为空。如果提示词里没有对这种情况做任何约束，Agent就会为了完成"任务完成率"硬编一个答案出来，而评分规则最恨的就是编造。

写法也很简单，但一定要写得具体。举几个我实际用过的句子：

• "如果查询结果为空，明确回复：未找到相关信息，不要猜测或编造数据。"
• "如果用户指令中存在歧义（例如地点、时间、对象不明确），先回复需要确认的参数，不要自行假设。"
• "在连续两次操作没有进展时，停止尝试并输出当前状态和困难原因。"

这些句子看着平淡，作用非常大。测评规则里通常都有"禁止幻觉信息"的检查项，把这几个边界写清楚，能立竿见影地减少"虚假成功"类型的失败。不要觉得模型应该天生会这些，它不一定知道你的业务里什么算歧义，什么算编造。

4. 工具调用调试：让Agent真正"会用工具"

如果你的Agent测评里涉及工具调用，那么恭喜你，进入了整个智能体开发里最磨人的环节。模型本身不会"使用"工具，它只是根据工具描述生成一个调用意图。工具描述不清楚、参数定义不合理、调用报错后没有恢复机制，都会直接把分数拽下去。

4.1 工具描述决定了Agent会不会选错工具

我见过很多开发者，工具描述写得像给自己看的开发文档："该函数用于获取用户信息，参数为userId，返回用户详情。"Agent一遇到"帮我查一下张三的年龄"这种指令就开始迷惑：张三算不算用户？应该用用户信息工具还是搜索工具？

工具描述要写的是"什么时候用、什么时候不用、参数含义、典型示例"，而不是简单翻译函数名。用一个我后来打磨过的工具描述做示例：

json复制{
  "name": "query_order",
  "description": "当用户查询订单状态、物流进度或订单金额时使用。仅用于已登录用户的订单查询；如果用户咨询的是商品库存或售后规则，请改用其他工具。参数order_id为用户下单时生成的13位订单号。",
  "parameters": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "13位订单号，示例：2025010112345"
      }
    },
    "required": ["order_id"]
  }
}

注意描述里既有正向触发条件（什么时候用），也有负向排除条件（什么时候不用），这能让Agent的选工具准确率高出一截。参数描述也要给出格式和示例，模型生成参数时就更少出现"把手机号当订单号传进去"这种低级错误。

4.2 参数校验与失败恢复：调用出错后的自动兜底

工具调用失败，不完全怪模型，有时候是工具本身的错误反馈太贫瘠。常见的做法是直接抛一个异常或者返回"调用失败"，让Agent一脸懵。正确的做法是：工具侧返回结构化的错误信息，告诉Agent哪里错了、应该怎么改。

一个好的错误返回大概长这样：

json复制{
  "status": "error",
  "error": {
    "code": "INVALID_PARAM",
    "message": "order_id必须是13位数字，当前接收到的是12位",
    "suggestion": "请检查order_id是否完整，补充为13位数字后再试"
  }
}

加了suggestion字段之后，Agent在下一次尝试时就能根据提示修正参数，而不是原地重复同样的错误。这一步对提升工具调用准确率极其明显。我在某个项目里给错误返回加上suggestion字段后，Agent的二次尝试成功率从40%升到了73%。

4.3 工具反馈闭环：把错误信息变成Agent的"学习信号"

工具调用除了"成功/失败"，还有一个新手容易忽略的环节：成功返回的数据里也藏着"不应当继续做什么"的信号。比如搜索工具返回了0条结果，Agent下一步如果还用同样的关键词再搜一遍，就是典型的低效死循环。

我给Agent设定的行为是：当某类工具返回空结果时，主动修改查询条件或换一个工具。最简单的方法是在提示词里加一条："如果搜索结果为空，先调整搜索关键词，再尝试一次；仍然为空则停止并报告，不要重复完全相同的查询。"这看起来是常识，但对模型的稳定性和效率都有直接影响。

同时要给工具调用加一个"最大尝试次数"限制，避免Agent陷入无限重试的循环。测评系统对循环很敏感，超过一定轮数会被判超时或任务失败。一般我会限制单任务最多5次工具调用，超过就强制停止并输出阶段性结果和原因，宁可给一个不完整的真实结果，也不要给一个假装的完整结果。

5. 多轮对话与记忆管理：别让Agent中途"失忆"

多轮场景是Agent测评里很有迷惑性的一环：前两轮表现得像个正常助手，到第五轮突然把用户第一次说的关键信息忘得一干二净。这种"失忆"问题不解决，你的Agent在客服、办公助手、数据分析这类场景里的测评分数永远上不去。

5.1 上下文窗口耗尽与早期信息被挤掉

Agent的每一轮对话，本质上是把历史消息重新发给模型。上下文窗口有限，对话轮数一多、工具返回内容一长，最早期的用户需求就可能被截断。这在测评里的典型表现是：第五轮开始复述用户需求时，漏掉了第一轮提到的关键约束。

排查方法不难：打开测评日志，看每一轮的请求里实际包含多少上下文。如果每轮都在涨，到某轮涨到接近上限，那么多轮失败基本就是上下文机制的问题，而不是模型变笨了。我调试过的一个项目，第三轮之后就稳定把system prompt里的规则挤掉了，因为每轮工具返回的数据都有几千个Token，模型只保留最新内容，旧指令自然被冲走。

5.2 短期记忆与长期记忆的分层设计

要解决失忆，先要分清记忆的类型。短期记忆是"这个任务进行中需要记住的东西"，比如用户这次要查的订单号、筛选条件；长期记忆是"跨任务、跨会话要记住的东西"，比如用户的常用城市、历史偏好。

新手容易把所有信息一股脑塞进上下文，结果窗口很快就满了。我的做法是分两层：短期记忆直接放在最近的对话消息里，由Agent在推理时自行引用；长期记忆单独存到数据库或向量库，需要时再检索进去。比如客服场景中，用户昨天投诉过物流问题，这不属于当前对话上下文，但应该在开始时从长期记忆里拉出来，放到提示词里作为背景信息。

这种分层能大幅减少上下文消耗。你不需要让模型记住所有历史，只需要让它把关键信息放到一个能再次找到的地方。

5.3 记忆摘要与检索机制：给Agent装一个"笔记系统"

就算做了分层，短期记忆还是可能超长，特别是多轮任务中工具返回内容很多的时候。这时候最常见的方案是摘要压缩：每进行N轮，或者上下文达到某个阈值时，把已发生的内容压缩成一个小结，只保留结论和关键字段，把长长的历史替换掉。

我给一个比较实用的做法：在提示词里告诉Agent"当对话超过8轮时，先输出一段对话摘要，用摘要替代前6轮的完整记录"。摘要要包括：用户的核心目标、已经完成步骤、剩余步骤、当前未解决的问题。这样做能避免删除历史时把关键信息删掉。

长期记忆的检索也有讲究。不是把所有历史都塞回去，而是根据当前用户指令，去向量库里找最相关的几条记录。比如用户说"还是按照上次那个地址寄"，Agent应该能检索出"上次那个地址"到底是什么。检索不到时，明确问用户要地址，而不是猜一个。这套"摘要在短期、检索在长期"的组合，是目前我见过性价比最高的多轮记忆方案，实测能在不大改架构的前提下稳住多轮连贯性的分数。

6. 用测评结果反哺改进：建立可持续的调优闭环

最后这部分，是很多新手在分数稍微回升之后最容易忽略的。测评的目的不是给你一个分数截图发朋友圈，而是持续驱动Agent改进。我从低分到高分的整个过程里，最大的收获不是某个具体技巧，而是建立了一套"只有会复盘的人才能持续进步"的调优节奏。

6.1 给失败案例建回归测试集，避免修好一个弄坏一个

你一定会遇到这种情况：辛辛苦苦把A类问题修好了，结果B类问题又多了几个。原因是只改了一个点，却没有覆盖其他场景的用例。所以从第一次正式测评开始，就应该把失败的案例收集起来，攒成一个回归测试集。

回归测试集不需要很大，从几十条失败里挑出覆盖不同失败类型的20到50条就够了。每次修改后，跑一遍全量测试加回归测试，对比分数。我当时就靠着一个45条的回归集，挡住了三次"自以为改好但实际弄坏其他功能"的上线。记录方式也很简单，用脚本或者电子表格，记下每次改动的版本号、测试集得分、失败样例列表。没有这个过程，你根本分不清分数上涨到底是因为模型升级还是因为你自己的改动起了作用。

6.2 一次只动一个变量，用数据确认改进有效

新手调Agent最常见的问题是"我同时改了提示词、换了模型、还调了温度，结果分数涨了，但不知道是谁的功劳"。这种状态看着在进步，其实一团乱麻，后面复现和优化都无从下手。

我的规则是：一次只改一个变量。这一轮只改提示词，下一轮只调参数，再下一轮才换模型。每次跑完对比数据，确认有提升就保留，没提升就回退。这个"无脑但有效"的节奏能让你每个动作都有据可依，也能避免做了很多无效劳动而不自知。

实际操作中，我还会给每一次改动取个代号，比如"prompt_v3_order_query"，然后记录得分。你不需要用什么复杂工具，一个表格就够。关键是坚持。

6.3 别把测评分数当KPI：过拟合基准与盲目堆功能

新手很容易在分数提升的路上走偏，最典型的偏法是"盯着已知失败样例改到完美"。如果测试集只有那些例子，Agent确实会被修得看起来很强，但换一批没见过的输入，分数立刻暴跌。这就是过拟合基准测试集。

防止的方法我比较推荐"留一手"：把评测集分成两半，一半用来日常调优，另一半当作盲测集，每周只跑一次。日常分数可以慢慢涨，但只有盲测分数也在涨，才是真的进步。如果日常分数涨了很多而盲测分数几乎不动，那就要警惕是不是过度拟合了个别样本。

另外，不要看到分数低就疯狂加功能、加工具、加提示词规则。功能越多，Agent的选择空间越大，出错的可能性也越高。我见过有同学给Agent接了十几个工具，结果一半测评失败都发生在"选错工具"上。先把高频失败场景的核心路径打磨顺，再加新功能，这是更稳妥的节奏。

最后分享一个我自己养成的习惯：每次测评结束后，先写三行失败总结，不许写套话，只写具体原因和下一步唯一要做的改动。坚持一个月，你的Agent改进效率会明显比别人快。分数这东西，本质是帮你定位问题的信号，不是用来证明你聪明的奖状。希望你下次打开评测报告时，能少一点懊恼，多一点"下一个问题在哪"的清晰感。