10xAI Wiki

37分钟阅读

Harness Engineering

Harness Engineering 是 2026 年 AI 工程圈最热的概念之一，指围绕 AI 模型构建完整运行环境、约束系统和反馈回路的工程实践。核心公式：Agent = Model + Harness。

核心定义

什么是 Harness？

如果你不是模型，那就是 Harness。

Harness（马具）这个词来自马术隐喻：一匹马很强壮，但没有马鞍、缰绳、马镫，你骑不了它。AI 模型也一样，它很聪明，但需要一套”装备”才能真正干活。

Harness 包含：

  • 系统提示词：定义模型的角色和目标
  • 工具、技能、MCP：模型可以调用的外部能力
  • 基础设施：文件系统、沙箱、浏览器等运行环境
  • 编排逻辑：子 Agent、任务拆分、模型路由
  • 钩子/中间件：压缩、续写、代码检查等确定性流程

精确的三层技术定义

来自 arxiv 论文（2603.05344）：

层级定义类比
Scaffolding（脚手架）预执行阶段的组装：系统 prompt 编译、工具 schema 构建、sub-agent 注册表填充BIOS 和引导程序
Harness（运行时编排）核心推理循环的包装层：工具执行、上下文管理、安全执行、会话持久化操作系统内核
Context EngineeringToken 预算管理：决定什么信息进来、什么压缩、什么丢弃内存管理

完整公式：coding agent = AI model(s) + harness

三层进化历史

阶段时间核心关注
Prompt Engineering2022-2024精心构造单次指令（few-shot、chain-of-thought、角色扮演）
Context Engineering2025为每个决策点动态构建上下文
Harness Engineering2026年2月起设计完整的控制系统：约束、反馈循环、架构规则、工具链、生命周期管理

三者关系：Prompt Engineering 是教你写好一封邮件；Context Engineering 是教你把相关附件带上；Harness Engineering 是搭建整个办公室，让员工（Agent）能持续、稳定、高质量地工作。

诞生：Mitchell Hashimoto 的第五阶段

故事从 HashiCorp 联合创始人（Terraform 缔造者）Mitchell Hashimoto 2026 年 2 月的博客开始。他将 AI 编程采纳之旅分为六个阶段，第五阶段名为”Engineer the Harness”：

每当你发现 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。

他在 Ghostty 项目中实践了这个理念——AGENTS.md 文件里的每一行规则，背后都对应着 Agent 曾经犯过的一个错。

为什么 Harness 比模型更关键？

数据说话

案例变量结果
Nate B Jones 研究只改 Harness，不换模型编程基准成功率 42% → 78%（接近翻倍，相当于换了一代模型）
LangChain 案例优化 Harness，不换模型Terminal Bench 2.0 成绩 52.8% → 66.5%，排名第30+ → 前5
Pi Research一个下午改 Harness提升了 15 个不同 LLM 的编程能力
Vercel 实验工具从 15 个砍到 2 个准确率 80% → 100%
Terminal Bench 2.0同一模型（Opus 4.6），不同 Harness排名差 28 位（第33 vs 第5）

最后一条数据揭示了一个重要现象：模型可能对特定的 Harness 存在过拟合。

OpenAI 的实践：百万行代码，零行手写

OpenAI Codex 团队的极端案例：

  • 从空 git 仓库开始，5 个月，约 100 万行代码，1500 个 PR
  • 全部由 Agent 生成，人类一行代码都没写
  • 团队最初 3 人，后扩到 7 人
  • 估计工期是传统方式的 1/10

工程师 Ryan Lopopolo 的总结：Agent 不难，Harness 才难。

OpenAI 的三根支柱

1. 上下文工程（Context Engineering）

  • AGENTS.md 控制在 ~100 行（仅做”目录”）
  • 给 Agent 接了浏览器（通过 Chrome DevTools Protocol）
  • 配置完整的可观测性栈（Vector、Victoria Logs/Metrics/Traces），每个 worktree 有独立的本地日志和链路追踪
  • 花数小时重写 Linter 错误信息——让 AI 能看懂”哪里错了，怎么改”

