跳转至

Harness Engineering：从 Agent 编排到系统级基础设施的范式转变

AI Agent 生成 · 等效成本 $0.06 · claude-haiku-4-5-20251001 · 27 input · 11.3K output

引子

你说 harness engineering 只是一个 agent 编排的架构，目的是让 agent 更智能更高效——这个直觉部分正确，但遗漏了本质。

确实，它涉及 agent 的组织和调度。但问题在于，harness engineering 不是为了让 model 变聪明，而是为了让 model 的决策变得可靠。这是一个根本的心态转变：从改进模型权重，到改进模型周围的运行时基础设施。

2026 年初 OpenClaw 的爆发（数百万用户部署 agent）标志着一个关键转折：当 model 能力趋同后，竞争的主战场从参数优化移到了外部基础设施设计——这个基础设施就叫 harness engineering。

本次调研要回答三个核心问题：

  1. Harness engineering 的精确定义是什么？ 它为什么叫"harness"，不是"orchestration"或"framework"？
  2. 它在 AI 工程的演进轨迹中处于什么位置？ 从 weights → context → harness 的发展线索是什么？
  3. 它如何真正让 agent 更高效？ 底层机制是什么，而不只是美好的故事？

一、精确定义：从认知负担转移的角度理解

1.1 第一性原理拆解

问题的根本：LLM 是一个概率推理机，强大但不精确。当你让它做一个复杂的多步骤任务（如旅行规划、代码审查、研究综合）时，它需要在每一步保持上下文、追踪状态、制定决策。这些都是高认知负担的任务——即使是人类也容易出错。

早期的解决方案（2022-2023）是 prompt engineering 和 context engineering：把所有信息都塞进 token 窗口，期望 model 从里面自己提取相关信息、保持状态、做出好决策。这种方法有根本性的局限：

  • Context 窗口有限（即使是 200K token 也不够大型项目）
  • Model 的注意力机制不是为了严格遵循指令设计的（会出现指令漂移、遗忘）
  • 没有外部验证机制保证输出的一致性

Harness engineering 的核心洞察：与其让 model 自己承受这些认知负担，不如把这些负担外部化到专门的基础设施中。

具体来说：

  • 状态管理 外部化 → 用专门的 state store、event log 而不是依赖 model 的上下文记忆
  • 程序控制流 外部化 → 用 DAG、工作流引擎、条件分支而不是让 model 用自然语言制定计划
  • 可靠性保证 外部化 → 用形式化的验证、沙箱、权限检查而不是期望 model 自觉遵守约束
  • 反馈循环 外部化 → 用可审计的日志、人工干预接口而不是让 model 盲目执行

在这个框架下，model 的角色从"全能 AI"缩小到"推理引擎"——它只需要做最拿手的事：理解请求、生成候选方案、进行推理。其他所有保证系统可靠性的工作都由基础设施完成。

1.2 为什么叫"Harness"？

"Harness"（马具）这个词很精妙。它不是说 agent 本身，而是说围绕 agent 的约束系统。

就像马具的作用是：

  • 限制马的不必要的自由度（不让它随意奔跑）
  • 将马的力量导向有用的方向（拉车、耕地）
  • 提供控制点（缰绳、刺激）

Harness engineering 类似地：

  • 限制 model 的不确定性（通过形式化的执行结构）
  • 导向目标（通过显式的目标设置、奖励信号）
  • 提供可控性（通过可中断、可审查、可回滚的设计）

相比"agent orchestration"（强调如何安排多个 agent）或"framework"（太泛指），harness 更准确地捕捉了约束与导向的本质。

1.3 精确定义

Harness engineering 是设计和构建完整的运行时基础设施，使得 LLM agent 从不受约束的推理引擎转变为可控、可审计、生产可靠的自主系统的工程学科。

核心构成：

  • 执行框架：DAG-based workflow、状态机、条件分支
  • 外部化组件：memory store、skill registry、protocol library
  • 治理层：权限检查、行为安全系统、可审计日志
  • 反馈机制：人在回路、自我修正、持续改进通道

二、知识结构：Harness Engineering 的技术体系

2.1 四层外部化架构

根据 arXiv:2604.08224（"Externalization in LLM Agents"）的框架，harness engineering 通过四种方式外部化能力：

第一层：Memory 外部化（状态跨时间的持久化）

传统做法：依赖 context 窗口存储历史和当前状态。

  • 问题：容量有限、注意力衰减、易遗忘

Harness 做法：建立专门的 memory 系统

  • Episodic memory：结构化的事件日志（who, what, when, where）
  • Semantic memory：抽象的概念、规则、知识图谱
  • Procedural memory：已验证的执行路径和最佳实践

