Dataiku Agent Management 上线前，企业怎么盘点 AI Agent？2026 清单

Dataiku Agent Management 计划于 2026 年 10 月正式开放，但你不必等工具上线：先建跨平台 AI Agent 清单，指定业务负责人并按实际影响分级，再核对监控、认证和复核证据。适用于 Agent 分散在多个平台或自建环境、需要确认责任与风险的团队；产品能提供运行可见性，不等于能替你控制执行权限或隔离环境。

平台工程师：负责发现 Agent、登记来源，并设计持续更新流程。
安全与 AI 治理负责人：优先处理接触敏感数据、面向客户或可能触发交易的 Agent。
研发与业务负责人：为每个 Agent 说明用途、所有者，以及继续运行或暂停的依据。

Dataiku Agent Management 上线准备，先把“看得见”与“管得住”分开

截至 2026 年 9 月 26 日核对的官方资料显示，Dataiku 于 9 月 24 日宣布 Agent Management 为独立产品，计划在 2026 年 10 月正式开放；具体开放日期及届时支持范围仍待官方更新。官方公告列出 AWS Bedrock、Databricks Agents、Google Vertex、Microsoft Copilot Studio、Azure Foundry、Salesforce Agentforce、Snowflake Cortex 和 Dataiku 等平台，并称支持通过 OpenTelemetry 覆盖自定义环境。这是厂商披露的接入范围，不应被理解为所有框架、版本或自建 Agent 都已验证兼容。公告还称，产品按实例收取年度访问费用，监控按 Agent 计量；未提供可供本文核验的具体报价。(Dataiku 官方公告)

对采购判断而言，你应先确认计量边界、Agent 数量如何计算、未监控项目是否计费，再拿正式报价与内部清单核对，而不是根据功能介绍推算预算。

跨平台盘点容易遗漏，不只是因为工具多。每个平台可能只看到自己托管的 Agent；自建项目的遥测可能未接入；单一账号的归属也未必代表业务责任人。更关键的是，监控信号记录的是系统活动，不会自动证明业务结果正确、代码通过测试，或 Agent 的权限已经收敛。OpenTelemetry 的可观测性依赖应用或组件实际发出遥测信号，因此没有插桩或信号缺失的环境不能仅凭“接入计划”视为已覆盖。(OpenTelemetry 插桩说明)

平台工程师：为每个 Agent 建立可核验的资产记录

把 AI Agent 资产盘点当作持续维护的配置清单，不要只在采购或审计时临时补表。Dataiku 的产品博客将 Agent 清单、运行表现和风险记录描述为产品能力；这属于厂商说明，不是对你现有环境的独立验证。(Dataiku 产品博客)

每条记录至少要回答：它是谁、在哪里运行、连接什么、由谁维护、信息从哪里来。对 API 扫描不到的自建环境，指定人工登记人和下一次核验条件；不要将“平台列表中出现”直接等同于资产完整。

• [ ] 为 Agent 分配稳定标识，并登记名称、当前版本或配置标记。
• [ ] 记录运行平台、部署环境和具体工作负载位置；自建或暂未接入的环境单独标记。
• [ ] 列出数据连接、模型来源、外部工具和可执行操作，注明信息来源。
• [ ] 记录首次登记人、最近核验人和核验状态；发现信息过期时，指定补齐责任人。
• [ ] 将“未发现”“无法接入”和“尚未人工确认”分成不同状态，避免把未知误写成零。

OpenTelemetry 可统一收集 traces、metrics 和 logs，但能收集到哪些内容，取决于 Agent 的插桩方式和环境实际暴露的数据。它是遥测基础设施，不是自动发现一切 Agent 的证明。

业务与研发负责人：分开登记所有权、用途与运营责任

一个常见治理误区，是把“谁创建了 Agent”或“它属于哪个平台账号”直接填成业务所有者。创建团队可能已离开项目，运营团队可能负责告警却无权决定业务是否继续使用。把这几种角色合并，出问题时就容易出现没人能批准停用、没人能解释数据使用目的的空档。

