Agent Product 101｜13｜Platform：从单个 Agent 到系统能力

Agent Platform 的核心不是堆更多 Agent，而是把创建、连接、运行、权限、评估、监控、发布、治理和生命周期变成可复用的平台能力。

核心结论

Agent Platform 不是“有很多 Agent 的产品”，而是让组织能够持续创建、连接、运行、评估、发布、监控和治理 Agent 的产品系统。

单个 Agent 解决的是一个任务。Agent Platform 解决的是一类能力如何规模化：

谁能创建 Agent。
Agent 能连接哪些系统。
运行时如何隔离和监控。
权限和策略如何统一管理。
质量如何评估和回归。
发布、版本、回滚、下线如何完成。
管理员如何治理风险。

对产品经理来说，Platform 的判断标准不是“我们有几个 Agent”，而是“每新增一个 Agent，是否能复用同一套 builder、connector、runtime、policy、monitoring、evaluation 和 lifecycle”。

读者收益

这一章帮助你判断三件事：

你的产品现在是单点 Agent，还是已经具备平台雏形。
平台能力应该先做 builder、connector、runtime、policy、monitoring，还是 marketplace。
企业 Agent 平台为什么必须从治理和生命周期开始，而不是只做一个低门槛搭建器。

从 Agent 到 Platform，变化在哪里

一个单点 Agent 可以靠一个团队、一个场景、一套 prompt、几个工具连接跑起来。但平台化之后，问题会完全不同。

维度	单个 Agent	Agent Platform
创建方式	团队手工配置	用户或组织可创建、复制、模板化
工具连接	点对点集成	connector 体系和权限管理
运行环境	为单一场景优化	多 Agent、多租户、多环境运行
质量保障	手工测试	eval、版本、灰度、回归
权限治理	单点判断	identity、policy、approval、audit
监控运营	看单次任务	看 Agent 组合、使用、失败和风险
生命周期	上线后继续改	创建、测试、发布、回滚、下线

平台化的本质是：把过去每个 Agent 都要重新解决的问题，沉淀成共享能力。

一个 PM 可用的 Agent Platform 模型

可以把 Agent Platform 拆成七层能力。

1. Builder：谁来创建 Agent，如何创建

Builder 不只是一个表单，也不是只让用户写 prompt。它需要帮助创建者定义：

Agent 服务的用户和任务。
输入入口和触发条件。
可使用的数据和工具。
允许执行的动作。
需要停下来的风险点。
输出产物和验收方式。
失败和升级路径。

PM 要警惕“低门槛创建”的幻觉：如果创建器只收集名称、描述和提示词，它创建的往往不是可运营 Agent，而是不可治理的自动化片段。

2. Connector：Agent 连接世界的方式

Agent 的价值通常来自连接真实系统：Slack、GitHub、Jira、Notion、Google Workspace、CRM、数据库、内部 API、支付、邮件、工单、BI。

Connector 层的产品问题包括：

问题	PM 需要定义
连接什么	系统、对象、字段、动作范围
谁授权	用户授权、管理员授权、服务账号
授权多久	一次性、任务级、长期、可撤销
能做什么	读、写、创建、发送、删除、发布
怎么审计	记录调用、结果、操作者、审批

没有 connector 治理，Agent 平台会变成一堆危险的 API 快捷方式。

3. Runtime：Agent 在哪里、以什么边界运行

Runtime 决定 Agent 是否可控。它要处理：

任务排队和并发。
长任务状态。
工具调用限制。
超时和重试。
sandbox 或隔离环境。
成本和资源预算。
多用户、多团队、多租户边界。
失败恢复和任务恢复。

PM 不需要设计底层架构，但必须定义用户可感知的运行边界：任务是否在后台跑、是否能取消、是否能恢复、是否会通知、是否会影响生产系统。

4. Policy：权限、审批和风险策略

平台越开放，越需要统一策略。否则每个 Agent 都会自己决定哪些动作能自动执行，最后风险不可控。

Policy 层至少要回答：

哪些系统只能读不能写。
哪些字段或动作需要审批。
哪些用户能创建、发布、连接、下线 Agent。
哪些数据不能进入模型上下文。
哪些任务只能在特定环境中运行。
哪些异常会触发降级或人工接管。

5. Evaluation：平台如何知道 Agent 质量可发布

平台不是让任何 Agent 都直接上线。它需要质量门槛：

创建阶段的测试任务。
发布前 eval。
失败样本回归。
工具调用正确性检查。
权限决策检查。
高风险任务模拟。
用户反馈进入改进循环。

Agent 平台的评估不能只测回答对不对，还要测能否按权限、流程、证据和恢复路径完成任务。

6. Monitoring：上线后如何持续运营

Monitoring 不是只看系统健康，还要看产品健康：

哪些 Agent 被使用。
哪些任务完成率高。
哪些任务经常阻塞。
哪些工具最常失败。
哪些权限请求最常被拒绝。
哪些 Agent 产生最多人工接管。
哪些 Agent 触发了策略或审计风险。

平台 PM 要把监控从“工程可用性”扩展到“任务交付质量”和“组织风险”。

7. Lifecycle：版本、发布、回滚、下线

Agent 是会变化的产品对象。模型会变，prompt 会变，工具会变，权限会变，业务规则会变。

因此平台必须支持：

草稿和已发布版本。
测试环境和生产环境。
版本差异说明。
发布审批。
灰度或分组发布。
回滚。
下线和迁移。
owner 变更和过期清理。

没有 lifecycle，Agent 越多，组织负债越大。

从真实产品看 Platform

Microsoft Copilot Studio：企业 builder + connector + governance

Copilot Studio 的启发是：企业 Agent 平台不能只有创建器。它必须和身份、连接器、环境、发布、监控、安全策略结合，否则企业不敢让业务人员创建可行动的 Agent。

