当前位置：首页 > news >正文

AI 智能体 Harness 架构简析

news 2026/7/10 17:07:41

AI 智能体 Harness 架构：2026 年前沿范式深度解析

一、什么是 Harness？核心定义

2026 年，AI 工程领域形成了一个共识公式：

Agent = Model + Harness

Harness（线束/驾驭系统）是包裹在 LLM 外层的全部工程基础设施——执行循环、工具接口、上下文管理、状态持久化、反馈验证、沙箱隔离、权限治理、可观测性。用一句话定位：“如果你不是模型，你就是 Harness。”

隐喻来源于驯马——模型是强大但不羁的马，Harness 提供方向、控制和安全。这个隐喻的深意在于：马越强，缰绳越重要。GPT-5 和 Claude Opus 4.7 级别的模型如果失控，破坏力远大于弱模型。

二、时代演进：我们怎么走到 Harness Engineering 的

时代	核心关注	核心问题
2022–2024	Prompt Engineering	“我怎么问？”
2025	Context Engineering	“模型应该知道什么信息？”
2026	Harness Engineering	“什么系统能让模型变得可靠？”

2022-2024 年大家在卷 prompt 技巧（Chain-of-Thought、Few-shot、ReAct）。2025 年发现上下文工程才是关键——给模型什么信息比怎么问更重要（RAG、上下文窗口利用、CLAUDE.md/AGENTS.md）。到了 2026 年，头部公司集体意识到：上下文工程之上，还需要一层"操作系统"来管理 agent 的完整生命周期。这就是 Harness Engineering。

三、Anthropic 的方案：“Agent OS”

Anthropic 是 Harness 思想最系统的推动者，将 Harness 定位为智能体操作系统，发表了最多公开论述。

3.1 长时运行 Harness（Long-Running Harness）

核心创新是将工作跨 session 拆分，通过两种 agent 角色接力：

Initializer Agent：负责 setup、生成 feature list、创建 progress file
Coding Agent：增量执行具体工作，每次启动先读取 progress file，做完后更新状态

使用结构化的 JSON feature list，每个 feature 有明确的 Pass/Fail 状态。Agent 可以随时被中断和重启——它是无状态的，状态全在 Harness 管理的持久化层。

3.2 上下文工程（Context Engineering）

渐进式披露（Progressive Disclosure）：短入口文件（CLAUDE.md）→ 结构化文档目录 → 按需读取
上下文窗口利用率建议控制在60% 以下，留足思考空间
信息要"可导航"而非"全量灌入"——索引比全文本重要

3.3 工具设计原则

少而精：少数强大工具 >> 大量狭窄工具。Vercel 从 15 个工具砍到 2 个后，准确率从 80% 飙到 100%
工具是给 agent 设计的，不能从人类 API 直接搬运
工具描述、错误信息、返回格式——每一个细节都影响 agent 的正确调用率

3.4 Planner → Generator → Evaluator 三段式

这是 Anthropic 最重要的架构创新之一：将生成和评估强制分离。

Agent 天然是过于乐观的自我评估者。一个 solo agent 做复古游戏机项目花了 $9 但失败；加上 Evaluator 子 agent 的完整 Harness 花了 $200、跑了 6 小时，但产出了可工作的软件。

三段式的核心逻辑：

Planner：制定计划，拆解任务
Generator：执行计划，产出代码/内容
Evaluator：独立评估产出——跑测试、lint、typecheck、视觉对比，甚至启动另一个 agent 专门"挑刺"

3.5 Managed Agents 三层拆分

将系统拆为三个独立组件：

层	职责
Session	事件日志，记录一切
Harness	Claude 调用循环，工具调度
Sandbox	执行环境，代码实际运行的地方

这种拆分实现了：崩溃恢复（Session/Harness 挂了不影响 Sandbox 状态）、安全隔离、跨 session 连续性。

3.6 Bitter Lesson 适用于 Harness

Harness 的每一行代码都在编码对当前模型局限性的假设。当模型升级后，部分脚手架变成死重，必须拆除。每一行 Harness 代码的半衰期约为 2 个月。

四、OpenAI 的方案：Repo as System of Record

OpenAI Codex 团队用 5 个月产出了~100 万行生产代码，0 行人类手写（约 1500 个 PR），其 Harness 思维的要点如下：

4.1 AGENTS.md 是目录，不是百科全书

~100 行上限，指向结构化docs/目录（设计文档、执行计划、产品规格、参考材料）
巨无霸 AGENTS.md = 维护噩梦 + 侵占稀缺的上下文窗口

4.2 仓库即系统记录（Repo as System of Record）

知识如果不在 repo 里（Slack 讨论、Google Docs、口口相传），对 agent 来说就不存在。所有决策、约束、设计意图必须物化在代码仓库中。

4.3 机械化的架构约束

自定义 linter、结构测试、命名规范、文件大小限制、依赖方向规则
“能被机械检查的，就不要让 agent 猜”
代码审查中最常见的错误类型被固化为 linter 规则

4.4 Agent 可观测的应用

Agent 可以启动应用实例、用 Chrome DevTools Protocol 截图和操作 DOM、查询日志（LogQL）、检查指标（PromQL）。闭环反馈是 agent 自我校正的前提。

4.5 熵管理（Entropy Management）

Agent 会复制已有模式（好的和坏的）。定期后台任务扫描架构漂移、更新质量评分、自动开重构 PR。

4.6 人与 Agent 的分工

“Humans steer, agents execute.”

