Agentic Work Atlas

Agent Harness

36分钟阅读

Agent Harness

定义

Agent Harness 是包装 LLM 的完整软件基础设施——编排循环、工具、记忆、上下文管理、状态持久化、错误处理和护栏，将无状态 LLM 转变为有状态的 Agent。Addy Osmani (2026) 总结公式：coding agent = AI model(s) + harness。

核心区分：Agent vs Harness

Agent 是涌现行为——用户交互的目标导向、工具使用、自我纠正实体。Harness 是产生该行为的机器。当有人说"我构建了一个 Agent"，实际意思是他们构建了一个 harness 并指向一个模型。

LangChain 的 Vivek Trivedy 公式："If you're not the model, you're the harness."

Scaffold vs Harness：细粒度区分

HuggingFace（2026）对术语做了更细的拆分，以解决 ICLR 2026 后社区对 harness/scaffold 含义不收敛的困惑：

组件定义类比
Scaffold（脚手架）行为定义层：系统提示、工具描述、输出解析、上下文管理——模型"看到"和"依据"的一切剧本：演员按此表演
Harness（harness，细粒度）执行层：调用模型、处理工具调用、决定何时停止——让 Agent "跑起来"的循环导演：控制何时开拍、何时喊停

两种用法并存:

  • 广义: Harness = 模型之外的一切（Claude Code 官方文档："Claude Code serves as the agentic harness around Claude"）
  • 细粒度: Scaffold（行为定义）+ Harness（执行循环）分离，在训练管线中尤为重要——训练时 scaffold 定义 agent 如何行为，harness 管理 rollout 和梯度更新

实践意义: 当只关注推理侧时，广义用法足够。当需要独立推理行为（scaffold）和执行（harness）时——例如训练管线中 scaffold 不变但 harness 管理并行 rollout——区分才有价值。

Von Neumann 类比

Beren Millidge (2023) 的精确类比：

计算机组件Agent 对应
CPU原始 LLM
RAM（快速但有限）上下文窗口
磁盘（大但慢）外部数据库
设备驱动工具集成
操作系统Harness

"We have reinvented the Von Neumann architecture" — Beren Millidge

长周期 Agent Harness 设计（Anthropic, 2026-06）

Anthropic 的 Justin Young 在 Claude Agent SDK 上实验了跨多个 context window 的长周期 Agent，发现了两个核心失败模式：

  1. One-shotting：Agent 试图一次做太多，在半实现状态下耗尽 context，下个 session 的 Agent 必须猜测之前发生了什么
  2. Premature Declaration of Victory：看到部分进展就宣布任务完成

解决方案是双 Agent 分工：

  • Initializer Agent：首次运行时设置环境——init.sh 脚本、claude-progress.txt 进度文件、200+ feature 的 JSON 列表（所有 feature 初始标记为 passes: false）
  • Coding Agent：每次只做一个 feature，完成后必须 git commit + 写 progress 更新。每次 session 启动时先读 git log 和 progress 文件获取上下文

关键设计决策：

  • 使用 JSON 格式（而非 Markdown）存储 feature 列表——模型更不容易不恰当地修改 JSON 文件
  • 强措辞指令："It is unacceptable to remove or edit tests"
  • 显式要求使用浏览器自动化工具（Puppeteer MCP）做端到端测试——Agent 默认倾向于跳过验证
  • Git 作为检查点机制：允许 Agent 回滚坏变更并恢复工作状态

这个方案验证了 Thin-Harness-Fat-Skills 原则：harness 只需提供环境初始化 + 结构化 artifact + 增量约束，Agent 依靠外部文件系统而非内部状态维持长期进展。

2026-09 补充：Harness 也控制证据入口与组织记忆

