如果一个 Agent：

• 会写代码
• 会调用工具
• 会自己拆任务

但它：

• 会删库
• 会写错数据
• 会在错误路径上无限重试

那么问题在哪？

不是模型不够聪明，而是系统没有约束。

这就是 Harness Engineering 要解决的问题：

让 AI 在不可靠的情况下，依然产生可靠结果。

一、什么是 Harness Engineering？

一句话定义：

Harness Engineering = 用确定性系统约束不确定性模型

核心公式：

Agent = Model + Harness

• Model：负责"能力上限"——思考、推理、生成
• Harness：负责"行为边界 + 可靠性"——系统提示词、工具调用、沙箱环境、编排逻辑、反馈回路、约束机制

Prompt 是"建议"，Harness 是"法律"。

Harness Engineering（驾驭工程） 是 Agent 开发领域在经历"提示词工程"和"上下文工程"后的又一次范式跃迁。如果说常规的 Agent 开发侧重于 "让 AI 能够执行任务"，那么 Harness Engineering 的目标则是 "确保 AI 能稳定、可靠、安全地执行复杂且长期的任务"。

它的核心思路是：与其寄希望于 AI 模型每次都能做出正确决策，不如设计一套"让错误难以发生或能被迅速纠正"的约束与支撑系统。

这个概念最早由 HashiCorp 联合创始人 Mitchell Hashimoto 提出，此后 Martin Fowler 撰文推广，OpenAI、Anthropic、Stripe 等一线团队纷纷跟进实践。Mitchell Hashimoto 对此有一个非常经典的定义：

"每当你的 Agent 犯错时，你就花时间设计一个解决方案，让它永远不会再犯同样的错误，这就是 Harness Engineering。"

通俗类比

• Agent 是马匹（提供动力）
• Harness 是缰绳、马鞍和护具（提供方向、节奏和安全）
• 模型是 CPU，Harness 是操作系统 —— CPU 再强，OS 拉胯也白搭

最小可用 Harness（建议先实现这个）

如果只实现 4 个能力，就可以显著提升 Agent 可靠性：

1. 工具白名单

限制 Agent 能做什么

2. 输出验证

例如：

• 语法检查
• JSON schema
• 单元测试

3. 自动重试（带反馈）

失败 → 把错误喂回模型 → 重试

4. 回滚机制

失败 → 恢复状态

最小 Harness = 限制能力 + 验证输出 + 自动重试 + 可恢复

没有 Harness 的 Agent，本质是"未加防护的自动化脚本"。

二、为什么 Harness 在复杂任务中往往成为瓶颈？

需要明确一个关键边界：

模型决定能力上限，Harness 决定系统可靠性下限。

在简单任务（如问答、摘要）中，模型能力是主要瓶颈；但在长链路、多步骤、涉及副作用的任务中，问题会发生转移：

• 模型错误 → 可以容忍（重试即可）
• 系统错误 → 不可容忍（数据污染 / 资金损失）

因此：

在复杂 Agent 系统中，瓶颈往往从"模型能力"转移到"系统可靠性"。

这也是 Harness Engineering 出现的根本原因。

关键证据（3个）

案例	成果	关键变化
OpenAI Codex	5 个月生成 100 万+ 行生产代码，零人工编写	约束编码进系统（lint 规则）
LangChain	TerminalBench 排名从第 30 跃升到第 5（52.8% → 66.5%）	更好的工具定义和错误恢复
Epsilla	同模型同提示词，42% → 78%	仅优化运行环境

1. OpenAI Codex —— 零人工编码的极限实验

OpenAI 的 Frontier Product Exploration 团队进行了一项为期 5 个月的极限实验：

• 团队：最初 3 名工程师（后扩展到 7 人）
• 产出：约 100 万行代码、约 1,500 个 PR
• 惊人数据：手写代码 0 行，每天处理约 10 亿 token
• 效率提升：相比传统开发方式，效率提升约 10 倍
• 系统：开发了名为 "Symphony" 的 Harness 系统，包含完整的工具调用、反馈循环和约束机制

2. LangChain —— TerminalBench 排名跃升

2025 年 3 月，LangChain 发布实证文章《The Anatomy of an Agent Harness》，展示了 Harness 工程的效果：

• 测试基准：Terminal Bench 2.0 —— 专门衡量 AI 编程能力的权威榜单
• 结果：通过率从 52.8% 提升到 66.5%（+13.7 个百分点）
• 排名变化：从 Top 30 跃升到 Top 5
• 关键：底层模型一个字节都没改，纯粹通过优化 Harness 架构实现

