Hooks 与 Joule：企业智能体迎来控制平面
--- title: Hooks 与 Joule：企业智能体迎来控制平面 slug: hooks-and-joule-enterprise-agents-get-a-control-plane meta_title: 企业智能体迎来控制平面 meta_description: 微软为 Copilot Studio 添加了 Hooks，使工作流在事件发生时触发，而非依据智能体判断；与此同时，SAP 将 Joule 推进为一个受治理的智能体工作层。 category: ai tags: Microsoft Copilot Studio,Hooks,SAP Joule,智能体治理,确定性护栏,企业 AI,工作流自动化,控制平面 ---
本月，微软和 SAP 在几天内相继发布了智能体功能，而这两个版本都承认了同一件事。让模型决定业务工作流是否启动，是一种可靠性风险。
微软的 Hooks 做什么
微软正在预览 Copilot Studio 的一项名为 Hooks 的功能，它在某件事发生时自动运行智能体工作流，而不仅仅是在智能体判断应该运行时才运行。一个钩子由两部分组成：智能体生命周期发出的事件，以及事件发生时触发的操作。当事件触发时，Copilot Studio 会调用绑定的工作流，传入所发生事件的详细信息，并将工作流响应读回对话中。
与工具的区别正是关键所在。工具在智能体认为相关时运行。钩子则在事件每次发生时都会运行。
微软列出了四个场景。在会话开始时添加上下文，在对话开始前查找未解决的客户支持案例。在工具运行前检查它，如果它违反业务规则就阻止该操作。对工具的结果进行后处理，例如脱敏敏感数据或写入审计记录。处理失败，告诉智能体重试、跳过或停止。
这些注意事项和功能本身一样具有信息量。Hooks 附加到特定智能体，添加一个钩子并不会改变其底层工作流。钩子失败时不会阻止智能体：如果工作流超时或返回不可读内容，智能体会像钩子什么都没返回一样继续运行。工作流必须发布，否则不会运行。输入应被视为不可信，编辑工作流会影响使用它的每一个钩子。
最后一点是一个不易察觉的维护隐患。一个工作流可以服务于多个智能体，因此为一个用例所做的更改会传播到其他用例。存在于共享工件中的治理需要版本管理纪律，而这是大多数自动化团队此前不必构建的能力。
这一设计还留下了一个值得指出的缺口。一个静默失败的钩子，是一种不控制任何东西的控制。微软关于验证输入的指导很重要，因为智能体无法区分真实答案和空答案，事后阅读日志的审计人员也无法区分。
SAP 在同一时期做了什么
SAP 将其 Joule 助手扩展为它所称的智能体工作层，与一项“自主企业”（Autonomous Enterprise）计划相关联。该公司表示，其智能体中心目前监管着约 150 家公司中的超过 100,000 个智能体，有 50 多个领域助手编排着 200 多个专业智能体，并声称其 Autonomous Close Assistant 可以将财务结账从数周压缩到数天。
把两者放在一起，模式就很清楚。供应商正在将解释与决策分离。模型读取发票；代码决定是否付款。
时机并非巧合。两家供应商在客户部署中都看到了同样的失败模式：智能体在演示中运行良好，却在生产环境中、无人注意的时刻做出了错误判断。解决方案是将决策移出模型。
有一种治理框架能让买家理解这一转变。监管机构已经从询问智能体是否安全，转向询问当它们不安全时由谁负责。能够指出确定性触发器、强制分支和审计追踪的供应商有答案。而贩卖自主性的供应商没有。
为什么密度迫使这一变化
当智能体数量达到 100,000 个时，瓶颈不再是能力，而是监督。了解每个智能体做了什么、为什么做，以及依据谁的授权，是一个与让智能体运行起来不同的问题。
SAP 报告的数字让这一点变得具体：50 多个领域 Joule 助手编排着 200 多个专业智能体，分布在约 150 家公司中，其 Autonomous Close Assistant 将财务结账从数周压缩到数天。在这种密度下，非正式监督会失效。没有人会阅读每一条追踪记录，而真正重要的失败正是那些没人注意到的失败。
成本也有同样的形态。一份实践者对 Copilot Studio 定价的分析估计，每个 Copilot Credit 约为 0.01 美元，操作消耗 1 到 100 个 credit，一个典型的基于数据的工作流大约花费 30 个 credit，约 0.30 美元。这在量级到来之前看似微不足道：100,000 次运行大约是 30,000 美元，而智能体不会等人点击。硬性的月度消耗限制成为架构要求，而不是管理员的偏好。
还有第三种压力。调查显示，开发者每周使用 AI 编码智能体的比例达到 90%，这些工作流底层的许多逻辑本身也是由机器起草的，这提高了测试门禁、代码审查和可回放日志的价值。90% 这一数字来自 JetBrains 的一项调查，它与另一个发现相吻合：更快的代码生成并不自动带来更快的交付。
三层模式
由此形成的架构包含三个部分。意图层让模型解释混乱的请求。确定性执行层运行小型、无状态、可测试的函数。控制平面执行预算、权限和审计追踪。
无服务器边缘工作线程适合中间层，因为它们按请求计费成本低、隔离且易于版本化。这一模式并不新颖；它类似于支付系统一直以来处理不可信输入的方式。改变的是，行业现在默认将其应用于智能体，而不是在事故之后才应用。
微软自己列出的用例完全符合这一模式。在会话开始时添加上下文、在工具运行前验证它、对结果进行后处理以及处理失败，都是生命周期中的拦截点。Hooks 将它们形式化为确定性代码可以查看智能体即将做什么的位置。
工作流设计还有一个附带好处：它让智能体的行为在事后变得可解释。记录输入和输出的钩子会产生智能体自身永远不会生成的审计记录。对于需要向监管机构交代的团队来说，这份记录是描述预期行为与证明实际行为之间的区别。
一个值得重复的警告：写在单一供应商 studio 内的治理逻辑，是你租来的治理逻辑。重要的业务规则应该存在于你可以迁移的代码中，因为控制层才是持久价值所在。
从竞争角度看，两家供应商从不同起点得出了相同结论。SAP 来自业务流程软件，审批路由是其原生词汇。微软来自低代码 studio，触发器和条件已经为人熟悉。两者都不再贩卖自主性。它们都在出售说“不”的能力。
这一框架也改变了买家评估这些产品的方式。问题不再是谁的智能体最聪明。而是哪一个能被精确约束到足以无人值守运行，以及哪一个在做意外之事时留下记录。