四篇新材料把 Harness 的边界从“包裹模型的运行时”推进到三个相互连接的层面：

  • ByteByteGo 说明 embedding、chunk、metadata、版本和 reranker 决定哪些证据有机会进入上下文；更强的生成模型无法修复未被检索出来的事实。
  • Meta 的 Organizational Second Brain 把组织知识、专家 recipes、依赖图、评估和专家反馈编排成可审计的知识运行时，并通过回归测试让纠正产生持久收益。
  • Google 的 harness 实践把 sandbox、失败日志回送、测试节点和 kill switch 组合成可停止的 repair loop；Challenge 案例则展示了双向 MCP、事件并行、统一验证和分层路由等可组合模式。

综合判断：Agent Harness 不只是让模型“能调用工具”，而是规定它能看到哪些证据、能触碰哪些状态、如何从失败中恢复，以及哪些结果才允许离开系统。

Harness 作为能力孵化层：边界会向模型内部移动（2026-09）

Runway 的 video agent 提供了软件 coding agent 之外的一条独立证据：当前系统仍由 LLM 在外部 orchestrate image/video models 与工作流工具，但 Anastasis Germanidis 预期部分规划、剪辑和生成流程会逐渐进入 omni model，并把这一现象概括为“能力先由 harness 做出来，随后成为模型的一部分”（20260925-latentspace-runway-world-models，01:11:41–01:23:12）。

判断：Harness 不只是固定的运行时外壳，也可以是能力原型层 / curriculum discovery layer。当外部 orchestration 反复证明某种任务结构有效，它就可能成为后续训练、post-training 或统一模型吸收的候选；模型能力增强后，Harness 的价值不会归零，而是继续上移到新的边界。

  • 证据：20260925-latentspace-runway-world-models；访谈以 reasoning chain 与 multi-shot video workflow 为例，描述显式 scaffold/orchestration 先出现、随后部分行为被模型原生学习的演化路径。
  • 边界：可内化的是能力模式，不是所有系统责任。 权限、审计、工具访问、确定性验证、状态持久化、成本控制和安全边界具有外部系统语义，即使模型更强也不能仅靠训练“吸收”后删除。

这给 Harness Engineering 增加了一个时间维度：

外部 harness 发现/验证任务结构
        ↓
高频稳定模式进入训练或 post-training
        ↓
部分能力成为模型原生行为
        ↓
harness 上移，负责新的工具、状态、验证和治理边界

因此，判断一个 harness 组件是否“技术债”，不能只问模型以后会不会更强，还要问：它承担的是可学习的认知模式，还是必须独立存在的系统约束？

安全自动化中的 Harness：判断与执行分离（2026-09）

GitHub Security Lab 的 Fuzzing Taskflow（20260924-github-security-lab-ai-fuzzing-taskflow）提供了一个高风险技术域的 Harness 实例：LLM 负责选择 fuzz target、设计 harness、判断 coverage gap 的下一步；MCP tools 负责运行 fuzzer、编译、读取 coverage 与保存 crash；跨阶段状态落在 SQLite，而不是只存在模型上下文里。

判断：高自治 Harness 的关键不是让模型拥有更多原始执行自由，而是把系统拆成：

LLM judgment
    ↓
窄的可审计执行 primitives
    ↓
外部持久状态
    ↓
客观反馈 / stop condition
    ↓
高语义风险结果再交人类复核

这个结构同时降低了上下文依赖和执行面的不可见性。文章中的 coverage plateau 是外部停止条件；漏洞 verdict / patch 标记为 review required，则把不可可靠自动判定的语义边界留给人。

  • 证据：20260924-github-security-lab-ai-fuzzing-taskflow，“The architecture in one minute”“The coverage-feedback loop”“Triage and vulnerability reports”。
  • 边界：当前实现仍可能运行由模型选择的 host build/fuzzing command；作者因此要求 disposable environment。工具封装不等于 containment，仍需 sandbox / least privilege。

Model × Harness 协同与事件驱动 Runtime（2026-09）

OpenAI DevDay 后的 Computer Use / API 访谈（20260930-latentspace-devday-2026）把 Harness 的作用推进到两个更硬的层面。