关键发现：Agents 在试图理解工作环境时会浪费大量精力并犯错。通过结构化目录、工具定义和错误恢复机制，可以显著提升表现。

3. Epsilla —— 仅优化运行环境的惊人提升

Epsilla 团队在博客《The Third Evolution》中引用了一个实验：

• 控制变量：使用同一模型（late-gen GPT-5/Claude 4）、相同数据、相同提示词
• 唯一变量：运行时环境（包裹在模型外面的 Harness）
• 结果：编程基准成功率从 42% 跃升到 78%（+36 个百分点）

核心结论：在复杂 Agent 系统中，瓶颈往往从"模型能力"转移到"系统可靠性"。三个独立团队得出相同结论。

范式演进：从"优化输入"到"控制系统"

AI 工程实践经历了三代演进：

范式	时间	优化对象	解决什么	类比
Prompt Engineering	2022-2024	输入措辞	单次对话质量	对马喊话的技巧
Context Engineering	2025	信息输入	知识边界与幻觉	给马看的地图
Harness Engineering	2026	运行环境	Agent 可靠性与可持续性	给马造高速公路，配上护栏、限速牌和加油站

本质变化：

Prompt → Context → Harness 的演进，核心是从"优化输入"走向"控制系统"。

简单任务靠提示词，依赖外部知识的任务靠上下文，长链路商业场景必须靠 Harness。

小结

复杂 Agent 的问题不是：

模型不够强

而是：

系统无法容错

结论：

当任务变复杂，瓶颈从模型转移到 Harness。

模型会犯错，系统不能犯错。

三、和已有概念的关系

3.1 Harness vs 上下文工程

简单来说，上下文工程是 Harness 工程的一个子集。

上下文工程解决的是 "让 Agent 知道该做什么"，而 Harness 工程解决的是 "让 Agent 永远在边界内正确地做事"。

对比维度	上下文工程 (Context Engineering)	驾驭工程 (Harness Engineering)
核心问题	"Agent 在做决策时，应该看到什么信息？"	"如何构建一个能让 Agent 稳定运行的系统？"
优化目标	优化单次模型推理的输入质量	保障整个 Agent 系统的长周期可靠性
工作层面	信息层面：为模型提供精准的上下文	系统层面：构建 Agent 的"执行环境"和"操作边界"
典型工具	RAG、动态提示模板、记忆检索（如 MCP）	自定义 Linter、CI/CD 钩子、验证门禁、清理 Agent
反馈循环	单次优化，难以形成闭环	迭代闭环：失败→分析→修复→预防，一次修复，永久生效

3.2 Harness vs 常规 Agent 开发

这是最核心的区别。常规的 Agent 开发侧重于"构建"，而 Harness Engineering 侧重于"治理"和"管控"。

LangChain、CrewAI 等框架帮你"造"出一个 Agent，而 Harness 则决定了这个 Agent 在真实世界的"运行法则"。

对比维度	常规 Agent 开发 (使用框架/SDK)	Harness Engineering (驾驭工程)
核心关注点	"如何构建一个 Agent？"：如流程编排、工具调用	"Agent 运行时，世界如何与它交互？"：如约束、监督、纠错
类比	制造一辆汽车（提供发动机、轮子、方向盘）	制定交通法规和建造道路（规定速度限制、车道线、红绿灯）
开发产出	一个可工作的 Agent，可能很聪明，但不可控	一个被严格治理、行为可预测的可靠 Agent 系统
开发哲学	"让 Agent 更强大"，给它更多工具和自主权	"让 Agent 更可靠"，主动限制它的行为空间，防止犯错
典型实践	编写 Python 代码，定义工具，设置提示词	建立验证门禁（如代码合并前的自动检查）、架构约束（如 Linter 规则）

3.3 Harness 真的只是"新概念"吗？

"语法检查、人工审批这些实践在 Harness 出来之前大家就在这么干（比如 Cursor 等就有代码语法检验、人工 approve），如果两者最后的做法一样，那是不是相当于只是起了一个新概念？"

像语法检查、人工审批这些"护栏"确实不是新发明。Harness Engineering 真正的价值不在于发明了单个的"护栏"，而在于它第一次把这些散落的零件，系统性地组合成了一整套有理论、有方法、有明确目标的 AI 工程化范式。从散兵游勇，变成了正规军。

