当公司变成模型的“挽具”

每一家SaaS公司都会变成围绕模型的挽具，不管他们自己有没有意识到。这是Shrivu Shankar在8月24日给出的判断。他用的词是“harness”——直译过来是“马具”或“挽具”，在AI语境里，它指的是包裹在无状态模型API外面的那一整套基础设施、界面、上下文和状态。

狭义上，人们常把harness和LangGraph这类框架，或者Codex、Claude Code、OpenCode这类编码智能体联系在一起。它们做的事情，是给一个本身不记事的模型套上足够的工具和状态，让它真的能干活。Shrivu把这个概念放大了：harness可以是所有围绕无状态大模型的基础设施、接口、上下文和状态的总和。一个harness可以由经过适配的或任务特定的子harness组成，其中负责编排的那个被称为“元harness”。一个“软件工厂”就是一个harness，它的各个部分都是更小的harness——一个写规格、一个写代码、一个做审核——再加上一个顶层的东西决定什么时候运行什么。

一条演进轨迹

如果你接受这个更宽泛的定义（或者把“harness”替换成你更喜欢的任何说法），Shrivu认为，对许多软件服务公司来说，你会看到这样一条轨迹：

第一步，他们以传统SaaS的方式销售软件服务。

第二步，他们销售软件服务，但工程师开始和智能体结对完成工作。产品、销售等其他职能也越来越多地用智能体提效。个体开始“操作harness”。

第三步，他们销售软件服务，许多核心任务转移到云端运行的后台智能体上——一台笔记本跑不了二十个智能体。工程、产品、销售都变成触发这些智能体的人，也就是写提示词的人，然后审核输出。个体开始“编排harness”。

第四步，他们销售软件服务，更多核心任务交给主动型后台智能体，工程、产品、销售转向审核智能体输出。持续审核变成抽样审核。智能体越来越多地自己决定做什么，而不是由人预先设计工作。这时候，是“harness在编排个体”。

沿着这条轨迹走到底，你实际上已经把公司变成了一个harness。生产软件服务的工作从人转移到了harness身上。核心任务由智能体完成，“产品”完全变成模型输出，公司提供的是上下文、集成能力和面向人的审核界面。

组织架构的逻辑被倒过来了

软件和组织结构的关系发生了反转。组织架构图变成了一个问题：人应该放在哪里，才能让harness从他们身上榨取最多的品味和判断力？人成了harness的一部分。公司的领域知识、工具、权限、审核循环、上下文，全都变成业务harness的组成部分。

有人会担心，主要由AI制作和审核的产品天然低质，用harness而不是用人来构建，会造出一个规模化的“垃圾工厂”。Shrivu认为，这种看法假设了这样运作的公司是无人值守的。真正的解法，是让harness自己挑出人的输入在哪里最重要。他举了几个例子：一个产品决策，可以由智能体向客户会议中的销售代表分发问题，再综合出一个产品演示，交给产品负责人审核；一个从客户会议里捞出来的功能建议，被智能体转化成重大架构决策，呈交给工程侧的品味把关人；一次UI改版在汇总反馈后启动，测试几个变体之后，把最优选项交给设计侧的品味把关人。好的harness在给客户创造最大价值的同时，只把人的注意力——员工的和客户的——花在真正需要的地方。

Shrivu也承认，即便用今天的前沿模型和精心打造的harness，要信任智能体这样处理外层循环仍然相当困难，他们自己就花了很多时间尝试。他只是认为，不值得赌模型最终做不到这件事，尤其是当越来越多这类规划和审核工作被拆成带有可验证奖励的任务、供实验室训练之后。

差异化来自挽具本身

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

harness现在决定了工作要发布必须满足什么条件（对应信任），产品以多快速度、以什么方式落地（对应分发），反馈循环的速度和上下文（对应效能），以及机构知识如何被吸收和维护（对应领域上下文）。

harness从“你乐意买的内部工具”，变成了“你绝不会外包的东西”，就像你不会外包产品工程团队或GTM团队一样。这和AI之前的世界明显不同，那时候产出主要受限于使用软件的人。

Shrivu认为，Ramp、Stripe、DoorDash等公司出现的自研AI开发者工具，就是这件事的开端。对于“AI化”的公司来说，等一个SDLC工具供应商添加集成、支持某个接口、或者达到某个成本效益水平，越来越会卡住他们构建和维护产品的能力。短期内尤其如此，因为第三方工具还无法替企业运行整个软件工厂——技术栈太定制、治理太严格、关键功能支持太慢，或者成本模型不合适。

他不认为所有东西都会自建自维护。公司应该拥有顶层harness——那个决定要构建什么、审核返回结果的外壳——然后把供应商产品插进它，用于特定工作流。