第一，Ari Weinstein 明确表示 OpenAI 的 Computer Use 模型会在其发行中的 harness 上训练，因此 model 与 harness 不是完全可交换的两层；特定 representation、tool surface、action substrate 和 recovery loop 可能直接进入训练分布。Computer Use 的近期进步也同时来自模型更会重试/调试，以及 harness 引入 accessibility、DOM、Playwright 与生成代码等多种执行路径。

第二，API runtime 正从同步 turn loop 走向异步、双向、事件驱动：async function calling 允许模型在工具运行时继续工作，mid-turn steering 允许工具结果或新指令在 reasoning 中途进入，WebSockets 则承担持续双向通道。与此同时，长寿命 thread 需要 cache pre-warming、长 cache window 与 compaction 共同维持状态和成本。

判断：生产 Agent Harness 的竞争力越来越来自 model-training interface × runtime scheduling × context lifecycle 的协同设计，而不是单独堆更多工具。Harness 既是模型能力的使用环境，也可能成为能力训练分布的一部分。

  • 证据：20260930-latentspace-devday-2026（00:05:20–00:12:02；00:16:03–00:23:21；00:32:35–00:38:56）。
  • 边界：官方 harness 的协同优势来自 OpenAI 一手陈述，来源没有提供同模型在第三方 harness 上的系统对照；平台化也可能提高切换成本，因此不能推出“官方 harness 总是更优”。

Decisions API 又展示了另一类 Harness primitive：高频局部判断可以用受约束、并行、低 time-to-first-decision 的 serving path 处理，而把长程 reasoning 留给更强模型。初版仍使用 Luna 权重，因此这里更准确的稳定抽象是 decision-serving primitive，而不是断言出现了新的 foundation-model 范式。

Harness 作为组合泛化器：RLM 的计算归纳偏置（2026-10）

Alex Zhang 对 Recursive Language Model（RLM） 的定义补充了 Harness 的另一条设计轴。主流 coding-agent harness 常把完整工具轨迹持续追加到主模型上下文，即 trajectory as a prompt；RLM 则把原始上下文外置为可寻址状态，让模型以代码作为主要控制语言，程序化切分问题、调用 subagent、聚合结果，必要时递归调用自身（20261002-latentspace-rlm-alex-zhang，transcript 00:31:01–00:49:15，“Why Claude Code, Codex, and Pi Are So Similar”至“Long Context, Composition, and Locally In-Distribution Tasks”）。

访谈中最值得沉淀的不是“递归”这个动作，而是 Harness 可以规定模型采用什么计算结构。Zhang 报告，在若干训练任务中，检索、聚合、数学和写作等表面不同的问题会收敛为相似的高层程序；在短任务学到的策略还可以迁移到更长任务。RLM 将这种目标描述为 locally in-distribution：整个问题可以是 OOD，但每个局部模型调用尽量保持在模型熟悉的分布内。

判断（综合判断）：Harness 不只是模型外的运行时，也可以成为一种 计算归纳偏置（computational inductive bias）。真正有结构差异的 Harness，可能通过 state representation、decomposition language、subagent topology 和 aggregation program 改变模型可学习、可泛化的任务形态。

证据：20261002-latentspace-rlm-alex-zhang（transcript 00:36:42–00:44:23，“Harnesses as Compositional Generalizers”；00:31:01–00:36:41，“Why Claude Code, Codex, and Pi Are So Similar”；00:44:24–00:49:15，RLM 定义与 locally in-distribution 讨论）；第一作者对 RLM 训练现象、trajectory-as-a-prompt 与 locally in-distribution 的说明。

边界：访谈没有给出完整 benchmark、方差和失败分布；“8–30× 更长任务”等数字应视为作者报告的特定实验结果。局部调用处于训练分布内也不保证 decomposition、共享状态和最终 aggregation 正确。

这一视角还把 Model / Harness 边界变成可研究对象：如果某些高层程序长期稳定，它们可能被 post-training 吸收为模型原生能力；但权限、审计、真实工具执行、持久状态、成本控制和确定性验证仍具有外部系统语义，不应因为模型更强就默认内化。

非工程流程中的 Harness：GitHub Marketing Ops（2026-09）

