为什么人人都在谈论 Harness Engineering
Prompting 已经不再足够——要让 AI agents 可靠，离不开 systems、guardrails 和 feedback loops
如果你最近到处都听到“harness engineering”，第一反应是：好吧，大概就是把 prompt engineering 换个好听的名字——那这是第一个需要扼杀的误解。
不是，而且也不“只是”一个新名词。
这件事重要的原因不止是词汇问题。它告诉你 AI 的真实走向。读完之后，你应该能分清 prompt engineering、context engineering 和 harness engineering 的差别，更重要的是，为什么行业会在此刻突然开始在意它。
变化其实很简单：agents 已足够好用，但还不够可靠，无法单独托付。故事就这么简单。
agents 既足够有用，也足够危险。它们已经不只是生成文本或 tokens。好用到人们开始让它们写严肃代码、发起真实的 tool calls，并处理长流程任务；危险到如果你只给它套个 loop、怀抱一点梦想，它就会自信地一错再错。我自己也有过让 Claude Code 循环太久，直到停下手头并行的事才去看它到底在干嘛的经历。
harness engineering 就是从这里诞生的。它来自痛点。来自一个现实：当模型足够强时，瓶颈不再是“它能不能生成代码？”，而是“我能不能让它在真实系统里可靠地行为？”
最清晰的理解方式是这样：prompt engineering 是“问什么”；context engineering 是“给模型什么，让它有把握回答”；harness engineering 是“整套东西如何运作”。不只是提示里的词，不只是上下文里的 tokens，而是模型周围的 environment：它能使用的 tools、它拥有的 permissions、它向前携带的 state、它必须通过的 tests、你捕获的 logs、那些 retries、checkpoints、guardrails、reviews 和 evals，阻止系统滑向胡言乱语。context engineering 就生活在这套东西之内，它很重要，但不是全部。更大的 context window 并不会把一个 flaky agent 魔法般变成一个 reliable system。
模型是引擎。没有它你干不了什么，但买车的时候引擎是自带的。你的价值在于你能改造的部分。context 像是燃料、保养和仪表盘信息：可被持续优化与掌控。harness 则是车的其余部分：steering、brakes、lane boundaries、maintenance schedule、warning lights，以及“车门不该在高速上掉下来”这件常识。如果你只盯着引擎与燃料，照样能造出一辆很烂的车。
这一点在 2025 年 12 月前后开始变得显而易见。Karpathy 谈到一种“倒置”：他的工作流从“主要是手写代码，少量 agent 协助”，转向“主要由 agent 驱动，自己做少量手动修改”。听上去很像“哇，模型赢了”。但并非如此。真实的故事是：一旦 agents 足够连贯、能做很多事，大家也同时发现它们在真实环境里很脆。它们会声称一个功能已完成，却没跑 tests，甚至根本没真正实现功能；它们在长任务中会丢失主线；它们会做出破坏架构边界的本地修补；它们会卡在 loops 里对微小片段反复做极细小的修改。这也刺激了围绕 compaction 的大量研究——如果你感兴趣，我很乐意在后续文章里聊聊，告诉我！
Anthropic 给出了最早、最清晰的信号之一。他们关于 long running agents 的文章，基本勾勒了一个蓝图：agents 分班倒、跨会话工作，在 context windows 之间没有原生 memory。于是，他们不再假装模型会“记住一切”，而是把 memory 外部化成 artifacts：结构化的 feature list、progress log、Git commits、init script。他们甚至把角色拆成 initializer agent 与 coding agent。这已经是 harness 思维：不再要求模型“魔法般可靠”，而是设计一套让 agent“更可能可靠”的系统。
我们开始围绕 LLMs 和 agents 编程，而不是围绕既有系统编程。
接着，Mitchell Hashimoto 在 2026 年 2 月初给这件事起了名字。老实说，我觉得他对问题的 framing 也是这个术语能流行起来的原因：每当 agent 犯错，不要只是指望它下次会更好。要工程化环境，让它无法以同样方式再次犯下同样的错。根据实际的不良行为改进 AGENTS.md；增加 scripts、linters、checks 和 tools，让 agent 能验证并修复自己的工作。这是一个非常重要的心态转变：把负担从“等待下一个 model release”移回到 builder 身上。你不再说“这个 model 很蠢”，而是说“我的 system 允许了这种 failure mode”。更重要的是，我们不再等待 model providers 去继续改模型，而是主动调整我们的 tools 和 setup；即使是非程序员，也可以通过更好的 skill files 和一般性的 prompting 来做到这一点，并与 agents 迭代，每次用它都更好。比如，我在和 Claude Code 或 Cowork 搭配的每个 skills files 里，都加了最后一步：回顾整次交互，消化我喜欢与不喜欢的地方，好让它自我微调 skill，下次更好。我有时也会让它先花点时间找更好的做法；如果可行，就让它更新 skill。自从这么做以后，我省下了大量 tokens 和时间。
随后，OpenAI 让这件事彻底无法被忽视。他们的报告提到构建一个内部产品：大约百万行代码，零手写源码。Claude Code 的创造者也发推，说过去的 Claude Code 代码行数全部由 Claude Code 自己提交。重点不仅是标题，而是他们为了让这成为可能，在 agents 周围搭了什么：把结构化的 repo docs 作为真正的 source of truth；把 AGENTS.md 做成 map，而不是一堵文字巨墙；用 linters 与 tests 强制执行分层架构；合并前进行 agent-to-agent review loops；后台的 cleanup agents 负责修复 drift。这不是在写 prompts，而是在做基础设施设计。是软件工程整体上移一层。
这也正是与 context engineering 的关联有用之处，因为我觉得很多人此刻把两个词搞混了。context engineering 是让任务在当下对模型“可解”：窗口里该放什么？该检索什么？该总结什么？该淘汰什么？这是真活儿，而且部分工作可以由 agent 自己自动化。它是很多系统超越“笨提示”的主要原因之一。但 harness 决定何时加载这些 context、有哪些 tools 可用、允许哪些 actions、失败如何处理、以及在任何东西被称为“完成”之前会发生什么。
你的 harness 是你在模型周围构建的基础设施。
所以，context engineering 也许会确保模型看到正确的 database schema；但 harness engineering 要求它仍需运行 linter、通过 tests、遵守 permissions，并且保存 progress，避免在第三轮对话时忘记目标。前者是模型看见什么，后者是系统如何行为。
这也解释了为什么大家如今频繁谈到 progressive disclosure。如果你把整家公司的“脑子”全倒进一个巨大的 AGENTS file，agent 不会更聪明，通常更糟。更多噪音、更多 context rot、更多被无声忽略的东西。更好的模式似乎是：前面给一张简短的 map，只有在需要时再拉取更深的 sources of truth。这是一个 harness 里的 context engineering：harness 决定何时呈现什么，而不是把 context window 当垃圾填埋场。
那么，这些对整天做 coding agents 的人之外有什么意义？因为这正在逐渐成为软件被构建的新方式。不是完全、不是干净利落、当然更不是开箱即安全。但方向在变清晰。LangChain 展示了：只改 harness、不改 model，也能把一个 coding agent 从 Terminal Bench 2.0 的 Top 30 之外提到 Top 5。同一模型，更好的 system。据报道，Stripe 的 agents 每周会产出超千个被合并的 pull requests，但都在隔离的 environments 内，配有硬性的 CI 限制与升级规则。Datadog 更进一步，把生产 telemetry 也当作 harness 的一部分：一旦性能回退，这个信号会回到循环里。这不是“vibe coding”，而是 generate、validate、fix，外加 observability。
还有个更重要的含义：程序员的工作在转变。不是消失，是转变。更少时间手敲每一行；更多时间去设计“habitats”，让 agents 能做有用的事，又不把周边搞得一团糟。更多机器可读的文档、更多 evals、更多 sandboxes、更多 permission 边界、更多结构化 tests、更多 logs、traces 与可回放性。prompting 是最容易的部分；可靠性才是真正的工作。
但实话实说，这并不意味着 agents 被“魔法般”解决。memory 仍会失效，validation 仍会漏掉问题，tool use 仍然带来安全风险。harness debt 也是真实存在的，因为你的 harness 自身会变成一个产品，带着自己的 bugs 和 drift。人类注意力成了真正稀缺的资源：如果 agents 能产出远超人类能细查的量，严谨性就必须内移到系统里。你不可能永远手工审完一切。你需要可信的 checks，需要能安全失败的 environments，需要能告诉你“为什么出错”的 traces。
所以当人们问 LLMs 的走向，我觉得更好的答案是：它们正走进 systems——进入 workflows、agents、runtimes 与 harnesses。更多的价值来自 orchestration、constraints 与 feedback loops，而不是社交媒体上一张 prompt 截图。未来更可能不是“一个天才 model 包打天下”，而是“models 在精心工程化的 environments 中运行，使其真正可用”。
这就是 harness engineering 之所以重要。它不是给 prompting 改个时髦名字；而是当你不再只做智能的 demo、而是要真正把它交付出去时，必然会出现的东西。
感谢您的阅读！