AI Harness Engineering：从概念、场景到落地方法

给不可控的 LLM，加上一套可测试、可控制、可回滚、可持续优化的工程系统。

一、引言：为什么企业需要 AI Harness

过去很多 AI 应用的实现方式都很直接：用户输入问题，系统拼接 Prompt，调用模型，返回结果。这个模式适合原型验证，也适合低风险场景，但一旦进入真实业务，就会迅速暴露出一系列问题：

输出质量不稳定
幻觉与越权风险难以控制
工具调用过程不可观测
出错后难以回滚与复盘
Prompt 调整缺乏统一管理
线上效果无法通过数据持续优化

问题的根源不在于模型不够强，而在于企业真正缺的不是一个"会生成内容的模型接口"，而是一套能把模型纳入生产流程的工程系统。

这套系统，就是 AI Harness。

为了把这个概念讲清楚，本文会沿着一条清晰主线展开：先说明 AI Harness 到底是什么，再拆解它的系统分层与运行主链路，然后落到典型业务场景、数据底座和企业实施路径，最后总结设计原则。这样就能把"概念"自然推导到"场景"和"落地"，而不是停留在抽象定义上。

二、概念：什么是 AI Harness

如果用一句话定义：

AI Harness Engineering 是围绕大模型构建一整套运行时与治理体系，让模型输出在企业场景中变得可控、可审计、可迭代。

需要先说明一点：AI Harness Engineering 不是本文临时提出的说法，而是近一两年已经出现在 OpenAI、Anthropic 等公司的公开工程文章中的行业术语。本文的工作不是"发明这个概念"，而是结合你提供的架构材料，把这一术语放回企业系统设计语境中，整理成一套更完整的架构表述。

它不是单纯的 Prompt 管理，也不是简单的 Agent 编排，而是站在系统工程的角度，解决以下问题：

请求如何进入系统
Prompt 如何生成、版本化和管理
模型和工具如何被动态调度
输出如何经过质量与风险评估
高风险任务如何进入人工确认
整个过程如何被记录、追踪和分析
系统如何基于反馈持续优化

图 1：从 Prompt 到 Harness

flowchart LR P[Prompt Engineering\n关注如何写指令] --> C[Context Engineering\n关注给模型什么上下文] C --> H[Harness Engineering\n关注模型外层的执行系统] H --> R[Production AI System\n可控制可治理可优化]

这三者的关系可以概括为：

Prompt Engineering 解决"怎么说"
Context Engineering 解决"给什么信息"
Harness Engineering 解决"如何让模型可靠做事"

如果说前两者主要关注模型输入，那么 Harness Engineering 关注的就是模型运行时的外层系统。理解了这个差异后，下一步就不能只看"提示词怎么写"，而要看一套企业级 AI 系统究竟由哪些层组成。

三、架构总览：AI Harness 的系统分层

从架构上看，AI Harness 不是单层能力，而是一套自上而下的企业级分层系统。它既包含前台的请求入口，也包含中间的编排、执行与控制层，还包含后端的可观测、反馈与数据底座。

图 2：AI Harness 总体架构

flowchart TB U[用户 / 客户端\nApp API CLI UI] --> G[API 网关层\n鉴权限流路由统一入口] G --> O[AI 编排调度层] subgraph O[AI 编排调度层] P[Prompt 引擎\n模板变量版本] A[Agent 编排器\n多 Agent 调度] T[工具路由\nTool 调用链] M[模型路由\n多模型选择策略] end O --> L1[模型层\nClaude GPT TongYi DeepSeek 开源模型] O --> L2[工具层\n搜索数据库 API 外部服务插件] L1 --> E[评估与安全控制层] L2 --> E subgraph E[评估与安全控制层] Q[质量评分\n准确性一致性幻觉] S[安全过滤\n敏感内容越权检测] R[策略引擎\n规则判断风险评分阈值控制] F[回退机制\n重试 Fallback 回滚] end E --> D{风险是否可自动放行} D -->|低风险| X[执行结果处理层\n统一输出] D -->|高风险 / 不确定| H[人工确认层 HITL\n审核通过拒绝修改审计] H --> X X --> V[可观测层\n日志指标 Tracing] V --> B[反馈与优化层\n用户反馈人工标注 Prompt 优化 A/B 测试] B --> DL[数据层\nPrompt 仓库 Evaluation Dataset 日志指标存储] DL -.支撑下一轮执行.- O

这张图体现了 AI Harness 的核心思路：模型推理只是执行链路中的一个环节，真正决定系统能否落地的是执行前后的控制、分流、记录和优化机制。

不过，分层图只能回答"系统由什么组成"，还不能回答"这些模块如何协同工作"。因此，下面先按层解释每个模块的职责，再进一步看一条请求如何穿过整套系统。