GitHub APAC 的活动自动化显示，Harness 可以包住一个营销运营流程，而不只包住 LLM 调用：Issue form 定义输入，Issue 保存状态与审计历史，label 提供事件入口，Actions/平台 API 或 CLI 负责确定性执行，AGENTS.md 与 SKILL.md 提供规则和市场化能力，人负责决定与 sign off。

这组设计把 Copilot 放在“理解对话、起草计划”的位置，把可重复的副作用留在可审查的执行系统中。DRY_RUN 是回滚前的演练开关；测试、PR/CODEOWNERS、secret scanning 和数据政策约束变更；定时 workflow 还必须对失败发出可见信号。文章记录的五天静默失败说明：Harness 的 observability 不是附加监控，而是自动化流程的组成部分。

判断（综合判断）：面向组织工作的 Harness，核心边界是“模型提出候选动作，系统控制状态变化与权限，人类承担关键决策”；把确定性约束留在模型外，通常比把整条流程交给模型更容易验证。

证据：GitHub 案例使用 Issue、label、Actions、runbook、Skills、dry-run 和人工 sign off 串联活动全生命周期（见 20260911-github-marketing-ops-as-code）。

边界：这是单一厂商、单一营销团队的案例；其效果和安全性依赖 API/CLI 的能力、权限隔离、数据政策与监控实现，不能仅由“代码化”标签推出。

平台化 Harness：Habitat 的“少做”与集中控制（2026-09）

OpenAI 的 Habitat 展示了更靠近基础设施的一种 Harness：产品团队不直接管理底层数据库，而是通过服务层获得受限的 object/edge API；服务统一处理路由、访问控制、审计、可观测性、容量和数据安全。复杂查询不扩散到在线热路径，而通过 CDC 流向隔离的 Rockset 视图。

这个系统的关键不是“能力最多”，而是“默认工作量可预测”。OpenAI 通过 loop delay、CPU profiling 和线上实验定位 Statsig 配置抖动、LIFO 连接池反馈回路等尾延迟问题，再用 jitter、FIFO、Envoy/Istio 和受限接口拆除它们。Python 先承担快速交付，Rust 后来承担大部分生产流量，Agent 参与降低了重写成本，但边界、验证、流量切换和回滚仍由工程系统与人决定。

判断（综合判断）：当 Agent 或产品调用者的自由度会把不可控成本传给共享后端时，Harness 应把高风险表达力收窄为少量可审计原语，并为例外能力设置隔离出口；“少做”本身是一种规模化能力。

证据：Habitat 的受限 NoSQL API、CDC→Rockset 逃生舱、集中安全控制，以及从 Python 到 Rust 的渐进迁移（见 20260911-openai-habitat-storage-scaling）。

边界：这是 OpenAI 自述的单个平台案例；接口约束的收益取决于 workload、SLO、数据库能力与组织边界，不能推出所有系统都应服务化或改用 Rust。

三层工程

层级范围
Prompt Engineering设计模型接收的指令
Context Engineering管理模型看到什么、何时看到
Harness Engineering以上两者 + 完整应用基础设施

Harness 是 prompt 的包装，而是使自主 Agent 行为成为可能的完整系统。

12 个生产级组件

1. 编排循环 (Orchestration Loop)

心跳。实现 Thought-Action-Observation (TAO) 循环，也称 ReAct 循环：组装 prompt → 调用 LLM → 解析输出 → 执行工具调用 → 反馈结果 → 重复。

Anthropic 称其运行时为"dumb loop"——所有智能在模型中，harness 只管理轮次。

2. 工具层 (Tools)

Agent 的手。定义为 schema（名称、描述、参数类型）注入 LLM 上下文。处理：注册、schema 验证、参数提取、沙箱执行、结果捕获、格式化为 LLM 可读的观察。

3. 记忆 (Memory)

多时间尺度运作：

  • 短期记忆：单次会话内的对话历史
  • 长期记忆：跨会话持久化（CLAUDE.md / MEMORY.md、JSON Stores、Sessions）

