01 · Agent Platform 是什么？它如何工作？ - Fundamentals - 章节概述与研究导读
所属知识库：Agent 全栈技术地图
所属领域：04 · Agent Platform
所属章节：01 · Agent Platform 是什么？它如何工作？ - Fundamentals
文档类型：章节概述 / 研究导读 / 专题导航
版本：v1.3
更新日期：2026 年 11 月 1 日
核心问题：如何建立对 Agent Platform 的统一认识，理解其边界、组成、运行机制、类型、对象生命周期与架构设计原则，并为后续技术架构、产品架构和工程实践建立共同的概念基础？
专题导读
本篇属 Agent Platform。本章是第四领域的概念基础。前三个领域已经分别研究 AI 的模型能力、Agent 的自主行动机制、Agent System 的执行与治理；本章进一步回答：当开发者希望持续创建、复用、交付和管理多个 Agent 或 Agent System 时，为什么需要平台？平台与具体 Agent System 的关系是什么？平台究竟管理哪些对象，又通过什么机制使开发、运行和使用形成闭环？
本章不直接展开控制面 API 的详细实现、多租户数据库隔离方案或可视化编辑器的组件设计；这些属于后续 Technical Architecture、Product Architecture 与 Engineering & Practice。这里首先建立可供后续专题共同使用的概念、对象模型和判断标准。
本章沿用 v1.3 已确定的六个专题及其顺序：Definition & Boundaries、Core Components、Platform Architecture、Platform Types、Lifecycle Management、Design Principles。
一、本章的定位与学习成果
1.1 与前三个领域的关系
| 领域 | 研究单位 | 关注点 | 本章如何衔接 |
|---|---|---|---|
| 01 · AI | 模型与推理调用 | 智能能力从何而来 | 平台管理模型接入与使用，而非重新解释模型训练 |
| 02 · Agent | Agent 定义与行为 | 单体如何执行任务 | 平台让 Agent 可以被创建、配置、版本化与复用 |
| 03 · Agent System | 可执行系统 | 任务编排、执行、可靠性与治理 | 平台将系统能力包装为多用户可管理的服务 |
| 04 · Agent Platform | 平台产品与服务 | 开发、运行、交付、治理的统一入口 | 本章定义平台及其核心工作方式 |
关键边界：Agent Platform 不必自己实现所有 Agent 推理与编排算法；它可以集成现有 Agent Runtime 或 Agent System。反过来，一个成熟 Agent System 即使有管理后台，也不自动等同于具备可复用、可供多项目使用的平台能力。是否称为平台，应结合其可服务对象、能力复用、治理边界和实际产品范围判断，而非凭界面数量判断。
1.2 完成本章后应能够回答的问题
- 给出可操作的 Agent Platform 工作定义，并解释它与 Agent、Agent System、Agent Builder、Agent Harness 的边界。
- 识别平台的核心构成，以及控制面、执行面、开发服务、开放接口与产品界面的关系。
- 追踪从 Agent 创建到执行结果交付的典型端到端路径。
- 依据主要用户、平台职责、部署方式和开放程度比较不同平台类型，而不将类型误认为互斥分类。
- 区分 Agent Definition、Version、Deployment、Instance、Run、Workspace、Project、Artifact 等对象及其生命周期。
- 解释平台架构的核心设计取舍，并说明哪些能力必须由可信服务端执行。
二、统一工作定义与研究边界
Agent Platform（本知识库工作定义）：一种面向开发者、团队、平台管理员或终端用户，提供 Agent 及其相关工作流、资源和运行实例的创建、配置、测试、发布、部署、执行、协作、观测、管理和治理能力的软件平台。它通过统一的对象模型、平台服务、执行能力、接口和产品交互，使 Agent 能力能够在多个项目与用户之间被复用和持续运营。
该定义用于本知识库的研究组织，不是行业唯一标准。现实平台可聚焦开发、运行或业务应用中的某一部分；不能用“是否具备全部功能”作为单一的命名门槛。
纳入研究：平台对象模型、能力边界、控制与执行关系、平台类型、跨对象生命周期、平台设计原则及其权衡。暂不展开：具体 SDK 参数、数据库 DDL、前端交互细节、生产部署清单、商业定价模型和具体产品功能比较结论；它们在后续章节研究。
三、六个专题的正式目录与职责
| 编号 | 正式专题名称 | 本专题必须回答 | 主要产出 |
|---|---|---|---|
| 01 | 什么是 Agent Platform？ - Definition & Boundaries | 平台为何存在，与系统及工具的边界在哪 | 工作定义、边界判据、反例 |
| 02 | Agent Platform 由什么构成？ - Core Components | 平台由哪些概念性组成部分构成 | 核心组件图、职责矩阵 |
| 03 | Agent Platform 如何运行？ - Platform Architecture | 用户操作如何触发控制、调度、执行和反馈 | 端到端运行链路、架构视图 |
| 04 | Agent Platform 有哪些类型？ - Platform Types | 如何按职责、用户、部署与开放程度分类 | 多维分类法、选型比较框架 |
| 05 | 平台如何管理各类对象及其生命周期？ - Lifecycle Management | 平台管理哪些实体及状态转移 | 对象模型、生命周期状态机 |
| 06 | 如何设计 Agent Platform 的架构？ - Design Principles | 如何权衡可扩展、安全、可靠和复杂度 | 设计原则、决策记录模板 |
以上标题与顺序遵循 v1.3；六篇专题之间是递进关系，但概念组件、实际部署模块与产品功能不能直接一一对应。
四、理解 Agent Platform 的三种互补视图
4.1 能力视图：平台提供什么
平台能力可按“定义与开发、运行与执行、资源与集成、资产与协作、观测与治理、对外交付”归纳。这些是分析维度，不是要求所有平台必须部署六套独立服务。一个早期单体应用完全可以在同一进程实现其中多项能力。
4.2 架构视图：平台如何协调
用户 / 开发者 / 管理员 / 外部系统
│
产品界面 / API / SDK
│
控制面：定义、配置、版本、授权、部署决策
│ 发布配置 / 执行指令
执行面：运行实例、任务执行、工具访问、状态更新
│ 事件 / 状态 / 产物
平台服务：注册、资源、资产、工作流、观测与治理
│
持久化存储 / 消息与基础设施这是逻辑关系示意，不是规定的网络拓扑。平台服务可能同时服务控制面和执行面，执行面也可能由第三方 Agent Runtime 承担。控制面负责“什么可以运行、由谁运行、使用哪一版、遵守什么策略”；执行面负责“具体任务如何执行并报告结果”。两者的职责划分不意味着必须分成两个微服务。
4.3 对象视图：平台管理什么
| 对象 | 含义 | 典型关联 |
|---|---|---|
| Workspace / Organization | 组织、权限和资源的逻辑边界 | 拥有 Project、成员和配额 |
| Project / Studio | 业务任务与协作容器 | 关联 Agent、Workflow、Run、Artifact |
| Agent Definition | 可编辑的 Agent 逻辑定义 | 生成 Version |
| Agent Version | 可识别、可回滚的定义快照 | 被 Deployment 引用 |
| Deployment | 将特定版本绑定到运行配置与环境 | 产生运行实例或任务 |
| Runtime Instance | 具体的运行承载实体 | 执行一个或多个 Run，依实现而定 |
| Workflow Definition | 工作流定义及其版本 | 发起 Workflow Run |
| Run / Task | 一次可追踪的执行活动 | 产生状态、事件和 Artifact |
| Artifact | 文件、报告、数据集等交付成果 | 关联来源 Run、版本与权限 |
术语提醒：不同平台可能使用 Session、Conversation、Job、Execution 等不同命名，且 Instance 与 Run 的关系并非统一标准。本章先建立概念区分，后续研究必须注明具体实现的映射方式。
五、端到端运行示例：研究报告 Studio
以用户创建一个“行业研究报告 Studio”为例，平台工作可划分为以下阶段：
创建与配置：用户在 Workspace 中建立 Project，选择选题 Agent、调研 Agent、审核 Agent，配置模型、工具和权限。平台保存 Agent Definition、Workflow Definition 及相应版本，并验证配置是否合法。
发布与授权：平台将已验证的版本关联到 Deployment 或可执行配置；用户启动研究前，控制面校验身份、项目权限、预算与运行策略。对于涉及外部写入或高风险动作的任务，可设置审批要求。
调度与执行：控制面创建可追踪的 Run，将任务交给执行面。执行面调用 Agent System 的运行机制完成选题、调研、审核和迭代；平台持续收集状态、事件、耗时、消耗和错误。这里的编排算法属于 03 Agent System 的研究对象，平台侧重点是配置、承载、调度和可见性。
人机协作与交付：当审核节点需要人工确认时，平台记录待办和审批结果；执行完成后，报告文件被登记为 Artifact，并按 Workspace / Project 的访问规则提供预览、下载和版本追踪。
后续运营：管理员可以查看运行记录、调整配额、禁用有问题的 Agent Version 或回滚 Deployment。平台必须区分“撤销未来调用资格”和“停止正在运行的任务”，不能假设修改配置会自动改变所有正在执行的实例。
这条链路用于检验平台职责是否完整，不是对某个已部署 Studio 的测试结果。
六、平台类型：不要把分类维度混为一谈
| 分类维度 | 常见取向 | 选择时关注 |
|---|---|---|
| 主要职责 | 开发平台 / 运行平台 / 应用平台 | 平台主要为谁解决什么问题 |
| 开发方式 | 代码优先 / 低代码 / 可视化优先 | 可扩展性、门槛与可调试性 |
| 部署方式 | 托管 SaaS / 私有部署 / 混合 | 数据边界、成本与运维责任 |
| 服务对象 | 个人 / 团队 / 企业 / 平台开发者 | 权限、协作、治理与 API |
| 开放程度 | 封闭集成 / 开放 API / 插件生态 | 集成成本、迁移与锁定风险 |
同一产品可以同时属于多个类别。分类目的是比较产品能力和架构取舍，而非给平台贴单一标签。专题 04 将建立统一比较维度，并用官方资料核对具体案例。
七、对象生命周期：本章最关键的共同基础
7.1 区分四类变化
- 定义变化：Agent 的指令、模型、工具、技能或工作流定义被编辑。
- 版本变化：某个定义形成不可变或可追溯的版本快照。
- 部署变化：运行环境选择并激活某个版本及资源配置。
- 执行变化：某次 Run 从创建、排队、运行、等待审批到完成、失败或取消。
这四类变化具有不同的授权、审计和回滚语义。不能把“编辑 Agent”“发布 Agent”“启动 Agent”当作同一操作，也不能把“删除定义”简单等同于“删除历史运行记录”。
7.2 建议的最小状态示例
Agent Definition: Draft → Validated → Versioned
Agent Version: Created → Published → Deprecated → Archived
Deployment: Pending → Active → Updating / Rolling Back → Retired
Run: Created → Queued → Running ↔ WaitingForInput → Succeeded / Failed / Cancelled以上状态机是设计示例，不是行业通用协议。实际系统还需要定义非法转移、幂等键、并发更新、审计事件和失败恢复。对于取消、超时与外部副作用，应明确“请求取消”与“执行已终止”并非必然同时成立。
八、架构设计原则与典型取舍
| 原则 | 设计关注点 | 需要避免的误区 |
|---|---|---|
| 职责分离 | 定义、部署、执行、观测边界清楚 | 误认为必须微服务化 |
| 可复用与可组合 | Agent、Workflow、资源可跨项目复用 | 共享对象缺少权限与版本约束 |
| 明确租户边界 | 数据、密钥、配额、执行隔离 | 仅在前端隐藏资源 |
| 可追踪性 | 版本、Run、事件、产物具有关联标识 | 只有聊天记录没有执行证据 |
| 安全默认 | 最小权限、凭据隔离、审批与审计 | 依赖 Prompt 作为权限控制 |
| 渐进式复杂度 | 从单租户 MVP 向团队化演进 | 为假设规模提前堆叠复杂设施 |
| 可替换性 | 模型、工具、Runtime 通过清晰接口集成 | 假设所有供应商能力完全等价 |
| 可靠交付 | 幂等、恢复、失败处理、产物一致性 | 把任务成功等同于报告可用 |
设计原则并非无代价：隔离增强可能提高资源成本；高可配置性会增加测试组合；开放扩展会扩大攻击面；强一致性与高吞吐之间可能需要权衡。专题 06 将把原则转化为可记录的架构决策，而非口号。
九、与后续三章的知识交接
| 本章产出 | 后续专题承接 | 需要进一步细化的内容 |
|---|---|---|
| 控制面与执行面逻辑边界 | P1、P2 | API、事件、任务派发与故障边界 |
| Agent 定义、版本与部署模型 | P3、P5 | 注册、版本不可变性、部署与运行管理 |
| 开发能力与资源依赖 | P4、P7、P9 | Builder 服务、模型工具接入与插件扩展 |
| 开放能力与数据资产 | P8、P10 | SDK 契约、资产元数据与权限 |
| Workspace、租户及治理边界 | P11、P12 | 组织隔离、授权、审计、配额 |
| 用户任务与交付链路 | F1 - F2 - F3 - F4 - F5 - F6 - F7 - F8 - F9 - F10 - F11 - F12 | 具体产品功能、交互和角色权限 |
| 架构取舍与验收指标 | Engineering & Practice 01 - 06 | 技术选型、MVP、部署与测试 |
避免重复的写作规则：Fundamentals 解释“是什么、为什么、概念关系”；Technical Architecture 解释“内部怎样实现”；Product Architecture 解释“用户如何完成任务”；Engineering & Practice 解释“如何设计、构建、验证并运营”。对于跨章主题，允许引用但应明确不同研究视角。
十、研究方法、证据标准与专题验收
10.1 研究顺序
按 v1.3 正式目录依次完成六篇：01 Definition & Boundaries → 02 Core Components → 03 Platform Architecture → 04 Platform Types → 05 Lifecycle Management → 06 Design Principles。完成每篇后维护术语表、对象关系表和跨专题引用，避免后续文章改变已定义术语却未同步更新。
10.2 每篇专题的研究要求
每篇至少包括：明确问题与适用边界；核心定义和概念辨析；必要的结构图或流程；主要机制与设计取舍；Studio 贯穿案例；常见误区与反例；可检验的研究结论；参考资料及证据/验证声明。涉及特定产品功能或 API 行为时，应优先引用对应版本的官方文档；设计示例应与已验证实现明确区分。
10.3 本章完成标准
- 六篇专题均与 v1.3 正式名称和编号一致。
- 能用同一对象模型解释创建、版本、部署、执行、产物与权限关系。
- 能说明平台与 Agent System 的边界，且不把控制面、执行面误写成固定部署方案。
- 能对不同平台按多个维度分类，并说明分类不是互斥集合。
- 能为后续 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 System 能力转化为可复用、可管理、可持续交付的平台能力，而不是简单增加一个可视化界面。第二，平台必须从能力、架构与对象三个视图同时理解，避免将产品功能直接等同于部署服务。第三，控制面与执行面是重要的职责分离，但不规定唯一的物理架构。第四，平台类型是多维度、可组合的，不能以单一产品形态定义整个领域。第五，定义、版本、部署、实例、执行和产物的生命周期必须区分，才能保证权限、审计、回滚和运营管理语义清晰。第六，平台设计应在复用、安全、可靠、可扩展与实施复杂度之间作明确取舍，并将这些取舍传递给后续技术、产品和工程专题。
附录 A：参考文献与原始资料
以下为后续六篇专题的优先参考入口。本篇是知识体系概述；这些资料是可核验的官方来源，不意味着已逐项实测所有产品当前版本的功能。
- [R1] Kubernetes - Cluster Architecture：kubernetes.io/docs/concepts/architecture
- [R2] Kubernetes - Controllers：kubernetes.io/docs/concepts/architecture/controller
- [R3] OpenTelemetry - Documentation：opentelemetry.io/docs
- [R4] OpenAI Agents SDK - Documentation：openai.github.io/openai-agents-python
- [R5] LangGraph - Overview：docs.langchain.com/oss/python/langgraph/overview
- [R6] Temporal - Documentation：docs.temporal.io
- [R7] Model Context Protocol - Documentation：modelcontextprotocol.io
- [R8] Dify - Documentation：docs.dify.ai
- [R9] NIST AI Risk Management Framework：www.nist.gov/itl/ai-risk-management-framework
- [R10] OWASP - GenAI Security Project：genai.owasp.org
附录 B：研究证据、验证声明与适用边界
目录依据：本章的六个专题标题、编号与顺序直接来自用户确定的《Agent 全栈技术地图》v1.3 目录。领域定位、对象示例和研究衔接参考同版本《04 · Agent Platform - 领域概述与研究总纲》。
研究性归纳：平台工作定义、能力视图、逻辑架构、对象清单、示例状态机和设计原则属于用于知识组织与工程讨论的综合模型，不构成行业唯一标准或具体产品的正式接口规范。
验证声明：本章没有部署 Agent Platform，没有执行 API、权限、性能、隔离、可靠性或端到端验收测试；Studio 流程为解释性案例，不能视为已经验证的生产实现。官方参考资料仅列为后续专题核验入口。
适用边界：适用于 Agent 开发平台、运行平台及应用平台的概念研究、架构沟通与学习规划；不同规模、监管要求、部署方式与商业目标下，平台所需功能和实现复杂度会不同。