技术速递｜云原生多智能体实践：基于 Kars 在 Kubernetes 上安全运行智能体

MicrosoftReactor

77人浏览 · 2026-08-12 00:32:58

MicrosoftReactor · 2026-08-12 00:32:58 发布

云原生多智能体实践：基于 Kars 在 Kubernetes 上安全运行智能体

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

排版：Alan Wang

https://techcommunity.microsoft.com/blog/azuredevcommunityblog/cloud-native-multi-agent-running-agents-safely-on-kubernetes-with-kars/4543047/?wt.mc_id=3reg_webpage_reactor

为什么云原生与多智能体正在走向融合

从“一个聊天机器人”到“一支智能体工作队列”

一次单独的 LLM 调用，本质上是一个无状态函数：输入文本，输出文本。而多智能体系统则完全不同——它是一组长期运行的进程，能够进行规划、调用工具、生成辅助智能体、彼此通信，并在没有人工参与的情况下持续工作数分钟甚至数小时。一旦你赋予智能体真正的工具能力，你也同时赋予了它真正的凭证，以及真正的网络访问能力。这正是为什么这个问题如此困难的根本原因。

在实际生产环境中，一个智能体通常具备以下特征：

长期运行：它不是简单的请求/响应接口，而是会维护会话、进行重试，并在生命周期内发起大量下游调用。
自主决策：它会自己决定何时调用哪个工具，而不是由开发者手写控制流程。
具备工具与网络能力：它会读取文件、调用 API、抓取网页，并且越来越多地开始调用其他智能体。
会被复制和扩展：一个“任务”通常并不对应一个智能体，而是一条流水线——研究员把结果交给写作者，写作者再交给审查者。

这种“长期运行、自主决策、联网、可扩展”的特征，实际上与微服务集群高度一致。因此，运维层面的答案不断落到同一个地方：Kubernetes。企业已经非常熟悉如何为微服务提供：身份、网络策略、密钥管理、配额、可观测性，以及 GitOps。最自然的演进方式，就是让智能体也遵循与其他服务相同的运维纪律，而不是再发明一套平行且缺乏监管的运行时体系。

企业级部署的核心问题：爆炸半径

关于多智能体系统部署，有一个令人不舒服的事实：**只要一个被提示词注入攻陷的智能体能够访问某些资源，它就可能访问这些资源所能触达的一切。**如果智能体持有 Azure Key，提示词注入就可能窃取它。如果智能体拥有开放的网络出口，一个被污染的文档就可能把它变成数据外传通道。如果智能体还能以相同权限创建子智能体，那么一次入侵就会扩散成多次入侵。

安全领域对最危险的模式有一个经典称呼：“致命三重因素”，它同时具备：

访问私有数据
接触不可信内容（网页、邮件、待总结的文档等）
拥有向外发送数据的能力

而一个通用智能体框架，往往默认同时具备这三项能力。2026 年 1 月曾公开讨论过一起真实案例：针对智能体“协同工作”流程的文件外传攻击。这正是整个安全治理体系试图防止的典型事件。（Kars 甚至提供了该攻击的复现实验，后文还会提到。）

因此，企业真正的问题并不是：

“智能体能不能完成这个任务？”

而是：

“当这个智能体被攻陷时——不是‘是否会被攻陷’，而是‘被攻陷之后’——它的爆炸半径有多大？谁能够证明影响被成功隔离了？”

长期运行的第三方智能体框架的特殊风险

大多数团队并不会从零编写智能体。他们通常会采用现成框架，例如：OpenClaw、Hermes、OpenAI Agents SDK、Microsoft Agent Framework，以及 LangGraph 等。这些框架极大提升了开发效率，但也从三个方面改变了安全模型。