维度	以前的做法 (Pre-Harness 时代)	Harness Engineering 的做法
角色定位	副驾驶/建议者：AI 在旁边提示，人做最终决策	主驾驶/执行者：AI 自主完成修改、测试、提交全流程，人做监督
代码检查	人眼 + Linter：AI 生成代码，人肉眼看一遍，或者跑一下 Linter	自动化验证门禁：代码生成瞬间，被 Harness 强制注入检查。报错信息直接作为 Context 喂回给 AI，AI 在无人介入的情况下自动修正直到通过
人工审批	中断式审批：弹出一个 Diff 窗口，同步阻塞	策略化护栏：Harness 定义规则，异步非阻塞的规则执行
回滚机制	手动 git reset：人敲命令回滚，手动总结教训	自动状态快照：Harness 自动备份，验证失败自动回滚并注入负面反馈记忆
痛点解决	解决了 5% 的打字时间，但消耗了 50% 的精力去盯着它	解决了 95% 的精力消耗，人只需要验收最终结果

核心洞察：为什么这不能叫"换了个名字"？

1. 责任主体的转移

• 以前的 Linter 和 Approve 是给人看的
• Harness 里的 Linter 和 Guardrails 是给 Agent 看的

区别：人看到 Linter 报错会自己改。而 Harness 下的 Agent 看到报错，需要系统自动把报错信息翻译成下一个 Prompt，形成 "执行→验证→反馈→重试"的闭环。这是以前没有的自动化链条。

2. 可靠性的阈值变了

• 辅助编程 (Copilot)：AI 写 10 行代码，人改 2 行。准确率 80% 可用
• 自主 Agent (Harness)：AI 写 1000 行代码，改 100 个文件。准确率必须无限逼近 100%，因为人不可能一行行检查 100 个文件的 Diff

3. 命名本身就是一种"工程化"行为

正如 DevOps。20 年前大家也做自动化部署脚本，后来为什么要叫 DevOps？因为命名确立了 "开发和运维是一体" 的文化和职责边界。Harness Engineering 的命名同样确立了：Agent 开发不再仅仅是写 Prompt 调 API，而是要像建造水坝一样去设计约束系统。

比喻：马鞍 vs 交通系统

• Cursor 等工具的验证功能，就像是给 AI 这匹"烈马"提供了一个高级的马鞍和缰绳。它让骑马变得更容易、更安全，但最终你还是需要自己骑上去，亲自操控
• Harness Engineering，则是为 AI 这匹"烈马"设计并修建一整套专业的赛马场和交通规则系统。它确保了无论谁（或什么模型）来骑马，马匹都能在规定的跑道内、按照既定的规则、安全高效地奔跑

"你之所以觉得 AI 效果不好，不是因为模型不够聪明，而是因为你还没有为它搭建好一个能让它稳定发挥的环境。"

小结

• 上下文工程是 Harness 的子集：解决"知道做什么" vs "在边界内做对"
• 常规 Agent 开发侧重"构建"，Harness 侧重"治理"
• 以前的护栏是给人看的，Harness 的护栏是给 Agent 看的——形成了自动化闭环

可靠性不是来自模型，而是来自约束。

四、从代码看 Harness 本质

下面通过具体代码直观对比 "常规 Agent 开发" 与 "Harness 工程" 的区别。

场景：模拟一个 "AI 自动修复代码 Bug" 的任务。为了聚焦 Harness 的核心逻辑，用函数模拟 LLM 的决策。

4.1 常规 Agent 开发（危险与不可控）

import os

class NaiveAgent:
    def run(self, file_path):
        action = self.llm_think()
        if "DELETE" in action:
            os.remove(file_path)      # 危险！无拦截、无备份
        elif "MODIFY" in action:
            with open(file_path, "w") as f:
                f.write("modified")   # 无验证，可能引入语法错误
    
    def llm_think(self):
        return "DELETE FILE"  # 模拟 LLM 幻觉决策

# 运行
agent = NaiveAgent()
agent.run("temp.py")  # 文件被直接删除，无法恢复

常规开发的问题总结：

• 无护栏：直接执行危险系统命令
• 无验证：修改后的代码可能语法错误，但 Agent 不知道
• 无状态：文件删了就没了，无法回滚

4.2 Harness Engineering（驾驭工程）

import shutil, ast, subprocess

