在 AI Agent 爆发的 2026 年，“Harness Engineering”（驾驭工程）成为开发者社区的热词。什么是 Harness Engineering？它如何在实际项目中运作？硅基流动「开发者说」访谈了前产品经理、现 AI 开发者姬阁阁（网名产品二姐），通过一个名为 Book2Skills 的实际项目，分享了她对 Harness Engineering 从模糊到清晰、从理念到实践的完整探索。
作为一位深耕 AI 领域的创业者与实践者，她不仅详细拆解了构建 Harness 的四个关键步骤，更坦诚地分享了打磨 Skill 过程中的试错与思考。这是一次接地气的经验复盘：关于如何让 AI 真正可靠地工作，关于技术如何服务于真实的商业场景。以下是她的讲述。
最近新模型纷纷发布，模型介绍里几乎都能看到 Agentic、Coding 这些关键词，以及对 OpenClaw、Hermes Agent 的支持。这些都在传递一个信号：AI Agent 已成为行业共识。这也解释了为什么 Harness Engineering 这个概念会在这个阶段引发共鸣：它体现了我们对 AI 能力的信任，AI Agent 正在真正走向生产环境，真的在落地了。
前段时间大家都在聊 Harness Engineering，不过我有一个略显保守的判断：真正在项目里把这套理念和机制运作起来，至少需要一年。
我第一次看到这个概念时，有一种“既模糊又精准”的矛盾感。模糊是因为这个词听起来挺抽象，精准感来自于它恰好描述了我一直在实践、一直在思考的内容，只是之前一直找不到一个合适的词来概括。
这几年我一直在 Vibe Coding，随着模型迭代、工具框架进化，用 AI 写代码的体验也在不断改变。但这些探索的核心方向始终是：让 AI 能够持续、稳定、高质量地写好代码。比如同类问题需要反复修改，之前要在对话框里一次一次地聊，是不是有什么办法让 AI 一次就记住？再比如，AI 执行过程中遇到新问题不知道怎么解决，它就停摆了，怎么让它能自主应对？对于这些问题，在不同阶段探索过不同的解法，比如 Prompt + Workflow，上下文工程等。积累到现在我才理解，这一套方法其实就是 Harness Engineering。
Harness Engineering（驾驭工程），本质是在构建一个让 AI 能长时间且可靠执行的系统，目前主要应用在代码中，但实际上是可以应用在任何长任务的执行中。文档、标准、约束、反馈循环、自我迭代等等，这些都是 Harness 的组成部分。
正好有个一直想做的事情，我决定结合自己对 Harness Engineering 的理解实践起来，于是就有了这个项目：Book2Skills。
Book2Skills：一次 Harness Engineering 实践
这个项目的目标很简单：给 AI 一本书，它就能自动提炼核心方法论，生成一个可执行的 Skill，并开源发布到 GitHub 上，用户可以看到一个网页。我希望这个项目可以 7×24 小时无人值守地运行，我只需要偶尔看看，整个网站的内容完全是 AI 自己来做。
目前这个项目的效果肯定没有 100% 达到我的期待，但也基本满意了。而拿到这个结果的过程，就是 Harness Engineering 最核心的地方。我用四个步骤构建了这个 Harness，花了差不多两天时间。
- Step1：写需求。 一开始我只有一个模糊的想法：最好的 Skill 隐藏在经典书籍中，很多时候与其读书不如直接用书。和 AI 一起探讨，最终形成 requirements.md。
- Step2：构建 Skill. 我的项目是把书转化成 Skill，但怎么才能做好这件事？最终设计出 6 个 Skill，包含一个总 Skill，以及读书、提炼、发布 GitHub、生成 Skill 效果示例、生成网站内容的几个子 Skill。这部分耗时最多，反复打磨，有时候拆分，有时候替换，一点点调整，直到结果让自己满意为止。
- Step3：写锚定文档。 写了一篇“What is book2skills”的文档，这不是对外介绍产品，而是给自己定边界，确保接下来的 Skills 不会过度设计，不会跑偏。
- Step4：赋予 Skill 迭代能力。 每个 Skill 内部都沉淀出 Markdown，有具体的 reference 和 spec，它会按需更新自己的文件，下次运行立即生效，并让这个迭代过程能够自动化地实现。
至此，Book2Skills 这个项目中生产 Skill 的过程就完成了初步的 Harness 化。项目虽然比较小，但已经可以看到做好 Harness 的性价比很高。比如我一次性选 10 本书，它自己还会启动并行处理，给了我一点小惊喜。
经过这个小项目，我验证了启动 Harness Engineering 其实没那么难，但真正做好也并不容易，我觉得有以下三个关键点可以重点分享。
1. 文档很重要
让 AI 能够自主干活，和 AI 对齐就是必选项，而文档是我实践下来性价比最高的对齐方式。一个好的 Harness 环境包含各种各样的文档：Architecture（项目结构是什么？提供项目地图）、Execution Plan（发现哪些问题需要做）、Technical Debt（技术债务清单）、Backlog（影响业务的功能哪些不完善）等。这些文档相当于给 AI 提供了一个项目地图，遇到什么问题，AI 就先来这里找，然后 route 到对应的文档里面去读。说得夸张一点，文档是后续一切的基础。
2. Session 管理
不知道你是不是也有过类似经历：项目刚开始，AI 执行得很好，但是时间一长，当项目变复杂，AI 能力有时候会变差。出现这种情况，大概率还是上下文记忆爆炸导致的。我现在的做法是，设计一个机制让 AI 自己来解决这个问题：当上下文快满时，就把这一次对话里生成的所有东西都写一个过渡性文档和摘要，交接出去。也就是让 AI 自主发起一个 Session 转换，写一个 progress.md，然后重新开始一个新的对话。
3. Generator + Evaluator，自我迭代是精髓
这是 Harness Engineering 的核心，也是最难的部分。简单来说，流程是这样的：Generator 创建内容（比如生成一个网页）→ Evaluator 评估质量，对照设计标准提意见 → Re-generator 基于反馈改进。我们看 Anthropic 给的一个为博物馆做官网的案例里，最初版本和经过 10 次自我迭代后的版本完全不一样，没有迭代就没有最后的结果。
谁能更好地实现这个自我迭代的机制，谁就能把 Harness Engineering 做得更好，谁的 Agent 就能更好地干活儿。一方面，让 AI 能无人值守地长期运行，从几小时到几天到更长时间；另一方面，让 AI 不仅能干活，还能自己学会干得更好。这才是 Harness Engineering 的魅力所在。这种活的、自我进化的 Harness Engineering 实现出来并不容易，这也是为什么我说真正落地至少要一年，还得是在有非常先进认知的人手里才能更快、更好地实现。
专注打磨 Skill，它不性感，但有用
Harness Engineering 是一套动作组合，但在我的实践中，我有一个直观感受：高质量且持续优化的 Skill 是保证 Harness 效果好的关键。把 Skill 做好，Harness 这件事就做好了大半。
之前有段时间我觉得 Skill 就是一堆 Markdown 文件，结合 Harness 理念实践下来，我认为 Skill 的“自我进化”才是关键：可以极其方便地并行迁移、自我迭代。
现在是 Skill 爆发的阶段，每天都有大量的 Skill 被创造出来，但对自己真正好用的 Skill 很多时候还是得亲自打磨，并不能拿来即用。Skill 的增长飞快，但打磨空间也无限大。
还是结合 Book2Skills 这个项目里我打磨 Skill 的经历，分享几条关于 Skill 的思考。
1. Skill 是支撑 Agent 有效干活的更底层的原子能力，是可以被组合、被复用、甚至被交易的基础单元。
2. 我在 Book2Skills 项目里最后设计出了一个主 Skill，采用“松散指令”而非“硬编排”，AI 可以根据实际情况灵活判断。松散指令给了 AI 更大的自主权，它可以根据实际情况调整顺序，可以跳过不必要的步骤，可以并行处理多个任务。
3. 创建 Skill，不要一开始就想着做一个大而全的东西，能做所有的事。如果你的 Skill 效果不好，大概率能通过“拆”这个动作得出更好的 Skill。但具体怎么拆、拆多少、拆到什么程度，真的没有一个标准，得自己一遍一遍去试、去验证，不存在一次性完美的 Skill 版本。谁说有了AI，人就被释放出来呢？反正我是没这种感受，Skill 也好，Harness 也好，没有一劳永逸的事儿。
4. 人的产品 Sense 依然重要。在 Book2Skills 项目里，有一个“生成示例”的 Skill，这不是我和 AI 讨论出来的，而是源于我自己的判断。我也在网上看过很多 Skill，很多时候看介绍还是不知道这个 Skill 到底能干什么、能实现什么效果，所以这是我自己的一个“痛点”，那就通过 Skill 来解决它。
5. Skill 可以在运行过程中被直接修改和持久化。它不是静态的配置文件，而是一个活的、会学习的系统。前两年我的很多项目都是用 Langchain 搭建工作流来实现的，如果用户发现问题，我要修改，这个流程至少也要一天。现在我基本都用 Skill 替换了 Langchain 工作流，修改 Skill 只需要一句话，下次运行立即生效。所以，你的 AI 产品用户越多，给的反馈越多，就会一直帮你优化 Skill，让它每时每刻都在进化。
6. “次抛 Skill” 能解决问题，但如果长期使用，还是要沉淀下来，不断打磨。有人说，AI 能力这么强，需要的时候自己现写一个 Skill 就行了，为什么还要花那么大精力来打磨呢？确实，如果只用一次，这个思路可行，不过我们的很多问题和场景是有共性的，每次都重复写，质量不够好，Token 消耗也不经济。如果使用场景洞察足够精准，应用高频且广泛，那么细致打磨出来的 Skill 价值就很大，甚至完全可能成为一门生意：有人专门造轮子，其他人拿来即用或者稍微改改就能用。现在还是 Skill 的早期阶段，服务不同人群、风格化的高品质 Skill 生态也还刚刚开始，我们可以预见一个极大丰富、即插即用的 Skill 未来。
写 Skill 不是目的，解决问题才是
说了这么怎么打磨 Skill，还有一个话题值得聊聊：写 Skill 不是目的，解决问题才是。这是最近几年我服务客户过程中经常思考的一个问题，可以稍微扩展一点：用 AI 不是目的，用 AI 解决问题才是。就像最近我也感受到 Token 消耗越来越多，Coding 套餐都不够用。作为开发者，Token 消耗数、Skill 创建数都让我兴奋，但我也会常常回归到产品经理的角色，提醒自己：技术含量、难度、复杂度、优雅度等等，这些都不等同于商业回报。
很多从大厂出来的人，包括我自己，容易陷入宏大叙事，动不动就想做平台、做生态。写个 Skill 都想要解决宏大问题。其实，有些项目就是解决一个很小、很具体的需求，但它是刚需，而且能做得足够好。分享一个真实案例：我正在给一家线下眼镜店做一个项目，解决他们多个店铺手写单据的录入问题，并能实现镜片的自动下单。为实现项目目标，正在打磨多个 Skills。这个场景甚至有点“原始”，很多人不理解怎么现在还有手写单据，但现实世界远比我们理解的复杂，有太多折叠面。不眼高手低，真的投入进来做具体的事，我发现这件看似简单的事依然有很多问题和挑战，但解决了就能获得最直接的价值。
不得不说，大模型时代，变化就是常态。经过这几年的“洗礼”，我也沉淀了一些“不追热点”的稳定心态，比如我到现在也没养虾，因为我知道自己在做什么，知道为什么这么做。我和客户离得越近，越能看见那些不一定宏大、但真实存在的挑战。这些需求会让我踏实下来，把注意力放到怎么用当下最好的工具和思路去解决问题。
2026 年，模型能力还在进化，工程正在加速。打磨一个解决具体问题的 Skill，认真做 Harness Engineering，我们自己也在这个过程中持续进化着。这件事本身，自有价值。