自主运行的代码不是你写的。第三方 Harness 会在你无法完全控制的循环中自行决定工具调用行为。你审查了自己的 Prompt，并不代表你审查了它的工具调度逻辑。
它们天生就是长期运行的。像 Hermes 这种“以消息通道为中心”的框架，本来就是为了长期驻留在 Telegram、Slack 等频道中，对任何新消息持续做出响应。而“长期运行”+“响应不可信输入”，恰恰是“致命三重因素”最容易出现的环境。
它们会引入插件和依赖。每一个插件、MCP Server、Tool 都会带来新的供应链攻击面，以及网络出口攻击面。

错误的应对方式，是直接 fork 并修改框架源码。这样做会带来沉重的维护负担，并且很容易落后于上游安全修复。正确的做法是：把框架本身视为一个不可信租户，并把安全控制放在框架之外。核心原则包括：智能体内部不保存凭据，智能体不拥有自己的网络，所有外部调用都必须经过代理与审计。这正是 Kars 采用的设计理念。也因此，Kars 能够在不修改、补丁或 Vendor 化源码的前提下运行 OpenClaw 与 Hermes——任何上游新版本都可以直接替换。

Token 使用已经成为一级生产治理问题

有两件事让 Token 成本不再只是“账单备注”。

自主性会放大消耗。一个会循环、重试、生成子智能体的系统，其 Token 消耗往往是非线性增长的。失控循环不仅是成本事故，也可能演变为可用性事故（级联故障）。
多租户环境需要公平性。如果 10 个团队共享同一个 Kubernetes 集群，那么某一个团队的失控智能体绝不能拖垮其他团队。

因此，生产环境必须具备：每次请求的 Token 上限，每个租户的每日 / 每月 Token 配额，以及请求速率限制。并且这些限制必须在请求离开 Pod 之前生效。超限时，应直接返回 HTTP 429。事后查看下个月账单并不算治理，那只是“事后尸检”。

“上线前怎么验证？”——Go-Live 验证问题

在智能体正式上线之前，安全团队必须能够基于证据回答以下问题：

智能体是否真的没有任何长期凭证？
网络出口是否真的只允许访问白名单主机？
内容安全策略是否真的能拦截 Jailbreak？
如果输入一个被污染的文档，隔离机制是否真的有效？
YAML 中写的策略，是否真的是当前运行时正在执行的策略？

唯一可信的答案是：可复现的测试。理想情况下，本地和云端应当使用相同的 Pod 结构，相同的策略，以及相同的审计格式，并配合可重放的攻击样本库和防篡改的证明。“演示里运行成功了”不是上线证据。“这是可重放的证据，证明所有 N 层防护都成功生效”才是。

最后一个问题：如何真正部署到云端？

生产级智能体平台绝不只是“一个容器”。它还需要：镜像仓库，支持工作负载身份的 Kubernetes 集群，具备内容安全能力的模型后端，智能体间消息中继，对外提供跨组织调用的入口。很多团队最大的痛点在于：**开发环境和生产环境是两套完全不同的系统。**于是，本地测试通过的东西，并不一定真正上线。理想模式应该是：**从笔记本到云端只有一个统一的心智模型。**环境升级只需要“一行配置变化”，而不是重新迁移整个平台。

接下来，我们将看到一个开源技术栈如何用同一套设计同时解决上述六类问题。

Kars：微软面向 Kubernetes 的开源智能体参考栈

一句话介绍

Kars（Agent Reference Stack for Kubernetes） 是微软 Azure Cloud Native 团队推出的开源智能体运行栈，用于在 Kubernetes 上安全运行 AI 智能体。它的核心理念可以概括为一句话：每个智能体一个加固沙箱，智能体内部零凭证，所有外部调用都受到治理。 任何离开智能体的数据，都会经过一个运行在 Pod 内部的 Rust 推理路由器，由它统一执行身份认证、内容安全、Token 预算控制、工具策略、网络出口规则，以及防篡改审计日志。不同框架实现的智能体，则通过端到端加密的 Mesh 网络进行通信。整个系统从本地 Kubernetes 到 AKS，都可以使用同一套 CLI 与资源定义进行管理。

最核心的设计：信任边界是 Pod，而不是集群