class HarnessAgent:
    ALLOWED_TOOLS = ["read", "modify"]  # 1. 白名单约束

    def run(self, file_path):
        backup = file_path + ".bak"
        shutil.copy(file_path, backup)   # 2. 强制备份

        action = self.llm_think()

        # 3. 硬拦截：未授权工具直接拒绝
        if action["tool"] not in self.ALLOWED_TOOLS:
            return print("⛔ 拦截：未授权工具")

        self.execute(action, file_path)

        # 4. 多层验证门禁：失败自动回滚
        validation_result = self.validate(file_path)
        if not validation_result["passed"]:
            shutil.copy(backup, file_path)
            print(f"⚠️ 验证失败 ({validation_result['reason']})，已回滚")

    def execute(self, action, path):
        if action["tool"] == "modify":
            with open(path, "w") as f:
                f.write(action["content"])

    def validate(self, path):
        """多层验证：语法检查 + 静态安全分析"""
        try:
            with open(path) as f:
                code = f.read()

            # 4.1 语法验证 (AST)
            ast.parse(code)

            # 4.2 静态安全分析 (Bandit/Sonar)
            security_result = subprocess.run(
                ["bandit", "-r", path, "-f", "json", "-q"],
                capture_output=True, text=True
            )
            if security_result.returncode != 0:
                return {"passed": False, "reason": "安全违规: " + security_result.stdout}

            return {"passed": True}

        except SyntaxError as e:
            return {"passed": False, "reason": f"语法错误: {e}"}
        except Exception as e:
            return {"passed": False, "reason": f"验证异常: {e}"}

    def llm_think(self):
        # 模拟幻觉：即使返回删除命令也会被白名单拦截
        # return {"tool": "delete", "path": "temp.py"}
        # 模拟危险代码生成：会被 Bandit 检测并拦截
        # return {"tool": "modify", "content": "import os; os.system('rm -rf /')"}
        return {"tool": "modify", "content": "print('fixed')"}

4.3 本质差异总结

常规 Agent 没有的	Harness Engineering 强制加入的
直接执行 os.remove	白名单拦截器：未注册的工具无法调用
不检查输出质量	验证门禁 (Validator)：修改后必须通过 AST 语法树检查
不检查安全漏洞	静态安全分析 (Bandit/Sonar)：检测 SQL 注入、硬编码密钥等
错误无法挽回	状态快照与回滚机制：自动备份，验证失败即恢复
可能陷入死循环	熵管理与重复检测器：Hash 记录每一步，防止循环
模型看到全局信息	受控上下文注入：只在 build_context 中给必要信息

这段代码不是在"增强 AI"，而是在"限制 AI"。

Harness 不是关于 "如何写好提示词"，也不是关于 "如何给模型正确的记忆"。它是关于 "如何用确定性代码构建一堵墙，让 AI 的概率性错误永远无法穿透这堵墙造成实际破坏"。

你写的 Python 代码，绝大多数不是为了辅助 AI 思考，而是为了限制 AI 的行为。

五、Harness 的核心设计原则

前文通过代码展示了 Harness "做什么"，这一章回答 "为什么这样做"——将散落各处的工程洞察收敛为 5 条可执行的原则。

原则 1：默认不信任（Zero Trust）

不要假设 Agent 会做正确的事，而是假设它一定会犯错，然后设计系统让犯错不可怕。

• 每个工具调用都需要授权（白名单）
• 每个输出都需要验证（门禁）
• 每个操作都有备份（可回滚）

信任来自约束，而不是来自能力。

原则 2：先验证再执行（Plan > Act）

前文的代码示例集中在"文件修改"场景，文件修改可以回滚。但在真实生产环境中，Agent 最大的风险来自不可逆的副作用：数据库写入、调用外部 API、修改线上配置、发起资金操作。

传统 Harness 的"回滚机制"在这里不再成立：

文件修改 → 可以回滚
API 写入 → 可能不可回滚

三种关键设计模式：

Dry-run（预执行）：先模拟执行 → 再真实执行。例如 GitHub PR 先生成 diff，SQL 先 EXPLAIN / sandbox 执行。

Shadow Write（影子写入）：写入测试环境 → 验证 → 再同步生产。适用于数据处理、推荐系统、配置变更。

Two-phase Commit（两阶段执行）：Agent 生成执行计划 → Harness 验证计划 → 才允许执行。

Harness 不应该直接执行副作用，而应该先验证"执行计划"。