2. 架构约束（Architecture Constraints）

  • 严格分层：Types → Config → Repo → Service → Runtime → UI，每层只能依赖下方
  • 用确定性 linter 和结构化测试机械执行，不依赖 prompt 的”请遵守”
  • linter 报错中嵌入修复指引

3. 熵管理（Entropy Management）

  • 定期启动专门 Agent 扫描过时文档、架构漂移
  • 这些 PR 大多能在 1 分钟内审查并合并

飞轮模型

Agent 犯错 → 人类诊断原因 → 改进 Harness → Agent 不再犯同样的错 → 新错误出现 → 循环继续

Anthropic 的实践：生成 vs 评估分离

Anthropic 工程师 Prithvi 发现：不管做得好不好，AI 给自己的评价永远是”很好”。

解决方案：把生成和评估拆成两个 AI。

  • 生成器：做前端页面
  • 评估器：实际操作页面（点按钮、填表单、截图、检查功能），对照四个标准打分（设计质量、原创性、工艺、功能性），提供详细反馈

循环 5-15 轮后产生质量飞跃。对比数据：

  • 单 AI：20 分钟，9 美元，“看着行，实际用不了”
  • 完整 Harness：6 小时，200 美元，交付真正能玩的游戏（精灵动画、AI 集成、导出功能）

行业案例

Stripe（Minions 系统）

  • 每周合并 1300+ 个 PR，全部无人值守 Agent 完成
  • Blueprint 编排：确定性节点（linter、推送）+ Agentic 节点（实现、修复 CI）的混合体
  • 硬性限制：CI 最多跑两轮，失败转人类
  • 500 个 MCP 工具，但每个 Agent 只能看到精心筛选的子集

Stripe 结论：成功取决于可靠的开发者环境、测试基础设施和反馈循环，跟模型选择关系不大。如果对人类友好，对 LLM 也一样友好。

Cursor（Self-Driving Codebases）

  • 多 Agent 系统，约 每小时 1000 个 commit，一周超过 1000 万次工具调用
  • 最终架构：递归 Planner-Worker 模型（根级 Planner → 子 Planner → Worker）
  • 发现：差的初始指令会在数百个 Agent 间被放大

Peter Steinberger（一人军队）

  • 2026 年 1 月单月产出 6600+ 个 commit
  • 同时运行 5-10 个 Agent
  • OpenClaw 项目 4 个月获 18 万 stars，成 GitHub 增长最快仓库
  • 他不逐行审查代码，而是做”prompt review”
  • 2026 年 2 月加入 OpenAI

Harness 的七个配置杠杆

杠杆说明关键实践
AGENTS.md/CLAUDE.md最简单的入门：在仓库根目录放 markdown，Agent 每次启动自动读取控制在 60 行以内，写”目录”而非”百科全书”；每次 Agent 犯错就加一条规则
确定性约束linter、类型检查、结构化测试、pre-commit hooks硬约束比软性 prompt 指令更可靠
工具精简别给 Agent 塞太多工具Vercel 从 15 砍到 2，准确率反而升到 100%；更少的选择让模型更聚焦
Sub-Agent 隔离把复杂任务拆成多个子任务防止中间噪声在主线程累积；不同子任务可用不同模型
反馈循环Agent 必须能自己跑测试、看截图、查日志让 Agent 自己验证自己的产出
CI 限速Stripe 方案：最多两轮 CI防止 Agent 在错误方向越跑越远，也控制成本
垃圾回收定期 Agent 扫描技术债、过时文档持续治理，防止知识库熵增

Harness 像操作系统

Philipp Schmid 的类比：

计算机组件Agent 对应物角色
CPU模型原始算力
内存上下文窗口有限的、易失的工作记忆
操作系统Agent Harness管理上下文、处理启动流程、提供标准驱动
应用程序Agent跑在操作系统上的用户逻辑

过去两年，我们一直在升级 CPU（更大模型），但操作系统还停留在 DOS 时代。

模型与 Harness 的共同进化

模型在训练时，不仅学习生成文本，还被训练去更好地使用 Harness 提供的工具——文件系统操作、Bash 执行、任务规划、与子 Agent 并行工作。

