作者：卢建晖 - 微软高级云技术布道师
排版：Alan Wang

改变一切的那个转变

过去两年里，“AI 编程”意味着自动补全。编辑器中出现一个建议，你按下 Tab 键，然后继续工作。智能体只会在你主动输入代码时存在。

如今，这已经不再是唯一的模式。一类新的工具正在以异步、自主的方式运行：你通过聊天窗口——Teams、Slack、Telegram——向智能体发送消息，描述你的需求，然后离开。智能体会自行规划、编写代码、运行测试、完成部署，并最终将结果交付给你。其中一些甚至永不休眠：它们拥有持久化记忆，能够加载自己的技能，并在无需提示的情况下按照计划执行任务。

这就是 OpenClaw、Hermes Agent 以及其他长时间运行自主智能体的世界。它们在 2026 年席卷了开发者社区。仅 OpenClaw 一项就获得了超过 37.7 万个 GitHub Star 和数百万活跃用户，并一度成为 GitHub 上 Star 数量最高的项目。你只需一行命令完成安装，连接一个聊天频道，然后就能直接通过手机开始委派任务。

工作流也从结对编程转变为任务委派与结果审查。交互式 Copilot 会问：“接下来我应该写什么？”而自主智能体会问：“你希望我完成什么？”

而正是这种思维模式的转变，让以下三个问题成为架构师们夜不能寐的原因：

1. 它安全吗？ 你正在赋予一个自动运行的进程执行 Shell 命令、修改文件和调用 API 的能力。一份社区报告曾形象地将这些智能体描述为群聊中的一位队友，而他恰好拥有代码库的 Root 权限。这并不是赞美，而是一种威胁模型。

2. 它能够融入真正的多智能体协作吗？ 单个智能体只是演示，生产环境需要的是一个智能体舰队——由多个专家型智能体组成，并在它们之间建立任务交接和控制机制。

3. 它是否足够灵活且可控？ 自主性令人兴奋，但前提是智能体不会把上周遗留下来的旧文件打包进本周的交付物，也不会因为一个失败的测试而陷入无限循环。

本文将回答这三个问题，而且不是纸上谈兵，而是通过一个你今天就能克隆并运行的参考实现：Multi-AI-Agents-Cloud-Native 仓库中的 CustomCodingAgentApp。它是一个“Agentic Prototype Factory（智能体原型工厂）”，能够将自然语言描述的想法直接转换成经过测试、运行在 Azure 上的原型应用，而整个过程无需离开聊天窗口。

产品经理只需在 Microsoft Teams 中输入“构建一个 BBC 风格的世界杯专题页面”。几分钟后，他们就能收到一个已经运行的 HTTPS 地址和可下载的源码 ZIP 包。在底层，五个由 Microsoft Foundry GPT-5.5 驱动的 OpenClaw 专业智能体会在共享沙箱中协作，运行真实的 pytest/Jest 测试套件，并将最终结果部署到 Azure Container Apps。而这一切都通过一个 **Model Context Protocol（MCP）**服务进行编排，因此任何 MCP 客户端（GitHub Copilot、Claude 或 Teams 机器人）都能够驱动整个流程。

接下来，我们将按照最适合学习的顺序逐步构建这套架构。

第 1 部分——长时间运行的自主智能体，以及它们面临的两个核心难题

它们究竟有什么不同

传统聊天机器人是“文本输入，文本输出”。它一直在等待你的指令。而自主智能体则完全颠倒了这种模式：

属性	传统聊天机器人	长时间运行的自主智能体
执行方式	响应提示词	主动执行（通过“心跳机制”定时唤醒）
作用范围	文本	文件、Shell、浏览器、API——真实计算环境
记忆能力	仅当前会话	跨会话持久保存
交互界面	Web 聊天框	任意聊天渠道 + 终端
自主性	无	自主规划并执行多步骤任务

