技术速递｜当编码智能体离开代码库：使用 Azure KARS 构建多运行时 AI 智能体基础设施

MicrosoftReactor

218人浏览 · 2026-09-30 00:02:45

MicrosoftReactor · 2026-09-30 00:02:45 发布

作者：卢建晖、许豪

排版：Alan Wang

故事从一个不会写代码的人开始

在这里插入图片描述

先从一个我在社区活动中经常遇到的场景说起。

去年年底的一次活动结束后，我收到了一封邮件。发件人并不是开发者，而是一家制造业客户的市场经理。他写道：“我按照你们的教程安装了 Claude Code。本来只是想让它帮我修一个静态网页，结果后来发现，我可以把十几个 Excel 文件丢给它，它能读取这些文件、编写脚本进行数据处理，然后生成 PowerPoint。现在我每周的经销商简报都是它帮我做的。”

然后他问了一个再普通不过的问题：“我们能把它推广到整个部门吗？”

这个问题就是本文的起点。

1.1 为什么编码智能体悄悄变成了业务智能体

过去两年里，我们大多数人都是从另一个方向构建智能体：定义工具架构、编写函数调用、搭建编排器、接入 RAG、调整提示词。这条路没有任何问题——但它有一个隐藏前提：你必须提前知道用户会做什么，这样才能把对应的能力封装成工具。

编码智能体（Claude Code CLI、GitHub Copilot CLI、Codex CLI 以及它们的同类产品）走的是完全相反的路线。它们最初的设计目标是“在真实文件系统中，通过真实命令行完成真实的软件工程任务”。为了做到这一点，它们不得不获得四项能力：

第一，文件系统是一等公民。 智能体拥有自己的工作目录，可以读取、写入、列出和生成文件。对于开发者来说，这意味着“编辑代码”。但对于市场经理来说，它意味着“我把十几个电子表格丢进去，然后得到一份演示文稿”。同一种能力，换一个场景，就变成了完全不同的产品。

第二，Shell 是通用工具。 传统智能体每增加一种能力，都需要新增一个工具定义。而编码智能体只有一个终极工具：运行命令。这意味着 pandas、LibreOffice、curl、ffmpeg、Chromium——任何可以放进容器里的东西，都可以自动成为智能体的能力。扩展工具集也因此从编写代码变成了编写 Dockerfile。

第三，它天生就是为长任务设计的。 编写代码不是简单的请求/响应，而是计划 → 执行 → 读取错误 → 修复 → 再次执行。把这个循环放到业务场景中，就会变成：读取数据 → 发现列无法对应 → 清洗 → 重新计算 → 制作图表 → 编写报告。聊天式智能体最难实现的自我纠错循环，恰恰是编码智能体的默认行为。

第四，它已经拥有成熟的扩展协议。 MCP 将它连接到外部系统；Skills 则向它传授你的领域知识和交付规范。一个 SKILL.md 文件就可以告诉它：“我们的月报应该是什么样的，这些术语的定义是什么，免责声明要放在第二页。”整个过程完全不需要编写代码。

所以结论很明确：**编码智能体的运行时并不是后来被改造成业务智能体运行时的。它本来就是我们目前拥有的最通用的智能体运行时。**代码只是它最初的落地场景，因为代码拥有最清晰的评估标准（能不能运行？）。但它底层的形态——在隔离环境中，使用大量工具，迭代式地生成文件——实际上描述了大多数知识型工作。

1.2 然后，真正的问题出现了

回到那封邮件。“我们能把它推广到整个部门吗？”从一台笔记本电脑到整个部门之间，存在一系列与 AI 能力本身无关的问题：

他的 Claude Code 运行在自己的 Mac 上，使用他自己的 API 密钥，而且他很乐意跳过权限提示（没错，真的跳过了）。
一些同事想使用 Copilot CLI，因为公司使用 GitHub Enterprise。另一些人则想使用 Codex CLI，因为他们前面接的是自托管的 OpenAI 兼容网关。
安全部门只有一个问题：“这个东西可以执行任意命令，还可以访问网络。它到底能接触到我们什么东西？”

这三个问题分别有自己的名字：运行时异构性、凭证治理和爆炸半径。而恰好，这正是 Azure KARS 所要解决的问题。