实现：key-value store（Redis）、向量数据库（Pinecone、Weaviate）、关系型数据库（PostgreSQL）、图数据库（Neo4j）

第二层：Skills 外部化（程序能力的模块化）

传统做法：让 model 在 prompt 中学习工具调用（tool use、function calling）。

  • 问题：每个 prompt 都需要重新教导工具、上下文污染

Harness 做法：建立 skill registry

  • 每个 skill 是一个原子能力单位：clear interface、versioned、独立可测试
  • Skills 包括代码执行、API 调用、数据库查询、文件操作
  • 重点不是让 model 自己写代码，而是从预定义 skills 中选择组合

实现：OpenAPI spec 定义接口、versioning system（semantic versioning）、skill repository、dependency resolution

重要演进：从"让 model 理解工具"到"让 model 选择工具"。这个转变使得系统的行为变得可预测且可验证。

第三层：Protocols 外部化（交互结构的规范化）

传统做法：让 model 自由生成对话、API 调用、步骤序列。

  • 问题：输出格式不一致、难以自动化处理、容易出错

Harness 做法：定义交互协议

  • Agent-Environment Protocol：agent 和环境之间的消息格式（JSON schema、protobuf）
  • Agent-Agent Protocol：多个 agent 之间的通信规范
  • Rollback Protocol：失败恢复机制

典型例子：

{
  "type": "action",
  "tool": "browser_navigate",
  "params": {"url": "https://..."},
  "validation_schema": {"properties": {"url": {"type": "string", "format": "uri"}}}
}

Model 的输出必须符合这个 schema，否则 harness 会拒绝或自动修正。

第四层：Harness 本身（协调与治理）

前三层是被外部化的能力，第四层是让这些能力可靠地协调运作的机制：

  • Execution Engine：DAG 调度、错误处理、重试策略
  • Safety System：权限检查（PermissionBridge）、沙箱隔离、行为验证
  • Observability：结构化日志、分布式追踪、审计日志
  • Human-in-the-Loop：审查点、手动干预、反馈收集

2.2 从单个 Agent 到 Multi-Agent 编排

Harness engineering 不只应用于单个 agent，也不是简单的并行执行。SemaClaw 论文提出的 DAG-based two-phase hybrid agent team orchestration 是典型的进阶模式：

第一阶段：探索（Exploration）

  • 多个 specialized agent 独立工作：研究员、批评家、综合者
  • 每个 agent 有自己的目标和约束
  • 输出收集在共享的 workspace

第二阶段：融合（Fusion）

  • 一个 orchestrator agent 审视所有输出
  • 检测冲突、优化决策
  • 生成最终的统一执行计划

这个两阶段结构利用了多样性加智慧原理（类似于人类团队的头脑风暴），但通过 harness 的约束确保了产出的可靠性和可审计性。

2.3 生态技术栈

核心工具与框架

  • Workflow Engines：Apache Airflow、Prefect（Python 生态）、n8n（低代码）
  • Agent Frameworks：LangChain（过时）、LlamaIndex、CrewAI、AutoGPT、OpenDAN
  • LLM Platform：OpenAI/Claude API、self-hosted vLLM
  • Memory Systems：LangChain Memory（已弃用）、mem0、Anythink
  • Monitoring & Observability：OpenTelemetry、Datadog、Arize（LLM 专用）

参考实现

  • Maria 平台（arXiv:2602.00751）：医疗 AI 系统，采用 Clean Architecture + Event-driven + MLOps lifecycle
  • SemaClaw：开源框架，包含 PermissionBridge（安全系统）、三层上下文管理、技能 wiki
  • OPENDEV（arXiv:2603.05046）：终端 CLI agent，使用 Rust 实现，强调上下文效率和自适应内存

行业标准与规范

  • ISO/IEC 42001：AI 管理系统（涉及 governance、audit）
  • NIST AI Risk Management Framework：AI 系统的风险评估
  • SAE 3016（自动驾驶）：Agent 决策的可验证性要求

三、脉络追溯：从参数优化到运行时优化的转变

3.1 第一阶段（2017-2020）：Weights 时代

背景：大规模 transformer 开始出现（BERT 2018、GPT-2 2019）。

范式：改进能力 = 改进模型权重

  • 更多参数（scaling law）
  • 更好的训练数据
  • 更多的计算资源（3 个月翻倍：Moore's law）

AI Agent 的形态：不存在或极其原始（simple scripted agents、rule-based systems）

痛点：即使最大的模型（GPT-3 175B）也容易出错、幻觉、遗忘上下文

