从提示词到执行编排：Harness Engineering的本质解析

一、三次工程重心的迁移

大模型应用的发展，实质上是一条“工程重心不断外移”的演进路径。可以粗略划分为三个阶段：

第一阶段：Prompt Engineering。 核心问题是“模型能不能听懂”。工程手段集中在指令措辞、示例设计、输出格式约束上。这一阶段的产出物是“一段好用的提示词”，它的边界很清晰：一次交互、一个任务、一个回合。

第二阶段：Context Engineering。 核心问题变成“模型知不知道该用什么信息”。当任务需要外部知识、历史对话、结构化数据时，单纯优化措辞已经不够，工程重心转向上下文的检索、裁剪、组织与注入。这一阶段的产出物是“一套上下文供给策略”。

第三阶段：Harness Engineering。 核心问题是“模型能不能稳定做对一连串的事”。当任务从单轮问答变成多步骤执行——需要调用工具、需要跨步骤保持状态、需要在中途失败后恢复——问题的性质就变了：它不再是“单点智能”问题，而是“系统可靠性”问题。

理解这三阶段的差异，可以用一句话概括：前两个阶段在优化“模型这一次的输出质量”，第三个阶段在优化“系统在一段执行过程中的整体成功率”。前者是概率问题，后者是工程问题。

Harness 一词本意是“束带、挽具”，引申为“约束并引导力量的结构”。这个词的选择很准确：它不是替模型思考，而是给模型的行动套上一副可控制、可观测、可回退的骨架。

二、Harness 的本质：把不确定性关进流程

要理解 Harness Engineering 的本质，先要承认一个前提：模型在单步决策上是概率性的，在多步串联中误差会累积。若不加以约束，一个 95% 单步成功率的环节，串联十步后整体成功率会降到约 60%。步骤越多，衰减越明显。

Harness 要解决的就是这个衰减问题。它的本质可以归纳为三层含义：

其一，职责分离。 把“决策”和“执行”分开。模型负责在有限选项内做判断，Harness 负责判断的边界、执行的方式、结果的校验。模型不需要知道工具如何鉴权、失败如何重试、状态存在哪里——这些由 Harness 承担。

其二，状态外置。 把执行过程中的中间结果、已完成的步骤、待办事项从模型的上下文窗口中抽离出来，放到显式的状态结构里。模型每次只需看到“当前该看的那一部分”，而不是把全部历史反复灌入。

其三，可控可退。 每一个动作都有前置校验与后置校验，每一次失败都有明确的恢复路径。系统不是“尽力而为”，而是“要么成功，要么停在已知的、可恢复的状态上”。

用一段示意性的伪代码可以更直观地表达这种分层：

# 模型侧：只做局部决策
decision = model.decide(
    goal=current_subgoal,
    observation=state.visible_view(),   # 由 Harness 裁剪后的视图
    available_tools=tool_registry.names()
)
# Harness 侧：承担边界、执行、校验与恢复
validated = guard.validate(decision, state)          # 约束校验
result = executor.run(validated, sandbox=env)        # 可控调用
state.commit(result)                                 # 状态落盘
if not checker.accept(result):
    state.rollback(); planner.replan(state)          # 失败恢复

这段代码体现的核心思想是：模型始终在一个被收窄的决策空间里工作，而 Harness 负责把这个局部决策安全地接入到全局流程中。

三、Harness 的六层结构

把 Harness 拆开看，它并不是一个单一模块，而是六个相互配合的层次。以下逐层展开。

第一层：上下文的精细化管理

这一层解决“模型此刻应该看到什么”。与 Context Engineering 的区别在于：后者关注“如何组织一次上下文”，前者关注“在长流程中，上下文如何随步骤演进而动态变化”。

关键设计点包括：

• 视图裁剪：每一步只暴露与当前子目标相关的上下文片段，避免无关历史稀释注意力。
• 结构化注入：把检索结果、工具返回值、状态摘要按固定 schema 组织，而非拼接成自由文本。
• 预算控制：为不同来源的上下文分配 token 预算，超限时按优先级舍弃，保证关键信息不被挤掉。
• 去噪与压缩：对长历史做摘要与要点提取，保留决策相关的因果链，丢弃冗余细节。

这一层的工程价值在于：它把“上下文”从一个静态输入变成了一个随执行推进而演化的动态视图。

第二层：工具系统的可控调用

这一层解决“模型能做什么、以什么方式做”。工具是模型作用于外部世界的唯一通道，因此也是最需要约束的地方。

关键设计点包括：

• 能力注册与描述规范化：每个工具都有明确的输入 schema、输出 schema、副作用说明与幂等性标注。描述不清的工具等同于不可用工具。
• 参数校验：在调用前对模型产出的参数做类型、范围、必填项校验，拒绝不合法的调用而不是让它带着错误参数进入执行。
• 权限与沙箱：按最小权限原则授予工具访问范围，高风险操作在隔离环境中执行。
• 幂等与去重：对有副作用的操作设计幂等键，避免重试导致重复写入。
• 超时与限流：为每次调用设定时间与频率上限，防止单点阻塞拖垮整条链路。

这一层的核心原则是：把“模型想调用什么”和“系统允许调用什么”分开，中间隔一道可编程的闸门。

