Long-form

Harness 即公司:当 SaaS 的生产资料变成一套 Agent 执行框架

DOC
N°420
DATE
Oct 3, 2026
READ
5 min read
TAGS
Agent, 架构思考, SaaS, Harness, 组织变革

如果你最近一周同时刷到过三条新闻——Earendil 发布持久化 Agent 框架 Pi Durable、DeepSeek 把自家的 Agent 工作台 DeepSeek Harness 开源、arXiv 上出现一篇叫 Harness Annealing 的论文——你可能会隐约感觉到一件事在发生。Shrivu Shankar 在八月底写的那篇「The Harness Is the Company」给出了名字:每一家 SaaS 公司,不管意识到没有,都会变成模型周围的一层 harness。

这篇文章把这个判断放到本周的语境里重新检验,结论是:它不仅成立,而且正在从观点变成可观察的事实。

先定义:harness 到底是什么

狭义的 harness 大家都熟悉:LangGraph、Claude Code、OpenCode 这些框架,把一个无状态的模型 API 包上工具、上下文和状态管理,让它能干活。

但 Shankar 的用法更宽:harness 是围绕无状态 LLM 的一切基础设施、接口、上下文与状态。它可以由更小的子 harness 组合而成,顶层的编排者叫 meta-harness。一家「软件工厂」就是一个 meta-harness——一个负责写规格、一个负责写代码、一个负责审查,最上面还有东西决定什么先跑。

这个定义的关键推论是:harness 不是开发工具,harness 是生产资料。

四级演化:从用到被编排

Shankar 给出的路径值得逐级对照自己的团队:

第一级:没有 harness。 传统 SaaS,人写软件,卖软件服务。

第二级:个人操作 harness。 工程师、产品、销售开始和 Agent 搭档干活,产出仍是人的,效率提升了。

第三级:个人编排 harness。 核心任务迁到云端后台 Agent——笔记本跑不动二十个并发 Agent。人们的工作从「做」变成「触发」(写提示词)和「审阅」(看产出)。

第四级:harness 编排个人。 后台 Agent 变成主动式,人的审阅从逐条变成抽样,Agent 自己决定做什么。到这一步,公司实质上已经变成了一个 harness:产品完全是模型输出,公司提供的是上下文、集成和人类审阅界面。

多数技术公司现在停在第二、三级之间,但设备商、支付公司这些「软件服务密集型」行业的领先者已经在向第四级迁移。

本周的三重佐证

判断一个抽象趋势是否成真,最好的办法是看基础设施是否在跟进。本周恰好凑齐了三层:

持久化层:Pi Durable 把「长时运行、崩溃恢复、多对话并发」做成了约一万五千行 TypeScript 的开源框架。它的检查点设计——每一步任务先存检查点、崩溃后从未完成处续跑、提交恰好一次——解决的是第四级演化的硬前提:harness 必须比进程活得久,否则「后台 Agent 主动干活」就是一句空话。

产品层:DeepSeek Harness 开源,把「一切皆插件」的执行框架、Creator Mode 对话式建插件、定时任务与执行轨迹排查打包成可用产品。注意它的定位:不是编码工具,是覆盖办公、数据、编码、研究的通用工作台。大厂开始把 harness 当独立产品线经营,说明这一层的商业价值已被官方确认。

模型层:arXiv 新论文 Harness Annealing 研究的问题恰好是反面——如何让模型学会在更少的外部控制下行动。加上同批次的 AutoCompact(把上下文压缩决策学进策略),研究者正在把 harness 里的关键决策逐个内化到模型权重里。

三层同时推进,说明 harness 不是某个产品类目的营销词,而是一个正在成型的技术栈分层。

组织反转:人成为 harness 的组件

这是 Shankar 文章里最尖锐也最容易被误读的部分。他说:组织图与软件的关系反转了——过去组织围绕人设计,软件是产出;harness 化之后,组织图变成一个问题:把人放在哪里,才能让 harness 从他们身上获得最多的品味和判断。

