AI早知道 | 面向 AI 工程师的周刊与深度研究

Harness系列： AI早知道 · 第一篇

我们在使用 OpenClaw、在上面开发 Skill 的过程中，碰到了一个反复出现的问题：模型够好，工具够多，但结果就是不稳定。直到我们系统地读了 Anthropic、OpenAI 的工程实践，加上独立开发者 Mario 的极简哲学，才意识到问题出在哪——我们缺的不是更好的模型，而是一套经过设计的 Harness。这个系列，是我们梳理这些思想、结合自己实践之后，想给同样在路上的人的一份参考。

古人说，千里马常有，而伯乐不常有。

但现在的问题不一样了。

大模型这匹千里马，已经到处都是。GPT、Claude、Gemini，随便哪一匹，都能日行千里。问题不再是"哪里找一匹好马"，而是：你能不能驾驭它？

驾驭一匹千里马，需要骑手。骑手只能是人——决定去哪、什么时候停、速度多快，这些判断不能外包给马本身。但光有骑手和马还不够。你还需要缰绳、马鞍、脚蹬、挽具。没有这套装备，再好的骑手也只能徒手抓马鬃，再好的马也跑不出应有的方向。

这套装备，就是 Harness。

一个被低估的词

Harness 在英文里本来就是"挽具"的意思，专指套在马或其他牲口身上、连接骑手与马力的那整套装备。

在软件工程里，这个词早就存在——test harness，测试框架，指包裹被测代码、让测试能够稳定运行的那套基础设施。

但在 AI agent 的语境里，Harness 的含义在 2026 年发生了一次质变。

今天说的 Harness，指的是：

围绕 AI 模型构建的运行环境的总和。 包括工具集、上下文管理策略、反馈回路、约束机制、状态管理方式，以及多 agent 的协作结构。它决定模型的能力能否稳定地转化为可交付的结果。

这里有一个关键的区分值得单独说清楚。

没有 Harness 的大模型，是信息工具：你输入问题，它输出答案，世界的状态没有改变。它能告诉你怎么写代码，但不会去写；能告诉你这封邮件应该怎么回，但不会发出去。

有了经过设计的 Harness，大模型才能成为生产工具：文件被修改了，代码被运行了，任务被真正完成了，世界的状态发生了真实的改变。

Harness，是千里马从信息工具跨越到生产工具的那道门。 这是这个系列最核心的判断，也是理解后续所有讨论的前提。

注意这个定义里没有出现"提示词"。Prompt 是你每次跟模型说的话，是骑手发出的指令。Harness 是更底层的东西——是让这些指令能被稳定执行的整个环境。

也注意这个定义里没有出现"框架"或"工具"。LangChain、LlamaIndex、Claude Agent SDK，这些是制作马具的材料，不是马具本身。你用什么材料做缰绳是一回事，你把缰绳系在哪、松紧怎么调、和马鞍怎么配合，是另一回事。后者才是 Harness。

为什么 2026 年突然重要了

这个词并不新。Harness 的概念，在 AI 研究界很早就有了。但为什么现在突然成了工程师之间最高频的词之一？

答案是：千里马刚刚真正跑起来了。

2024 年之前，大模型在大多数实际任务上还不够可靠。你可以用它写邮件、总结文档、生成代码片段，但让它独立完成一个需要多个步骤、跨越多个工具、持续运行数小时的任务——不行，或者说，不稳定。

2025 年，这个局面开始改变。前沿模型开始能稳定完成真正复杂的任务。Agent 的概念从 demo 走向了生产环境。

但"能做"和"稳定交付"之间，还有一道鸿沟。

一匹千里马，如果没有骑手引导方向，可能会漫无目的地狂奔。如果没有缰绳，骑手想转弯也转不了。如果没有马鞍，骑手坐不稳，跑到一半就会摔下来。

这道鸿沟，就是 Harness 要填平的地方。

今天，硅谷最聪明的工程团队，正在把大量精力从"选一匹更好的马"转移到"设计更好的挽具"。这不是因为马不重要，而是因为马已经够好了，现在的瓶颈换地方了。

Harness 的五个核心维度

要分析一个 agent 系统的 harness 设计得好不好，有五个维度值得审视。

维度一：上下文管理（Context Management）

核心问题：agent 在任何时刻，能看到什么？

上下文窗口是 agent 的工作记忆，也是最稀缺的资源。怎么向 agent 传递信息、传多少、什么时候清空重来、什么时候压缩保留——这些决策直接决定 agent 能否在长任务里保持连贯。

典型的设计张力：全量注入 vs 渐进式披露。把所有指令一次性塞给 agent，会挤占处理任务的空间；但如果信息太分散，agent 又会在需要的时候找不到。Anthropic 的研究发现，模型接近它"认为"的 context 上限时，甚至会提前收尾——他们把这个现象叫做 "Context Anxiety"（上下文焦虑）。

维度二：工具集设计（Tool Design）

核心问题：agent 能做哪些操作？粒度怎么定？

工具是骑手用来控马的"手"。工具太少，agent 能做的事有限；工具太多，agent 不知道该用哪个，或者每次 session 开始时就消耗大量 token 来加载工具描述。

一个具体的成本：Playwright MCP 有 21 个工具，光是工具描述就占用 13,700 个 token——在你和 agent 说第一句话之前，9% 的上下文窗口已经没了。

关键不只是"有哪些工具"，而是工具的粒度、描述方式，以及是全量加载还是按需激活。

维度三：反馈回路（Feedback Loop）

核心问题：agent 怎么知道自己做得好不好？