Azure KARS：将智能体作为标准 Kubernetes 工作负载处理

Azure/kars —— Kubernetes 的智能体参考技术栈。它由 Azure Cloud Native 团队以开放方式开发，这也是负责 Azure Kubernetes Service 和 Azure Linux 的团队。

最重要的一句话先说在前面：这不是 Microsoft 官方支持的产品。 没有 SLA，没有支持合同，也没有产品路线图承诺。它是一个参考实现——你可以阅读它、从中学习架构，并在此基础上构建自己的技术栈。

2.1 用一句话概括这个问题

KARS README 中有一句话，我认为它就是整个项目的核心思想：赋予 AI 智能体真正的工具，就意味着赋予它真正的凭证和真实的网络访问能力——而在生产环境中，这意味着过大的爆炸半径，因为一个受到提示词注入攻击的智能体，就可能访问你的 Azure 订阅、GitHub 组织以及客户数据。

它的答案不是“限制智能体能做什么”，而是按照与其他服务相同的运维纪律来运行智能体。

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

KARS 最重要的结构性设计之一是：每个智能体使用一个经过强化的沙箱，并且智能体本身没有独立的网络。

智能体容器以 UID 1000 运行，没有自己的出站网络；它只能通过同一个 Pod 内的 localhost 访问推理路由器。所有离开 Pod 的数据都必须经过这个 Rust 路由器。NetworkPolicy 和负责出站流量控制的 iptables init 容器则充当安全网，如果路由器被绕过，可以进一步限制爆炸半径。最终实现的结果是：即使智能体遭到入侵，也不会进一步危及云账户、模型、审计日志或其他智能体组成的网络。

这个路由器是整个安全模型的承重墙。它作为独立容器运行，使用不同的 UID（1001），持有智能体本身无法看到的凭证，并作为唯一的策略执行点：在这里插入图片描述

有一个常见的疑问值得直接回答：“我们已经有 API 网关了，这不是重复建设吗？”

不是。南北向网关负责管理集群边界的流量；KARS 路由器则是位于 Pod 内部、localhost 上、介于智能体和其他所有资源之间的策略执行点，因此智能体没有可以绕过它的网络路径。二者处于不同层级，相互补充而不是相互替代——集群边缘网关可以位于 KARS 前面，而每个 Pod 中的路由器仍然负责执行单个沙箱的身份、内容安全、预算和审计策略，这是共享的边缘网关无法完成的。这正是零信任模型的结构核心：信任边界是 Pod，而不是集群外围。

2.3 多运行时：一份 YAML，八种智能体框架

这一部分与本文主题的关系最为直接。你通过 KarsSandbox.spec.runtime.kind 选择运行时，而无论使用哪种运行时，路由器、治理、隔离和审计链都是完全一致的。

内置运行时包括：OpenClaw（默认，TypeScript/Node）、Hermes（Nous Research，Python）、OpenAI Agents SDK、Microsoft Agent Framework（Python；.NET 延后支持）、LangGraph、LangGraph.js、Anthropic Claude Agent SDK、Pydantic-AI，以及 BYO：你的镜像，我们的契约。

作为一名布道师，我认为“相同的路由器、治理、隔离和审计链”是这个代码仓库中最容易被低估的一句话。这意味着安全审查只需要进行一次。 安全团队不需要先审查 LangGraph，再审查 Claude Agent SDK，然后再审查你的 CLI 封装。他们审查的是 Pod 形态、CRD 和审计格式。按照项目自己的说法：安全团队审查的是 YAML，而不是 Python。

审批门禁、速率限制、工具允许列表、内容安全下限、Token 预算以及信任拓扑，都通过声明式 Kubernetes 资源定义——将它们提交到代码仓库，用 Argo/Flux 进行调谐，通过 git log 进行审计。

2.4 一个心智模型，三种运行方式

三种模式共享相同的 KarsSandbox YAML。区别在于运行在哪里以及由什么进行隔离。