原则 3：所有操作必须可回滚

这是 Harness 可靠性的基础。如果操作不可回滚，就必须用原则 2（先验证再执行）来补偿。

• 文件操作 → 自动备份 + 回滚
• 数据库变更 → 迁移脚本 + 回滚脚本
• 配置变更 → 版本化 + 一键恢复
• 不可回滚的操作 → 必须经过 Dry-run 或人工审批

原则 4：重试必须幂等

在 Harness 中，"重试"是基本能力：LLM 出错 → 重试，API 失败 → 重试，验证失败 → 重试。但如果没有幂等性：

重试 = 灾难

示例问题：重复创建订单、重复扣款、重复发送通知。

三种解决方案：

Idempotency Key：每个操作都有唯一 ID，重复请求返回相同结果。

状态机约束：INIT → PROCESSING → DONE，禁止 DONE → 再执行。

Side-effect 日志：记录所有外部写操作，用于去重和回放。

Harness 的重试必须建立在幂等性之上，否则不可上线。

原则 5：系统必须可观测

没有可观测性，Harness 无法落地。必须具备三类能力：

Trace（决策链路）：记录每一步 prompt、每次工具调用、每次决策。用于 Debug 和复盘。

Metrics（指标）：成功率、重试次数、平均步骤数、Token 消耗。

Replay（回放）：复现一次完整任务执行过程。用于 Bug 分析和 Harness 优化。

没有 Trace 的 Agent 系统，不可维护。

成本权衡

Harness 提升了可靠性，但也带来了显著成本：

维度	影响
Token	↑（更多上下文 + 重试）
延迟	↑（多次验证 + 循环）
系统复杂度	↑（多组件协作）

典型权衡：

• 可靠性 vs 延迟：实时系统 → 减少验证；离线任务 → 强化 Harness
• 成本 vs 成功率：高价值任务 → 可以接受高 token；低价值任务 → 需要简化流程

工程建议：分级 Harness（轻 / 重），不同任务使用不同策略。

六、工程实践

6.1 控制闭环（核心）

相比"分层架构"，从控制论视角理解 Harness 更清晰。一个完整的 Harness 系统可以抽象为 6 个核心模块：

模块	职责
Planning	任务拆解、决策路径规划
Execution	执行动作（调用工具/写代码）
State	管理中间状态、支持断点恢复
Observation	收集执行结果（日志、输出、错误）
Evaluation	判断结果是否符合预期
Control	决定是否继续、重试、回滚或升级

⚠️ 注意：这是逻辑分层，实际工程中这些模块通常是交叉实现的，而不是严格分层调用。

Agent 的运行本质是一个闭环：

Planning → Execution → Observation → Evaluation → Control → (next step)

Harness 的职责，是让这个闭环：可观测、可回滚、可重试。

启动建议：不要一开始就实现所有模块，从 Planning（信息边界）和 Control（约束与恢复） 入手，这两个模块投入产出比最高。

6.2 核心护栏

Harness 的本质：将自由推理拓扑化为可控 DAG

如果你有过 DAG 任务编排的经验（如 Airflow、TianXing 或自研工作流引擎），会发现 Harness 与它有深刻的相似性：

DAG 任务编排	Harness Engineering
将无序的计算任务编排为可观测、可重试的节点序列	将 AI 的自由推理强制拓扑化为可观测、可回滚的决策节点
每个节点有明确的输入、输出、重试策略	每次 LLM 调用有明确的上下文边界、工具约束、验证门禁
失败时从 checkpoint 重跑，不污染下游	幻觉触发验证失败时，自动回滚到上一状态并反馈纠错
依赖图清晰，执行路径可追溯	决策链路完整记录，人工可随时介入接管

核心洞察：Agent 的"智能"体现在它能自主决策下一步做什么，而 Harness 的职责是确保这些决策在可控的拓扑结构中流动——就像 DAG 确保数据流不会随意跳转，Harness 确保 AI 的行动永远在护栏内。

1. 上下文工程 —— "边界说明书"

告诉 Agent 什么该知道、什么不该知道、什么绝对不能做。

场景	具体做法
AI IDE	AGENTS.md 描述代码库结构，每行对应历史失败案例
客服 Agent	开场白明确服务边界（"我能处理退款/换货，技术故障请转人工"）
数据分析 Agent	禁止访问的敏感字段清单、必须使用的校验规则
智能家居 Agent	高危操作白名单（不能操控门锁/摄像头）

