Harness Engineering

Harness Engineering：驾驭工程，2026年兴起的AI工程化新范式，核心在于为AI智能体（Agent）构建一套完整的运行环境、约束规则与反馈闭环，使其能可靠、自主地完成复杂任务 。

将大模型比作“野马”，Harness则是“马具”（缰绳、鞍具），工程师的工作重心从“手写代码”转向“设计让AI可靠工作的控制系统” 。
基本公式：Agent = Model + Harness，Model提供推理能力，Harness提供工具、记忆、权限与纠错机制 。这是继提示词工程（Prompt Engineering）和上下文工程（Context Engineering）之后的第三次重心转移。前两者关注单次交互或信息填充，而Harness Engineering关注全生命周期的系统化控制，旨在解决AI在长周期、多步骤任务中容易跑偏、幻觉或失控的问题 。

Harness Engineering 通过工程手段让AI更“靠谱”，是将软件工程严谨性从“编写代码”转移到“设计环境”的关键实践 。

Harness 组件

Harness 是包裹在模型外部的一整套工程机制，包括系统提示词、上下文管理、工具调用、任务路由、工作流编排、结构化输出、结果校验、失败重试、权限控制、安全护栏、日志追踪和评估体系。一个强模型如果没有Harness，就像一个能力很强的员工，却没有业务流程、操作系统、质量检查和管理机制。一个中等模型配合成熟Harness，有时反而比裸用最强模型更稳定。

    OpenAI在介绍GPT-5.5时披露，一个配备定制Harness的内部版本曾帮助研究人员发现一个与Ramsey数相关的新证明。这个案例说明，实际效果并不只取决于模型本身，还取决于模型外部为它提供了什么工具、验证机制和任务流程。

· 约束与安全：划定工具权限、沙箱隔离、高危操作拦截（如删除文件需人工确认）。
· 上下文与知识：按需加载项目文档、代码规范、API定义，确保AI理解业务背景。
· 验证与反馈：建立自动化测试、错误日志回传机制，让AI在出错后能自动识别并修正 。
· 状态管理：外部化记忆（如进度文件、Git历史）解决长任务中的“失忆”问题，支持多轮协作 。

微调

大模型解决的是能力上限，而微调解决的是业务稳定性。企业需要的不是模型偶尔给出一次惊艳答案，而是模型能够以可预测的成本，长期稳定地按照业务规则完成任务。

最新模型确实减少了很多微调需求。过去需要训练专用模型完成的文本分类、信息抽取、代码生成、文档总结等任务，现在通过强模型、提示词和少量示例就能达到不错的效果。GPT-5.5已经能够面向复杂专业工作和智能体任务，Claude Opus 4.8则进一步提升了工具使用、长任务执行和结果自检能力。

但模型能力变强，并不等于业务系统自动变得可靠。通用模型追求的是广泛适用，企业应用追求的是特定任务中的一致性。例如，模型可能会写SQL，但不一定理解企业内部的字段口径；可能会分析合同，但不一定严格按照固定枚举值输出；可能会回答政策问题，但不一定始终引用正确条款。

因此，微调的目标已经发生变化：不是让模型从“不会”变成“会”，而是让模型从“有时做对”变成“稳定做对”。

微调最适合解决的不是知识更新，而是行为固化。

- 任务模式固化，如合同条款抽取、招标文件解析、舆情分类、工单分派、NL2SQL和意图识别。这些任务通常有固定输入、固定输出和明确判断标准。

- 输出稳定性，如要求模型必须输出固定JSON字段、枚举值或评分结果。Harness可以负责兜底校验，微调可以降低出错概率，两者结合效果更好。

- 业务风格，如政务助手要严谨，客服助手要友好但不能过度承诺，销售助手要积极但不能虚构能力。

- 专业判断边界，金融、医疗、审计、工业和招投标等场景，往往需要模型学习企业特有的判断标准，而不是简单记住一些知识。

- 降本，把高质量大模型生成或人工审核的数据用于微调小模型，让小模型承担大量重复、标准化任务，从而降低推理成本和响应延迟。

Harness和微调的区别

Harness解决的是模型如何工作，微调解决的是模型形成什么习惯。

例如，一个合同抽取系统要求模型输出固定JSON。通过Harness，可以增加JSON Schema校验，发现格式错误后自动重试；通过微调，则可以让模型从一开始就更倾向于按照企业要求输出。前者是在外部纠正模型，后者是在内部改变模型行为。

