第 16 章：什么时候一个 Agent 应用开始平台化
本章目标：讲清一个 Agent 应用为什么会从“功能集合”长成“平台”，以及平台化真正发生的标志到底是什么。
本章对应总纲：docs/ebook-outline.md中“第 16 章正文写作提纲（2026-03-31 归档）”。
16.1 为什么很多系统其实还没到“平台”这一步
很多团队一做出几个功能入口，就很喜欢把自己的系统叫成平台：
- 有命令
- 有插件
- 有几个配置项
- 能接几个外部能力
听起来很像平台。
但大多数时候，这还只是一个逐渐变大的应用，不是真正的平台。
因为“平台化”不是功能变多，而是系统开始具备这件事：
别人在不修改核心实现的前提下，也能稳定地往系统里接入新能力。
如果每次扩展都还得回核心代码里打洞、加分支、补特判，那它就还只是一个大应用，不是平台。
16.2 平台化真正发生的分水岭是什么
一个实用的判断标准是：
16.2.1 扩展开始独立于核心迭代
如果新能力可以作为独立单元接入，而不是必须和主系统一起改、一起发，那就开始有平台味了。
16.2.2 接入方式开始标准化
如果系统开始明确规定：
- 扩展应该放哪
- 用什么格式声明
- 暴露什么接口
- 拿到什么上下文
- 拥有什么权限
那它就不再是“随便接”，而是在长稳定扩展面。
16.2.3 核心开始转向治理，而不是亲自实现一切
一旦平台化，核心系统做的事会慢慢变化：
- 不再负责写每个功能
- 而是负责发现扩展
- 管理权限
- 保证生命周期
- 提供运行时约束
- 处理冲突与隔离
这时核心的职责已经从“功能提供者”部分转成了“能力编排者”。
但这里说的“编排”还是平台级的：它关心的是扩展如何被发现、接入、治理和组合；不等于第 18 章要讲的任务运行时编排，不要混成一锅。
16.3 为什么 Agent 系统特别容易走向平台化
Agent 系统比很多普通应用更容易走向平台化，因为它天然就围绕“能力接入”和“能力组合”在生长。
现实里很快就会出现这些需求：
- 加一个新命令
- 加一个新 Hook
- 加一个新 Agent
- 加一个新 Skill
- 接一个新的 MCP 服务
- 给不同场景装不同能力组合
如果这些东西全都回核心里硬编码，系统很快就会烂掉。
所以 Agent 系统一旦做大，往往天然会逼自己长出扩展点。
不是因为平台化更高级，而是因为不用平台化，复杂度就只能全堆进核心。
16.4 平台化不是“能扩展”这么简单，而是要有稳定扩展点
很多系统也能扩展，但方式很脏：
- 改一个 if
- 补一个 case
- 加一个私有入口
- 复制一份旧逻辑再改名
这不叫平台化，这叫扩展债务。
平台化真正重要的是“稳定扩展点”。
所谓稳定，至少意味着：
- 扩展怎么声明是清楚的
- 扩展拿到什么输入是清楚的
- 扩展能做什么、不能做什么是清楚的
- 扩展失败后系统怎么处理是清楚的
- 核心升级时扩展不会随便一起炸
也就是说，平台化的核心不是“留后门”，而是“给接口”。
16.5 一个 Agent 平台通常会长出哪些典型扩展点
16.5.1 入口型扩展点
最常见的是能力入口。
例如：
- 命令
- 子 Agent
- 技能调用入口
- UI 触发入口
它们解决的是“用户或系统从哪里开始一段能力调用”。
16.5.2 生命周期型扩展点
另一类扩展点不是新功能入口，而是挂在系统过程上。
例如：
- 前置检查
- 后置校验
- 停止时收尾
- 子任务结束时处理
这类扩展点的价值在于：允许系统在不改主流程的前提下，把额外约束插进运行时。
16.5.3 能力型扩展点
还有一类是直接给系统增加新能力源。
例如：
- 新工具
- 新资源提供方
- 新 MCP 服务
- 新 Provider 对接
这类扩展点本质上是在扩大系统的行动半径。
16.5.4 策略型扩展点
最后还有一类，控制的是系统如何做，而不是做什么。
例如：
- 审查策略
- 权限策略
- 输出风格
- 风险拦截规则
这类扩展点让平台不仅能扩能力，还能扩治理方式。
16.6 平台化会立刻带来哪些新成本
16.6.1 兼容性成本
一旦扩展点公开，核心系统就不能再随便改接口了。
这意味着：
- 字段名不能说变就变
- 生命周期不能说删就删
- 输入输出契约不能乱动
平台化以后，“Never break userspace” 这条铁律会开始真正压到系统设计上。
16.6.2 治理成本
扩展点越多，系统越得回答：
- 哪些扩展可信
- 哪些扩展可组合
- 哪些扩展会冲突
- 哪些扩展拥有高风险权限
- 哪些扩展只在某些环境允许加载
如果没有治理，平台化只会把复杂度从核心代码转移到整个生态。
16.6.3 质量成本
一旦允许别人接入扩展，你就不能只关心“自己写的能不能跑”，还得关心：
- 扩展写坏了怎么隔离
- 扩展报错怎么降级
- 扩展性能差会不会拖垮主流程
- 扩展是否污染用户体验
平台化之后，系统质量不再只取决于核心实现。
16.7 为什么“扩展自由”常常会把平台做烂
很多平台一开放扩展，就走向一个很蠢的极端：
- 啥都能接
- 啥都能改
- 啥都能覆盖
- 啥都没有硬边界
短期看很自由，长期看基本等于系统失控。
因为扩展一旦没有边界，很快就会出现：
- 互相打架
- 权限失控
- 生命周期冲突
- 用户不知道当前到底是谁在接管行为
所以一个成熟平台真正追求的，不是“开放程度最大化”，而是：
在可治理的前提下，让扩展点足够稳定、足够有用。
16.8 用 Claude Code 看一个现实里的平台化样本
Claude Code 很适合拿来理解这件事，因为它已经明显不是一个只靠核心代码完成所有能力的单体工具了。
从当前仓库结构就能看到平台化的味道已经很重：
.claude/commands/把命令做成独立入口层plugins/下面拆出 hookify、feature-dev、plugin-dev、code-review、security-guidance 等多个独立模块plugins/README.md明确给出统一插件结构：.claude-plugin/、commands/、agents/、skills/、hooks/、.mcp.jsonexamples/settings/提供 lax / strict / bash-sandbox 三档策略样板，说明策略本身也被当成可复用扩展面来管理.github/workflows/deploy-docs.yml把文档构建和部署单独做成 CI/CD 链路，说明连内容系统都已经有独立交付面.vitepress/config.ts又把导航、搜索、侧边栏和内容排除规则单独做成壳层配置，说明内容层和呈现层也在分离
你能从这些结构里看出几个很硬的设计思路：
- 扩展优先走标准目录，而不是回核心里打补丁
- 核心负责定义扩展面和治理规则，扩展负责填充具体能力
- 配置样板和工作流也被当成平台的一部分，而不是边角脚本
- 平台不是把一切混在一起，而是把入口、执行、策略、呈现和交付拆层
这说明它的核心已经不只是“自己提供几个功能”，而是在做更高一层的事：
- 定义扩展点
- 规定接入方式
- 管运行边界
- 管工具权限
- 管生命周期事件
- 管不同模块之间的组合关系
这就是平台化的典型味道。
16.9 什么时候你真的该承认自己在做平台，而不是继续装应用
有几个信号很明显：
- 新能力开始频繁由独立模块接入
- 核心代码越来越像调度层和治理层
- 团队开始关心扩展兼容性而不只是功能开发
- 不同扩展之间开始需要统一生命周期和权限模型
- 你已经没法靠“改主代码”来维持开发速度
一旦这些信号出现，再把系统当普通应用看，只会让架构判断继续失真。
这时承认自己在做平台，不是自我吹捧，而是认清现实。
16.10 平台化不是终点，而是责任升级
最后也得把幻觉打掉。
平台化不是系统毕业了，也不是突然变高级了。
它只是说明：
- 核心开始承担生态责任
- 兼容性开始成为硬约束
- 治理开始和功能同样重要
- 扩展点设计开始决定系统上限
平台化不是奖章，而是负担升级。
如果你没准备好承担这些责任，那最好就别过早开放扩展面。
16.11 本章小结
这一章真正想讲清的是：一个 Agent 应用开始平台化，不是因为功能多了，而是因为系统开始长出稳定扩展点，让新能力能在不修改核心实现的前提下被接入、治理和运行。
你现在应该记住六件事：
- 平台化的分水岭不是功能数量，而是扩展是否独立于核心迭代。
- Agent 系统天然容易走向平台化，因为它本来就围绕能力接入在生长。
- 真正的平台化依赖稳定扩展点，而不是不断给核心打补丁。
- 入口型、生命周期型、能力型、策略型，是四类常见扩展点。
- 平台化会立刻带来兼容性、治理和质量成本。
- 平台化不是更高级，只是系统开始承担生态责任。
下一章我们继续往下走，专门把这些扩展点拆开看：命令、Hook、Agent、Skill、MCP 这些东西为什么不能混着理解，它们各自解决的到底是什么问题。