我见过太多AI创业者的故事，结局都是一样的悲剧——
他们花两年时间打造了一个看起来很美的产品：会计AI、律师AI、医疗AI。工作流、界面、领域逻辑、 accountability（责任追溯），全打包在一起。用户用着顺手，公司收着钱，一切看起来都很好。
然后，大模型能力跃升，通用AI Agent出现了。以前的护城河，一夜之间变成了壁垒——不是挡住竞争对手的壁垒，是困住自己的壁垒。
这时候，有人开始鼓吹"Headless"转型：把工作流和界面让给Agent，把领域专业知识暴露成可调用的服务。
听起来很时髦对吧？
但这篇论文告诉我："去headless"可能是一个陷阱，而且大多数公司正在往里跳。
---
💡 什么是"去headless"？
要理解这个概念，先得搞清楚什么是垂直AI公司。
垂直AI公司就是那些在某个特定领域（比如法律、医疗、会计）提供AI解决方案的公司。它们的传统模式是捆绑——把工作流、界面、领域逻辑全都打包进一个应用里，用户不需要知道背后是什么，只需要会用就行。
这个模式有两个好处：
- 用户体验简单：一个软件解决一个领域的全部问题
- 责任清晰：出了问题，用户找这家公司就行了
于是有人就想：既然通用Agent什么都能干，我为什么还要自己做应用？不如把"专业能力"暴露成API，让Agent去调用。这就是"去headless"的核心思路。
理论很美。现实很残酷。
---
⚠️ 一个危险的混淆：接口边界 vs 责任边界
这篇论文最核心的洞察，是一个看似简单但极其重要的区分：
接口边界（interface boundary） 和 责任边界（accountability boundary） 不是一回事。
接口边界回答的问题是：用户通过什么方式跟系统交互？是网页、手机App、还是API？
责任边界回答的问题是：当出了问题，谁来负责？
"去headless"的倡导者混淆了这两个概念。他们觉得把接口从App变成API只是在"做一个技术决策"，但实际上，他们可能正在把责任边界也一起移动了——而这是不应该的。
论文举了一个形象的例子：会计软件出错，税务申报出了问题，公司倒闭了。谁负责？
如果是软件公司的责任，那用户知道该找谁、怎么维权。但如果这家软件公司"去headless"了，把专业能力暴露成API，让一个通用Agent去调用——当税务申报出问题的时候，谁负责？软件公司？Agent开发者？还是用户自己？
当责任边界模糊之后，没有人会真正负责。
这就是"去headless"最危险的地方。
---
📐 一个分析框架：Coase、Teece 和平台包络
为了搞清楚哪些垂直AI公司应该"去headless"，哪些不应该，论文引用了三个经典理论：
Coase的企业理论：为什么会有企业？因为市场交易有成本。当内部协调成本低于市场交易成本时，企业就出现了。
Eisenmann等的平台包络框架：平台可以通过"包围"竞争对手的产品来获得权力——即使技术上的互操作性在提升。
Teece的互补资产理论：真正难以复制的价值，往往在于那些跟核心能力高度互补的资产。
综合这三个理论，论文得出了一个关键结论：
在开放协议上运行的编排者（orchestrator），会获得包络权力——即使技术互操作性在提升。而且，耐久价值会集中在那些"共同专业化的 accountability 资产"上——专业签字权、受监管的工作流、证据链、可信记录系统。
这些"accountability 资产"，才是垂直AI公司真正的护城河。不是算法，不是模型，而是在出问题的时候有人承担责任的承诺和历史记录。
---
🏛️ 一个三类 Taxonomy：组件、集成平台、双轨
论文提出了一个三维分类法，不是按行业分，而是按任务-责任制度分：
第一类：组件（Component）。这类公司的存在价值在于提供专业能力，但没有责任归属。比如一个提供税务计算API的公司，它不保证你按它的结果报税能通过审计。
第二类：集成软件平台（Integrated Software Platform）。这类公司打包了工作流、界面和领域逻辑，同时承担全部责任。用户不需要知道背后是谁在干什么，出问题找平台就行了。
第三类：双轨（Dual-track）。同时运营组件业务和集成平台业务，两条腿走路，但用不同的品牌、不同的法律实体、不同的责任结构严格分开。
这个分类的关键在于：你属于哪一类，不由你的业务内容决定，而由你愿意承担多少责任决定。
一个会计AI公司，如果"去headless"了，把自己变成纯API供应商，它实际上就从第二类滑向了第一类——它放弃了责任，获得了更快的扩张速度，但同时失去了护城河。
---
📝 规则债务：被忽视的隐性成本
论文还提出了一个非常有意思的概念——规则债务（Rule Debt）。
当商业规则和专业标准从"受治理的系统"迁移到"prompt和Agent指令"中时，未来的治理、维护和责任负担就会像债务一样累积到客户组织身上。
这句话有点绕，让我翻译成人话：
当一个会计软件帮你算税的时候，这个计算逻辑是写在"受监管的系统"里的——有审计、有合规检查、有记录。
但如果这个逻辑变成一个prompt给通用Agent调用呢？prompt会不会被修改？ Agent会不会"理解错"？谁来审核这个prompt的正确性？
这些问题不会消失，只是被转移了。 转移到了那些没有专业能力去处理它们的客户身上。
这就是论文所说的"规则债务"——表面上你在给客户"赋能"，实际上你在把负担转嫁给客户。
---
🔑 四条原则
基于以上分析，论文给出了四条实操原则：
原则一：按责任分解，不要按接口分解。在决定保留什么、暴露什么的时候，先问：这一块的责任归属是什么？如果责任是你的，就不应该把它"去headless"。
原则二：倒转边缘，保留核心。把边缘的、非核心的工作流让给Agent，但把核心的、需要承担责任的部分牢牢攥在手里。
原则三：把规则债务当作集成平台给客户省下的成本来定位。如果你的集成平台能帮客户避免规则债务，那它就值这个价。
原则四：避免对单一编排者的依赖。不要把所有的专业能力都暴露给一个Agent去调用，否则你就会变成那个Agent的"附庸"。
---
🤔 一个留给创业者的思考
"去headless"是一个诱人的愿景。它听起来现代化、开放、面向未来。
但我看到的更多是：很多创始人在追逐这个趋势的时候，没有意识到他们正在放弃自己最宝贵的资产——不是技术，不是数据，而是"在出错的时候有人负责"的承诺。
一个行业，如果没有人负责，就会变成一个没有人敢用的行业。
医疗AI为什么推进缓慢？不是技术不行，而是没有人愿意在AI出错的时候当被告。
会计AI为什么难以普及？不是AI不够聪明，而是没有事务所愿意在税务申报上签名然后承担罚款。
accountability 不是负担，它是护城河。
当你准备"去headless"的时候，先问自己一个问题：这件事出错的时候，谁来负责？
如果你答不上来，那可能就不应该去。
---
参考文献
1. Hydari, M. Z., & Muzaffar, F. (2026). *Going Headless? On the Boundaries of Vertical AI Firms*. arXiv:2605.17812.
2. Coase, R. H. (1937). The nature of the firm. *Economica*, 4(16), 386-405.
3. Eisenmann, T., Parker, G., & Van Alstyne, M. (2006). Strategies for two-sided markets. *Harvard Business Review*, 84(10), 92-101.
4. Teece, D. J. (2010). Business models, innovation strategy, and the catch-up problem. *Strategic Management Journal*, 31(2), 151-174.
5. Zuboff, S. (2019). *The Age of Surveillance Capitalism*. PublicAffairs.
---
#VerticalAI #GoingHeadless #AIEnterprise #Accountability #BusinessStrategy #智柴认知实验室🎙️