从架构角度来看，OpenClaw 并不是一个可导入的库，而是一个运行时环境。一个长期运行的进程（Gateway）负责连接消息渠道与 LLM 后端，维持会话状态，在有序队列中管理任务，并驱动经典的智能体循环：调用模型 → 执行模型请求的工具调用 → 返回结果 → 重复执行直至完成。这里不存在固定的步骤规划器，真正负责决策的是模型本身。这既是它令人惊艳的原因，也是它难以约束的原因。

而这种约束问题主要体现在两个方面。

难题 #1 —— 安全性

正是那些让自主智能体变得强大的特性，也让它变得危险。完整系统访问权限 + 主动执行能力 + 一个包含 3.2 万台服务器工具的生态系统，共同构成了一个庞大的、自主运行的攻击面。OpenClaw 自身的发展历史就是最好的警示案例：项目早期曾出现一个严重的一键远程代码执行漏洞；其技能市场中发现了数百个恶意社区技能；并且研究人员在开放互联网中发现了数万个暴露在公网的 Gateway 实例。这些问题并不意味着“不要使用自主智能体”。它真正说明的是：永远不要在你重视的机器上，让智能体带着默认凭证直接运行。智能体应该被放置在一个有明确边界隔离的环境中运行。

难题 #2 —— 持久化与连续性

真实世界中的智能体任务往往持续时间很长。重构一个代码库、跨数十个网页进行研究、构建—测试—部署一个应用，这些任务通常需要数分钟甚至数小时，远远超出一次简单请求与响应的时间范围。因此，运行时环境必须具备持久化会话能力，需要能够保存状态的存储空间，以及一个能够跨步骤持续存在的工作区。但问题在于，一个被持续复用的持久化工作区也会带来新的风险：状态泄漏。昨天任务遗留下来的文件，可能会污染今天的任务结果，甚至被意外打包进今天的交付物中。连续性和清洁性天然存在冲突，而解决这种张力，正是系统架构设计必须面对的问题。

一个智能体只是演示；生产环境需要的是一个智能体团队

如果让一个庞大的单体智能体同时负责“收集需求、编写代码、运行测试、部署应用以及打包交付”，那么它很可能每件事都做得不够出色，而且各个阶段之间的边界也会变得模糊。生产环境采用的是编排器—工作器模式：由多个各司其职的专业智能体组成，并通过明确的任务关卡依次完成交接。OpenClaw 正是支持这种模式——它能够创建子智能体，甚至调度外部代码运行框架，充当的是一个元编排器，而不是单纯依赖一个模型。真正的问题从来不是“是否应该采用多智能体”，而是“应该在哪里划分职责边界，以及如何设置安全防护机制”。

对于“它安全吗？”这个问题，答案是：把智能体放进 MicroVM

如果智能体必须拥有 Root 权限才能真正发挥作用，那就赋予它 Root 权限——但应当是在一个可随时销毁的 MicroVM 中，而不是直接运行在宿主机上。截至 2026 年，已经有几种成熟可行的方案：

• Kata Containers on AKS —— 每个 Pod 都拥有独立的轻量级虚拟机边界和 Guest Kernel。

• Hyperlight Wasm —— 面向每次调用创建基于快照恢复的 Wasm MicroVM，用于运行由 LLM 生成的代码。

• Azure Container Apps Dynamic Sessions —— 基于 Hyper-V 隔离的预热沙箱，可在毫秒级启动，支持扩展到数千个实例，并专门面向“安全执行自定义代码”和“运行 LLM 生成的脚本”而设计。

其中最后一种——ACA 沙箱——是聊天驱动型智能体工厂的最佳选择：既具备强隔离能力，又无需自行维护 Kubernetes 集群，同时还提供 Exec API，可直接在沙箱内部执行命令。这也是本文参考实现所采用的方案。

第 2 部分——将 OpenClaw 部署到 ACA 沙箱中

