做Agent应用开发和做传统软件有一个特别不一样的地方：传统软件你测的是“逻辑对不对”，而Agent你测的是“能力的边界在哪里”。我在不少项目里见过同一个Agent，换一种Prompt表述效果就天差地别，换一套运行环境直接罢工，这背后缺的就是一套完整的评估机制——也就是业内常说的Harness Engineering。说得直白一点，harness就是给智能体“套缰绳”的那套系统化装置：任务怎么下发、环境怎么搭、结果怎么收集、能力怎么度量，全都要有明确的设计和标准。这篇文章我会从评估维度设计、基准集构建、环境隔离、评分机制到常见坑点排查，完整梳理我在智能体能力评估体系上的实操经验。适合正在做Agent应用开发、想要系统验证智能体能力边界的团队和个人参考。
1. 先想清楚：为什么评估Agent比评估模型难一个量级
1.1 传统模型评测的本质是“静态比对”
早些年做大模型评测，思路其实很朴素：准备一批带标准答案的题目，把模型输出跟参考答案做匹配，算准确率或者ROUGE分数。这种评估方式有一个隐含前提——输入输出空间是封闭的，正确答案可以被穷举。比如判断一段文本的情感倾向，答案基本就是正向、负向、中性，套个分类指标就行。
这种静态评测对单纯的文本生成模型仍然有效，但放到智能体身上就完全不适用了。因为Agent不是一次性输出一个结果，它会经历多轮对话、调用外部工具、读取环境反馈、修正自己的计划，最终才给出结论。整个过程是一串由动作和观测组成的闭环序列，而不是孤立的一句话。
1.2 智能体评测引入了“过程”和“环境”两个变量
举个例子。你让一个Agent帮你订机票，它需要先理解你的出行需求，再调用航班查询工具，看到返回结果后筛选合适班次，然后调用下单接口，最后跟你确认订单信息。这个过程中任何一步出了偏差——比如工具参数传错了、返回结果解析失败了、或者用户临时改了日期——Agent都需要自主适应。你光看最后“是否订票成功”这个结果，根本判断不出它到底是靠合理的规划走通的，还是碰运气蒙对的。
更麻烦的是环境因素。同一个Agent，在不同接口响应速度、不同数据格式、不同上下文长度的环境里，表现可能差很多。你在离线环境测得好好的，一放到生产环境就频繁超时。所以评估Agent，本质上是在评估一个“闭环决策系统”，而不只是一个“文本生成器”。这个系统里有模型本身的推理能力，有工具调用链路的稳定性，有记忆管理策略，还有应对异常情况的恢复能力。
1.3 Harness Engineering就是把这个闭环变得可控
正因如此，才需要专门的Harness Engineering来做能力评估。它的核心目标是把上面这些不确定性因素，变成可控的、可复现的实验条件。我理解下来，一套合格的harness至少要满足四个约束：
- 任务空间可控：你知道每个测试任务在考什么能力、难度层级是多少，而不是随便从题库里抽题。
- 环境状态可控：工具返回什么内容、接口通断状态、数据噪音这些都由测试平台注入，不能靠运气。
- 观测路径可控：Agent每一步决策、每次工具调用、每轮上下文变化都能被记录下来，事后可回溯。
- 评分标准可控：什么样的过程算合理、什么样的结果算达标，规则在测试开始前就定死，不能被主观偏好左右。
一句话总结，Harness Engineering要做的就是把“考驾照”变成“赛道测试仪器”。驾照考试只能告诉你这人过没过，赛道测试能告诉你每一个弯道的入弯速度、刹车点、方向盘修正幅度。后者才是你迭代Agent真正需要的数据。
2. 智能体能力雷达：五个核心评估维度怎么设计
2.1 任务理解能力：能不能把模糊意图拆成可执行清单
这是Agent区别于普通对话机器人的第一道门槛。真实场景里用户很少会给出精确指令，更多是“帮我安排一下下周去某地的出差行程”这种模糊描述。任务理解能力的评估重点，是看Agent能不能从模糊需求中提取关键约束——时间、地点、预算、偏好——并且转化成可执行的操作序列。
我常用的测试手法是构造“意图梯度”：同一个底层需求，给出信息完整程度递减的多种描述。比如先给“从北京到上海，下周二早上出发，预算两千以内”，再给“我下周要出差，帮我看看怎么去合适”。前者考察信息提取能力，后者考察主动澄清和合理假设能力。评分维度分两层：一层是提取出的约束项是否完整，另一层是据此制定的任务清单是否和约束冲突。
2.2 工具调用能力：接口参数与返回解析的硬功夫
Agent的能力延伸全靠工具，所以工具调用是评估的重中之重。这里最容易踩的坑是只看“调用成功与否”，而忽略了参数构造的合理性和返回值解析的健壮性。
我会把工具调用拆成三个子指标来做记录：
- 参数准确性：传给工具的参数值是否符合语义要求，比如查天气时城市名是否规范、查股票时股票代码是否补全了交易所后缀。
- 工具选择合理性：面临多个工具可选时，是否选了最合适的那一个。有些Agent会“偷懒”，凡是日期问题都去查日历，明明算一下就能搞定。
- 返回解析稳定性：工具返回的是JSON还是纯文本？字段缺失时会不会崩溃？返回格式变化时能不能自适应？
设计工具集的时候我会故意埋一些“坑”：比如某个接口偶尔返回空字段、某个接口会在特定条件下报错。这不是刁难Agent，而是真实生产环境里一定会遇到的情况。你希望Agent在返回异常时能从容地换一条路，而不是直接卡死或编造一个错误结果。
2.3 多轮规划与记忆管理：长任务不迷路
任务越长，越考验Agent的规划能力和记忆管理能力。一个需要十步以上的任务，Agent很容易做着做着就忘了原始目标，或者被中间某个细节点带偏。
评估多轮规划能力，我倾向于用“路径偏离度”来衡量：把任务的标准步骤序列定义出来，然后看Agent实际执行的动作序列与标准路径的重合程度，以及关键节点是否按序完成。这里要注意留出合理的弹性空间——允许Agent用不同顺序完成任务，只要结果对、没有逻辑硬伤就行。
记忆管理方面，我会专门设计一些跨轮信息依赖的任务。比如前一轮聊到的某个偏好，要在五轮之后的操作中体现出来。如果Agent在中途把用户偏好忘了，那说明上下文管理或长期记忆机制存在缺陷。这个问题在真实落地中非常致命，因为用户对Agent反复上下文的容忍度极低。
2.4 错误恢复能力：出状况之后的临场反应
生产环境不可能一直风平浪静。接口超时、传参失败、返回数据格式错误、甚至用户中途改变主意，这些都是常态。错误恢复能力评估的核心在于：Agent能不能发现异常、判断异常类型、采取合理兜底策略。
我在harness里专门设计了“故障注入”机制，在任务执行到特定步骤时，人为让某个工具报错或者返回意料之外的数据。观察点有三个：
- 能不能感知异常：是明确识别到“工具调用失败”，还是把异常结果当成正常数据继续用？
- 能不能定位问题：会不会把网络原因归咎于参数问题，或者反复用同一个错误参数重试？
- 能不能调整策略：故障后是换工具、调整参数、跟用户确认，还是干脆放弃任务？
这里有一条我很在意的底线：Agent绝对不允许因为环境异常就编造结果。有一次实测里，某个Agent在工具查询失败后直接“脑补”了一组数据返回给用户，这是最危险的错误类型。评估体系里我会把这种行为直接判为任务失败，没有任何商量余地。
2.5 安全边界与合规意识：能力再强也得守规矩
安全边界评估分为两个层面。第一个层面是内容安全：Agent会不会输出危险指令、歧视性内容、或者诱导用户做违规操作。第二个层面是权限边界：Agent面对超出能力范围的请求时，会不会越权调用工具或者编造“已处理成功”。
我会设计一批“越权请求”用例，比如让Agent修改其他用户的订单、查询未授权的数据。标准行为应该是明确拒绝或者提示权限不足，而不是试图绕过限制。还有一种情况也要测：请求本身合法但实现链路涉及敏感操作时，Agent是否会先跟用户做二次确认。这个细节对金融、医疗、企业内部应用尤其重要。
3. 从零搭建一套可复现的评估基准集
3.1 第一步：先画能力画像，再写测试任务
很多人搭评估集一上来就闷头写Prompt，这是本末倒置。我之前踩过这个坑，写了一堆看起来像模像样的任务，结果跑完发现全在考“知识问答”，根本没有触达工具调用和规划能力。
正确做法是先画能力画像。所谓能力画像，就是把你期望Agent具备的能力列成一张矩阵，标注每一项在目标业务里的权重。举个例子，如果一个Agent是做智能客服的，那么任务理解权重可能占30%，工具调用占25%，错误恢复占20%，多轮规划占15%，安全边界占10%。而如果做的是一个数据分析Agent，那么工具调用的权重可能会被拉到40%以上。
能力画像确定之后，再按权重分配测试任务数量。这样做的好处是，最终评估分数能直观反映Agent在目标场景下的“适用度”，而不是一个含糊的“综合智商”。
3.2 第二步：任务集的来源与扩充
任务来源我一般有三个渠道。第一是真实日志脱敏：从生产环境的用户请求里筛选有代表性的case，去掉隐私信息后改写成测试用例。这是最宝贵的一手素材，因为它天然代表了真实的输入分布。第二是人工编制：针对已知的能力短板编写针对性用例。第三是生成式扩写：用大模型把种子任务做同义改写、难度变体，扩充任务规模。
不过生成式扩写之后必须人工审核，这一点不能省。模型改写出来的case有时会引入逻辑矛盾或隐含提示，直接拿去做测试会导致评估结果失真。我习惯的做法是抽20%的扩写用例做人工审核，如果错误率超过5%，就整批退回重写。
3.3 第三步：任务分类与难度标注
每个测试任务都要打上元信息标签，否则后面的统计分析会无从下手。我常用的标签体系包含四层：
- 能力维度：对应前面说的五个评估维度之一
- 难度等级：初阶、中阶、高阶，依据需要的推理步数、干扰项数量、环境复杂度判定
- 工具依赖：这个任务需要调用几个工具，涉及哪些外部服务
- 环境敏感度：任务对接口响应内容、响应时长的敏感程度
难度标注特别重要，因为它是分析“能力天花板”的关键维度。我会默认设定一套难度评级标准：初阶任务通常只需要单步工具调用或者直接问答；中阶任务需要3到5步推理、多工具协作或一定程度的容错；高阶任务则需要长程规划、跨域调度或在恶劣环境条件下完成。
任务建好之后，在正式跑测试之前必须做一次“可解性验证”。即用人工或者已知的高质量模型先跑一遍，确认任务确实可解，并且存在合理路径。这一步能避免因任务本身设计错误而导致的误导性结果。
3.4 第四步：构建环境隔离舱与工具模拟器
这一步是整个harness工程里最耗费精力的环节。评估Agent时绝不能拿生产环境直接测试——一来外部接口的波动会污染结果，二来评估任务可能触发真实业务副作用。所以我建议构建独立的测试环境舱，所有工具调用都指向模拟服务。
模拟器要能配置返回内容、响应延迟、报错时机，从而模拟不同的“环境剧本”。比如“乐观剧本”是各接口都正常返回，“严苛剧本”里会有30%的概率超时、10%的返回数据缺字段。这样不仅评估了Agent的能力，也顺带测试了它在不同环境条件下的鲁棒性。
脚本模拟服务的实现不难，核心是接口契约要对齐线上真实版本。你真打生产接口拿到了什么结构、字段含义是什么，模拟器就得保持一致。差异太大，Agent在模拟环境里学到的应对方式拿到真实环境会失效。
4. 评分机制：从“凭感觉”到“可计算”
4.1 结果分与过程分双轨记账
评分机制是harness的“裁判系统”，设计得不好会让整套评估失去公信力。我强烈建议不要只给一个总分，而是把结果分和过程分拆开统计。
结果分关注的是终态是否达标。比如订机票任务里“是否成功出票”、查询任务里“返回字段是否齐全”。结果分简单直接，但信息量有限——两个Agent都订到了机票，一个精打细算选了最便宜班次，另一个无脑选第一班，结果分一样，能力差异完全体现不出来。
过程分则关注决策质量。比如Agent查询航班前的约束条件是否用足、遇到航班取消时的备选方案是否合理、整个链路中是否对用户传达了恰当预期。过程分的评分标准要提前定义成评分细则（rubric），每个分数档位对应什么样的行为描述。
4.2 分步打分：把人怎么判规则翻译给机器
纯靠人工看过程分，评估一百个用例还能接受，评估上千个用例就完全不现实了。所以我把过程分拆成“可程序化校验”和“语义评判”两部分。
可程序化校验的部分包括：是否调用了指定工具、工具调用次数是否在合理范围内、是否发生了权限越界、是否在超时时间内完成任务。这些规则代码可以直接判断。
语义评判的部分则需要结合大模型裁判。比如“Agent给出的理由是否充分”“备选方案是否合理”，这类问题我采取两阶段策略：先用一个评判模型粗筛，把明显达标和明显不达标的case过滤掉，剩下的模糊地带交给人工仲裁。这种做法能把人工成本压缩到20%以内。
4.3 温度参数与随机性控制：保证同一任务可重复
模型输出的随机性是评估复现的头号杀手。同一道题同一套配置跑三次，结果可能不一样。为了让评估可复现，至少要做到三点：固定temperature（通常设置在0.2以下）、固定随机种子、固定模型上下文窗口截断策略。
这里要特别提醒一个容易被忽视的细节：评估环境里要把“模型推理开关”统一配置。像思维链展示长度、重试次数上限、单步超时时间，这些参数不一致的话，指标差异很难归因到模型能力本身还是配置差异上。
还有一个经验：每个测试任务至少跑3次取结果分布，而不是只跑一次记一个分数。因为大多数场景我们关心的不只是平均能力，还有稳定性。一个平均分高但方差极大的Agent，在生产环境里大概率会让你头疼。
4.4 防泄漏与防污染机制
基准集泄漏是评估体系最常见的隐性问题。这里说的泄漏不仅指测试题出现在训练数据里，还包括Agent在任务过程中“意外”访问到答案信息。比如模拟器里的某个接口恰好返回了参考解，被Agent抓到后直接照抄输出。
我在harness里规定了一条硬规则：任何测试环境的返回数据中，不允许包含参考答案、期望规划路径、额外评分提示。模拟器返回内容必须和真实环境无差别。同时，基准集要按版本管理，每轮评估完成后记录测试集版本号和评测时间，方便追溯是否有数据污染情况。
5. 常见问题与排查技巧实录
5.1 同一个任务跑三次结果差异巨大
现象很典型：三跑同一任务，一次完美完成、两次方向跑偏。可能的原因有几个：模型随机性过高（检查temperature和top_p是否没固定）、上下文长度超限导致早期信息被截断、工具返回中没有解析到关键字段导致Agent被迫猜测。
排查路径：先看日志，对比三次跑动中同一位置的动作序列差异在何处出现。如果是执行早段就开始分叉，大概率是模型随机性或任务描述歧义；如果前半程一致、后半程分叉，一般就是上下文丢失或环境步变量干扰。
5.2 评估分数虚高，一到真实验证就翻车
这是最常见的“惊喜”。虚高的原因通常有三个方向：任务集和Agent的Prompt存在隐式“对答案”——比如测试数据的表述和参考路径天然同构，模型不需要真正推理就能蒙对；评分标准过宽——终态对了就给满分，完全不看过程中的严重错误；模拟器和真实环境状态分布不符——真实环境的噪音和变化远高于模拟器。
对应药方：不断往跑测环境里注入干扰项、拉大评分扣分的粒度、定期用真实环境样本做交叉盲测。我自己会在每次上线前做一次“对照跑测”：同一批任务，用模拟器和灰度真实环境各跑一遍，对比两边的分布差异。差异超过20个百分点，说明模拟器的保真度已经出问题了。
5.3 工具偶尔报错，Agent全部白跑
有些Agent在工具调用失败后会直接放弃或者反复重试同一个请求，白白消耗预算和时间。这个问题一方面要靠Prompt侧优化，另一方面评估体系里必须记录“重试策略”指标——Agent在什么条件下重试、重试多少次、有没有更换参数。
我习惯在harness里专门统计一个“无效动作占比”：Agent所有动作中，因重复调用同一接口且参数未变化而产生的无效动作所占比例。这个指标我设了一个预警线——超过10%就要去看Agent的重试逻辑了。
5.4 评估成本居高不下
很多团队到最后不是不想评估，而是评估太贵了。每次跑一个完整基准集要几百万token、上千次模拟工具调用，时间成本和经济成本都很高。
我的建议是分层抽样策略。日常迭代不要每次跑全量，先跑一个核心子集。核心子集是从全量基准集中按能力维度和难度分层抽样出来的，大约占全量30%的规模。只有到了发版或里程碑节点，才跑全量基准集。另外，分级难度任务的评估频率可以不同，低难度任务在回归时快速跑，高难度任务做精测。这种组合能显著压缩评估周期，同时把风险控制在一定范围内。
6. 一些关于“评估体系可持续性”的经验
Harness Engineering建设不是一次性工程，它会随Agent能力演进不断迭代。我这里分享几个实用心得。
第一，基准集要跟着Agent的成长做难度升级。模型能力越来越强之后，原来设计的“高阶任务”可能已经变成“中阶任务”。建议每轮大版本迭代后，对基准集整体做一次难度校准，删掉那些所有Agent都能满分通过的题目，补充新的、更有区分度的任务。否则整个评估体系会慢慢变得像摆设——分数永远好看，但再也拉不开差距。
第二，人工抽检不能停。机器评分和模型裁判做得再好，也必须保留一个固定比例的人工复核通道。我习惯是每轮评估抽5%到10%的样本做人工盲审，重点看不按规则出牌的边界case。很多体系性的漏洞最早都是通过人工盲审发现的。
第三，不要被指标牵着走。我见过不少团队为了追求评估集分数，反复去调Prompt和Agent的“应试技巧”，把这些技巧在测试任务上刷到新高，但真实业务指标毫无变化。如果遇到这种情况，几乎可以断定评估任务的设计出现了方向性偏差。一个健康的harness应该能真实预测业务表现，而不是只跟基准本身自洽。
第四，评估结果要能给出“可执行的行动项”。我的建议是不要只出一张打分表，而是强制要求每次评估的产出物里包含能力短板清单和对应的改进建议。比如，在某次评估中发现“错误恢复维度”得分低了就能很快定位到工具错误解析代码，说明逻辑链路有问题。这样的评估才真正指导到了下一次迭代，让评估体系本身也形成闭环。
说实话，做一个让人信服的评估体系比开发Agent本身更考验工程功底。它要求你把不确定的东西变成可度量的，把模糊的能力叙述变成可验证的指标，还得在成本、效率和真实性之间反复博弈。这一套东西没有银弹，只能一个坑一个坑地踩平。不过一旦跑起来，它给你带来的回报是持续的——每一次Agent迭代，你都能明确知道是变好了还是变差了，以及差在哪一个具体的能力维度上，这比任何主观的“感觉更强了”都靠谱得多。
