从AI Agent系统出发，解析Harness Engineering的本质与技术谱系

引子

最近，Harness Engineering 从一个相对松散的圈内说法，逐步变成agentic systems讨论中的显学。Thoughtworks 把它明确写成一种面向coding agents的“外层 harness”；OpenAI 把它落到Codex的开发实践中；Anthropic既在长时应用开发的工程文章里讨论harness design，也在agent eval的方法文中把“agent harness/scaffold” 作为专门术语界定； Phil Schmid，Martin Fowler则更直接地把harness提升为 2026 年AI agent systems的关键基础能力之一。行业的关注点，正在从“模型会不会”转向“系统怎么跑”。但也正由于这个概念突然升温，概念很容易被炒作的过大，Harness Engineering值得认真对待，但需要我们认清其技术边界的前提下。

我认为Harness Engineering的新意，主要不在单点技术发明，而在于工程对象的重构，它没有重新发明测试、监控、回滚、隔离、审批、根因分析这些能力,而是把这些原本分散在AI Safety/系统可靠性等不同工程传统里的能力，围绕agent runtime重新组织成一层更清晰的运行系统。那它和我们熟悉的AI Safety工程，AI系统可靠性工程联系和区别到底在哪里呢？我们从头开始说。

一、从AI Agent Systems出发：Harness 为什么会自然长出来

如果从大模型应用的演化路径看，Harness 的出现几乎是必然的。早期系统主要是单轮问答、单次生成、短路径推理，工程焦点自然围绕模型能力本身：谁在benchmark上更强，谁的知识覆盖更广，谁的静态推理更好。可一旦系统进入agent形态——多步规划、工具调用、状态延续、跨session执行、与外部环境持续交互——问题中心就不再只是模型本身，而是模型被放进了什么运行结构里：谁管理上下文，谁执行业务工具，谁维护任务连续性，谁在异常时拦截、诊断、恢复。

Phil Schmid在2026年初的Blog文章里把这个转折说得很直接：顶级模型在静态榜单上的差距正在收窄，但一旦任务拉长到几十次、上百次tool calls，差距会重新显现；真正拉开差距的，不再只是单步“机智”，而是durability，也就是模型在长期执行中持续遵循目标、维持中间状态和避免逐步偏航的能力。行业需要的是能证明模型可以可靠执行multi-day workstreams的系统，而不仅是更美丽的单次分数。这个判断，本质上就是在说：agent的瓶颈已经从推理问题转成运行问题。

因此，Harness更准确的定义不应只是“安全护栏”或“外围脚手架”。综合 Phil Schmid、Anthropic、Thoughtworks 和 OpenAI 的表述，我会把它定义为：围绕 agent runtime 建立的一层外部运行系统，用来管理上下文、工具调用、生命周期、反馈回路、权限边界、诊断机制和恢复路径，从而让 agent 在长时、多步、真实环境任务中保持可靠、可控、可转向。

Phil Schmid 的类比尤其有启发性：Model = CPU，Context Window = RAM，Harness = Operating System，Agent = Application。这个类比之所以好，不在于它完全精准，而在于它把 Harness 从“配套设施”提升成“运行层”。在这个视角里，模型提供原始智能，context window 提供短期工作内存，而harness负责引导启动、组织上下文、处理tool drivers、管理生命周期，并让上层agent逻辑能够运行。也就是说，Harness不是agen本身，但agent没有它很难稳定成为一个系统。

Anthropic在agent eval的文章里实则给了一个很重大的补充定义：agent harness（或scaffold）是让模型能够作为agent行动的系统，它负责处理输入、编排工具调用并返回结果；因此当我们评估“一个 agent”时，实际上评估的是 harness 和 model 共同构成的系统。 这个定义有两个后果：第一，agent不是模型单体。第二，所谓“agent 表现”，从方法论上就已经是系统性能，而不是纯粹的模型性能。

OpenAI与Anthropic的实践说明，今天真正困难的地方已经不只是“让模型会写代码”或“让模型会调用工具”，而是构建环境，反馈回路机制及系统控制。OpenAI 明确写道，他们最难的问题聚焦在设计环境、反馈回路和控制系统上；Anthropic 则反复强调harness design对前沿 agentic coding 表现的重大性。换句话说，当agent真正进入长链条执行时，最贵的工程资产开始从模型本身转移到运行结构本身。

Harness不该被仅仅写成AI safety和可靠性的一个子话题。AI safety很重大，但它只是这个运行层必须吸收的一组约束；系统可靠性也很重大，但它也只是另一组机制来源。Harness 更像二者在agent runtime 中的交汇层：它一方面承接长时任务、环境交互、工作流编排这些agent-system需求，另一方面把风险边界、可观测性、故障隔离、恢复机制、人工接管等能力编织进一个持续运行的闭环里。

二、Harness的前史：不只是一套控制机制，也是一套异常发现与定位机制