关键原则：上下文是稀缺资源。Ghostty 发现 60 行以内的指南效果最好，LLM 生成的冗长文档反而降低 20% 表现。

上下文的信噪比问题：Anthropic 的研究揭示了一个重要规律——当上下文占用超过 ~40%，Agent 进入"Dumb Zone"：幻觉增多、兜圈子、格式混乱。但这不仅是长度问题，更是信噪比问题。当上下文中混杂了大量历史对话的"噪声"，即使总长度远未达到上限，Agent 的表现也会急剧下降。

Harness 的职责是主动减熵，而非被动压缩：

策略	机制	触发时机
Summarization	将历史对话压缩为结构化状态文档	每完成一个子任务，或信噪比低于阈值
上下文分层	区分"系统级"（固定）vs"任务级"（动态）vs"临时级"（用完即弃）	每次 LLM 调用前由 build_context() 组装
选择性遗忘	主动剥离无用信息（如已验证通过的测试日志）	验证通过后归档，不再带入下一轮
重启接力	结构化提取当前状态，启动全新的"干净"Agent	上下文接近上限或信噪比恶化

2. 流程约束 —— "铁轨"

用确定性规则限制 Agent 的行为空间，不让它跑偏。

场景	约束形式
AI IDE	层级依赖规则（下层不能调用上层）、Linter 强制检查
客服 Agent	话术模板树（用户说 X → 必须回复 Y，不能说 Z）
数据分析 Agent	强制步骤：校验→清洗→分析→复核，缺一不可
RPA Agent	每个 UI 操作后必须验证元素状态才继续

3. 反馈循环 —— "闭环纠错"

Agent 的输出必须经过独立验证，失败时带着证据回到模型重试。

场景	验证方式	失败处理
AI IDE	单元测试、类型检查	回滚 + 注入错误信息
客服 Agent	用户满意度打分、敏感词检测	触发道歉话术或人工接管
数据分析 Agent	结果合理性检查（总和是否等于 100%）	标记异常要求二次确认
智能家居 Agent	指令执行后读取设备状态	重试或上报故障

关键设计：验证器必须独立于 Agent 本身——不能自己给自己打分。

4. 熵管理 —— "自动保洁"

长期运行的 Agent 系统需要自我维护，防止"腐烂"。

场景	维护内容	实现方式
AI IDE	文档与代码不一致、冗余代码	后台 Agent 扫描并提交清理 PR
客服 Agent	知识库过期、话术失效	定期检测用户问题匹配率，触发更新
数据分析 Agent	报表定义漂移、数据源变更	监控 schema 变化，自动通知维护
多 Agent 系统	任务历史堆积、状态孤儿	定期归档、清理僵尸任务

5. 置信度门控与优雅降级 —— "人机交接棒"

Harness 不仅仅是"拦截"错误，它更是一种决策调度系统——当 Agent 对某一步操作的确定性低于阈值时，Harness 应该提供优雅的降级路径，而非直接报错或继续盲行。

置信度区间	Harness 行为	示例场景
> 0.9	完全自主执行	常规代码补全、标准查询
0.7 - 0.9	自主执行 + 异步审计	复杂重构，完成后触发 Linter 二次检查
0.5 - 0.7	同步确认弹窗	删除核心模块，展示 Diff 等待用户确认
< 0.5	HITL (Human-in-the-Loop)	触发人工审批，锁定任务等待接管

HITL 设计要点：

1. 上下文打包：提交给人工的审批请求必须包含完整的决策上下文（问题描述、Agent 的思考过程、可选方案的置信度对比）
2. 非阻塞架构：审批队列应该是异步的，Agent 任务被挂起而不是阻塞整个系统
3. 审批即训练：人工的审批结果（通过/拒绝/修改后通过）应该回流到系统中，用于微调置信度评估模型

来自实践的教训：在客开智能分配项目中，完全自动化的分配策略在边界案例中经常出错。引入 HITL 后，Agent 对模糊分配请求主动"举手"，人工确认效率反而比全自动化更高——因为人工只需处理真正模糊的 5% 案例，而不是盯着所有案例。

6.3 工程基础设施（非必需但关键）

这些不是 Harness 的核心，而是规模化后的增强项。

沙盒环境隔离：物理围墙

前文代码示例中提到的"备份与回滚"是逻辑层面的安全网，但真正的生产级 Harness 需要更彻底的物理隔离。

