Workday 正在开放其平台，允许开发者在 Claude Code、Cursor 和其他工具中构建自己的 HR 和财务智能体，只要这些智能体遵循与使用它们的人相同的规则。

周二，在拉斯维加斯举行的 Workday Rising 大会上，该公司将其 Trusted Agent（智能体） Platform 变为“无头”模式。

借此，其 Model Context Protocol (MCP) 服务器、对实时 Workday 数据的 SQL 访问，以及智能体的共享运行时现已全面可用，客户可以在来自 Anthropic、Google、Meta、Mistral、Nvidia 和 OpenAI 的模型上运行自己的智能体。

正如 Workday 首席技术官 Gabe Monroy 在活动前的新闻发布会上所指出的：“无论智能体由谁构建，它都在 Workday 的权限、审批和审计跟踪下运行——没有智能体可以走后门。”

Workday 指出，许多公司目前通过数据湖中的副本或服务账户将智能体连接到 HR 和财务数据，但该公司认为，这些方法绕过了那些访问控制（尽管 SAP、Microsoft 等公司肯定会辩称，它们也设置了访问控制）。

MCP 工具、SQL 和共享运行时

对于 AI 开发者来说，进入 Workday 生态系统的主要入口是 Agent-Ready Tools。这是该公司的 MCP 服务器，作为 Workday Extend AI 的一部分提供。用户使用自己的 Workday 凭据登录，Workday 表示，代表他们行动的智能体无法访问他们自己账户无法访问的任何内容。这是这里的一个关键特性，它将智能体直接绑定到用户的账户。

Monroy 表示，该服务器目前提供 275 个读取工具和 54 个写入或删除数据的工具。

Live Data Query 是 Workday Data Cloud 的一部分，允许 BI 工具和智能体直接对 Workday 的数据运行 SQL 查询。Monroy 将其描述为对 Workday 对象图的 JDBC 访问，该公司表示，每个查询只返回请求用户被允许查看的内容。

今天还有三个组件全面可用。Agent Harness 是共享运行时，Workday 自己的智能体以及客户和合作伙伴构建的智能体都在其上运行。它将用户的身份、组织职位和访问权限传递给每个智能体，限制智能体可以做什么，并根据成本和性能选择由哪个模型处理每项任务。Developer Agent 可在 Claude Code、Codex、Cursor 或 Workday Developer Site 中根据自然语言提示生成 Workday 智能体和应用。Custom Agents 允许团队将他们使用 LangChain 或 Google 的 Agent Development Kit (ADK) 构建的智能体部署到 Agent Harness 上，不过 ADK 支持目前仅限于设计合作伙伴。

还有两个部分计划于 2027 年初开放早期访问。Agent Context Service 将仅预加载任务所需的 Workday 数据，Workday 表示这可以加快智能体的速度并限制其接触敏感记录。Grounded Reasoning 将在智能体执行计划操作之前，根据客户的政策、流程规则和 Workday 记录对其进行检查。

Workday 表示，在过去四个月中，客户已使用 Developer Agent 和 Agent-Ready Tools 构建了 500 多个智能体和 6,000 多个应用。

“无头，无法无天的方式”

在简报中，Monroy 演示了他所称的“无头，无法无天的方式”。一个连接到自定义 MCP 服务器的智能体——他说这种设置在 Workday 的客户中如今很常见——返回了其用户无权查看的职位申请，然后在未经批准的情况下将错误的员工在团队之间调动。当指向 Snowflake 中的 Workday 数据副本时，同一个智能体在被问及时输出了 CTO 的薪资。

“当它失败时，不仅仅是一个错误的答案，”Monroy 说，“而是一个没有人批准的错误操作。”

当智能体改为通过 Workday 自己的 MCP 服务器和 Data Cloud 运行，且用户已登录时，同样的查询不出所料地只返回了该用户被允许查看的职位申请（当然，否则那些访问控制演示就没什么意义了）。

“一小部分用例”

当被问及无头对 Workday 是否像对 Salesforce 一样重要时，Workday 产品与技术总裁 Gerrit Kazmaier 表示，Workday 正在给客户选择：“我总是更希望他们使用我们的用户界面，但无头也同样好。”

Kazmaier 指出，直接在 Workday 的工具和 API（应用程序编程接口）上构建智能体“只适用于一小部分不需要 HR 或财务领域逻辑的用例”。对于其他所有情况，他指向了一种 AI 到 AI 的集成，其中 Claude 将请求交给 Workday 的智能体编排器 Sana，然后由 Sana 调用 Workday 自己的领域智能体。

数据湖用于分析，而非用于智能体

值得注意的是，Snowflake 的例子对 Workday 来说有点尴尬。当该公司在 2025 年 9 月宣布 Data Cloud 时，其宣传包括与 Databricks、Salesforce 和 Snowflake 零拷贝共享 Workday 数据。Snowflake 于 10 月 7 日全面推出其 Workday Data Cloud 集成，Databricks 于次日将其用于 Unity Catalog 的 Workday 连接器投入公开测试。

据 Databricks 称，Workday 管理员通过注册一个 Integration System User (ISU) 来设置连接器，这是 Workday 客户用于传统集成的那种系统账户，对共享表具有读取权限。之后，Unity Catalog 在目录、模式和表级别的权限决定谁可以查询数据。

Monroy 表示，数据湖对于分析以及将 Workday 数据与公司其他数据连接起来仍然有意义，但外部数据湖是“构建需要受治理访问 Workday 的智能体的错误场所”。

“你可以导出你的数据，但你不能导出治理数据的规则，”他说，并补充说在数据湖中重建这些规则意味着“维护 Workday 安全模型的第二份副本”，“而一旦它发生偏移，就全错了。”

人人都在失去头脑

无头（Headless）似乎是当下的趋势。例如，Salesforce、ServiceNow 和 Microsoft 已经允许外部智能体（Agent）进入其记录系统。Salesforce 在 4 月的 TDX 开发者大会上推出了 Headless 360，使 Claude、ChatGPT、Cursor 或终端中的智能体能够处理 Salesforce 数据。ServiceNow 于 5 月正式发布其 Action Fabric MCP 服务器，Anthropic 作为发布合作伙伴，Microsoft 则为 Dynamics 365 ERP 提供了 MCP 服务器。

四家供应商均表示，外部智能体仍受其现有权限模型的约束。

智能体使用谁的身份？

在智能体身份方面，不同供应商目前采取了截然不同的方法。

例如，据 Salesforce Ben 报道，Salesforce 正准备让通过 MCP 或其 API 连接的智能体以自己的凭据和权限注册，而非以用户身份行事。MCP 客户端最终需要切换到与这些智能体身份绑定的 OAuth 凭据。

Workday 的文档称，其智能体已经可以拥有最多两个自己的系统账户，称为智能体系统用户（ASU），一个用于代表用户行事，一个用于“环境”工作，每个都有自己的 OAuth 2.0 客户端。当客户开启环境技能时，Workday 会自动创建环境账户。

销售 Workday MCP 集成的 Unified.to 表示，每条 Workday MCP 路径，“无论官方与否”，都始于创建一个 ISU。Cequence 为其 Workday MCP 集成提供的设置指南要求客户创建一个“具有适当安全组”的 ISU。通过 ISU 工作的智能体只能看到这些安全组允许的内容，无论提示它的是谁。

更具说明性的信号或许是 Kazmaier 的附加说明。如果直接在 MCP 服务器上构建仅适用于少量用例，那么 Workday 期望大多数客户使用的无头版本是 Claude 与 Sana 对话，Sana 再与 Workday 自己的智能体对话，而 Workday 的运行时处于每次调用的中间。