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

作者卢建晖、许豪排版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 容器则充当安全网如果路由器被绕过可以进一步限制爆炸半径。最终实现的结果是即使智能体遭到入侵也不会进一步危及云账户、模型、审计日志或其他智能体组成的网络。这个路由器是整个安全模型的承重墙。它作为独立容器运行使用不同的 UID1001持有智能体本身无法看到的凭证并作为唯一的策略执行点有一个常见的疑问值得直接回答“我们已经有 API 网关了这不是重复建设吗”不是。南北向网关负责管理集群边界的流量KARS 路由器则是位于Pod 内部、localhost 上、介于智能体和其他所有资源之间的策略执行点因此智能体没有可以绕过它的网络路径。二者处于不同层级相互补充而不是相互替代——集群边缘网关可以位于 KARS 前面而每个 Pod 中的路由器仍然负责执行单个沙箱的身份、内容安全、预算和审计策略这是共享的边缘网关无法完成的。这正是零信任模型的结构核心信任边界是 Pod而不是集群外围。2.3 多运行时一份 YAML八种智能体框架这一部分与本文主题的关系最为直接。你通过KarsSandbox.spec.runtime.kind选择运行时而无论使用哪种运行时路由器、治理、隔离和审计链都是完全一致的。内置运行时包括OpenClaw默认TypeScript/Node、HermesNous ResearchPython、OpenAI Agents SDK、Microsoft Agent FrameworkPython.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。这就是 BYOBring 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.contractv1、UID 1000、可写的/sandbox和/tmp、8080 端口以及对SANDBOX_NAME和KARS_RUNTIME_CONTRACT_VERSION的验证——但它仍然可能直接把模型请求发送到公共互联网。因此一个真正的 BYO 接入应该按照以下顺序进行部署上游 KARS启用controller.byoStricttrue并将运行时镜像推送到自己的镜像仓库。在挂载智能体配置和可写工作区时遵循对应的 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 CLIworkspace/.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 中。执行平面就是前面描述的 PodUID 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_id3reg_webpage_reactor延伸阅读https://github.com/Azure/kars/?wt.mc_id3reg_webpage_reactorhttps://github.com/Azure/kars/tree/main/examples/byo-quickstart/?wt.mc_id3reg_webpage_reactorhttps://github.com/Azure/kars/blob/main/docs/runtimes/CONTRACT.md/?wt.mc_id3reg_webpage_reactorhttps://github.com/Azure/kars/blob/main/docs/operations/byo-strict.md/?wt.mc_id3reg_webpage_reactor