经理在Claude里问：“这个岗位能不能从内部调人？”系统要读招聘编制、预算和员工信息。候选人匹配得再漂亮，只要经理看见了不该看的薪酬，或者建议绕开了审批，整个流程就没有通过验收。Workday与Anthropic在10月13日宣布新合作，真正值得拆开看的正是这个分工：让Claude参与推理与交互，让人事、财务系统继续裁定谁能看、谁能改、哪些动作必须审批。我的判断是，企业智能体进入权威业务系统后，成败取决于权限和业务规则是否在每一次实际操作时重新生效，而不是两个聊天界面能否流畅传话。
Workday公告介绍了两条方向。员工可在Claude中调用Sana智能体，分析获准的人事与财务信息并办理业务；在Sana主持的长流程里，需要特定推理步骤时也可调用Claude。双方使用模型上下文协议MCP交换任务和信息，Workday表示原有权限、业务规则与审计控制继续适用，每项变更由用户确认。[1] 这份公告给出的是产品规划与开放安排，Sana in Claude插件目前供早期客户使用，预计2026年晚些时候普遍开放；Agent-Ready Tools则已通过Workday Extend AI向客户提供。[1]
先问谁握着最终记录
人事经理编制一个内部流动计划时，可以请模型从职位要求和团队技能中找可讨论的匹配。建议本身还不是调岗。岗位有没有预算、员工的主管是否同意、岗位是否在有效编制内，答案藏在企业正式流程里。财务负责人检查发票例外也是一样：模型可以读采购单和发票，指出金额不符的原因；批准付款所需的岗位权限、金额阈值与审批链仍要由权威系统核验。Workday公告用内部招聘和发票例外作为Claude内工作的例子，还说明Sana可以在薪酬周期等长流程中组织工作，在需要撰写加薪说明的步骤使用Claude。[1]
这类场景容易出现一种错觉：用户已经登录Claude，智能体就自然拥有与用户相同的全部业务权限。事实上，模型收到的上下文和业务系统判断许可所依据的上下文是两回事。一次请求应标明员工身份、角色、组织范围、业务对象和拟执行动作；Workday端再根据当前规则给出允许、拒绝或需要审批。这里描述的是企业应检验的控制路径，不等同于公告公开了全部技术实现。操作成功后，还要能在原业务系统查到变更、时间与审批人，而不是只在聊天记录里看到“已处理”。
Workday的Agent-Ready Tools页面写得很具体：工具承载审批路由和规则，智能体须在明确的用户委托下行动，超出护栏的操作交给人处理，并称通过Agent System of Record留下记录。[2] 这些是产品方的能力描述。企业试点要拿本单位现有的人事与财务规则逐条走一遍。例如部门主管通常可看本组人员但不能看隔壁部门薪酬；临时代理主管可能昨天有权审批、今天授权已经失效。若只在首次连接时读一次角色，而执行时不再核验，长流程的边界会随人员变动悄悄滑掉。
MCP传得动任务，传不走责任
MCP提供客户端与工具服务之间交换请求的通用方式。其授权规范对基于HTTP的受保护服务说明了资源服务器、客户端和授权服务器的角色，规定可使用的授权发现流程；协议也明确授权能力属于可选部分，不能把“使用MCP”直接当作“已配置好业务审批”。[3] Anthropic的MCP连接器文档提供按工具允许或拒绝、OAuth认证和多服务器连接等配置能力；文档同时说明该API连接器当前只支持MCP的工具调用部分。[4] 协议与产品各有边界，不能从一条通用规格推断Workday某个插件的实际授权细节。
想象一次员工调岗申请跨过几个节点：Claude听懂经理问题，调用Sana或Workday工具查询空缺与预算，模型提出人选和理由，Workday检查申请人对该岗位的权限并路由审批。MCP可以帮这些节点对接，但调用参数是否超出用户授权、查询结果是否最小化、审批是否真正落在系统记录里，都要由实现和配置来保证。一个工具能够被发现，不意味着每位连接的用户都该拥有执行权限。把“有这个工具”和“此人此时可用这个工具”拆成两道检查，系统才知道该在哪一步说不。
数据路径同样值得问。Workday公告表示Sana主持的流程可以把工作上下文留在Workday，需要Claude参与特定步骤时只共享该步骤所需内容。[1] 对企业而言，这应转化为样本级测试：写一份包含敏感薪资的模拟表，观察发给模型的输入究竟有没有包含无关员工的记录，返回内容里能否出现超出当前经理权限的数据。不要只检查最终回答；原始工具请求、模型上下文和临时日志都可能持有数据。供应方说“数据留在Workday”时，应请其说明具体路径、存储位置及所指的Sana流程范围，避免把不同入口混作一项承诺。
从一个薪酬用例走完五道门
可以在隔离环境建立虚拟员工、部门、薪资带宽和审批链。第一道门是身份：让普通经理、HR专员、财务审批人分别提出同样的问题，看结果是否随角色变化。第二道门是最少数据：普通经理查询团队调薪建议时，模型输入里不应混入其他部门的个人明细。第三道门是推理：请Claude把建议所依据的岗位、预算和政策条款分别指出，无法判断时列出待核资料，而不是替人补一条不存在的制度。第四道门是审批：让系统分别处理额度内、额度外和被撤销授权的申请。第五道门是记录：在Workday一侧找出真实请求及审批轨迹，再尝试更正一笔已经确认的测试记录。图中的“五道门”是验收框架，不是产品披露的流程图。
这套测试最好包含一次中途变化：经理发起调薪建议后离开，部门预算收紧，审批人也换了。等智能体恢复工作，原来的建议可以作为草稿留下，最终提交必须读取当前规则。要记录哪个节点重新查询了预算、谁重新确认了金额、失败后系统是否停止。真实环境里的风险往往发生在任务暂停和恢复之间，而不是首次顺畅演示时。尤其要防止一种“批量确认”：对话开始时批准了整个分析任务，随后把这份确认延伸成同意具体改薪金额；Workday公告强调用户确认每项变更，[1] 企业验收就应检查确认窗口与最终写入对象、字段和值是否一致。
若系统拒绝了一次申请，团队还要查拒绝是否明确到业务原因，而非只有“工具调用失败”。例如预算不足与权限不足，下一步由不同人处理；接口超时则不能让智能体猜测批准与否并再次提交。对有副作用的操作，复用请求号或在目标系统查原记录，可以降低重复申请的可能。审批撤回、流程作废后的回滚，则需要企业先确认原系统可用的更正办法；不能假定模型对话里说一句“撤销”就能恢复工资或账簿。上述做法是流程设计建议，没有宣称插件默认具备所有回退动作。
买连接器还是重做权限模型
Workday称管理员一次连接即可沿用原有权限，不需要为每个人重建一套权限模型。[1] 这对大型组织有吸引力，因为再维护一份与HR系统不同步的权限表，很快会变成事故来源。不过旧规则也可能有历史包袱。人能在页面上看见某字段，不代表它应当被批量喂给模型；人可以审批一笔发票，不代表智能体在没有呈现差异时可以替他按下确认。接入之前，建议业务部门把实际职务分离要求写成用例：申请人不能审批自己的申请、同一笔付款不能由同一角色创建和放行、跨部门数据须按现有规则遮蔽。再让技术团队逐项比对权限结果。
Workday在6月的开发工具公告已介绍Agent-Ready Tools通过MCP提供人事财务数据上的受控动作，以及Agent Passport的验证设想；当时公告将工具的一般可用时间预计在2026年下半年。[5] 10月13日的新公告更新了当前供应状态：工具通过Workday Extend AI已向客户提供，而Claude插件仍处早期开放。[1] 时间线能帮助企业分清可采购、可试点和待普遍开放的组件。试点合同应把入口、租户地区、所需授权、日志可见范围和可用版本逐项写清，不要让“合作已发布”代替交付清单。
还有一个容易被价格表掩盖的问题：哪一方负责修正错误。Claude若建议了错误人选，Sana如果传了旧预算，Workday规则若配置得过宽，三个故障来源对应不同负责人。要把任务编号贯穿对话、工具请求、审批记录和正式业务对象，出问题时才找得到分界点。企业内部的模型平台团队可以负责提示与评估，人事财务系统管理员负责角色及规则，业务负责人负责最终流程；不要把所有异常都推给“AI回答不稳定”。
让审计员重放一次决策
做完功能演示，换一位没有参加演示的人，只给他业务系统与平台留下的日志，请他说明某项测试调薪为什么被批准。若他只能看见“Claude建议同意”和“审批通过”，却找不到申请人当时的岗位、采用的薪资政策版本、预算数据的时间点及审批者确认的金额，就没法复盘。日志当然不必把全部敏感内容复制一遍；它至少要有贯通的任务编号、数据版本、调用动作与审批指向，需要查看原始资料时再按审计权限回到权威系统。记录越多不一定越安全，复制一份完整工资表到外部日志还可能制造新的泄露面。
还要做一次反向演示：以无权查看薪酬的身份发起查询，让模型主动提出一条貌似合理的推理路线，再看系统能否在真正读取数据前拒绝。安全测试如果只问“它会不会直接说出工资”，可能漏掉中间查询工具已经取到了工资、最后回答却做了遮盖的情况。把工具请求与发给推理模型的实际字段一起核对，才能确定拦截发生在哪个位置。模型说“我不能提供”当然友好，但企业要看到敏感字段根本没有越过不该越的边界。
业务负责人也得参与定义“合理拒绝”。某位HR确实要处理跨部门调岗，但平时没有该部门资料权限，正确处理可能是先请有权者提供受限摘要或走临时授权审批，而非让模型凭借一句业务紧急自动扩大读取范围。权限例外如果始终靠人工私聊绕开正式系统，智能体投入使用以后只会把这种旧习惯放大。把例外写进可追踪的流程、明确到期时间和批准人，既方便开展真正需要的工作，也给拒绝提供可解释的下一步。
谁给智能体发起委托
在公司里，权限通常跟岗位走，委托却跟一次任务走。HR专员有权查询某些员工记录，但对话里的“帮我分析人力成本”范围太大；他可能只想看这个季度本部门的总额。试点时可以要求每项敏感任务同时保存发起人、查询目的、数据范围、计划动作和有效时间。申请发起者改变目标后，原委托应重新确认；岗位变更后，旧委托即便还显示在聊天历史里，也不能继续授予查询资格。这些字段属于本文建议的授权记录，不是Workday已经公开的插件字段。
跨平台还要考虑消息到达的先后。一个审批在Workday里被撤回，Claude会话里可能仍显示旧的建议；用户关闭会话、第二天继续时，智能体应该先取当前审批状态。财务月结期间尤其不能按昨天的余额批准今天的例外。对流程负责人，最可靠的验收不是问模型是否记得工作进度，而是改一项底层规则后重试同一个请求，观察结果能否随权威系统变化。如果不能，就要找出缓存失效和状态同步在哪里断开。
决定放行的依据
第一次上线只给智能体建议权，保留人工提交。拿到连续、可复盘的合成用例结果以后，再开放明确字段上的操作，尤其注意例外审批、权限撤回和跨组织查询。统计准确率之外，至少记录越权请求被拦截的情况、业务规则命中的原因、人工确认次数、目标系统回执与修复耗时。所谓高效不能建立在让HR事后逐笔纠错之上。
这次合作呈现了一个可检验的企业架构：模型在员工熟悉的入口里帮助推理，权威系统继续握住人员与资金记录。[1][2] 真正的采购问题因而很尖锐：经理在Claude里读到一项建议后，哪一份权限在最后写入前被核过？审批者看到了什么？如果人改变主意或规则改了，旧任务会不会继续跑？在这些问题有可回放的答案之前，先把Claude当作辅助分析员；让它执行敏感动作，得靠业务系统每一步的真实约束。
参考资料
[1] Workday Newsroom，《Workday and Anthropic Announce New Partnership to Connect Reasoning to the Rules That Run the Business, Wherever People Choose to Work》，2026-10-13。双方数据交换、用例、用户确认及开放阶段。https://newsroom.workday.com/2026-10-13-Workday-and-Anthropic-Announce-New-Partnership-to-Connect-Reasoning-to-the-Rules-That-Run-the-Business,-Wherever-People-Choose-to-Work
[2] Workday，《Agent-Ready Tools for Data》，产品页无明确发布日期，2026-10-14访问。工具内置业务规则、明确委托、越界转人工与记录的厂商描述。https://www.workday.com/en-us/ai-platform/agent-ready-data-tools.html
[3] Model Context Protocol，《Authorization》，2025-11-25版本。HTTP传输授权范围、资源服务器/客户端角色和授权为可选能力的规范说明。https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
[4] Anthropic，《MCP connector》，在线文档，2026-10-14访问。工具白名单、OAuth及API连接器当前功能边界。https://platform.claude.com/docs/en/agents-and-tools/mcp-connector
[5] Workday Newsroom，《Workday Launches New Tools for Developers to Build, Connect, and Verify AI Agents For HR, Finance, and IT》，2026-06-02。Agent-Ready Tools的功能与当时供应规划。https://newsroom.workday.com/2026-06-02-Workday-Launches-New-Tools-for-Developers-to-Build,-Connect,-and-Verify-AI-Agents-For-HR,-Finance,-and-IT
两张配图是企业流程概念示意，不对应Workday或Claude的实际界面和具体实现。