每个 SaaS 业务都会变成围绕模型的套件（harness），无论是否意识到。狭义上人们将套件关联框架 LangGraph 或代码代理（Codex）、Claude Code、OpenCode，它们为无状态模型 API 包裹工具与状态。广义上套件指环绕无状态大语言模型（LLM）的所有基础设施、接口、上下文和状态，可由子套件组成，软件工厂便是部件为更小套件的套件。

Harness 就是公司

每一家 SaaS 企业都会变成围绕模型的 harness，无论它们是否已经意识到这一点。

狭义上，人们常把 "harness" 等同于 LangGraph 这类框架，或 Codex、Claude Code、OpenCode 这类编码 agent——它们把无状态的模型 API 包裹上足够的工具与状态，让你真的能把活干完。

我这里用 "harness" 是广义的：围绕无状态 LLM 的所有基础设施、界面、上下文和状态。一个 harness 可以由为特定任务调整过的子 harness 组成（负责编排的那个叫 "meta-harness"）。"软件工厂" 就是一种 harness，它的各个部件本身也是更小的 harness——一个写规格、一个写代码、一个做审查——再加一个上层决定什么在什么时候运行。

如果你接受这个更宽的定义（或者把 "harness" 替换成任何你偏好的词），我猜很多软件服务企业会走过这样一条轨迹：

1. 用传统 SaaS 方式销售软件服务。
   1. 没有 harness。
2. 仍然销售软件服务，但工程师与 agent 结对完成工作。产品、销售等其他职能也越来越多地与 agent 结对来提效。
   1. 个人操作 harness。
3. 销售软件服务，但许多核心任务转移到云端运行的后台 agent（一台笔记本跑不了二十个）。工程、产品、销售都来触发这些 agent（也就是写 prompt）并审阅产出。
   1. 个人编排 harness。
4. 销售软件服务，许多核心任务转移到主动式后台 agent，工程、产品、销售的职责转为审阅 agent 的产出，持续审阅变成抽样审阅。越来越多的工作由 agent 主动决定做什么，而不是由人预先设计。
   1. harness 编排个人。

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

• 核心任务由 agent 完成，"产品"如今完全是模型输出，公司提供的是上下文、集成和面向人的审阅界面。
• 软件与组织架构的关系倒转过来：组织图变成一个该把人放在哪里的问题，好让 harness 从他们身上获得最多的品味与判断。人成了 harness 的一部分。
• 公司的领域知识、工具、权限、审阅回路、上下文等等，全都成为业务的 harness。

人们很容易觉得，主要由 AI 制作和审阅的产品天然质量低下，用 harness 而不是用人来构建，会规模化地造出一座垃圾工厂。我认为这种想法假定这样运作的公司是座"熄灯工厂"。

真正的解法是让 harness 去挑选人类输入最有价值的位置。比如：

• 一个产品决策可以由 agent 在客户会议上向销售代表发散提问，再综合出一个产品演示，交给产品负责人审阅。
• 从客户会议中提取出的一条功能建议，被 agent 转化为一个重大架构决策，呈交给一位负责工程品味的把关人。
• 一次 UI 改版在汇总反馈后启动，测试过几个版本后，把最优选项呈交给负责设计品味的把关人。

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

如果你仍然怀疑，这很合理。即便用今天的前沿模型加上精心打造的 harness，要放心让 agent 处理这样的外循环仍然相当困难。我只是觉得，不值得去赌模型最终做不到这件事，尤其当越来越多这类规划与审查工作被拆成带可验证奖励、实验室可以拿来做训练的任务时。

按服务类型不同，公司的差异化往往来自信任、分发、效能和领域上下文这些东西。在主动式后台 agent 的世界里，你构建 harness 的能力——它如何学习、关注什么、如何与人的品味把关人对接、集成哪些系统——会越来越成为维持差异化的方式。

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

harness 会从你乐于外购的内部工具，变成像产品工程团队或 GTM 团队一样绝不能外包的东西。这与前 AI 时代截然不同——那时产出基本上受限于使用软件干活的人。

我认为企业自建的 AI 开发者工具（比如 Ramp、Stripe、DoorDash 等已经出现的那些）正是这件事的开端。