Claude Code 三级层次：轻量索引（~150 字符/条目，始终加载）→ 详细主题文件（按需加载）→ 原始记录（仅通过搜索访问）。关键原则：Agent 将自己的记忆视为"提示"，行动前验证实际状态。

4. 上下文管理 (Context Management)

核心问题：上下文腐烂（Context Rot）——随着上下文窗口填充，模型推理和任务完成能力下降，关键内容落在窗口中间位置时性能下降 30%+。

生产策略：

  • 压缩 (Compaction)：接近限制时总结对话历史
  • 观察掩码 (Observation Masking)：隐藏旧工具输出，保留工具调用可见
  • 即时检索 (JIT Retrieval)：维护轻量标识符，动态加载数据
  • 上下文重置 (Context Reset)：对于超长任务，销毁当前会话并根据紧凑的“移交文件（Hand-off file）”重建新鲜上下文（Anthropic 模式）。
  • 子 Agent 委派：每个子 Agent 广泛探索但仅返回 1,000-2,000 token 摘要

目标：找到最小的高信号 token 集合，最大化期望结果的可能性。

5. Prompt 构建 (Prompt Construction)

分层组装：系统 prompt → 工具定义 → 记忆文件 → 对话历史 → 当前用户消息。

OpenAI Codex 优先级栈：服务端系统消息（最高）→ 工具定义 → 开发者指令 → 用户指令（级联 AGENTS.md，32 KiB 限制）→ 对话历史。

6. 输出解析 (Output Parsing)

现代 harness 依赖原生 tool calling，模型返回结构化 tool_calls 对象。检查：有工具调用？执行并循环。无工具调用？那就是最终答案。

7. 状态管理 (State Management)

LangGraph：类型化字典流过图节点，super-step 边界检查点。Claude Code：git commits 作为检查点，进度文件作为结构化草稿本。

8. 错误处理 (Error Handling)

10 步流程，每步 99% 成功率 → 端到端仅 ~90.4%。错误快速复合。

四种错误类型：瞬态（退避重试）、LLM 可恢复（返回错误作为 ToolMessage）、用户可修复（中断等待人工）、意外（上报调试）。Stripe 生产 harness 限制重试不超过两次。

9. 护栏与安全 (Guardrails & Safety)

三级：输入护栏、输出护栏、工具护栏。"绊线"机制触发时立即停止 Agent。

Anthropic 架构分离：模型决定尝试什么，工具系统决定允许什么。Claude Code 独立门控 ~40 个离散工具能力。

10. 验证循环 (Verification Loops)

区分玩具 demo 与生产 Agent 的关键。三种方式：基于规则的反馈（测试/linter/类型检查器）、视觉反馈（Playwright 截图）、LLM-as-Judge（单独子 Agent 评估输出）。

Boris Cherny：给模型验证自身工作的方式，质量提升 2-3x。 在生物学等高精度领域，这层演化为**确定性检索层**（如 gget-virus），将混乱的界面操作转化为机器可验证的可靠步骤（Anthropic, 2026）。

11. 子 Agent 编排 (Subagent Orchestration)

Claude Code 三种执行模型：Fork（父上下文字节级复制）、Teammate（独立终端窗格 + 文件邮箱通信）、Worktree（独立 git worktree + 隔离分支）。

12. 安全执行环境 (Sandboxed Execution)

工具在沙箱环境中执行，读取操作可并发，变更操作串行。

7 个架构决策

1. 单 Agent vs 多 Agent

Anthropic 和 OpenAI 都说：先最大化单 Agent。多 Agent 增加开销（额外 LLM 调用、上下文丢失）。仅在工具过载超过 ~10 个重叠工具或明确分离的任务域时才拆分。

Hao 好聊趋势的 multi-agent 组织病文章补充了第二个理由：多 Agent 不只是增加工程开销，也会引入 组织病理。harness 可以治理动作、权限和上下文，但如果 Agent 需要彼此讨论、形成共识或接受不可见编排，还会出现从众、责任稀释和 内态解离 这类更深问题。

2. ReAct vs Plan-and-Execute