本地 kind（推荐）——一个多容器 Pod：智能体 + 路由器 + init 出站流量控制器。这是真正的生产形态，并且与 AKS 使用相同的 NetworkPolicy 和出站流量控制器。这是推荐的开发循环，因为你在本地测试的东西，就是最终部署的东西。
本地 Docker——单个容器，将智能体和路由器放在一起。提示词/工具的内部循环最快，但并不是生产形态。
AKS（生产环境）——多容器 Pod：智能体（UID 1000）+ 路由器（UID 1001）+ init 出站流量控制器，可选 Kata + AMD SEV-SNP 机密容器（需要 Kata 节点池）。

相同的 CRD。相同的路由器代码路径。相同的审计格式。相同的治理配置。从本地环境升级到 AKS，只需要修改 CLI 中的一行，而不是迁移到一个全新的系统。

而且，它的入门体验对于 Kubernetes 项目来说异常简单：执行 npm i -g @kars-runtime/cli，然后运行 kars dev --release --target local-k8s。首次运行时选择一个提供商，Kars 就会在本地 kind 集群中启动控制器、加密网络以及一个沙箱化的智能体。镜像支持多架构（amd64 + arm64，在 Apple Silicon 上原生运行），并且使用 cosign 签名；--release 会直接拉取镜像，因此不需要 Rust、不需要 clone，也不需要构建。

BYO：将编码智能体 CLI 引入契约时需要注意什么

在这里插入图片描述

现在回到那封邮件真正提出的问题。我的那位市场经理朋友既不想要 OpenClaw，也不想要 LangGraph。他想要的是自己已经知道如何使用的 CLI。 这就是 BYO（Bring Your Own runtime，自带运行时）场景。

而 BYO 恰恰是最容易出现问题的地方——因为 BYO 的本质是：平台为你提供隔离和治理的骨架，但“智能体究竟如何运行”又重新交回到你的手中。

3.1 陷阱 #1：把“能够启动”误认为“已经完成治理”

这是我最常看到的误判。相关文档对此非常坦诚：这些 CLI 仍然使用自己的原生协议访问配置好的模型服务，而 BYO 运行时集成并不意味着所有可选的 KARS 能力都已经启用——包括 Token Budget、Content Safety、对每个原生工具调用进行完整的 /agt/evaluate 评估，以及跨智能体的 AgentMesh 编排。仅仅通过严格的镜像标签或 CR 准入，并不能实现完整的运行时插件契约。

简单来说：**一个能够启动的 Pod，并不等于一个已经受到治理的 Pod。**你的容器可以完美满足上游 BYO 快速入门中的镜像和 HTTP 适配器约定——org.kars.runtime.contract=v1、UID 1000、可写的 /sandbox 和 /tmp、8080 端口，以及对 SANDBOX_NAME 和 KARS_RUNTIME_CONTRACT_VERSION 的验证——但它仍然可能直接把模型请求发送到公共互联网。

因此，一个真正的 BYO 接入应该按照以下顺序进行：

部署上游 KARS，启用 controller.byoStrict=true，并将运行时镜像推送到自己的镜像仓库。
在挂载智能体配置和可写工作区时，遵循对应的 CRD 和控制器实现。
采用零凭证路由时，通过路由器的 /anthropic 和 /v1 端点路由 Claude 和 Codex 的推理请求。
为每一次 CLI 工具执行集成 /agt/evaluate，并在声称实现完整工具治理之前，通过 /mcp 路由 MCP。
对 Copilot CLI 原生 Token 身份验证和网络流量分别验证受控出站访问以及代理兼容性。

最后一点尤其值得强调。Copilot CLI 的身份验证方式与 Claude 和 Codex 不同——并不是简单地把 Base URL 指向其他地方。任何携带自身身份验证链的 CLI，都必须单独验证其受治理的出站访问。绝不能类推。

3.2 陷阱 #2：工具开关是一种授权，而不是一种审批

BYO Agent Studio 项目中有一段非常坦诚的说明：智能体默认使用受限的工具设置，而启用工具后，就授权 CLI 在自己的运行时中执行命令、修改工作区以及调用已配置的 MCP 服务器。这是一项广泛的能力授权，而不是逐命令审批。禁用工具也会禁用已配置的 MCP 服务器，但不同 CLI 的原生限制行为有所不同，而且它不是额外的操作系统隔离边界。

很多团队在这里会产生一种危险的错觉：认为 CLI 自己的权限提示就是安全边界。事实并非如此。真正的边界是 Pod 隔离以及路由器的出站策略。 CLI 层面的开关只是便利性的配置。

