周六在上海的 AI Maker Summit 大会上，分享了一下我们在 Harness Coding 上的一些实践。 这次也把分享时使用的 PPT ，以及我演讲前准备的完整口播稿 ，一起放到公众号上。 这里先多聊两句。 我个人做 PPT 的习惯，一般是先把整场 PPT 梳理出来，然后再针对每一页，单独写对应的口播稿。 写口播稿并不是为了逐字背诵，更多是为了提前把整场分享过一遍。 而真正到了现场，我会基于每一页 PPT 建立几个自己的 演讲锚点 ，只记住关键的核心内容，具体怎么讲，会根据现场状态调整。 所以这篇文章里放出来的，是我 演讲前准备的版本 ，和当天实际讲出来的内容会有一些差异，但整体逻辑和核心观点基本一致。 另外，因为它本质上是一份 口播稿 ，不是按照公众号文章重新写的一篇长文，所以读起来会更口语化一些，也会保留一些现场转场和重复说明。 大家可以把它理解成： 这场分享的 PPT ＋完整演讲底稿。 接下来，正式开始。 关于 Harness ，在我的体感里，大概是从 25 年 11 月份，Anthropic 对外发表关于长任务运行的工程实践开始。 整个 AI Coding 领域，开始逐步从 Vibe Coding 往更加工程化的方向演进。 然后到了 26 年 2 月份，OpenAI 又发表了一系列 Harness Engineering 相关的内容。 此时关于 Harness 、反馈回路这些话题，也逐渐在国内开始蔓延。 所以其实你现在如果想学习 Harness ，能够找到的材料已经很多了。 OpenAI 、Anthropic 的工程文章，开源项目，还有各个团队的实践，都可以拿来参考。 我们自己学习的时候，也会让 AI 帮忙读这些资料，梳理里面的思路，再放到自己的项目里尝试。 所以方法越来越容易获得，模型本身也一直在进步。 那我们还在线下分享这些东西，有什么价值？ 这个我思来想去，我觉得价值其实就在大家各自不同的经历里。 同一个方法，到了不同的项目中，可能会遇到完全不同的问题。 我们做过哪些优化，后来为什么又改了，哪些东西最后留下来了， 这些细节往往比单纯地再读一篇博客更值得交流。 所以我今天想分享的，也主要是这些内容。 从我们最开始遇到了什么问题，到围绕这些问题做了哪些优化，再到这些设计真正放进一次开发任务里以后，到底是怎么工作的。 对于刚接触 Harness 的朋友，我会尽量用一个简单的例子把整个过程讲清楚。 已经在实践的朋友，也可以对照一下自己的项目，看看我们的取舍是不是一样。 我们遇到类似的问题，差不多也是在 4 月份的时候。 当时我们在用 AI 编程的过程中，比较明显地遇到了两个问题。 第一个是测试。 Agent 告诉我们，代码已经改好了，测试也做完了。 但再去看实际执行情况，会发现验证并没有充分完成。 它最后给出的完成总结，和我们真正能够核对的结果之间，还是存在一些距离。 第二个是架构。 AI 改出来的功能可以用，但是没有遵守项目原来的模块约定。 我举一个比较通用的例子。 一般一个软件产品里，都会有用户账号管理相关的功能。 账号模块通常会有自己独立的封装，账号状态变更、权限校验等逻辑都会在这里处理。 但是 AI 在实现某个业务功能的时候，可能没有复用账号模块，而是直接去修改账号表。 短期来看，状态确实改成功了。 但是从整体代码来看， 它已经偏离了我们最初定义的架构规范。 这两类问题都在提醒我们： AI 交付产物的时候，我们不能只看它最后回答了什么。 代码到底是怎么实现的，经过了哪些验证，有没有破坏项目原来的架构约定，这些我们都需要有办法看清楚。 只有这样，我们才能更加信任 AI 在企业业务场景下的产出。 那这两个问题，其实都指向了同一个更根本的问题。 现在通用的 Coding Agent ，已经非常擅长改文件、执行命令这些具体工作了。 那为什么真正进入项目以后，它的产出还是经常达不到我们想要的要求？ 后来我们把这个问题拆下来，发现主要来自四个方面。 这个地方我觉得很重要。 因为后面我们会讲到 OpenWiki 、知识地图、多 Agent 、Hook ，这些其实都是“术”，都是具体执行层面的手段。 那它背后的“道”，也就是我们真正需要解决的根因是什么？ 就是下面这四个问题。 第一，模型本身很擅长基于当前上下文去理解和推理下一步应该做什么。 但它天然不知道你们项目里的真实事实。 比如，它不知道这段代码背后曾经出现过哪些故障，也不知道为什么当年做了某个特殊的设计，更不知道里面可能存在什么历史债务。 所以这些项目上下文的缺口，需要我们通过一系列技术手段主动提供给模型。 也就是： 它知道吗？ 第二：它做得到吗？ 即使 Agent 推理出来它应该做什么，也不代表它真的有办法完成。 比如，它知道这个时候应该去查看上下游服务日志，但是没有访问日志平台的工具。 它也知道应该运行集成测试，但没有办法启动相关的上下游服务。 因此，除了给它项目事实以外，我们还需要给它提供真实的工具、运行环境、权限和操作入口。 这一层解决的是： 让它不只是知道应该做什么，而且真的做得到。 第三：它看得见结果吗？ Agent 做完动作以后，我们还需要把真实的运行结果交给它。 比如测试到底有没有通过，接口真实返回了什么，数据库状态有没有发生变化，当前的覆盖率和性能指标到底是多少。 这样它才能根据真实结果，判断下一步应该做什么。 这一层解决的是： 让判断建立在真实结果上，而不是模型自己的预期上。 第四：它知道什么时候才算结束吗？ 即使 Agent 已经拿到了真实结果，它也不天然知道哪些条件必须全部满足以后，这个任务才允许结束。 它可能只运行了单元测试，没有运行集成测试。 也可能某个检查已经失败了，但它觉得这个问题不重要，于是仍然决定继续往下走。 所以我们需要提前定义清楚完成标准，再通过 Hook 、脚本、CI 、合并策略和人工审批，把这些标准真正接到控制点上。 比如覆盖率必须达到 80%，架构检查不能失败。 任何一个必要条件不满足，就不能结束，也不能进行代码合并。 这一层解决的是： 不只是告诉 Agent 什么叫完成，而是让不满足条件的任务无法被当成完成。 所以整个项目级 Harness 真正要解决的，可以总结成四句话： 第一：给 Agent 注入正确的项目上下文； 第二：给 Agent 在真实环境中行动的能力； 第三：把真实的运行结果反馈给 Agent ； 第四：不满足完成条件，就不允许任务结束。 所以后面我们讲到的 OpenWiki 、Spec 、测试脚本、Hook ，甚至多 Agent ，其实都是围绕这四个问题在解决。 这些都是术。 而这四个问题，才是为什么通用 Coding Agent 进入真实项目以后，我们仍然需要项目级 Harness 的根本原因。 接下来我们用一个比较简单的业务场景来举例，然后一步一步往下深入，看一套项目级 Harness 是怎么逐渐长出来的。 比如我们给 AI 的原始需求是： 开发一个新的需求，历史账号只有完成迁移以后，才能走激活流程，其他账号不受影响。 这个时候第一步，我们需要先把原始需求转成可检查的 Spec 文档。 也就是把一句自然语言需求，变成后面可以真正拿来开发和验收的依据。 什

  • 情报分类：商业与市场研究
  • 分类依据：内容涉及商业、投资或市场动态
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/9/28 11:00:48