这是目前最被忽视、也最关键的维度。大多数 agent 系统里，反馈回路只有一条：出错了人去看日志，然后调整 prompt。

更成熟的 harness 会有结构化的反馈机制：自动化测试、专门的 evaluator agent、或者将应用的运行状态（日志、截图、报错）直接暴露给 agent 自己审查。Anthropic 的研究发现，让 agent 评估自己的工作，它几乎永远给出好评——即便输出显然有问题。分离生成者和评估者，是突破这个瓶颈的关键。

维度四：状态与记忆（State & Memory）

核心问题：跨 session 的信息怎么保存和传递？

大模型没有持久记忆。每次对话结束，它忘记一切。这对需要长期运行、多次迭代的任务来说，是一个根本性的挑战。

Harness 需要解决：什么信息需要持久化？以什么形式存储？下一个 session 的 agent 如何"继承"上一个 session 的工作成果？值得注意的是，几乎所有成熟的 harness 实践，最终都把答案收敛到同一个地方：文件。PLAN.md、TODO.md、AGENTS.md——文件是唯一同时满足"agent 可读"、"人类可读"、"可版本控制"、"跨 session 持久"这四个条件的状态载体。

维度五：约束与架构（Constraints & Architecture）

核心问题：什么能做，什么不能做，怎么机械地强制执行？

没有约束的 agent 系统，会随着时间推移越来越混乱——agent 会复制它见过的模式，包括坏模式。OpenAI 的团队发现，他们每周五要花 20% 的时间清理 AI 写出的"垃圾代码"。这显然不可持续。

好的 harness 会把关键规范编码成可执行的约束：自定义 linter、架构分层规则、命名规范、文件大小限制。这些约束不依赖 agent 的"自觉"，而是机械地强制执行。"在人力开发里，这些规则可能显得迂腐；在 agent 系统里，它们是约束乘以速度的倍增器。"

Harness 的三个尺度

这五个维度，在不同的尺度上呈现出完全不同的形态。

个人/任务层：你在一次 session 里怎么组织工具、怎么写系统提示、怎么检验输出。这是大多数开发者最熟悉的层面。

应用层：当单个 agent 不够用时，多个 agent 怎么分工协作？planner、generator、evaluator 各是什么角色？他们之间怎么传递上下文？这是多 agent 架构设计的核心问题。

工程文化层：当整个团队都开始用 agent 写代码时，工程规范、知识管理、架构决策怎么重新组织？这是最复杂也最少有人讨论的层面。

Harness 对不同群体意味着什么

同样是"需要做好 harness"，对不同的人来说，这句话指向完全不同的决策。

对独立开发者和个人黑客来说，harness 最核心的问题是：你对 agent 的行为有多少可见性？

独立开发者的资源有限，没有团队来帮你检查 agent 做了什么。如果你的工具链在背后注入了你看不见的上下文，如果 sub-agent 的行为对你是个黑箱，如果 agent 出错了你只能盲目地重试——这些都是 harness 设计上的失败。对这个群体来说，极简和可观测是最高优先级，复杂的多 agent 结构往往是负担而非资产。核心决策是：用最少的工具、最清晰的状态管理，换取最大的掌控感。

对软件公司和产品团队来说，harness 最核心的问题是：如何在速度和质量之间找到可持续的平衡点？

软件公司用 agent 编码，天然面临一个悖论：agent 跑得越快，产出的代码越多，但 review 和 QA 的压力也同步放大。如果 harness 没有内建的质量反馈机制，速度越快，技术债堆积越快。这个群体需要认真对待的是 evaluator 设计和约束机制——不是为了限制 agent，而是为了让 agent 的高速产出能被接住。核心决策是：找到你的业务里哪些质量标准可以被 agent 自动验证，把这些标准编码进 harness，而不是依赖人工 review。

对实体企业和传统公司来说，harness 最核心的问题是：企业里的知识和流程，有多少是 agent 能直接推理的形态？

这是被讨论最少、但影响最深远的一个维度。大多数企业的知识，活在三个 agent 完全无法访问的地方：人脑、会议记录、和 Word 文档。当你开始用 AI agent 处理业务流程时，这些知识对 agent 来说等于不存在。一家公司的核销流程写在钉钉群的置顶消息里，一个工厂的排产规则存在老工人的经验里——agent 无论多聪明，都碰不到这些。

这个群体面临的不只是技术决策，而是一次更深层的组织转型：把企业的隐性知识显性化，把显性知识结构化，把结构化知识变成 agent 可以直接推理和操作的形态。 这件事做不好，再好的 agent 工具也只能在企业的边缘打转，进不了核心业务流程。

一个悬而未决的问题

有了定义，有了框架，有了不同群体的决策地图，还有一个问题值得在整个系列里保持开放：

模型越来越强，harness 应该越来越复杂，还是越来越简单？

Anthropic 的研究工程师说：随着模型能力提升，你应该持续移除不再必要的脚手架。每个组件都是对模型能力的一个假设，假设过时了就该拆掉。

OpenAI 的工程团队说：结构性的复杂度应该尽早建立。严格的架构约束不是负担，是 agent 系统能快速运转而不腐烂的前提。

独立开发者 Mario 说：从第一天就保持极简。4 个工具，900 token 系统提示，benchmark 跑分和 Claude Code 不相上下。你加的每一个功能，都是在压缩你对 context 的掌控权。

三个人，三种做法，都有真实的工程实践为支撑。这个系列接下来的四篇，就是对这三种答案的深度拆解——以及我们自己的判断。

下一篇：AI 写代码的时候，谁在当质检员？—— 深解 Anthropic 如何用 Generator-Evaluator 结构突破长任务天花板