四、分层解析：每一层到底负责什么

从静态结构上看，AI Harness 可以理解为"入口层、编排层、执行层、控制层、反馈层、数据层"的逐层展开。只有先看清每一层负责什么，后面才容易理解它们为什么必须连成闭环。

1. 统一入口层：收敛请求与系统边界

最上层是用户请求入口，可以来自 App、内部系统、开放 API 或 CLI 工具。请求进入后，先经过统一网关，完成：

身份鉴权
访问控制
频率限制
请求路由
租户或环境隔离

这一层的作用不是"智能"，而是先把 AI 能力纳入企业已有系统边界。

2. AI 编排调度层：把请求变成可执行任务

编排层是整个系统的大脑，负责把用户请求翻译成一条可执行链路。通常包含四类能力：

Prompt 引擎：根据场景、变量和版本生成最终 Prompt
模型路由：根据任务特性选择模型，如低成本模型、长上下文模型或高质量模型
工具路由：决定是否调用数据库、搜索、知识库、业务 API 或插件
Agent 编排器：复杂任务下支持多 Agent 分工与串并行执行

这一层解决的不是"让模型回答"，而是"怎么组织模型去做事"。

3. 模型层与工具层：执行实际推理与外部动作

模型层负责理解、推理、生成和判断；工具层负责访问真实世界中的外部资源。

典型工具包括：

搜索与检索服务
数据库查询
业务 API
插件系统
文件或知识库访问

当模型和工具组合后，AI 系统才从"文本生成器"变成"任务执行器"。

4. 评估与安全控制层：先判断，再放行

这一层是 AI Harness 的关键控制点。在进入业务主流程、自动执行链路或高风险场景时，模型产出的结果不应被直接视为最终结果，而应先作为候选结果进入质量与风险控制，再决定是否正式交付。

这里通常包括四类机制：

质量评分：判断准确性、一致性、完整性、幻觉概率
安全过滤：识别敏感内容、越权访问、违规输出
策略引擎：按规则和阈值计算风险，决定是否放行
回退机制：在失败或高风险时执行重试、降级、Fallback 或回滚

这一层决定系统是否具备生产可控性。

5. 人工确认层：Human in the Loop

对于高风险或不确定结果，系统不会自动返回，而是进入人工确认流程，即 HITL。

人工确认层通常包含：

审核队列
审核工作台
通过、拒绝、修改等动作
审批角色与权限控制
全量审计日志

这并不意味着系统自动化程度低，而是说明系统对风险有清晰边界。对于客服答复、审批意见、合规问答、经营分析等场景，这一层往往是必须存在的。

6. 结果处理层：统一出口与回退机制

无论结果来自自动放行还是人工确认，最终都进入统一结果处理层。它负责：

输出给终端用户
回写下游系统
触发后续业务动作
在异常时执行回退或回滚

它是 AI Harness 的统一出口。

7. 可观测层、反馈层与数据层：形成闭环

一套成熟的 AI 系统必须像现代软件系统一样具备可观测性，而且这种可观测性不是在结果输出后"补记一笔"，而是贯穿 Prompt 生成、模型调用、工具调用、评估决策、人工审核和结果返回的全过程。这里至少要采集三类数据：

日志：输入、输出、中间过程、工具调用、决策结果
指标：延迟、成本、成功率、审核率、Fallback 率
链路：一次请求在整个系统中的完整执行轨迹

在这些数据之上，系统再进一步建设反馈与优化能力，例如：

用户反馈
人工标注
Prompt 优化
自动调参
A/B 实验
评测回归

最终，这些数据沉淀到底层数据层，成为下一轮执行和优化的基础。至此，系统的静态结构已经完整了，接下来需要把这些模块串起来，看一条请求是如何在运行时依次经过这些层的。

五、主链路：一条请求在系统里如何流动

图 3：AI Harness 执行主流程

flowchart TD A[用户请求] --> B[Prompt 生成] B --> C[模型推理 + 工具调用] C --> D[输出评分\n质量 + 风险] D --> E{分流判断} E -->|低风险| F[直接返回] E -->|高风险| G[进入人工审核] G --> H[通过 / 修改 / 拒绝] H --> I[最终输出] F --> I I --> K[进入反馈优化系统] O[贯穿式日志 / 指标 / Trace] -.覆盖.- B O -.覆盖.- C O -.覆盖.- D O -.覆盖.- G O -.覆盖.- I

这条主链路说明，AI Harness 的核心不是"一次模型调用"，而是：

执行 -> 评估 -> 分流 -> 输出 -> 记录 -> 优化

这是一条完整的生产链，而不是一次性推理调用。同时，可观测能力并不位于链路末端，而是贯穿执行、评估、分流和输出的全过程。

