DeepSeek 刚刚开源了自己的 Harness。官方把它的核心思路概括成“一切皆插件”：模型、工具、Skill、会话、沙箱，甚至 loop 和 UI，都可以通过插件组合和替换。连 Agent loop 也只是一个可以替换的插件。
当 Agent 开始同时生成多组代码改动，很多团队最先想到的，还是把审查做得更细：代码要 review，diff 要检查，写之前要规划，写完要测试，中间每一步最好都有 Skill 约束。机器写得越快，人就得审得越快，将来团队之间的效率差异，可能就看谁能更快完成审查。
这些要求各有理由，但我不太认同这个方向。
一个 Agent 一次生成一份代码，人或许还能逐行检查。当一个人可以同时调度几个 Agent，它们一天就能生成过去几周才能完成的改动，人的阅读速度再快，最后还是会成为瓶颈。
到了这个产出速度，仅仅让人审得更快已经解决不了问题。人的逐步审查还要不要继续充当研发的主循环？
旧流程曾经是合理的
传统研发流程不是凭空来的。过去代码主要由人编写，一次需求从讨论、设计到开发和上线，往往需要几周甚至几个月。实现成本很高，上线后的修复也很慢，大家自然希望在执行之前把事情想得更清楚，在执行过程中多设置几项检查。
需求评审、技术方案评审、代码审查、测试验收，每一项检查都在购买更多确定性。
那时人的判断也确实很有价值，一个经验丰富的工程师花半天看完一份 diff，可能避免团队几天甚至几周的返工。严格的流程，是组织面对高昂执行成本时形成的理性选择。
Agent 进入研发流程以后，很多团队只是让写代码这个节点变快了。需求仍然层层确认，Agent 负责实现，然后人继续逐行检查、逐项验收。为了让它更可靠，还会加入更多 Skill，规定必须先分析、再计划、再实现、再测试、再 review。
过去排队等开发，现在排队等审查。如果 Agent 的产出提高十倍，人的审查速度只提高一倍，流程的上限仍然由人决定，瓶颈也只是从“写不出来”变成了“看不过来”。
把旧流程写进 Skill，仍然可能是旧流程
Skill 有没有价值，主要看它补充的是什么。
公司的业务口径、项目目录、接口调用方式、数据出境限制和发布流程，模型不可能自己知道这些。这类知识型、项目型 Skill，在模型能力变强以后反而更有价值，因为模型能更好地理解和使用这些外部知识。
另一种 Skill 直接规定 Agent 应该怎样工作：先做什么、再做什么，任务必须拆成几步，要启动几个 subagent，经过几轮 review，遇到问题按照什么路径上报。这些规则通常在弥补某一代模型和 Agent 系统的不足，模型和执行环境变了，原来的规则也可能跟着失效。Skill 成了新瓶，装的还是旧酒。
Superpowers 就是一个很典型的例子。截至本文写作时，它在 GitHub 上已有超过 27 万 Star。Star 不等于使用者逐条认同其中的规则，但它显然不是一个边缘项目。
Superpowers 提供的不是项目知识，而是一整套软件开发方法：每项任务派一个新的 implementer，随后进行规格和代码质量审查，最后再做一次分支级 review。它还规定了 implementer 什么时候可以向 controller 请求更多上下文，以及问题怎样重新派发。
这些设计都有自己的适用背景。麻烦出在模型和执行环境变化以后，流程仍被原样套用。
有人在 Superpowers 的 issue 中报告，一项内容已经完全确定、只需要创建一个五行文件的任务，因为固定的实现、审查、修改和复审流程，触发了六七次 Agent 调用。杀鸡用了牛刀。另一个 issue 则提出，当 Claude Code 自己开始通过 Ultracode 生成动态工作流时，Superpowers 的 SDD 也在决定任务怎样拆分、怎样调度和怎样审查，于是可能出现“两套编排器同时抢方向盘”。
这两条都是社区反馈，不能据此判定 Superpowers 本身有缺陷，但至少能说明：行为约束型 Skill 同样依赖模型版本和执行环境。
Anthropic 自己就有一个更典型的例子。
为了控制新模型在 Claude Code 中过于啰嗦的问题，Anthropic 曾经在系统提示词中加入一条很具体的长度限制。这项修改经过数周内部测试，当时跑的评测没有发现性能回退。发布以后，他们扩大评测范围，逐行做了提示词消融实验，才发现这条看起来无害的行为规则，让 Opus 4.6 和 4.7 的一项编程评测成绩下降了 3%。
Anthropic 随后撤回了这条规则，并决定以后每一次系统提示词修改都要进行更广泛的分模型评测。因为不同模型的行为并不完全相同，适合一个模型的 harness，不一定适合另一个模型。
看到这里，我想到《孟子》里一句很短的话：
仲尼不为已甚者。
朱熹引杨氏的话解释：
圣人所为，本分之外，不加毫末。
我尤其服气“本分之外，不加毫末”这几个字。它主张的不是降低标准，该有的测试、审查和安全边界都在本分之内；只是规则本身也有成本，不能因为多一道流程看起来更稳妥，就默认它一定有价值。
一次多余的确认看起来无伤大雅。十个环节各自为了稳妥再增加一次确认，最后得到的未必是更安全的产品，也可能只是更多审查记录、更长的等待时间，以及一种一切都在控制之中的感觉。
流程看起来很繁荣：Skill 很多，review 很多，文档和记录也很完整。但控制的痕迹，并不等于控制的能力。
Harness 不是让 Agent 服从更多步骤
我理解的 harness，不是给 Agent 画一张更复杂的流程图。把任务交给 Agent 以前，目标要能转成验收条件，权限边界和停止条件也要说清楚。执行过程中，系统能够自动运行测试和评测，观察失败，控制灰度范围，需要时快速回滚。任务完成以后，Agent 还要一并交付测试结果、运行日志、截图或者其他可以复核的证据。
这些条件并没有预先规定 Agent 每一步应该怎么走，但它做错以后，系统能够发现，Agent 也可以根据反馈继续调整。
DeepSeek Harness 正好把这种思路做成了一个公开产品。在它的设计里，模型、工具、会话、沙箱，甚至 Agent loop 都可以作为插件装入或卸载。需要新的能力，就装入相应的插件；不再需要时，插件注册的服务、事件和由框架记录的其他影响也会一并撤销。
它底层用的 Cordis，正是《A Programming Paradigm for Spatiotemporal Composability》这篇论文描述的那套框架。论文把动态变化拆成两个很实际的问题：一个组件被移除以后，它留下的副作用能不能撤销；组件之间的依赖发生变化以后，相关部分能否自动重新调整。DeepSeek Harness 的仓库里已经提供一组可选的运行时工具：Agent 可以查看当前运行环境中已经加载的插件和服务，挂载由模型临时写出的插件，也可以把这些临时插件卸载。
这还不等于它已经能可靠地自我演进，DeepSeek Harness 本身也还在开发者预览阶段。但论文里的设想已经有了公开实现。DeepSeek Harness 的架构文档要求，每次发给模型的内容都必须能够从会话日志中重建，插件出了问题可以卸载并撤销它留下的影响，沙箱和权限限制也由系统执行，不靠提示词反复提醒。
Prompt Engineering 主要解决怎样把一次指令写得更好。Loop Engineering 处理的是接下来的问题：第一次做错以后怎样发现和调整，什么时候继续，什么时候停止，遇到什么情况必须把任务交还给人。
Claude Code 负责人 Boris Cherny 在一次访谈中说，他已经不再亲自 prompt Claude，“My job is to write loops”。Prompt 仍然重要，只是它成了循环中的一个部件。固定流程预先规定 Agent 的路线，loop 则允许路线变化，同时守住目标、边界、验证标准和停止条件。固定流程像铺好的铁轨，loop 像会实时改道的导航。
OpenAI 在 Harness Engineering 中描述的也是这个方向：人负责设定意图、设计环境和反馈循环，Agent 负责执行；架构约束被写进测试和静态检查，而不是依赖人逐行提醒。Symphony 则进一步把 issue tracker 作为控制面，Agent 自己运行、测试，处理持续集成报出的问题和代码冲突，最后把结果及审查证据交给人。
DeepSeek Harness 对检查的要求一点也不低。仓库里有单元测试、类型检查、静态检查、快照和端到端测试，主要源码还要求逐文件达到 100% 的测试覆盖率。开发者在本地只需运行与当前改动有关的检查，代码提交以后，再由系统运行更完整的一套。验证没有减少，只是更多由系统完成，人的精力可以留给异常、边界和取舍。
人仍然要判断什么值得做，哪些边界不能突破，什么结果算成功，出现哪些异常时必须停止。资金、权限、数据、合规和关键生产系统，仍然应该由人严格把关。人不必因此检查 Agent 的每一个中间动作。
变化的不只是写代码的方式
如果只把这场变化理解成研发提效，可能仍然低估了它。
Anthropic 在谈 AI 时代的产品管理时，描述了一种和传统产品开发很不一样的节奏：短周期实验，快速制作原型，用 demo 和评测代替一部分长文档；先让内部用户真实使用，再决定哪些方向值得继续放大。
在这样的节奏里，产品判断不会在构建之前一次完成。做出原型、让人实际使用、看到反馈，本身就是思考的一部分。
过去，一个产品想法可能需要先写清楚需求，组织几轮讨论，排进研发计划，几周以后才能看到实物。因为验证成本太高，大家会自然地要求在开始之前获得更多确定性。
现在，产品经理、设计师或工程师可能在一个下午就做出可以交互的版本。错误的方向很快就能被丢掉，有反应的部分继续迭代。文档仍然有用，但不再独自承担证明一个想法正确的责任。
Anthropic 把这套方法讲得比较清楚。DeepSeek Harness 的发布本身也带着这种节奏：先开放开发者预览版，明确告诉使用者项目在快速迭代，未来可能有破坏兼容性的变更。这相当于先划出一个试验区域，愿意接受变化的开发者先用，稳定性要求更高的用户可以继续等。
至于 OpenAI，没有发布一篇完全对应的文章，不过 Codex 的公开更新节奏提供了一些旁证。
我自己经常使用 Codex，有时一天会遇到一两次，甚至两三次更新。写这篇文章时我去看了它的公开仓库：8 月 13 日清晨，相隔两个多小时就发布了两个 Alpha 版本，主分支当天也在持续合入大量 PR。这种可见的节奏和 Anthropic 描述的产品逻辑正好对得上。
这个节奏并不总是平滑。我现在打开 Windows 版 Codex 时，鼠标有时会卡顿几秒，GitHub 上也有人报告过近似问题：启动应用或者切换任务时，鼠标出现明显卡顿。
这会影响体验，但在我的使用中，这类问题还没有严重到阻断核心任务，新能力和修复也在持续进入产品。
截至 2026 年 8 月，Codex 与 ChatGPT Work 合计活跃用户已超过 1500 万。这样规模的产品，用“不重视用户体验”是解释不通的。
它更像是在采用另一种质量观：不等着产品“彻底完成”，只要风险仍然可控，就继续发布和观察，再把发现的问题带回下一轮修复。
“零 Bug 上线”是一种静态质量观
很多企业仍然追求“零 Bug 上线”。如果这个要求针对的是数据错误、安全漏洞、核心功能不可用这类严重问题，它完全合理：这类问题应该尽可能在发布之前解决。不同企业对 P0、P1 的定义并不相同，但这不改变底线：可能造成重大损害的风险，不能拿快速迭代当放松标准的借口。
现实中，一些组织会把严重程度完全不同的问题放进同一套流程。边缘页面的轻微错位、低频操作下的短暂卡顿，和资金计算错误、权限泄露、生产系统不可用，可能要经过相似的审批和等待。每个人都能为自己新增的审批或检查找到理由，因为任何一次发布事故都会被清楚地记录下来。每一道审批，都是一张个人免责声明。
一个 Bug 上线，通常能找到对应版本、团队和责任人。一个有价值的功能晚三个月上线，却很少被登记成一次事故。前者造成的损失集中、可见，后者的成本分散在用户流失、反馈减少和错过的市场窗口里，很难归到某个人头上。
于是每个人都倾向于做对自己最安全的选择。审批和检查不断增加，很少有人需要为产品晚了三个月负责，整个组织却会因此越来越慢。
“为了用户体验”可能是真实理由，但用户体验不只发生在上线那一刻。用户在意产品有没有问题，也在意需要的能力什么时候出现，出了问题多久能够修好，产品能不能持续改善。
零 Bug 通常只能说明发布时没有已知且未处理的问题，不能保证产品进入真实环境以后不会出现新问题。我更愿意把质量理解成一段时间内的连续能力：问题有多严重，影响了多少人，持续了多久，系统能否及时发现，团队能否快速回滚和修复。这更像看一个人的健康，不是体检那天没病就算健康，而是看他平时会不会生病、病了能不能好。
AI-native 研发不是有意带着 Bug 发布，也不是把用户当成测试人员。P0、P1 和不可逆风险仍然要在发布前挡住。对于影响有限、可隔离、可观测、可回滚的问题，可以采用灰度、内部试用、研究预览和快速修复，让问题在可控范围内尽早暴露，在下一轮迭代里修掉。小问题同样有成本，只是还要和延迟发布、错失反馈以及阻碍产品演进的成本放在一起比较。
快速发布必须同时具备发现问题、修复问题和控制影响范围的能力。少了这些条件，快速迭代就只是把测试成本转嫁给用户。
确定性并没有消失，只是研发不再要求所有变化都在上线前购买同样昂贵的确定性：它开始来自清楚的边界、自动验证、真实反馈，以及出事之后的观测和恢复能力。
人最终要负责什么
人不会退出产品研发，反而是要做的判断更难、更关键了。
过去，人花大量时间确认任务有没有按照流程执行。以后，人要更早说清楚我们到底想解决什么问题，哪些结果不可接受，什么证据足以证明方向有效，哪些风险必须由人亲自决定。
产品经理、设计师和工程师之间的边界也会继续变淡。产品经理可以直接做出原型和评测集，工程师会更早参与产品判断，Agent 则承担越来越多从方案到验证的连续执行。
企业真要做这种转变，也不必一上来就碰资金、权限和关键生产系统。可以先划出低风险、可隔离、可回滚的试验区域，把团队反复进行的人工判断逐步转成测试、评测集、日志和审查证据，让 Agent 交付结果时也交付证明。
试验区域跑起来以后，再按风险高低分配人的精力。高风险变化仍然由人严格审核，低风险变化更多依靠自动验证、灰度和快速纠错，人集中处理异常和取舍，不再平均地检查所有步骤。
Agent 产出还不高的时候，多看几遍 diff 也许不会有什么问题。随着它们开始并行工作，人的注意力会更加捉襟见肘。未来团队之间的差异，可能不再是谁能看完更多代码，而是谁能更早判断：哪些事情必须由人决定，哪些判断可以写成边界和验证，哪些低风险变化可以先发生，再由真实反馈推动下一轮。
研发从来无法把每一次变化都变成毫无风险的事件。不可承受的风险要尽早挡住；对那些后果可承受、过程可观测、出错能回滚的变化，就让它更快发生，出了问题及时看见、回滚和修复。
该做的做到本分。本分之外，不再为了看起来稳妥而层层加码。