第三层：任务执行的全局编排

这一层解决“多个步骤如何组织成一条可靠的执行链”。它对应的是流程控制，而不是单步决策。

关键设计点包括：

• 任务分解与依赖图：把目标拆成子任务，显式表达依赖关系与可并行部分，而不是让模型在自然语言里隐式维护顺序。
• 控制流模式：支持顺序、分支、循环、并行、汇合等基本模式，并为每种模式定义明确的终止条件，防止无限循环。
• 检查点：在关键节点保存执行快照，使流程可以从中间状态重启。
• 动态重规划：当某一步的结果偏离预期时，触发局部重规划，而不是让整条链从头再来。

这一层是 Harness 的“骨架”。没有它，工具调用只是一盘散沙；有了它，多步执行才具备可推理的结构。

第四层：记忆与状态的分层管理

这一层解决“跨步骤、跨会话的信息如何保存与取用”。它与第一层互补：第一层管“看什么”，这一层管“存什么”。

常见的分层方式：

• 工作记忆：当前任务内的短期状态，随任务结束而释放。
• 会话记忆：跨多轮交互的上下文，需要摘要与衰减策略。
• 长期记忆：跨会话可复用的知识、偏好与历史结论，需要写入、检索、更新与淘汰机制。
• 事实状态：结构化的执行结果与系统状态，强调一致性与可查询，而非语义检索。

分层的意义在于：不同性质的信息有不同的生命周期与访问模式，混在一起管理会导致要么检索不准，要么存储膨胀。

第五层：独立的评估与观测体系

这一层解决“怎么知道做得好不好”。关键在于“独立”：评估不能依赖执行路径自身的自述，而要有外部可验证的信号。

关键设计点包括：

• 过程观测：记录每一步的输入、决策、工具调用、返回值与耗时，形成可回溯的执行轨迹。
• 结果校验：用规则校验、单元测试式断言、交叉验证等方式判断产出是否满足要求，而非仅凭模型自评。
• 指标定义：单步成功率、端到端成功率、平均步数、失败恢复率、成本与延迟，都是可量化的观测对象。
• 离线回归：把真实执行轨迹沉淀为评测集，在变更后做回归对比，防止优化一处、退化另一处。

这一层是整个 Harness 的“仪表盘”。没有观测，前四层的设计好坏无从判断；有了观测，调优才有依据。

第六层：约束校验与失败恢复机制

这一层解决“出错时怎么办”。它是可靠性的最后一道防线，也是 Harness 区别于普通编排框架的关键。

关键设计点包括：

• 前置约束：在执行前校验决策是否满足业务规则、安全策略与资源限制。
• 后置校验：对执行结果做正确性、完整性、一致性检查，不通过则视为失败。
• 失败分类：区分可重试失败（超时、瞬时错误）、可修复失败（参数错误、缺失信息）与不可恢复失败（权限拒绝、目标不可达），分别对应不同处理策略。
• 重试与退避：对可重试失败采用指数退避，并设定上限，避免放大故障。
• 回滚与补偿：对有副作用的操作设计补偿动作，保证失败后系统回到一致状态。
• 降级与兜底：在无法恢复时给出明确的降级路径或人工介入点，而不是静默失败。

这一层的设计哲学是：把失败当作一等公民来设计，而不是事后补救。

四、六层之间的关系

这六层不是并列的清单，而是有依赖关系的整体：

• 上下文管理与记忆管理共同构成“信息面”，决定模型看到什么、记住什么。
• 工具调用与任务编排共同构成“行动面”，决定模型能做什么、按什么顺序做。
• 评估观测与约束恢复共同构成“保障面”，决定系统如何被度量、如何从错误中恢复。

信息面供给决策，行动面执行决策，保障面校验并兜住决策的偏差。三者形成闭环，缺一层都会导致系统性脆弱：缺信息面则决策失焦，缺行动面则无法落地，缺保障面则错误无法收敛。

五、实践中的几条设计原则

1. 先显式化，再自动化。 把状态、依赖、约束先写成显式结构，再考虑让模型自由发挥。隐式的东西一旦出错，几乎无法定位。
2. 每一步都要可观测。 不可观测的步骤等于不可调试的步骤，也等于不可优化的步骤。
3. 失败路径优先设计。 在写正常路径之前，先想清楚失败如何分类、如何重试、如何回滚。
4. 模型只做它擅长的事。 让模型做判断与生成，把确定性计算、状态维护、权限控制交给代码。
5. 评估独立于执行。 用外部信号而非模型自述来判断正确性，否则观测体系会失去意义。
6. 控制决策空间。 给模型的选项越收敛，输出越稳定；开放式决策只应出现在确实需要创造性的环节。

六、小结

Harness Engineering 的本质，不是让模型更聪明，而是让系统更可靠。它承认模型在长链条执行中的不确定性，并用六层结构把这部分不确定性约束在可管理、可观测、可恢复的范围内。

从 Prompt Engineering 到 Context Engineering，工程优化的是“一次交互的质量”；到了 Harness Engineering，工程优化的是“一段执行的确定性”。这是一次从“提示词工艺”到“系统工程”的跃迁——也正是智能体从演示走向生产所必须跨过的那道门槛。