对每个 Agent，分别记录业务所有者、创建或开发团队、日常运营负责人和受影响的使用对象。业务负责人说明预期用途和继续运行的理由；运营团队负责异常处置；开发团队维护实现和配置。如果用途已经偏离原设计，先由业务负责人重新确认，再决定是否进入下一阶段。

NIST 的生成式 AI 风险框架强调结合组织情境管理风险，而不是用一组脱离业务的通用标签替代判断。你可以用它梳理“治理、识别、衡量、管理”等工作，但最终的接受门槛仍须由本企业结合用途、责任和证据定义。(NIST 生成式 AI 风险框架)

安全与治理负责人：把高影响 Agent 排在复核队列前面

优先级不该只看 Agent 是否使用新模型，而应看它能触及什么、能造成什么后果。先挑出面向客户、处理敏感数据、可写入系统、能够执行交易或触发不可逆操作的项目。记录数据范围、外部工具、权限类型、副作用和人工审批位置，再据此决定复核深度。

OWASP 对过度自主与过度权限的风险说明，Agent 可用工具太多、权限超出用途或在高影响动作前缺少人工审批，都可能扩大失误影响。因此，“厂商标记为低风险”不能代替你对实际权限和数据流的审查。(OWASP Agent 安全清单)

• [ ] 只读与写入权限分开记录，并核对凭据实际能访问的资源。
• [ ] 对发送、删除、付款、发布等高影响动作，标出审批人和审批发生的位置。
• [ ] 检查 Agent 是否拥有用途不需要的工具、连接或数据访问权。
• [ ] 将无明确所有者、用途已变更或无法说明审批边界的项目设为待确认。
• [ ] 证据不足时，暂停高影响操作或收紧权限，补测通过后再复核放行。

风险等级要依照企业规则和能复核的证据确定。NIST 的 Playbook 提供的是自愿采用的建议行动，并非要求各组织照单执行的统一认证清单。(NIST AI RMF Playbook)

运行与交付团队：监控信号不能替代验收

监控回答的是“运行时发生了什么”，交付验收回答的是“这个版本是否按预期工作、能否安全交付”。两者相关，但证据不能混用。遥测可以暴露错误、调用变化或成本异常；它本身不能证明业务结果准确、回归测试通过，或权限变更经过批准。

每个重点 Agent 都要写清楚：健康状态、使用情况、成本、质量和行为变化分别取自什么数据；缺数据时由谁检查、多久复核以及采取什么处置。OpenTelemetry 将 traces、metrics 和 logs 作为不同类型的信号；你可以据此检查观测覆盖，但不能仅凭“有日志”就宣布监控充分。(OpenTelemetry 信号说明)

对于数据缺失，先确定人工核验路径：谁能确认 Agent 仍在运行、谁会检查业务结果、异常时谁有权暂停。对于版本或配置变更，要求重跑与风险相关的测试；没有新测试证据的高影响变更，不应沿用旧认证结论。

FAQ：把盘点边界说清楚

上线准备清单应包含哪些信息？

先登记 Agent 标识、负责人、用途、运行平台与环境、数据连接、模型和工具依赖，再补充信息来源及最后核验状态。官方支持范围可以帮助你判断潜在接入方式，但不能证明自建环境已经被发现。对无法自动核验的条目，明确人工确认人和补齐动作。

如何避免把平台账号当成 Agent 的业务负责人？

分别确认业务所有者、创建团队和日常运营负责人。业务所有者解释目标与继续运行的依据，运营负责人承担告警和故障处置，开发团队负责实现和配置。缺少任何关键角色，或业务用途无法复述时，将记录设为待确认，而非默认放行。

哪些 Agent 需要先做风险分级和认证？

先看影响面，而不是先看供应商标签：处理敏感数据、面向外部用户、写入业务系统或能够触发交易的 Agent 应优先复核。留存权限、工具、副作用、人工审批、测试结果和责任人；若证据不足，限制高影响操作或暂停相关能力，再补测和复核。

监控覆盖了 Agent，是否就完成执行环境验收？

没有。可观测性说明你收集到了某些运行信号，不代表执行权限最小化、不同任务彼此隔离，也不代表交付结果正确。环境验收还要检查凭据边界、网络和数据访问、审批策略、版本变化及回归测试；缺少这些证据时，应明确标出未验收部分。

