主题
产品原型：把平台能力做成可点击的界面
一句话：原型不是 UI 稿，而是把平台的关键对象和状态流做成可操作界面；它验证的是“信息是否齐全、动作是否闭环”，不是配色和动效。
为什么需要
平台类产品最容易死在“能力都有，但没人会用”。文档能说清架构，却说不清一个业务人员从进入平台到拿到结果要经过哪些页面、每个页面必须看到什么、出错后从哪里恢复。原型把这些动作提前跑一遍：创建 Agent 时缺哪个字段、发布 Skill 时卡在谁审批、任务失败后在哪看轨迹，都会在点击过程中暴露。
这个原型已经具备完整交互，因此不重做页面，而是直接嵌入。阅读时建议先自己走一遍，再回来看下面的页面地图。
原型入口
如果嵌入区域显示不完整，可以在新窗口打开原型。原型内的数据均为演示数据，不连接真实系统。
核心机制
页面地图：按角色而不是按技术分层
三条虚线是这张图的重点：一个业务 Agent 从创建到运行，必然经过“选能力 → 产生运行数据 → 能力过评测”三次交接，这三条线不通，平台就退化成三套互不相干的后台。实线只是各角色自己的页面顺序，看的时候可以先略过。
导航按使用者组织，而不是按微服务组织。业务使用者关心“有没有这个场景、怎么建、跑得怎么样”；开发者关心“工具和技能怎么上架”；平台运营关心“资源、质量、成本、风险”。同一份底层能力在不同角色下呈现不同入口，这是平台产品与基础设施控制台的关键差别。
五类关键对象
| 对象 | 代表什么 | 创建后最关键的状态 |
|---|---|---|
| 场景 | 一类业务问题的入口 | 草稿 → 试运行 → 上线 → 下线 |
| Agent | 一次可执行的编排实例 | 定义 → 发布 → 运行 → 归档 |
| Skill | 可复用的业务步骤 | 草稿 → 审核 → 灰度 → 全量 |
| MCP Server | 原子工具连接 | 注册 → 安全评审 → 上架 → 废弃 |
| 知识库 | 受控的知识供给 | 摄入 → 索引 → 生效 → 失效 |
原型里每个列表页都在回答同一个问题：这个对象现在处于什么状态、下一步该谁操作。状态机不完整的平台，最后都会退化成“找管理员改数据库”。
从创建到运行的四个断点
- 创建断点：模型、运行时、工具、知识域、预算是否在一个表单里说清。缺一项，运行时就会用默认值猜。
- 发布断点：谁能发布、需要谁审批、灰度比例多少、失败怎么回滚。原型中的审批页就是把这个断点显式化。
- 运行断点：任务卡住时，用户看到的是“处理中”还是具体步骤、已用预算、当前阻塞点。
- 恢复断点：失败后是重试、换模型、转人工还是终止，界面必须给出可执行动作，而不是只显示错误码。
原型覆盖的能力面
| 区域 | 覆盖内容 | 验证的问题 |
|---|---|---|
| 概览 | 调用量、成功率、成本、告警 | 管理者能否在 30 秒内判断平台是否健康 |
| 资源市场 | MCP、Skill、知识库 | 能力能否被发现、申请、版本化 |
| 核心能力 | Agent 中心、场景、纳管 | 新建与接入是否走同一套治理 |
| 模型与成本 | 路由、预算、计量 | 模型切换与成本归集是否可视化 |
| 运维治理 | 监控、评测、安全、数据飞轮 | 质量与风险是否有闭环动作 |
| 企业管理 | 租户、权限、调度、审批 | 组织边界是否落到界面 |
实战场景
场景一：评审会上被问倒的不是界面，是断掉的状态机
现象：一次平台评审，业务负责人在 Skill 发布页连问三个问题：“提交之后谁来审”“灰度期间出问题找谁”“回滚从哪里进”，平台侧三个人各答一套。会后业务方提了 14 张返工需求单，两个页面重做，排期推迟两周（代价数字为经验值，需校准）。被否掉的不是配色和动效，是没人说得清的流转。
排查：对着会议录屏按四个断点回放，卡点全部落在发布断点与恢复断点。原型把 Skill 画成“草稿 / 已上线”两个状态，中间的审核与灰度被合并掉了：审批人没有落点，灰度比例没有入口，失败没有回滚动作；任务失败页只展示错误码，“重试 / 换模型 / 转人工 / 终止”四个可执行动作一个都没有。对象状态机不完整，页面改得再好看，回答的仍是错误的问题。
对症：每个列表页强制回答同一个问题——这个对象现在处于什么状态、下一步该谁操作，缺哪段状态补哪段：
| 对象 | 原型缺失 | 补齐后的状态与动作 |
|---|---|---|
| Skill | 审核、灰度被合并进“上线” | 草稿 → 审核 → 灰度 → 全量，每个状态标注操作人与等待时长 |
| Agent | 发布后没有归档入口 | 定义 → 发布 → 运行 → 归档，归档保留迁移窗口 |
| 会话与任务 | 失败只显示错误码 | 恢复断点四选一：重试 / 换模型 / 转人工 / 终止 |
复盘：状态机不完整的平台，最后都会退化成“找管理员改数据库”——评审前这条只是判断句，评审后它是那叠返工工单。原型通过的标准不是“看着清楚”，而是任何角色点开任一对象，都能在界面上找到下一个操作人和下一个动作。
场景二：走查记录里每个“查不到”，都是一张后端接口欠账清单
现象：按三角色组织 60 分钟走查，运维角色从“概览页看到客服场景告警”出发，想定位到某一次工具调用，连着三个区域走不通：运维治理看得见租户级成功率下跌，说不出是哪个 Skill 版本变了；点不进单条会话的调用链；成本预算页查得到月账单，查不到单任务预算余量。业务方同样没能在 30 秒内判断平台健康——概览只有数字，没有归因入口。
排查：把三类角色记录的“查不到的字段”汇总去重共 9 项（样本数为经验值，需校准），逐字段回答“这个数据应该由谁产生”。结论是字段缺失不在前端，而在后端能力不存在：trace 没有贯穿网关、会话、Pod、工具与模型五段；会话启动时没有固定配置版本，事后无法还原那次执行用的哪份 Skill 与哪版路由——这一条属于定义态与运行态的契约，见 03-定义态运行态与支撑服务；预算消耗没有任务级快照，计量只能停在账单粒度。
对症：把 9 个字段转成接口清单，页面冻结，后端按清单补齐后才进下一轮走查：
| 走查页 | 查不到的字段 | 对应后端能力 |
|---|---|---|
| 运维治理 | 一次执行的完整调用链 | trace 贯穿网关 / 会话 / Pod / 工具 / 模型 |
| 核心能力 | 本次执行的配置版本与预算余量 | 会话启动固定版本，预算做任务级快照随执行更新 |
| 模型与成本 | 单任务成本与终止原因 | 计量随 trace 上报，按租户与任务归集 |
复盘：原型是需求的最小表达：页面上每个“要问人才能回答”的点，都是一个没写出来的 API。走查的产出是需求清单而不是改页面工单——这条纪律让下一轮开发没有收到一张“界面优化”类需求。
场景三：评审叫“技能”、接口叫“插件”，验收时两套语言对不上
现象：原型评审通过后三个月进入联调验收，业务方按原型语言提改动单“资源市场缺少版本历史”，开发在代码库里搜“技能”一无所获——那个模块叫 plugin。命名分叉扩散到状态词：原型叫“灰度”，接口返回 canary，监控看板叫“放量”。一次 Skill 版本回滚需求在三套语言之间来回翻译，澄清 4 天，23 张工单返工（代价数字为经验值，需校准）。
排查：分叉的时间点能精确定位——原型定稿之后、后端技术评审之前，没有任何产物把页面对象名与 API 资源名锁成同一张表。按五类关键对象逐一核对，场景、Agent、MCP Server、知识库四类的对象名对上了，状态词全部对不上：原型里 Skill 的状态机是“草稿 → 审核 → 灰度 → 全量”，接口枚举是 draft / review / rollout / live，审核与灰度的边界在两套命名里含义不同。
对症：术语同源做成发布门禁，而不是靠评审时的口头约定：
| 门禁项 | 规则 | 不满足时 |
|---|---|---|
| 对象命名 | 页面文案与 API 资源名逐字一致，同受“原型随平台版本更新”约束 | 不发版 |
| 状态命名 | 同一状态机共用一套枚举值与状态迁移表 | 不发版 |
| 变更流程 | 改状态先改定义态状态迁移表，再同步页面 | 变更无效 |
复盘：原型评审锁定的是后端契约：对象名、状态名、动作名，三项都要在原型与实现之间同源。否则评审通过的界面会在实现时变成另一套语言，上线后对不上账的代价全落在工单里。
最小上手
把原型当成评审工具，而不是交付物。组织一次 60 分钟的走查：
- 选一个真实场景，让业务人员从“场景市场”走到“任务完成”，记录每个需要问人的地方。
- 让开发者从“注册 MCP”走到“Skill 灰度发布”，记录每个需要线下沟通的审批。
- 让运维从“告警”走到“定位到某次工具调用”，记录每个查不到的字段。
- 把三类断点分别写成需求，而不是直接改页面。
走查通过的判据是：每个关键动作都能在界面上找到入口、状态和下一步；每个失败都有可执行动作；每个高风险操作都有影响面提示。
生产动作
- 原型与实现同源：页面里的对象名、状态名与后端 API 保持一致，避免评审时叫“技能”、实现时叫“插件”。
- 演示数据脱敏：原型进入文档站前清除内部产品名、真实机构名和真实业务数据，只保留结构与交互。
- 可访问性：表格支持横向滚动，颜色之外还有文字状态，键盘可完成主流程。
- 性能：大列表分页或虚拟滚动；原型阶段就要考虑真实数据量，否则上线后第一屏就卡。
- 版本化：原型随平台版本更新，过期的原型比没有原型更误导。
边界
- 原型不能替代可用性测试：它验证信息结构，不验证真实用户在压力下的行为。
- 交互完整不等于逻辑完整：页面能点通，不代表权限、并发、失败恢复已经设计。
- 不要用原型承诺排期：演示效果会抬高预期，范围与验收标准要单独确认。
- 嵌入页面的限制：原型是独立 HTML，样式与站点隔离；移动端体验以新窗口打开为准。
讲清楚
产品原型的价值是把平台对象、状态和动作提前变成可点击的界面，让业务、开发、运维在同一张图上暴露断点。看原型时不要只看页面数量，而要看五类对象的状态机是否完整、四个断点是否有明确动作：创建时字段是否齐全，发布时审批是否闭环，运行时能否看到阻塞，失败后能否恢复。原型进入文档站前必须脱敏，并且与后端对象命名保持同源，否则评审通过的界面会在实现时变成另一套语言。
适用：企业级 Agent 平台产品设计 | 初稿 2026-10