ReAct 每步交织推理和行动（灵活但每步成本高）。Plan-and-Execute 分离规划与执行。LLMCompiler 报告比顺序 ReAct 快 3.6x。

3. 上下文窗口管理策略

五种生产方案：基于时间的清除、对话总结、观察掩码、结构化笔记、子 Agent 委派。ACON 研究通过优先推理痕迹而非原始工具输出，实现 26-54% token 减少同时保持 95%+ 准确率。

4. 验证循环设计

计算验证（测试/linter）提供确定性 ground truth。推理验证（LLM-as-Judge）捕获语义问题但增加延迟。Martin Fowler 框架：guides（前馈，行动前引导）vs sensors（反馈，行动后观察）。

生产级 harness 的问题不只是“有没有 sensor”，而是 sensor 是否分布在正确时间尺度、是否会给 Agent 太多噪声，以及反馈文本本身是否足够可执行。

5. 权限与安全架构

宽松（快速但有风险）vs 严格（安全但慢）。取决于部署上下文。

6. 工具作用域策略

更多工具往往意味着更差的性能。Vercel 从 v0 中移除 80% 工具后效果更好。Claude Code 通过懒加载实现 95% 上下文缩减。 原则：暴露当前步骤所需的最小工具集。

7. Harness 厚度

多少逻辑放在 harness 中 vs 模型中。Anthropic 押注薄 harness + 模型改进。图框架押注显式控制。Anthropic 定期从 Claude Code 的 harness 中删除规划步骤，因为新模型版本内化了该能力。

IBM Research 的 agent logic 给这个问题增加了企业侧边界：在强结构工作流中，harness 不应只做模型调用和工具循环，还应承载知识图谱、程序分析、策略执行、图遍历和验证逻辑。判断标准不是”harness 越厚越好”，而是稳定、可验证、低熵的企业约束应留在模型外，开放、语义、跨上下文的部分才交给 LLM。

Natural-Language Agent Harnesses (NLAH) 提出了另一种可能：把驾驭策略从代码中外置为可执行的自然语言文档。消融实验首次用数据回答了”harness 该保留哪些模块”——文件持久化状态是最稳正贡献，多候选搜索和上下文压缩反而有害。

脚手架隐喻

建筑脚手架是临时基础设施，使工人能够到达无法触及的楼层。它不做建筑工作，但没有它工人到不了高层。关键洞察：建筑完成时脚手架被拆除。 随着模型改进，harness 复杂度应降低。

Manus 在六个月内重建了五次，每次重写都移除了复杂性。复杂工具定义变成通用 shell 执行。"管理 Agent"变成简单的结构化交接。

共进化原则：模型现在在训练时将特定 harness 纳入循环。Claude Code 的模型学会了使用它被训练的特定 harness。更改工具实现可能因这种紧密耦合而降低性能。

面向未来的测试：如果性能随更强大的模型提升而无需增加 harness 复杂度，设计就是正确的。

Harness 即平台：Cursor Automations 与 SDK

Cursor 2026 春季报告揭示了 harness 演化的下一个阶段：从开发者工具变成可编程平台。

  • Cursor Automations: 自动化工作流（安全审查为首个强用例），采用增长迅速
  • SDK runs: 将 Cursor 的 agent 基础设施作为可编程平台，按公司自定义方式构建和维护软件
  • 平台化信号: harness 不再只是单个开发者的编码助手，而是整个团队的软件构建系统
  • HaaS (Harness-as-a-Service): 从构建底层 API 转向构建 Harness 运行时 API。开发者不再从零构建循环，而是基于成熟的 Harness SDK 进行场景化配置。

演化路径

单 Agent harness → 多 Agent harness → 自动化 harness → harness 即平台（SDK + Automations） → HaaS (Harness-as-a-Service)

Microsoft Foundry 五层生产架构（2026-07）

Microsoft Core AI VP Marco Casalaina 描述了生产级 Agent Harness 的五层架构：