理解这条链路之后，接下来的问题就变成：哪些业务真的值得为此付出系统复杂度？换句话说，什么样的场景应该从"调用模型"升级到"建设 Harness"？

六、典型场景：什么样的业务必须用 Harness

并不是所有 AI 应用都需要完整的 Harness。对于一次性、低风险、低成本的问答任务，直接调用模型往往已经足够。只有当任务开始进入业务主流程，或者对准确性、风险控制、审计和持续优化提出更高要求时，Harness 的价值才会真正体现出来。

1. 企业知识问答与智能客服

如果系统只做简单闲聊，直接调用模型即可；但一旦涉及知识库、权限、回答一致性和品牌风险，就需要 Harness：

结合知识库或检索服务生成答案
对回答进行事实性评估
对敏感问题触发升级处理
对高风险回复转人工审核

2. Text-to-SQL 与数据分析助手

这类系统往往需要让模型理解业务语义、调用数据库、生成 SQL，并把结果转成业务语言。如果没有 Harness，风险会非常高：

SQL 可能错误
查询可能越权
解释可能出现幻觉
成本可能不可控

通过 Harness，可以加入查询前校验、输出后评分、人工复核和全链路追踪。

3. 企业流程自动化

例如：

工单归类
邮件分发
报告生成
审批建议草拟
风险摘要生成

这些任务本质上都不是简单的文本输出，而是业务流程中的一个节点。只有进入可评分、可分流、可回滚的 Harness，AI 才能真正融入流程。

4. Agent 类应用

只要 AI 需要调用工具、访问系统、执行多步骤动作，就已经进入 Agent 场景。此时真正的难点从"能不能做"转成"做错了如何治理"。

Agent 应用天然需要 Harness，尤其适用于：

研发辅助 Agent
BI 分析 Agent
运营数据 Agent
内部知识搜索 Agent
跨系统任务执行 Agent

5. 高合规与高风险场景

金融、法务、医疗、政务等场景对输出的准确性、合规性和审计能力要求极高。在这些场景里，评估 + 分流 + HITL + 审计 不是加分项，而是必选项。

七、数据底座：系统为什么必须有 Prompt、Evaluation、Run Log、Metrics

前面讨论的是"在哪些场景需要 Harness"。但要把这些场景真正跑稳，单靠流程编排还不够，还必须有稳定的数据底座。因为没有数据沉淀，系统就无法评估质量、追踪过程，更谈不上持续优化。这里的数据底座不一定一开始就做得很重，但至少要从最小闭环阶段就具备基础日志、关键指标和可追踪的 Prompt 版本。

图中的另一个核心信息，是数据闭环。可以把 AI Harness 的底层数据资产抽象成四类：

Prompt Registry：管理规则
Evaluation Dataset：管理质量
Run Log：记录过程
Metrics Aggregated：管理整体状态

图 4：AI Harness 的数据闭环

flowchart LR PR[Prompt Registry\n版本模板变量适用场景] --> EX[执行系统] ED[Evaluation Dataset\n样本标注评分维度] --> EX EX --> RL[Run Log\n请求链路模型调用工具调用人工审核] RL --> MT[Metrics\n成本延迟成功率风险率] RL --> FB[分析与反馈] MT --> FB FB --> OP[Prompt 优化 / 阈值调整 / A-B 测试] OP --> PR FB --> ED

这四类数据分别回答四个不同的问题：

Prompt 告诉系统"应该怎么做"
Evaluation 告诉系统"做得好不好"
Run Log 告诉系统"实际发生了什么"
Metrics 告诉系统"整体运行得怎么样"

少了其中任何一个，系统都很难形成真正的工程闭环。也正因为如此，企业在实施 Harness 时，不能只做前台调用链，还必须同步建设 Prompt、评测、日志和指标这几类基础设施。

一个典型的 trace 上下文对象

为了支持链路追踪，系统通常要为每次请求维护统一上下文对象，例如：

json 复制代码

{
  "trace_id": "uuid",
  "user_id": "u123",
  "session_id": "s456",
  "model": "claude",
  "prompt_version": "v3",
  "cost_limit": 1.0
}

在此基础上，每一层写入 trace 事件：

PromptStart
ModelRequest
ToolCall
ToolResponse
EvalResult
HumanReview
FinalOutput

这让一次请求从入口到输出的每一步都可以被回放和分析。

八、落地方法：企业应该如何分阶段建设

当概念、架构、主链路、适用场景和数据底座都明确后，落地路径就会清晰很多。企业真正要回答的问题，不再是"要不要做 AI"，而是"先从哪一类任务切入，再用什么顺序把 Harness 搭起来"。

AI Harness 不适合一上来就做成"大而全平台"。更务实的做法是围绕一类高价值任务，分阶段建立最小闭环。

阶段 1：先定义任务边界和风险边界

