MuleSoft Agent Fabric本地部署与测试实战

传统AI Agent测试的痛点

如果你用 MuleSoft Agent Fabric 构建 AI Agent，大概率经历过这种折磨：改一行路由逻辑、调整 MCP 配置、或修改 LLM 的指令后，想验证改动是否生效，传统流程要求你把所有资产发布到 Exchange，配置网关，将 Agent Broker 应用部署到 CloudHub 2.0 或 Runtime Fabric，然后等待整个部署完成，最后才能调用 Broker 测试。一旦失败，还得回到 Anypoint Code Builder 重头再来。

这种循环的代价不只是时间，更是注意力的碎片化——每次微调都要经历一次完整的发布-部署-等待链路，开发者很难保持心流状态。MuleSoft 最新的本地部署能力正是冲着这个痛点来的。

本地部署的核心机制：Docker + Anypoint Code Builder

据 YouTube 频道 MuleS Academy 的演示，新方案的核心思路是把原本发生在云端的部署链路压缩到本地 Docker 环境中。开发者不再需要发布任何资产到 Exchange，也不需要远程部署，所有网关、策略和 Broker 都在本地容器中运行。

演示中展示了一个旅行规划 Broker 项目，其结构包含三个关键文件：

• .agent.yaml：定义 Agent 网络的节点结构
• exchange.json：项目元数据
• 配置文件：声明 LLM 连接与 MCP 服务器连接

.agent.yaml 中的节点依次为：系统指令、Broker 配置（使用 OpenAI LLM）、Actions（调用 Flight MCP Server 的搜索机场、搜索航班、获取航班详情三个只读工具）、触发节点、子 Agent（负责推理）、路由节点（决定返回成功或错误响应）、Agent Card，以及注册 MCP 和 LLM 的上下文与 Registry。

你可能没注意到 exchange.json 中暴露的敏感信息——OpenAI API Key 和 MCP 服务器的公网 URL。演示者特别提醒：填写 MCP 服务器 URL 时不要带 /mcp 后缀，这是实际踩坑后的经验。

MCP（Model Context Protocol） 是由 Anthropic 提出并开源的协议标准，用于让 LLM 应用以统一方式连接外部工具、数据源与服务。在 MCP 架构中，提供能力的一方称为 MCP Server（例如文中的 Flight MCP Server，暴露“搜索机场”“搜索航班”等工具），调用方称为 MCP Client。相比为每个工具单独写适配代码，MCP 把工具描述、参数模式和调用接口标准化，使 Agent 可以在运行时动态发现并调用工具。MuleSoft 在网关层内置 MCP 支持策略，正是为了让 Agent 网络能够以标准协议接入外部 MCP Server，而无需在 Broker 内部硬编码连接逻辑。

A2A（Agent-to-Agent） 协议关注的是不同 Agent 之间如何互相发现与协作。其中 Agent Card 是一份描述性元数据，列出该 Agent 的技能、描述、标签和访问端点，供其他 Agent 或客户端在调用前了解其能力。文中 ingress 网关上自动应用的 A2A Agent Card 策略，就是把 Broker 的能力信息以标准形式对外暴露，这也是在 Code Builder 中能直接看到填充好的 Agent Card 的原因。

前置条件与操作流程

要在本地运行 Agent 网络项目，需要满足几个前提：Anypoint Code Builder 保持最新版本、本地安装 Docker Desktop、Code Builder 与 Anypoint 平台正确连接并具备相应权限。

操作上，通过 Ctrl+Shift+P 调出命令面板，可以看到新增的两个选项——这是 MuleSoft 为本地部署专门添加的。选择"以默认配置启动 Agent 网络本地部署"后，左侧会生成 .deployment 文件目录，部署状态实时可见。若停在"等待输入"状态，复制日志中给出的 UI 地址继续即可。

幕后发生了什么：网关、策略与连接

本地部署完成后，Docker 中会看到 local-run 下的 exchange-1 环境，ingress 网关运行在 8081 端口，egress 运行在 8082 端口，此外还有 travel-planner-broker 端点。

原本需要手动完成的工作——部署网关、应用策略、部署 Agent 网络项目——现在一次性完成。ingress 网关上自动应用了用户上下文传播、MCP 支持策略、A2A Agent Card 策略、OpenAI 转码策略等。egress 网关上则能看到 MCP 连接和 OpenAI 连接这两个 API 的部署。这种透明性对排查问题很有价值，开发者能直接看到每一步背后的实际配置。

ingress 与 egress 网关是 API 网关架构中的一对方向性概念。ingress（入站）网关负责接收来自外部客户端或上游 Agent 的请求，承担认证、用户上下文传播、协议转换等职责；egress（出站）网关则管控 Agent 对外部服务的调用，例如访问 MCP Server 或调用 OpenAI 接口，用于统一管理出站凭证、限流与审计。两者分离的好处是入站与出站的策略可以独立配置、独立观测，出现问题时能快速定位是请求入口还是外部依赖环节出了差错。文中 8081 与 8082 两个端口分别对应这两个网关，egress 上看到的 MCP 连接与 OpenAI 连接两个 API，正是被纳管的外部出站依赖。

OpenAI 转码策略属于协议转换类策略。不同 LLM 提供方在请求格式、认证方式、模型命名和响应结构上存在差异，转码策略在网关层完成请求与响应的格式映射，使 Agent 侧可以使用统一的内部契约调用模型，而无需为每家提供方改造代码。这样当需要更换模型供应商或调整模型参数时，只需修改网关策略配置，Agent 逻辑本身保持不变，也便于在网关层集中管理 API Key 等敏感凭证，避免像 exchange.json 那样把密钥直接暴露在项目文件中。

直接在 Code Builder 中测试 Agent

部署就绪后，选择 Broker 即可看到填充好的 Agent Card，包括技能列表、描述和标签。演示者用 Chenai 到新加坡的航班查询做了实测：输入提示词后，Broker 开始推理，调用 Flight MCP Server 的 get flight details 工具，最终返回包含出发时间、到达时间、时长、价格和座位可用性的完整结果。

这意味着不再需要 A2A Inspector 或 Postman 之类的外部工具，测试闭环完全在 IDE 内完成。演示者表示会在 GitHub 仓库中分享测试用的提示词。

开发者体验层面的意义

这次更新的价值不在于某个单点功能，而在于把"发布-部署-等待-测试"的长链路替换成了"改-跑-看"的短循环。对于频繁迭代 Agent 逻辑的团队，这种本地化能力直接降低了验证成本，也让调试从黑盒变为可观测——ingress 和 egress 的配置、策略应用、工具调用过程都暴露在开发者眼前。

当然，本地环境终究只是开发验证的一环，生产部署仍需走云端流程。但对日常开发而言，这个改变已经足够实质。