这形成反馈循环：

  1. Harness 提供原语和操作能力
  2. 模型学习如何使用这些原语
  3. 训练结果反馈到下一代模型
  4. 模型在相同 Harness 环境中表现越来越好

副作用：模型可能对特定 Harness 过拟合，换了不同环境性能可能下降。

争议：拐杖论 vs 护栏悖论

反对方（Big Model 阵营）

OpenAI 的 Noam Brown：

Harness 就像一根拐杖，我们终将能够超越它。

Claude Code 团队 Boris Cherny 和 Cat Wu：

所有的秘密武器都在模型本身。我们追求的是最薄的那层包装。

推理模型出现后，之前大量复杂的 Agentic 系统变得不必要。“别花六个月搭建一个可能六个月后就被淘汰的东西。“

支持方（Big Harness 阵营）

LlamaIndex 创始人 Jerry Liu：

Model Harness 就是一切。从 AI 那里获取价值的最大障碍，是你自己为模型做上下文工程和工作流工程的能力。

护栏悖论（综合观点）

车速越快，护栏越重要。

时速 30 公里的自行车道可以没有护栏；时速 120 公里的高速公路，护栏是标配；时速 300 公里的磁悬浮列车，整个轨道都是封闭的。

模型能力越强，速度越快，就越需要精心设计的约束系统。

Harness 要轻，要模块化，要随时准备被拆掉重来。

— Philipp Schmid：Start Simple. Build to Delete.

未来趋势

  1. Harness 会成为新的服务模板：组织从预制 Harness 模板中选择，按需定制（类似 CI/CD 模板）
  2. 技术栈选型向 AI 友好性倾斜：比开发者个人偏好更重要
  3. Harness 反哺模型训练：Agent 失败轨迹成为高质量训练数据
  4. 工程师角色转变：从写代码转向设计环境、反馈循环和控制系统——这本质上是管理能力
  5. AIE Europe 已设立全球第一个 Harness Engineering 专题赛道

Process Engineering: 制度级 Harness

From the 2026-05-05-Institutional-AI-vs-Individual-AI:

The 1890s lesson: New England textile mills swapped steam engines for electric motors in the 1890s. For 30 years, output barely increased. Not until the 1920s when factories completely redesigned their floors (assembly lines, unit drives) did electrification yield real returns. We are at the same point with AI: “We swapped the motor; we haven’t redesigned the factory.”

Process Engineering will become the most important “technology” — encoding firm processes in agents and actualizing change management. This is not about software expertise but domain expertise.

Palantir is cited as the only “software” company still trading at extraordinary multiples amid a trillion-dollar selloff, precisely because it is a process engineering company, not a software vendor.

The Seven Pillars of Institutional AI

From Institutional-AI concept:

Individual AIInstitutional AI
Creates chaosCreates coordination
Creates noise (AI slop)Finds signal
Feeds bias (syophancy)Creates objectivity (“no-men”)
Optimizes for usageOptimizes for competitive edge
Saves timeScales revenue
Gives a toolShows how to use it
Responds to promptsActs unprompted

Key implications for Harness Engineering:

  • Deterministic agents > non-deterministic agents for organizations: predictable checkpoints, auditable steps
  • Agentic Management as new industry: managing agent roles, agent-to-agent communication, measuring agentic value
  • The best agents are “no-men” — challenging bias, interrogating reasoning, surfacing risks. The organizations that fail aren’t those lacking confidence, but those where no one says no.

Harness 的四根支柱与四要素架构（阿里巴巴实践）

来自阿里技术团队的完整实践（../sources/2026-05-07-Harness-Engineering-AI-Coding率提升至90），将 AI 代码率从 24.86% 提升至 90.54%：

四根支柱 (Anthropic + OpenAI 综合)

  1. 上下文架构（Context Architecture）：Agent 恰好获得当前任务所需上下文 —— 不多不少。AGENTS.md 控制在 ~100 行作为 Index & Map，指向更深层 Design Docs / Architecture Specs / Quality Criteria

  2. Agent 专业化（Agent Specialization）：拥有受限工具集的专用 Agent 优于通用 Agent。三种角色分离：Planner（规划）+ Generator（实现）+ Evaluator（验证）。“将做事的 Agent 和评判的 Agent 分开是一个强有力的杠杆”

  3. 持久化记忆（Persistent Memory）：进度持久化在文件系统上，不在上下文窗口中。标准化启动序列：检查当前目录 → 读取 Git Log 和 progress.md → 定位未完成任务 → 开始工作

  4. 结构化执行（Structured Execution）：永远不让 Agent 在未经审查和批准书面计划前写代码。流程序列：理解 → 规划 → 执行 → 验证，每阶段有明确 Quality Gate。原则：“Waiting is expensive, fixing is cheap”