或一个客服智能体回答错误时，Harness可以检索知识库、调用订单系统、校验用户权限，并在最终输出前进行敏感内容检测；微调则可以让模型长期保持统一的客服语气、分类边界和回复风格。

因此Harness通常应该走在微调之前。因为很多看起来像“模型不够聪明”的问题，本质上是工作流缺失、上下文错误、工具设计不合理或结果缺少验证。

大模型落地顺序：选择合适的基础模型 → 提示词与上下文工程 → Harness → RAG → 微调。

过去常见的路线是：提示词工程、RAG、微调

· 最强模型不一定是最优模型，需要综合考虑能力、速度、成本、上下文长度和部署方式。Anthropic官方在模型选型指南中强调，应在能力、速度和成本之间进行平衡。

· 优化提示词和上下文，任务目标、输入范围、输出格式、判断标准和示例是否清晰，往往直接决定模型表现。

· 构建Harness，把模型接入真实业务流程，包括工具、权限、路由、校验、重试、监控和安全机制。

· 引入RAG，如果模型缺少企业内部知识、最新政策、产品资料或项目文档，应优先通过检索提供信息。

· 微调，如果模型已经获取了正确知识，工作流也已经完善，但在行为模式、专业判断、格式遵循和业务风格上仍然不稳定，再通过微调固化能力。

是否需要微调

Evaluation Harness

评估框架，企业做微调前，应该建立自己的评估Harness。它至少要包含固定测试集、基线模型、业务指标、自动评分、人工复核、错误分类和版本对比。否则，微调完成之后很难回答三个基本问题：模型究竟提升了多少？是不是只提升了训练集类似任务？是否损害了其他能力？

微调最常见的风险不是模型没有提升，而是局部指标提升了，却出现了新的退化。例如格式遵循率提高了，但事实准确率下降；某类业务分类变准了，但其他分类边界变差；专业语言更像企业风格了，但通用推理能力下降。

所以，评估不是微调结束后的验收，而是微调开始前就必须建立的基础设施。

是否要微调

第一，是否已经使用当前主流强模型重新测试？基础模型快速迭代，过去需要微调的问题，可能已经被新模型直接解决。

第二，是否已经系统优化提示词和上下文？如果任务定义、示例和输出要求本身不清晰，微调只会把混乱固化进模型。

第三，是否已经建立Harness？工具调用、流程编排、校验和重试可以解决的问题，不应全部交给模型参数。

第四，问题是知识不足，还是行为不稳定？知识不足优先使用RAG，行为不稳定才考虑微调。

第五，是否有高质量训练数据和评估集？微调不是把历史数据全部投入训练，而是选择能够清晰表达正确行为的代表性样本。

基础模型决定能力上限，RAG提供实时知识，Harness保证流程可靠，微调固化业务行为。

状态感知 State-Aware Runtime

Harness 解决的是静态问题-“Agent 的外围系统由哪些组件构成”

动态问题：“这些组件，如何共同维护一个长期稳定、可审计、可回滚、可恢复的运行状态？”

把 Agent 的每一步执行都建模为可验证的状态转移，系统必须知道当前状态是什么，哪些动作只是候选，哪些动作已经提交，哪些状态可以回滚，哪些失败需要隔离或交给人类处理。在一个长程 Agent 中，真正的核心是高频的状态转移。每一次的运转，绝不仅仅是生成下一个 Token。

在这个执行流中，最可怕的不是模型输出了错误答案，而是系统根本不知道当前处于什么状态。

哪些事实是不可篡改的常识？哪些只是临时的会话上下文？哪些动作已经被永久写入了数据库？错误发生后，系统应该把状态指针回退到哪一个安全的存档点？如果缺乏显式的状态管理，Agent 充其量只是一个看起来极其聪明，但内部状态早已相互冲突的文本生成器。

长上下文绝对不等于长期状态管理。

在 Runtime 里，错误状态被提交才是致命错误，传统评测大模型（如 MMLU）只看最终答案：答对即成功，答错即失败。但评估 Agent 时这种思路完全失效。Agent 的失败是在过程中发酵的，具有极强的级联传播特性。

关注长程 LLM Agent 中的状态保持、程序遵循、过程审计、门控与回滚机制，并将其理解为 State-Aware Runtime 问题，而不是单纯的 Prompt Engineering 或 Memory Augmentation 。

参考：

一篇Harness研究后的思考！

现在大模型这么强，为什么还要微调？