Harness Engineering的本质：让模型真正成为Agent

一、一条看似绝对的判断，划出了系统的边界

“你不是模型，那你就是 Harness。”

这句话初听有些武断，但拆开来看，它其实精确地划出了一条系统边界：在智能体（Agent）系统里，除了模型本身，其余的一切都属于 Harness——系统提示词、工具调用框架、文件系统、沙箱环境、编排逻辑、钩子与中间件、反馈回路、约束机制。

为什么这条边界如此重要？因为模型只是能力的来源，而能力不等于产出。一个本质上是“文本进、文本出”的函数，无论参数规模多大、推理多强，都无法自己维持状态、无法真正行动、无法感知外部世界的实时变化，更无法判断自己做得对不对。只有当 Harness 把状态、工具、反馈和约束串成一条完整链路，模型才能从“会答题的头脑”进化为“能干活的 Agent”。

业界在解剖 Agent 系统结构时，有一种被广泛认可的切分方法：先明确模型负责什么，再推演系统需要补齐什么，用这条线把整个系统一分为二。线内是模型，线外的全部工程，就是 Harness Engineering。

二、一个类比：模型是 CPU，Harness 是操作系统

理解 Harness 最直观的方式，是回到计算机体系结构里那个经典类比：

• 模型 ≈ CPU：提供原始算力与指令执行能力；
• Harness ≈ 操作系统：负责调度、资源管理、系统调用、进程隔离与异常处理。

CPU 再强，操作系统拉胯也白搭。给一台机器装上最新款的高性能芯片，如果系统频繁崩溃、调度混乱、驱动缺失，实际体验反而不如老芯片配一套稳定成熟的操作系统。模型与 Harness 的关系正是如此。

这个类比还可以继续往下推：

操作系统的职责	Harness 的对应职责
进程调度与生命周期管理	任务编排与多步执行的状态推进
系统调用接口	工具调用框架
文件系统与内存管理	上下文管理与记忆系统
权限模型与进程隔离	执行沙箱与权限约束
异常处理与看门狗	错误检测、重试、回滚与故障恢复

操作系统的价值，不在于替 CPU“算得更快”，而在于让算力可以被安全、稳定、可组合地使用。Harness 的价值同理：它不提升模型的智能密度，而是让模型的智能能够被可靠地兑现。

三、三层嵌套：Prompt、Context 与 Harness Engineering

围绕大模型的工程实践，通常可以概括为三个层次。需要强调的是，三者不是并列关系，而是嵌套关系——外层包着内层，且每一层解决的是完全不同的问题。

层次	核心问题	关注点	典型手段
Prompt Engineering	表达：怎么把指令写好	塑造局部概率空间，让模型听懂意图	系统提示词设计、少样本示例、思维链引导
Context Engineering	信息：给 Agent 看什么	在合适时机拿到正确且必要的事实信息	上下文管理、检索增强生成（RAG）、记忆注入、Token 预算优化
Harness Engineering	执行：整个系统怎么持续运转	长链路任务中的持续正确、偏差纠正、故障恢复	文件系统、沙箱、约束执行、熵管理、反馈回路

三者的重要性随任务形态动态变化：

• 简单任务里，提示词最重要。 问答、改写、摘要这类单轮任务，把话说清楚基本就赢了。
• 依赖外部知识的任务里，上下文很关键。 信息喂错了，模型再强也会一本正经地出错；检索的质量、注入的时机、Token 的取舍，直接决定输出质量。
• 但在长链路、可执行、低容错的真实商业场景里，Harness 才是决定成败的东西。 一个要跑几十步、要操作真实系统、错一步就有真实代价的任务，单次生成的质量再高也撑不住整条链路——真正决定成败的是执行层的工程能力。

这也解释了一个现象：真正把 Agent 推向生产环境的一线团队，重心几乎都压在 Harness 上。

四、反推法：从“模型做不到什么”理解 Harness

理解 Harness 最好的方式，不是罗列它包含什么，而是反过来问：模型做不到什么？无论模型看起来多能干，它的本质始终是一个函数——文本（或图像、音频）进，文本出。这个本质决定了四条硬边界，每一条边界都对应 Harness 的一类补位机制。

1. 模型无状态：记不住历史 → 记忆系统

模型自身不保存任何东西，上一次调用结束，一切归零。所谓“多轮对话能力”，其实是 Harness 在每次请求前，把历史记录重新组织后拼进上下文再喂给模型。工程上至少要处理三件事：

• 会话内记忆：对话历史的裁剪、压缩与摘要，防止上下文窗口被撑爆，同时保住关键信息；
• 跨会话记忆：把重要事实持久化到外部存储，需要时检索注入，让 Agent 拥有“长期记忆”；
• 记忆治理：区分用户偏好、任务状态、系统约定等不同性质的信息，防止过期或错误的记忆污染后续决策。

2. 模型无行动力：跑不了代码 → 受控执行环境

模型可以“写出”一段完美的代码，但它自己无法运行。执行能力必须由 Harness 提供：命令行环境、代码执行器、文件读写能力，以及包裹这一切的沙箱。关键工程点包括：

