挽具即公司

为什么 SaaS 生意如今是一门 harness 生意

Shrivu Shankar

2026 年 8 月 24 日

每一门 SaaS 生意都会变成套在模型外面的 harness，不管他们自己有没有意识到。

harness 到底是什么？

狭义上，人们常把 “harness” 和 LangGraph 这类框架，或 Codex、Claude Code、OpenCode 这类编码 agent 联系在一起——它们给无状态的模型 API 包上足够的工具和状态，让你真能干成活。我这里用 “harness” 是广义的：围绕无状态 LLM 的一切基础设施、接口、上下文和状态。一个 harness 可以由若干经过适配的、面向具体任务的子 harness 组成（负责编排的那个叫 “meta-harness”）。“软件工厂” 就是一种 harness，它的各个部件本身是更小的 harness——一个写规格，一个写代码，一个做评审——再加上一层决定什么时候跑什么。如果你接受这个更宽的定义（或者把 “harness” 全部替换成你更喜欢的说法），我猜很多软件服务公司会走出这样一条轨迹：

1. 他们卖的是按传统 SaaS 方式做出来的软件服务。没有 harness。

他们卖软件服务，但工程师和 agent 结对来完成工作。产品、销售等越来越多的职能也在和 agent 结对提效。

1. 个人操作 harness。

他们卖软件服务，许多核心任务转移到跑在云端的后台 agent 上（笔记本跑不了二十个）。工程、产品、销售都在触发这些 agent（也就是写 prompt）并审阅输出。

1. 个人编排 harness。

他们卖软件服务，许多核心任务转移到主动的后台 agent 上，工程、产品、销售转向审阅 agent 的输出。全量审阅变成抽样审阅。越来越多的 agent 自己主动决定该做什么，而不是由人预先设计好工作。

1. harness 编排个人。

倒置。在 SaaS 形态里，是人把软件撑起来；在 harness 形态里，模型干活，人的注意力被引导到真正重要的地方。

沿着这条轨迹走下去，你其实已经把公司变成了一个 harness。生产软件服务的工作，已经从人转移到了 harness 上。

• 核心任务由 agent 完成，“产品”完全成了模型输出，公司提供的是上下文、集成，以及面向人的审核界面。
• 软件与组织结构的关系发生了倒置：组织架构图变成了一个问题——人放在哪里，才能让 harness 从他们身上获得最多的品味和判断力。人本身就是 harness 的一部分。
• 公司的领域知识、工具链、权限、审核回路、上下文等等，全都成了业务 harness。

这听起来像个 AI 垃圾工厂。

人们很容易认为，主要由 AI 制作和审核的产品必然质量低下，用 harness 而不是用人来构建，只会大规模产出垃圾。我觉得这种看法默认了这样运作的公司是无人工厂。

真正的解法，是让 harness 自己挑出人的输入在哪里最关键。比如：

• 一个产品决策，可以由 agent 在客户会议上向销售代表分头提问，再把结果综合成一个产品 demo，交给产品负责人审核。
• 客户会议上冒出的一个功能建议，被 agent 转化为一项重大架构决策，提交给工程侧的品味把关人。
• 一次 UI 改版在汇总反馈后启动，测试几个版本之后，把最优方案提交给设计侧的品味把关人。

好的 harness 在为客户创造最大价值的同时，只在必要之处花费人的注意力——员工的，以及客户的。

注意力，是被路由的。harness 决定了人类的输入投向哪里，包括客户的那一份。

如果你仍然怀疑，这很合理。即便有当今的前沿模型和精心打造的 harness，要放心让 agent 这样处理外循环依然相当困难（我们花了大量时间尝试）。我只是觉得，不值得押注模型最终做不到这件事，尤其是当越来越多这类规划与评审工作被拆解成带有可验证奖励、可供实验室训练的任务时。

想进一步了解“品味持有者”型组织可能是什么样子，见 The Transposed Organization。本文相当程度上建立在那一篇提出的想法之上。

如果 harness 负责生产并销售产品，那它就是你的核心能力。

具体取决于服务类型，一家公司的差异化往往来自信任、分发、效能、领域上下文这些东西。在主动式后台 agent 的世界里，你构建 harness 的能力——它如何学习、盯住什么、如何与人类品味持有者对接、集成哪些系统——将越来越成为你维持这种差异化的方式。

harness 如今决定了工作要交付必须满足哪些条件（约等于信任）、产品以多快速度、以何种方式落地（约等于分发）、反馈回路的速度与上下文（约等于效能），以及机构知识如何被吸收和维持（约等于领域上下文）。

harness 从你乐意花钱买的内部工具，变成了一样你绝不会外包的东西——就像你不会外包产品工程团队或 GTM 团队一样。这与前 AI 时代截然不同：那时产出在多大程度上受限于使用软件把事情做成的人。

这已经在发生了。

我认为，自研的 AI 开发者工具（比如 Ramp、Stripe、DoorDash 等 我们看到的那类）就是这件事的开端。

直说这个判断。

对已经把 AI 吃进工作流的公司来说，等一个 SDLC 工具厂商去加集成、支持某个接口、或者把成本降到可接受的水平，正在越来越严重地卡住它们开发和维护产品的能力。短期内尤其如此，尤其是那些还无法替企业跑完整个软件工厂的第三方工具——原因往往是技术栈太定制化、治理限制太严、关键功能的支持太慢，或者成本模型不合心意。

我并不指望所有东西都在内部自建自维护。公司应该掌握顶层 harness——决定做什么、审查返回结果的那一层——再把厂商产品接进来，用于具体工作流。最终会有第三方把企业级的“从规格到经过测试的 pull request”做得相当好，到那时公司可以把软件循环中的这一段换成那个产品，同时仍然保留负责写输入规格、以及处理 pull request 输出后续步骤的 agent。

如果整个外层循环不知怎么都能由第三方 harness 完成（也就是把整个业务当作服务，靠主动式后台 agent 跑起来），那我认为这家公司已经被商品化了。

所以呢？

如果这个心智模型是对的，你应该会看到：

• 内部自建 harness 的数量异常之多，构建侧和销售侧都是如此
• 组织架构和个人角色围绕其在业务 harness 中的位置被重塑
• 在“护城河”容易被 harness 化的领域，AI 原生创业公司打败 incumbent
• 软件公司用到的所有软件（位于核心构建或销售路径之上，或与之绑定的）都需要 headless，这样外层 harness 才能驱动它们