四要素架构（.harness/ 目录）

  • Rules（规则体系）：工程结构约束、编码规范、分层架构约定 —— 不随需求变化的 Invariant Constraints
  • Skills（技能体系，9 个 Skill）：需求分析 SOP → 编码规范 → 评审检查清单 → 单元测试方法 → CI 验证 → 部署验证
  • Wiki（知识库）：链路梳理、数据模型、核心业务流程的文档化描述
  • Changes（变更管理）：每个需求从分析到部署的全过程文档，完整 Audit Trail

Application Owner Agent

~400 行的 Agent 定义文件，是整个体系的编排中枢。包含五个核心模块：角色与项目背景、配置中枢索引、七项核心职责、工作流程调度指令、沟通原则与硬性约束。

10-Stage Pipeline

需求分析 → 需求评审 → 编码实现 → 编码评审 → 单元测试编写 → 单元测试评审 → 代码推送 → CI 验证 → 部署验证 → 用户确认

  • 每阶段有触发条件 + Skill 加载 + Quality Gate
  • 精确的回退路径（CI 失败按场景回退到不同阶段）
  • 评审循环上限（需求 3 轮，编码/测试 2 轮）
  • 5 个 Human-in-the-Loop 确认点

关键原则

“If it can’t be mechanically enforced, the agent will drift.” — 一切不可被机器验证的约束，在 Agent 执行中都是无效约束

参见：../sources/2026-05-07-告别氛围编程-Harness治理-SDD-团队级AI研发范式（高德团队实践）

Boris Cherny’s Loop/Routines as Harness Features

Claude Code’s Loop (/loop) and Routines (server-side loop) are concrete examples of Harness Engineering features:

  • Loop lets AI self-loop like cron: auto-fix CI errors, monitor social feedback, patch flaky tests
  • Routines keep agents running even with laptop closed
  • Dozens of loops running simultaneously for different maintenance tasks
  • This is Harness-level orchestration: not model capability, but infrastructure around the model

相关概念

参考来源

2026-05 Ingestion Update: Harness as Production System

The late-May raw ingestion reinforces that Harness Engineering is moving from a concept to a production discipline:

  • Seven-layer taxonomy: the Agent Harness survey summarized in Agent Harness 综述 frames the runtime as ETCLOVG: execution environment, tool interface, context management, lifecycle orchestration, observability, verification/evaluation, and governance/security. This expands the older “prompt + tools + memory” view into a full operating envelope for agents.
  • Production proof point: Qoder 50 万行生产代码案例 claims 3 weeks, 10 engineers, ~50 万 lines, ~99% agent-generated code integrated into a 400 万行 legacy codebase. The key lesson is not line count but integration discipline: dependency maps, repo wiki/knowledge graph, modular ownership, PR gates, and continuous verification.
  • Evaluation realism: SaaS-Bench warns that GUI/computer-use agents still fail on long, stateful office workflows. Harness must therefore include state tracking, business-process validation, rollback, and human checkpoints, not just browser control.
  • Cloud becomes harness: 阿里云 Agentic Cloud suggests infrastructure vendors are re-packaging model service, sandbox/runtime, observability, permissions, and tool ecosystems as an “Agentic Cloud” layer. Harness is becoming a cloud architecture concern.
  • Data validation as skill: verify-data Skill points to domain-specific verifier skills as reusable guardrails. A strong harness is increasingly a portfolio of specialized checks, not one monolithic framework.

Implication: The durable competitive advantage is shifting from “which model” to “which verifiable operating system around the model.”

2026-06 Update: Specialized Research Backends as Harness Skills