人转变为系统设计者：将用户反馈转为验收标准，识别缺失约束，喂回 repo 供 agent 消费。人工干预的最大杠杆点在规划阶段，而非代码审查阶段。

五、Google 的方案：方法论体系（Addy Osmani）

Google Cloud 的 Addy Osmani 将 Harness 拆分为五个层次：

层	组件
Context（上下文）	AGENTS.md（短入口）、结构化文档、渐进式披露
Action（行动）	Shell、文件系统、Git、浏览器、MCP、数据库、开发 CLI
Persistence（持久化）	Git 历史、progress 文件、session 日志、决策记录
Feedback（反馈）	测试、lint、类型检查、静态分析、浏览器截图、日志、指标、trace
Governance（治理）	权限、沙箱、hooks、审批门禁、人机协同、清理

Google 的核心方法论：每次 agent 失败，将其编码为 Harness 的一个约束——一条 AGENTS.md 规则、一个 hook、一个工具限制。每个真实的失败变成永久的工程约束。

六、ETCLOVG：学术界的七层框架

CMU / Yale / Tulane / Amazon 联合综述扫描了 170+ 项目，归纳出 7 层标准架构：

E · Execution Environment ── 执行环境 & 沙箱 T · Tool Interface ── 工具接口 & 协议 C · Context Management ── 上下文管理 L · Lifecycle & Orchestration ── 生命周期 & 编排 O · Observability ── 可观测性 V · Verification ── 验证 G · Governance ── 治理

前四层（ETCL）构成结构核心，后三层（OVG）构成控制平面。这个框架已经成为学术界讨论 Agent 架构的通用语言。

七、Agent Loop 即操作系统

2026 年 Harness Inc. 和社区共同推动的一个关键认知转变——Agent Loop 就是新的操作系统：

while (!task_done) { context = observe(environment) // 工具输出、历史结果 plan = reason(context, goal) // LLM 推理 action = select_tool(plan) // 工具选择 result = execute(action) // 工具执行 environment.update(result) // 状态变更 }

OS 概念	Agent 等价物
Kernel	MCP Server / Harness 编排器
Syscalls	Tool calls（统一接口）
RAM	Context window（有限且珍贵）
虚拟内存	Schema discovery（按需分页）
VFS / vtable	按资源类型的注册表分发
文件描述符	Tool handles

LLM 是调度器，工具是系统调用，上下文窗口是内存。智能存在于循环中，不在工具里。

关键设计不变量：

工具数量保持 O(1)——通过数据和分发扩展能力到 O(n)
~10 个通用动词分发到 140+ 资源类型
执行前验证（毫秒级 vs 信任破裂的代价）

八、2026 年前沿论文与工程框架

8.1 Harness Engineering as Categorical Architecture（arXiv: 2605.12239）

Bogdan Banu 提出用范畴论形式化 Harness 设计，用(G, Know, Φ)三元组：

G——句法连线（协议、消息格式）
Know——结构性保证/证书（完整性门禁、质量升级路径）
Φ——部署映射（哪个模型跑哪个阶段）

关键洞察：结构性保证是 Harness 级别的属性，不是模型行为。可以通过编译器函子将证书跨框架保留（LangGraph → CrewAI → Swarms）。

8.2 Polar: Agentic RL on Any Harness（arXiv: 2605.24220）

将 Harness 视为黑盒，代理 LLM API 调用，实现可扩展异步 RL。在 SWE-Bench Verified 上通过简单 GRPO 提升 +22.6 分。这意味着：Harness 的设计直接影响 RL 训练效果。

8.3 Harness-MU: 多用户 Agent Harness（arXiv: 2606.21856）

首个模型无关、零微调的多用户多主体框架。治理约束通过执行 hooks 强制执行，而非依赖 LLM 的概率性推理。权限是确定性的运行时变量，不是 prompt 里的"建议"。

8.4 SwarmResearch（arXiv: 2607.02807）

Orchestrator-Subagent Harness：Shepherd Agent + Search Agent 群，每个 search agent 在自己的 git 分支中用独立上下文运行。实验证明：Harness 层的设计选择（上下文积累方式、单一程序状态）直接限制了探索广度。

8.5 harness-rs：Rust 生产级框架

层	功能
`harness-models`	3 种协议族（OpenAI、Anthropic、Gemini）
`harness-loop`	ReAct + 工具分发 + 传感器反馈
`harness-loop-engine`	成熟度 L1→L2→L3、人工门禁、token 预算
`harness-orchestrator`	并发 Job DAG + 重试/退避 + 动态重规划
`harness-experience`	Episode 录制 + 语义召回（CortexDB）

设计原则：“代码能做的事，不要烧 token”——lint/format/git 通过传感器和 hooks 执行，不走模型。

九、五大经典失败模式与 Harness 修复

所有三家头部实验室收敛到相同的失败模式：

失败模式	根因	Harness 修复
过早宣布胜利（"搞定了！"但实际坏了）	无反馈循环；仅靠自我评估	强制性 test/lint/typecheck 退出码；独立 Evaluator 子 agent
上下文焦虑（接近窗口上限时仓促行事）	上下文窗口压力	progress file + 60-70% 利用率时主动重启
跨 session 遗忘（重复已做的工作）	无持久化状态	PROGRESS.md + AGENTS.md 中"先读 PROGRESS.md"规则
架构漂移	无机械约束	自定义 linter、依赖规则、结构测试
工具过载（选择瘫痪）	工具太多	精简到必要工具；Vercel 从 15→2 个