Harness Problem：为什么你的 AI Agent 只能演示，不能上线？

上个月，一个做 AI 产品的朋友跟我吐槽："我们的 Agent 演示的时候惊艳全场，客户当场就说要签单。结果部署到生产环境，第一天就出了三个事故。"

我问他："什么样的事故？"

他说："Agent 执行到第 15 步的时候，忘了第 3 步定下的约束条件，直接把客户的测试数据写进了生产数据库。"

我说："那你的 Harness 是怎么设计的？"

他愣了一下："什么是 Harness？"

这个反应，我在过去几个月里见过不下十次。几乎每个 Agent 创业团队都在疯狂优化 prompt、挑选模型、调整温度参数，但很少有人认真想过：模型之外的那些东西，才是决定 Agent 能不能上线的关键。

这就是 Harness Problem——2026 年 AI Agent 领域最核心、也最被低估的挑战。

---

什么是 Harness Problem？

先说一个你可能没想到的类比。

如果把 AI 模型比作一匹千里马，那 Harness（直译"马具"）就是套在马身上的缰绳、马鞍和笼头。千里马再强，没有缰绳它只会乱跑；没有马鞍，骑手坐都坐不稳。

在 AI Agent 的语境里，Harness 指的是模型之外的所有基础设施：上下文管理、状态持久化、工具调度、验证循环、人类审批流程、错误恢复机制……这些东西加在一起，才构成一个"能上生产"的 Agent 系统。

Philipp Schmid（Hugging Face 技术负责人）用了一个更精确的类比：

• 模型 = CPU（算力核心）
• 上下文窗口 = 内存（易失性工作记忆）
• Harness = 操作系统（调度、管理、容错）
• Agent = 应用程序（面向用户的功能）

你什么时候见过有人买了一颗顶级 CPU，不装操作系统就直接拿去跑业务的？

但这恰恰是今天大多数 Agent 团队在做的事情——他们花 90% 的精力选模型、调 prompt，却只用 10% 的精力去搭建 Harness。

所以，Harness Problem 的本质是：Agent 从"能演示"到"能上线"之间的鸿沟，不是模型能力的问题，而是模型之外所有工程的问题。

一句话：模型是发动机，Harness 是整辆车。发动机再猛，没有底盘、刹车和方向盘，你哪儿也去不了。

---

36% 的数学诅咒：可靠性为什么会"塌方"？

你可能会说，模型不是已经很强了吗？单步成功率 95%，这不是 A+ 的成绩吗？

对，但 Agent 不是考试，不是做一道题就交卷。Agent 是做一套卷子——而且每道题的答案会影响下一道题的题目。

做一道数学题：

假设 Agent 每一步的成功率是 95%。5 步之后，端到端成功率是多少？

0.95 × 0.95 × 0.95 × 0.95 × 0.95 = 77%

还行？那 10 步呢？

0.95^10 = 60%

20 步呢？

0.95^20 = 36%

36%。一个每步成功率高达 95% 的 Agent，执行 20 步之后，有将近三分之二的概率会出错。

这就是"可靠性复合衰减"——复利的反面。爱因斯坦说复利是世界第八大奇迹，那复合衰减就是工程师的第一大噩梦。

更可怕的是，Agent 的失败不像程序崩溃那样"哐"一声。它经常是"软失败"——Agent 觉得自己做对了，自信满满地把错误结果交给你。你看着输出觉得"嗯，挺像回事"，直到三天后发现数据全是错的。

但问题来了：Harness 到底需要解决什么？为什么简单地"加个重试"不够？

答案藏在一个更深层的概念里——Context Rot。

---

Context Rot：Agent 为什么越跑越笨？

你有没有过这样的体验？跟 ChatGPT 聊到第 50 条消息的时候，它突然"忘了"你前面说的某个关键约束，开始自说自话？

这不是你的错觉。这个现象有一个正式的名字：Context Rot（上下文腐烂）。

打个比方：想象你在参加一场开卷考试。一开始，桌上只有教材和笔记，你翻到哪页都很清楚。但随着考试进行，你不断从各种地方查资料，打印的论文、同学传来的小纸条、自己的草稿纸——桌子上越堆越多。

到最后，你要找一个关键公式，必须在一堆废纸里翻半天。有时候你翻到的还是一个两小时前就已经被你推翻的错误版本。

Agent 面对的就是这个困境。

在一个长时间运行的任务里，Agent 的上下文窗口会逐渐堆满：中间调试输出、过期的文件版本、失败的工具调用结果、走不通的探索分支……噪声堆积的速度远远快于有效信号。

