Harness工程就是人类几十年前就有的工程纪律

2026 年初，“Harness Engineering” 突然成为 AI 工程圈的热词。顶会论文、技术博客、框架文档都在反复强调同一个公式：Agent = Model + Harness。斯坦福 IRIS 实验室的对照实验表明，固定模型仅更换 Harness 架构，任务完成率可产生 6 倍 的性能差距。

但如果我们剥开这层新术语的外衣，会发现一个略显讽刺的事实：Harness Engineering 并不是什么新发明，它只是人类过去 60 年积累的工程纪律，在 LLM 时代的一次强制回归。

从 Dijkstra 对 goto 的批判，到 GoF 的设计模式，再到控制理论与 DevOps，Harness 的每一块基石都早已存在。我们之所以觉得它新，只是因为过去两年，太多开发者试图用裸 LLM 调用跳过工程基础，直到系统在生产环境中失控，才被迫重新捡起这些老规矩。

一、Dijkstra 的幽灵：从 goto 到裸 LLM 调用

1968 年，Edsger W. Dijkstra 发表《Go To Statement Considered Harmful》。他的核心论点并非 goto 无法工作，而是：

goto 让程序的控制流无法被人类心智所理解。

你可以用 goto 写出任何逻辑，但当代码变成面条一样的跳转时，没有人能证明它正确，没有人能调试它，没有人能维护它。

半个多世纪后，裸用 LLM 构建 Agent 正在重演同样的控制流灾难：

用户请求 → LLM 自由思考 → 可能调工具 → 可能不调 → 可能死循环 → 可能发散 → ？？？ → 输出

问题不在于模型不够聪明，而在于控制流缺乏结构化约束。

两者的本质缺陷完全相同：控制流缺乏结构化约束。

Dijkstra 的解法不是禁止编程，而是引入 顺序、选择、循环 三大结构化构造。Harness Engineering 做的是同一件事，只是对象从 CPU 指令变成了 LLM 决策：

• if/else 分支 → 验证闸门 (Verification Gates) ：不满足 Schema 或业务规则，绝不流向下游
• while 循环 + 终止条件 → 重试策略 + 最大迭代限制 ：防止成本失控与无限循环
• 函数封装 → 工具编排 (Tool Orchestration) ：隔离副作用，明确输入输出边界

二、GoF 设计模式的 AI 映射：约束即赋能

1994 年，《Design Patterns》出版。GoF 的核心贡献不是 23 个模式，而是三条至今仍在指导架构设计的原则。将它们平移到 AI 系统，恰好解释了为什么 Harness 能带来数量级的稳定性提升。

1. 封装变化 → 封装随机性 (Encapsulate Stochasticity)

传统软件中，变化指需求变更。AI 系统中，最大的变化是 LLM 的概率性输出。同一个 Prompt，模型今天返回 JSON，明天返回纯文本，后天可能直接拒绝回答。

裸用 LLM 将这种不确定性直接暴露给业务逻辑，导致下游解析频繁崩溃。Harness 充当了 适配器 (Adapter) 与 外观 (Facade) ，内部允许模型重试、反思、修正，外部提供确定性接口。

from dataclasses import dataclass
from typing import Protocol, runtime_checkable
import json

@runtime_checkable
class LLMBackend(Protocol):
    def generate(self, prompt: str) -> str: ...

@dataclass
class ExtractionResult:
    age: int
    confidence: float

class DeterministicExtractor:
    """Harness 层：将概率性模型封装为确定性组件"""
    def __init__(self, llm: LLMBackend, max_retries: int = 3) -> None:
        self.llm = llm
        self.max_retries = max_retries

    def extract_age(self, text: str) -> ExtractionResult:
        for attempt in range(self.max_retries):
            raw = self.llm.generate(f"Extract age as JSON: {text}")
            try:
                data = json.loads(raw)
                if "age" in data and isinstance(data["age"], int):
                    return ExtractionResult(age=data["age"], confidence=0.95)
            except (json.JSONDecodeError, TypeError):
                continue
        raise ValueError("Failed to extract valid age after retries")

# generated by hugo AI

2. 组合优于继承 → 编排优于巨型 Prompt

早期 Agent 开发极易陷入 巨型 Prompt (Mega-Prompt) 陷阱：在一个 Prompt 里塞入角色定义、工具说明、约束条件、Few-shot 示例、推理步骤。这就像写了一个几千行的 God Class，牵一发而动全身。

Harness 提倡 组合 (Composition) ：

• Router 模式 ：先意图分类，再路由给垂直子 Agent
• Pipeline 模式 ：拆解为 Summarizer → Translator → Formatter
• Tool Use 模式 ：模型仅负责决策，执行交给外部确定性函数