从这里开始，这个项目不再只是架构示意图，而是真正可以运行的代码。Agentic Prototype Factory 将“一个想法 → 一个可运行应用”的整个流程拆分为五个按顺序执行的 OpenClaw 专业智能体，它们全部运行在同一个沙箱中：

requirements → coding → testing → deployment → save

OpenClaw Gateway 提供兼容 OpenAI API 的接口，因此每个智能体都可以作为独立的模型目标进行访问：

model 值	路由目标
openclaw / openclaw/default	默认智能体
openclaw/requirements-agent	需求智能体
openclaw/coding-agent	编码智能体
openclaw/testing-agent	测试智能体
openclaw/deployment-agent	部署智能体
openclaw/save-agent	保存与下载智能体

控制，而不是“凭感觉”：带反馈闭环的审核关卡

没有审核关卡的自主智能体，很容易出现这样的情况：智能体信心满满地部署了一个已经损坏的应用。因此，协调器会将这五个智能体组织成一个带有严格边界控制的执行流程图。

所有可调参数都在 server.py 中明确配置，例如：

_MAX_TEST_ROUNDS = 3

_MAX_DEPLOY_REVIEW = 2

_DEPLOY_POLL_ATTEMPTS = 12

_DEPLOY_POLL_DELAY_S = 20

测试智能体每轮执行结束时，都必须明确输出 TESTS_PASSED 或 TESTS_FAILED 作为最终判定。而协调器只有在完成以下两项检查之后，才会宣布部署成功：首先，对已部署的网址执行 HTTP 检查；然后，进一步检查返回的响应内容。这是因为，即使页面返回的是 HTTP 200，实际内容仍然可能只是一 ResourceNotFound 页面。这才是真正意义上的“灵活且可控”：LLM 可以在一个确定性的状态机中自由发挥创造力，而整个执行流程始终受到严格控制。

运行前进行确定性清理（解决状态泄漏问题）

由于 ACA 沙箱会在多次运行之间复用（速度更快、成本更低），因此编排器会在每次运行开始前执行一项严格的操作：清空所有遗留的智能体工作区。这样，上一次任务留下的陈旧文件就绝不会泄漏到新的任务中，也不会被错误地打包进新的交付结果。这正是针对第二个核心难题——状态泄漏的工程化解决方案。

顺应沙箱的限制，而不是与之对抗

ACA 沙箱的 Exec API 存在约 120 秒的硬性超时限制，这一时间不足以完成一次冷启动的 az acr build 加上 az containerapp create。如果采用最直接的实现方式，智能体就会因超时而报告失败。巧妙之处在于，即使客户端的 Exec 连接在约 120 秒后断开，这些命令仍会继续在 Azure 服务端执行直至完成。因此，部署流程被拆分为两个阶段：

1. deploy-build

   —— 安装部署辅助工具，生成精简的 .dockerignore 文件，并启动 ACR 镜像构建，将镜像标记为 <app>:latest。即使客户端在约 120 秒后断开连接，镜像仍会继续构建并最终上传至 ACR。

2. deploy-finish —— 该命令具有幂等性，最多轮询 12 次。当镜像尚未构建完成时，它会返回 STILL_BUILDING；一旦检测到镜像已存在，便执行带有 --no-wait 参数的 containerapp create 命令，最后返回 DEPLOYED_URL=https://<fqdn>。

这是整个示例中最重要的一点：自主智能体真正需要的不是更长的超时时间，而是理解其所运行平台的持久化执行语义。

第 3 部分——MCP，以及为什么它的安全性至关重要

五智能体工作流功能十分强大，但如果访问它的唯一方式只是一个专有 API，它就会成为一个孤立的系统。因此，该项目将整个编排流程封装为一个 Model Context Protocol（MCP）服务（acamcp_node），并通过 /mcp 提供基于 Streamable HTTP 的访问接口，同时仅暴露了一组简洁、清晰的工具接口：

MCP 工具	功能
generate_prototype	端到端运行完整的五智能体工作流
run_agent	调用指定名称的单个智能体
check_gateway_health	检查 OpenClaw Gateway 的存活状态与就绪状态