研究者发现了一个叫"Lost in the Middle"的效应：当上下文变长时，模型会系统性地忽视中间部分的信息，只关注开头和结尾。这意味着你在第 5 步设定的关键约束，到了第 15 步可能已经被"埋"在上下文的中间地带，模型根本看不到了。

"即使信息在技术上仍然存在于上下文窗口中，模型也无法找到它。上下文窗口更大只能推迟腐烂，但不能消除它。"
—— Understanding AI, 《Context Rot: The Emerging Challenge》

你可能会想：那用 100 万 token 的超长上下文窗口呢？

答案是：有帮助，但远远不够。更大的上下文窗口像是给你一张更大的桌子——但如果你不整理桌面，桌子再大也会被废纸淹没。

Agent 不是变笨了，是被自己的记忆淹没了。

那么，好的 Harness 应该长什么样？有没有一个系统性的框架来思考这个问题？

---

CAR 框架：给 Agent 装上缰绳、马鞍和赛道

Martin Fowler 的团队提出了一个极其优雅的框架来理解 Harness 的结构：CAR 框架——Control、Agency、Runtime。

还是用赛马的比方来解释：

• Control（控制）= 缰绳：定义 Agent 不能做什么。包括约束规范（AGENTS.md）、代码检查器（linter）、测试门禁、权限边界
• Agency（代理能力）= 马鞍和马镫：定义 Agent 能用什么工具。包括 MCP 服务器、子 Agent、API 接口
• Runtime（运行时）= 赛道：定义 Agent 怎么跑。包括生命周期钩子、重试策略、回滚机制、状态持久化

Martin Fowler 团队进一步把 Control 层拆成了两种机制，这是我觉得最有洞见的部分：

前馈控制（Guide）：在 Agent 行动之前，告诉它什么能做、什么不能做。就像你给新入职的实习生一份 SOP 手册——他还没开始干活，你就先把规矩立好。

反馈控制（Sensor）：在 Agent 行动之后，检查它做得对不对。就像代码里的单元测试——不是阻止你犯错，而是在你犯错后立刻告诉你。

控制类型	时机	方式	例子
前馈（Guide）	行动前	规范、约束、Prompt 注入	AGENTS.md、系统提示词、权限白名单
反馈（Sensor）	行动后	检查、测试、AI 审查	Linter、集成测试、代码审查 Agent

有意思的是，这跟传统软件工程的"左移质量"思路完全一致：能在编译期抓住的错误，就别等到运行时；能在 Agent 动手之前预防的问题，就别等它搞砸了再修。

Manus（一个知名的 Agent 产品）在六个月内重构了五次 Harness。LangChain 的 Deep Research Agent 在一年内重写了三次架构。Vercel 则走了另一个极端——砍掉了 80% 的工具，反而让 Agent 跑得更快、更稳。

这些案例说明一件事：好的 Harness 不是一次性设计出来的，它是"活"的，需要跟 Agent 一起进化。

好的 Harness 不是限制 Agent，而是让它跑得更远。就像好的赛道不是缩短赛程，而是让赛马全力奔跑时不会摔断腿。

---

五个关键工程模式：Harness 的解药

理解了问题，接下来聊解法。我从目前行业实践中提炼了五个最关键的工程模式，每一个都经过了生产验证。

模式一：验证循环（Verification Loop）

这是 Harness 工程中投入产出比最高的一个模式。

原理很简单：Agent 每完成一步操作，不要直接执行下一步，而是先过一道验证门。这道门可以是确定性的（运行测试）、也可以是推理性的（用另一个 AI 审查）。

# 验证循环的核心逻辑
def agent_step_with_verification(task, state):
    # 1. Agent 执行一步
    result = agent.execute(task, state)

    # 2. 确定性验证：跑测试、跑 linter
    test_ok = run_tests(result)
    lint_ok = run_linter(result)

    # 3. 如果验证失败，把错误信息喂回给 Agent
    if not (test_ok and lint_ok):
        return agent.fix(result, get_errors())

    # 4. 验证通过，提交状态，进入下一步
    commit_state(result)
    return result

关键在第 3 行和第 7 行之间：每一步都有"刹车"。这能把软失败在传播之前就拦截下来，避免错误沿着执行链一路放大。

Anthropic 的实验发现，当 Agent 被明确要求"像人类用户一样通过浏览器自动化工具做端到端测试"时，完成质量出现了质的飞跃。不是让 Agent 自己判断"我做对了"，而是让外部系统来验证。