传统如果把Harness Engineering当作一门全新的技术，就会误读它。更准确的定义应该是多条传统工程的交汇。这里至少有两条主线：第一条是控制与韧性传统：SRE、error budgets、canary release、chaos engineering、circuit breaker、bulkhead。第二条是异常检测与诊断传统：observability、anomaly detection、fault localization、root cause analysis、AIOps。Harness今天看起来像一层新工程对象，不是由于它突然发明了某个零件，而是由于它把这两条线围绕agent runtime重新合并了。

第一看控制与韧性线。SRE的重大贡献是把系统运行写成一个明确的控制回路：先定义目标，再持续观测偏差，再用可量化阈值决定是否允许继续激进变更。虽然这里没有引用Google原书细节，但这条思想后来几乎成了现代可靠性工程的底座。Harness在agent系统里继承的也是同样的逻辑：不是让agent无边界地自动运行，而是让它在一组明确的约束、预算和停止条件内运行。

Canary release的思想也高度同构：不要一次性把新版本暴露给全部流量，而是先在一个小范围、可观测、可比较、可回滚的区域里看它是否引入副作用。映射到agent runtime上，就是渐进式放权：不要一开始就给 agent全部权限、全部工具和全部真实环境，而是在低权限、低影响、可恢复的条件下先观察其行为。这个映射并不意味着harness发明了新原理；它说明的是，agent系统终于开始系统性复用原本服务工程里的“逐步暴露风险”机制。

Chaos Engineering进一步把这条线推进到更主动的一面。它的核心不是“故意制造事故”，而是：在定义steady state之后，通过受控扰动验证系统是否仍能保持关键行为。放到agent语境里，这几乎就是对“happy path eval”的直接修正：不能只在理想条件下看agent完成任务，还要主动注入API超时、错误工具输出、上下文污染、权限变化、环境漂移、网页结构变化、缓存脏数据等异常，检验它会不会偏航、卡死、误恢复，或者把一个局部错误扩散成系统性失败。

Circuit Breaker和Bulkhead则是失败扩散控制的经典技术先例。前者强调当失败达到阈值时应直接短路，后者强调将不同工作负载放在隔离资源池中，避免一个局部问题拖垮全局。今天把它们翻译到Harness语言里，很容易得到对应的agent机制：某类工具连续失败后自动停用、某类高风险动作被限流、某个sub-agent被资源隔离、某条执行链在可疑状态下直接切断。这里最值得强调的一点是：Harness许多“强控制感”，并非来自全新理论，而是来自成熟弹性模式向agent对象的迁移。

Harness另一半前史来自系统异常检测与故障定位。现代复杂系统从来都不是透明的；微服务和分布式系统的一个故障，常常伴随着日志洪峰、指标偏移、trace异形、依赖级联和多组件告警。于是，异常检测、fault localization与RCA长期成为系统运维和AIOps的核心主题。微服务故障诊断的研究对象可以分成failure classification与root cause localization两大类，说明系统工程早已把“找到真正的问题在哪里”视为一个独立学科问题。

在这条诊断线里，异常检测和根因定位不是一回事。异常检测回答“系统偏离正常态了吗”，而fault localization/RCA回答“到底哪里出了问题、为什么是这里出问题、问题是如何传播到当前表面的”。这条线和 Harness 的关系超级直接。今天agent harness强调logs、metrics、traces、trajectory、tool-call chains、handoff artifacts，并不是由于agent发明了“诊断”这个问题，而是由于它把诊断对象从服务组件扩展成了认知-执行混合轨迹。传统RCA主要处理“哪个服务挂了”“哪个依赖异常了”；而agent harness还要处理“哪一步开始偏航”“哪次工具调用污染了后续上下文”“哪一段 handoff 让目标漂移”“哪个子 agent 把错误传入后续流程”。工程逻辑没有变，难度结构变了。

近两个月出现的多agent failure attribution工作，正说明这条诊断线已经正式进入 agent 系统时代。AgentTrace把问题定义为 deployed multi-agent workflows的post-hoc failure diagnosis，通过从 execution logs重建causal graphs来追溯故障根因，agent系统的诊断问题已经从“看日志”升级成“重建因果”。

因此，Harness Engineering的前史，不只是一部控制与韧性机制的历史，也是一部异常检测、故障定位与根因分析不断向运行时收敛的过程。过去这些机制面对的是服务实例、RPC 链路、微服务组件和日志流；今天 Harness 要面对的是 trajectory、tool chain、memory state、subtask handoff、approval path 和 environment state。对象变了，但先看见异常、再缩小范围、再定位根因、最后决定拦截/恢复/重试/降级/转人工的工程范式并没有变。

三、从AI Agent Systems看Harness：它能吸收哪些AI系统可靠性的技术能力？

如果继续站在AI agent systems的主视角下，真正的问题是：当系统从模型应用演化成agent system之后，哪些原本分散的系统能力开始被 Harness 收编为统一的运行层。

