Agent Harness 到底该怎么评测：维度、方法与结论边界

一、评测概述：为什么要单独评测 Harness

过去一年，行业讨论智能体的重心从“模型能不能答对”转向“系统能不能把事做完”。当一个智能体产品连续执行几十步、调用多个外部工具、读写文件、访问网络并管理长上下文时，真正决定成败的往往不是底层模型本身，而是包裹在模型外面的那一层执行框架，也就是通常所说的 Harness。

Harness 大致承担这些职责：驱动“思考—调用—观察—再决策”的循环、组装与裁剪上下文、把自然语言意图翻译成结构化的工具调用、约束权限与执行环境、处理超时与重试、记录全链路轨迹、控制 token 与步数开销。这些能力大多不出现在模型评测榜单里，却直接决定产品在真实业务中的可用性。

因此本文的评测对象不是某一个模型，而是一类执行框架的工程能力。评测的意义在于：帮助团队判断某个 Harness 方案是否值得进入试点、试点前应补齐哪些验证、以及在什么条件下它的结论不再成立。评测环境本身可基于公开的通用云资源搭建，例如云服务器、容器平台、对象存储、消息队列、日志服务、监控告警与身份认证等通用类目，不涉及任何特定厂商的专有实现。

二、评测目标：本次评测要回答六个问题

1. 功能完整性：常见任务流程是否被完整覆盖，缺失环节能否补齐。
2. 任务有效性：给定明确验收标准时，任务完成质量与一次通过率处于什么水平。
3. 长程稳定性：步数增多、上下文变长、依赖服务抖动时是否仍然可控。
4. 安全与边界：权限约束、沙箱隔离、敏感信息保护、外部内容注入防护是否可靠。
5. 可观测与可维护：出问题时能否定位、能否回放、能否回归。
6. 成本可控性：完成同一批任务的资源、调用与人力开销是否可预测。

需要强调的是，这是一次条件化评测，不是排名。同一套 Harness 在不同模型、不同工具集、不同任务分布下结论差异很大，任何脱离配置的结论都没有迁移价值。

三、评测对象说明：Harness 的六个组成部分

组成模块	主要职责	缺失后的典型症状
循环控制层	终止条件、步数上限、失败退出、人工介入	死循环、无限调用、预算失控
上下文管理层	历史裁剪、摘要压缩、外部检索、状态外置	越跑越慢、早期指令被遗忘
工具适配层	工具描述、参数校验、返回值归一化、错误表达	参数幻觉、工具选错、错误无法被模型理解
执行与沙箱层	文件系统范围、进程与网络权限、依赖隔离	误改生产文件、越权访问
并行编排层	子任务拆分、结果汇总、冲突消解	多智能体互相覆盖、结果不可合并
可观测与治理层	轨迹记录、指标统计、成本记账、回放回归	无法复现、无法归因、无法优化

四、评测维度设计

维度	关键观察指标	主要验证方式
功能完整性	需求覆盖比例、流程闭环率	场景清单逐项走查
任务有效性	一次通过率、返工轮次、验收得分	固定任务集多次重复
上下文与记忆	长任务指令保持率、压缩后信息损失	超长多轮任务、跨会话任务
工具调用正确性	选路准确率、参数合法率、错误恢复率	构造相似工具与歧义工具
长程稳定性	步数分布、中断率、恢复成功率	长链路任务与故障注入
安全	越权拦截率、注入抵抗率、密钥泄露情况	红队用例与恶意指令集
可观测性	轨迹完整度、定位耗时、回放成功率	人为制造故障再排查
可维护性	升级回归成本、配置变更影响面	版本升级与配置切换
成本结构	单位任务调用量、token 消耗、人力投入	同任务多方案对照记账
易用性	接入工作量、文档完备度、调试便利度	新人从零接入计时

维度不能一次全上。建议按“先有效性与安全、再稳定性与可观测、最后成本与体验”的顺序推进，否则容易出现指标很多但无法指导决策的情况。

五、评测环境与前提条件

控制变量是评测可信度的前提，测试前必须固定并书面记录以下内容：

• 模型侧：模型版本、上下文窗口、采样参数、是否启用扩展推理，评测期间不随意更换。
• 框架侧：Harness 版本、循环上限、压缩策略、缓存策略、重试策略。
• 工具侧：工具数量与描述文本、权限模式（只读/可写）、是否允许网络访问。
• 环境侧：资源配置、网络链路、依赖服务版本、并发上限、限流阈值。
• 数据侧：任务集规模、任务难度分布、验收脚本、是否允许模型访问评测集。

同时必须建立基线：先用一个最小可用方案（例如不带压缩、不带并行、只读权限的简单循环）跑完整任务集，后续所有方案都与该基线对比。没有基线的对比数字没有意义。

六、评测方法与测试流程

推荐流程分七步：

1. 构造任务集：从真实业务日志中抽取任务，覆盖简单单步、多步依赖、需要外部信息、需要写操作、需要人工确认五类；同时保留一批“应当被拒绝”的任务用于安全测试。
2. 编写验收脚本：每个任务的成功标准必须是可自动判定的（文件是否存在且内容匹配、字段是否一致、测试是否通过），避免主观打分污染数据。
3. 建立基线并锁定环境：记录基线在各项指标上的表现，之后每次只改动一个变量。
4. 重复采样：同一任务多次执行，区分“能力问题”和“随机性问题”。单次成功不能证明能力，多次分布才能反映稳定性。
5. 故障注入：在依赖调用中注入超时、限流、异常返回、脏数据、超大响应，观察重试与降级行为。
6. 安全与红队测试：加入外部内容中的恶意指令、伪装成系统消息的文本、越权写入请求，验证权限边界是否真的生效。
7. 记录与回归：把所有轨迹、日志、成本数据落盘，形成可回归的评测集，每次升级后重跑。