模式二：子 Agent 架构（Sub-Agent Isolation）

还记得 Context Rot 吗？子 Agent 是解决它最直接的手段。

想象你是一个项目经理。如果你亲自去做每一件事——调研、写代码、测试、写文档——你的大脑很快就会被细节淹没。

聪明的做法是什么？委派。让调研员去调研，开发者去写代码，测试员去测试。每个人完成后，只给你一份简洁的报告。你的脑子里始终只有"全局概况"，不会被任何一个子任务的细节污染。

子 Agent 架构干的就是这件事：主 Agent 负责编排和决策，脏活累活委派给专门的子 Agent。子 Agent 的上下文是隔离的——它的调试噪声、中间结果、失败回溯，全部留在自己的上下文里，不会"传染"给主 Agent。

模式三：JIT 上下文检索（Just-In-Time Retrieval）

Claude Code 用的就是这个策略：不预加载所有信息，而是在需要的时候才去获取。

这跟传统软件中的"懒加载"是一个思路。你不需要把整个数据库都加载到内存里，你只需要在用到某条记录的时候才去查。对 Agent 来说，你不需要在第 1 步就把项目的全部代码、全部文档、全部历史记录塞进上下文——在 Agent 真正需要某个文件的时候再读取它就好。

简单，但有效。因为它从源头控制了上下文的膨胀速度。

模式四：状态外化（State Externalization）

上下文窗口是"易失"的——一旦超出长度被截断，或者开启新的会话，之前的信息就丢了。

解决方案：把关键状态写到上下文之外。

Anthropic 的 Harness 设计用了一个巧妙的做法：让 Agent 把进度写入 claude-progress.txt 文件，每完成一个功能就用描述性的 git commit 记录状态。这样，即使开启一个全新的上下文窗口，Agent 读一下进度文件和 git log，就能快速重建工作状态。

这不是什么高科技——每个靠谱的人类软件工程师每天都在做这件事：写 commit message、更新 TODO、记录决策。Harness 工程的本质，就是把人类工程师的隐性经验，变成 Agent 能遵循的显性规则。

模式五：增量执行 + 干净状态（Incremental + Clean State）

Anthropic 在构建 claude.ai 克隆的实验中发现，Agent 最常见的失败模式是"试图一口气做完所有事"。

解法是：强制 Agent 每次只做一个功能，做完之后代码必须处于"可合入主分支"的状态——没有重大 bug、代码整洁、文档齐全。

这跟软件开发中的"小步提交"原则如出一辙。你不会让一个工程师闷头写三天再提交一个 2000 行的大 PR。你会要求他每天提交，每次 PR 只做一件事。

---

写在最后：三个没有答案的问题

写到这里，核心洞察可以浓缩成一句话：2025 年是 Agent 的元年，2026 年是 Harness 的元年。建 Agent 是序章，建 Harness 才是正文。

但聊到这里，有三个问题我还没有答案，也不确定行业什么时候能给出答案：

第一，Harness 会不会被模型本身吞掉？

随着模型上下文窗口越来越长、推理能力越来越强，今天需要 Harness 解决的问题（比如 Context Rot），会不会在下一代模型中自然消失？如果 Context Rot 是个工程问题而非架构缺陷，那模型进化也许能解决它。但如果它是 Transformer 注意力机制的内在局限，那 Harness 就是永远的刚需。

第二，当 Agent 能自主调用 100+ 工具时，信任边界谁来画？

今天的 Harness 主要靠人类预设权限白名单。但当 Agent 能力越来越强、自主性越来越高时，这种"硬编码"的信任模型还能 scale 吗？OpenID Foundation 已经在探讨"递归委托"的治理框架——但从论文到落地，还有很长的路。

第三，Harness 工程师会成为一个独立岗位吗？

Martin Fowler 的文章用了"Harness Engineering"这个术语。这暗示它可能从"Agent 开发的一个环节"升级为"一个独立的工程学科"。就像 DevOps 从"开发附带做的运维工作"变成了一个独立职业。如果 Agent 成为软件开发的主力军，那负责"管好 Agent"的人，可能会比"构建 Agent"的人更稀缺。

我不知道这三个问题的答案。但我知道一件事：在未来 12 个月里，谁先把 Harness 做好，谁就能在 AI Agent 的落地竞赛中领先整整一个身位。

因为在这个赛道上，瓶颈已经不是"马跑多快"，而是"缰绳够不够好"。