先选定一个具体场景，例如智能客服、报告生成、Text-to-SQL 或审批辅助，并明确：

输入是什么
输出是什么
成功标准是什么
哪些结果允许自动通过
哪些结果必须进人工审核
主要风险点是什么

不要先做平台，再找场景；应该先找场景，再抽象平台。

阶段 2：搭建最小可用链路

先实现最核心的一条闭环：

统一入口
Prompt 模板和版本管理
单模型调用
最小工具集
基础评分机制
低风险自动通过
高风险转人工
基础日志、Trace 和关键指标
Prompt 版本记录

一开始最重要的不是能力多，而是链路完整。

阶段 3：补齐评估、策略与人工审核

很多团队最大的缺口在这里：有生成，没有判断；有自动化，没有治理。

这一阶段要补齐：

质量评分标准
风险判定规则
阈值与分流机制
人工审核工作台
审计日志

只有做到这一层，系统才真正具备上线能力。

阶段 4：完善可观测与数据底座

在最小闭环已经具备基础观测能力的前提下，这一阶段要把数据底座从"能记录"升级为"能分析、能优化"，重点补齐以下基础设施：

Run Log
指标聚合
调用链 Tracing
Prompt Registry
Evaluation Dataset

因为没有数据底座，后续所有优化都只能凭经验进行。

阶段 5：进入反馈驱动的持续优化

最后才是"把 AI 变得更好"的阶段。这个阶段主要做三件事：

根据线上数据分析失败模式
根据评测结果优化 Prompt 和路由策略
通过 A/B 测试和自动调参迭代版本

图 5：企业落地路线图

flowchart LR A[定义场景与风险] --> B[搭建最小闭环] B --> C[补齐评估与 HITL] C --> D[完善可观测与数据底座] D --> E[进入反馈驱动优化]

九、设计原则：做 Harness 时最重要的五条原则

落地路径解决的是"先做什么、后做什么"，设计原则解决的是"做的时候不要走偏"。下面这五条原则，可以理解为建设 AI Harness 时最容易被忽略、但又最影响成败的共性约束。

1. 不要把 Harness 误解成 Prompt 系统

Prompt 很重要，但它只是其中一层。真正的 Harness 必须包含执行控制、风险治理、人工审核和数据闭环。

2. 先做最小闭环，再做复杂编排

不要一开始就引入过多模型、工具和多 Agent 拓扑。复杂度应该只为真实失败模式服务。

3. 进入业务前，输出应先评估

尤其在自动执行链路或高风险场景中，模型输出在进入业务前，应该先经过质量评分和风险判断，而不是直接返回。

4. 高风险任务必须保留人工兜底

人工审核不是系统不成熟，而是系统成熟的表现。它明确了自动化边界。

5. 所有优化都要回到数据闭环

没有 Prompt 版本、评测集、运行日志和指标系统，系统只会陷入反复改 Prompt 的手工试错。

十、结语：Harness 不是模型附加层，而是企业级 AI 的运行底座

回到文章开头，企业真正缺的从来不是"再接一个模型"，而是把模型接入业务之后，如何让它持续、稳定、可控地运行下去。AI Harness Engineering 的真正价值，不是让企业"更会写 Prompt"，而是让企业有能力把模型纳入一套可管理、可治理、可优化的生产系统中。

从这个角度看，企业级 AI 的核心能力不再只是调用模型，而是建设这样一套闭环：

用编排层组织任务
用评估层控制风险
用 HITL 承接高风险场景
用可观测层理解系统运行
用数据层支撑反馈与优化

因此，整篇文章其实围绕的是同一个问题在展开：从概念上，AI Harness 解释了为什么需要模型外层系统；从架构上，它说明系统应该如何分层；从场景上，它说明哪些业务值得引入这套复杂度；从落地方法上，它给出了从最小闭环到持续优化的实施路径。

最终，AI Harness 解决的不是"模型会不会生成"，而是"模型生成的结果能不能进入真实业务"。

这，才是大模型真正落地企业的关键。

从术语来源上看，Harness Engineering / AI Harness Engineering 并不是本文提出的新词，它已经出现在 OpenAI、Anthropic 等公司的公开文章中。更准确地说，它更接近一种正在形成中的行业工程方法论，而不是一个已经被严格学术化定义的独立研究方向。OpenAI 的 Harness engineering: leveraging Codex in an agent-first world ，以及 Anthropic 的 Harness design for long-running application development 、Scaling Managed Agents，都可以视为这一术语在公开语境中的代表性文本；而本文对"工具调用、评估闭环、人工兜底、可观测与数据闭环"的讨论，也主要建立在这些工程实践，以及 tool-using agents、iterative refinement、LLM evaluation、human-in-the-loop 等既有研究基础之上。

AI Harness Engineering：从概念、场景到落地方法