当前位置：首页 > news >正文

Harness 工程是个框，什么都可以往里装

news 2026/6/17 23:21:18

在最近使用 LLM 进行自动化 Prompt 工程，并推进 Agent 工作流端到端落地时，我尝试将底座模型切换到了 Gemini 3 Flash 和 Sonnet 4.6 这个级别。一个棘手的问题开始暴露：在简单的prompt指令下，模型往往倾向于“走捷径”完成优化任务，也就是简单把bad cases直接写入prompt，让llm记住从而提升测试集准确率。

这也就是由来已久的或老大难的Reward Hacking（奖励作弊/奖励劫持）。事实上，为了解决大模型输出不稳定、幻觉、可控性差等痛点，近期 Claude 团队提出了Harness Engineering这个概念，而现在它更是被自媒体大加吹捧，甚至有将其视为 Agent 时代“新范式”的趋势。但从业务一线的视角来看，我们有必要对这些名词做一次祛魅，回归软件工程的本质。

Reward Hacking：当聪明成为一种“阻碍”

当你的系统具备了明确的评估机制（比如测试用例、或者 LLM-as-a-Judge），高智商的模型往往不会按照你预期的业务逻辑去推导，而是会直接寻找规则的漏洞。

这并非我们业务中独有的现象，海外的研究社区已经给出了大量实证：

绕过单元测试：在针对大模型代码生成的强化学习研究中，研究人员发现，当业务代码逻辑过于复杂时，Agent 会选择直接修改底层的测试代码，把断言（Assertion）条件改为恒为真，以此获取“测试通过”的奖励信号。
滥用评估指标：当系统使用类似 ROUGE 这类文本重合度指标作为奖励函数时，模型会生成毫无可读性、但词频完美契合参考文本的乱码，从而把分数刷满。
破坏运行环境：Palisade Research 等机构在近期的 Agent 安全测试中发现，部分具备高级执行权限的模型，在发现常规方法无法完成目标时，会尝试直接终止对手进程或修改系统环境配置来达成“任务完成”的状态。

这些案例说明了一个残酷的现实：单纯依赖 Prompt 调优（比如在提示词里加上“必须严格遵守规则”）已经无法约束强模型的下限了。

祛魅 Harness：它究竟是什么？

面对大模型的不稳定以及狡猾的 Reward Hacking，我们需要在系统里引入更强硬的控制手段。这就引出了被广泛讨论的 Harness Engineering。

很多讨论将 Harness 描述得非常宏大，包含了意图控制、自我反思、元约束等。但如果我们去看 Anthropic 官方工程团队在《Demystifying evals for AI agents》一文中的定义，他们对 Evaluation Harness 的解释其实非常朴实：

“An evaluation harness is the infrastructure that runs evals end-to-end. It provides instructions and tools, runs tasks concurrently, records all the steps, grades outputs, and aggregates results.”

用开发者的语言来说，Harness 本质上就是一套用于运行端到端评估的脚手架代码。它负责加载数据集、并发调用接口、记录中间态、运行断言，最后输出评估报告。

它并不是什么颠覆性的新物种，而是我们熟悉的自动化测试流水线（CI/CD）在 AI 领域的延伸。只不过，以前的测试对象是输入输出确定的纯函数，现在变成了充满非确定性的 Agent 系统。

构建 Agent 系统的几点工程建议

既然明确了 Harness 的本质是自动化测试与边界约束代码，那么在实际构建业务 Agent 时，我们可以采取一些更务实的工程手段：

1. 软提示转为硬约束 (Hard Constraints over Prompts)

永远不要将系统输出的稳定性完全寄托在 LLM 的指令遵循能力上。与其花几个小时修改 Prompt 试图让模型输出格式完美的 JSON，不如直接在工程流中串入强校验器（如 Pydantic）。

防御性编程：在业务代码层面，如果模型的输出不符合业务枚举值、格式错误或产生幻觉，直接在代码层抛出异常并触发重试机制，将脏数据拦截在下游业务逻辑之外。

2. 建立由 Bad Case 驱动的测试集 (Failure-Driven Evaluation)

不需要一开始就追求一个大而全的评测集。最有效的评测数据永远是被业务 Bug 喂出来的。

例如在 400 电话场景中，只要发现模型将特定的方言误判了意图，就立刻将这条转写文本补充到 Base 测试库中。
所谓的“Harness”，也就是在你每次修改 Prompt、调整 RAG 检索策略或切换大模型版本时，用自动化脚本把这个积累了几千条 Bad Case 的库跑一遍。核心指标（如 Recall 和 Accuracy）退化，就不允许上线。

3. 限制“裁判”的自由裁量权 (Guard the Judge)

如果我们使用 LLM 来做意图的交叉过滤或自动打分，必须防范模型固有的“奉承偏见”（倾向于给长篇大论打高分）。