harness-what-is-why-important-ai-harness
一篇来自 IBM AI Developer Advocate Tis 的现场演讲整理。从「为什么需要 Harness」讲到「Agent Harness 到底是什么」，再用一个浏览器 Agent 给 Hacker News 点赞的 demo，一步步演示如何在不改 Prompt 的前提下，用 Harness 把一个又笨又会撒谎的模型变成可靠的 Agent。
最近听了一期公开演讲，演讲者是 IBM 的 AI Developer Tejas Kumar ，所在团队负责训练前沿模型、构建 harness 等工作。他先做了一个现场调查：「在座有多少人敢说自己真正理解 AI Harness？」——几乎没人举手。这正是这场演讲存在的意义。
Tejas 强调：harness 这个词最近被滥用，每天可能听到几万次，但在不同语境里含义完全不同。
在传统机器学习里，它指「模型测试套件」；而在 AI 工程语境下，它指的是完全不同的东西。这场分享就是要把后者讲清楚。
为什么需要 Harness：我们都在向模型公司「交租」 大多数开发者并不是「token（代币，模型按 token 计费的最小单位）亿万富翁」，而是每月付 $20 订阅 Claude Pro 这种「租客」。租来的模型有三个根本问题：
是个黑盒 ，理论上服务方随时可以在你不知情时把 Opus 偷换成 Sonnet；所以 Harness 的核心关键词只有一个——Reliability（可靠性） 。它要保证：无论底下挂的是哪个黑盒模型、租自哪家厂商，你构建的 Agent 都能稳定地完成它该做的事。
从字面理解 Harness：登山扣与狗绳 回到「harness」这个词的本义：
登山者 把自己用 harness 锚定在山体这种「稳定的东西」上，防止失足坠落；遛狗时的胸背带 同样如此——它把狗拴在主人这个稳定锚点上，防止它乱跑（顺便说，「也防止它把你的 token 账单跑爆」）。Harness 的设计本质就是：把一个容易失控的东西，锚定在一个稳定的环境里，不让它漂太远。
两种 Harness：ML世界 vs AI 工程世界 机器学习里的 Harness ：本质是一个升级版的测试套件 + test runner（测试执行器），喂模型一堆输入，看输出质量。AI 工程里的 Agent Harness ：完全是另一回事，是这场演讲的主角。Agent Harness 究竟是什么 这是整场演讲的「核心金句」：
Agent Harness 就是模型周围的一切，是让模型在现实里有所「锚定」的那层东西。
比如 Claude Code，本质上既是一个 Coding Agent（编程智能体），也是一个被 harness 包裹起来的 Coding Agent 。Cursor、Codex 同理。
Agent Harness 的五大典型组成部分 Tis 总结了一个标准 Agent Harness 通常包含的「嫌疑人名单」：
Tool Registry（工具注册表） ：例如读写文件系统、执行 bash 命令等工具集合。Model（模型） ：有些 harness 允许你切换底层模型，有些不行。Context（上下文）管理原语 ：几乎所有现代 harness 都会自动压缩上下文 ，这是 harness 的本职工作。Guardrails（安全护栏 / 防护栏） ：比如「最多 5 次 tool call（工具调用），超出就 kill（强制终止）掉本次运行」。Agent Loop（智能体循环） ：注意——harness ≠ agent loop。Harness 是环绕在 agent loop 周围 的东西，甚至可以是「loop 套 loop」，例如外层再加一个 N 次重试的 loop。Verify Step（验证步骤） ：比如 coding agent（编程智能体）写完代码后，跑一遍 lint（代码风格 / 静态检查）和测试，确认没把别的东西搞坏。Harness 把不确定的黑盒模型，扎根在一个你完全可控的稳定环境中。
实战 Demo：穷人版 AI Harness 为了从第一性原理理解 harness，Tis 现场写了一个「穷人版 AI Harness」 ：
任务 ：打开 Hacker News，给第一条帖子点赞。方式 ：浏览器使用型 Agent（Browser Use Agent）。底层模型 ：故意挑了一个又笨又老的 GPT-3.5 Turbo （2023 年的模型）。关键约束 ：全程不修改 Prompt（提示词，即给模型的输入指令） ，只通过构建 harness 来提升能力。他用的并不是 Playwright MCP（一种把工具暴露给模型的标准协议），而是直接调用普通 Playwright（一款浏览器自动化工具）：开 Chromium（开源浏览器内核）、建 context（浏览器上下文 / 会话）、新 tab（标签页）、navigate（跳转到指定网址）。工具定义用的是 OpenAI SDK（OpenAI 官方软件开发工具包）的标准格式：name（名称）、description（描述）、parameters（参数）、execute（执行函数）。Context（上下文，即模型每次能看到的对话内容）也极其朴素——只有最基础的 system prompt（系统提示词）+ 用户任务。Agent loop（智能体循环）就是一个 while true（无限循环）：拿响应，如果是 stop（停止）就退出，否则把事件 push（推入）进一个 trace（执行轨迹）历史列表里。
第一版：裸奔的 Agent 会撒谎 直接跑这个最朴素的版本，结果是：
Agent 打开 Hacker News，点了 upvote 按钮，撞上登录页 。 它直接「panic」并退出，但却汇报说：任务完成。 这是裸奔 Agent 最危险的特性——它会撒谎 。很多人遇到这种情况的第一反应是「再 prompt（提示词）狠一点」「改 system prompt（系统提示词）」，但 Tis 提醒：这通常不是真正的解决办法。真正的解法是给它加 harness。
第二版：加上 Guardrails（安全护栏：最大步数 + 上下文压缩） 第一步迭代，引入最基本的两条 guardrail（安全护栏）：
maxIterations（最大迭代次数） ：超过 6 步直接 kill（强制终止）。maxMessages（最大消息数） ：消息数超过阈值，就压缩上下文。上下文压缩策略也非常 naive：永远保留 system prompt + 用户任务 + 最近两条消息 ，中间的全部丢掉。Tis 自己承认这种做法很粗糙，但「这是 baby's first harness（婴儿的第一个 Harness）」。
第三版：把所有逻辑搬进 Harness Tis 接着做了一次重要的重构：把入口文件 index里的逻辑全部移进一个名为 runHarness的函数里。index 只剩 19 行代码。
这一步只是「搬家」，但意义在于：从此项目里真正出现了一个被命名为 Harness 的抽象层 ，后续所有改进都围绕它进行。
第四版：用 Verify Step（验证步骤）让 Agent 不再撒谎 接下来要解决「Agent 撒谎」的问题——「在解决问题之前，先得让它承认问题存在」。Tis 在 harness 里新增了：
maxAttempts（最大尝试次数） ：整个任务最多尝试 3 次，超过就放弃。runHarnessAttempt（单次 Harness 尝试） ：把单次执行抽出来，外层用循环包住，由 harness 层强制执行最大尝试次数。verifySuccessfulUpvote（验证点赞是否成功） ：一个确定性（deterministic，即结果可预测、不靠模型猜） 的验证函数。它读取 agent loop（智能体循环）的 trace（执行轨迹）历史，判断：是否真的发生了对 upvote（点赞）按钮的点击？是否「真的成功」？ 如果检测到 harness_auto_login（Harness 自动登录）失败信号，提前返回 failed（失败）。 如果工具历史里没出现过登录动作，但当前 URL（浏览器网址）又是登录页，也判定 failed（失败）。 再跑一次：Agent 仍然没成功，但它不再撒谎了 ，会如实报告失败。Tis 说：「这就是 TDD（测试驱动开发）的味道——先让它会失败，再让它能成功。」
第五版：用 Login Handler（登录处理器）让 Agent 真的能登录 最后一步：加一个 Login Handler（登录处理器） 。
它在 agent loop（智能体循环）的每一步里、push（推入）trace（执行轨迹）之前被调用。 如果当前浏览器 URL（网址）不是 登录页，立刻 return（直接返回），几乎零开销。 如果是 登录页，就由 harness 以确定性 + 安全 的方式（凭证可以来自环境变量或 secret manager，即密钥管理器），直接填账号密码、提交表单。 完成后向消息队列里 push（推入）一条：「Hey, harness 已经替你登录好了，可以继续了。」 关键点在于：登录这件事不是交给 Agent 自己摸索的，而是 harness 在确定性环境里做掉的。
再次运行，结果非常漂亮：
控制台输出：「成功 upvote（点赞）了 A little snitch for Nix （一条 Hacker News 帖子标题），rank（排名） #2，6 次迭代后完成。」 刷新 Hacker News 验证：点赞按钮已变为可「取消点赞」状态——任务真实完成。
一个最重要的启发：全程没改 Prompt Tis 反复强调一句话：
从头到尾，我没有动过一行 Prompt。
仅仅通过构建 harness——加 guardrail（安全护栏）、加 verify（验证步骤）、加 login handler（登录处理器）——一个 2023 年的「老旧低配模型」就完成了一个原本完全做不到的任务。这是这场演讲最重要的工程启示：当 Agent 表现不好时，第一反应不该是「prompt 得更狠」，而是「我是不是缺了一个像样的 harness」。
Harness 的真实价值：以 IBM Open RAG 为例 Harness 之所以重要，是因为：
而工程目标永远是「用更少做更多」——用更便宜的模型（比如 Qwen，即阿里通义千问；GPT-OSS，即 OpenAI 推出的开源模型）做更难的事。 一个好的 harness，能让小模型/便宜模型走得很远。IBM 在企业里部署的开源项目 Open RAG 就是这种思路的产物：在大型企业最敏感、最孤岛化的数据区（Teams 通话、PDF、发票等）做 RAG，依靠一套企业级的 harness 提供安全与可靠性保障。
总结与展望：2026 是 Harness 之年 这场 18 分钟的 deep dive（深度解读），可以浓缩成几句话：
Harness = 模型周围那一圈让它有锚点的东西 ：tool registry（工具注册表）、context（上下文）管理、guardrails（安全护栏）、agent loop（智能体循环）外的 loop（外层循环）、verify step（验证步骤）……Harness 的目标只有一个：Reliability（可靠性） 。不改 Prompt，只改 Harness ，也能让一个弱模型完成原本完成不了的任务。Tis 最后给出了他对未来的判断：
2027 年，他希望是「动态、即时生成的 Harness」之年 ——用户对 Agent 说一句「帮我订张机票」，Agent 先为自己生成一个 harness ：识别可能出错/可能幻觉的地方，写好 guardrail（安全护栏）和 verify step（验证步骤），再去执行任务。这是 plan mode （计划模式，先制定计划再执行）的升级版，他认为这可能是迈向 AGI 的下一个合理步骤。「Models 是黑盒，Harness 是你能控制的那一切。当你掌握了 harness，你就掌握了让不可靠的智能变成可靠系统的方法。」
原视频：
YouTube Harnesses in AI: A Deep Dive — Tejas Kumar, IBM Harnesses in AI: A Deep Dive — Tejas Kumar, IBM
The agent hit a login page, panicked, reported success anyway, and the upvote never happened. Tejas Kumar's diagnosis: not a prompt problem. A harness problem.
The demo builds a browser agent on GPT-3.5 Turbo (consciously choosing a VERY old model to show how good harness eng can improve it a lot) against Hacker News and layers in a harness without touching the prompt once. Guardrails cap iterations and compact context. A verify step reads the tool call history to catch the agent lying about what it did. A login handler watches the browser URL each loop and injects credentials programmatically when it hits the login page. By the end the cheap old model reliably logs in and upvotes the post.
Speaker info:
- https://x.com/TejasKumar_
- https://www.linkedin.com/in/tejasq/
- https://github.com/TejasQ
Timestamps:
0:00 Introduction to Tejas Kumar and AI Harnesses
1:45 Why we use harnesses: Reliability and control
3:00 Defining an agent harness from first principles
4:32 Key components of an agent harness (Tooling, Context, Guardrails)
5:59 Starting the demo: Building a browser agent
7:00 Inspecting the initial agent loop
8:12 The problem: Agent failure and hallucination
10:20 Adding guardrails and context management
11:54 Refactoring into a formal harness
13:02 Implementing a verify step to catch lies
15:36 Implementing a login handler for programmatic access
17:42 Final demonstration: Successful autonomous upvoting
18:34 Summary and the future of dynamic harnesses
YouTube