这是 Kars 最重要的设计决策，也是它区别于传统“集群边缘网关”的关键。

在这里插入图片描述

请仔细理解这个模型，因为几乎所有安全属性都源于它：

智能体容器没有自己的网络。它只能访问 localhost。任何访问模型、工具，以及其他智能体的请求，都必须经过 Router。
Router 使用独立身份运行。Router 运行在不同的 UID 下（例如 Router 为 1001，而 Agent 为 1000）。真正的云凭证保存在 Router 中，智能体进程永远无法直接看到 Azure Key。
Init Container 安装网络隔离规则。一个名为 egress-guard 的 Init Container 会安装 iptables 规则，使智能体 UID 只能访问本地 Router。同时，Kubernetes 的 NetworkPolicy 会阻止 Pod 间横向移动。Router 是主要的策略执行点，而这些网络规则则是防止绕过 Router 的第二道安全网。

最终带来的保证是：即使智能体本身被完全攻陷，也不会进一步攻陷云账号、模型服务、审计日志或其他智能体。 即使存在一个完美的 Prompt Injection Payload，能够读取智能体进程能读取的所有字节，它依然无法窃取 Azure Key——因为智能体内部根本不存在这些密钥。

为什么这不是“另一个 API Gateway”。传统 API Gateway 管理的是集群边界的南北向流量。而 Kars 的 Router 是：运行在 Pod 内部、位于智能体与外部世界之间的本地策略执行点。因此它能够实现每个智能体独立身份、每个沙箱独立内容安全策略、每个智能体独立预算控制，以及每个智能体独立审计链。这些能力是共享边缘网关无法做到的。两者并不冲突：集群边缘网关负责整体入口，Kars Router 负责每个智能体沙箱内部的精细治理。

零信任核心：Inference Router 实际执行什么

Per-Pod Router 是整个安全模型的核心。它所执行的每一项能力，都直接对应前文提到的风险问题：

在这里插入图片描述

多运行时：你的框架，无需修改，运行在加固沙箱中

kars 本质上是一个 智能体运行时宿主平台。所谓运行时，就是你的智能体代码所依赖的框架，再加上一个将其接入沙箱环境的小型适配器。在 kars 中，切换运行时只需要修改 KarsSandbox.spec.runtime.kind 这一个字段。无论使用哪种框架，它们都会共享：相同的 Router，相同的治理配置，相同的审计链，以及相同的 NetworkPolicy。

当前已支持的运行时：

OpenClaw（默认运行时）——它在 Mesh 之上还提供了两个多智能体辅助能力：
- 子智能体继承：新生成的子智能体会自动继承父智能体的 Provider、模型、Endpoint 和凭据绑定配置。
- 同伴角色列表：每次生成子智能体时都会指定角色，例如“数据分析师”或“技术写作者”，智能体之间会按照角色互相通信，这对于“分析师 → 可视化 → 写作者”这类流水线非常重要。
Hermes——这是一个以消息通道为中心的智能体 Harness，原生支持 MCP。如果你希望快速构建一个基于 Telegram 或 Slack 驱动的智能体，而不想自己编写集成逻辑，Hermes 会非常合适。Hermes 会加入与 OpenClaw 相同的加密 Mesh 网络，并且 kars_mesh_send 可以在 OpenClaw 与 Hermes 智能体之间双向通信。这种跨运行时互操作性会在每次代码提交时进行端到端验证。
其他已支持运行时：
- OpenAI Agents SDK
- Microsoft Agent Framework（Python）
- LangGraph（Python 与 TypeScript）
- Anthropic Claude Agent SDK
- Pydantic-AI
- BYO（Bring Your Own）：只要遵循一个简单约定，任何容器都可以作为运行时接入。

这些适配器会完成三件看起来不显眼、但实际上至关重要的事情：