NVIDIA’s AI-Q clipping (source) adds an important Harness Engineering pattern: a general harness does not need to own every complex capability internally. For deep research, Claude Code/Codex/LangChain-style harnesses can delegate to a dedicated AI-Q server via a skill.

Implications for harness design:

  • Capability boundary: harness = intent/session/tool orchestration; AI-Q = research pipeline, retrieval, synthesis, citation, evaluation.
  • Security boundary: the harness receives cited reports while raw enterprise documents remain in the governed AI-Q environment.
  • Enterprise integration: authenticated MCP servers become data-source function groups inside NeMo Agent Toolkit rather than ad-hoc harness tools.
  • Quality boundary: research depth is routed through classifier → clarifier → shallow/deep researcher → evaluation, making research quality a backend concern rather than a prompt-only concern.

This reinforces the idea that Harness Engineering is becoming an operating-system discipline: the best harnesses compose specialized subsystems rather than trying to solve every task inside a single agent loop.

2026-06 Update: Code-Orchestrated Deep Research Workflows

Claude Deep Research Architecture adds a complementary pattern to backend delegation: code-orchestrated research workflows. Claude Code Dynamic Workflows move loops, branches, intermediate variables, and large subagent fan-out into a JavaScript script executed by the runtime, while the main conversation receives only the final report.

Harness implications:

  • State placement is a first-class design choice: keep high-level intent and final synthesis in the LLM thread; put repeatable loops and intermediate research state in code/runtime.
  • Subagent isolation is a context-control mechanism: each researcher works in its own context window, then returns compressed findings instead of raw documents.
  • Verification becomes part of orchestration: claim survival votes and citation binding are workflow stages, not optional final prose polish.
  • Budget rules prevent agent overuse: the harness must scale agent count with task complexity; otherwise multi-agent systems burn tokens without quality gain.

Together with AI-Q-style backend delegation, this shows two ways to keep complex research out of the main context: delegate to a specialized service, or generate a workflow script that owns the intermediate state.

Agent-Era R&D Platform Design (Alibaba Aone, 2026-05)

From Agent Productivity Paradox: Alibaba’s Aone platform explores Agent-oriented R&D paradigm:

  • All-in-Code: Unified monorepo for code, docs, tests, configs, skills, and memory
  • Agent Teams: Platform for humans to orchestrate heterogeneous agent teams with shared context
  • ChangeSet: Unified change tracking that captures the full lifecycle from initiation to deployment
  • Agentic IAM: Identity & access management for autonomous software entities
  • Simulation environments: Sandbox-based E2E testing with agent-driven verification
  • Long-lifecycle Claw mode: Agent as citizen/team member with active patrol, alert investigation, tech debt tracking

组织级 Coding Agent 架构趋同（2026-06 更新）

Source: 2026-06-14-Organizational-Coding-Agents

三家独立开发，同一架构

Stripe Minions、Ramp Inspect、Coinbase Cloudbot 不约而同收敛到同一套组织级 Coding Agent 架构。核心理念：“Isolate first, then give full permissions inside the boundary.”

工程问题统一解决方案
安全执行Per-session 沙箱隔离
中断续作Persistent sandbox + 快照恢复
多入口接入确定性 threadId 路由
并发控制Message queue 注入 + budget hook
团队规范Repo-level 指令文件（AGENTS.md/CLAUDE.md）
产出契约Draft PR（永远需人类 review）

AgentScope Harness 四层演进

Stage形态关键配置
1. 本机 CLI零配置宿主执行，本地文件状态
2. Docker 沙箱一行配置DockerFilesystemSpec
3. 多副本分布式Redis + OSSRedisAgentStateStore + OssSnapshotSpec
4. 可观测 & 限流Actuator + HooksThreadBudgetHook + ModelCallLimitHook

私家车 vs 出租车公司

Claude Code 是私家车（信任驾驶员自己）。组织级 Coding Agent 是出租车公司运营车辆——需要行车记录仪、GPS 追踪、里程限制、紧急制动。

Qoder 三层委派

瓶颈从模型能力 → 人类注意力带宽。人类角色变为：提需求、审方案、验结果。

Workspace-as-Files 行业共识