平台、安全与审计负责人：让认证证据跟着版本走

重点 Agent 需要的不只是一个“已认证”状态，还要能追溯它依据什么通过。至少留存适用风险、核验范围、测试结果、批准人、复核责任人和对应的版本或配置标记。若工具权限、提示策略、数据连接或执行环境改变，旧证据可能不再适用，应触发重新评估。

把无法提供足够证据的项目写成具体处置：限制操作范围、撤销非必要写入权限、暂停交易能力，或在测试环境补测。不要让“待治理”成为没有负责人、没有期限、也没有临时控制的长期状态。

FinOps 与技术管理者：按风险、成本和价值排治理顺序

把用量、成本、业务价值和风险放进同一轮审查。优先追问三类项目：没有明确责任人的 Agent；影响高但缺少认证或复核证据的 Agent；成本来源和业务收益都解释不清的 Agent。厂商披露了按实例年度计费、监控按 Agent 计量，但企业预算仍需结合正式报价、实际登记范围和计费定义核验。

如果你还没有统一清单，就先抽取一批重点业务 Agent，核对登记信息与实际运行情况，再估算后续治理工作量。不要从厂商的功能描述直接推算节省金额、执行环境容量或自动覆盖比例；这些判断需要你自己的用量和测试证据。

最后要把“管理记录”和“执行控制”放在不同层面验收。你可以用清单发现缺口、用遥测观察变化、用认证材料说明复核过程；但要限制 Agent 能做什么，仍需检查实际凭据、工具权限、审批规则和运行隔离。若目前依赖各平台各自的控制台和人工表格，常见代价是视野分散、责任难追、核验重复；但它们未必都该被立即替换，已有且有效的本地权限与隔离机制仍应保留。

如果清单暴露出 Agent 执行边界说不清，下一步应先补部署与隔离环境验收，而不是先采购新的监控层。对于涉及真实 macOS 工具链构建或交付测试的项目，再比较本地 Mac 与临时远程 Mac 环境是否合适；长期稳定重负载、必须连接专用物理设备的工作未必适合租赁。需要短期验证 macOS 工作流时，可将 vmzig 的 Mac 租赁作为候选方案之一，并先确认环境、权限和交付要求是否匹配。

最后更新于 2026 年 9 月 26 日；开放时间、平台接入范围、计费方式与产品功能核对自 Dataiku 官方公告和产品博客。风险治理与遥测边界另参考 NIST 生成式 AI 风险框架、NIST AI RMF Playbook、OpenTelemetry 插桩与信号说明，以及 OWASP Agent 安全清单。

常见问题

Dataiku Agent Management 开放前，盘点记录要先准备什么？

先为每个 Agent 建立可持续更新的记录：唯一标识、用途、业务所有者、运营团队、运行平台、部署环境、数据连接、模型与工具依赖，以及信息来源和最近核验状态。把尚未查清的项目标为待确认，并记录谁负责补齐；不要因为平台暂时无法接入，就把它从清单中删除。

跨平台部署的 Agent，负责人和业务用途怎么登记才不混淆？

把创建者、平台账号归属、业务所有者和日常运营团队分开记录。业务所有者说明 Agent 为什么存在、服务谁以及继续运行的依据；运营团队负责监控和故障处置。若无人能确认用途或责任人，先列入待确认，不要默认批准上线或继续高影响操作。

哪些 Agent 应优先做风险分级和认证复核？

优先检查面向客户、访问敏感数据、能够写入业务系统或触发交易的 Agent。留存其权限范围、可调用工具、副作用、人工审批点、测试结果和复核责任人。风险等级应按企业自己的影响标准和证据确定；厂商的风险提示可作为线索，不能替代企业认证。

Agent 的监控记录能证明权限受控或执行环境隔离吗？

不能。运行遥测可以帮助你观察调用、错误、成本或行为变化，但不能单独证明 Agent 只有最小权限、审批无法绕过、任务结果正确，或进程运行在隔离环境中。权限策略、审批配置、环境边界和交付测试要分别留存证据，并在配置或版本变化后重新核验。