一个最小的评测驱动骨架示意如下（伪代码，仅表达流程，不代表任何具体实现）：

def run_eval(harness, tasks, model_cfg, repeats=3):
    results = []
    for task in tasks:
        for i in range(repeats):
            trace = harness.run(
                instruction=task.prompt,
                tools=task.allowed_tools,
                max_steps=task.step_budget,
                permission="read_only" if task.read_only else "workspace_write",
            )
            results.append({
                "task_id": task.id,
                "run": i,
                "passed": task.verify(trace),      # 自动验收
                "steps": trace.step_count,
                "tool_errors": trace.error_count,
                "recovered": trace.recovered_count,
                "tokens": trace.token_usage,
                "human_interventions": trace.interventions,
                "violations": trace.policy_violations,  # 越权/越界行为
                "trace_ref": trace.id,
            })
    return summarize(results)   # 通过率分布、步数分布、成本分布、违规清单

七. 关键维度的深入验证

长程任务与上下文管理。 设计 30 步以上、需要跨多个文件或多个会话的任务，观察早期指令是否被保留、状态是否被正确外置。有效做法是每隔若干步抽查“关键约束复述”，并对比开启压缩与关闭压缩的信息损失差异。如果压缩后任务成功率显著下降，说明摘要策略丢失了关键约束，而不是模型能力问题。

工具调用正确性与错误恢复。 故意提供若干功能相似的工具（如“搜索”“读取”“查询数据库”），并让其中一个的参数描述带有歧义，观察选路准确率；再让工具稳定返回错误码与可读错误信息，观察框架是否把错误有效反馈给模型并触发重试，而不是静默失败。这里的核心指标是恢复率，而非一次成功率。

并行与多智能体编排。 多智能体范式本身不是加分项，需要验证的是收益与代价：拆分子任务后总耗时、总 token 是否反而上升；并行写入是否互相覆盖；结果汇总是否引入新的错误。判断标准很直接——若并行版本的成功率没有提升而成本明显上升，则该场景下不应启用。

安全与隔离。 必须覆盖四类用例：越权读取工作目录之外的资源；写操作绕过确认流程；外部内容中夹带“忽略此前指令”类注入；日志与错误信息中泄露凭据。评测重点是默认拒绝是否成立，以及权限提示是否可被绕过。任何一次凭据泄露都应视为阻断性问题。

稳定性与容错。 注入依赖超时、限流、超大响应与非法 JSON，观察重试是否带退避、是否幂等、是否存在重试放大。同时观察资源占用曲线：长跑任务中的内存与文件句柄是否持续增长，是判断能否上生产的关键信号。

可观测性。 人为制造一次失败，记录从告警到定位根因所需的信息是否齐全：是否有完整轨迹、每步的输入输出、工具耗时、token 记账、策略拦截记录。能否一键回放同一轨迹做回归，决定了后续优化速度。

八、结果解读：什么结论才站得住

• 通过率高但步数分布方差大，说明方案“能做成但不稳”，生产环境需加超时与人工兜底。
• 通过率低但错误集中在工具参数上，问题多半在工具描述与参数校验，属于可修复项，不应据此否定整体架构。
• 只开只读权限表现良好、开放写权限后违规事件上升，说明瓶颈在权限设计而非模型。
• 单次运行的成功案例不具统计意义，必须看多次重复后的分布。
• 成本上升若伴随成功率同比例上升，属于可接受交换；若成功率持平而成本翻倍，则应回退配置。

常见误读之一是把模型升级带来的收益记在框架头上。控制变量、逐次只改一项，是避免归因错误的唯一可靠办法。

九、适用场景分析

场景	优先关注的维度	需要弱化的维度
编码与工程辅助	工具调用正确性、沙箱隔离、回滚能力	交互美观度
流程与办公自动化	功能完整性、人工确认机制、可维护性	极限吞吐
数据分析与报表	结果准确性、幂等性、可复现性	多智能体并行
客服与内容场景	安全合规、注入防护、成本	长程规划
内部研发平台	可观测性、接入成本、回归能力	单任务峰值性能

十、风险与限制

评测结论的边界主要来自四处：任务集与真实流量分布不一致导致的样本偏差；模型版本或依赖服务在评测期间变动导致的环境漂移；评测集被模型见过造成的乐观偏差；以及长周期行为（内存泄漏、成本累积、策略退化）在短测中不可见。此外，自动验收脚本本身的严格程度会直接放大或掩盖差距，脚本过松会系统性高估所有方案。

十一、选型与使用建议

1. 先建评测集，再谈选型。评测集是团队资产，应当从真实业务中持续沉淀并版本化管理。
2. 试点从只读权限开始，写权限按目录、按操作分级放开，并对不可逆操作保留人工确认。
3. 把步数上限、token 预算、超时与重试退避作为默认配置，而不是事后补丁。
4. 灰度上线时同时观测业务指标与框架指标（违规拦截数、恢复率、人工介入率、单位任务成本）。
5. 每次框架或模型升级都跑一次回归，把“升级是否退化”变成例行检查项。
6. 在多智能体编排上保持保守：只有当任务可清晰拆分且汇总代价可控时才启用。

十二、总结

讨论 Harness，实质是在讨论“智能体如何被可靠地约束和驱动”。评测它的正确方式，是把它拆成循环控制、上下文管理、工具适配、执行沙箱、并行编排与可观测治理六个部分，分别设计可自动判定的指标，在控制变量的前提下建立基线、重复采样、注入故障并做安全红队，然后结合业务场景给出条件化结论。任何脱离任务分布与配置组合的绝对判断都不可迁移；真正有价值的产出不是一句“好用或不好用”，而是一套能随版本持续复用的评测集与改进清单。