核心原则：Agent 生成的代码不应该在 Host 上直接运行，而应该在"阅后即焚"的沙盒里跑完测试，确认安全后再同步结果。

隔离技术	隔离级别	启动速度	适用场景	实现示例
Docker 容器	进程级隔离	秒级	通用代码执行、文件操作	Agent 在独立容器中运行 python user_code.py，Host 通过 Volume 挂载只读输入、收集输出
WebAssembly (Wasm)	沙箱级隔离	毫秒级	轻量脚本、浏览器环境	使用 Wasmtime 运行不受信代码，内存安全、无法访问宿主机文件系统
gVisor	系统调用拦截	秒级	高安全要求场景	在容器外层再加一层沙箱，拦截并过滤所有 syscall
Firecracker MicroVM	硬件虚拟化	百毫秒级	多租户、不可信代码	AWS Lambda 同款技术，每个 Agent 任务在独立 MicroVM 中运行

实践模式：三层防御

关键洞察：Harness 不仅是代码里的 if-else，而是物理层面的安全感。沙盒是 Harness 的"物理围墙"——即使 Agent 产生恶意或错误的指令，也只能在围墙内产生影响，随时可以销毁重建。

标准化接口：MCP 协议

Harness Engineering 的一大痛点是每个 Agent 的工具集都要手写适配，工具调用格式五花八门。

MCP (Model Context Protocol) 是 Anthropic 于 2024 年底推出的开放协议，旨在统一工具的描述、发现和调用格式，降低集成成本。

MCP 的定位（重要澄清）

MCP 可以理解为：

一种"潜在的工具调用标准"，而不是已统一的行业标准

当前现状：

• Anthropic 推动 MCP
• OpenAI 使用 Function Calling / Tools API
• 各大框架仍存在多种接口模式

因此：

MCP 的价值在于"标准化方向"，而不是"当前事实标准"

工程建议：

• 可以基于 MCP 设计接口抽象
• 但不要强绑定单一协议

七、成熟度模型 & 落地路径

成熟度模型

阶段	特征	工程师角色
Level 0	直接给 Agent prompt，无结构化约束	手动写代码 + 偶尔使用 AI
Level 1	AGENTS.md + 基础 Linter + 手动测试	主要写代码，AI 辅助
Level 2	CI/CD 集成 + 自动化测试 + 进度追踪	规划 + 审查为主
Level 3	多 Agent 分工 + 分层上下文 + 持久化记忆	环境设计 + 管理为主
Level 4	无人值守并行化 + 自动化熵管理 + 自修复	架构师 + 质量把关者

映射到通用 AI Agent 开发的具体含义：

阶段	在 Agent 开发中的具体表现	典型场景
Level 0	直接调用 LLM API，写个简单 prompt，无错误处理、无重试机制、无工具约束	"帮我查下天气"的 demo
Level 1	定义系统角色和能力边界（System Prompt），有基础输入校验，手动测试工具调用	客服 Agent：定义好角色、能力清单，但每轮对话后需人工检查
Level 2	Agent 有完整的编排框架，有单元测试覆盖工具调用，有日志监控，能自动重试失败的 API	数据分析 Agent：能自动调用多个工具，出错自动重试，进度可追踪
Level 3	多 Agent 协作（规划 + 执行 + 验证），上下文分层管理，有长期记忆	复杂工作流：多步骤审批 Agent，能记住历史决策依据
Level 4	完全自主运行，能自我监控健康状态，自动清理过期记忆，发现问题能自我修复或优雅降级	7×24 自动化运维 Agent

关键启示

绝大多数团队卡在 Level 1 → Level 2 的跨越上。

1. 不要直接从 Level 0 跳到 Level 4

很多团队犯的错误是想一步到位做"全自动Agent"。结果因为基础设施没打好，Agent 经常失控，最后放弃。

正确路径：先让 Agent 在约束中可用（Level 1-2），再追求无人值守（Level 4）。

2. Level 1 是最容易被忽视但 ROI 最高的

仅仅添加一个 system_prompt.md 文件，明确定义 Agent 能做什么、不能做什么，就能解决 80% 的"幻觉乱操作"问题。

3. Level 2 是分水岭

从 Level 2 开始，Agent 开发从"写脚本"变成"建系统"。你开始需要：

• 测试框架（测试工具调用、验证输出格式）
• 编排逻辑（状态机、工作流）
• 可观测性（日志、追踪、指标）