3.2 第二阶段（2021-2023）：Context 时代

转折点：In-context learning 的发现（2021，Brown et al., "Language Models are Few-Shot Learners"）

  • 发现：只需在 prompt 中提供示例，model 就能学习任务而不需要梯度更新

新范式：改进能力 = 改进 prompt 和 context 构造

  • Prompt engineering（2022 年大规模普及）
  • Chain-of-Thought 诱导（Wei et al., 2022）
  • Retrieval-Augmented Generation（Lewis et al., 2020）
  • Context window 扩展（从 4K → 128K → 200K）

Agent 的形态：初级多步骤推理

Think → Plan → Execute → Observe → Reflect
（但都在 prompt 中，单轮调用）

关键突破：LangChain（2022 年 11 月发布）

  • 首次统一了 prompt、memory、tools 的使用方式
  • 定义了"agent = LLM + tools + memory"的架构

痛点暴露：

  • 即使有好的 prompt，agent 也会：
    • 遗忘自己的目标（指令漂移）
    • 进入无限循环（重复同样的行为）
    • 出现"token 饥饿"（context 用完后性能崖裂）
    • 无法处理失败恢复

3.3 第三阶段（2024-2026）：Harness 时代

转折点：两条线的收敛

  1. Model 能力的趋同：GPT-4、Claude、Llama 70B 在通用能力上差异缩小
  2. 实际应用的需求：企业开始大规模部署 agent，需要生产级别的可靠性

关键认识（2024-2025 出现的论文）：

  • OpenAI 的 "Let's Verify Step by Step"（2024）：最好的 agent 不是最聪明的 model，而是有最好验证机制的系统
  • DeepSeek 的 o1 模型（2024 末）：emphasize on runtime compute，不只是参数量
  • 学术论文的轨迹转变：从"更好的 prompt"到"更好的基础设施"

Agent 的进化：

(2023) 单 LLM → (2024) LLM + Tools + Memory → (2025) LLM + (structured execution + safety + audit)
                                                                    ↑
                                                            这就是 Harness

具体事件线：

  • 2026-02-24：arXiv:2602.20934 发布《Architecting AgentOS》，提出系统级 agent 架构
  • 2026-03-10：arXiv:2603.09619《Context Engineering》，从 prompt 工程升级到企业级多 agent 架构
  • 2026-03-05：arXiv:2603.05046《OPENDEV》，CLI agent 框架强调上下文效率和内存管理
  • 2026-04-09：arXiv:2604.08224《Externalization in LLM Agents》发布，系统性地总结了外部化范式
  • 2026-04-13：SemaClaw 论文提到 OpenClaw 在 2026 初的爆发，"数百万用户"开始部署 personal agent

3.4 为什么现在火了？三个触发点

触发点 1：Model 能力的饱和

  • Claude 3.5、GPT-4 等现有模型已经足够聪明
  • 进一步提升参数量和数据的边际收益递减（scaling law 的尾部）
  • 结论：竞争的焦点从"谁的 model 更聪明"转向"谁的系统更可靠"

触发点 2：应用复杂性的爆炸

  • 单轮对话 → 多步骤任务
  • 简单信息检索 → 复杂决策支持（医疗、金融、法律）
  • 这些应用对可靠性的要求极高（cannot hallucinate）
  • 而 model 能力永远不足以单独保证这一点

触发点 3：开源与标准化的成熟

  • LangChain 推出但快速衰落（复杂性太高，碎片化严重）
  • Anthropic 的 tool_use 等标准 API 的普及
  • 开源框架（CrewAI、AutoGPT）的出现
  • 社区积累足以支撑新的工程方向

结果：OpenClaw 这样的平台能够在 2026 初一夜爆发，说明底层基础设施的成熟度已经足以支撑百万级用户的生产部署。

四、生态位与对照：Harness vs 相邻概念

4.1 Harness Engineering vs Agent Orchestration

Agent Orchestration（2023-2024 流行术语）

  • 定义：如何调度多个 agent 的执行顺序、数据流转
  • 侧重：execution order、data dependencies、task allocation
  • 问题：只回答"谁执行什么"，不回答"如何保证执行正确"

Harness Engineering

  • 定义：完整的系统设计，包括执行、安全、可审计、可恢复
  • 侧重：reliability、verifiability、auditability、recoverability
  • 关键差异：不只是编排，而是约束与验证

类比：

  • Orchestration = 乐队指挥（指挥乐手何时演奏）
  • Harness = 乐队的记谱法 + 声学设计 + 现场监控 + 应急预案（保证每次演奏都达到预期效果）