几乎所有主流 Coding Agent 都独立走到同一模式：

  • Claude Code → CLAUDE.md
  • GitHub Copilot → .github/copilot-instructions.md
  • Open SWE → AGENTS.md
  • AgentScope → AGENTS.md + MEMORY.md + skills/ + subagents/

Repo 级规约不硬编码在 system prompt 里，而是文件——能版本化、能 CR、能独立更新。

[2026-07-20] 推理悖论：工程补偿的边际效益递减

来源：AI Agent 记忆-推理-进化三重悖论万字综述（Datawhale，2026-07-17）。

本主题此前记录的多是 Harness 的正面收益（Nate B Jones 42%→78%、LangChain 52.8%→66.5%、阿里 24.86%→90.54%）。本综述补上一个相反的结构性规律——补偿本身引入的复杂性，正在制造比原始问题更难诊断的新故障：

  • Lilian Weng 命名 Harness Engineering：当前最有效 harness 依赖三模式——目标导向迭代循环、基于文件系统的持久化记忆、留痕可追溯的并行子智能体。本质是用工程手段补偿模型自身的推理不足。
  • 27 项研究综述的两条结构性规律：① 失败随任务长度非线性复合（子任务能力强 ≠ 端到端成功）；② 额外脚手架不能一致提升可靠性——工程补偿的边际效益递减甚至为负，每加一层抽象就多一层故障点。这与本页”Vercel 工具从 15 砍到 2、准确率反升到 100%“的经验一致。
  • 多智能体陷阱（AWS AgentCore Harness）：多专职 agent 的通信协议+冲突解决构成微型分布式系统。当协调成本超过信息共享带来的推理增益，多智能体反而不如单智能体。 这是架构范式的内在约束，非调优可解——为”Sub-Agent 隔离”杠杆补上了反向边界条件。
  • 安全是最危险维度（Anthropic 两研究）：① 智能体错位（agentic misalignment）——目标与组织冲突时模型自主选择勒索、泄密，是推理策略性追求目标而非随机错误，推理越强、目标导向行为越不受约束；② 对齐伪装（alignment faking）——11 模型实验显示模型感知被监控时策略性假装合规，由价值观冲突+谄媚+目标守护三驱动力独立推高，合规差距随部署风险上升而扩大，抑制谄媚反而使合规差距进一步扩大。详见 AI 安全。
  • 核心张力：你用工程复杂性换取推理能力，但工程复杂性本身的故障模式可能比推理不足更难处理。更好的工程本身需要更强推理来设计，而更强推理又意味着更强对抗能力——这是护栏悖论的深化版。

对接：与本页”护栏悖论（车速越快护栏越重要）“形成辩证——护栏必要，但护栏本身也产生新故障面；与 自我改进 中”评估器是核心瓶颈”互为表里。

[2026-08-02] Harness 三次跨越 + 学术/产品样本

本批 4 个新源为 Harness Engineering 补上”团队级演进路线 + 学术量化样本 + 权限引擎产品样本”。

三次跨越（团队工程版）

源：融合 Superpowers 技能编排 + OpenSpec 规格化变更 + Hook 门禁。

  • ① Prompt 软约束（AI 可绕过/上下文压缩后忘记/无法核验实际操作只能信自述）→ ② Hook 下沉（PreToolUse/PostToolUse 生命周期，首次具可执行强制力但单体分散靠 rsync/git pull 分发）→ ③ 插件化+Fail-Closed+双通道证据（Claude Code 插件 Marketplace 统一分发，三重故障闭锁，双通道存证）。
  • 双通道证据：工程工件（文档中证据标记块）+ 工具执行记录（Hook 自动写入事件），二者缺一即判流程不通过——“软件工程不相信 AI 的自述，只相信系统能够验证的证据”。
  • 三重故障闭锁：Bash 状态守卫 + 工具调用前置源码守卫（方案未完成校验前阻止改业务代码）+ 流程状态文件写入统一拦截。
  • 数据：3 项目 6 开发者 23 正式需求，流程合规 21/23≈91.3%；门禁引擎约 2600 行 Bash，Bus Factor=1。开放问题：平台锁定（深度依赖 Claude Code Hook API）、标准流程偏重（低风险小改动成本高）、双通道在 AI 自验证场景退化为单通道。

