02 · Agent Platform 由什么构成？ - Core Components
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：01 · Agent Platform 是什么？它如何工作？ - Fundamentals
文档类型：专题研究
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：Agent Platform 应当由哪些核心能力与逻辑组件构成？这些组件分别承担什么职责、管理什么对象、通过什么契约协同？如何区分平台的必需能力、可选能力、逻辑组件、实际部署服务与用户界面，并将组件模型映射到 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12、F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12？
专题导读
本篇属 Fundamentals。本篇承接《01 · 什么是 Agent Platform？ - Definition & Boundaries》的工作定义：Agent Platform 将 Agent 的定义、配置、运行与管理能力抽象为可复用、可访问、可治理的软件服务。上一专题解决“什么可以称为平台”；本篇解决“平台的能力由哪些部分共同实现”。核心组件是逻辑职责的划分，不等于独立微服务、代码仓库、数据库表或页面。 同一部署单元可承担多个职责；同一逻辑职责也可能由外部服务提供。
研究路线：从使用者与平台对象出发，建立组件分类和依赖关系；解释各组件的输入、输出与责任边界；以研究报告 Studio 演示跨组件协同；最后给出最小平台、扩展平台、验证清单及与后续章节的映射。本文的组件分类是知识库的参考模型，不是行业唯一标准或某个厂商的标准产品清单。
一、为什么要从“组件职责”而不是“功能页面”理解平台
“创建 Agent”可以是一个页面，也可以是一组 API，但实际涉及身份授权、Agent 定义校验、配置存储、版本生成、资源引用和审计。“运行 Agent”可能表现为点击按钮，内部却需要版本解析、执行请求、调度、运行时、工具权限、状态记录与结果交付。因此，不能从页面数量推导平台的组成，也不能把 Agent Builder 当作平台的全部。
为了避免概念混淆，本篇使用四个不同层次：**能力（Capability）**指平台向使用者提供什么；**逻辑组件（Logical Component）**指谁对一项职责负责；**部署单元（Deployment Unit）**指这些职责运行在哪些进程或基础设施中；**产品功能（Product Feature）**指使用者通过什么交互完成任务。例如“Agent 版本管理”是一项能力，“Registry”可以承担其数据管理职责，Registry 可部署在单体后端中，用户则在版本页面操作。四者相关，但不等同。
1.1 从平台成立条件推导最小能力
| 平台成立维度 | 最小可观察能力 | 典型逻辑责任方 | 不必具备的形式 |
|---|---|---|---|
| Agent 对象化 | Agent 可被定义、标识、读取和更新 | 定义管理 / Registry | 独立 Registry 微服务 |
| 能力服务化 | 通过稳定接口创建、运行、管理 | API / 接入层 | 图形界面、公开市场 |
| 运行可管理 | Run 有标识、状态和结果记录 | 运行管理 / Runtime | 独立执行集群 |
| 资源与责任边界 | 操作权限、工具使用和资源边界可执行 | 身份授权 / 策略执行 | 完整企业级 IAM 产品 |
最小平台还必须具备某种实际执行路径，但 Agent Runtime 可以是平台内置组件，也可以是受控的外部系统。组件“必需”应理解为必须落实职责，而不是必须自行研发全部实现。
二、Agent Platform 的核心组件参考模型
为了覆盖从开发到运行再到交付的闭环，本篇将平台能力分成六组：①接入与体验；②定义与开发；③控制与生命周期；④执行与协作；⑤资源与数据；⑥横切治理与运营。它们是分析分组，不是六层强制堆叠架构。
┌─────────────────────────────────────────────────────────────────────────────┐
│ 使用者：开发者 / Agent 创建者 / 业务用户 / 管理员 / 外部系统 │
└─────────────────────────────────────────────────────────────────────────────┘
│ Web UI / API / SDK / CLI
┌─────────────────────────────────────────────────────────────────────────────┐
│ 接入与体验：身份入口、工作空间、Builder、运行控制、监控与产物查看 │
└─────────────────────────────────────────────────────────────────────────────┘
│ 认证身份 + 资源范围 + 操作请求
┌────────────────────────────── 控制与管理职责 ───────────────────────────────┐
│ Agent 定义/Registry │ 配置/版本 │ 发布/部署 │ Run 控制 │ Workflow 定义/调度 │
│ 租户/项目管理 │ 资源目录 │ 资产管理 │ 策略与配额│ 审计与管理接口 │
└─────────────────────────────────────────────────────────────────────────────┘
│ 已授权、已解析版本的执行请求
┌────────────────────────────── 执行与协作职责 ───────────────────────────────┐
│ 执行入口 / 队列 / 调度 │ Agent Runtime / Engine │ Workflow Runtime │
│ 模型与工具适配 │ 运行状态 / 检查点 │ 事件 / 结果 / 产物输出 │
└─────────────────────────────────────────────────────────────────────────────┘
│
┌─────────────────────────────────────────────────────────────────────────────┐
│ 共用依赖：数据库、对象存储、事件总线、密钥管理、模型端点、工具、知识资源 │
│ 横切约束：身份授权、租户隔离、观测、成本与配额、安全策略、可靠性与审计 │
└─────────────────────────────────────────────────────────────────────────────┘图示解读： 控制职责决定“谁可以发布什么版本、使用什么资源、启动哪次运行”；执行职责负责“按批准的定义与策略执行任务、更新状态并产生结果”。运行中也可能发生动态授权、人工审批和策略复核，因此二者不是完全单向的数据流。共用依赖与横切治理贯穿多组组件，不应机械地视为单独一层。
2.1 组件总表：职责、对象、典型契约
| 组件组 | 逻辑组件 | 核心职责 | 主要对象 / 典型接口 |
|---|---|---|---|
| 接入与体验 | API Gateway / BFF / SDK 接入 | 对外提供稳定契约、身份传递、限流 | API Request、API Version |
| 接入与体验 | Workspace / Project 服务 | 用户、团队与业务容器的组织 | Workspace、Project、Member |
| 定义与开发 | Agent Builder / 开发服务 | 编辑、校验、测试 Agent 定义 | Draft、Agent Definition |
| 定义与开发 | Agent Registry | 保存定义、版本、元数据与引用关系 | Agent ID、Version ID |
| 控制与生命周期 | 配置与发布管理 | 版本冻结、环境配置、发布与回滚 | Release、Deployment |
| 控制与生命周期 | Run 管理 | 创建、查询、取消和关联运行 | Run、Run Status |
| 执行与协作 | 调度 / 任务队列 | 接纳、排队、分派执行请求 | Job、Queue、Lease |
| 执行与协作 | Agent Runtime 适配 | 启动或调用 Agent 执行，处理回调 | Execution Request、Event |
| 执行与协作 | Workflow 管理与运行 | 定义依赖、调度步骤、协作与审批 | Workflow Definition、Workflow Run |
| 资源与数据 | 模型 / 工具 / 知识资源目录 | 统一资源描述、授权和引用 | Resource、Credential Reference |
| 资源与数据 | 平台数据与产物服务 | 保存配置、文件、执行结果与共享资产 | Artifact、Asset、Object URI |
| 横切治理 | IAM / 策略 / 租户边界 | 身份、权限、隔离、配额、审计 | Principal、Policy、Tenant |
| 横切运营 | 可观测性 / 计量 / 运维 | 日志、追踪、指标、成本与健康状态 | Trace、Usage Record、Alert |
表中列出的是完整研究范围。一个最小平台可合并多项职责，并不要求实现每一项高级功能。各逻辑组件的细节将在后续 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 中展开。
三、接入与体验：平台如何被使用
3.1 平台接入层（Interface & Access）
接入层提供 Web UI、API、SDK、CLI 或事件接口，使外部主体能够按明确契约访问平台。其职责包括请求认证、基础参数验证、请求关联 ID、接口兼容性与必要的限流。API Gateway 不应成为唯一授权点：执行侧的工具调用、跨租户资源访问和高风险操作仍需要在可信执行路径中校验权限。API 是平台能力的边界，不只是前端调用后端的内部约定。
典型输入是“用户在工作空间中创建 Agent”或“外部系统触发某个已发布 Agent 的运行”；输出是已验证并带有主体身份、租户范围和请求标识的业务命令。外部 SDK 不应包含平台的主授权逻辑，也不应持有所有租户的共享管理密钥。
3.2 工作空间与项目管理（Workspace & Project）
工作空间负责组织成员、权限、资源配额与共享边界；项目或 Studio 负责组织业务目标、Agent 团队、工作流、任务与产物。它们是产品对象，也是权限和数据归属的基础。Workspace 不等于 Agent 的短期记忆空间，也不等于 Runtime 进程目录。 具体平台可以采用 Organization → Workspace → Project 的多级结构，也可以在单租户 MVP 中简化为 Workspace → Project。
3.3 Builder 与开发体验
Builder 将用户意图转换为可验证的 Agent Definition。它可能是可视化表单、流程图编辑器、代码仓库配置或 SDK。核心职责是编辑、校验、预览与提交定义，而不是在浏览器中直接持有高权限模型密钥、运行任意工具或执行生产部署。Builder 依赖 Registry、资源目录、配置服务和测试运行入口；可视化编辑器是 Builder 的一种实现，而非必备形式。
四、定义与生命周期：平台如何管理“要运行的东西”
4.1 Agent Definition 与 Registry
Agent Definition 是 Agent 的逻辑描述，通常包含角色、指令、模型策略、工具引用、知识引用、运行约束和输出契约。Registry 为其分配稳定 ID，维护元数据、版本和引用关系。一个 Agent 可以拥有多个版本，多个部署环境可以引用不同版本。定义版本应尽量不可变，避免历史运行无法复现其配置；运行时密钥应通过引用注入，而不应明文固化到版本快照中。
Registry 不必直接存储所有大文件或模型权重。其职责是建立可追溯的定义索引和引用关系，而大文件可以保存在对象存储或专用知识系统中。Registry 与 Asset Store 的分工是“结构化定义和引用”对“文件、模板、结果等实体资产”。
4.2 配置、发布与部署管理
需要区分四个动作：保存草稿（Draft）、生成不可变版本（Version）、发布可供使用的版本（Release）、将版本绑定到环境和运行参数（Deployment）。有些平台合并发布与部署，甚至直接运行草稿；研究时仍应区分这些概念，以便理解审核、灰度、回滚与历史追溯。
部署对象应指明版本、运行环境、资源限制、可访问工具、密钥引用、发布状态与回滚目标。它不必意味着每个 Agent 都拥有独立常驻容器；无服务器或按需执行也可以通过 Deployment 表达“已批准的可运行配置”。
4.3 Run 管理与运行记录
Run 是一次可识别的执行尝试或任务执行实例，通常关联 Agent Version、Deployment、发起主体、输入、状态、时间、成本和结果。Run 管理组件负责受理、查询、取消、重试策略和运行记录；具体模型推理与工具调用由 Runtime 完成。一个 Workflow Run 可以包含多个 Agent Run；Run 也可能包含多次模型调用、工具调用和人工等待。
运行实例（Runtime Instance）与 Run 不必一一对应：一个进程可能顺序处理多个 Run；一次 Run 也可能在重试或恢复时跨多个进程执行。此区分对可靠性、计费和状态恢复至关重要。
五、执行与协作：平台如何让任务真正发生
5.1 执行入口、调度与资源分配
执行请求首先经过授权、版本解析与配额校验，再由调度组件分派给合适的 Runtime。调度可能使用进程内任务队列、数据库任务表、消息队列或集群调度器。最小平台可以同步执行，但当任务变长、需要重试或并发隔离时，应将请求受理与实际执行解耦。调度负责“任务交给谁、何时运行”；Agent Engine 负责“Agent 如何决定下一步”。
5.2 Agent Runtime / Engine
Runtime 加载已解析的 Agent 定义、模型与工具访问策略，执行推理 - 工具调用 - 观察 - 继续的循环，产生日志、事件、状态和结果。平台可以集成第三方 Agent Engine，因此“平台包含 Runtime 适配职责”不等于“必须自己编写推理循环”。这也是与 03 · Agent System → L4 Agent Engine 的关键边界：L4 研究执行引擎内部机制；本篇研究平台如何管理、调用与约束该引擎。
5.3 Workflow 与多 Agent 协作
Workflow 负责步骤依赖、任务分支、协作关系、超时、审批和结果汇聚。需要区分 Workflow Definition（可编辑流程）、**Workflow Version（可追溯快照）**和 Workflow Run（一次执行）。多 Agent 协作可以由 Workflow Runtime 执行，也可以由某个 Agent 动态委派；平台应统一追踪这些运行关系，但不要求所有协作都使用可视化 DAG。
在 Studio 场景中，选题 Agent、审核 Agent、调研 Agent 等可以通过编排关系协作；用户审核属于可信的人机交互与审批环节，不应简化为另一个 Agent 自我确认。
六、资源、数据与资产：平台如何复用外部能力
6.1 资源目录与集成适配
资源目录登记模型、工具、知识源、外部 API、连接器及其可用范围，支持配置引用和权限校验。模型资源可以由 Model Gateway 代理，工具资源可以由 Tool Gateway 或受限执行环境提供，知识资源可由检索服务提供。资源目录是“发现与配置”，资源访问执行是“实际调用与授权”；只登记工具名称并不能确保工具调用安全。
连接器和插件的区别在于：连接器通常封装某个外部服务的访问，插件机制则定义第三方能力如何被安装、注册、授权、升级与卸载。二者可重叠，但不应默认同义。对应 P7 Resource & Integration 与 P9 Extensibility & Ecosystem。
6.2 平台数据与资产服务
平台数据可区分：①管理数据（用户、定义、版本、权限）；②执行数据（Run、事件、检查点、指标）；③业务数据（文档、知识库、用户输入）；④产物（报告、文件、图像、代码等）；⑤审计与计量数据。不同数据的保留期、访问边界、删除方式和合规要求不同。Artifact 是一次任务或项目的成果对象，不等于 Agent 的 Memory，也不等于所有平台资产。
产物服务需要提供可追溯的来源关系：哪个 Run、使用哪个 Agent Version、在哪个 Project 中生成、由谁可访问。大文件宜通过对象存储及受控访问地址交付，而非无限制写入执行日志。
七、横切组件：权限、治理、观测与运营
7.1 身份、授权与租户隔离
身份认证回答“谁在请求”，授权回答“这个主体可以对哪个资源执行什么操作”，租户隔离回答“一个组织的数据和资源是否会被另一个组织访问”。三者相互关联，但不能互相替代。权限校验至少应覆盖 Agent 定义修改、版本发布、Run 启动、工具调用、知识访问和产物读取等关键路径。不能仅依赖 Prompt 声明权限；应在可信服务端或工具执行边界强制执行。
单租户平台仍需要主体权限与资源边界；多租户平台则进一步涉及 tenant_id 的数据隔离、密钥隔离、计算资源配额与噪声邻居问题。完整技术方案属于 P11 与 P12。
7.2 观测、审计、计量与成本
可观测性记录执行状态、结构化日志、链路追踪、延迟和错误；审计记录敏感管理操作与策略决策；计量记录模型 token、工具调用、执行时间及资源消耗。三类数据可以关联 Run ID 和 Trace ID，但用途、访问权限和保留策略不应混为一谈。成本与配额需要在执行前、执行中和执行后形成控制闭环，而不是只在账单页面展示累计费用。
7.3 可靠性与运维
平台需要处理超时、重试、幂等、并发限制、取消、断点恢复、降级、告警与发布回滚。并非所有任务都能做到严格 exactly-once；对外部有副作用的工具调用，通常需要幂等键、事务边界或补偿机制。03 · Agent System 的 H1 - H2 - H3 - H4 - H5 - H6 - H7 - H8 - H9 - H10 - H11 - H12 已研究底层工程治理；本篇重点说明平台如何为多个项目统一提供和落实这些治理能力。
八、核心对象模型与依赖关系
Organization / Tenant
└── Workspace
├── Member / Role / Policy
├── Project / Studio
│ ├── Workflow Definition → Workflow Version → Workflow Run
│ ├── Run → Step / Event / Trace
│ └── Artifact
└── Agent Definition → Agent Version → Release / Deployment
└── Runtime Instance → Run
Resource Catalog → Model / Tool / Knowledge / Connector
Policy & Credential References → Deployment / Run / Tool Invocation此图表达概念关联，不规定所有对象的数据库外键或严格层级。Agent Definition 可以跨多个 Project 被引用；Run 可以由 Project、Workflow 或外部 API 发起；Runtime Instance 与 Run 的关系随运行模式变化。Organization 与 Workspace 也可在单租户产品中合并。
8.1 最容易混淆的六组对象
| 易混对象 | 核心区别 | 错误后果 |
|---|---|---|
| Agent Definition / Agent Version | 可编辑逻辑定义 / 可追溯快照 | 历史执行无法复现 |
| Version / Deployment | 定义内容 / 环境中的可运行绑定 | 无法解释灰度与回滚 |
| Deployment / Runtime Instance | 可运行配置 / 实际承载进程或实例 | 资源管理与运行记录混乱 |
| Runtime Instance / Run | 计算载体 / 一次任务执行 | 错误统计并发和计费 |
| Workspace / Project | 权限资源容器 / 业务任务容器 | 数据归属和权限失控 |
| Asset / Artifact / Memory | 可复用资源 / 任务成果 / Agent 记忆 | 误删、越权共享或污染上下文 |
九、贯穿案例：研究报告 Studio 的组件协同
假设平台支持创建一个“研究报告 Studio”，其中有选题、调研、分析、审核与发布环节。以下是参考交互序列，不是已部署系统的运行记录。
| 阶段 | 用户行为 / 平台事件 | 参与组件 | 关键状态或产物 |
|---|---|---|---|
| 1 | 用户创建 Studio 项目 | Workspace / Project、IAM | Project ID、成员权限 |
| 2 | 用户创建选题 Agent | Builder、Resource Catalog | Agent Draft |
| 3 | 用户配置模型与工具 | Builder、资源目录、Policy | 资源引用、访问约束 |
| 4 | 用户保存并发布版本 | Registry、版本与发布服务 | Agent Version、Release |
| 5 | 用户创建研究工作流 | Workflow 管理、Registry | Workflow Definition / Version |
| 6 | 用户启动研究任务 | API、Run 管理、授权、配额 | Workflow Run ID |
| 7 | 调度器分派 Agent 任务 | Scheduler、Runtime、Tool Gateway | Agent Run、事件与检查点 |
| 8 | 审核节点等待人工确认 | Workflow Runtime、审批服务 | Pending Approval |
| 9 | 用户确认或要求返工 | 产品界面、授权、Workflow | Approval Decision、后续步骤 |
| 10 | 报告生成并交付 | Artifact Store、Project、API | Report Artifact、可控访问链接 |
| 11 | 用户查看状态与成本 | Monitoring、Metering、Audit | Trace、Usage、操作记录 |
关键路径一：配置不等于授权。 用户在 Builder 中选择了某个外部工具，只说明定义引用了该工具；实际 Run 仍必须验证工具在当前 Workspace、Deployment 和请求主体下是否允许调用。
关键路径二：人工审批必须具有可信状态。 审核结果应由平台记录审批主体、决定、时间和适用对象；Agent 自己生成“审核通过”文本不能替代真实审批记录。
关键路径三：交付产物要可追溯。 报告至少关联 Project、Run、版本与权限；否则难以解释某份报告由哪个版本生成，也难以可靠回滚和审计。
十、最小可行平台与成熟平台：哪些组件必须先做
10.1 MVP：落实必要职责，而不是实现所有模块
面向单团队、单租户的研究 Studio，最小闭环可以由一个后端应用、一个数据库、一个对象存储和外部 Agent Runtime 构成：
- 对象管理：Agent Definition / Version、Project、Run、Artifact 有稳定标识和持久化记录。
- 服务入口：通过受认证的 API 或 UI 创建 Agent、启动 Run、查询结果。
- 执行适配：能把已解析的 Agent Version 与允许的资源传给受控 Runtime。
- 权限边界：用户不能读取其他项目的私有资源；工具调用由可信服务校验。
- 基本运行管理：Run 状态、失败信息、取消能力（若 Runtime 支持）和结果持久化。
- 基本观测：能关联请求、Run、错误、成本估计与输出产物。
这六项可以在一个单体服务中实现。初期无需先建设独立 Registry 集群、插件市场、计费中心、多租户控制平面或通用 Workflow IDE。
10.2 规模扩大后的组件演进
| 触发条件 | 优先演进方向 | 不宜提前做的事 |
|---|---|---|
| 多个 Agent 项目复用定义 | 强化 Registry、版本与模板 | 仅为了“微服务化”拆分数据库 |
| 长任务与并发增长 | 队列、Worker、Run 恢复与取消 | 无指标时直接引入复杂集群 |
| 多团队共享平台 | Workspace 权限、配额与审计 | 先建设全功能 Marketplace |
| 外部开发者接入 | 稳定 API、SDK、接口版本管理 | 让外部直接访问内部数据库 |
| 多租户商业化 | 租户隔离、计量、账单与策略 | 把租户隔离仅做成 UI 过滤 |
| 第三方插件增多 | 插件签名、授权、沙箱和生命周期 | 默认授予插件全局系统权限 |
成熟度不等于组件数量。平台是否成熟，应由使用场景下的可维护性、可靠性、隔离性、开发者体验与实际运营结果判断。
十一、组件接口与责任边界：一个最小契约示例
以下是说明性接口契约，并非某一框架的实际 API。它展示如何将定义、版本、运行和产物关联起来：
{
"request": {
"project_id": "project-research-01",
"agent_version_id": "agent-topic:v3",
"input": {"topic": "Agent Platform 组件研究"},
"idempotency_key": "request-20261031-001"
},
"accepted_run": {
"run_id": "run-1042",
"status": "QUEUED",
"agent_version_id": "agent-topic:v3",
"project_id": "project-research-01"
}
}执行前，可信服务必须验证请求主体、Project 访问权限、Agent Version 是否允许使用、资源和配额策略。执行后，Run 记录应能关联状态、事件、成本和 Artifact。幂等键只能帮助识别重复提交，不能自动保证外部工具的副作用恰好执行一次；对邮件发送、支付、删除文件等操作仍需独立的副作用控制。
11.1 核心组件之间的契约清单
| 组件边界 | 必须明确的契约问题 |
|---|---|
| Builder → Registry | 定义校验规则、版本生成、并发编辑冲突 |
| Registry → Deployment | 版本是否不可变、资源引用如何解析、如何回滚 |
| API → Run Manager | 身份、授权、幂等、请求状态与取消语义 |
| Run Manager → Scheduler | 排队、超时、重试、优先级与配额 |
| Scheduler → Runtime | 输入、版本、密钥引用、工具策略、事件格式 |
| Runtime → Artifact Store | 产物归属、上传权限、校验和与保留策略 |
| Runtime → Observability | Trace ID、Run ID、事件顺序、错误分类 |
| Policy → Tool Invocation | 谁可调用何工具、在哪个范围、是否需审批 |
十二、与 v1.3 正式目录的映射
本篇的组件分组是概念视图；P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 是后续技术专题，F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 是用户产品专题。它们存在多对多关系，不能机械地一项组件对应一个页面。
12.1 技术架构 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12
| 专题 | 主要深入研究的组件职责 |
|---|---|
| P1 · Control Plane | 统一控制、对象与策略管理、协调与配置下发 |
| P2 · Execution Plane | 执行环境、运行入口、资源边界与事件回传 |
| P3 · Agent Registry | Agent 定义、版本、索引与引用关系 |
| P4 · Agent Development Services | Builder、校验、测试与开发服务 |
| P5 · Deployment & Runtime Management | 发布、部署、实例、Run 生命周期 |
| P6 · Workflow Management | 流程定义、调度、协作与审批 |
| P7 · Resource & Integration | 模型、工具、知识与外部资源接入 |
| P8 · Platform API & SDK | 对外接口契约、SDK、认证与兼容性 |
| P9 · Extensibility & Ecosystem | 插件机制、扩展点与第三方生态 |
| P10 · Platform Data & Assets | 数据对象、资产、产物与访问控制 |
| P11 · Multi-tenancy & Isolation | 组织、工作空间与隔离策略 |
| P12 · Platform Governance | 权限、配额、审计、策略与治理 |
12.2 产品架构 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12
| 专题 | 主要用户体验与平台组件依赖 |
|---|---|
| F1 · Agent Creation | 创建向导 / Builder / Registry |
| F2 · Agent Configuration | 配置编辑 / 资源目录 / 权限校验 |
| F3 · Agent Development & Testing | 调试、测试运行 / 开发服务 / Runtime |
| F4 · Agent Publishing & Sharing | 发布、共享 / 版本、部署、授权 |
| F5 · Workspace & Project Management | 项目与成员管理 / Workspace / IAM |
| F6 · Agent Execution | 启动、取消、重试 / Run 管理 / Runtime |
| F7 · Agent Collaboration | 多 Agent 流程 / Workflow / 协作状态 |
| F8 · Agent Monitoring | 运行状态与结果 / 观测 / Run 数据 |
| F9 · Agent Management | 版本、停用、归档 / Registry / 生命周期 |
| F10 · Artifact & Delivery Management | 产物查看、分享、交付 / Artifact Store |
| F11 · Developer Experience | API Key、SDK、文档 / 接入层与 API |
| F12 · Platform Administration | 组织、权限、配额、审计 / 治理组件 |
十三、组件设计中的典型错误与检查方法
| 常见错误 | 为什么有问题 | 建议检查 |
|---|---|---|
| 把 Builder 当成整个平台 | 缺少运行、权限与生命周期管理 | 无 UI 时 API 是否仍能工作？ |
| 把 Control Plane 等同于一个后台服务 | 控制职责可能跨多个模块 | 哪些操作是配置决策，哪些是实际执行？ |
| Agent Version 与 Run 不关联 | 历史结果不可追溯 | 任一 Run 能否定位定义快照？ |
| 仅在 UI 层做租户隔离 | API / Worker 可能越权访问 | 直接调用接口是否仍被隔离？ |
| 工具授权写在 Prompt 中 | 自然语言不是强制安全边界 | Tool Gateway 是否执行独立校验？ |
| 所有日志都当成审计记录 | 可能缺少完整性、保留与权限约束 | 审计能否追溯敏感操作主体？ |
| 将 Artifact、Memory 混用 | 数据保留与访问语义不同 | 产物是否独立授权、追踪与删除？ |
| 过早拆分十余个微服务 | 运维成本高于复用收益 | 是否有真实独立扩展或组织边界？ |
13.1 研究验收问题
完成本篇后，应能独立回答：①平台有哪些核心能力组；②每个组件管理什么对象；③控制面与执行面怎样区分；④Registry、Builder、Runtime、Workflow 的关系是什么；⑤权限、观测、计量为什么是横切能力；⑥一个最小平台如何落地；⑦这些组件如何对应 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12 与 F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12；⑧哪些组件可由第三方系统承担。
十四、研究结论
Agent Platform 不是固定数量组件的集合，而是一组围绕 Agent 对象、执行能力与使用者责任边界组织起来的可复用服务职责。 为便于研究，可以将其归纳为接入与体验、定义与开发、控制与生命周期、执行与协作、资源与数据、横切治理与运营六组能力。六组之间共同构成从 Agent 创建、配置、发布、运行到结果交付和持续治理的闭环。
其中，Registry 负责定义与版本，Builder 负责构建体验，控制职责负责版本、权限与运行决策，Runtime 负责实际执行，Workflow 负责跨任务协作，资源目录和资产服务负责外部能力与结果的可复用管理，治理与观测确保整个闭环可控、可追溯。它们可以合并部署，也可以通过外部服务组合，不要求一开始建设完整微服务体系。
对实际工程最重要的是先确定平台对象与组件责任，再设计接口与数据关系，最后根据规模和隔离需求决定部署边界。下一专题将从“组件有哪些”进入“这些组件如何在平台整体架构中协同运行”。
附录 A：参考文献与原始资料
以下优先列出可核查的官方技术文档，用于支撑有关控制器、执行引擎、平台 API、可观测性和授权模型的相关技术事实与工程类比。本文的六组能力分类和最小平台模型属于知识库提出的综合分析框架，不能将其误认为这些来源共同发布的 Agent Platform 标准。由于本篇未实时访问并逐条核验全部页面，涉及具体产品当前版本的功能应在后续案例研究中另行验证。
- Kubernetes Documentation, Controllers：kubernetes.io/docs/concepts/architecture/controller （控制与期望状态的工程类比）。
- Kubernetes Documentation, API Overview：kubernetes.io/docs/reference/using-api （资源对象与平台接口设计的工程参考）。
- LangGraph Documentation, Overview：docs.langchain.com/oss/python/langgraph/overview （Agent / Workflow Runtime 及状态管理相关机制）。
- OpenAI Agents SDK Documentation：openai.github.io/openai-agents-python （Agent、工具与执行抽象的技术参考）。
- OpenTelemetry Documentation：opentelemetry.io/docs （分布式追踪、指标与日志的标准化参考）。
- Open Policy Agent Documentation：www.openpolicyagent.org/docs （策略决策与执行边界的技术参考）。
- OWASP, Top 10 for LLM Applications：genai.owasp.org/llm-top-10 （LLM/Agent 集成风险的安全参考）。
- CNCF Cloud Native Glossary：glossary.cncf.io （平台与云原生基础概念的术语参考）。
附录 B：研究证据、验证声明与适用边界
研究性质： 本篇是平台组件的概念建模、职责划分与工程设计研究，不是对某一厂商现有产品的功能审计。组件总表、对象关系、Studio 场景、MVP 分阶段方案与 JSON 契约均为参考模型或教学示例。
已核验范围： 已对照本知识库 v1.3 既定 Fundamentals 目录，以及 P1 - P2 - P3 - P4 - P5 - P6 - P7 - P8 - P9 - P10 - P11 - P12、F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 的名称和顺序进行内部一致性检查；已检查本文逻辑组件、对象和跨章节边界的表述。未执行实时网页资料核验、生产部署、API 调用、负载测试或安全渗透测试，因此不声称这些示例已在真实系统中得到验证。
适用条件： 本文适用于需要复用 Agent 定义、运行和治理能力的内部或外部平台。单场景 Agent 应用可能不需要完整平台化；小规模平台可以单体部署；复杂多租户平台应根据数据敏感性、规模与合规要求追加独立隔离、计量和治理能力。
下一篇： 03 · Agent Platform 如何运行？ - Platform Architecture。下一篇将聚焦控制面、执行面、平台服务与外部使用者之间的端到端交互机制，而不重复本篇的组件清单。