PM 启发：低代码 builder 的终点不是“人人都能建”，而是“人人能在组织允许的边界内建”。

Salesforce Agentforce：平台价值来自业务对象和治理

Agentforce 把 Agent 放在 CRM、Data Cloud、Flow、MuleSoft 等业务基础设施之上。它的重点不是聊天，而是让 Agent 能围绕客户、销售、服务、营销等业务对象行动。

PM 启发：企业 Agent 平台要先找到业务对象。没有业务对象，Agent 只能聊天；有了业务对象，Agent 才能进入流程和结果。

Slack Agents：平台入口在团队协作上下文

Slack 的 thread、channel、workflow、通知和审批，本身就是团队协作的任务表面。Agent 如果能进入这些表面，就不需要用户离开原工作流。

PM 启发：平台不一定从独立控制台开始，也可以从用户每天所在的协作空间开始。

v0 / Replit：App Builder 平台要围绕项目生命周期

App Builder 的平台能力不只是生成页面，还包括 project、preview、environment、deployment、rollback、collaboration、template。用户最终买的不是代码片段，而是从想法到可运行应用的路径。

PM 启发：垂直 Agent 平台要围绕交付物生命周期，而不是围绕模型对话能力。

Hermes Agent：个人自动化平台来自记忆、工具和技能积累

个人 Agent 的平台化不一定是企业管理后台，也可能是用户自己的工作系统：记忆、技能、工具、定时任务、委托、跨应用动作逐步积累。

PM 启发：个人平台的核心是可持续积累，而不是一次性完成任务。

产品判断表：你需要平台吗

当前状态	是否需要平台化	优先补什么
只有一个清晰场景	不急	把单点任务做可靠
多个 Agent 重复接同样工具	需要	connector 和权限复用
多团队都想创建 Agent	需要	builder、模板、发布流程
Agent 已进入业务系统	必须	policy、audit、approval
任务质量难以稳定	必须	eval、monitoring、回归集
Agent 数量快速增长	必须	lifecycle、owner、版本管理

平台化不是越早越好。如果单个 Agent 的任务对象、可靠性和验收方式都没跑通，先做平台只会放大混乱。

平台产品的设计原则

原则一：先沉淀重复能力，再开放创建

如果团队还不知道一个好 Agent 需要哪些字段、权限、评估和监控，就不要急着让所有用户自助创建。

更稳的路径是：

先做几个高质量垂直 Agent。
抽出共用的 connector、runtime、policy、eval。
再做模板和 builder。
最后开放更广泛的创建和发布。

原则二：平台要有默认安全边界

不要让每个创建者自己理解安全策略。平台应该提供默认边界：

默认只读。
默认草稿输出。
默认高风险动作审批。
默认记录审计。
默认限制生产写入。
默认测试后发布。

默认边界越清楚，平台越容易规模化。

原则三：把 Agent 当作有生命周期的产品对象

每个 Agent 都应该有：

owner。
目标用户。
任务范围。
连接器清单。
权限范围。
版本。
发布状态。
监控指标。
评估集。
下线规则。

如果这些信息不存在，Agent 增长越快，治理越困难。

原则四：平台指标要衡量复用和治理，不只看调用量

平台 PM 应关注：

新建 Agent 数量中有多少成功发布。
发布 Agent 中有多少被持续使用。
平均创建到发布时间。
connector 复用率。
eval 通过率。
失败和接管分布。
审批和策略命中率。
过期或无人维护 Agent 数量。
高风险动作拦截率。

平台的成功不是“创建很多”，而是“创建出的 Agent 可用、可控、可维护”。

常见误区

误区一：把平台等同于 Agent 列表

一个页面展示很多 Agent，不等于平台。平台必须提供共享创建、连接、运行、治理和生命周期能力。

误区二：先做 marketplace，后补治理

如果没有质量、权限、版本、审计，marketplace 只会放大低质量 Agent 和组织风险。

误区三：让 prompt 成为唯一配置界面

Prompt 很重要，但不能承载全部产品责任。任务范围、权限、审批、连接器、失败路径、验收方式都应该结构化。

误区四：平台团队只服务开发者，不服务管理员

企业平台至少有三类用户：创建者、使用者、管理员。只优化创建者体验，会让管理员无法接受。

误区五：所有 Agent 使用同一套自主策略

不同任务风险不同。平台应该支持按任务、系统、动作、角色定义不同边界。

产品检查清单

评审 Agent Platform 时，可以问：

平台是否定义了 Agent 这个产品对象的字段、owner、版本和状态？
Builder 是否让创建者定义任务、权限、工具、验收和失败路径，而不只是写 prompt？
Connector 是否有授权、撤销、范围限制和审计？
Runtime 是否支持长任务、隔离、取消、恢复、成本和状态管理？
Policy 是否统一管理读写权限、高风险动作和审批？
Evaluation 是否成为发布门槛，而不是上线后的补救？
Monitoring 是否能看到任务质量、失败原因、接管率和风险事件？
Lifecycle 是否支持草稿、测试、发布、灰度、回滚、下线？
管理员是否能知道组织里有哪些 Agent、连接了什么、在做什么？
平台是否先解决了可复用能力，而不是只做 Agent 数量扩张？

小结

Agent Platform 的价值不在于“拥有更多 Agent”，而在于把 Agent 从一次性功能变成组织可持续使用的能力。

一个成熟平台应该让创建者更容易构建，让用户更放心委托，让管理员更容易治理，让产品团队更容易评估质量，让组织更容易复用已有系统。

下一篇会进入 Autonomy Levels：平台一旦允许更多 Agent 行动，就必须定义不同任务下的授权范围、停顿点、证据要求和责任边界。