2026 年 10 月 13 日，Workday 宣布，其 Trusted Agent Platform 向 AI Agent 开放无需经过传统操作页面的 HR 与财务能力。它强调，无论 Agent 由谁构建，经过平台执行的动作仍遵循 Workday 的权限、审批和审计机制。Workday 官方公告
这种形态被称为 headless。放在企业软件里，可以简单理解为：用户表达目标，Agent 调用业务能力，员工不必再逐页寻找按钮。这里省去的是人工操作页面的过程，身份验证和业务授权仍然需要成立。
这则消息让一个问题变得更具体：假如客户以后很少登录后台，一家软件公司应该向客户交付什么？
页面仍然可以很好看，功能菜单仍然可以很丰富。但如果主要操作者逐渐变成 Agent，产品就需要解释得更深一些：一次调用到底承接了什么工作，在什么条件下能够完成，发生异常时又怎样继续。
我认为，这会推动企业软件把过去藏在界面、操作习惯和实施经验里的业务承诺，逐步变成可以直接理解、执行和核对的能力。
一套后台运行顺畅，往往也包含了许多人没有被记录的劳动。
用一个假设场景来说明。一位运营负责人对助手说："按上周的方案，给三家门店补一批货。"
熟悉业务的员工听到这句话，可能先检查门店库存，再核对在途数量，随后发现其中一家店正在调整经营范围，于是找负责人确认。提交之前，他还会检查本周是否更换了供货仓，以及上周价格是否仍然适用。
在软件日志里，这些工作也许最终只留下几次查询和一张补货单。经验、询问和判断发生在页面之间，系统未必完整感知。
如果把同样的页面交给 AI 操作，点击可以自动化，但这些判断并不会随之自动补齐。直接开放几个查询和写入接口，也不能保证原来由人承担的判断已经有了可靠去处。
这就是很多企业接入 Agent 时会遇到的落差：演示里，模型找到工具、填好参数、收到成功返回；实际经营里，负责人仍然需要检查，它完成的究竟是不是这次工作。
软件团队因此需要重新梳理原来默认由员工理解的含义。"可用库存"是否已经扣除了占用？"提交"表示保存待审，还是已经向仓库派发？"沿用上周方案"允许复用哪些信息，又有哪些条件必须重新查询？
这些问题越清楚，Agent 越容易正确使用系统，人也越容易判断什么时候可以放心委托。
业务能力的交付，需要从一个接口名称走向一项有条件的工作承诺。
仍以前面的补货为例。一个叫作"创建补货单"的接口，可以接受门店、商品和数量，再返回一个单号。这样的接口足以连接系统，却可能不足以承接"把货补好"这个目标。
至少还需要说明：这个单号对应什么状态；库存是否已经预留；是否需要审批；后续由哪个系统处理；如果只完成了部分门店，怎样找回已经发生的记录。
这并不意味着一个接口必须包办整项工作。恰恰因为任务会经过多个环节，每一项能力才需要清楚说明自己承接到哪里。
查询库存可以承诺返回指定门店、指定口径、某个时点的库存信息。创建草稿可以承诺留下一个可继续编辑的业务对象。提交审批可以承诺生成可查询的审批记录。实际出库则由掌握库存与仓库状态的系统确认。
它们组成一条能够解释的工作链。客户无需了解每个内部接口，却应当能够看到当前完成了哪一步、正在等谁，以及还有什么没有发生。
这里有一项值得保留的纪律：系统只能承诺自己能够确认的结果。请求已接收、审批已通过、业务已生效，分别对应不同事实。把它们都压成一句"处理成功"，会把后续核对成本留给使用者。
对于软件厂商，这种能力比再增加一个聊天入口更费功夫。它需要产品、业务开发和实施人员一起把工作含义整理清楚，也更容易沉淀成其他入口能够复用的产品资产。
Workday 的此次选择值得关注，正因为它将开放能力与原系统规则放在一起讨论。其官方技术说明提出，通过 Agent-Ready Tools 和实时数据访问，在每次请求中延续既有安全与业务约束。同时，部分上下文与推理能力仍列在后续计划中，不能把整套路线都当成今天已经交付的功能。Workday 平台说明
一个厂商的公告当然不能证明所有行业都已经解决了这些问题。不过，它提供了一个明确的产品方向：原有系统积累的业务知识，需要以新的方式进入 Agent 的工作过程。
规则能否跟随业务能力，取决于规则究竟落实在哪里。
过去，一些限制通过页面实现：没有权限的按钮不显示，不合条件的选项变灰，提交之前弹出一个提醒。对人的操作体验来说，这些设计很有价值。
当同一项能力增加了 API、批处理或 Agent 入口，软件就必须确认，这些限制在实际执行时是否仍然成立。否则，企业增加的每一个入口，都可能需要重新维护一份不同的规则。
例如，补货草稿中的门店范围来自谁的授权，提交时应由可信身份和业务权限共同决定；库存是否足够，应以业务系统当前能够确认的状态为准；需要人工决定的金额或范围，应呈现具体对象和参数，而不是由模型在描述里写一句"已获批准"。
入口可以帮助表达目标，Agent 可以拆解步骤，中间层可以控制调用范围和衔接审批。真正掌握实时业务事实的系统，仍然需要保留最终执行判断。
这也意味着，企业没有必要为每一个助手重建一套自己的经营制度。更值得投入的是让不同入口在使用同一项业务能力时，能够共同遵守它的有效条件。
对于维护多年行业系统的团队，这项工作有现实基础。你们知道哪些历史操作不能简单删除，哪些数量不能直接相加，哪些状态变化会影响下游履约。这些经验的价值，在于能否转化为持续有效的行为，而不只存在于少数熟练员工的脑海里。
当 Agent 一次协调多个系统，软件还需要把"没有做完"表达得足够清楚。
回到三家门店的补货任务。第一家已生成补货单，第二家正在等待审批，第三家因为供货仓变化而没有继续。此时，聊天界面里的一段流畅总结，不能代替三个业务对象各自的真实状态。
如果助手断线之后重新开始，最有价值的能力是找回原任务中已经生成的记录，核对未完成部分，再决定下一步。把三家门店全部重新提交一遍，很可能增加重复单据和人工清理。
如果负责人改变主意，要求取消，也要知道取消影响的是尚未派发的步骤，还是已经出库的业务。已经发生的动作可能需要另一个退回流程，不能仅靠把任务状态改为"已取消"就视为恢复原状。
企业软件过去也需要处理这些问题。Agent 让它们更加突出，因为原来由人盯着页面、记住单号、联系同事完成的衔接，现在需要成为机器和人都能接续的明确机制。
一个系统能够清楚返回"等待决定"，另一个能够解释"当前条件已变化"，第三个能够提供"这一笔已经执行"的记录，跨系统协作才有可靠的依据。开放更多工具，并不能替代这些细节。
这也是为什么，面向 Agent 的软件质量不能只看接口调用成功率。还需要看调用者是否理解了正确含义、结果是否可以核对，以及异常之后是否增加了使用者的工作。
一百次成功请求，如果产生了重复业务或需要人工逐笔核查，未必比一次明确拒绝更有价值。一次拒绝如果说清楚原因，并保留可以继续处理的上下文，反而可能保护后续工作的连续性。
由此看待"开放生态"，要求也会具体许多。
连接方式趋于一致，可以降低技术接入成本。但两个系统都提供"提交补货"，并不表示它们对库存预留、审批时点和失败恢复具有相同约定。生态的可组合性，需要这些差异能够被看见，而不是靠相同的工具名字把它们藏起来。
我们围绕 A2B、ACC 和 BailingHub 所做的工作，也从这个问题出发。
A2B，也就是 Agent-to-Business，是我们用来讨论 Agent 接受委托、进入已有业务系统并形成业务后果的一个认知框架。它让注意力回到：组织究竟交出了哪一部分行动能力，以及结果怎样返回到人和组织。
ACC 是独立的能力治理声明契约，用来表达能力面向 Agent 时的范围、风险和约束。声明本身不会授予业务权限，也不会替系统判断当前库存或审批结果。
BailingHub 开源 Core 则提供能力发现、受控调用、审批衔接和执行追溯等运行时机制。在本地智能体接入路径中，模型与任务编排由客户端宿主负责，原业务系统保留最终授权与领域规则。这样的分工让行业团队可以逐项开放既有能力，同时保留清楚的执行边界。
这些机制能承接治理与衔接工作。补货规则是什么、库存何时算作预留、出库后怎样退回，仍然需要业务系统正确实现。中间层越清楚自己的职责，越能帮助不同系统合作，也越容易让开发者评估接入成本。
对企业而言，评估这种改造可以从一项经常发生的工作开始。让同一项业务分别通过原后台和 Agent 入口处理，核对它们是否使用相同的业务规则，是否留下可以对应的记录，以及出现等待、拒绝或部分完成时，人是否仍然能够接手。
需要观察的也不只是模型耗时。人工检查、补充说明、异常处理和恢复成本，都属于这项工作的真实成本。只有完整工作变得更容易交付，自动化才真正产生了收益。
人的界面在这里仍然重要。负责人可能需要用表格比较三家门店的方案，用清楚的差异视图作出决定，再让助手继续处理。日常准备可以更自动化，关键判断则应获得更好的呈现。专业界面与 Agent 入口，可以围绕同一组可靠能力各自发挥作用。
客户以后也许很少记得自己在哪个后台点过哪些按钮，但他会知道：货有没有补对，等待有没有被遗漏，出现问题能不能找到记录，换一种工作方式以后规则是否还在。
企业软件的价值，就需要在这些具体结果中被看见。掌握业务事实、维护有效规则、交付可以核对和接续的工作，这些能力需要持续建设，也需要持续接受客户检验。
当 AI 帮人省下越来越多的操作步骤，软件厂商值得追求的，是让每一次被调用的能力，都有清楚的含义、可靠的行为和可以交接的结果。页面可以退到日常操作之后，这份工作仍然必须有人做好。
本文依据截至 2026 年 10 月 16 日的公开资料展开。门店补货为说明性假设，产品方向与价值判断为作者分析；Workday 公告不代表与本文所述开源项目存在合作或兼容关系。