第10部分：智能体审批流程的经验教训与可复用蓝图

第 10 部分，共 10 部分 · 在 MuleSoft 上构建代理式变更审批的 MVP

这是最后一部分。在九篇文章中，我们将一个痛苦的流程——将 SAP 变更从开发环境提升到生产环境——转化为在 MuleSoft 上构建的代理式 MVP：涵盖了 21 个步骤的流程、决定自动化范围的 2x2 矩阵、架构、代理网络、MCP 工具、网关策略、Vibes、测试、CI/CD 以及生产支持。

本部分将这些内容整合在一起：总结哪些做法有效、哪些我们会做出改变，并提供一个可复用的蓝图，供你应用于自己的流程。

五个成功的做法

1. 从流程入手，而非从代理入手。我们在编写任何提示词之前，先映射了所有 21 个步骤，并将每个步骤归类为规则、代理或人工处理。大多数步骤根本不需要代理参与。这张流程图仍然是该项目中最有用的产物。

1. 在代码中强制执行人工关卡。如“人在回路”一文所述，在任何操作触及 SAP 之前，每次审批都由 Process API 进行检查。无论提示词如何，代理都无法跳过关卡，因为关卡并不包含在提示词中。

1. 将 Process API 暴露为工具，而非 System API。集成团队已经构建的业务规则成为了代理的安全层。我们复用的代码远多于新写的代码。

1. 让确定性检查做决策。AI 提议软件包、风险类别和传输订单。但由模式定义、Process API、网关策略和人员来决定是否继续执行。同样的规则也适用于 AI 开发人员：Vibes 提议代码，钩子和 CI 负责检查结果。

1. 在我们能测试的地方进行精确测试。只有 LLM 步骤会被评分。其他所有内容都通过精确测试，这使得测试套件保持常规、快速且可信。

五个我们会采取不同做法的地方

1. 首先编写工具描述和命名错误。我们调试的大多数代理问题，包括死循环，都源于工具没有说明何时使用它们或在出错后该怎么做。下次我们会在编写任何代理提示词之前就写好这些内容。

1. 在第一个代理之前构建黄金数据集。我们在第一个版本运行成功后才构建了它。如果从一开始就有这个数据集，那么每一次早期提示词的更改都可以量化衡量，而不是依赖主观判断。

1. 从一开始就设定令牌预算。在一次提示词更改导致令牌使用量倍增后，我们添加了 LLM 速率限制策略。从一开始为每个代理设定预算成本很低，并能立即捕获此类问题。

1. 保持代理规模较小。我们早期的一个代理拥有过多的工具，并在这些工具之间做出了糟糕的选择。将其拆分为两个各含少量工具的代理，比重写任何提示词都更有效。

1. 在上线前规划支持。第 9 部分中的关联 ID、仪表板、运行手册和暂停开关都来得太晚。它们应该是首个发布版本的一部分，而不是首次事故后的补救措施。

蓝图

如果你想将此方法应用到自己的流程中，以下是我们会遵循的顺序：

1. 映射流程。列出每个步骤，并将其分类为规则、代理或人工处理。
2. 找到关卡。在每个审批中强制执行 Process API，而不是在提示词中处理。
3. 暴露工具。通过 MCP 工具暴露 Process API，并为代理编写描述性文本及命名错误。
4. 设计网络。小型代理，每个代理仅包含少量工具，并配置带有循环限制和升级至人工处理的经纪人图（broker graph）。
5. 治理流量。在 Omni Gateway 中实施工具白名单、PII（个人身份信息）检测和令牌预算。
6. 按标准构建。在 Vibes 中为 AI 开发人员提供技能、规则和流程；使用钩子和 CI 来检查结果。
7. 测试、部署和运行。结合精确测试和黄金数据集，为 Mule 应用和代理网络提供单一版本化的发布，并为每种故障模式准备运行手册。

第 1 步和第 2 步是团队最想跳过的步骤，但正是它们确保了后续步骤的安全性。

它还适用于其他场景

该蓝图中的内容并不局限于 SAP。任何涉及人员审批与系统执行的多步骤流程，如访问请求、供应商入职、Salesforce 或 Workday 中的配置推广，或一般的发布管理，都适用相同的结构。如果您的流程包含检查清单、少数审批人以及最终的系统记录源，那么它就符合应用此蓝图的条件。

谢谢

感谢阅读，也感谢所有评论和提问的朋友。本系列的十个部分将作为一个整体呈现。

您所在组织中，您会优先将哪个流程纳入此蓝图？下一系列应该涵盖什么内容？

本系列基于一家虚构公司构建了一个参考模型。产品功能基于截至 2026 年 10 月的 MuleSoft 文档；在实施之前，请查阅最新文档。