从场景穷举到能力抽象：Agent 平台产品的设计方法

摘要

Agent 平台产品设计过程中存在一类高频偏差：产品经理沿用需求定义阶段的穷举方法，逐条罗列业务场景，并以此作为平台设计的输入。该方法在需求定义阶段具有合理性，但在平台构建阶段会带来三类系统性代价——覆盖不可完备、维护成本递增、缺乏结构信息。

本文提出一条从场景到能力的抽象路径：以动作结构统一场景描述，以动词收敛压缩场景空间，以契约属性划分能力边界，并以"新增场景是否零新增能力"作为抽象是否完成的验收标准。在此基础上，给出平台级场景的判定标准，包括平台级场景应具备的六项特征、不具备平台化价值的场景类型，以及打样场景的选择标准，并给出可对照判断的场景示例。文末给出 16 条典型偏差对照表与 5 项自检问题。

一、问题的提出

1.1 穷举在需求定义阶段的合理性

穷举并非方法错误，其合理性取决于所处的设计阶段。

偏差的产生机制是阶段错配：将需求定义阶段形成的工作习惯直接沿用到平台构建阶段，导致所有场景均被当作独立需求处理。

1.2 平台阶段沿用穷举的三类代价

1.3 三类判断信号

当设计过程中出现下列信号时，说明方法已与阶段不匹配：

二、穷举与抽象的适用边界

穷举与抽象并非互斥，二者作用于不同对象。

2.1 适用对象的划分

基本原则：对失败路径穷举，对成功路径抽象。

失败路径须逐条穷举，原因是交互体验的显著劣化集中发生在异常处理环节，且该环节的条目数量有限，通常为 8 至 12 条，处于可控范围。

2.2 兜底路径清单

下表可直接作为设计检查项使用。

三、平台级场景的判定标准

并非所有场景都具备平台化价值。将缺乏可抽象性的场景上收，会产生"伪平台能力"——契约模糊、无法复用、维护成本高于收益。因此在上收之前，须先判定场景是否具备平台级特征。

3.1 平台级场景的六项特征

3.2 不具备平台化价值的场景

判据的补充说明：场景集合是收敛还是发散，决定了平台化是否成立。 若已知场景集合有限且封闭，平台化只会抬高实现成本。

3.3 打样场景的选择标准

平台化的第一步是完成 1 至 2 个真实场景，作为抽象的样本来源。打样场景的选择直接影响抽象结果的质量。

补充说明：若当前仅有单一场景，应记录其动作结构并保留抽象可能，但不应立即上收。过早抽象产出的契约，会在第二个场景出现时被推翻。

3.4 典型场景示例

（一）适合平台化的场景

（二）不适合平台化的场景

（三）打样场景的选择示例

补充说明：上述示例的共同做法是——先用两个真实场景验证动作是否重复出现，再决定是否上收。表（一）中列出的是已经具备平台级特征的场景类型，而非可以直接上收的结论。

四、从场景到能力的抽象路径

抽象过程可拆解为四个顺序步骤。

4.1 四步法

4.2 契约判据

第三步的判断依据为下列四问，任一项存在差异即须拆分。

示例：同属"查询"语义，查询天气（无副作用、结果可缓存）与查询订单（涉及隐私数据、须鉴权）应拆分为两个独立能力。

五、抽象的验收标准

判定原则：若新增一个场景不需要新增能力、仅需新增一条编排，则抽象已完成。

三个可验证信号：

反向判据：若每新增一个场景均需新增能力，则抽象尚未完成。

六、转化阶段的四类典型偏差

补充一项流程层面的偏差：以场景清单作为交付验收依据。交付物应为"能力与编排"，而非场景列表。

七、场景层与能力层的职责划分

结论：场景通过编排能力实现，而非通过新增能力实现。

以能力作为场景的划分依据是该方法论中最常见的混淆：场景按行业与工作流划分，能力按契约划分，二者不属于同一维度。该划分方式将导致能力数量随"场景数 × 动作数"增长，无法收敛。

八、能力的可运营性要求

能力完成抽象后，若缺乏必要的运营手段，则无法在生产环境中持续使用。

须注意：版本号相同不代表能力集合相同。 发布物应能够明确回答"当前具备哪些能力"，仅提供版本号不足以支撑定位判断。

九、常见偏差对照表（16 条）

9.1 场景与需求

9.2 边界切分

9.3 能力运营

9.4 组织与流程

十、结论与自检清单

在平台设计完成后，可用下列五个问题完成自检：

1. 当前工作属于场景罗列，还是能力抽象？（阶段判断）
2. 该抽象是否有 2 个以上真实场景支撑？（上收条件）
3. 新增一个场景是否需要新增能力？（抽象完成度）
4. 失败路径是否已逐条穷举？（异常覆盖）
5. 该能力上线后是否具备灰度、停用与故障识别的条件？（可运营性）

全文结论：穷举用于确定当前阶段应实现的内容，抽象用于避免下一阶段重复建设。二者的适用边界一旦混淆，平台设计将退化为需求列表的持续累加。