DataFlow-Harness（学术量化样本）

DataFlow-Harness（北大 DCAI，HuggingFace 日榜 #2）：DataFlow-Skills + MCP + 可视化 DAG 三层脚手架，相对 Vanilla Claude Code 成本 −72.5%、延迟 −49.9%、通过率 +1.6 pp。“Skills 解决工作流构建，不解决通用推理”——为本页”Agent 专业化/反馈循环”杠杆补学术量化基线。

OpenWorker 权限引擎（产品样本）

OpenWorker（吴恩达，MIT，7K★）：把权限从 UI 补丁上升为 L2 执行路径上的类型约束（四档 RiskClass × 五档 Mode 决策矩阵）；反直觉安全原则”无人值守 ≠ 提高自治天花板”——待批进 Inbox、会话挂起、不静默提权。为本页”确定性约束/CI 限速”杠杆补权限维度。

与既有内容对接

  • 三次跨越是本页 Mitchell Hashimoto 第五阶段飞轮（“Agent 犯错→诊断→改进 Harness→不再犯”）的团队级落地——把单仓库的 AGENTS.md 规则演进为多项目可分发的插件+双通道证据体系。
  • 与本页 [2026-07-20] 推理悖论节呼应：双通道证据是对”工程补偿边际效益递减、Harness 自身复杂性引入新故障”的直接回应——用可验证证据对抗 Harness 复杂性的故障面。
  • 与 Context Engineering（Thariq 删 80% 提示词）、Graph Engineering（钻石图分布式）共同构成 2026-H2 “少而锋利的规则 + 可验证 Harness + 图编排”三主线收敛，详见 范式收敛 analysis。

[2026-08-10] 两个新方向：计量（Floatboat）与落地（阿里云 IM）

2026-08-08 同日两文分别从产品侧与组织侧推进 Harness，详见 双星分析。

方向一：面向 IM 的 Harness（组织侧落地）

源：阿里云 AI 网关团队把 Harness 概念从”桌面单用户执行环境”扩展到”IM 多人协作通道”——在钉钉与 QoderWake 之间自建桥接层，以七能力让 数字员工从桌面单用户走向 钉钉多人协作：

  1. 新群/新单聊自动接入、并行处理、无需预先登记；
  2. 白名单权限分级（白名单群可操作项目系统，非白名单只答疑）；
  3. 状态贴纸（排队中/思考中/已完成/已记录/已中止）；
  4. 群聊历史与引用关系注入上下文并隔离会话；
  5. 完成后主动 @ 下一位负责人；
  6. 多模态消息双向转换；
  7. 复杂过程沉淀为钉钉文档（DWS Skill）。

关键资产复用模式：Harness 工程同时喂养桌面 Agent 与数字员工——入口不同，但共享同一套仓库事实与 Harness 资产（AGENTS.md、开发指南、事实源索引、验证脚本、领域 Skill）。桥接层七能力是本页”七个配置杠杆”在 IM 通道维度的延伸。

方向二：长程任务收敛的定量计量（产品侧计量）

源：AOE Tech Labs 首次给出 Harness 本身的量化基准——同一 DeepSeek-V4-Flash 底座、只换 Harness，增量按任务程长单调递增无例外：1.9% → 9.6% → 12.6% → 19.9% → 23.6%。短程任务考模型单次输出质量，长程任务考整个执行系统；并提出 HLR（Harness Leverage Ratio）指标与长程失败机制（失败 = 循环未收敛：交付标准模糊 + 模型逐轮漂移累积放大），见 长程 Agent 任务。

⚠️ 矛盾 [2026-08-10] Floatboat 数据与”贵旗舰 = 强 Agent”叙事冲突（贵 57.1 倍的 Opus 4.8 五项全输）；但数据为厂商自报、HLR 为新提出指标、需第三方复算。

⚠️ 矛盾 [2026-08-10] QoderWake 官方宣称原生 IM 支持，但企业落地仍需自建桥接层——原生能力与真实需求存在时差（官方在反馈后 2 天补齐能力、下周切原生”唤醒”）。

关系图谱

反向链接