排版：Alan Wang
改变一切的那个转变
于过去的两年时间当中, "AI编程"所代表的是自动补全, 在编辑器里会出现一条建议, 你按下Tab键后, 接着继续开展工作, 智能体仅仅是在你主动去输入代码之际才会存在。
现在, 这已然并非是独一无二的模式了。有一类全新的工具正于持异步、自主的状态去运行着: 你借助聊天窗口, 也就是Teams、Slack, 朝着智能体发送消息, 对自身需求予以描述, 而后离去。智能体会自行开展规划, 进行代码编写, 实施运行测试, 达成部署事宜, 并且最终把结果交付给你。其中有一些甚至从不休眠停滞: 它们具备持久化记忆, 能够加载自身技能, 且在没有提示的状况下依照计划执行任务。
这便是 、 Agent 以及别的长时间运行自主智能体所处的世界 , 它们于 2026 年风靡了开发者社区 , 仅 一项便收获了超过 37.7 万个 Star 以及数百万活跃用户 , 还曾一度成为 上面 Star 数量最为庞大的项目 , 你只需要通过一行命令来实现安装 , 连接一个聊天频道 , 接着就能凭借手机直接着手委派任务。
工作流发生了转变, 从结对编程转变成了任务委派以及结果审查。交互式的会问这样的问题: "接下来我应当去写些什么? "而自主智能体会问: "你期望我达成什么? "。
正是这种思维模式发生了转变, 使得以下这三个问题, 变成了架构师们, 夜不能寐的缘由:
它是否安全呢? 你正给予一个自动运行的进程具备执行Shell命令、修改文件以及调用API的能力, 一份社区报告曾把这些智能体颇为形象地描述成群聊里的一位队友, 且他恰巧拥有代码库的Root权限。这并非是赞美, 而是一种威胁模型。
它可不可以融入切实的多智能体协作呢? 单独的智能体仅仅是做演示, 而生产环境所需求的乃是一支智能体舰队, 这支舰队由众多专家型智能体构成, 并且要在它们相互之间构建起任务交接以及控制机制。
它是不是足够灵活, 以至于能够被把控呢? 自主性让人感到兴奋, 可是, 前提在于, 智能体不会把上周留存下来的旧文件, 收纳进本周的交付物品当中, 并且, 也不会由于一个失败了的测试, 从而陷入没有尽头的循环里。
针对这三个问题, 本文会予以回答, 并非仅作理论空谈, 而是借助一个现今你能够进行克隆以及运行的参考实现方式:
位于 Multi - AI--Cloud - 仓库里的它, 是个称作" （智能体原型工厂）"的存在, 它可以把用自然语言表述的想法, 直接转变为经过测试的、运行于 Azure 上的原型应用, 并且整个过程都不用离开聊天窗口。
需在Teams里输入这样一句话, 即"构建一个BBC风格的世界杯专题页面", 产品经理要做的仅为此事。几分钟后, 他们将会收到一个已然运行着的HTTPS地址, 以及一个可用于下载的源码ZIP包。在底层部分, 五个由GPT - 5.5驱动的专业智能体, 会于共享沙箱之中展开协作, 运行真实的/Jest测试套件, 随后将最终结果部署到Azure Apps。而这所有的一切, 是借助一个Model （MCP）服务来开展编排工作的, 故而不论是 类型的MCP客户端、 类型的MCP客户端, 亦或是Teams机器人, 都有能力去驱动整一个流程。
接下来，我们将按照最适合学习的顺序逐步构建这套架构。
第1部分, 是长时间运行的自主智能体, 还有它们所面临的两个核心难题。
它们究竟有什么不同
被称为传统聊天机器人的存在, 呈现的是"文本输入, 文本输出"这种形态, 它始终处于等待你下达指令的状态, 然而自主智能体却将这种模式彻底进行了颠倒:
属性
传统聊天机器人
长时间运行的自主智能体
执行方式
响应提示词
主动执行（通过"心跳机制"定时唤醒）
作用范围
文本
文件、Shell、浏览器、API------真实计算环境
记忆能力
仅当前会话
跨会话持久保存
交互界面
Web 聊天框
任意聊天渠道 + 终端
自主性
自主规划并执行多步骤任务
从架构的角度去看, 它并不是那种能够进行导入的库, 实际上是一种运行时的环境, 有一种长期运行着的进程, 这个进程肩负着连接消息渠道以及LLM后端的责任, 还要持续维持着会话的状态, 在有序的队列以内去管理任务, 并且驱动经典的智能体循环, 具体就是调用模型, 接着执行由模型请求的工具调用, 之后返回结果, 随后反复执行, 一直到任务全部完成, 在这里并不存在固定的步骤规划器, 真正承担决策职责的是模型自身, 这既是它让人感到惊艳的因素, 也是它难以受到约束的缘故了。
而这种约束问题主要体现在两个方面。
难题 ------ 安全性
那种致使自主智能体强大起来的特性, 同样致使它变得危险。完整系统访问权限, 加上主动执行能力, 再加上一个涵盖 3.2 万台服务器工具的生态系统, 一道构成了一个庞大的、能自主运行的攻击面。其自身的发展历程就是非常绝妙的警示事例: 在项目早期存在过一个极为严重的一键远程代码执行漏洞；在其技能市场发觉了数百个恶意社区技能；而且研究人员于开放互联网当中发现了数万个暴露在公共网络的实例。这些难题并不表明"不要运用自主智能体"。具体而言, 它所切实表明的是, 不论何时, 都绝对不要于你所极为看重的机器之上, 让智能体依据默认凭证径直运行。并且, 智能体应当被安置于一个具备清晰边界从而实现隔离的环境里去运行。
难题 ------ 持久化与连续性
从事智能体任务, 所在的是真实世界, 其任务持续时间常常很长, 比如重构代码库, 比如跨数十个网页展开研究, 比如构建、测试、部署一个应用, 这些任务通常得耗费数分钟, 甚至数小时, 这时间远远超出了一次简单请求与响应的时间范围。所以, 运行时环境必须拥有持久化会话的能力, 要有能保存状态的存储空间, 还要有一个可跨步骤持续存在的工作区才行。然而, 存在的问题是, 一个被持续复用的持久化工作区会带来新的风险, 也就是状态泄漏。昨晚任务所遗留下的那些文件，极有可能对今日任务的相应结果造成污染, 甚而会被意外地打包进今日的交付物品当中。连续性跟清洁性在天然的状态下便存在着冲突, 然而要去解决这种张力, 恰恰是系统架构设计必然要面对的一个问题。
一个智能体只是演示；生产环境需要的是一个智能体团队
倘若致使一个规模巨大的单体智能体同时去负责, 收集需求、编写代码、运行测试、部署应用以及打包交付这些事项, 那么它极有可能针对每一件事情都做得并非足够出色, 并且各个阶段之间的界限也会变得含混不清。生产环境运用的是编排器---工作器模式, 该模式由多个各自履行职责的专业智能体所构成, 并且借助清晰明确的任务关卡依照次序完成交接。正是支撑这般模式, 它能够创建子智能体, 甚至调度外部代码运行框架, 充当的是一个元编排器, 而非仅仅依赖一个模型。实际的难题向来都不是"是不是要运用多智能体", 而是"职责界限该在何处去划分, 还有安全防护机制要怎样去设立"。
对于"它安全吗？"这个问题，答案是：把智能体放进
要是智能体非得具有Root权限方可切实发挥其作用, 那就给予它Root权限, 不过这应当是在一个能够随时予以销毁的环境裹而已, 并非是直接在宿主机上去运行的。截止到2026年, 已然存在好几种成熟且可行的方案。
其中, 最后一种, 也就是名为 ACA 沙箱的, 是聊天驱动型智能体工厂的最佳选择, 它具备强隔离能力, 它无需自行维护集群, 它还提供 Exec API, 能够直接在沙箱内部执行命令。此外, 这也是本文参考实现所采用的方案。
第 2 部分------将 部署到 ACA 沙箱中
自此处起始, 此项目已不再单单是架构示意图了, 而是切实能够运行的代码。把"一个想法→一个可运行应用"的整个流程划分成五个依照顺序来执行的专业智能体, 它们全都运行于同一个沙箱之中:
requirements → coding → testing → deployment → save提供具备兼容性的、针对 API 的那种接口, 所以呢, 每一个智能体, 都能够当作是独立的、作为模型目标的存在来进行访问:
model 值
路由目标
/ /
默认智能体
/-agent
需求智能体
/-agent
编码智能体
/-agent
测试智能体
/-agent
部署智能体
/save-agent
保存与下载智能体
控制，而不是"凭感觉"：带反馈闭环的审核关卡
不会有审核关卡存在的自主智能体, 极易出现如下状况: 智能体满怀信心地去部署一个已然损坏的应用。所以, 协调器会把这五个智能体组合成一个具备严格边界控制的执行流程图。
所有可调参数都在 .py 中明确配置，例如：
= 3、 = 2、S = 12、 = 20
每轮测试智能体执行完毕告终时, 都务必要确切地给出输出或者当作结局判定。而协调器唯有在实行完下面所讲的这两项查验之后, 才会宣告部署达成: 其一, 针对已部署的网址施行HTTP检查；其二, 加以进一步查验返回的响应内容。之所以如此, 是鉴于就算页面返回的是HTTP 200, 实际的内容依旧有可能仅仅只是一个页面而已。这方可算是真正层面上的"灵活又可控": LLM能够于一个具有确定性的状态机当中任意施展创造力, 然而整个执行的流程始终都处于严格的把控之下。
运行前进行确定性清理（解决状态泄漏问题）
存在这样一种情况, ACA 沙箱具备在多次运行之间进行复用的特性, 复用的好处是速度更快、成本更低。基于此情况, 编排器会在每次运行开始之前执行一项操作, 此项操作十分严格, 具体为清空所有遗留的智能体工作区。通过这样做得以实现, 上一次任务之中留下的陈旧文件, 绝不会泄漏到新的任务里面, 同时也不会被错误地打包进新的交付结果当中。这一做法, 恰恰就是针对第二个核心难题, 也就是状态泄漏的工程化解决方案。
顺应沙箱的限制，而不是与之对抗
ACA沙箱的Exec API有着大约一百二十秒的强制性超时限定, 这一时长没办法达成一回冷启动的az acr build加上az , 要是采用最径直的实现形式, 智能体就会由于超时而汇报失败, 美妙之处在于, 哪怕客户端的Exec连接在约一百二十秒之后断开, 这些指令依旧会持续在Azure服务端执行直至完毕, 所以, 部署流程就被划分成了两个阶段。
-build
.文件，并启动 ACR 镜像构建，将镜像标记为
这项命令具备幂等特性、最多进行12次轮询。当镜像还没构建完毕的时候, 它会给出返回。一旦查证该镜像早已存在了, 那么就会去执行携带 --no - wait参数所指代的命令, 最终返回 =https://。
在整个示例里, 存在着极为关键的一点, 那就是在那个地方: 自主智能体切实需要的, 并非是增加延长了的超时时间, 而是要去领会理解它正在运行的那个平台所具备并遵循的持久化方面的执行语义。
第 3 部分------MCP，以及为什么它的安全性至关重要
五智能体工作流具备极为强大的功能, 可是倘若对其进行访问的唯一途径仅仅是一个专有 API, 那它便会演变成一个孤立的系统, 所以, 该项目把整个编排流程封装成一个 Model （MCP）服务, 并且经由 /mcp 提供基于 HTTP 的访问接口, 同时仅仅展现出一组简洁且清晰的工具接口:
MCP 工具
功能
端到端运行完整的五智能体工作流
调用指定名称的单个智能体
检查 的存活状态与就绪状态
存在这样一种情况, 其带来的收益极为宽泛可观 , 那便是任何MCP客户端当下能够驱动整个原型工厂, 还有接下来即将介绍的Teams Bot也能够运用它 , 它是一种支持多个前端的协议。
然 MCP 之意义, 非仅在于便利系统集成, 其本质乃为一控制平面, 且每一 MCP 工具皆代表一种具权限之能力。于一包含超 3.2 万个社区 MCP 之生态里, "增添一个 MCP"实际即为一次供应链安全决策。一次工具调用, 本质亦而为另一种之代码执行形式。是以, 整个安全策略必须经由精心设计。如下所示参考实现是怎样对 MCP 施行安全加固的, 且这些原则同样适用于任何 MCP 部署:
对于 MCP 来说, 其结论跟自主智能体全然一样: 要把协议看成是一扇入口之处, 且在该入口的地方设置安全防护举措。身份认证这一行为, 明确的允许列表这种情况, 私有入口这般事物, 还有基于代理的身份机制这个方面, 一同把 MCP 从当作一个开放的攻击面的状态, 转变成为一个受到治理的控制平面的情形。
第4部分, 完整解决方案, 是关于Teams加ACA之上的MCP, 以及ACA沙箱之中的。
现在，将这三个可部署组件组合起来，形成一个完整的运行闭环：
请求生命周期：端到端流程
产品经理仅需于Teams里发送一句话, 身为MCP客户端的（借助.ts）会启动MCP握手, 并且进行调用。
部署于 ACA 之上的 MCP 服务, （）开启整个编排进程呐: 先是开展运行前的清理操作, 接着依照顺序逐个调用需求分析, 而后进行编码, 最后实施测试。
部署于 ACA 沙箱里的, 某事物是这样的, 什么事物呢, 它负责去执行各个智能体, 还要那般, 通过托管身份连接 GPT - 5.5, 而且全程不需要在运行环境当中保存任何密钥, 是这样的情况。
实实在在的, 以及 Jest 测试套件会于沙箱之内运行。要是测试失败, 那么就会进入受到管控的回退重试流程；要是测试通过, 那么便会进入部署阶段。
构建与轮询这两个阶段的机制被用于部署流程, 以此来避开大约120秒的Exec超时限定, 应用接着被部署到Azure Apps, 在实际的访问地址那儿执行带有响应内容校验的健康检查。
生成一个需身份认证的ZIP下载链接来保存与下载智能体, Bot会将各智能体的执行进度实时回传到Teams会话线程里, 最终返回可访问的HTTPS地址以及源码ZIP, 并且还能够选择自动在VS Code中打开该项目。
这套架构如何回答三大问题
问题
解决方案
是否安全？
自主智能体运行的地方是采用 Hyper-V 隔离的 ACA 沙箱, 并非开发者的本地电脑。运行环境里不会保存任何模型密钥, 所有针对的访问都是借助 Entra ID 托管身份去完成代理的。MCP 处在 Basic 的后面, 处于采用 Token 保护的私有入口后面；Token 是以的形式来存储的, 绝对不会被写入镜像。每次运行之前都会开展确定性清理, 将跨任务状态泄漏彻底消除掉。
是否适用于多智能体协作？
它自身是个多智能体系统, 此系统由五个专用智能体构成, 这些智能体经由 A2A 交接与审核关卡协同开展工作。与此同时, 鉴于整个系统借助 MCP 对外供给能力, 、、Teams 等任意 MCP 客户端均可对其予以编排以及调用。
是否足够灵活且可控？
创造力于一个具有确定性的状态机里运行, 系统运用明确的判定结果, 有着受限的重试次数, 有基于响应内容的健康检查, 还有Teams会话里的人工审批机制, 这些共同确保整个流程既具备智能性又拥有可控性。
自行部署
该项目给出了三层组件的完备部署脚本, 通过平台托管身份去访问, 所以不需要管理API Key, 并且也不用重新构建镜像了:
# 1) OpenClaw Gateway + 五个智能体（acasbxapp_node）cd acasbxapp_nodecp .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_nodecp .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）来构建的, 其中, 和MCP服务都是以容器的形式去运行的, 而代码执行沙箱采用的是ACA的Exec API, 在这里建议, 始终要把部署在私有入口之后, 并且在任何公网暴露之前去配置TLS。
总结
把世界杯演示案例放置一旁不去谈论, 这套方案沉淀生成了一种能够进行复用的架构模式, 这是一套适用于企业级长生命周期自主智能体的参考蓝图。
一个由消息驱动的智能体, 加上一个沙箱（Azure Apps）, 再加上一个拥有身份认证能力的 MCP 控制平面, 加上企业身份体系（Entra ID 托管身份）, 加上一个面向用户的人机交互界面（Teams）。
令这类智能体迅速走红的, 恰恰是自主执行能力, 而让企业安全团队心存顾虑的, 也正是这种自主能力。解决此种矛盾的办法, 并非削减智能体的自主性；而是要给它提供一个具备坚固边界的运行沙箱, 一个受安全掩护的控制平面, 一套基于身份而非密钥的认证机制, 以及始终留有人工参与的审批环节。达成这一切以后, "产品经理发出一句话, Azure自动部署一个应用"便不再只是令人忧心的演示, 而是切实能够投入生产环境的企业级解决方案。
欢迎克隆项目、尝试实践、不断完善：
/Multi-AI--Cloud- → code/
正成为新终端的是聊天窗口, 让我们一起精心地把它打造成既具备智能特性, 又拥有安全保障措施的样子。
/Multi-AI--Cloud- → code/