固定模型访问入口。它会把模型的 Base URL 强制指向本地 Router：
http://127.0.0.1:8443，这样 SDK 从物理层面就无法直接访问公网模型服务。
替换真实 API Key。它会使用一个占位符：ROUTED-VIA-KARS，因此智能体内部永远不会保存真实云凭据。
自动接入平台基础设施适配器还会自动完成：
- 联邦身份
- OpenTelemetry
- Mesh 注册

这就是为什么第三方智能体框架可以完全不修改源码地运行，同时依然受到统一治理。

API 就是 YAML：安全团队审查 YAML，而不是 Python

在 kars 中，运维人员配置的所有内容，本质上都是 Kubernetes Custom Resource。这是一个刻意的设计选择。审批流程、限流规则、工具白名单、内容安全等级、Token 预算以及智能体之间的信任拓扑，都会变成可声明式定义的资源，提交到 Git 仓库中的 YAML 文件，通过 Argo / Flux 持续对账，并通过 Git Log 进行审计。

你真正会编写的 10 个工作负载 CRD：
在这里插入图片描述

策略是可验证、可签名、不可篡改的，kars 支持使用 **OCI 不可变 Digest 和 cosign 数字签名 **来固定策略内容。控制器会验证签名，重新规范化策略内容，并在 Router 加载之前再次计算 Digest。只有当 Router 回报的 Digest 与控制器验证的 Digest 完全一致 时，对应 CRD 才会进入 Ready 状态。也就是说：**YAML 中的内容 = 控制器验证过的内容 = 运行时真正执行的内容。**只要三者有任何不一致，资源就不会 Ready。

九层安全防护（纵深防御）

kars 采用的是 分层控制平面。每一层都能够独立限制爆炸半径，而多层叠加之后，才能实现：**“一次入侵”不会变成“全面失守”。**下面是在真实 AKS 集群上的一次在线验证中使用的九层安全模型。

在这里插入图片描述

这些能力如何对应上一部分的问题

在这里插入图片描述

在 Kars 上规划一个财经短视频生产流水线

在这里插入图片描述

现在让我们把这些概念落到一个更具体的场景中。下面是一个完整的示例：基于多智能体系统自动生成财经新闻短视频（“财经短视频”）。这个示例主要用于说明 Kars 的能力（Kars 官方提供的是通用示例，而不是这一套完整业务），但下面涉及的每一个资源与命令都是真实存在的 Kars API。之所以这个场景非常适合作为 Kars 的示例，是因为它同时具备了最棘手的几类生产特征：

不可信输入内容：市场新闻、公告、研报等外部数据源；
受监管输出：财经内容通常需要合规审查；
高成本生成：长脚本、图像、配音、视频渲染都会消耗大量 Token 与算力；
天然的多智能体协作链路：新闻采集 → 分析 → 文案 → 审核 → 视频生成 → 发布。

在这里插入图片描述

把流水线拆成一支“智能体工作队列”

一个“财经短视频工厂”天然就是由多个专业角色组成的流水线：

在这里插入图片描述

其中，每一个方框都对应一个 KarsSandbox。各个智能体之间通过 加密 Mesh 网络 进行交接，并使用 OpenClaw 的同伴角色列表来通信。也就是说，智能体之间是按角色协作的，例如：“把已审核脚本发送给配音智能体。”这正是 Kars 中 子智能体继承与角色列表所设计要解决的典型场景——分析师 → 写作者 → 审核者。

每个智能体对应的运行时与风险模型：

在这里插入图片描述

为什么发布器选择 Hermes？因为 Hermes 是一个以消息通道为中心的智能体 Harness。它非常适合对接 Telegram、Slack，以及各类内容发布平台。更重要的是，它与 OpenClaw 流水线之间的 加密 Mesh 互操作 是 Kars 官方支持并持续测试的能力。例如 Scriptwriter（OpenClaw）完成脚本，或通过 kars_mesh_send 将“已审核完成的视频包”发送给 Publisher（Hermes）。在这个过程中，你看不到传输中的明文，微软看不到，中继服务也看不到。所有跨智能体通信都以 端到端加密密文 的形式在 Mesh 中传递。

