一个没人定义得了的词，凭什么火三个月
Dan Ariely 说大数据像 teenage sex：everyone talks about it, nobody really knows how to do it, everyone thinks everyone else is doing it, so everyone claims they're doing it。Harness Engineering 现在就是这个状态。
AI 领域每隔几周就有一个新概念被推上风口，热闹一阵，然后被下一个概念取代。RAG是这样，LangChain 是这样，Context Engineering 也是这样。
Harness Engineering 不太一样。从 Mitchell Hashimoto 2026 年 2 月首次提出，到 OpenAI 正式采用，到 Garry Tan 的"Thin Harness Fat Skills"拿下 140 万阅读，这个概念已经持续了近三个月，热度没有明显衰减。而这三个月里，几乎没有人能给出一个让大家都满意的定义。
OpenAI 写了一篇好文章，Garry Tan 有影响力，三大公司同时发文形成共振。这些可以解释第一周的热度，但解释不了第三个月的热度。三个月的持续需要需求侧的真实共鸣：一群人在自己的实践中撞上了同一组问题，然后发现 harness 这个词恰好描述了它。
Agent 撞了哪些墙
第一面墙：错误的组合爆炸。 单个 agent 的错误模式是可管理的，但两个 agent 串联起来，失败模式不是叠加而是组合。一医疗场景案例：三个 agent 各自准确率 95%，Agent A 生成了不存在的药物名称，Agent B 基于它检测出虚构的药物相互作用，Agent C 据此向医生发出了紧急警报。每个 agent 的 guard 都通过了，但组合在一起产出了完全虚构的高置信度医疗告警。
根源：传统的逐组件防错机制建立在错误模式可穷举的假设上，agent 的概率性输出让这个假设不再成立。
第二面墙：自然语言产出无法度量。 传统的 observability 度量结构化数据：HTTP status code、latency、error rate。但 agent 的核心产出是自然语言。Mezmo 的 AURA 项目负责人说："agents fail silently. They hallucinate, loop, and make confident but incorrect decisions based on incomplete context. Traditional observability stacks offer no visibility into these failures."
根源：传统的观测体系建立在被观测对象是结构化数据的假设上，agent 的自然语言产出让这个假设不再成立。
第三面墙：被管理的对象会感知环境并改变行为。 Cognition（Devin 团队）在重建产品时发现了 context anxiety：agent 提前感知到 context window 的限制，开始走捷径、提前收尾任务。解决方案完全在环境层面：开启 1M token context，实际限制使用量在 200K，让模型认为自己还有大量余量。模型没变，环境变了，问题消失了。
根源：传统的状态管理建立在被管理的对象不会感知资源约束的假设上，agent 对 context 的主动感知让这个假设不再成立。
第四面墙：输出不可复现，传统测试失效。 传统的测试手段建立在"同样的输入产生同样的输出"这个前提上。Agent 的输出每次都不一样，需要的是基于评判标准的持续评估：用统计方法判断整体质量是否在可接受范围内。
根源：传统的验证体系建立在行为可复现的假设上，agent 的概率性输出让这个假设不再成立。
第五面墙：治理框架管不住概率性行为。 McKinsey 数据显示超过 70% 的企业在试点 AI，但只有不到 20% 成功规模化。IDC 更尖锐：只有 2.9% 的组织在跨部门规模化 agent 应用。
根源：传统的治理框架建立在"一个系统被授权做某件事，它就只做那件事"这个假设上，agent 的概率性行为让这个假设不再成立。
统一的模式： 每一面墙对应的都是传统软件可靠性保障链条上的一个环节：防错、观测、状态管理、验证、治理。五个环节合在一起，覆盖了软件从运行到交付的完整生命周期。而每个环节失效的原因都是同一个：它的底层假设建立在确定性系统上，agent 的概率性行为打破了这个假设。
换句话说，agent 不是在某一个点上出了问题，而是让整条可靠性保障链条同时失效了。
太阳下面没有新鲜事
把五面墙放到管理学语境下看，每一面都有现成的对应物：
- 错误的组合爆炸 → 跨部门协作中的组合性风险（解法：端到端流程审计、跨部门 independent review、关键交接点设置 checkpoint）
- 自然语言产出无法度量 → 考核指标失效（解法：同行评审、案例复盘、基于 rubric 的多维评分）
- Context anxiety → 员工感知资源压力后降低标准（解法：合理分配工作量、明确优先级、正确预期）
- 测试失效 → 产出波动大的团队成员（解法：持续的绩效追踪机制，用多次采样替代单次考核）
- 治理框架失效 → 组织扩张中的管控失灵（解法：层级结构、标准化流程、跨团队协调机制）
既然是管理学，为什么之前没火
"用 AI 就是在做管理"这个观察并不新鲜。Karpathy 2023 年提出 Software 3.0，Ethan Mollick 2024 年写"great AI management, not great models, creates competitive advantage"，Simon Willison 把 agent 定义为"an LLM that runs tools in a loop"——这些观点都对，但没有一个形成持续的热度。
为什么？
第一，「管理 AI」唤起的联想是错的。一说管理学，技术社区的第一反应是：供应链管理、财务管理、人力资源管理，跟我写代码有什么关系？人类管理的难点在意愿（willingness），AI 管理的难点在可靠性（reliability）。叫管理学，大家想到的是意愿那一半，而 agent 真正需要解决的是可靠性那一半。
第二，它听起来是软技能。市场只给名词定价，不给动词定价。Debug 一个 multi-agent 系统的级联错误是动词，设计验证循环是动词，管理 agent 的 context 生命周期是动词。这些动词没有 GitHub 仓库，不能 pip install，不能写进简历的技能栏。
Harness engineering 解决了这两个问题。Harness（马具）的原始含义是：马有自主能动性，能自己判断路况，但骑手用 5% 的力气决定 95% 的行进路线。这个隐喻精确地映射了 agent 的特性：有能动性、有判断力，但需要 high-leverage 的引导。
而 engineering 这个词把一组散落的动词打包成了可以被讨论和定价的名词——从软性认知的货架搬到了硬核技术的货架上。
更精确的类比：DevOps
运维的原则几十年没变：监控、告警、容量规划、故障恢复。传统数据中心时代实现工具是 Nagios + 手动 SSH + 运维团队 oncall。Cloud-native 时代，同样的原则有了完全不同的实现：Prometheus + Grafana + Kubernetes + Terraform + GitHub Actions。原则没变，但 cloud-native 环境要求一套全新的工具和实践。
DevOps 不是发明了新的运维原则，而是在新的执行环境中重新实现了旧原则。
Harness engineering 和管理学的关系也是如此。管理人用 1-on-1、绩效考核、文化建设。管理 agent 用 checkpoint 设计、验证循环、context 生命周期策略、可观测性 stack。
2026 年 Q1 的三篇奠基文章从这个角度看就清晰了：
- OpenAI 解决交互维度：人如何用最少的介入来 steer 大量 agent 工作，对应管理学中的 span of control 和 delegation
- Cursor 解决空间维度：几百个 agent 并行如何不踩脚，对应跨团队协调
- Anthropic 解决时间维度：一个 agent 连续跑几小时如何不走偏，对应长期项目的 milestone management
这也是为什么大家对 harness 的定义始终无法收敛：每个人都在往这个词里装自己正在解决的那个特定维度的管理问题。
对实践者的意义
好消息： 你不需要从零学一门全新的学科。管过人、管过项目、管过团队，你已经具备了 harness engineering 的原则基础。
坏消息： 原则相通不等于可以直接搬。Agent runtime 有自己特有的约束和机会，需要专门学习的新实践：
- 人类团队有 tribal knowledge，很多事情不用写下来大家也知道。Agent 没有，所有上下文必须显式写成文档，document first 不是锦上添花而是基本前提
- 人类员工在任务进行到 80% 的时候不会突然偷工减料。Agent 会：当 context window 接近容量上限时会感知压力并开始走捷径（context anxiety）。你需要主动管理 context 生命周期，在它接近阈值之前做 divide and conquer
- 让十个人同时做同一件事然后赛马，成本高、伦理上也说不通。管理 agent 的时候，你可以让十个 agent 并行跑同一个任务，取最优结果，这在统计学里叫 bootstrapping，成本几乎为零
这些实践在管理人的语境下要么不可能，要么不经济，但在 agent runtime 中是基本操作。Harness engineering 的原则来自管理学，但它的工程实践必须针对 agent 的特性重新设计。这也是为什么它值得有自己的名字。