还有一个相关细节：系统会将配置好的名称写入 SKILL.md 的 frontmatter 中，以便三个 CLI 都能一致地识别 Skill——但 Skill 提供的是指令，而不是工具权限。 如果一个 Skill 需要读取文件或执行工作流，你仍然必须启用工具。

3.3 陷阱 #3：把开发模式下的凭证存储当成密钥保险库

凭证只由本地配置和当前运行时使用；它们不会进入镜像构建上下文，也不会出现在进程命令行中。但文档明确指出：**这不是一个密钥保险库。**本地用户、Docker 管理员以及启用了工具的智能体都可以访问运行时凭证。MCP 环境变量和请求头同样应当作为密钥处理。

还有一个值得明确标记的边界：不要直接将本地控制平面暴露到公共互联网。 它是一个单用户开发工作区——没有多用户登录、没有应用级 RBAC、没有远程 Docker TLS，也没有生产级密钥管理。

3.4 陷阱 #4：只使用可信 MCP，不要通过临时 npx 获取工具

只能连接可信的外部 MCP 服务器，因为它们拥有自己的权限和副作用。从实现角度来看：stdio MCP 进程运行在智能体运行时内部，而不是宿主机上；如果需要额外的可执行文件，应当扩展容器/Dockerfile——不建议通过临时的 npx 调用下载工具，因为根文件系统采用只读模式。

这一规则背后还有一个更大的原则：**在 BYO 世界中，能力应该由镜像声明，而不是在运行时临时产生。**镜像可以进行审计、签名和回滚。而在对话过程中通过 npx 临时拉取的东西，这些特征一个都没有。

3.5 陷阱 #5：版本漂移

运行时镜像会固定 CLI 版本，例如 Claude Code 2.1.263、GitHub Copilot CLI 1.0.83、Codex CLI 0.152.0。Copilot 的受限模式使用一个非空的工具允许列表，并且该列表是针对特定版本进行验证的；Codex 则使用原生功能设置以及随附的模型元数据。每当 CLI 版本发生变化，都必须重新验证适配器。

编码智能体 CLI 每周都在迭代。在 BYO 架构中，CLI 版本是一项基础设施依赖，而不是可以随意升级的客户端。 应当将它纳入变更管理，否则某天早上，你的工具允许列表可能会在不知不觉中与实际情况不再匹配。

3.6 关于文档本身的另一个说明

上游快速入门 README 中引用的是 k8s/karssandbox.yaml，而当前 main 分支中的示例文件可能仍然叫 k8s/clawsandbox.yaml——应当以实际代码仓库中的内容为准，而不要依赖一个可能已经过时的路径。这是一个很小的细节，但它说明了一个更大的问题：BYO 意味着你面对的是一个仍在持续演进的契约。

实际运行效果：KARS BYO Agent Studio

理论说得够多了。下面是一个把这些原则全部串联起来的例子——KARS BYO Agent Studio。

它是一个支持三种运行时的智能体工作区：Claude Code CLI、GitHub Copilot CLI 和 Codex CLI。你可以创建智能体、配置 MCP 服务器和 Skills，并通过统一的 UI 运行流式对话。该项目同时支持本地 Docker 开发，以及基于 AKS/KARS 的 Azure 部署。

这正是我的那位市场经理朋友需要的东西：他完全不需要学习 Kubernetes，同时他的智能体仍然运行在受治理的沙箱中。

4.1 创建智能体：四个步骤

选择运行时，并输入名称、模型、端点和凭证。
添加智能体指令，并根据需要启用工具、MCP 服务器和 Skills。
保存智能体，构建并启动其运行时，然后在共享聊天中创建 Session。
使用 @AgentName 启动 Session，以选择一个智能体。之后的消息都会继续使用该智能体，直到再次显式提及其他 @AgentName，才会切换执行器。

三种运行时在具体需求上存在明显差异——这正是“按运行时分别进行 BYO 验证”的具体体现：
在这里插入图片描述