这不是「人被替代」的叙事,而是「人的位置由系统的信息流决定」。产品负责人不再逐个做决定,而是在 Agent 汇总了二十场客户访谈后审阅综合结论;架构品味持有者不再读代码,而是在 Agent 提出的三个方案里做选择。人类判断成了稀缺资源,harness 的职责是把它花在刀刃上。

对「AI 粗制滥造工厂」的担忧,答案也在这里:好的 harness 不是熄灯工厂,而是品味分配器。哪怕今天的前沿模型还做不好外循环,把规划与审查拆成带可验证奖励的任务,正是各家实验室正在训练的方向。

选型与自建的分界线

对要落地这件事的团队,Shankar 给的分界线很实用:

  • 自建顶层 harness——决定做什么、审查产出、编排全流程的部分。这是新的核心竞争力,等同于前 AI 时代的产品工程组织,不该外包;
  • 标准环节买现成——当某个第三方把「规格到已测试的 PR」这类可验证任务做得足够好,就整体替换掉,但要保留写输入规格和处理产出的部分;
  • 所有软件必须 headless——核心链路上的一切工具都要能被外层 harness 以 API 方式驱动,界面成为人类审阅专用。

判断标准也很残酷:如果一家公司的全部外循环都能被第三方 harness 接管,那这门生意已经被商品化了。

写在最后

把本周的三件事连起来读,可以看到一条清晰的曲线:harness 的能力边界由框架决定(Pi Durable)、由生态决定(DeepSeek Harness)、由模型内化的程度决定(Harness Annealing)。三条曲线在 2026 年 10 月这个时点交汇,而大多数企业还停在第二级。

窗口期就在这里:当 harness 化的工具链变得人人可得之前,先把组织往第三、四级迁移的公司,会积累一层别人难以复制的资产——不是模型,不是代码,而是被 harness 结构化过的领域知识和人类品味的接线方式。这才是「harness 即公司」的真正含义。

Frequently asked questions

这里说的 harness 具体指什么?
广义的 harness 指围绕无状态模型的一切基础设施:接口、上下文管理、状态存储、权限、工具集成和人类审阅流程。狭义用法才是 LangGraph 或 Claude Code 这类框架。一个「软件工厂」本身是 meta-harness,由负责写规格、写代码、做审查的多个子 harness 组合而成。
harness 化会导致 AI 粗制滥造工厂吗?
不会必然。关键设计是让 harness 把人类注意力投放在价值最大的位置:产品决策可以由 Agent 汇总客户访谈后交给产品负责人审阅,架构决策呈现给工程品味持有者把关。好的 harness 不是熄灯工厂,而是一台「人类品味分配器」,把有限的判断力花在刀刃上。
为什么说组织结构会被反转?
传统公司围绕人来设计流程,软件是人的产出。harness 化之后产出主要来自 Agent,组织图反过来变成一个问题:把人放在哪里,才能让 harness 最大化地吸收他们的品味与判断。人类从执行者变成 harness 的一个组件,位置和职责由系统的信息流向决定。
企业应该自建 harness 还是买现成的?
合理的分界线是:自建顶层 harness——决定做什么、审查产出、编排流程的部分;把成熟的标准环节外包给厂商,比如从规格到已测试的 Pull Request 这类可验证任务。当某个环节的第三方产品足够好时可以整体替换,但写输入规格和处理产出的部分始终自持。
开发者个人应该怎么应对这个趋势?
职业安全感的来源正在从「会写代码」转向「会设计 harness」:定义清晰的验收标准、设计人类审阅的介入点、把领域知识编码成 Agent 可用的上下文。此外理解底层机制越来越重要——本周的 AutoCompact 论文和 Pi Durable 的检查点设计都说明,harness 的细节决定 Agent 的实际上限。
// next.txt ›

Some outbound links in this post are affiliate links — see disclosure.