这样带来的收益非常巨大：任何 MCP 客户端现在都可以驱动整个原型工厂——GitHub Copilot、Claude，以及接下来将介绍的 Teams Bot 都可以使用它。一种协议，支持多个前端。

但 MCP 的意义并不仅仅在于方便系统集成，它本质上还是一个控制平面，而每一个 MCP 工具都代表着一种具有权限的能力。在一个拥有超过 3.2 万个社区 MCP Server 的生态中，“添加一个 MCP Server”实际上就是一次供应链安全决策。一次工具调用，本质上就是另一种形式的代码执行。因此，整个安全策略必须经过精心设计。下面介绍参考实现是如何对 MCP 进行安全加固的，而这些原则同样适用于任何 MCP 部署：

• 在协议入口之前进行身份认证。MCP 的入口部署在 Basic Authentication 之后（MCP_BASIC_AUTH_PASSWORD）；Gateway 本身也要求使用 Gateway Token 作为 Bearer 凭据（Authorization: Bearer <token>）。任何工具调用都必须经过身份认证，不允许匿名访问。

• 采用精简且明确的允许列表，而不是无限制开放。Gateway 仅允许路由到六个明确指定的模型目标。不存在“运行任意智能体”的后门，整个路由表本身就是允许列表。

• 工作负载中不保存任何密钥。运行中的容器内不存在任何模型 API Key，模型访问完全通过 Entra ID 托管身份完成代理；Gateway Token 则保存在 Kubernetes Secret 中，而不会被打包进镜像。

• 默认采用私有访问。Gateway 提供的 OpenAI 兼容接口属于运维级访问接口，仅开放私有入口，并在任何公网暴露之前就已经启用了 TLS 和身份认证。

• 身份权限遵循最小权限原则。Gateway 仅被授予访问 Foundry 所需的权限（Cognitive Services User / Cognitive Services OpenAI User），除此之外不具备任何额外权限。

对于 MCP 而言，结论与自主智能体完全一致：应当把协议视为一扇入口，并在入口处设置安全防护。身份认证、明确的允许列表、私有入口以及基于代理的身份机制，共同将 MCP 从一个开放的攻击面，转变为一个受到治理的控制平面。

第 4 部分——完整解决方案：Teams + ACA 上的 MCP + ACA 沙箱中的 OpenClaw

现在，将这三个可部署组件组合起来，形成一个完整的运行闭环：

请求生命周期：端到端流程

1. 产品经理只需在 Teams 中发送一句话。作为 MCP 客户端的 teamsbot_app（通过 mcpClient.ts）会发起 MCP 握手，并调用 generate_prototype。

2. 部署在 ACA 上的 MCP 服务（acamcp_node）启动整个编排流程：先执行运行前清理，然后依次调用需求分析 → 编码 → 测试。

3. 部署在 ACA 沙箱中的 OpenClaw Gateway（acasbxapp_node）负责执行各个智能体，并通过托管身份连接 Microsoft Foundry GPT-5.5，全程无需在运行环境中保存任何密钥。

4. 真实的 pytest 和 Jest 测试套件会在沙箱内运行。测试失败则进入受控的回退重试流程；测试通过则进入部署阶段。

5. 部署流程采用“构建 + 轮询”两阶段机制，以规避约 120 秒的 Exec 超时限制；应用随后部署到 Azure Container Apps，并在实际访问地址上执行带有响应内容校验的健康检查。

6. 保存与下载智能体会生成一个需要身份认证的 ZIP 下载链接。Bot 会将每个智能体的执行进度实时回传到 Teams 会话线程中，并最终返回可访问的 HTTPS 地址以及源码 ZIP，同时还可以选择自动在 VS Code Insiders 中打开该项目。

这套架构如何回答三大问题

