我打赌，一半人没看到 harness 的精髓

近一年所有 AI agent 项目里都在讲 harness。LangChain 在讲、OMC 在讲、Cursor 在讲、随便一个新创业团队的 PR 通稿都要带一句"我们的 agent harness 设计得多优雅"。

但目前关于 harness 的讨论，大多其实在讲 workflow。

这两个词差一个字，对应的是两种完全不同的工程演进路径。

多数人讲的 harness ≠ harness

打开任意一个热门 agent 框架的"harness 教程"，看到的内容大概率是这种：

• 怎么把 5 个 agent 串起来跑（这是 orchestrator）
• 怎么让 agent 选择调用哪个工具（这是 agent loop）
• 怎么管理多 agent 共享状态（这是 state machine）
• 怎么动态加载新 skill（这是 plugin system）

这些都是好东西。但都不是 harness。

它们的共同点：全部在 agent 视野内运行。agent 看得到、agent 能调用、agent 能选择不调用、agent 失败时能切换。这是工作流的特征——让 agent 内部更聪明、更自由。

真正的 harness 走相反方向：让 agent 在 agent 看不见的层被限制。

agent 看不到的层

很多 agent 框架现在提供的 skill / plugin 系统就是这种工作流——一个清理代码的 skill 被注册给 agent，agent 觉得"这次需要"就调，觉得"这次不需要"就不调。skill 是 agent 视野内的工具。

如果某次 agent 写的代码全是冗余抽象，但它判断"不需要 cleaner"——cleaner 不会被触发。这就是 skill 形态最致命的问题：约束力来自 agent 自己愿不愿意调。

同样的设计选择在传统软件工程里早就有过前车之鉴。后来站住的方案，全部走相反方向。

iOS App Sandbox。一个 app 想读你照片库，必须向 OS 申请权限。你拒绝，这个 app 永远调不到那个 API。app 看不到 OS 是怎么判断「要不要给它权限」的——决策在 OS 内核里，app 只能在 OS 划的圈里跑。app 是 agent，OS 是 harness。

GitHub branch protection。开发者 push 到 main 分支，自动被拒绝；必须经过 reviewer + CI 通过才能 merge。开发者看不到这套规则配在哪个 settings 里——规则在仓库管理员的视野里，开发者只能在管理员划的圈里跑。开发者是 agent，branch protection + required checks 是 harness。

把这种思路移植到 AI agent：想给 agent 加一个"代码必须经过质量检查"——做法不是写一个 cleaner skill 然后期望 agent 主动调。做法是把 cleaner 做成 hook，配在 agent 工具调用的前置链上。agent 不调 cleaner 不行；agent 想绕开 cleaner 也不行；agent 甚至不知道有 cleaner 这个东西——只看到自己的代码提交被某个不可见的层卡住了。

skill 是工具——agent 决定要不要用 harness 是边界——agent 决定不了

这个差异决定了 agent 系统在实战中的安全性上限。

真正 harness 的三个物理边界

边界放在 agent 看不到的地方。

检查规则、能力列表、权限集合——这些约束应该放在 OS 级 capability、sandbox 进程外、hook 拦截器、agent prompt 看不到的配置文件里。

为什么必须看不到？因为只要 agent 能看到，就能拿来当攻击地图。把"agent 不能调 X 工具"写进 prompt，模型会知道"X 是禁忌"——下次再有相似情境，模型会用诱导性绕开 X 的方式表达同样意图。规则在 agent 视野里 = 规则被武器化。

把规则放在 agent 看不到的层，agent 只能在边界内自由跑。

做事的和把关的物理隔离。

工程界这条原则有几十年历史。生产线上的 QA 不是同一个工人自己检查自己的活；银行柜员不能同时是审计员；代码 PR 作者不能 approve 自己的 PR。

到了 agent 这一层，原则没变：写代码的 agent 不能同时是审代码的 agent；执行操作的 agent 不能批准自己的操作；写文章的 agent 不能读审稿规则。

具体实现上有几种隔离强度，从弱到强：

• 同一个 agent 不同 prompt——最弱，agent 自己能拼接两套 prompt 互相影响
• 不同 agent 同一个进程同一个 LLM——稍强，但 agent 间状态可能泄漏
• 不同 LLM 不同进程跨厂商（如 OpenAI 系审 Anthropic 系写的，反之亦然）——最强，物理上做不到串通

任一边的代码改动不影响另一边——这是物理隔离的判定标准。

fail-closed 是默认。

防火墙领域有个一线工程师都懂的规矩：检查规则跑不动时，默认 block 所有流量，不是默认放行。原因很简单——安全机制在故障期默认放行 = 故障期就是最大攻击窗口。

这条原则到 agent 一样适用。如果你的 agent 系统里某个安全检查依赖外部服务（LLM API、扫描工具、人工审核），外部服务挂了系统该怎么办？

很多人的反应是"那就先放过去吧，下次再审"——这是 fail-open。它意味着安全检查在最关键的时刻（基础设施故障期）默默失效。攻击者只要等到检查服务挂的那一刻就能绕过去。

正确的反应是 fail-closed：检查跑不动 = block 操作 + 通知人。决策权回到人手里，绝不默默放行。

fail-open 的检查跑久了，所有人都会发现"反正它有时候放过去"——这条共识一旦形成，检查就名存实亡了。

自查自己的 agent 系统

• agent 在 prompt 里能看到约束规则吗？看得到 → 你画的不是边界，是地图
• agent 能选择不调用某个安全检查吗？能 → 那个检查是 skill 不是 hook
• 安全检查跑不动时系统默认放行还是 block？放行 → 你的 fail-closed 写反了
• 写者和审者是同一个 agent / 同一个 prompt / 同一个 LLM 进程吗？是 → 隔离没做

每一项缺失，都是边界上的一个实际漏洞。

为什么很多人搞错

市场激励的方向和工程价值是反的。

加 skill 容易：写个新 skill 装上去，demo 立刻能跑，PR 通稿立刻能写"agent 能力又增强了"。

加 hook 难：要在 agent 看不见的层写代码，要测覆盖率，要应对 agent 的"假装失败"和"诱导性绕开"，做完之后 agent 看起来反而"功能没变多"——卖点不好讲。

但工程价值刚好相反。skill 让 agent 在已有边界内更自由，hook 决定边界本身——后者是更核心的工程壁垒，只是卖点弱。

绝大多数 agent 项目走第一条路，是市场激励的结果，不是工程判断的结果。

把 harness 找回原位

下次评估一个 agent 系统时，把"它有多少 skill / 多少 chain / 多少 plugin"放一边，看一眼 hook 配置、capability 列表、sandbox 边界——harness 在那里。

harness 不是把 agent 变得更自由的工具。是 agent 看不见的边界。