Token 规划：在真正发生消耗的地方治理成本

Scriptwriter 通常是整个系统中最容易消耗 Token 的热点，因此应该为它配置明确的 Token 预算。在 kars 中，每个 Sandbox 都必须引用一个 InferencePolicy，模型路由、内容安全等级以及 Token 预算都定义在这个策略中。

apiVersion: kars.azure.com/v1alpha1
kind: InferencePolicy
metadata:
  name: scriptwriter-inference
  namespace: finvideo
spec:
  appliesTo:
    sandboxName: scriptwriter
  modelPreference:
    primary:
      provider: azure-openai
      deployment: gpt-4.1
  inference:
    contentSafety: true          # Foundry 内容过滤 + Prompt Shields
    contentSafetyMinimum: Medium # 不能低于集群最低安全等级（Admission 阶段会拒绝）
  # Token 预算由 Router 强制执行：请求级上限 + 租户级日/月配额
  # 超限返回 HTTP 429 —— 对应第 1.4 节中的失控循环 / 成本事故防护

设计建议

为每个智能体单独配置预算。Research 智能体几乎不需要太多 Token，而 Scriptwriter 则需要较高预算。独立的 InferencePolicy 可以确保某个失控智能体只会触发自己的预算上限，而不会拖垮整个团队的共享账单。
预算不仅是成本控制，更是安全控制。当失控循环触发 HTTP 429 时，你阻止的不只是费用上涨，更是在阻止级联故障和拒绝服务（DoS）问题。
速率限制是独立存在并始终启用的。预算限制的是 Token 总量，而速率限制限制的是调用频率。

安全规划：每个智能体都遵循最小权限原则

由于 kars 的 API 本身就是 YAML，“最小权限”不再是口头原则，而是可以被写下来并由审查者直接阅读的配置。例如，可以锁定 Research 智能体的网络出口，防止一篇被污染的新闻文章把它变成数据外传通道。基础出口策略会被签名并固定，任何额外出口都必须通过带有效期的 EgressApproval 临时开放：

apiVersion: kars.azure.com/v1alpha1
kind: EgressApproval
metadata:
  name: research-newswire-window
  namespace: finvideo
spec:
  sandboxName: research-agent
  hosts:
    - api.approved-newswire.example
  ttl: 4h        # 自动撤销；不存在长期宽泛出口
  reason: "Q3 earnings-week coverage"

将 Market-Data 智能体通过带有 OAuth 和按工具设置的白名单的 MCP Server，严格限制在唯一的工具范围内——智能体可以获取行情报价，但无法调用该 MCP Server 恰好暴露的其他任何工具：

apiVersion: kars.azure.com/v1alpha1
kind: McpServer
metadata:
  name: market-quotes
  namespace: finvideo
spec:
  # 通过 OAuth 访问上游 MCP Server；仅允许以下工具
  allowedTools:
    - get_quote
    - get_daily_ohlc

通过 ToolPolicy 对 Compliance 智能体的审批进行门控（审批机制 + 高信任阈值），使“批准发布”这一操作成为一个受治理的决策。同时，基于哈希链的审计日志将成为你的监管记录，清晰记录了哪个智能体在什么时间批准了哪份脚本。在受监管领域，这种防篡改的审计链并不是可有可无的附加功能，而是审计人员会要求提供的正式凭证。

对于使用 Foundry Provider 的请求，内容安全默认开启，包括 越狱、间接攻击、仇恨、暴力、自残和色情内容检测。平台运维人员可以设置一个最低安全等级，任何单独的策略都不能低于这一等级——并且这一限制会在准入阶段强制执行，因此开发者实际上无法部署一个安全等级低于集群最低标准的 Sandbox。

身份——每个智能体都是独立的主体

启用按 Sandbox 配置的身份，使每个智能体都以自己的身份向 Azure 进行身份验证：

--mesh-trust=entra