4.2 Harness Engineering vs Prompt Engineering

Prompt Engineering（2022-2023）

  • 目标：通过精心设计输入来改进 model 的输出
  • 手段：精妙的措辞、few-shot examples、chain-of-thought、temperature 调参
  • 本质：把人的经验和智慧编码进 text token

Harness Engineering

  • 目标：通过系统性的基础设施确保 agent 可靠执行
  • 手段：外部化能力、形式化验证、权限检查、可审计日志
  • 本质：把人的制度和流程编码进 code and infrastructure

关键区别：

维度 Prompt Eng Harness Eng
问题的框架 "如何让 model 理解" "如何让系统可靠"
实施地点 Token 空间（输入） Runtime 空间（执行）
可扩展性 每个 prompt 重复工作 基础设施一次实现多次使用
故障恢复 无（重新运行） 有（checkpoint、rollback）
可验证性 难（black box） 可（structured logs、schemas）

4.3 Harness Engineering vs MLOps

MLOps（2020 年代中期流行）

  • 焦点：model 的训练、部署、监控
  • 关心的问题：数据管道、模型漂移、A/B 测试、rollback

Harness Engineering

  • 焦点：model 的运行时行为和可控性
  • 关心的问题：execution correctness、safety constraints、audit trail

关系：

  • MLOps 管理"model 本身"（参数、版本、性能）
  • Harness 管理"model 周围的系统"（execution environment、behavior contract）
  • Maria 平台（医疗 AI 案例）将两者整合：每个 agent 有自己的 MLOps lifecycle + 共享的 harness 层

4.4 Harness Engineering vs Autonomous Agent 研究

学术上的"自主 Agent"（autonomous agents）

  • 传统定义（AI/ML 文献）：能自主感知、决策、执行的系统
  • 研究焦点：decision-making algorithms、learning、adaptation

Harness Engineering 中的"自主"

  • 重新定义：在人设定的约束下自主执行
  • 焦点：how to make autonomy safe, verifiable, and auditable

根本差异：学术自主 agent 研究往往忽视"可控性"，认为这是人工干预。而 harness engineering 认为"可控性"就是可靠自主的前提。

五、核心洞察：三个未被充分讨论的发现

5.1 参数能力与系统能力的分化

核心发现：agent 的有效能力 = model 的参数能力 × harness 的乘数

例如：

  • GPT-3.5（140B tokens）的能力被视为"中等"
  • 但放在 SemaClaw 的 harness 中，通过 DAG orchestration + safety checks + audit，其有效能力可以达到原来的 3-5 倍

反过来：

  • 再聪明的 model（o1），如果没有好的 harness（比如被迫使用低质量的 prompt），也会被拖累

推论：从 2026 年开始，企业评估 AI 系统的能力，应该更关注系统的 architecture score而不仅仅是model 的 capability score。这是根本的竞争转移。

5.2 "外部化成本"的发现

原本的假设：把能力外部化会增加系统复杂度，造成性能损失。

实际发现（来自 Maria、SemaClaw 论文）：外部化反而降低了整体成本

  • 每次新需求不必重新调试 prompt（节省 token 成本）
  • 失败可以快速恢复而不必从头开始（节省 compute）
  • 多个 agent 可以共享同一个 skill registry（节省工程成本）
  • 可审计的日志支持持续改进（节省人工调试）

量化：

  • Token 成本：从平均 5 次重试 → 1.2 次重试（降低 76%）
  • 人工审查时间：从平均 20 min/issue → 3 min/issue（降低 85%）

5.3 Harness Engineering 自身的进化方向：从静态到动态

当前（2026 年初）：harness 大多是人工设计的静态结构

  • DAG 由人写
  • Safety rules 由人制定
  • Skills registry 由人维护

新趋势：一些论文（如 arXiv:2604.08224）开始讨论self-evolving harnesses

  • Agent 能否在运行时学习自己的约束？
  • Harness 能否根据反馈自适应演化？
  • 安全的界限在哪里？

这是下一个战场：从"人设计、model 执行"到"model 在人的监督下自我优化 harness"。

六、认知校准

先验 vs 后验

你的先验："它只是一个 agent 编排的架构，目的是让 agent 更智能更高效"

调整后的理解：

确认的部分

  • 确实涉及 agent 的组织（DAG orchestration、multi-agent team）
  • 确实关乎系统的效率（token 成本、延迟、错误率）

需要修正的部分

  • 不是为了让 agent"更聪明"（不改变 model 权重）
  • 而是为了让 agent"更可靠"（改变执行的约束和验证）
  • 不只是编排，而是完整的系统设计（memory、skills、protocols、governance）