3. 针对接口编程 → 针对契约编程 (Program to Schema)

在 AI 工程中，实现是具体模型（GPT-4、Claude、Llama），接口是 数据契约 (Schema) 。Harness 强制定义输入输出契约，模型输出不合规则拦截修正。切换底层模型时，只要符合契约，业务代码 一行都不用改。这正是 策略模式 (Strategy Pattern) 的标准实践。

三、控制论底座：为什么 Harness 能带来 6 倍性能差距？

Harness Engineering 的另一个名字，叫 控制工程 (Control Engineering) 。

1940 年代诞生的控制理论核心思想是：通过反馈回路 (Feedback Loop) 让动态系统收敛到目标状态。LLM 本质上是一个高维非线性动态系统，裸调用等于开环控制 (Open-loop)，而 Harness 提供的是闭环控制 (Closed-loop)。

工业案例：LangChain Terminal Bench 优化

LangChain 团队在优化 Terminal Bench Agent 时，并未更换底层模型，而是重构了 Harness 层：

• 增加 上下文组装器 ：动态裁剪无关历史，保持 Context 信噪比
• 引入 验证回路 ：工具执行失败时，自动注入错误堆栈并触发反思重试
• 添加 成本与超时熔断 ：防止单任务吞噬全局预算

结果：任务完成率从 52.8% 提升至 66.5% 。模型没变，变的是控制回路。

斯坦福 IRIS 实验室的进一步消融实验证明，Harness 变量（上下文策略、工具路由逻辑、验证严格度、重试机制）对最终性能的影响权重，远超模型参数量差异。Agent 的瓶颈不在智力，而在控制架构。

四、生产级 Harness 架构解剖

一个成熟的 Harness 不是 Prompt 模板库，而是运行时基础设施。其核心组件可抽象为以下控制流：

                   ┌─────────────────────────────────────┐
                   │          Observability & Cost       │
                   └───────────────▲─────────────────────┘
                                   │ metrics/logs
┌──────────┐   ┌──────────────┐   │   ┌──────────────┐   ┌──────────┐
│  User    │──▶│ Context      │───┼──▶│ Verification │──▶│  Output  │
│  Request │   │ Assembler    │   │   │ Gate         │   │  Schema  │
└──────────┘   └──────▲───────┘   │   └──────▲───────┘   └──────────┘
                      │           │          │ fail
                      │           │   ┌──────┴───────┐
                      └───────────┼───│ Retry /      │
                                  │   │ Reflection   │
                                  │   └──────▲───────┘
                                  │          │
                           ┌──────┴──────────┴──────┐
                           │   LLM + Tool Executor  │
                           └────────────────────────┘

核心模块职责

五、历史的三重奏：为什么我们总在重新发明工程纪律？

新原语（如 LLM）出现时，开发者总会被其表面能力迷惑，误以为旧规则不再适用。直到规模放大、错误累积、成本失控，工程纪律才会以新名字回归。

Harness Engineering = 结构化编程 + 设计模式 + 控制理论 + DevOps

它不限制智能，它让智能可组合、可验证、可维护。正如 Dijkstra 当年所证明的：约束不是枷锁，而是构建复杂系统的唯一路径。

Agent 的上限由模型决定，但 Agent 的下限由 Harness 决定。而生产环境，永远为下限买单。

你在实际落地 Agent 时，是否也经历过从"裸调模型"到"构建 Harness"的转变？欢迎留言讨论。

参考文献

1. The Rise of Harness Engineering: Your Agent Isn’t Broken, Your Harness Is - Medium. https://medium.com/@cdcore/the-rise-of-harness-engineering-your-agent-isnt-broken-your-harness-is-8835ad7394ff
2. What Is Harness Engineering? The Discipline That Makes AI Agents Reliable. https://harness-engineering.ai/blog/what-is-harness-engineering/
3. Harness Engineering Is Now a Formal Discipline: 6 Findings That Change How You Build AI Agents - MindStudio. https://www.mindstudio.ai/blog/harness-engineering-formal-discipline-6-findings-ai-agents/
4. Why Harness Engineering? - beginning-harness. https://thebeginningharness.com/docs/09-harness-engineering
5. Dijkstra, E. W. (1968). Go To Statement Considered Harmful. Communications of the ACM.
6. Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.
7. Stanford IRIS Lab (2026). Controlled Ablations on Agent Harness Architectures. (技术报告摘要引用)

See also

• AI Native 研发实战：一个类 Notion 笔记的创业团队的 Harness 工程与知识复利
• 如果你现在在做的系统不能自主进化，你已经落后了
• 构建 Agent 的动态路由决策系统：千人千面的任务执行引擎
• AI 工程的 10X 生产力，藏在测试和监控里
• 能做事的 Agent，需要一个推荐系统