套壳框架即公司

# Harness 就是公司本身 来源：https://blog.sshh.io/p/the-harness-is-the-company 每一家 SaaS 公司最终都会变成围绕模型的 harness——无论它们自己是否已经意识到这一点。 从狭义上说，人们常把 "harness" 和 LangGraph 之类的框架，或 Codex、Claude Code、OpenCode 这类编码 agent 联系起来——这些工具把无状态的模型 API 包裹在足够的工具和状态之中，让你真正能把事情做成。 我在这里使用的 "harness" 是广义的，指围绕无状态 LLM 的所有基础设施、接口、上下文和状态。一个 harness 可以由多个经过适配或面向特定任务的子 harness 组成（其中负责编排的那个被称为"元 harness"）。所谓"软件工厂"，就是一个由更小的 harness 组成的 harness——一个负责写规格说明，一个负责写代码，一个负责审查——再加上一层机制来决定什么在什么时机运行。 如果你接受这个广义定义（或者把所有 "harness" 换成你更喜欢的任何说法），我猜测你会在许多软件服务类公司身上看到这样的轨迹： 1. 他们以传统 SaaS 方式销售软件服务。1. **没有 harness。** 2. 他们销售软件服务，但工程师与 agent 配对来完成工作。越来越多的职能部门——比如产品和销售——也与 agent 配对以提升效率。1. **个人在操作 harness。** 3. 他们销售软件服务，许多核心任务转移到云端后台运行的 agent 上（一台笔记本跑不动二十个）。工程、产品和销售都在触发这些 agent（即编写提示词）并审查输出。1. **个人在编排 harness。** 4. 他们销售软件服务，许多核心任务转移到主动式的后台 agent 上，工程、产品和销售的工作则转向审查 agent 的输出。持续性的审查转变为抽样审查。越来越多的 agent 会主动决定做什么，而不是由人类预先设计工作内容。1. **harness 在编排个人。** [](https://substackcdn.com/image/fetch/$s_!DMig!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd8cf3fdf-c311-47d0-b42d-f75864c4dd68_1620x897.png) **沿着这条轨迹走下去，你实际上是把公司变成了一套 harness。生产软件服务的工作已经从人转移到了 harness 上。** - 核心任务由 agent 完成，而"产品"如今完全是模型的输出，公司负责提供上下文、集成和面向人类的审查接口。 - 软件与组织结构之间的关系发生了反转——组织架构图变成了一个关于"把人放在哪里才能让 harness 从他们身上榨取最多的品味和判断力"的问题。人成了 harness 的一部分。 - 公司的领域知识、工具、权限、审查流程、上下文等等，全都构成了业务的 harness。 人们很容易认为，主要由 AI 打造和审查的产品天生质量低下，通过 harness 而不是通过人来构建，会在规模上制造出批量生产的垃圾（slop）。我认为这种假设的前提是，按这种方式运营的公司是"无人工厂"（lights-out，参见 [Lights_out_(manufacturing)](https://en.wikipedia.org/wiki/Lights_out_(manufacturing))）。 核心的缓解手段其实是让 harness 自己来判断人类输入在哪些环节最重要。例如： - 一个产品决策可以让 agent 在客户会议中把问题分发给多位销售代表，然后综合生成一个产品演示给产品负责人审查 - 从客户会议中提取出的功能建议，由 agent 整理成一个重大的架构决策，呈现给掌握工程品味的人（taste-holder）。 - 一个 UI 重设计在汇总反馈后启动，测试几个方案后，把最优选项呈现给掌握设计品味的人。 好的 harness 会在为顾客创造最大价值的同时，只在真正需要的地方花费人类注意力——无论是员工的还是客户的。 [](https://substackcdn.com/image/fetch/$s_!tPqs!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fcb6e7dab-cf7d-4625-9a34-22e2804b4ae_1604x897.png) 如果你仍然持怀疑态度，那很合理。即便以今天的前沿模型和一套精心构建的 harness 来说，要信任 agent 处理这种*外循环*仍然相当困难（我们在 [Nora——我们的第一位 agent 员工](https://builders.abnormal.ai/p/nora-our-first-agent-employee) 这件事上花了大量时间尝试）。我只是觉得，把赌注押在"模型最终做不到这些"上并不值得——尤其是随着越来越多这类规划与审查工作被拆解成具有可验证奖励（verifiable rewards）的任务、可以供实验室训练时（参见 [RLVR](https://rlvrbook.com/chapters/01-introduction.html#what-rlvr-is)）。 *想进一步探讨一个由"品味持有者（taste-holder）"组成的组织可能是什么样子，可以参见[《转置的组织》](https://blog.sshh.io/p/the-transposed-organization)。本文的许多思路都建立在那篇文章的基础上。* 根据不同服务类型，一家公司的差异化往往来源于信任、分发、效果和领域上下文之类的东西。在一个由主动式后台 agent 主导的世界里，你构建 harness 的能力——它如何学习、观察什么、如何与人类品味持有者交互、与哪些系统集成——将越来越成为你维持这种差异化的方式。 harness 现在决定了什么必须成立才能让工作交付（≈信任），产品落地的速度和方式（≈分发），反馈循环的速度和上下文（≈效果），以及制度化知识如何被吸收和维护（≈领域上下文）。 Harness 会从你乐于购买的内部工具，变成一件你绝不会外包出去的东西——就像你不会外包你的产品工程团队或 GTM 团队一样。这与 AI 出现之前的世界有着本质区别，那时的产出能力主要受限于使用软件完成工作的那些人。 我认为像 [Ramp、Stripe、DoorDash 等公司已经实践的那种自研 AI 开发工具](https://background-agents.com/)，正是这一切的开端。 [](https://substackcdn.com/image/fetch/$s_!rBvF!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F83849b6a-e988-4458-b072-788a781d43f9_889x324.png) 对于 AI 深度拥抱型的公司来说，等待某个 [SDLC](https://en.wikipedia.org/wiki/Systems_development_life_cycle) 工具供应商添加集成、支持某种接口或达到某个成本效益水平，越来越会成为它们构建和维护产品的瓶颈。短期来看尤其如此——第三方工具往往还无法为一家企业运行整个软件工厂（通常因为技术栈过于定制化、治理过于严格、关键功能支持太慢，或者是因为特定的成本模式偏好）。 我并不预期*所有*东西都会自建自维护。相反，公司应该拥有顶层 harness——也就是那个决定构建什么、审查产出结果的 harness——然后把供应商产品接入其中来处理特定的工作流。最终会有第三方把企业级的"规格说明到已测试的 PR"这套流程做到相当成熟的程度，到那时公司就可以用那个产品替换掉软件循环中的那一部分，同时仍然保留那些编写输入规格、并处理 PR 输出后续步骤的 agent（或 agent 群体）。 如果整个外循环真的都能由第三方 harness 完成（即通过一项服务，用主动式后台 agent 运营整个业务），那么我会论证，这项业务已经被商品化了。 如果这是正确的心智模型，你应该会看到： - 在构建侧和销售侧都出现不同寻常的自研 harness 的投入 - 组织结构和个人角色围绕它们在业务 harness 中的位置被重新塑造 - AI 原生初创公司在那些"护城河"可以被轻易 harness 化的领域击败既有巨头 - 软件公司使用的所有软件（与核心构建或销售路径相关联的）都必须是"无头"（headless）的，以便外层 harness 能够驱动它们运行 #### 本文讨论 ### 还想看更多吗？