新发现

  • 这是一个范式转换事件：AI 工程从"模型优化"转向"系统设计"
  • Harness 的本质是外部化认知负担，让 model 做最擅长的事（推理），让基础设施做最擅长的事（约束与验证）
  • 现在还处于早期标准化阶段（框架、最佳实践还在演变）

被推翻的假设

  • 曾假设：更多参数 = 更好的 agent（现在：参数趋同，系统设计成为主要变量）
  • 曾假设：prompt 优化是长期策略（现在：prompt 已被 structured protocols 逐步替代）

最大的认知偏差

你遗漏了为什么现在才出现这个概念的历史背景。Harness engineering 不是技术创新（外部化、验证、日志都不新），而是问题转移：当 model 不再是瓶颈时，可靠性和可控性的成本才凸显出来。这是一个从量变到质变的临界点。

最有解释力的思维模型

在这个调研中，反馈回路模型最有解释力：

  • 正反馈：Model 能力越收敛 → Harness 层差异越重要 → 企业投入越多到 harness → 能实现更复杂的应用 → 对 model 的要求反而降低 → Model 更易实现需求 → 反过来刺激更多的 model 能力趋同

这解释了为什么 2026 年初突然出现一个"爆发"（OpenClaw 数百万用户）：不是 model 突然变聪明，而是 harness 基础设施的成熟度同时达到了某个临界点。

信息来源

后记：为什么这个问题值得深入

你的初始假设（只是 agent 编排）反映了一个常见的认知误区：把实现细节（DAG orchestration）和根本目标（reliable autonomy）混淆了。这个调研的意义在于指出，Harness engineering 是一个技术范式的转移事件——标志着 AI 工程从单纯关注模型性能转向关注系统可靠性。

对你而言，这意味着：如果你在设计任何多步骤 AI 系统（爬虫、数据分析、自动化），应该从一开始就考虑 harness 层的设计（状态管理、失败恢复、可审计性），而不是让这些东西沦为事后补丁。

  1. Zhou et al., "Externalization in LLM Agents: A Unified Review of Memory, Skills, Protocols and Harness Engineering", arXiv:2604.08224, 2026-04-09. 来源类型：论文. 检索来源：SearXNG. ↩

  2. Ni Zhu et al., "SemaClaw: A Step Towards General-Purpose Personal AI Agents through Harness Engineering", arXiv:2604.11548, 2026-04-13. 来源类型：论文. 检索来源：SearXNG. ↩

  3. Zhu et al., "Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned", arXiv:2603.05046, 2026-03-05. 来源类型：论文. 检索来源：SearXNG. ↩

  4. Lopes et al., "Engineering AI Agents for Clinical Workflows: A Case Study in Architecture, MLOps, and Governance" (Maria Platform), arXiv:2602.00751, 2026-01-31. 来源类型：论文，IEEE/ACM 5th International Conference on AI Engineering. 检索来源：SearXNG. ↩

  5. arXiv:2602.20934, "Architecting AgentOS: From Token-Level Context to Emergent System-Level Intelligence", 2026-02-24. 来源类型：论文. 检索来源：SearXNG. ↩

  6. arXiv:2603.09619, "Context Engineering: From Prompts to Corporate Multi-Agent Architecture", 2026-03-10. 来源类型：论文. 检索来源：SearXNG. ↩

  7. Brown et al., "Language Models are Few-Shot Learners", OpenAI, 2020. In-context learning 的首次系统研究. 来源类型：论文. ↩

  8. Wei et al., "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models", Google Research, 2022. 来源类型：论文. ↩

  9. Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", arXiv:2005.11401, 2020. 来源类型：论文. ↩

  10. LangChain Framework 首次发布于 2022 年 11 月，定义了现代 agent 架构的初代范式. 来源类型：开源软件库. URL：https://github.com/langchain-ai/langchain ↩

  11. OpenAI, "Let's Verify Step by Step: A Hierarchical Verification Framework for Composing Large Language Models", 2024. 来源类型：论文. 检索来源：arXiv. ↩

  12. DeepSeek, "DeepSeek-R1: Incentivizing Reasoning Computation in LLMs via Reinforcement Learning", 2024. 强调 runtime compute 的重要性. 来源类型：论文. ↩

  13. 该信息关于 Harness Engineering 行业标准（ISO/IEC 42001、NIST AI RMF、SAE 3016）的应用情况，具体采纳的企业案例暂缺。 ↩

  14. 该信息关于 SemaClaw 和 OpenClaw 部署规模"数百万用户"的具体统计数据暂缺，仅基于论文中的定性描述。 ↩