平台吃功能

一句话定义

Agent 友好将成为 SaaS 的 table stakes，就像 2015 年的移动端适配。独立做 Agent 协作中枢的产品会被平台原生实现吃掉。

出处

Linear AIG (2026-04-01) 同日发布即覆盖 Case - Multica - Agent协作项目管理 90% 核心功能 → 写入 AI产品分析框架 维度 6。

核心机制

独立 Agent 协调层产品（Multica）
        ↓
被平台级玩家（Linear）原生实现 Agent 交互
        ↓
平台 vs 独立产品：谁有更多用户？谁有更长上下文？谁有更多数据？
        ↓
独立产品 90% 功能被覆盖 → 窗口关闭

推论

• 独立的 Agent 协调层产品被挤压——各平台会原生实现 Agent 交互
• Agent 基础设施层反而受益——更多平台接入 Agent = 更多底层需求（身份 / 支付 / 通信）
• 垂直领域 + Agent 集成的产品 = 仍有空间（平台不会做所有垂类）

三个使用场景

1. 快速判断产品风险：这个产品做的事，现有平台加一个 feature 就能覆盖吗？能 → 平台吃功能威胁；不能 → 有独立空间。
2. 诊断”Agent 协作工具”赛道：通用 Agent 协作工具几乎都会被吃；垂直领域 Agent + 业务深度的产品有机会。
3. 客户咨询窗口期评估：跨平台 Agent 协作产品 → 窗口期 6-12 个月；垂直 Agent 应用 → 窗口期 12-24 个月+。

检验问题

• 这个产品做的事，Linear / Slack / Notion / GitHub 加一个 feature 就能覆盖吗？
• 现有平台是否有动机和能力做这件事？
• 占优策略分析：平台不做的成本是多少？

反例 / 边界

• ❌ “Agent 协作中枢” — 99% 会被平台吃
• ❌ “通用 Agent 工作流编排” — 平台天然要做
• ✅ 垂直领域 Agent（如 Lucius 做对外触点 context 层）— 平台不会专门做
• ✅ Agent 基础设施层（身份 / 支付 / 通信）— 平台多 = 需求多

典型案例

• ❌ Case - Multica - Agent协作项目管理 — 被 Linear AIG 吃功能的活案例
• ✅ Case - agentcard.sh - Agent支付基础设施 — Agent 基础设施层，受益方
• ✅ Case - Lucius - 组织context层 — 垂直对外触点，避开平台

相关术语

• 协议即产品 — 平台吃功能的载体（Linear AIG 是协议，所以才能吃 Multica 功能）
• NOT Positioning — 没有 NOT 的产品最容易被平台吃
• 同团队范式跃迁 — 被平台吃后的范式跃迁活样本
• 水平与垂直陷阱 — 水平产品最容易被平台吃