部署的成败往往取决于这些细节。对于 Claude，需要输入服务根地址，CLI 会调用 Messages API。对于 Codex，需要输入包含 /v1 的 Base URL，并且提供商必须实现 Responses API，而不仅仅是 /chat/completions。Copilot 凭证必须是 CLI 支持的 GitHub OAuth Token，或者账户拥有 Copilot Requests 访问权限的细粒度 PAT——不支持经典 PAT，任意 OpenAI 密钥也不能作为 Copilot 凭证。

还有一个本地调试中最常见的陷阱：从本地运行时容器访问宿主机上的模型服务时，应使用 http://host.docker.internal:<port>，而不是 localhost。

另外值得注意的是：智能体草稿可以在没有凭证的情况下保存，但在配置有效凭证之前，聊天功能仍不可用——并且创建智能体后，运行时类型不可修改；如果需要切换运行时，就必须创建新的智能体。

4.2 长时间运行的任务与交付物：业务工作真正不同的地方

这一部分最能体现非编码工作与编码工作的区别。生成一份完整的演示文稿可能需要十几分钟甚至更长时间——远远超过普通对话轮次的持续时间。

Website 和 KARS 运行时每 15 秒发送一次心跳，以保持长时间文件生成流的运行。Website 不会对正在执行的任务设置过早的截止时间。运行时默认允许智能体运行 60 分钟，而 CHAT_TIMEOUT_MS 可以将限制配置在 1 分钟到 24 小时之间。

更重要的是断线恢复能力：如果浏览器到 Website 的流连接中断，智能体仍然会在后台继续运行。 UI 会轮询当前 Session，并在任务完成后恢复最终响应和交付物。只有显式点击停止生成才会取消运行时任务。关闭笔记本电脑、坐地铁经过隧道——工作都不会因此白费。

还有一个非常符合业务场景的工程细节：被抑制的工具事件默认拥有 64 MiB 的预算，因此长时间运行的 PowerPoint 生成任务不会因为中间工具输出超过 4 MiB 而被终止。用户可见的助手文本仍限制在 4 MiB，而结构化输出预算通过 CLI_STRUCTURED_OUTPUT_LIMIT_BYTES 进行配置。任何使用过程序化生成 Office 文档的人都会对此会心一笑——中间输出往往远大于最终答案。

生成的文件会显示在助手回复下方，并提供针对不同文件类型的预览：

Word、Excel 和 PowerPoint 会通过 LibreOffice 转换为 PDF 进行预览，但下载时仍保留原始文件；
PDF 使用原生嵌入式查看器；
HTML 在沙箱 iframe 中渲染，不允许脚本执行；
SVG/PNG/GIF/JPG/WebP 使用原生图片预览；
Markdown 会安全地以 GFM 形式渲染。

安全边界一直延伸到交付物：工具结果不会输出到浏览器，也不会持久化到 Session；交付物只有在通过路径遍历、符号链接、扩展名、文件数量和文件大小检查后，才能从对应智能体的工作区读取。

4.3 Skills：将业务知识放入智能体

这是非编码业务智能体中最关键的一部分。Skill 名称只能使用小写字母、数字和连字符。每个 Skill 以 ZIP 形式上传，大小最多 5 MiB。SKILL.md 必须位于 ZIP 根目录，或者位于唯一的顶层目录中。压缩包还可以包含脚本、模板以及其他资源。

这里的设计亮点在于跨运行时的一致性。上传的 Skills 会被安全地解压到持久化的智能体存储中，并在每次 KARS 对话之前同步到 /sandbox/agents/<agent-id>/skills/<skill-name>/，这样即使 KARS Pod 重启，也不会丢失 Skills。之后，运行时会将它们映射到每个 CLI 的原生位置：

Claude Code：~/.claude/skills/
GitHub Copilot CLI：<workspace>/.github/skills/
Codex CLI：~/.agents/skills/

一个 ZIP，三个运行时。 这意味着“我们公司如何编写月度报告”——你的真正组织资产——不会被绑定到某一个模型厂商。

4.4 架构：控制平面与执行平面清晰分离

在这里插入图片描述

该项目同时支持 Azure 托管模式和本地 Docker 模式。在 Azure 中，Website/控制平面运行在 Azure Container Apps 中，而智能体则在 AKS 上的 KARS Sandbox 中执行。