层级功能Microsoft 实现
Inference统一模型接口，模型可替换支持 11,000+ 模型（OpenAI/Anthropic/xAI/DeepSeek/MAI）
Agent Runtime编排循环、工具调用、对话状态框架中立（LangChain/LangGraph/CrewAI 可互换）
Observability跨项目 fleet 可见性、健康评分、drift 检测Foundry Control Plane → Azure Monitor
IdentityAgent 作为独立 principal 的身份和审计Entra 扩展（目录条目、角色分配、邮箱）
Context多源检索 + 行动面四个 IQ 服务通过 MCP 调用

关键架构模式：Retrieval-as-a-Subagent（上下文层）、Distinct-Principal-Identity（身份层）、Rubric-Based-Evaluation（评估层）。

核心判断："The harness matters as much as the model"——Claude Opus 4.8 发布后，GitHub Copilot CLI 团队必须重新调优 harness 并重新运行评估才能上线。

关键数据点

  • LangChain 仅改变 harness（同一模型、同一权重）就从 Top 30 外跃升至 TerminalBench 2.0 第 5 名
  • 独立研究项目通过让 LLM 自身优化 harness 实现 76.4% 通过率，超越手工设计系统
  • 上下文窗口中间位置内容使模型性能下降 30%+
  • Vercel 移除 80% 工具后效果更好
  • Claude Code 通过懒加载实现 95% 上下文缩减
  • LLMCompiler 比顺序 ReAct 快 3.6x
  • ACON 实现 26-54% token 减少，保持 95%+ 准确率
  • 10 步流程每步 99% 成功率 → 端到端仅 ~90.4%
  • 验证循环使质量提升 2-3x（Boris Cherny）
  • Claude Code 独立门控 ~40 个离散工具能力
  • Cursor Automations 采用增长迅速，安全审查为首个强自动化用例；SDK runs 展示 harness 向可编程平台的演化（Cursor, 2026 春季）
  • Cursor 持续改进 agent harness 以优化跨模型和提供商的 token 缓存（Cursor, 2026 春季）
  • Anthropic 研究显示：科学 Agent 在无专用工具时检索准确率低至 16.9%，引入确定性检索层 gget-virus 后升至 99.7%（2026）。
  • Manus 六个月内重建五次

前提与局限性

  • Harness 有效性高度依赖具体模型——更换 harness 可能只是针对特定 benchmark 优化，而非通用能力提升
  • "薄 harness"假设模型能持续内化当前 harness 功能，但新能力可能只是增加新的复杂性维度
  • 共进化原则暗示模型和 harness 的锁定效应——更换 harness 需要重新训练模型
  • 12 组件框架是对多个框架的综合抽象，实际实现中组件边界可能模糊
  • 大部分数据来自框架自述（Anthropic、OpenAI、LangChain），独立验证有限

关联概念

四层循环堆叠模型（2026-06 更新）

LangChain（Vivek Trivedy）提出的四层模型是 Agent Harness 的分析框架，不是最优结构：

四层结构

层级功能必要性
Agent loop基础循环：感知-思考-行动必须
Verification验证层：检查输出是否正确必须
Event-driven事件驱动：处理外部事件和中断可选
Hill climbing自我改进：从错误中学习并优化可选

关键洞察

  1. Verification 是必须的，其他层是可选的：没有验证的 Agent 是危险的——它可能自信地输出错误结果
  2. 验证深度取决于风险等级：风险等级 = 失败成本 × 检测难度 × 影响范围
  3. 四层模型是工具箱，不是最优结构：每层可选，根据场景决定
  4. 企业需要标准化验证策略：预定义风险等级 + 标准化流程 + 异常处理

验证深度框架

风险等级失败成本检测难度影响范围验证深度
低风险可逆显性局部基本验证（编译/测试）
中风险部分可逆中等多个系统标准验证 + 人工审查
高风险不可逆隐性全局深度验证 + 多层检查 + 事后审计

Harness-Bench 测试结果

  • 配置级差异导致 23.8 分的性能差距
  • 可观测性是关键因素
  • 简单循环 + 良好提示可能就够了（Simon Willison 视角）

关系图谱

反向链接