很多 AI agent 平台做到一定规模之后，会出现一种很反直觉的低效：平台其实已经有不少成熟能力，但业务团队、交付团队，甚至内部支持团队仍然会反复问同样的问题。这个流程能不能自动化？某个连接器到底是不是正式支持？哪类任务需要人工 review？某个模板是不是只给特定租户开过，还是已经算正式产品能力？当这些信息没有被稳定地放进一个可发现的系统对象里，平台能力越多，组织摩擦反而越大。
表面上看，这像是文档不全。真正的问题更深：平台没有把“能力”当成产品对象管理。于是能力信息散落在演示稿、群消息、支持工单、客户成功同学的经验、以及几个资深工程师脑子里。短期里大家还能靠熟人网络把事情推进，规模一上来，业务会把“平台其实已经支持”感知成“平台说不清自己到底支持什么”。
所以 capability catalog 的价值，不是给平台多做一层展示页，而是让每一项能力都带着明确的适用场景、风险边界、责任人和接入路径。没有 discoverability，平台增长到后面，最昂贵的不是研发成本，而是每次都从头解释一次“这东西到底能不能用”。
建议配合 AI agent Use-Case Intake 与 Automation Review Board、AI agent Delegated Admin 与 Scoped Operations、AI agent Workflow Ownership Registry 与 Escalation Routing 和 AI agent Capability Deprecation 与 Sunset Migration 一起看。
Feature 列表、能力目录和接入路径，不是同一件事
| 对象 | 它回答什么问题 | 缺了之后会发生什么 |
|---|---|---|
| Feature 列表 | 平台大概有什么功能 | 看起来丰富，但业务仍不知道能不能真用 |
| Capability Catalog | 某项能力适用于什么场景、有哪些边界 | 团队反复误用或重复造轮子 |
| 接入路径 | 想用这项能力要满足什么条件、找谁、走什么流程 | 平台永远只能靠人工协调推进 |
很多团队把产品菜单、发布日志或者销售材料当作能力目录，这就是问题的起点。因为业务团队真正关心的，不是“你们平台有 OCR、有审批、有连接器”，而是这些能力在当前租户、当前流程、当前风险等级下到底是否可用，以及一旦不可用该走哪条替代路径。
一个可用的 capability catalog，至少要把“能做什么”和“不能怎么做”同时写清
真正有用的 catalog，不应该只有能力名和简短介绍，还应该带着最少但关键的几类元数据：
- 适用场景：它适合哪类用例，不适合哪类高例外或高不可逆动作
- 风险等级：是否需要人工 review、是否受地区、合规或权限约束
- 依赖条件：是否需要特定连接器、数据结构、模板包或管理员权限
- 责任人：能力 owner 是谁，支持升级链路怎么走
- 生命周期状态：是 GA、受限可用、deprecated，还是仅限试点
只有把这些信息绑定在一起，catalog 才不只是“能力墙”，而是一个真正能帮助业务做判断的产品对象。否则平台即使把功能全部列出来，用户读完还是不知道自己到底该不该用。
Discoverability 的关键，不是搜索框，而是能力语义和组织语义对得上
很多目录失败，不是因为没有 UI，而是因为平台用自己的技术语言在描述能力，业务却是按工作流和结果来找能力。平台写“异步回调收敛”“策略豁免登记”“运行状态语义”，业务问的却是“供应商审批能不能先做半自动”“客服升级流能不能保留人工兜底”“月底批处理能不能不影响日常任务”。
这意味着 discoverability 不能只按技术模块组织，还要按业务问题组织。更稳的做法通常是双层入口：
- 一层按平台能力分组，方便产品、工程和支持团队维护边界
- 一层按典型业务任务分组，方便使用者从问题出发找到可用能力组合
如果只做第一层，目录会越来越像内部架构图；如果只做第二层，平台又很难维护统一边界。两者都要有，catalog 才能真正被消费。
一个常见事故：平台明明已经有能力，业务还是重复提了三次需求
某团队的平台其实已经具备文档分类、表单预审和人工 review 接力三项能力，理论上完全能支持多个业务线接入。可半年里，不同业务团队还是反复提出“能不能做文档预分类”“能不能把表单先自动检查一下”“能不能先给人工审核做个草稿建议”。问题不是平台没有能力，而是这些能力分别藏在不同 demo、不同项目经验和不同同学脑子里，没有一个统一目录告诉新团队：哪些能力已经成熟、哪些只是试点、哪些要先满足数据契约才能开。
最后平台团队修的不是又做一遍能力，而是把能力目录显式化：每项能力带状态、owner、风险边界、适用模板和接入前置条件；业务侧提需求时，必须先从 catalog 里标出准备复用哪一类能力。这个改动没有立刻减少研发工作量，但显著减少了“平台已经做过却还在从零解释”的浪费。
如果你现在只能先补一层，先把 Top 20 高复用能力做成带边界的目录
很多团队会被“要不要先把完整 catalog 一次做完”卡住。其实更务实的做法，是先收口最常被问、最常被复用、最容易被误用的那一批能力。优先不是覆盖面，而是清晰度：每一项能力都要能回答使用条件、限制、owner 和生命周期状态。
AI agent 平台做大之后，一个能力如果无法被发现、无法被理解、无法被正确找到 owner，实际效果就和它不存在差不多。目录不是装饰层，它本身就是平台可规模推广的一部分。
延伸阅读：