控制平面负责智能体/提供商/Skill 配置、Session 和消息持久化、浏览器流以及后台恢复、工件元数据/预览/下载代理，以及通过 Managed Identity 对 AKS 进行身份验证。持久化状态——包括配置、凭证、ZIP Skills、Session 和历史记录——存储在 Azure Files 中。

执行平面就是前面描述的 Pod：UID 1000 的 BYO 智能体容器，采用只读根文件系统，并与 KARS 治理/运行时并列运行，包括推理路由器、出站流量控制器/代理、网络和工具策略。其中安装的内容也完全围绕业务场景设计：三个 CLI、Chromium 和 curl、LibreOffice，以及 MCP 客户端。浏览器也没有特殊豁免——chrome、chromium、google-chrome 和 google-chrome-stable 命令全部使用 KARS 出站代理，不会绕过沙箱网络治理。

智能体的工作区域位于 /sandbox/agents/<agent-id>/ 下，并分为三个部分：

workspace：生成的交付物；
home：原生 CLI 配置；
skills：同步后的 ZIP Skills。

最后还有一个我真正欣赏的取舍：Session 是可移植的对话记录，而不是在三个 CLI 之间共享的原生 Session ID——并且**当对话上下文过大时，会明确失败，而不是静默截断。**静默截断是智能体产品中最隐蔽的问题之一；用户永远不会知道为什么智能体突然“忘记了”。明确失败是正确的选择。

我们实际上正在构建什么

回到那封邮件。如果今天让我回答这个问题，我会这样说：

可以，你可以把它推广到整个部门。但你构建的并不是“一个更大的 Claude Code”——而是一层智能体基础设施。

这层基础设施包含四个需要认真考虑的层级：

Level 1 — 运行时：拥抱异构性，而不是押注某一种运行时。

编码智能体 CLI 之所以成为通用业务智能体中最好的运行时之一，是因为它们把文件系统、Shell、迭代循环和扩展协议整合到了一起。但这个领域每个月都在变化。你的架构应该允许 Claude Code、Copilot CLI 和 Codex CLI 共存，让用户根据任务进行选择，而不是让公司押注某一种运行时。需要注意的是，智能体创建之后，运行时类型不可修改：这个限制本身就在提醒我们，运行时选择是一项一次性的决定，这也正是为什么它不应该成为整个公司的统一选择。

Level 2 — 治理：把边界放在智能体无法触及的地方。

KARS 给出的答案是，信任边界应该是 Pod，而不是集群外围。智能体没有自己的网络，凭证存储在由不同 UID 运行的容器中，每一次出站访问都会在 L7 层进行检查，每项决策都会进入哈希链式审计日志。你在智能体内部进行的任何限制，都属于便利性配置。只有在智能体之外进行的限制，才是真正的安全。

Level 3 — 知识：这才是你的护城河。

模型会变化。CLI 会升级。但“我们如何撰写季度复盘”“经销商简报中的定义是什么”才是你的资产。将这些内容编写成 Skill，并将同一个 ZIP 提供给三个运行时——这才是业务智能体真正实现可移植性的唯一方式。

Level 4 — 体验：长时间任务和交付物才是分水岭。

15 秒心跳、60 分钟默认运行时间、断线后的后台继续执行、Office 转 PDF 预览、64 MiB 中间输出预算——这些都不是所谓的“AI 能力”。但缺少其中任何一个，我那位朋友的演示文稿都无法生成。一个非编码业务智能体最终能否成功，很大程度上取决于这些工程细节。

最后，还有一点想和各位分享。KARS 并不是官方支持的产品；它目前仍处于积极开发阶段，CRD 处于 v1alpha1 阶段，其接口可能会随着小版本更新而变化，而数据路径、安全模型和审计链保持稳定。它的 README 中有一个我认为非常值得肯定的部分：Known limitations（已知限制） 列表，并用这样一句话作为开头：“我们宁愿让你在这份列表中发现这些问题，也不希望你在生产环境中发现它们。”

这种坦诚，才是参考实现真正的价值。你买到的不是一个承诺——你看到的是一份关于如何安全运行智能体的工程答案。而对于我们这些从事技术推广的人来说，真正值得传递的信息并不是“看看这个有多强大”。而是：我们终于知道边界应该画在哪里。

请查看这个代码仓库： https://github.com/kinfey/kars-byo-demo/?wt.mc_id=3reg_webpage_reactor