Harness第一吸收的是context与state continuity能力。对单轮模型来说，上下文只是一次性输入；但对 agent 来说，上下文同时承担工作内存、任务历史、计划依据、工具结果和中间状态的角色。Phil Schmid 把 harness 与 context engineering绑定，认为 harness 实现了compaction、state offloading、task isolation 等策略；Anthropic 在长时 harness 里则把 context resets 与 structured handoff 当成关键设计点，用来处理长任务中模型逐步失去连贯一致性、接近上下文极限时提前“收尾”的问题。Harness 之所以成为一层独立对象，第一就是由于 agent 不再是一锤子买卖，而是一种需要连续工作能力的执行体。

Anthropic 的经验特别说明问题：随着context window被填满，模型会在长任务上失去连贯一致性，一些模型还会表现出所谓的 “上下文焦虑”，在接近上下文限制时开始过早结束工作；早期 harness 通过 context resets 和 structured handoff 来解决这个问题，而后续模型能力提升后，才有可能减少对此机制的依赖。这个叙述表明，所谓 harness 并不是抽象概念，它实际承接的是一个超级具体的 agent-system 病灶：上下文耐久性不足。

其次，Harness吸收的是tool、workflow 与 lifecycle orchestration。Phil Schmid 把 prompt presets、opinionated tool-call handling、lifecycle hooks、planning、filesystem access、sub-agent management 都放进 harness，而不是 framework；Anthropic 也在eval方法文里把 harness 定义为负责处理输入、编排工具调用和返回结果的系统。这背后的本质是：agent 一旦进入真实任务，它的难点就不再是“会不会用一个工具”，而是“谁来管理整个工具使用生命周期、阶段切换、任务拆分、恢复与收束”。

Anthropic 在长时应用开发里的
planner/generator/evaluator设计，是这条能力线最典型的例子。文章明确说，planner 能避免 generator 在原始 prompt 上直接 under-scope；evaluator 则通过 Playwright MCP 主动浏览页面、截图、打分、写 critique，并把反馈回送给 generator，形成 5 到 15 轮迭代。后来在 full-stack 场景里，evaluator 又按照 sprint contract 的测试标准去检查运行中的应用并 filing bugs。这里的关键不是“多 agent”这个字眼本身，而是职责分离、信息交接、反馈闭环和任务连续性被显式工程化了。

第三类被Harness明显吸收的能力，是 observability、anomaly detection与fault localization。OpenAI 在Codex实践中把logs、metrics、traces暴露给agent，并让agent通过本地observability stack使用 LogQL、PromQL和TraceQL；OpenTelemetry则在 2025 年推动AI agent observability的标准化语义，目标是让不同 agent applications和frameworks都能报告统一 telemetry；Anthropic在eval文章里又把transcript/trace定义为trial的完整记录，明确包含outputs、tool calls、intermediate results等。三者合起来说明一个变化：可观测性不再只是给人类的dashboard，而开始成为 agent-readable、agent-actionable的运行材料。

一旦observability真正进入agent可消费的闭环，异常检测与故障定位就会自然进入 Harness 核心。OpenAI 的图示很清楚：Codex使用logs、metrics、traces来查询、关联、推理，再回到代码库实现修复、重启应用、重跑 workloads 和 UI journeys，如此反复。Thoughtworks也强调sensors的价值在于给 agent 产生适合 LLM 消费的反馈信号，例如带自修复指令的linter messages。换句话说，诊断信号不再停留在“人看到报警”，而是开始演变成“agent 据此继续行动”的一部分，这是 Harness 相比传统 observability 最重大的变化之一。

第四类，是 reliability、resilience 与 runtime control。这一部分和SRE/canary/chaos/circuit breaker的关系最明显。OpenAI在实践中明确写道，agents在“strict boundaries and predictable structure”的环境里最有效，因此他们采用严格的 architectural model，并通过 custom linters 和 structural tests机械化执行这些约束；Thoughtworks则把harness的feedforward/feedback 控制分为 computational与inferential两类，并强调“keep quality left”，把快速、确定的传感器尽量左移到agent 工作流前部。Harness在agent系统里继承的，是一套典型的“用结构换可控性”的可靠性工程思路。

同时，uncertainty estimation、confidence calibration、OOD detection 这类常被放在AI safety或 robustness旗下的研究的内容，更适合被理解成Harness的风险传感器。它们回答的是“这里不确定性高吗”“这里可能越出已知分布了吗”，但不直接回答“系统目前该怎么处置”。而Harness必须进一步决定：是否降低自治等级、是否改走保守路径、是否禁用某类工具、是否切到人工复核。换句话说，传感器重大，但不能把传感器误当成整套运行层。

到此为止， 整个关系结构就比较清晰了：Harness应该吸收的，是一整套围绕持续执行组织起来的系统能力。 其中，context continuity解决“能否长期工作”，workflow orchestration解决“如何被组织与调度”，observability与fault localization解决“如何被看见和诊断”，reliability机制解决“如何在异常中继续受控运行”，而AI safety则为这些机制提供风险边界和干预要求。只有把这几层一起看，Harness才真正像一个独立工程对象。

文章来源于黄大年茶思屋