03 · Agent Platform 应该提供哪些产品功能？ - Product Architecture（章节概述）
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：03 · Agent Platform 应该提供哪些产品功能？ - Product Architecture
文档类型：章节概述 / 产品架构研究 / 研究导航
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 应向用户、开发者与管理员提供哪些可理解、可操作、可验证的产品能力？这些能力如何组织为完整的使用旅程，并与底层技术架构形成清晰映射？
专题导读
本篇属 Agent Platform。本章从产品使用者的任务与体验出发，研究 Agent Platform 的功能架构（Product Architecture）。它承接上一章 02 · Technical Architecture 的 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12，但不把底层技术模块直接照搬为菜单。技术架构回答“平台如何实现”，产品架构回答“谁在什么情境下，能够通过平台完成什么任务，并获得什么反馈”。两者通过产品对象、操作契约和用户旅程建立映射。
本章采用三类主要使用者视角：使用 Agent 完成任务的业务用户、创建与维护 Agent 的开发者／构建者、管理组织和平台风险的管理员。三类角色可以由同一自然人承担，但权限和操作上下文应分开设计。
研究范围覆盖 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 全部正式专题。本文是章节导航与设计原则，不替代后续各专题的详细交互设计、技术设计或真实用户研究。文中“建议”“参考流程”“验收标准”均属于待验证的设计假设。
研究结论
- 产品架构应围绕完整用户任务组织，而不是围绕微服务命名。 从创建、配置、调试、发布，到执行、协作、监控、管理与交付，用户应能理解任务所处阶段及下一步行动。
- Agent、Workflow、Run、Artifact 是四类关键产品对象。 Agent 表示可复用能力；Workflow 表示协作流程；Run 表示一次执行；Artifact 表示具体产出。界面必须清楚区分定义、版本与运行实例。
- 创建与执行应分离，编辑与发布应分离。 草稿修改不能静默改变已发布 Agent，运行中的任务不能因为版本更新而意外改变执行依据。
- 系统状态、任务结果与质量审核是不同维度。 “运行成功”不等于“结果正确”，产品界面必须分别呈现。
- 人类控制是产品能力的一部分。 用户需要知道任务由谁执行、正在做什么、消耗多少资源，以及何时可以暂停、取消、审批、返工或接管。
- 权限、预算和数据边界必须在关键操作点可见。 产品不能仅在管理员后台隐藏这些限制，也不能让前端可见性替代后端授权。
- 初期应优先完成闭环而非铺满功能。 对 Studio，优先实现“构建 - 测试 - 发布 - 执行 - 审核 - 交付 - 复盘”的一条真实链路，再扩展市场、复杂团队协作与高级治理。
01 · 本章研究定位
1.1 Product Architecture 的定义
Agent Platform 的 Product Architecture 是面向用户的功能能力、产品对象、信息架构、交互流程、状态反馈与角色权限的系统组织方式。它将平台技术能力转换为用户可执行的操作和可感知的结果。
可从五个层次理解：
| 层次 | 研究问题 | 典型交付物 |
|---|---|---|
| 用户与情境 | 谁在何时为什么使用平台？ | 角色画像、任务场景、Jobs-to-be-Done |
| 产品对象 | 用户操作的实体是什么？ | Agent、Workflow、Run、Artifact 对象关系 |
| 功能能力 | 用户可以完成哪些动作？ | F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 功能树、权限矩阵 |
| 使用流程 | 如何从起点走向可验证结果？ | 用户旅程、任务流、状态机、异常路径 |
| 体验与质量 | 如何判断可用、可靠、易理解？ | 可用性指标、验收标准、错误与恢复设计 |
1.2 与其他章节的边界
| 章节 | 核心视角 | 与本章的关系 |
|---|---|---|
| 04/01 Fundamentals | 平台定义、构成、类型和原则 | 说明为什么需要这些产品能力 |
| 04/02 Technical Architecture | Control Plane、Execution Plane、Registry、Workflow 等实现机制 | 为功能提供真实的系统支撑 |
| 04/03 Product Architecture | 用户任务、功能、交互与体验 | 把系统能力组织为可用产品 |
| 04/04 Engineering & Practice | 技术选型、研发、部署与验证 | 把产品需求落到工程计划与交付 |
本章并不把 UI 页面设计等同于产品架构。一个“启动”按钮背后包含版本选择、权限校验、预算检查、运行创建、事件订阅和取消语义；反过来，底层每个 API 也不一定需要独立页面。
02 · 使用者、角色与目标
| 使用者 | 主要目标 | 常见操作 | 最关心的反馈 |
|---|---|---|---|
| 业务用户 / Operator | 让 Agent 完成实际任务 | 选择 Agent、启动、提供输入、审核、导出 | 进度、质量、成本、交付 |
| Agent 构建者 / Builder | 设计可复用的 Agent | 创建、配置、调试、测试、发布 | 版本、测试、依赖、可维护性 |
| Workflow 设计者 | 组织多个 Agent 协作 | 设计节点、依赖、分支、审批 | 执行路径、失败恢复、产物流转 |
| 应用开发者 / Developer | 将平台集成到其他产品 | API Key、SDK、Webhook、日志 | 契约稳定性、错误、配额 |
| 工作空间管理员 | 管理团队协作与资源 | 成员、角色、共享、预算 | 访问边界、成本、审计 |
| 平台管理员 / Operator | 保障平台可运营 | 策略、租户、运行环境、告警 | 健康、容量、风险、事件 |
角色不是固定的账户类型。 同一用户可以同时是某个工作空间的管理员和另一个项目的普通成员；实际权限必须结合主体、资源、操作与上下文判定。
2.1 三条核心用户旅程
旅程 A：构建者。 创建 Agent → 配置能力与依赖 → 预览调试 → 运行测试 → 发布版本 → 分享或部署 → 观察反馈 → 迭代。
旅程 B：业务用户。 进入工作空间 → 选择 Agent / Workflow → 输入任务 → 确认成本与权限 → 启动 Run → 观察进度 → 审核与干预 → 获取产物 → 评价结果。
旅程 C：管理员。 建立组织与工作空间 → 配置成员与资源 → 设置权限和预算 → 查看运行与审计 → 处理异常 → 调整策略。
这三条旅程交叉但不混同：构建者的“发布成功”、业务用户的“执行成功”和管理员的“合规通过”应分别呈现。
03 · 产品核心对象与关系
flowchart LR
Org[Organization / Tenant] --> WS[Workspace]
WS --> Project[Project]
WS --> Agent[Agent Definition]
Agent --> AV[Agent Version]
WS --> WF[Workflow Definition]
WF --> WV[Workflow Version]
WV --> Run[Workflow Run]
AV -. 被固定引用 .-> Run
Run --> Step[Step Run / Agent Run]
Step --> Artifact[Artifact]
Artifact --> Asset[Managed Asset]
WS --> Resource[Resource Binding]
Resource -. 受授权调用 .-> Step| 产品对象 | 用户可见含义 | 关键动作 | 不应混淆的对象 |
|---|---|---|---|
| Agent | 一种可复用的任务执行能力 | 创建、编辑、测试、发布、共享 | 具体运行 Run |
| Agent Version | 某次已冻结的能力定义 | 查看差异、发布、回滚引用 | 可变草稿 Draft |
| Workflow | 一套可复用的协作流程 | 编排、校验、发布 | 某次执行 Workflow Run |
| Run | 某次具体执行 | 启动、观察、暂停、取消、重试 | Agent 定义本身 |
| Workspace / Project | 团队与任务的组织范围 | 创建、授权、归档 | 租户安全边界本身 |
| Resource / Connection | 模型、工具或数据源的受控连接 | 配置、授权、绑定 | 明文凭证 |
| Artifact / Asset | 执行产物及受管理资产 | 预览、审核、版本化、导出 | 临时运行日志 |
产品必须明确显示关键对象的名称、归属、状态、版本、权限与来源，避免“同名不同版”“看到但无权操作”“成功但找不到产物”等问题。
04 · F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 正式专题导航
本表严格遵循 v1.3 既定目录名称与顺序。
| 编号 | 正式专题 | 用户核心问题 | 核心能力 | 主要角色 |
|---|---|---|---|---|
| F1 | 用户如何创建一个 Agent？ - Agent Creation | 如何从零创建一个可识别、可保存的 Agent？ | 创建入口、模板、基本信息、草稿初始化 | Builder |
| F2 | 用户如何配置和修改 Agent 的能力？ - Agent Configuration | 如何设定 Agent 的行为和依赖？ | 模型、指令、工具、知识、参数、权限引用 | Builder |
| F3 | 用户如何开发、调试和测试 Agent？ - Agent Development & Testing | 如何验证 Agent 能按预期工作？ | 预览、Trace、测试集、回归、错误定位 | Builder |
| F4 | 用户如何发布、共享和复用 Agent？ - Agent Publishing & Sharing | 如何让 Agent 被可靠复用？ | 发布版本、渠道、权限、分享、复制与复用 | Builder / Operator |
| F5 | 用户如何组织和管理工作空间与项目？ - Workspace & Project Management | 如何组织人、任务和资源？ | 空间、项目、成员、角色、资源归属 | 全角色 |
| F6 | 用户如何启动、操作和控制 Agent？ - Agent Execution | 如何发起并控制一次任务？ | 输入、启动、进度、暂停、取消、重试 | Operator |
| F7 | 用户如何组织多个 Agent 协同工作？ - Agent Collaboration | 如何让多个 Agent 分工协作？ | 工作流、任务分配、交接、审核、人工介入 | Builder / Operator |
| F8 | 用户如何查看 Agent 的运行状态与结果？ - Agent Monitoring | 如何知道发生了什么？ | Run 列表、状态、Trace、成本、结果与告警 | 全角色 |
| F9 | 用户如何管理 Agent 的版本与生命周期？ - Agent Management | 如何持续维护已有 Agent？ | 版本对比、升级、停用、回滚、归档 | Builder / Admin |
| F10 | 用户如何管理任务产物与交付成果？ - Artifact & Delivery Management | 如何检查、复用和交付结果？ | 产物预览、审核、版本、下载、分享、导出 | Operator |
| F11 | 开发者如何通过 API 与 SDK 集成平台能力？ - Developer Experience | 如何从外部产品可靠调用平台？ | 凭证、文档、示例、SDK、Webhook、调试 | Developer |
| F12 | 管理员如何管理整个平台？ - Platform Administration | 如何让平台安全、稳定且可控？ | 租户、成员、策略、预算、配额、审计 | Admin |
4.1 功能分组只是分析辅助，不替代正式编号
- Agent 供给链（F1 - F2 - F3 - F4、F9）：创建、配置、验证、发布与维护。
- 协作与执行链（F5 - F6 - F7 - F8）：组织、启动、协同与观察。
- 成果与开放链（F10 - F11 - F12）：交付、集成与治理。
这些分组有交叉：例如 F5 的工作空间影响所有功能的资源归属；F12 的权限治理贯穿所有用户操作。正式知识库仍以 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 独立专题为准。
05 · 产品功能与技术架构映射
下表为主要依赖，不代表一对一模块映射。
| 产品专题 | 主要依赖的技术架构专题 | 核心接口 / 状态契约 |
|---|---|---|
| F1 创建 | P4 Development Services、P3 Registry | Draft 创建、唯一身份、初始状态 |
| F2 配置 | P4、P7 Resource & Integration、P12 Governance | 配置校验、依赖绑定、权限检查 |
| F3 开发测试 | P4、P2 Execution Plane、P10 Data & Assets | Preview Run、Trace、测试报告 |
| F4 发布共享 | P3、P10、P11 Multi-tenancy、P12 | 不可变版本、发布渠道、共享授权 |
| F5 工作空间 | P11、P12、P10 | 成员、归属、资源边界 |
| F6 执行 | P1 Control Plane、P2、P5 Runtime | Run 状态、幂等、取消与恢复 |
| F7 协作 | P6 Workflow Management、P1、P2 | Workflow Version、Step Run、审批 |
| F8 监控 | P2、P5、P6、P10、P12 | 事件流、Trace、状态、成本 |
| F9 管理 | P3、P5、P12 | 版本、部署、弃用、回滚 |
| F10 产物 | P10、P6、P12 | Artifact Version、审核、交付 |
| F11 开发者体验 | P8 Platform API & SDK、P9 Extensibility | API 契约、SDK、Webhook |
| F12 管理 | P11、P12、P5、P7 | 策略、配额、审计、资源健康 |
跨层设计要求： 前端显示的操作可用性、后端实际授权和运行时执行约束必须一致；当出现延迟或冲突，以后端有效决策为准，并向用户返回可理解的原因与恢复建议。
06 · 信息架构与导航原则
6.1 参考信息架构
flowchart TB
Home[平台首页 / Dashboard]
Home --> WS[工作空间 / 项目]
WS --> Agents[Agents]
WS --> Workflows[Workflows]
WS --> Runs[Runs / Activity]
WS --> Assets[Artifacts / Assets]
WS --> Integrations[Resources / Integrations]
Home --> Developer[Developer / API]
Home --> Admin[Administration]
Agents --> Builder[Create / Configure / Test / Publish]
Workflows --> Editor[Design / Validate / Publish]
Runs --> Detail[Trace / Approval / Controls / Results]这是参考导航模型，不是强制页面数量。面向业务用户的产品可以把 Run 和 Artifact 合并为“任务详情”；面向构建者的产品可以突出 Builder 和测试；面向管理员则突出治理面板。关键在于同一对象的身份和状态应跨页面一致。
6.2 产品界面需要遵守的六条原则
- 对象清晰。 明确当前操作的是 Agent 草稿、已发布版本、部署还是某次 Run。
- 状态可解释。 除“运行中／成功／失败”，应呈现等待审批、排队、取消中、部分成功、质量未通过等状态。
- 操作可恢复。 高风险操作提供确认、撤销或明确的补救路径；不能保证撤销的外部副作用须明确告知。
- 版本可追溯。 Run 详情可查看实际使用的 Agent / Workflow 版本和关键资源引用。
- 权限可理解。 显示为什么某项操作不可用，但不泄露敏感策略和其他租户信息。
- 结果可交付。 产物应可定位、可预览、可审核，符合权限后可下载或共享。
07 · 关键状态与交互契约
7.1 Agent 创建与发布
stateDiagram-v2
[*] --> Draft
Draft --> Draft: 编辑 / 校验 / 测试
Draft --> Published: 校验通过 + 发布授权
Published --> Deprecated: 弃用
Published --> Revoked: 撤销
Deprecated --> Archived: 归档
Revoked --> Archived: 归档这是产品视角的简化状态图。已发布的具体版本不可变；继续编辑应创建新草稿或新版本。撤销是否影响运行中的任务，必须结合风险等级和治理策略单独定义。
7.2 Run 执行与结果
| 维度 | 典型状态 | 产品含义 |
|---|---|---|
| 执行状态 | queued、running、waiting、completed、failed、cancelled | 任务引擎执行进度 |
| 审核状态 | not_required、pending、approved、rejected | 人或规则是否接受结果 |
| 交付状态 | not_ready、ready、delivered、revoked | 产物是否可以交付与访问 |
不能将三个维度压缩成单个“成功”。例如，执行 completed 但审核 rejected，应允许基于审核意见返工；交付 delivered 也不等于结果的事实正确性已经独立验证。
7.3 关键异常路径
| 场景 | 必须告知用户 | 建议的恢复动作 |
|---|---|---|
| 资源授权失效 | 哪类连接失效、影响哪个步骤 | 重新授权、重新运行受影响步骤 |
| 预算不足 | 当前已用与预计超额 | 调整预算、缩小任务、申请审批 |
| Agent 版本已弃用 | 受影响的版本与替代版本 | 查看差异、迁移或保留历史运行 |
| 任务失败 | 失败步骤、可重试性、已产生的副作用 | 安全重试、人工处理、终止 |
| 审批超时 | 审批对象、等待时长、超时策略 | 催办、改派、取消 |
| 产物不可访问 | 权限或保留状态的可公开原因 | 请求访问、重新生成、联系管理员 |
08 · Studio：多 Agent 研究报告平台的贯穿案例
8.1 用户场景
用户希望创建一个“研究报告 Studio”，组织选题 Agent、选题审核 Agent、调研 Agent、分析 Agent 和写作 Agent，完成从需求输入到正式报告交付的全过程。平台既要让用户管理 Agent 团队，也要展示工作流执行、审核返工、人工确认和最终产物。
8.2 最小闭环
flowchart TD
A[创建 Workspace / Project] --> B[创建或选择 Agents]
B --> C[配置工具 / 知识 / 权限]
C --> D[预览测试]
D --> E[发布 Agent Versions]
E --> F[配置 Workflow]
F --> G[启动 Workflow Run]
G --> H[选题与审核]
H -->|不通过| H
H -->|通过| I[深度调研与分析]
I --> J[人工确认]
J -->|返工| I
J -->|通过| K[写作与产物提交]
K --> L[审核 / 导出 / 交付]
L --> M[运行复盘与版本迭代]在此流程中，F1 - F2 - F3 - F4 解决“Agent 能否被可靠构建和复用”，F5 - F6 - F7 解决“团队如何组织和运行”，F8 - F9 - F10 解决“如何观察、审核和交付”，F11 - F12 解决“如何集成、授权和治理”。
8.3 Studio 初期产品页面建议
| 产品界面 | 用户核心动作 | 最小数据要求 | 主要对应专题 |
|---|---|---|---|
| Studio / Project 首页 | 查看研究目标、团队、当前阶段 | Project、成员、状态 | F5 |
| Agent 管理 | 创建、配置、测试、发布 | Agent、Draft、Version、Test | F1 - F2 - F3 - F4、F9 |
| Workflow 编辑 | 选择节点、设置顺序与审核 | Workflow Definition / Version | F7 |
| Run 工作台 | 启动、观察、暂停、审批、返工 | Run、Step Run、Event、Approval | F6 - F7 - F8 |
| 产物中心 | 查看草稿、对比、审核、导出 | Artifact、Asset Version | F10 |
| 资源与设置 | 连接工具、管理权限和预算 | Resource Binding、Grant、Budget | F5、F12 |
阶段性取舍： 初期可以先实现单工作空间、固定工作流模板、少量内置 Agent、基础 Trace 和 Markdown 交付。复杂画布编辑、公开市场、多租户计费与企业级管理功能应依据真实使用需求分阶段引入。
09 · 功能优先级与分阶段开发
优先级是对 Studio 早期场景的参考判断，不是对所有 Agent Platform 的通用结论。
| 阶段 | 目标 | 重点功能 | 进入下一阶段的判据 |
|---|---|---|---|
| M0 · 概念闭环 | 验证任务流程与信息架构 | 固定 Agent、固定工作流、模拟审核与产物 | 用户可理解完整流程，关键状态无歧义 |
| M1 · 真实闭环 | 一条端到端真实任务可用 | Agent 配置、真实 Run、审批、Trace、产物 | 真实研究任务可重复完成并交付 |
| M2 · 可复用 | 支持多项目和持续迭代 | 版本发布、工作空间、测试、资源绑定 | 版本可追溯，失败可恢复，资产可复用 |
| M3 · 团队协作 | 支持权限和组织协作 | 角色授权、共享、审计、配额 | 不同角色职责清晰、权限验证通过 |
| M4 · 平台开放 | 面向外部开发者与生态 | SDK、API、插件、开放集成 | 契约稳定，安全与兼容性验收通过 |
避免的反模式： 在没有真实执行闭环前过度建设 Agent Marketplace；把模型输出当作可审计状态；用聊天消息列表替代 Workflow Run / Step Run；把“Agent 自己说已完成”当作系统完成判据。
10 · 产品评价与验证方法
10.1 评价维度
| 维度 | 核心问题 | 可观察指标（待定义基线） |
|---|---|---|
| 任务完成度 | 用户是否达成目标？ | 端到端完成率、交付率、人工返工率 |
| 易学性 | 新用户能否理解对象与流程？ | 首次任务成功率、求助次数、任务耗时 |
| 可控性 | 用户能否知道并干预运行？ | 状态理解准确率、取消/审批成功率 |
| 可追溯性 | 能否还原产物与执行依据？ | 版本关联完整率、产物来源完整率 |
| 可靠性 | 失败后能否安全恢复？ | 恢复成功率、重复副作用事件数 |
| 成本透明度 | 用户能否理解消耗？ | 预算超限事件、估算与结算偏差 |
| 安全性 | 权限边界是否有效？ | 越权测试通过率、敏感操作审计覆盖率 |
上述指标需要结合目标用户、业务风险与真实运行数据制定阈值；不能仅凭界面演示判定系统可靠。
10.2 用户研究与工程验证结合
- 任务访谈： 观察构建者、业务用户和管理员分别如何理解 Agent、Workflow、Run 与 Artifact。
- 可用性测试： 让参与者完成创建、配置、启动、审批、查错和交付等真实任务，记录阻塞点。
- 契约测试： 验证 UI 状态与 API / 运行状态的一致性，特别关注异步、重试和取消。
- 权限测试： 验证跨工作空间访问、角色变更、撤销授权及敏感资源调用。
- 故障注入： 模拟 Worker 失联、事件延迟、资源不可用、预算耗尽和审批超时。
- 产物质量评估： 单独评估研究报告的事实准确性、引用完整性与审核一致性。
10.3 章节级验收清单（参考）
- [ ] 用户能明确区分 Agent 草稿、已发布版本、Workflow 与 Run。
- [ ] 所有关键操作都有明确的权限边界与错误反馈。
- [ ] 创建、配置、测试、发布、运行、交付形成完整闭环。
- [ ] 异步任务的排队、运行、等待、失败与取消状态可解释。
- [ ] 用户能查看任务实际使用的 Agent / Workflow 版本。
- [ ] 审核通过、执行完成、产物交付具有独立状态。
- [ ] 用户能定位错误步骤、理解可重试性与副作用风险。
- [ ] 产物可以关联来源、审核记录及版本。
- [ ] 管理员可以追踪关键授权、配额和高风险操作。
- [ ] 开发者能够通过文档化 API 调用核心能力（开放阶段）。
11 · F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 后续研究的统一写作框架
为保持专题深度与可比较性，后续每篇建议遵循以下研究顺序，同时按具体问题调整篇幅：
- 专题导读与研究结论： 该产品能力解决什么用户问题，结论与适用边界是什么。
- 用户与场景： 主要角色、触发情境、任务目标、前置条件与限制。
- 功能边界： 本功能负责什么，不负责什么，与相邻专题如何衔接。
- 产品对象与状态： 核心对象、属性、生命周期、权限与状态转换。
- 用户流程与交互： 主路径、替代路径、异常路径、反馈与恢复。
- 功能需求： 最小能力、可选高级能力、业务规则与非功能要求。
- 技术映射： 依赖 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 的哪些能力、API、事件和数据契约。
- Studio 案例： 用研究报告平台的具体操作展示产品闭环。
- 验证方法： 可用性、契约、安全、可靠性及验收用例。
- 参考文献与证据说明： 区分已核验资料、设计推论和未测试方案。
每篇专题都应回答： “用户想做什么、系统提供什么、交互如何发生、失败如何处理、如何证明该功能有效？”
12 · 本章研究顺序与专题衔接
| 顺序 | 专题 | 核心交付关注 |
|---|---|---|
| 1 | F1 · Agent Creation | 创建入口、模板、草稿、身份 |
| 2 | F2 · Agent Configuration | 能力配置、依赖与授权 |
| 3 | F3 · Agent Development & Testing | 预览、调试、评估、反馈 |
| 4 | F4 · Agent Publishing & Sharing | 发布、共享、复用与可见性 |
| 5 | F5 · Workspace & Project Management | 空间、项目、成员与资源归属 |
| 6 | F6 · Agent Execution | 任务输入、启动、控制与恢复 |
| 7 | F7 · Agent Collaboration | 多 Agent 协作与人机审批 |
| 8 | F8 · Agent Monitoring | 运行状态、Trace、成本、结果 |
| 9 | F9 · Agent Management | 版本与生命周期维护 |
| 10 | F10 · Artifact & Delivery Management | 审核、版本、交付与复用 |
| 11 | F11 · Developer Experience | API、SDK、集成与文档 |
| 12 | F12 · Platform Administration | 平台治理、配额、审计与运营 |
13 · 局限、待验证问题与后续决策
- 目标用户尚需验证。 不同产品可能面向非技术用户、工程师或企业管理员；信息架构需要依据真实用户测试调整。
- 产品功能与底层实现不是一一对应。 例如一个 Run 详情页会跨越执行、工作流、资产和治理多个技术服务。
- Agent 的自主程度影响交互设计。 高自主、长时运行的 Agent 需要更明确的中间检查点、预算上限与人工介入机制。
- 不同执行引擎的能力不同。 暂停、恢复、检查点和取消是否可用，取决于底层实际实现，不能仅靠 UI 宣称支持。
- 质量评价是独立研究问题。 模型输出的正确性、研究报告的证据质量及用户满意度不能由执行状态自动推断。
- 移动端、国际化、无障碍与多端同步需要在正式产品设计中单独制定标准，本概述不提供完整设计规范。
- 商业化与计费模型可能改变工作空间、组织和配额设计，需与后续商业需求联合验证。
附录 A：参考文献与原始资料
以下列出与本章相关的规范和官方文档入口，用于后续 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 的具体研究。它们不共同构成一套现成的 Agent Platform 产品架构标准；本章对象模型、分组与 Studio 优先级属于综合分析与设计建议。未对全部外部页面执行逐条实时核验。
- OpenAI. Agents SDK Documentation. openai.github.io/openai-agents-python （Agent 构建、工具、运行与追踪的实现参考）。
- LangChain. LangGraph Documentation. docs.langchain.com/oss/python/langgraph/overview （状态化工作流、人类介入与持久执行参考）。
- Dify. Documentation. docs.dify.ai （可视化 Agent / Workflow 产品能力参考）。
- Microsoft. Microsoft Agent Framework Documentation. learn.microsoft.com/en-us/agent-framework （Agent 与工作流框架参考；具体功能以当前版本为准）。
- OpenAPI Initiative. OpenAPI Specification. spec.openapis.org/oas/latest.html （API 契约与开发者集成）。
- JSON Schema. Specification. json-schema.org/specification （结构化配置和输入校验）。
- W3C. Web Content Accessibility Guidelines (WCAG) 2.2. www.w3.org/TR/WCAG22 （界面可访问性要求）。
- NIST. AI Risk Management Framework. www.nist.gov/itl/ai-risk-management-framework （AI 风险治理与组织管理）。
- Nielsen Norman Group. Ten Usability Heuristics for User Interface Design. www.nngroup.com/articles/ten-usability-heuristics （可用性启发式原则）。
- Kubernetes. Objects in Kubernetes. kubernetes.io/docs/concepts/overview/working-with-objects （声明式对象、状态与元数据的工程类比；不等同于 Agent 产品规范）。
附录 B：研究证据、验证声明与适用边界
| 内容类别 | 证据状态 | 使用说明 |
|---|---|---|
| F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 名称、编号与顺序 | 已由本项目 v1.3 目录确定 | 属于本知识库内部权威目录，不是外部标准 |
| P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 与产品功能的映射 | 架构推论 | 应随技术实现和真实需求复核 |
| Agent / Workflow / Run / Artifact 产品对象 | 参考设计 | 与既有技术研究概念保持一致，需在具体平台中落实契约 |
| Studio 用户旅程与 MVP 优先级 | 项目场景推论 | 基于多 Agent 研究报告流程提出，未经过正式用户研究 |
| Mermaid、状态机与页面导航 | 参考方案 | 非生产系统截图或已运行系统证明 |
| 产品指标、验收清单 | 验证计划 | 尚未收集真实指标，不代表测试通过 |
| 外部参考文献 | 官方资料入口 | 未逐条实时核验页面内容、版本和发布日期 |
结论边界： 本章建立研究导航与产品架构分析框架，不宣称 Studio 已具备所列全部功能，也不把建议中的交互流程视为经过可用性测试的最终设计。