协议即产品（Software as Protocols）

一句话定义

不是做一个功能，是定义一套交互协议。任何 SaaS 都可以 follow 这套设计。功能可被复制，协议一旦成为标准就是护城河。

出处

Linear AIG（Agent Interaction Guidelines）(2026-04-01)。

我们不是”给产品加 AI 功能”，我们是”重新定义软件应该如何对待 Agent 用户”。

协议时代的评价体系

旧时代（GUI 时代）	新时代（协议时代）
界面好看	接口稳定 = 信用
体验流畅	文档清晰 = 美
加载快	响应可预测 = 靠谱
数据多	数据独家 = 地位

协议不在乎界面好不好看；协议需要稳定、可靠、无处不在。一旦成为某个 Agent 工作流里的默认调用，后来者便很难替代你。

三个使用场景

判断”功能 vs 协议”定位：客户产品是在做一个功能还是定义一种协议？协议级产品具备平台扩展性，功能级产品容易被平台吃。
诊断”我们做了 N 个功能”叙事：堆功能 = 旧时代思维；定义可被遵守的协议 = 新时代壁垒。
客户咨询定位升级：把产品从”功能”重新讲成”协议”——找出 N 个可推广的设计模式（如 delegate ≠ assignee、10 秒超时等）。

协议级产品的特征

零成本安装：Agent 接入无摩擦（Linear AIG: Agent 不计费 = 零采用摩擦）
可被任何人 follow：发布的不是 SDK，是 spec
标准即锁定：先定义标准的人就是裁判（与稀缺性反演反面 4 判断品味呼应）
平台级护城河：自己定义标准 → 别人来遵守 → 标准即锁定

反例 / 边界

❌ “我们做了一个 AI 功能” — 功能级
❌ “我们的 SDK 集成方便” — 仍是功能级，只是接口更友好
✅ “我们定义了 Agent 与 SaaS 交互的 6 条原则 + 10 个设计模式” — 协议级
✅ “任何 SaaS 都可以 follow 这套设计” — 协议级

典型案例

✅ Linear AIG — 协议级产品的代表
✅ MCP（Model Context Protocol）— 调用层协议化
❌ Case - Multica - Agent协作项目管理 — 功能级产品，被协议级 Linear AIG 吃功能

相关术语

GUI 界面税 — 协议时代的对立面（界面是给人看的，协议是给 Agent 用的）
平台吃功能 — 协议级产品有能力吃掉功能级产品
Agent-native 壁垒 — 协议成为标准 = 维度 9 中”基础设施成本”的极致版本
NOT Positioning — 协议级产品需要明确”我们不做什么”