缰绳即公司
为什么 SaaS 业务如今已成为一种缰绳业务。
每一家 SaaS 业务最终都会成为一个围绕模型的 harness，无论它们是否已经意识到这一点。
harness 到底是什么？
狭义上，人们常将“harness”与 LangGraph 这类框架，或 Codex、Claude Code、OpenCode 这类编码代理联系起来——它们在无状态模型 API 外包裹了足够的工具和状态，让你真正能把工作完成。
我在这里广义地使用“harness”一词，指围绕无状态 LLM 的所有基础设施、接口、上下文和状态。一个 harness 可以由经过适配的或任务专用的子 harness 组成（其中负责编排的被称为“元 harness”）。“软件工厂”就是一个由更小的 harness 组成的 harness——一个写规格说明，一个写代码，一个做审查——外加顶层的某个东西决定何时运行什么。
如果你接受这个更广的定义（或者把所有“harness”替换成你更喜欢的说法），我猜对于许多软件服务企业，你会看到这样的轨迹：
他们以传统 SaaS 方式销售软件服务。
没有 harness。
他们销售软件服务，但工程师与代理结对完成工作。产品和销售等其他职能也越来越多地与代理结对以提升生产力。
个人操作 harness。
他们销售软件服务，许多核心任务转移到在云端运行的后台代理（一台笔记本跑不了二十个）。工程、产品和销售都触发这些代理（即编写提示词）并审查输出。
个人编排 harness。
他们销售软件服务，许多核心任务转移到主动式后台代理，工程、产品和销售则转向审查代理的输出。持续审查转为抽样审查。代理越来越多地主动决定做什么，而不是由人事先设计工作。
harness 编排个人。
沿着这条轨迹发展下去，你实际上已经把公司变成了一个 harness。生产软件服务的工作已经从人转移到了 harness。
核心任务由代理完成，“产品”现在完全是模型的输出，而公司提供上下文、集成和面向人的审查界面。
软件与组织结构的关系发生了反转：组织架构图变成了一个关于把人放在哪里的问题，以便 harness 从他们身上获得最多的品味和判断力。人是 harness 的一部分。
公司的领域知识、工具、权限、审查循环、上下文等等，全都变成了业务 harness。
感谢阅读 Shrivu 的 Substack！免费订阅以接收新文章并支持我的工作。
这听起来像个 AI 粗制滥造工厂。
人们很容易认为，主要由 AI 打造和审查的产品本质上质量低下，通过 harness 而非通过人来构建会大规模产出粗制滥造的工厂。我认为这种看法假设这样运营的公司是 无人值守的。
核心的缓解措施是让 harness 自己挑选人类输入最重要的地方。例如：
一个产品决策可以来自代理向客户会议中的销售代表发散提问，然后综合出一个产品演示供产品负责人审查
从客户会议中提取的功能建议被代理转化为一个重大的架构决策，提交给有工程品味的决策者。
在汇总反馈后，UI 重新设计启动，测试了几个变体后，最佳选项被提交给设计品味决策者。
一个好的框架（harness）在分配人力注意力——员工的和客户的——时，只在必要的地方投入，从而最大化客户价值。
如果你仍然持怀疑态度，那很正常。即使有了当今的前沿模型和精心打造的框架，要信任智能体像这样处理外循环仍然相当困难（我们花了很多时间尝试）。我只是认为，赌模型最终做不到这一点并不值得，尤其是当越来越多的规划与审查工作被拆解为具有实验室可以训练的可验证奖励的任务时。
要深入了解由“品味决策者”组成的组织可能是什么样子，请参阅《转置型组织》。本文在很大程度上建立在那篇文章所阐述的思想之上。
如果框架负责生产和销售产品，那它就是你的核心竞争力。
根据服务类型的不同，公司的差异化往往来自信任、分发、效能和领域上下文等因素。在主动式后台智能体的世界里，你构建框架的能力——它如何学习、监控什么、如何与人类品味决策者交互、与哪些系统集成——将越来越成为你维持这种差异化的方式。
框架现在决定了工作交付必须满足什么条件（~信任）、产品以多快的速度以及如何落地（~分发）、反馈循环的速度和上下文（~效能），以及机构知识如何被吸收和维护（~领域上下文）。
框架从你乐于购买的内部工具，变成了你不会外包的东西，就像你不会外包你的产品工程团队或 GTM 团队一样。这与前 AI 世界截然不同，那时的产出主要受限于使用软件完成工作的人类。
这已经开始发生了。
我认为内部 AI 开发者工具（比如我们从Ramp、Stripe、DoorDash 等看到的那些）是这一趋势的开端。
对于 AI 化的公司来说，等待一个SDLC工具供应商添加集成、支持某种接口或达到一定的成本效益，越来越成为它们构建和维护产品的瓶颈。短期内，对于那些还不能为其运行整个企业软件工厂的第三方工具尤其如此（通常是因为技术栈过于定制、治理过于严格、关键功能支持太慢，或出于偏好的成本模式）。
我不期望所有东西都在内部构建和维护。相反，公司应该拥有顶层框架——即决定构建什么并审查返回内容的框架——并将供应商产品接入其中以完成特定工作流。最终，某个第三方会非常擅长企业级的“从规格说明到经过测试的拉取请求”，届时公司可以用该产品替换软件循环中的这一部分，同时仍然维护编写输入规格说明并处理拉取请求输出后续步骤的智能体。
如果整个外循环都能由第三方框架完成（即通过主动式后台智能体即服务来运营业务），那么我认为这项业务已经被商品化了。
那又怎样？
如果这是正确的心智模型，你应该会看到：
构建侧和销售侧都出现了异常大量的内部工具链建设
组织结构和个人角色正围绕其在业务工具链中的位置被重塑
AI 原生初创公司在“护城河”容易被工具链化的领域击败了老牌企业
软件公司使用的所有软件（位于核心构建或销售路径上，或与之相连）都需要是无头的，以便外层工具链能够运行它
感谢阅读 Shrivu 的 Substack！免费订阅以接收新文章并支持我的工作。