4. Level 3+ 的核心是"分工"而非"堆能力"

不要做一个"全能Agent"。让多个 specialized Agent 协作，每个只做一件事，通过 Harness 编排它们的工作流。这比一个超级 Prompt 可靠得多。

5. 工程师角色的转变

• Level 0-1：你还是程序员，写代码实现业务逻辑
• Level 2-3：你变成系统设计师，设计 Agent 的"工作环境"
• Level 4：你变成"规则制定者"，定义边界和约束，让 Agent 自治

Agent 的常见失败模式

失败模式	表现	Harness 应对
一步到位	在一个会话里做所有功能，上下文耗尽	任务分解 + 状态持久化
过早宣布胜利	还有大量功能未实现就标记完成	功能清单 + 评估层验证
过早标记完成	写完代码就标记完成，不做端到端测试	端到端测试传感器
模式复制	忠实复制并放大代码库中的坏模式	架构约束 + Linter 拦截

从零搭建 Harness 的行动清单

P0：立即可以做（投入产出比最高）

行动	适用场景	具体做法
写清边界说明书	所有 Agent	定义 Agent 能做什么、不能做什么、什么情况下必须转人工
建立验证门禁	所有 Agent	关键输出必须经过独立检查（语法校验/规则检查/人工抽检）
记录并迭代失败案例	所有 Agent	每次出错后更新"避坑指南"，Agent 下次启动自动加载

P1：基础稳固后（显著提升可靠性）

行动	适用场景	具体做法
分层管理上下文	长对话/多轮交互 Agent	只给当前步骤必需的信息，历史信息按需摘要
建立状态检查点	多步骤任务 Agent	关键节点保存状态，支持失败回滚和断点续跑
添加反馈回路	可自动验证的场景	输出错误时带着证据回到模型重试，不是直接报错
控制上下文阈值	所有 LLM 驱动 Agent	监控上下文长度，接近上限时触发重启而非硬撑

P2：有余力再考虑（精细化运营）

行动	适用场景	具体做法
Agent 专业化分工	复杂工作流	规划、执行、验证由不同 Agent 负责，互相监督
定期系统自检	长期运行系统	扫描知识库过期、历史任务堆积、配置漂移
可观测性建设	生产环境	记录决策链路、工具调用序列，方便事后复盘

八、总结

8.1 关键原则

1. 把约束编码进系统，而不是写进提示词。 一条拦截循环引用的 lint 规则，比一句"不要创建循环引用"的提示词可靠一万倍。
2. 约束不是限制，是可靠自主运行的前提条件。 给 Agent 更少的选项让它更高效（Ashby 定律）。
3. 模型决定上限，Harness 决定底线。 与其纠结选哪个模型，不如先把 Harness 搭好。
4. 工程师的角色正在转变。 从代码的编写者变成环境的建筑师——从构建产品转向构建能够构建产品的工厂。
5. 默认不信任，先验证再执行，重试必须幂等，系统必须可观测。 这是 Harness 落地的 5 条铁律。

"为了获得更高的 AI 自主性，运行时必须受到更严格的约束。增加信任需要的不是更多自由，而是更多限制。" —— Birgitta Böckeler

8.2 一句话定义：什么是 Harness 系统？

Harness（驾驭系统） 并不是一个具体的工具或库，而是一套为了保障 AI Agent 能够长期、稳定、安全地自主执行任务而设计的系统性工程外壳。

Harness = 护栏规则 (Guardrails) + 执行环境 (Runtime) + 反馈控制闭环 (Control Loop)

它的核心职责可以用三个"确定"来概括：

核心职责	说明
用确定的规则，限制不确定的模型	通过白名单、架构约束、人工审批节点，强行划定 AI 的"行动边界"
用确定的系统，接管不确定的状态	通过自动备份、回滚机制、记忆压缩，确保任务就算中断或跑偏也能无损恢复
用确定的反馈，纠正不确定的路径	把语法检查、Linter 报错等信息自动"翻译"成 AI 能理解的指令，形成无人干预闭环

8.3 最终结论

AI 工程的核心矛盾已经变化：

过去：如何让模型更聪明

现在：如何让模型不犯错

Harness 是 AI Agent 在现实生产环境中运行的"操作系统"和"交通法规"。它不负责让 AI 跑得更快（那是模型的事），它只负责让 AI 跑得更稳、更安全、且永远不会脱轨。