一句话：把智能体塞进主数据，先让底座替它背书
9 月 29 日，主数据管理（MDM）厂商 Stibo Systems 推出 AgentWorkx，一套建在其 STEP 平台之内的智能体框架，同时给出两个由 Stibo 自己造好并维护的现成 Agent。它想说的不是「我们又做了个 Agent 平台」，而是一个更底层的主张：当企业把智能体架在可信数据底座之上、而不是直接另起一套影子 AI 时，Agent 才真正具备规模化落地的信任前提。CEO Adrian Carr 把话讲得很直白——当智能体承担越来越多企业工作量，真正的约束是「底下的数据能不能在机器速度下被信赖」。
为什么值得看：数据底座决定 Agent 能不能被信
过去两年企业 Agent 的叙事，大多从「模型够不够强」「编排巧不巧」起笔。AgentWorkx 的角度反过来了：一个连产品、客户、供应商、地点之间关系都理不清的系统，喂给再聪明的 Agent，产出的也只是指令级的幻觉。Stibo 的逻辑是，它做主数据管理做了很多年，语义数据底座、基于角色的权限、审计、跨域关系这些能力早就就位，而它们恰好是 Agent 跑起来最缺的那块「可信上下文」。于是 AgentWorkx 不重复造轮子，而是把「造 Agent、配 Agent、编排 Agent、治理 Agent」收进同一个框架，让所有智能体都活在 STEP 既有的权限与审计之内。这把「AI 就绪」的回答从「我们买了模型」改成了「我们的数据本来就治理好了」。
机制拆解：两条用 Agent 的路，同一套框架托底
AgentWorkx 给客户两种用法，但底层是同一套框架。其一，直接用 Stibo 造好并维护的现成 Agent：首发的两个分别是 Upload Anything AGT（把结构化和非结构化数据快速灌进平台，把原本要几个月的接入流程压到几天）和 Content Optimizer Agent（用受治理的产品属性与业务上下文生成商品描述、SEO 文案与营销文案）。其二，企业用同一套框架和 Studio 自己搭专属 Agent，去覆盖自家特有的流程，但仍留在 Stibo 平台的权限控制之内。两种用法的差别只在「逻辑由谁写」，治理、角色、审计则是共享的。这种「平台方提供一部分、企业自己写一部分」的分层，恰好踩中了企业怕两头的痛点：全靠厂商怕不合身，全自己写怕失控。
两个现成 Agent 解决了什么
把首发两个 Agent 拆开看，它们解决的都是 MDM 里最磨人的「脏活」。Upload Anything 针对的是数据接入——企业要把散在表格、文档、邮件里的主数据搬进平台，过去靠人工映射和长周期项目，现在交给 Agent 先读懂再结构化。Content Optimizer 针对的是「数据有了但不会用」——产品属性在库里躺着，营销文案却要反复手写，Agent 用受治理的属性直接出稿，保证说出来的每一句都有数据撑腰。两者的共同点是：都不要求客户自己先把底层能力建起来，而是在受治理环境里把 MDM 工作流变成 Agent 体验。用首席产品与增长官 Neda Nia 的话说，话题正从「能不能造出来」转向「能不能信、能不能扩、ROI 能不能证」。
优势与局限：方向对，但边界要讲清
它的长处是把「可信数据」这个常被 Agent 叙事跳过的底座，重新摆回 C 位，并给出「即用 + 自建」两条平滑路径，降低了企业试 Agent 的门槛。局限也同样现实：其一，AgentWorkx 的价值高度绑定 Stibo 既有的 MDM 客户群，对非 MDM 场景的泛化能力尚未经过大规模验证；其二，所谓「受治理」的粒度，仍取决于企业有没有把权限和角色在 STEP 里真正理顺，框架不能替客户补这块欠账；其三，关于客户实际跑起来后每任务的 token 成本、人工接管率与失败回退率，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。它真正的信号是：Agent 落地的信任问题，正在从模型侧往数据底座侧迁移。
结语
AgentWorkx 未必会是最出圈的 Agent 发布，但它点破了一件事——企业 Agent 的竞争，迟早会回到「谁的数据更可信、谁的治理更现成」。当智能体站在理好的认知上工作，而不是每次从头搜，所谓规模化才不至于把幻觉也一起放大。对甲方来说，与其追着 newest 的 Agent 框架换，不如先问一句：我的数据底座，到底有没有替 Agent 背书的资格。