使用 --mesh-trust=entra 后，Controller 会为每个 Sandbox 创建独立的 Microsoft Entra Agent ID（类型为 microsoft.graph.agentIdentity 的 Service Principal），为该 Service Principal 分配作用域限定的 Foundry RBAC 权限，配置联邦凭据，并配置 Mesh Relay，使其能够通过 Entra 的 JWKS 验证对等智能体的 JWT。这样，Foundry 看到的调用主体将是 Publisher 智能体或 Scriptwriter 智能体，而不是一个由整个集群共享的统一身份。这意味着可以实现最小权限 RBAC，并针对每个智能体建立清晰、独立的审计记录。（默认的 --mesh-trust=anonymous 会跳过 Entra，并共享集群的 Workload Identity，适合 Demo 或单租户场景。）

更重要的是，无论采用哪种模式，Router 都会通过联邦 OIDC/IMDS 代理获取 Token，智能体本身始终不会持有长期密钥。

Azure 集成——一条命令部署什么

当准备好部署到云端后，只需要一条命令，就可以在你的 Azure 订阅中搭建整个平台：

kars up --name finvideo-prod --region swedencentral --release --mesh-trust=entra

kars up 会按照以下顺序完成部署，而且整个过程是幂等的——如果因为配额或 IAM 权限问题中断，可以重新运行命令继续部署：

