核心要点
Harness 是编排中间层：构建在模型能力与用户需求之间，处理超时重试、权限回退、成本控制、可观测性等模型本身无法解决的工程问题，决定模型能力能否转化为可靠产品体验。
Harness Tax 概念：指模型推理之外的全部工程开销（工具编排、上下文拼装、重试、状态管理、护栏校验）占总成本的比例；同一模型套在不同 Harness 里，完成同一任务的 Token 消耗可相差数倍。
架构比模型更影响 Token 效率：当模型能力趋于同质化，Token 浪费主要来自编排层——冗余上下文重复注入、无效工具往返、过度重试，所以 Harness 架构比底层模型更决定编码 Agent 效率。
降低 Harness Tax 的手段：精简上下文（只注入当前步骤必需信息）、缓存中间产物、按需升级模型（简单子任务用便宜模型）、可观测性驱动调优（用 Trace 定位 Token 浪费点）。
简要回答
Agent Harness 是构建在模型能力与用户需求之间的可靠编排中间层，负责超时重试、权限回退、成本控制、可观测性等模型本身解决不了的工程问题。Harness Tax 指模型推理之外的工程开销占总成本的比例——同一个底层模型套在不同 Harness 里，完成同一任务的 Token 消耗可能相差数倍。差异不来自模型而来自编排层：冗余的上下文重复注入、无效的工具往返、过度的重试都会推高 Harness Tax。所以 Harness 架构比底层模型更影响编码 Agent 的 Token 效率。降低手段包括精简上下文、缓存中间产物、按需升级模型、用可观测性 Trace 定位浪费点。这正是 AIEWF 2026 把 Harness Engineering 列为定义性技能的原因——价值正从模型转移到编排层。
标准回答
一、什么是 Agent Harness
Agent Harness 是构建在 AI 模型能力与用户需求之间的可靠编排中间层，负责处理超时重试、权限不足、任务回退、成本控制等模型本身无法解决的工程问题，决定了模型能力能否转化为可靠的用户体验。它通常包含四层：意图解析层（把自然语言转为结构化任务）、规划层（分解子步骤、确定顺序与回退策略）、执行层（调用工具、管理状态、处理超时重试）、护栏层（安全校验、成本控制、权限检查、输出过滤）。设计原则是"模型可以犯错，但产品不能崩溃"——通过重试、回退、降级把模型的不可靠性封装在 Harness 内部。2026 年 7 月 AIEWF 把 Harness Engineering 列为定义性技能，Ryan Lopopolo 提出"Agents are not hard. The harness is hard."
二、什么是 Harness Tax
Harness Tax（编排税）指 Agent 系统中模型推理之外的全部工程开销占总成本的比例，包括工具调用编排、上下文拼装、重试回退、状态管理、可观测性与护栏校验。这些开销本身不直接产生业务价值，却是系统可靠运行必需的。关键洞察是：同一个底层模型，套在不同的 Harness 里，完成同一任务的 Token 消耗可能相差数倍。这个差异完全不来自模型，而来自编排层的设计质量。
三、为什么 Harness 架构比底层模型更影响 Token 效率
当模型能力逐渐趋于同质化（多家前沿模型在编码基准上分数接近），决定一个编码 Agent 实际 Token 效率的，越来越不是"用了哪个模型"，而是"Harness 怎么编排"。Token 浪费主要来自编排层的三类问题：第一，冗余的上下文重复注入——每一步都把大量其实当前不需要的信息塞进上下文，导致每次调用都为无关内容付费；第二，无效的工具往返——工具调用编排不当，反复调用、来回传递大体积工具输出；第三，过度的重试——错误恢复策略粗暴，一遇错误就整段重跑而非精准重试。这些都是 Harness 设计问题，换更强的模型不仅不能解决，反而因为更贵而放大浪费。
四、降低 Harness Tax 的工程手段
第一，精简上下文——只注入当前步骤必需的信息，用检索或摘要替代全量灌入，避免每步都重复携带历史。第二，缓存中间产物——对重复或相似的子任务结果做缓存，避免重复计算和重复调用。第三，按需升级模型——简单子任务用便宜模型，只在真正复杂的步骤升级到贵模型，结合任务复杂度分类器做模型路由。第四，可观测性驱动调优——为每次执行生成 Trace，关联所有模型调用与工具调用，用 Trace 定位 Token 浪费点，针对性优化。这四者本质都是把 Token 花在刀刃上。
五、范式含义
从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的演进，标志着 AI 工程抽象层级不断提升。当模型能力趋于同质化，Harness 工程质量成为 Agent 产品体验与成本的决定性变量。对编码 Agent 尤其如此——编码任务长、工具调用多、上下文大，编排层的浪费会被放大。所以优化编码 Agent 成本，第一优先级往往不是换模型，而是审视 Harness 架构。
常见误区
⚠️ 常见踩坑
误区一：以为 Token 效率主要由模型决定。 当模型能力同质化，同一模型在不同 Harness 里 Token 消耗可差数倍，编排层才是主因，换更贵模型反而放大浪费。误区二：把 Harness 当成"胶水代码"轻视它。 Harness 处理的是可靠性、成本、可观测性等决定产品成败的工程问题，AIEWF 2026 把它列为定义性技能，绝非可有可无。误区三：上下文"宁多勿少"。 每步都灌入全量历史看似稳妥，实则是 Harness Tax 的最大来源之一，应该只注入当前步骤必需信息。误区四：重试策略粗暴。 一遇错误就整段重跑会成倍推高 Token 消耗，应该精准定位失败点做局部重试，并配合缓存避免重复计算。
追问
追问 1：Harness Tax 和 Context Engineering 是什么关系？
**Context Engineering 是 Harness 工程的核心子集。**Context Engineering 是 Harness 工程的核心子集，专注于"喂给模型的上下文如何组织"，而 Harness Tax 是衡量整个编排层开销的经济学概念，上下文拼装是其中最大的一块。两者关系可以这样理解：Context Engineering 做得好，直接降低 Harness Tax 里"上下文拼装"这一项的成本。冗余的上下文重复注入是 Harness Tax 的主要来源，而 Context Engineering 的手段——按需检索、摘要压缩、动态裁剪、只注入当前步骤必需信息——正是针对这块的优化。但 Harness Tax 比 Context Engineering 更宽，还包括工具往返、重试、状态管理、护栏校验等开销。所以可以说：Context Engineering 是降低 Harness Tax 的最重要杠杆，但不是唯一杠杆，完整的 Harness 工程还要管工具编排、重试策略和可观测性。
追问 2：如何用可观测性来定位和降低编码 Agent 的 Token 浪费？
**核心是建立完整 Trace 再做归因。**核心是为每次 Agent 执行建立完整的 Trace，关联所有模型调用、工具调用和中间状态，然后基于 Trace 做归因分析。具体步骤：第一，给每次执行打 Trace ID，记录每次模型调用的输入 token 数、输出 token 数、所用模型、耗时，以及每次工具调用的输入输出体积。第二，做 Token 消耗分布分析——找出哪些子任务、哪些步骤消耗了不成比例的 Token，通常浪费集中在少数环节（比如某步反复注入巨大的工具输出）。第三，识别浪费模式——是上下文重复注入（每步都带全量历史）？是无效工具往返（反复调用同一工具）？还是过度重试（整段重跑）？第四，针对性优化——重复注入就用检索/摘要替代，无效往返就缓存工具结果，过度重试就改精准局部重试。第五，回归验证——优化后对比 Trace，确认 Token 消耗下降且任务成功率不降。关键是把 Token 消耗当作可观测指标持续监控，而不是凭感觉优化，这样每次改动都能量化效果。
追问 3：Anthropic Claude Code 的质量事故说明了 Harness 的什么道理？
**模型没变、体验崩坏，问题在编排层。**Claude Code 质量事故的典型意义在于：用户感知到"质量下降"，但底层模型能力并没有变差——问题出在编排层，某个变更导致工具调用顺序出错。这说明了几件事。第一，用户体验主要由 Harness 决定，而非单纯由模型决定——同样的模型，编排层出问题就会让体验崩坏，这印证了"Agents are not hard. The harness is hard."。第二，Harness 变更需要工程纪律——编排层的改动应该像生产代码一样有自动化回归测试、灰度发布和快速回滚能力，否则一个编排变更就能影响所有用户。第三，可观测性是定位这类问题的关键——如果有完善的工具调用审计和 Trace，这类"工具调用顺序出错"可以在影响少量用户时就被发现并回滚，而不是大面积爆发。第四，它揭示了 Harness 的隐藏风险——编排层的 bug 比模型 bug 更隐蔽，因为模型没变，人们容易误以为是模型退化，从而往错误方向排查。所以这个案例是 Harness Engineering 重要性的最好注脚。
🔗 相似问题
同一考点的不同问法，换着练更稳
延伸学习
按主题分类的相关资源，便于系统复习