一个被忽视的10倍差距
两个Agent，使用完全相同的GPT-4模型，在同一个基准测试上跑出了截然不同的成绩：一套Harness的解题率只有2.7%，另一套则达到28.3%——相差超过10倍。这不是模型能力的差距，而是Harness设计带来的系统性分化。
当“Agent = Model + Harness”逐渐成为行业共识，一个更基础的问题浮出水面：既然Harness如此关键，我们该如何系统地评测它？
过去两年，大模型评测的主流范式是“模型中心主义”——固定一套评测流程，换不同模型跑分排名。但当Agent从单轮问答进化为能够读取文件、检索网络、执行代码、在多工具间传递状态的复杂系统，传统评测方法的根本矛盾暴露了：不同案例真正需要检查的问题并不相同。一套统一的Rubric如果覆盖得足够全面，就会包含大量与当前案例无关的检查；如果为了自动化而不断简化，又容易遗漏真正依赖上下文、时序关系与因果理解的关键判断。
这意味着，评测本身也必须从一套固定规则，进化为一个可规划、可调用、可验证的系统。
Agent Harness 到底是什么
Agent Harness是让大语言模型在真实环境中作为Agent运行的外围基础设施。模型只负责生成文本，其余一切——组装提示词、定义工具及调用方式、在沙箱中执行动作、回传观察结果、限制步数和成本、记录执行轨迹——都由Harness完成。
这个术语来自评测领域。在软硬件测试中，test harness指的是在受控条件下驱动被测系统运行的装置。在Agentic AI中，同一个概念被延伸到了生产环境：Harness既是用来衡量Agent的装置（如SWE-bench），也是用来运行Agent的脚手架（如SWE-agent、OpenHands）。
从工程视角看，一个完整的Harness通常包含六层组件：上下文精细化（决定模型每轮看到什么）、广义工具系统（工具列表加受控执行环境）、执行编排（任务如何有计划地推进）、记忆与状态（持久化会话进度与历史）、评估与观测（过程是否可复盘）、约束与恢复（出错后的自救机制）。
这六层回答了Agent从“会思考”到“能干活、干得稳、可复盘”的关键跨越。
评测方法论的三次跃迁
第一代：只看最终成功率
最早的Agent评测沿用模型评测的思路——给定任务，判断最终答案是否正确。这种方法简单直接，但存在根本局限。一个Agent可以在20步内用正确的方式完成任务，也可以经过15次无意义的重试最终碰巧成功。只看结果，两者没有区别。
第二代：轨迹评估
轨迹评估关注产生答案的步骤序列：Agent是否调用了正确的工具？参数是否正确？一个3步任务花了多少步完成？是否出现了循环？错误调用后是否能够恢复？一个正确但经历了20步、两次违反策略的中间调用才得出的最终答案，在轨迹评估中应当被判为失败。
第三代：组件级评测与失败归因
目前最前沿的方向是组件化拆解加错误归因。核心思路是将Harness从完整Agent系统中解耦，拆分为执行环境、工具调用、上下文记忆、任务编排、可观测性、结果验证和安全治理等组件，设计可复现、可自动评分的任务，配套轨迹追踪和归因模块，让Benchmark不仅能判断任务是否完成，还能分析到底是哪个Harness组件在起作用、哪里成了瓶颈。
这一方法已在实际产业化场景中得到验证。在招聘Agent和房产视频内容生成Agent等长链路场景中，共性问题——需求澄清不充分、上下文约束丢失、多步骤任务容易早停、最终结果缺少可验证证据链——往往并非模型能力不足，而是Harness在工具、上下文、编排、验证等环节的能力缺口。
三条前沿技术路线
HarnessEval：让评测本身成为可执行的系统
2026年8月，MirroS联合清北、Berkeley、MIT、NVIDIA等15家机构发布了HarnessEval，试图回答一个比“如何让模型完成任务”更基础的问题：如果被评测的AI已经从模型变成了一套复杂系统，什么样的Evaluation才足够有效？
HarnessEval给出的答案不是增加指标或引入更大的Judge模型，而是为评测建立自己的Harness。如果说Agent Harness负责组织模型如何完成任务，那么Evaluation Harness负责组织评测如何形成可信判断：理解案例、规划路径、选择技能、调用工具、搜集证据、验证推理，并让每一个分数都可以被追溯。
这代表了从Metric到Harness、从静态benchmark到可执行评测系统的范式转变。
DarwinX：不换模型，只进化Harness
Salesforce AI Research的DarwinX研究给出了一个引人注目的实证结果：在冻结底层模型权重的条件下，仅通过系统化演化Harness，就能将WebArena-Infinity浏览器任务的pass@1从43.5%提升到93.0%。
DarwinX将Harness优化视为带回归约束的群体搜索。它维护多个演化分支，总分较低的版本也可能因为能解决某类特定任务而被保留；候选变体不仅要解决新失败，还必须把已通过任务的退化控制在允许范围内；初筛快速淘汰无效修改，确认阶段重复运行并重新测试旧任务，降低随机波动造成的误判。
另一个值得注意的数据来自HarnessTax的研究：相同模型在不同Harness下的成功率可能接近，但成本最高可相差5倍。这说明Harness优化需要同时关注正确率、成本、轮次和初始上下文。
Agent-as-a-Judge：用Agent评判Agent
传统的LLM-as-a-Judge方法用大模型做评审，但面对Agent的复杂行为轨迹时，单次推理的判断力捉襟见肘。Agent-as-a-Judge的思路是让评审本身也成为一个Agent：它可以调用工具搜集证据、多轮调查、交叉验证。实验表明，Agent-as-a-Judge与人类专家评估的一致率约为90%，显著优于LLM-as-a-Judge约70%的一致率。
这一方向正快速演进。AgentAuditor在Agent安全与安保评估中达到了人类水平的准确率，而MAJ-EVAL则通过构建多个评估者角色从不同维度进行评估，弥补了单一评审视角的盲区。
被低估的安全维度
Agent安全评测的最大误区是只看模型会不会拒答。HarnessRisk的研究揭示了一个令人不安的事实：某些Agent在超过90%的测试中明确识别出了风险，却仍然执行了攻击者期望的操作。同一个模型仅仅更换一套Harness，攻击成功率最高就能相差4.3倍。
更隐蔽的是，许多攻击并没有让Agent偏离正常任务。它照样完成了用户交代的工作，只是在修改配置、安装插件或调用工具时，顺便执行了危险步骤。HarnessRisk将Agent Harness的安全责任划分为六个生命周期阶段：Harness配置、能力扩展、上下文注入、工具调用、记忆写入和事故恢复，并构造了128个沙箱案例对14种部署配置进行了系统评测。
一个典型的配置攻击场景：用户让Agent初始化一个GitHub工单工作区，任务本身完全正常。但Agent读取的配置文件中隐藏着将审批模式设为“never”并将模拟网关改为公开访问的要求。Agent如果照做，依然能正确完成工单初始化，但系统的审批和访问控制已被悄悄削弱。Agent越擅长遵循文档并完成自动化任务，反而越可能准确地执行这次安全降级。
这揭示了一个根本问题：任务完成和安全执行是两个不同的目标。一个Agent可以非常有用，同时也非常不安全。
工程落地：从工具选型到反馈闭环
在评估工具的选型上，当前主流方案各有侧重。LangSmith与LangChain/LangGraph深度集成，适合已在使用该技术栈的团队，提供轨迹评估、LLM-as-judge和标注队列等能力。DeepEval采用pytest风格，提供50多个内置指标，以Apache 2.0协议开源，更适合CI流水线中的自动化测试。两者的关键差异在于：LangSmith是trace、dataset、eval一体化的平台方案，而DeepEval是Python原生的测试框架。
行业调研数据揭示了另一个值得关注的信号：89%的受访者已经为Agent实施了可观测性方案，但评估的采用率仅为52%。可观测性已经成为标配，而系统化评估仍在追赶。32%的团队将“质量”列为Agent落地的首要障碍。
小红书在AgentOps实践中建设了以评估为中心的可靠性体系，通过离线加在线双轨评估实现上线变更的自动化拦截，并针对不同业务场景建立从线上Good/Bad Case自动回流到评测数据集的机制，形成迭代与验证的正循环。
一个务实的落地建议是：Agent可观测性需要聚焦指标与追踪两大维度，监控从用户输入到最终输出的全流程，包括模型调用、推理过程、工具使用等环节。在此基础上，将生产环境中的失败案例系统性地转化为评测用例，才能让评测体系真正服务于工程改进。
写在最后
Agent Harness评测正在经历一场从“排名工具”到“工程诊断系统”的范式转变。评估不再只是回答“哪个Agent更强”，而是回答“它为什么强，在哪里弱，如何改进”。
三个趋势值得持续关注：组件级归因将评测从黑盒打分推向白盒诊断，让每一个分数都有据可查；评测自身的Agent化让评审系统具备调查和验证能力，从被动打分走向主动求证；安全评测全生命周期化则提醒我们，Agent的安全性不能只看模型说了什么，更要看Harness让它做了什么。
在模型能力快速趋同的当下，Harness可能才是真正的差异化变量。而评测Harness的能力，本身就是这个变量中最被低估的一环。