问题	解决方案
是否安全？	自主智能体运行在采用 Hyper-V 隔离的 ACA 沙箱中，而不是开发者本地电脑上。运行环境中不保存任何模型密钥，所有对 Foundry 的访问均通过 Entra ID 托管身份完成代理。MCP 位于 Basic Authentication 之后，Gateway 位于采用 Bearer Token 保护的私有入口之后；Token 以 Secret 的形式存储，绝不会写入镜像。每次运行前都会执行确定性清理，彻底消除跨任务状态泄漏。
是否适用于多智能体协作？	它本身就是一个多智能体系统——由五个专用 OpenClaw 智能体组成，通过 A2A 交接与审核关卡协同工作。同时，由于整个系统通过 MCP 对外提供能力，GitHub Copilot、Claude、Teams 等任何 MCP 客户端都可以对其进行编排和调用。
是否足够灵活且可控？	创造力运行在一个确定性的状态机之中。系统使用明确的 TESTS_PASSED / TESTS_FAILED 判定结果、受限的重试次数（_MAX_TEST_ROUNDS、_MAX_DEPLOY_REVIEW）、基于响应内容的健康检查，以及 Teams 会话中的人工审批机制，共同保证整个流程既智能又可控。

自行部署

该项目提供了三层组件的完整部署脚本（Gateway 通过平台托管身份访问 Foundry，因此无需管理 API Key，也无需重新构建镜像）：

# 1) OpenClaw Gateway + 五个智能体（acasbxapp_node）
cd acasbxapp_node
cp .env.example .env   # 配置 Gateway Token、Foundry Endpoint、Sandbox ID
./scripts/build-openclaw-image.sh   # 构建并推送 OpenClaw 镜像至 ACR
./scripts/deploy-aks-gateway.sh     # 授予 Foundry 权限并完成部署

# 2) MCP 服务（acamcp_node）
cd ../acamcp_node
cp .env.example .env   # 配置 ACR 与集群；Gateway Token 从 ../acasbxapp_node/.env 中读取
./scripts/build-images.sh           # 构建并推送 MCP 镜像
./scripts/deploy-aks.sh             # 将 Secret 与 Kubernetes 清单部署到 openclaw 命名空间
./scripts/smoke-check.sh            # 验证 MCP 握手是否正常

# 3) Teams Bot（teamsbot_app）—— Node.js / TypeScript MCP 客户端
cd ../teamsbot_app
# 按照该目录 README 完成配置并启动，然后将 Teams 应用包侧载到 Teams 中

该参考实现基于 Azure（ACA + AKS）构建：OpenClaw Gateway 和 MCP 服务均以容器形式运行，而代码执行沙箱则采用 ACA Dynamic Sessions 的 Exec API。建议始终将 Gateway 部署在私有入口之后，并在任何公网暴露之前配置 TLS。

总结

抛开世界杯演示案例不谈，这套方案沉淀出了一种可复用的架构模式——一套适用于企业级长生命周期自主智能体的参考蓝图：

一个消息驱动的智能体（OpenClaw / Hermes）+ 一个 MicroVM 沙箱（Azure Container Apps Dynamic Sessions）+ 一个具备身份认证能力的 MCP 控制平面 + 企业身份体系（Entra ID 托管身份）+ 一个面向用户的人机交互界面（Microsoft Teams）。

正是自主执行能力让这类智能体迅速走红，也正是这种自主能力让企业安全团队心存顾虑。解决这种矛盾的方法，并不是降低智能体的自主性，而是为它提供一个拥有坚固边界的运行沙箱、一个受安全保护的控制平面、一套基于身份而非密钥的认证机制，以及始终保留人工参与的审批环节。做到这些之后，“产品经理发送一句话，Azure 自动部署一个应用”就不再只是一个令人担忧的演示，而是真正能够投入生产环境的企业级解决方案。

欢迎克隆项目、尝试实践、不断完善：kinfey/Multi-AI-Agents-Cloud-Native → code/CustomCodingAgentApp

聊天窗口正在成为新的终端。让我们共同把它打造得既智能，又安全。