预检查——检查订阅 RBAC、资源提供程序、Entra Agent ID 所需的目录角色以及预览功能。
创建资源组：kars-finvideo-prod-rg。
创建 ACR（你的私有容器镜像仓库）和启用了 Workload Identity + OIDC Issuer 的 AKS 集群。
创建 Azure AI Foundry 项目、Content Safety 绑定以及模型部署。
将镜像导入 ACR——--release 会导入公开且经过 cosign 签名的 ghcr.io/azure/* 镜像，无需本地构建，也不需要 Rust 工具链。
部署 Helm Chart——包括 Controller、AgentMesh Relay/Registry、A2A Gateway 以及 CRD。
创建第一个 Sandbox，并等待其进入 Ready 状态。

如果你已经在运行 AKS、Foundry 或 ACR，也可以直接使用现有资源。Provider 采用可插拔设计，目前可以使用 GitHub Copilot（通过设备码登录，无需 Azure 账号，最容易开始），Azure AI Foundry / Azure OpenAI（功能最完整，包括 Memory Store、智能体、Content Safety 等），GitHub Models（免费使用，仅需 PAT）。切换后端只需要修改 一个 CRD 字段。

上线前测试：要的是“证据”，不是“感觉”

在这里插入图片描述

这是对“上架期间如何测试”这一问题的回答，主要包含四个部分。

在本地以生产环境的 Pod 形态进行测试。推荐的开发流程是在本地的 kind 集群中运行你的智能体，并使用与 AKS 相同的 Helm Chart、NetworkPolicy、UID 隔离方式以及 Router 代码路径：

kars dev --release --target local-k8s
kars connect scriptwriter

由于本地 Pod 的运行形态与 AKS 保持一致（区别仅在于身份认证来源和云基础设施），因此，你在本地测试的内容，就是最终上线的内容。从本地环境迁移到云端只需要一行命令而不是重新编写一套部署方案：

kars up

使用 KarsEval 重放签名攻击样本。使用 KarsEval 编写一个评估任务，让你的 Sandbox 配置针对一组可复现、经过签名的评估样本运行。这样，“内容安全是否会触发”“网络出口限制是否生效”“隔离机制能否阻止被污染的文档”等问题，就会变成可重复、可版本化的测试，而不再只是一次性的 Demo。
复现真实攻击。kars 提供了 lethal-trifecta-demo，用于复现 2026 年 1 月针对原生 OpenClaw 的文件外传攻击，并将其与受 kars 管理的智能体进行对比，同时展示六层独立的防护机制，其中任何一层单独都能够拦截该攻击。在你自己的流水线上运行这一测试，是最真实的上线前验证方式：将一个已知攻击样本发送给 Research 智能体，然后观察各层防护是否能够正常生效。demo-clawshield 示例则展示了多租户场景，包括一个被污染的文档、两个受影响的租户，以及最终的隔离证明。
验证运行时实际执行的策略。使用 kars attest <name> 可以在无需集群管理员权限的情况下，为 Sandbox 提供防篡改的验证证据，包括 Spec Hash，SSA 字段所有者映射，Observed Generation 演进链（用于检测配置漂移），以及各策略的版本哈希。你还可以直接验证整个策略执行链路：Controller 编译后的策略 Digest 必须与 Router 实际加载的 Digest 完全一致，否则对应的 CRD 就不会进入 Ready 状态。这就弥合了“YAML 中声明的内容”与“运行时实际执行的内容”之间的差距，并提供了一项审查人员可以直接执行的验证机制。

CI 流程还会执行：

cargo audit / npm audit：检查依赖项安全性；
Fuzz 测试和性质测试：覆盖安全关键路径，包括 handoff blobs、黑名单解析、策略引擎、Double Ratchet 等；
Sandbox 加固测试套件：验证 UID 隔离、只读 rootfs、Capabilities 是否已移除，以及 seccomp 配置是否正确生效。

端到端理解这套流水线

把以上内容串联起来，下面是一项财经短视频任务在 kars 中的完整生命周期：

Research 智能体获取经过批准的新闻稿内容（严格限制出站流量；内容安全机制会扫描传入文本；智能体中没有可供窃取的凭据）。
它通过端到端加密网格将内容交给 Market-Data 智能体；Market-Data 仅通过受限范围的 MCP 工具获取行情数据。
Scriptwriter 智能体在明确的 Token 预算下撰写脚本（失控的生成任务会触发 429，而不是消耗掉你整个月的账单额度）。
Compliance 智能体通过 ToolPolicy 审批门进行审核；其审批结果会写入哈希链式审计日志，成为你的监管记录。
Voiceover 和 Video-Assembly 智能体调用受限范围的媒体工具；对于计算量大或风险较高的步骤，可以在机密（Kata）隔离环境中运行。
Publisher（Hermes）通过最严格的出站流量控制 + TTL EgressApproval 将内容发布到平台——它是唯一允许与外部世界通信的智能体，同时也是受到最严格监控的智能体。

在每一步中：智能体都没有凭证，没有直接的网络连接，每一次调用都由每 Pod 一个的路由器进行代理、预算控制、安全检查和审计。每一项控制都以 YAML 的形式存放在代码仓库中。而且在运行 kars up 之前，你已经在与生产环境一致的 Pod 形态下，于本地完成了全部验证。

总结——需要记住什么

多智能体本质上是一个云原生问题。长时间运行、自主运行、联网运行并且规模化扩展的智能体，在运维层面与微服务集群具有相同的特征——因此应该采用同样的工程治理方式：身份、网络策略、配额、GitOps 和审计。
框架本身不是信任边界——Pod 才是。无论运行 OpenClaw、Hermes，还是其他任何框架，都无需修改其代码，但要将安全控制置于框架之外：智能体中零凭据、智能体没有自己的网络，以及由每 Pod 一个的路由器代理并审计每一次调用。
Token 预算和出站流量控制不仅仅是成本或运维方面的管理措施，也是安全控制。在调用离开 Pod 之前，就应该执行 Token 预算和按主机划分的出站流量控制。
上线前测试意味着可复现的证据。在本地使用与生产环境一致的 Pod 形态进行测试，重放经过签名的攻击数据集，复现真实的数据外泄攻击，并证明运行时实际执行的安全策略。
云端集成只需要一条命令即可完成，并且只需一行配置即可从本地环境迁移到云端。kars up 会完成 AKS + ACR + Foundry + 网格 + 网关的部署；--mesh-trust=entra 则为每个智能体提供独立的 Microsoft Entra 身份以及经过范围限定的 Foundry RBAC。