对已经把 AI 吃进去的公司来说，等着 SDLC 工具厂商添加一个集成、支持某种接口或达到某个成本效益水平，会越来越成为它们构建和维护产品的瓶颈。短期内尤其如此，因为第三方工具还无法替企业跑完整个软件工厂——常常是因为技术栈太定制化、治理太严格、关键功能支持太慢，或者成本模型不合意。

我并不指望所有东西都在内部构建和维护。公司应该自己拥有顶层 harness——决定要建什么、审阅返回结果的那一层——再把厂商产品插入具体的工作流。最终会有第三方把企业级的"从规格到测试通过的 PR"做得相当好，到那时公司可以换掉软件回路中的这一段，同时仍然自己掌握写输入规格的 agent 和处理 PR 产出后续步骤的 agent。

如果整个外循环某天都能由第三方 harness 完成（也就是以服务形式用主动式后台 agent 运营整个业务），那我会说，这门生意已经被商品化了。

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

• 在构建侧和销售侧都出现异常大量的自建 harness
• 组织架构和个人角色围绕自己在业务 harness 中的位置被重塑
• 在"护城河"容易被 harness 化的领域，AI 原生初创公司击败既有玩家
• 软件公司使用的所有软件（只要处在或关联核心构建与销售路径）都必须是无头的，以便外层 harness 能够驱动它们

社区对“企业将成为围绕 LLM 的 harness 并瓦解 SaaS 护城河”的论点严重分裂：较多人质疑其成本、非确定性与对人类判断的忽视，认为这无非是既有商业协调模式的重演；少数支持者则认为 harness 内化与软件商品化已不可避免。

认为 AI harness 将自动化决策并消解软件护城河

• 企业中期比拼 harness 优劣，长期软件极度商品化，数据护城河可被模拟取代，平台效应也能被 AI 绕开，初创须抓紧窗口，消费者最终受益（较多人） > 最优秀的 harness 公司将胜出，但长远看大多数现有护城河都会失效（@2001zhaozhao）

认为真实业务依赖人类判断与信任，harness 愿景不现实

• 历史表明成功来自深度理解客户而非产出最多，人类提供“何为好”的判断与信任，agent 无法替代创始人关注，SaaS 末日预言屡次落空（较多人） > 最成功的生意是深度理解客户，而非靠一堆 agent 做无效忙碌（@reticulates）

质疑全盘 LLM 化的成本、确定性与市场接受度

• 全面接入 LLM 过于昂贵且使业务非确定性，直接跑核心流程易引发合规混乱；同时多数企业主不愿自管 agent 复杂性，自研后售卖对象也成疑（较多人） > 把整个业务直接架在 LLM 上恐怕会招来巨大麻烦，且成本过高（@vjvjvjvjghv）

指出该概念并非新生，传统商业与 SaaS 本就是 harness

• 麦当劳、丰田等早已用系统协调人与流程，SaaS 本就是编程语言外的 harness，文章宽泛定义到包含界面无异于描述今日 SaaS（较多人） > 如今所谓的 harness 宽泛到连界面都包含，那不就是今天的 SaaS 吗（@tiffanyh）

认同内部构建 harness 趋势，但组织重塑尚早

• 职场与个人项目中用提示词直接生成产品的现象真实存在，但组织围绕 harness 重构仍可疑，非软件公司全面 headless 是迟早而非现在（较多人） > 我亲见工作场所有人用一次性提示建产品，虽被笑不严肃但确在发生（@jmathai）

担忧员工成为 harness 编排的首批试验品

• 用 harness 编排个体的趋势若到来，普通员工恐先被当作试错对象，引人忧虑（少数人） > 我怕这种东西会先拿可怜员工开刀试验（@asdfman123）

有价值的补充

• 文章称 harness 无状态，但 agentic 任务实际必有状态；未来数月可能出现原生有状态 ML 架构，将状态与记忆管理吸入模型，AI 工程岗位可持续性存疑（@ilaksh）
• 企业本质是对财产、物流、知识等施加的 harness，人类角色是提供判断与信任，这解释了为何信任成为最高溢价（@pizzafeelsright）