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

在最近使用 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 来做意图的交叉过滤或自动打分必须防范模型固有的“奉承偏见”倾向于给长篇大论打高分。不要让模型直接给出一个主观分数。在 Harness 脚本中应该向“裁判”模型提供结构化的事实检查清单Checklist。要求裁判必须先输出逐步对比的布尔值结果最后再根据预设的硬代码逻辑而不是模型自己的感觉来汇总得分。总结Harness 确实很重要它标志着大模型应用从早期的“写提示词阶段”逐渐步入了严肃的软件工程阶段。但在实际落地中我们无需对其过度包装。对于工程师而言少谈一些玄乎的范式转移多写一些兜底的代码断言踏踏实实地维护好那个包含着无数真实业务坑点的测试集才是保障 Agent 系统稳定上线的唯一捷径。