第3章 Harness 工程

约 1985 字大约 7 分钟

2026-06-24

这一章来聊聊 AI 工程的第三层:Harness 工程。它是什么、为什么 Agent 需要它、Claude Code 本身又是怎么做的。

3.1 为什么光有 Context 还不够

上一章我们聊了 Context 工程——把 AI 需要的信息都准备好。

但这只解决了"AI 知道"的问题。

你想想这个场景:

你让 AI 帮你重构一个代码仓库。你把所有代码、文档、历史 PR 都塞进了 Context。AI 看完了,然后告诉你:"好的,我应该先重构 utils 文件夹,然后更新测试,最后跑一遍 CI。"

然后呢?

然后还是你自己动手。

AI 说得头头是道,但它动不了手。它不能碰你的文件系统,不能执行命令,不能提 PR。

这就是 Context 工程的天花板:它只解决了"认知"层面的问题,没解决"执行"层面的问题。

要让 AI 真正能干活,你需要给它一个环境——这个环境就是 Harness。

3.2 Harness 是什么

Harness = AI 模型运行所需的全部"环境设施"。

包括但不限于:

AI 能用哪些工具(读文件?执行命令?调 API?)
AI 有哪些权限(能改你的代码?能花钱调用付费 API?)
AI 怎么访问文件系统(能看哪些目录?能写哪些文件?)
AI 跑在什么沙箱里(隔离环境,防止搞炸你的电脑)

大白话类比:雇一个实习生

这一章最核心的类比,我们把三层放在一起看:

层级	你在做什么	大白话
Prompt 工程	告诉员工"做什么"	"帮我重构这个项目"
Context 工程	给员工"项目资料"	把需求文档、代码仓库、历史记录都给他
Harness 工程	给员工"配好工位"	给他一台电脑、一个工位、一张门禁卡、一个 GitHub 账号

你想想,你招了个实习生。你跟他说清楚了要做什么(Prompt),给了他所有项目资料(Context)。但如果你不给他电脑、不给他工位、不给他系统账号——他还是干不了活。

Harness 就是"给 AI 配工位"这件事。

3.3 Harness 的四个关键组成

组成一:工具定义(Tools)

你得明确告诉 AI:"你能用哪些工具"。

比如:

你能读文件,但只能读 docs/ 目录下的
你能执行 git 命令,但不能执行 rm -rf
你能调用一个搜索 API,但每天最多调 100 次

这些"工具定义"就是 AI 的"工具箱"。工具箱里有什么,AI 就能用什么。

类比: 你给实习生配了一台电脑,但电脑上只装了 Word 和 Excel,没装 Photoshop。那他就只能做文档和表格,做不了设计。

组成二:权限管理(Permissions)

工具定义了"有什么"。权限管理定义"能不能用"。

同样是"执行命令"这个工具:

执行 ls(列目录)——不需要确认,直接放行
执行 git commit——需要用户确认一下
执行 rm -rf /——绝对不允许,直接拦截

权限管理就是给每个工具配上一个"审批规则"。

类比: 实习生有公司的门禁卡,但他只能进办公区,进不了机房。同样一张卡,权限不同。

组成三:文件系统访问(File Access)

AI 需要读写文件。但你不能让它随便碰你电脑上的任何文件。

一个好的 Harness 会:

限定 AI 只能访问项目目录
敏感文件(如 .env、密钥文件)对 AI 隐藏
AI 写的文件先放在一个"暂存区",你确认后再真正写入

组成四:沙箱隔离(Sandbox)

最关键的一道安全防线。

AI 执行的所有操作,都跑在一个隔离环境里。即使 AI 犯了错(或者被恶意 Prompt 攻击了),影响范围也被限制在沙箱内,不会波及你的真实系统。

类比: 你让实习生在"练习环境"里先操作一遍。他搞砸了也没关系,因为练习环境是独立的,不会影响线上系统。

3.4 为什么 Agent 特别需要 Harness

2025 年下半年开始,"Agent"这个词火得一塌糊涂。

Agent 和普通 AI 对话的区别在于:普通 AI 只是"回答你",Agent 会"自己动手"。

一个真正的 Agent 需要:

自己决定下一步做什么(规划)
自己调用工具(执行)
根据工具返回的结果调整计划(反馈)
一直循环直到任务完成(自主)

这意味着 Agent 会频繁地、自主地操作你的系统。如果没有一个好的 Harness,Agent 分分钟把你的项目搞炸。

一个真实的教训

2025 年有一个广为流传的案例:有人让 AI Agent 自动部署代码,但没有设好权限。Agent 觉得旧版本的日志文件"碍事",自己执行了 rm -rf 清理。结果把整个生产环境的数据库给删了。

这就是没有 Harness 的代价。

3.5 Claude Code 就是一个教科书级的 Harness

说点具体的。Claude Code 本质上是什么?

Claude Code = Claude 模型 + 一个精心设计的 Harness。

我们来看看 Claude Code 的 Harness 长什么样:

Harness 组件	Claude Code 怎么做的	大白话
工具定义	内置了读写文件、搜索、执行命令等工具	给实习生配好了电脑和软件
权限管理	有 `--allowedTools` 配置,危险操作要用户确认	危险操作需要你点头
文件访问	通过 `CLAUDE.md` 和工作目录限定范围	实习生只能在指定区域活动
沙箱	命令执行有超时限制和拦截机制	给实习生设了"红线"

你看,Claude Code 之所以让人觉得"靠谱",不是因为它用的模型有多强(虽然确实强),而是因为它的 Harness 设计得好。

模型是"大脑",Harness 是"身体"。光有大脑没有身体,什么也干不了。

3.6 Harness 工程的实操建议

如果你在用 Claude Code 或类似的 AI 编程工具,这里有几个 Harness 层面的实操建议:

建议一:写好 CLAUDE.md

CLAUDE.md 是 Context,但它也影响 Harness——因为它告诉 AI "这个项目的边界在哪"。

建议二:用好权限配置

// .claude/settings.json 示例
{
  "permissions": {
    "allow": [
      "Read",           // 允许读文件
      "Write",          // 允许写文件
      "Bash(npm test)", // 允许跑测试
      "Bash(git *)"    // 允许 git 操作
    ],
    "deny": [
      "Bash(rm -rf *)", // 禁止危险删除
      "Bash(sudo *)"   // 禁止提权
    ]
  }
}

把危险的、不可逆的操作拉进 deny 名单。这是 Harness 工程最基本的一步。

建议三:让 AI 先在分支上干活

不要让 AI 直接在主分支上操作。让它创建一个新分支,在那里随便折腾。出问题了直接删掉分支,主分支不受影响。

这就是"沙箱思维"——给 AI 一个可以犯错的空间。

3.7 Harness 工程的天花板

Harness 解决了"AI 能干活"的问题。但它还有一个短板。

AI 还是得你告诉它干什么。

你给它配好了工位、电脑、门禁卡。然后呢?你还是得一个一个任务地告诉它:"现在做这个""现在做那个""不对,重来"。

你想想,这不就是"手动驱动"吗?你变成了一个"人肉任务分配器"。

有没有可能……让 AI 自己决定该干什么?

有。那就是下一章的内容——Loop 工程。

下一章来聊聊最新最热的 Loop 工程,让 AI 自己驱动自己:第 4 章 Loop 工程