芯耀
与非AI
389
转载自公众号：敢敢AUTOHUB
1. 理解 AI 的"失忆症"——为什么需要 Harness？
1.1 AI 其实没有记忆
很多人以为跟 AI 聊天时，它会一直记得你说过的话。但真相是：每次你按下回车，都会有一个全新的 AI 被召唤出来。它不认识你，也不记得你们之前聊了什么。它之所以能接上话，是因为系统把你们之前所有的对话记录重新塞给它看了一遍。
想象一下这个场景：你在医院看病，每次进诊室都是不同的医生。但每个医生进来之前，都会先看一遍你的病历。所以虽然医生换了，但看起来他们都"记得"你的病情。AI 就是这样工作的——它本身没有记忆，靠的是"病历本"（上下文窗口）来维持对话的连续性。
这种工作方式在技术上叫做模型无状态性。每次 API 调用都会创建一个新的 AI 实例，处理完请求后立即消失。就像工厂流水线上的临时工，干完自己那一下就下班了，下一个临时工接着上。
1.2 100 个临时工完成一个任务
让我们看一个更具体的例子。当你让 AI 助手"帮我修复这个 bug"，等了 30 秒它回复"改好了"。这 30 秒里实际发生了什么？
轮次 1：召唤临时工 A → A 说"我先读一下报错的文件" → 系统读取文件 → A 消失
轮次 2：召唤临时工 B → B 看到文件内容，说"我再看看相关的测试" → 系统读取测试 → B 消失
轮次 3：召唤临时工 C → C 说"找到问题了，我改一下" → 系统写入文件 → C 消失
轮次 4：召唤临时工 D → D 说"跑一下测试看看" → 系统执行测试 → D 消失
轮次 5：召唤临时工 E → E 看到测试通过，说"改好了" → 循环结束 → 你看到回复
你看到的是最后那句"改好了"，但背后是 5 个不同的 AI 实例接力完成的。如果任务更复杂，可能需要 50 轮、100 轮对话。假设系统挂了 3 次、重启了 3 次，最后任务完成了，整个过程可能出现过 100 个不同的 AI 实例。
问题来了：是什么让这 100 个临时工协作起来不掉链子的？答案就是 Harness。
2. Harness 是什么？一句话说清楚
2.1 马具的比喻
Harness 这个词的原意是"马具"——套在马身上的那套皮带和缰绳。Anthropic 公司用这个比喻特别贴切：模型是马，Harness 是缰绳。你不需要一根比马更强壮的缰绳，多一根皮带都是累赘。
Harness 就是一个让 AI 能持续工作的执行框架。它只干三件最核心的事情：
1. 执行工具：模型说"帮我读一下这个文件"，Harness 就去读，把结果交回来
2. 管理上下文：把对话历史、工具结果、错误信息打包好塞给下一个 AI
3. 失败恢复：工具调用出错了，把错误信息原样返回给模型，让模型自己决定怎么办
注意——Harness 不负责规划，不判断对错，不评估好坏。模型说干什么它就干什么，干完把结果交回去。这种设计哲学叫做"薄框架"：Harness 是哑的，所有聪明的部分都在模型里。
2.2 While 循环：Harness 的心脏
Harness 的核心是一个 while 循环。什么是 while 循环？想象你在烧水，你不知道水什么时候开，但你知道一件事——水没开之前你得一直看着。所以你做的事是：看一眼壶 → 没开 → 等一会儿 → 再看一眼 → 没开 → 再等…… 直到水开了，你才停下来。
这就是 while 循环的本质：只要某个条件还成立，就一直重复执行同一套动作。
放到 Harness 里就是：
while (任务未完成) {
召唤新 AI → AI 决定用什么工具 → Harness 执行工具 → 结果塞回历史 → AI 消失
}循环什么时候停？只有三种情况：
正常退出：模型说"我搞定了"，没有更多工具请求•
保底退出：达到预设的最大循环次数（防止无限循环烧钱）•
异常终止：被用户手动打断、断电、程序崩溃
特别要注意：工具调用失败不是退出条件。如果 AI 让 Harness 去读一个文件，文件不存在，Harness 会把"文件不存在"这条错误信息原样返回给 AI。AI 看到后自己决定下一步：是换个文件名试试？还是先创建这个文件？"这条路走不通"本身就是有价值的反馈。
3. Harness 的六大核心组件
理解了 Harness 的基本概念后，我们来看看它具体由哪些部分组成。一个完整的 Harness 系统通常包含六大核心组件，每个组件都有明确的职责。
3.1 Agentic Loop（智能体循环）：系统的心脏
这是 Harness 最核心的部分，就是我们前面讲的 while 循环。它接受用户的输入，然后在返回最终结果之前，会经历一个详细的循环过程：调用模型 → 模型返回工具请求 → 执行工具 → 把结果塞回上下文 → 再次调用模型 → 继续循环……直到模型说"任务完成"。
这个循环看起来简单，但所有复杂的智能行为都从这个简单循环中涌现出来。就像细胞分裂的规则很简单，但能长出复杂的生命体。这个设计思想来自 2022 年的 ReAct 论文（Reasoning and Acting），它提出 AI Agent 应该是一个"推理-行动"的循环系统。
3.2 Tool System（工具系统）：AI 的手和脚
大语言模型本身只能生成文本，但通过工具系统，它可以真正与现实世界交互。工具系统让 AI 能够读写文件、执行代码、搜索网页、查询数据库、发送消息等等。
Claude Code 的工具设计哲学特别值得学习：少而精，原子化。它只提供几个最基础的工具：读文件（Read）、写文件（Write）、执行命令（Bash）、搜索内容（Grep）、版本控制（Git）。没有复杂的"代码分析器"或"项目理解引擎"，但通过这几个原子工具的组合，AI 可以完成极其复杂的任务。
为什么不提供更多工具？因为工具越多，模型的注意力就越分散。每个工具的定义都要占用上下文窗口，工具太多会导致模型"选择困难症"。而且，Unix 命令行工具已经被程序员用了 50 年，模型的训练数据里见过海量的使用示例，天然就"会用"这些工具。
3.3 Memory & Context Management（记忆与上下文管理）
还记得我们说的"临时工"比喻吗？每个新召唤的 AI 都需要看"病历本"才知道之前发生了什么。这个"病历本"就是上下文窗口，而如何管理这个窗口，是 Harness 最关键的技术之一。
上下文管理面临几个核心挑战：
挑战一：窗口容量有限。即使是最新的模型，上下文窗口也有上限（比如 200K tokens）。一个复杂任务可能产生几百轮对话，如果全部保留，很快就会爆掉。
挑战二：信息密度不均。有些对话很重要（比如用户的核心需求），有些是临时的（比如某次失败的尝试）。如何决定保留什么、丢弃什么？
挑战三：上下文污染。如果把所有历史都塞进去，模型可能会被无关信息干扰，反而降低性能。
Claude Code 在这方面做得特别好，它使用了多种技术：上下文压缩（把长对话总结成摘要）、分层存储（重要信息放在主上下文，次要信息放在外部存储）、按需加载（只在需要时才加载相关文档）。
3.4 Guardrails（护栏）：安全的缰绳
Guardrails 是 Harness 的安全机制，确保 AI 不会做出危险或不当的操作。它通常包含三种控制策略：
Allow（允许）：某些操作可以自动执行，不需要询问用户。比如读取项目文件、搜索文档等低风险操作。
Deny（拒绝）：某些操作被明确禁止。比如删除系统文件、访问敏感数据、执行危险命令等。
Ask（询问）：某些操作需要用户确认。比如写入文件、执行代码、发送网络请求等。这就是为什么你用 Claude Code 时，它会经常问你"是否允许执行这个操作"。
Guardrails 的设计需要在安全性和效率之间找到平衡。如果每个操作都要询问，用户会觉得很烦；如果什么都不问，又可能出现安全问题。好的 Guardrails 设计应该是：低风险操作自动执行，高风险操作必须确认，危险操作直接拒绝。
3.5 Hooks（钩子）：质量守卫
Hooks 是在特定时机自动触发的检查机制，就像代码提交前的 Git Hooks。它们确保系统在关键节点进行必要的验证。
常见的 Hooks 包括：
Pre-execution Hook：在执行工具前检查参数是否合法•
Post-execution Hook：在执行工具后验证结果是否符合预期•
Pre-commit Hook：在提交代码前检查是否包含敏感信息（比如 API 密钥、密码）•
Quality Hook：在任务完成前进行质量检查
举个例子：你让 AI 帮你写代码并提交到 GitHub。Pre-commit Hook 会自动检查代码中是否包含 .env 文件、是否有硬编码的密码。如果发现问题，会阻止提交并提醒 AI 修复。这种自动化的质量守卫，能避免很多低级错误。
3.6 Session（会话）：持久化的工作记录
Session 管理解决的是"关掉窗口还能接着干"的问题。它把工作进度、环境状态、历史记录持久化到硬盘上，即使程序崩溃或重启，新的 AI 实例也能无缝接续。
一个完整的 Session 通常包含：
对话历史：所有的用户输入和 AI 回复•
工具调用记录：执行了哪些工具、参数是什么、结果如何•
环境状态：当前工作目录、已安装的依赖、环境变量等•
进度标记：哪些任务已完成、哪些正在进行、哪些还未开始
Session 的设计让 AI Agent 从"一次性对话"升级为"可持续工作的系统"。你可以今天让 AI 开始一个项目，明天继续，后天再调整，就像跟一个真实的团队成员协作一样。
4. Harness 解决的五大实际问题
理论讲完了，我们来看看 Harness 在实际应用中解决了哪些关键问题。这些问题在早期的 AI Agent 系统中非常常见，直到 Harness 的出现才得到系统性的解决。
4.1 无限循环——AI 陷入死循环怎么办？
场景重现：你让 AI 帮你调试一个 bug，它尝试了一种方法失败了，然后又尝试同样的方法，再失败，再尝试……陷入无限循环，API 费用疯狂增长。
Harness 的解决方案：
1. 设置最大循环次数：比如限制 50 轮对话，超过就强制退出
2. 检测重复模式：如果连续 3 次执行相同的工具调用且都失败，自动中断并提示用户
3. 成本监控：设置预算上限，超过阈值自动暂停
这就像给烧水的人设置一个闹钟：如果 30 分钟还没烧开，说明可能出问题了，别再傻等了。
4.2 上下文爆炸——对话太长导致系统崩溃
场景重现：一个复杂任务需要 100 轮对话，每轮对话都在上下文窗口里累积。到第 80 轮时，上下文窗口已经塞满了，模型开始"焦虑"——它知道窗口快满了，就草草收尾、提前宣布完成，实际上任务根本没做好。
Harness 的解决方案：
1. 上下文压缩：每隔 20 轮对话，把历史总结成一段摘要，清空详细记录
2. 分层存储：核心信息保留在主上下文，详细日志存到外部文件
3. 智能裁剪：保留最近的对话和最重要的历史，中间的临时信息可以丢弃
想象你在写笔记，笔记本快写满了。你不是把前面的内容全撕掉，而是把重点提炼成一页摘要，详细内容归档到文件柜里。需要时再去翻阅。
4.3 权限失控——AI 执行了不该执行的操作
场景重现：你让 AI 帮你清理项目中的临时文件，结果它把整个项目目录都删了。或者它在你不知情的情况下，把代码提交到了公开的 GitHub 仓库，泄露了公司机密。
Harness 的解决方案：
1. 权限分级：读操作自动允许，写操作需要确认，删除操作需要二次确认
2. 沙箱环境：AI 在隔离的环境中执行操作，不能直接访问系统核心文件
3. 操作审计：所有操作都有日志记录，可以追溯和回滚
这就像给实习生分配任务：看文档随便看，改代码要给我看看，删东西必须经过我批准。
4.4 质量不可控——AI 说做完了但实际没做好
场景重现：你让 AI 实现一个登录功能，它说"已完成"。你一测试，发现密码验证根本不工作，或者界面上按钮点了没反应。AI 过早宣布胜利，实际上功能有严重缺陷。
Harness 的解决方案：
1. 强制测试：功能实现后，必须运行测试用例，测试通过才算完成
2. 独立评估器：用另一个 AI 实例来验证第一个 AI 的工作成果
3. 结构化验收：用 JSON 格式定义功能清单，每个功能必须有明确的 status 字段
这个设计特别巧妙。为什么要用独立的评估器？因为让运动员自己掐表，总会给自己掐个好成绩。评估器看不到实现过程，只看最终结果，所以更客观。
4.5 成本不透明——不知道花了多少钱
场景重现：你让 AI 帮你做一个项目，任务完成后发现 API 账单是预期的 10 倍。因为中间有很多失败重试、无效循环，但你完全不知道。
Harness 的解决方案：
1. 实时成本监控：每次 API 调用都记录 token 消耗和费用
2. 预算预警：设置预算上限，达到 80% 时提醒，达到 100% 时暂停
3. 成本分析报告：任务完成后，生成详细的成本分析，显示哪些环节最贵
就像打车软件会实时显示费用，让你知道这趟车要花多少钱。如果发现路线不对，可以及时调整。
5. Harness 的设计哲学——薄框架与厚技能
理解 Harness 的设计哲学，能帮助你做出更好的架构决策。这部分我们深入探讨"Thin Harness, Fat Skills"（瘦脚手架，胖技能）的核心思想。
5.1 为什么要"瘦"？
很多人的第一反应是：既然 Harness 这么重要，是不是应该做得越强大越好？提供越多功能越好？
答案恰恰相反。Harness 应该保持简单，只做最核心的事情。
原因有三个：
1. 避免上下文污染
每个工具的定义都要占用上下文窗口。如果你在 MCP 协议里塞了 40 多个工具定义，上下文窗口被占满，模型的大部分注意力花在理解工具定义上，而不是做正事。
有个真实数据：Playwright CLI 每次浏览器操作 100ms，而通过 Chrome MCP 做同样的事要 15 秒。75 倍的速度差距。为什么？因为 MCP 的工具定义太复杂，模型需要花大量时间理解和选择。
2. 保持灵活性
模型每年都在变强。今年需要的脚手架明年可能就不需要了。框架越厚，未来拆除的成本越高。
还记得前面讲的吗？当模型从 Sonnet 4.5 升级到 Opus 4.6 后，很多原本"必需"的组件直接被删掉了。如果这些组件跟核心架构深度耦合，删除会非常困难。
3. 涌现的力量
少而精的原子工具，通过组合能涌现出强大的能力。这比提供一堆专用工具更有效。
Claude Code 只有 5 个基础工具，但能完成极其复杂的任务。为什么？因为这 5 个工具是精心选择的"原子操作"，它们的组合空间是指数级的。
5.2 什么是"胖技能"？
如果 Harness 要保持简单，那复杂性去哪了？答案是：转移到 Skill 文件里。
Skill 文件是用自然语言写的"程序"，它教模型"怎么做某件事"。一个好的 Skill 文件应该：
1. 包含丰富的领域知识
不是简单的步骤列表，而是包含判断标准、边界条件、常见陷阱、最佳实践。
2. 像函数一样可复用
同一个 Skill，传不同参数，能产生完全不同的能力。比如 /investigate 这个 Skill：
- • 传入"医疗研究数据" → 模型变成医疗分析师• 传入"财务申报数据" → 模型变成法证调查员
3. 可以持续优化
Skill 文件是文本，可以版本控制、可以 A/B 测试、可以根据反馈持续改进。
这就是"胖技能"的含义：把人的判断和经验固化成可复用的文档。
5.3 潜在空间 vs 确定性执行：画一条清晰的线
Harness 设计中最重要的原则之一：清楚地区分什么该 AI 做，什么该工具做。
潜在空间的事，交给 AI：
- • 阅读理解• 判断综合• 模式识别• 检测矛盾
确定性执行的事，交给工具：
- • SQL 查询• 代码编译• 数学计算• 算法分配
经典反面案例：让模型给 800 人排座位。这是个组合优化问题，需要精确的约束求解。模型会一本正经地给出一份看起来很合理的座位表——但仔细检查就会发现各种冲突。
正确做法：让 AI 理解每个人的偏好和约束，然后调用专门的优化算法来计算座位分配。AI 负责理解，算法负责计算。
混用是 AI Agent 系统中最常见的架构错误。不是模型不够聪明，是你让它干了不该干的活。
5.4 从 Prompt 到 Context 到 Harness：三次跃迁
回顾 AI 工程的演进，我们经历了三次重要的思维跃迁：
2023 年：Prompt Engineering
那时候我们研究怎么写 prompt："你是一个很聪明的工程师"，"请你一步一步思考"。核心是让模型理解我们的意图。
2024-2025 年：Context Engineering
我们意识到：你给模型什么，就是你能从模型得到的。做企业知识库、做 RAG、优化上下文窗口。核心是给模型提供高质量的信息。
2026 年：Harness Engineering
现在我们需要的不只是回答问题，而是完成任务。设计循环策略、工具系统、质量审核、权限控制。核心是构建可控的系统。
每一次跃迁都不是否定前一阶段，而是在更高的层次上整合。好的 Harness 系统仍然需要好的 Prompt 和 Context，但它们现在是更大系统的一部分。
6. 从码农到系统工程师：永不失业的秘诀
在 AI 时代，有一个残酷的事实：工程师永远不会失业，但码农可能会失业。
什么是码农？就是单纯写代码的人。当 Agent 可以生成代码的时候，码农的价值就会被替代。
什么是工程师？是能够设计并驾驭复杂系统的人。工程师的核心能力不在于写代码，而在于：
1. 理解系统的复杂性
能看到表面问题背后的系统性原因。比如性能问题不只是代码慢，可能是架构设计有问题；用户体验差不只是界面丑，可能是业务流程有问题。
2. 抽象和结构化思维
能把复杂的问题拆解成清晰的结构。这是设计模式、架构模式、Harness 模式的共同基础。抽象能力是工程师最核心的竞争力。
3. 驾驭不确定性
AI Agent 是概率系统，不是确定性系统。工程师需要学会在不确定性中做决策：如何设置容错机制？如何平衡成本和质量？如何在失控和过度控制之间找到平衡？
4. 深度理解业务
越是在 AI 时代，懂业务越重要。AI 可以写代码，但它不知道这个功能为什么重要、用户真正需要什么、哪些边界条件必须考虑。这些只有深度理解业务的人才知道。
5. 持续学习能力
技术变化太快，具体的工具和框架会过时，但学习能力不会。能快速理解新概念、能从第一性原理思考、能在混乱中找到规律——这些元能力是永恒的。
7. 结语：Harness 是驾驭 AI 的缰绳
我们从"AI 的失忆症"开始，理解了为什么需要 Harness。然后深入学习了 Harness 的六大核心组件、解决的五大问题、演化的四个阶段。我们看到了真实的大规模应用案例，学习了实践指南和设计哲学。最后展望了未来方向和个人成长路径。
如果要用一句话总结 Harness 的本质，那就是：Harness 是我们驾驭 AI Agent 这个"不确定性系统"的缰绳。
参考链接
https://github.com/deusyu/harness-engineering
