Dataiku CEO Florian Douetteau 打了个比方：问一家银行有多少台服务器，答案能精确到小数点；问它在跑多少个 AI Agent，对方只能耸耸肩，或者猜一个数。9 月 24 日，Dataiku 在年度大会上发布独立产品 Agent Management，10 月 15 日正式可用，要回答的就是这个问题。
Dataiku 在产品博客里描述的场景是：营销团队用 Agent 写投放简报，财务团队用另一个对发票，运营团队又上线了三个，它们分别跑在 AWS、Databricks、Google、Microsoft、Salesforce、Snowflake 或自建框架上。Agent Management 自己不搭 Agent，它扫描这些平台，把每个 Agent 的负责人、用途、依赖的模型和工具、活跃用户、成本和风险记录汇进同一张清单。
这张清单能让管理者第一次看全分散的资产。但它汇总的是各平台交出来的数据，各家口径不一，Dataiku 也不接管这些 Agent 的运行。
只有 18% 的组织有完整的 AI 资产清单
Dataiku 在发布稿里引用了 IBM 商业价值研究院的调查：IBM 与迪拜未来基金会在 2025 年第四季度到 2026 年第一季度访问了 1006 名负责 AI 战略、交付或治理的高管，只有 18% 表示所在组织维护着完整、最新的 AI 资产清单。这个口径覆盖所有 AI 系统，不只统计 Agent，它说明的是企业普遍看不清自己的 AI 资产，并不能证明 Dataiku 的产品已经解决了这个问题。
产品的接入方式决定了它能看到多少。按产品页的说明，Agent Management 通过各平台的原生 API 和日志流接入，用户选好平台、完成认证，系统就自动扫描并登记 Agent；自建环境走 OpenTelemetry（一套开源的遥测数据标准）。它不在 Agent 和用户、工具之间转发请求，也不替 Agent 做决定，所以原有应用不用为接入而改写。
代价是清单的边界由权限决定。所谓“所有 Agent”，实际是连接器有权访问的账户、项目和环境里的 Agent。没接入的平台、权限之外的环境，以及没有按约定输出遥测的自建 Agent，都可能留在账外。产品页自己也写明，接入深度取决于各平台开放了什么。
六个平台公开的接口，能交出的字段各不相同
Dataiku 没有公开每个连接器的字段映射。下表对照的是各平台目前公开的管理和遥测接口，不等于 Dataiku 已经实现的能力，用来说明跨平台汇总要面对的原始差异。
| 平台 | 公开接口能提供什么 | 影响统一口径的条件 |
|---|---|---|
| AWS Bedrock | ListAgents 返回名称、状态、版本和 Guardrail 配置；AgentCore 把轨迹和指标送进 CloudWatch |
AgentCore Runtime 上的 Agent 自动插桩，运行在别处的 Agent 要自己配置 OpenTelemetry；清单和运行轨迹来自不同接口 |
| Databricks | MLflow Tracing 记录每一步的输入、输出、延迟、Token 用量和成本 | 数据深度取决于框架自动插桩或手工埋点，没覆盖的步骤不会出现 |
| Google Agent Platform | 内置指标包括请求数、容器 CPU 和内存分配时间 | 工具调用次数等指标要自己写日志生成，业务结果更要应用自己提供 |
| Microsoft Copilot Studio | 租户清单列出创建者、发布状态、渠道、身份验证和能力配置 | 清单文档仍属预览，不包含第一代 Copilot Studio 建的 Classic Bot |
| Salesforce Agentforce | Beta 版 OTel API 导出消息、LLM 调用、动作、评分和反馈 | 每次只能查一个会话，只返回 72 小时内开始的会话，并要求启用 Data 360 |
| Snowflake Cortex | 可查询对话、轨迹、工具、Token、延迟和反馈 | 读取需要对该 Agent 有 MONITOR 权限；完整对话和工具输入输出还要账户级的未脱敏读取权限 |
AWS 把 Agent 元数据和运行观测分在两个接口，Google 的默认指标主要反映服务是否可用，Databricks 和 Snowflake 能给到步骤级轨迹，Salesforce 的导出还有 Beta 限制，Microsoft 的清单把旧版 Bot 排除在外。把这些数据放进同一个界面不难，难在证明同名指标可以横向比较。
OpenTelemetry 统一了数据格式，没有统一业务价值
OpenTelemetry 已经为 Agent 调用、规划和工具执行定义了 gen_ai.* 系列 span，不同系统可以用同一种结构传输 Agent 名称、版本、模型、工具和错误信息。截至发稿，这套 GenAI Agent 语义约定仍标为 Development（开发中）。
它记录的是发生了哪次调用、用了什么工具、有没有报错，不定义这次调用给企业创造了多少价值。即使所有平台都稳定输出 Token、延迟和成功状态，客服 Agent、财务 Agent 和代码 Agent 的“一次成功”也是三种不同的业务结果。
Dataiku 的产品页说明，活跃用户按日、周、月从实际轨迹统计，成本由 Token 消耗乘以一张可调整的费率表得出，业务 KPI 由企业自己设定。成本口径可以慢慢统一，价值仍取决于企业怎么定义任务完成、选什么基线、按多长时间归因。没有这些条件，Agent 上线后收入增加或人工时下降只能算同时发生的变化，不能直接记成它的投资回报。
风险证据可以集中，停用要回到原平台
对处理客户、敏感数据或实时交易的高风险 Agent，Agent Management 会保存认证状态、已命名的风险和按计划重跑的测试记录。审计人员问起“谁批准了什么、依据是什么、现在是否仍然合规”，证据已经在一处，不用再翻表格、工单和各平台控制台。
产品页也写清了控制的边界：从 Agent Management 停用 Agent 只支持部分平台；它不在 Agent 和用户之间的流量路径上，运行时控制仍由各平台执行。它适合做监督和证据层，无法对所有 Agent 一键断路。安全团队仍要逐个平台验证停用动作、权限范围、生效延迟和失败后的回滚。
采购前先测清单能找到多少
Dataiku 在 9 月的发布稿里说，产品按实例收年费，监控再按 Agent 计量；官方材料没有给出具体价格、连接器的发现率或跨平台客户案例。企业采购前可以先做四项验收。
平台管理员准备一份已知的 Agent 样本，覆盖不同账户、地区、草稿、已停用实例和自建框架，测出每个连接器能找到多少、字段填得多全。财务和平台团队核对 Token、模型价格、共享基础设施和人工成本怎么分摊，别把可调整的费率表当成真实总成本。安全团队逐个平台演练认证过期、风险升级和停用，记下哪些动作能自动执行、哪些只能发提醒。业务负责人提前定义任务成功、质量门槛和对照基线，再决定哪些指标可以算进投资回报。
Dataiku 把企业 Agent 治理里最先缺的那一层做成了产品：先让分散的 Agent 进同一本账。这本账能不能从“看得见”走到“管得住”，取决于企业能否说清每一行数据从哪来、能比较到什么程度，以及出了问题时谁来按停止键、在哪个平台上按。
