Workday正在开放其平台，允许开发者在Claude Code、Cursor等工具中构建自己的HR和财务智能体，前提是这些智能体必须遵循与用户相同的规则。
周二，在拉斯维加斯举行的Workday Rising大会上，公司宣布其可信智能体平台（Trusted Agent Platform）实现了"无头化"（headless）。
借此，该公司的模型上下文协议（MCP）服务器、对实时Workday数据的SQL访问能力，以及智能体共享运行时环境现已全面上线，客户可以在Anthropic、谷歌、Meta、Mistral、英伟达和OpenAI的模型上运行自己的智能体。
正如Workday首席技术官加布·门罗伊（Gabe Monroy）在大会前的新闻发布会上所说："无论谁构建了这个智能体，它都要在Workday的权限、审批和审计跟踪机制下运行——任何智能体都没有后门可走。"
Workday指出，目前许多公司通过数据湖中的副本或通过服务账户将其智能体连接到HR和财务数据，但该公司认为，这些方式绕开了访问控制机制（不过SAP、微软等公司肯定也会声称自己同样设有访问控制）。
MCP工具、SQL与共享运行时
对于AI开发者而言，进入Workday生态系统的主要入口是"智能体就用工具"（Agent-Ready Tools）。这是该公司的MCP服务器，作为Workday Extend AI的一部分发布。用户使用自己的Workday凭证登录，Workday表示，代表用户行动的智能体无法访问用户自身账户无法访问的任何内容。这是一项关键特性，它将智能体直接与用户账户绑定。
门罗伊表示，该服务器目前提供275个读取工具和54个可写入或删除数据的工具。
实时数据查询（Live Data Query）是Workday数据云（Workday Data Cloud）的一部分，允许商业智能工具和智能体直接对Workday数据运行SQL查询。门罗伊将其描述为通过JDBC访问Workday的对象图，公司表示每次查询仅返回请求用户被授权查看的内容。
目前还有三个组件已全面上线。智能体运行框架（Agent Harness）是Workday自有智能体以及客户和合作伙伴构建的智能体所运行的共享运行时环境。它会向每个智能体传递用户身份、组织职位和访问权限，限制智能体可执行的操作，并根据成本和性能为每项任务选择合适的模型。开发者智能体（Developer Agent）可以根据Claude Code、Codex、Cursor或Workday开发者网站中的自然语言提示，生成Workday智能体和应用程序。自定义智能体（Custom Agents）允许团队将使用LangChain或谷歌智能体开发套件（ADK）构建的智能体部署到智能体运行框架上，不过目前ADK支持仅限于设计合作伙伴使用。
另外两项功能计划于2027年初开放早期访问。智能体上下文服务（Agent Context Service）将仅预加载任务所需的Workday数据，Workday表示这能加快智能体运行速度，并限制其对敏感记录的接触。有根据的推理（Grounded Reasoning）会在智能体执行计划操作之前，先对照客户的政策、流程规则和Workday记录进行核查。
Workday表示，在过去四个月中，客户已使用开发者智能体和智能体就用工具构建了超过500个智能体和6000多个应用程序。
"无头化，无序的方式"
在发布会上，门罗伊演示了他所称的"无头化，无序的方式"。一个连接到自定义MCP服务器的智能体——他表示这是Workday目前在客户中常见的配置——返回了用户本不该看到的职位空缺信息，并在没有任何审批的情况下将错误的员工调动到了其他团队。当指向Snowflake中的Workday数据副本时，同一个智能体在被问及时竟然给出了首席技术官的薪资信息。
门罗伊说："当它出错时，这不仅仅是一个错误答案，而是一个没有人批准的错误操作。"
而当该智能体改为通过Workday自有的MCP服务器和数据云运行，且用户已登录的情况下，同样的查询自然只返回了该用户被允许查看的职位空缺信息（否则这场访问控制演示也就没什么说服力了）。
"一小部分使用场景"
当被问及无头化模式对Workday的重要性是否与对Salesforce的重要性相当时，Workday产品与技术总裁格里特·卡兹梅尔（Gerrit Kazmaier）表示，Workday正在给客户提供选择权："我总是更希望他们使用我们的用户界面，但无头化模式同样出色。"
卡兹梅尔指出，直接基于Workday的工具和API构建智能体，"仅适用于一小部分不需要HR或财务领域逻辑的使用场景"。对于其他场景，他提到了一种AI对AI的集成方式，即Claude将请求交给Workday的智能体编排器Sana，再由Sana调用Workday自己的领域智能体。
数据湖用于分析，而非用于智能体
值得注意的是，上述Snowflake的例子对Workday来说有点尴尬。该公司在2025年9月宣布数据云时，其宣传内容就包括将Workday数据与Databricks、Salesforce和Snowflake进行零拷贝共享。Snowflake于10月7日正式上线其Workday数据云集成，Databricks也在次日将其面向Unity Catalog的Workday连接器推出公开测试版。
据Databricks介绍，Workday管理员通过注册一个集成系统用户（ISU）来设置连接器，这类系统账户正是Workday客户用于传统集成的账户类型，并赋予其对共享表的读取权限。此后，Unity Catalog在目录、模式和表级别的权限设置将决定谁可以查询这些数据。
门罗伊表示，数据湖对于分析以及将Workday数据与公司其他数据进行关联仍然有意义，但对于需要受管控访问Workday数据的智能体而言，外部数据湖"是构建智能体的错误场所"。
他说："你可以导出数据，但无法导出管理这些数据的规则"，并补充说，在数据湖中重建这些规则意味着"维护第二套副本"的Workday安全模型，"而一旦出现偏差，一切都会出错"。
人人都在"去头化"
无头化似乎正是当下的趋势所在。例如，Salesforce、ServiceNow和微软已经允许外部智能体接入其系统记录。Salesforce在4月的TDX开发者大会上发布了Headless 360，使Claude、ChatGPT、Cursor或终端中的智能体能够与Salesforce数据协同工作。ServiceNow于5月全面上线了其Action Fabric MCP服务器，Anthropic作为首发合作伙伴参与其中；微软则为Dynamics 365 ERP提供了MCP服务器。
这四家供应商均表示，外部智能体将保持在其现有权限模型范围内运行。
智能体使用谁的身份？
在智能体身份认证方面，不同供应商目前采取的方式差异很大。
例如，根据Salesforce Ben的报道，Salesforce正准备让通过MCP或其API连接的智能体以自己的凭证和权限进行注册，而不是以用户身份行事。MCP客户端最终将需要切换到与这些智能体身份绑定的OAuth凭证。
Workday的文档显示，其智能体已经可以拥有最多两个自己的系统账户，称为智能体系统用户（ASU），一个用于代表用户行事，另一个用于"环境式"（ambient）工作，每个账户都拥有自己的OAuth 2.0客户端。当客户启用环境式技能时，Workday会自动创建该环境账户。
销售Workday MCP集成服务的Unified.to表示，每一条Workday MCP路径，"无论官方与否"，都始于创建一个ISU账户。Cequence为其Workday MCP集成提供的设置指南也要求客户创建一个"具备相应安全组权限"的账户。通过ISU工作的智能体可以看到这些安全组所允许的所有内容，无论是谁在向它发出指令。
更能说明问题的或许是卡兹梅尔的那句警示。如果直接基于MCP服务器构建智能体仅适用于一小部分使用场景，那么Workday期望大多数客户使用的无头化版本，实际上是Claude与Sana对话，Sana再与Workday自有智能体对话，而Workday的运行时环境则始终处于每一次调用的核心位置。