• 隔离性：所有执行动作发生在受限环境中，限制文件访问范围、网络出口、资源配额与执行时长；
• 最小权限：默认拒绝一切危险操作，按需逐项放行；
• 可审计：每一次执行都留有日志，可回放、可追溯。

3. 模型无实时感知：知识停留在训练时刻 → 外部知识获取

模型的参数是训练完成那一刻的快照。新发布的库版本、刚变更的接口规范、今天的行业动态、企业内部的私有文档——它一概不知。Harness 需要为它搭建信息通道：

• 搜索工具：获取实时、公开的信息；
• 标准化工具调用协议：把数据库、内部服务、外部 API 以统一、可控的方式暴露给模型；
• 私有知识检索管线：对企业文档做切分、索引与召回，并控制注入上下文的信息质量。

4. 模型无法自证正确：会自信地犯错 → 验证闭环

这是最容易被忽视、也最致命的一条。模型生成的结果，模型自己无法可靠判断对错——它会自信地犯错，并且如果没有外部校正，错误会在后续步骤里被不断放大。Harness 必须构建独立于模型的验证闭环：

• 自动化测试：代码类任务必须跑测试、看断言结果，而不是看模型“觉得”对不对；
• 沙箱内预演：先在隔离环境里执行一遍，观察副作用，再决定是否应用到真实环境；
• 结构化校验：对输出做格式与语义校验，对关键事实做交叉核对；
• 人工卡点：高风险操作（如删除数据、对外发布）前强制人工确认。

验证闭环的意义在于把“生成”与“验收”解耦：系统的正确性不依赖模型的自评，而依赖独立的、可设计的验证机制。

模型的硬边界	Harness 的补位机制	核心组件
无状态，记不住历史	维护并注入对话历史	记忆系统
无行动力，不能执行	提供命令行与代码执行环境	沙箱与执行环境
无实时感知	搜索与标准化工具接入	外部知识获取
无法自证正确	独立验证与纠偏	验证闭环

五、Harness 的骨架：一个极简主循环

把上述组件拼装起来，一个 Agent 系统的核心循环大致长这样（示意代码，非真实接口）：

# Agent 主循环骨架（示意）
while not task.finished:
    observation = env.collect_state()               # 状态采集：文件、日志、环境
    context     = ctx.build(history, observation)   # 上下文工程：筛选、压缩、注入
    action      = model.decide(context)             # 模型：单步决策
    result      = sandbox.run(action)               # 沙箱执行：隔离、限时、限额
    feedback    = verifier.check(result)            # 验证闭环：测试、断言、校验
    if not feedback.ok:
        env.rollback_or_replan(feedback)            # 纠偏：回滚、重试、修正计划
    history.append(action, result, feedback)        # 状态推进

这个循环里有几个值得展开的工程细节：

1. 熵管理。 长链路任务中，小错误会累积、放大。Harness 需要设计“负熵”机制：定期校验中间状态、设置检查点、支持回滚到最近的正确状态，而不是让错误像滚雪球一样传播到终点。
2. 偏差纠正。 当模型偏离计划——比如反复尝试同一条注定失败的路径——Harness 要能识别并干预：注入纠偏提示、调整策略，必要时升级为人工介入。
3. 可观测性与量化。 每一步的决策依据、工具调用、执行结果、验证结论都要落日志、落指标。没有度量就没有优化，“感觉它变强了”不是工程结论。
4. 钩子与中间件。 在模型调用前后插入系统级逻辑：调用前做输入合法性检查与敏感操作拦截，调用后做结果审计与格式规整，让安全与合规约束不依赖模型的“自觉”。

六、落地建议：从切分线开始

如果要在真实业务中实践 Harness Engineering，建议从三个动作入手：

1. 画出切分线。 把任务链路上的每个环节逐项标注“这是模型做的”还是“这是系统做的”。凡是模型做不到的——状态、执行、感知、验证——都必须有明确的系统组件承接，不能靠“模型应该能想到”来赌。
2. 先建验证闭环，再扩能力。 宁可先让 Agent 只会做三种被充分验证过的操作，也不要一上来开放十种无法验收的权限。可靠性是能力的乘数：验证跟不上的能力，在生产环境里等于负资产。
3. 复用成熟基础设施，聚焦业务特有部分。 沙箱可以依托容器类服务构建隔离执行环境，记忆与状态可以落在数据库和对象存储上，日志与指标可以接入日志服务和监控告警体系，模型推理可以由成熟的模型服务平台托管。这类基础设施在主流云平台均有成熟供给——例如百度智能云的容器服务、对象存储、日志服务、监控告警等通用产品类目，都可以直接复用。工程团队真正需要自行设计的，是编排逻辑、约束机制与验证闭环这些与业务强相关的部分。

七、结语：模型决定上限，Harness 决定下限

回到最初的问题：Harness Engineering 的本质是什么？

它本质上是一门把“不可靠的单次文本生成”工程化为“可靠的持续行为”的系统学科。模型提供能力密度，Harness 决定这些能力能否在真实世界中被安全、稳定、可验证地兑现。

一句话总结：模型决定系统的上限，Harness 决定系统的下限。而在生产环境中，决定生死的，往往是下限。