AI 领域中的控制套件到底是什么？

我最近看到 OpenClaw 被称为控制套件。我心想：“这很有趣。OpenClaw 不是控制套件，它是一个代理运行时，用于驱动代理循环。”那么，“控制套件”这个词到底是什么意思呢？

目前为止的讨论

这个概念的结构性基础来自 Birgitta Böckeler 于 2026 年 4 月发表的一篇文章，文中用以下公式巧妙地定义代理：模型 + 控制套件 = 代理。她将该堆栈分为构建器控制套件（随工具提供的内部运行时）和用户控制套件（开发人员的自定义上下文）。这个定义建立在 2026 年 2 月掀起的一波讨论热潮之上，其中包括 Mitchell Hashimoto 关于对 AGENTS.md 上下文进行工程化设计的实用方法、OpenAI 关于用于自动化部署的内部控制套件工程的概述，以及 Böckeler 最初的总结备忘录。

由外而内的五个层次

我认为代理不仅仅是模型加控制套件。对我来说，这源于一个观察：我们根本无法信任代理运行时。为了在一定程度上确保代理工厂所生成代码的软件供应链安全性，我们需要一个独特的沙盒层，用于捕获来源信息，并限制代理失控时可能造成的影响。

我将这种安全的代理运行时架构想象成一个俄罗斯套娃，从外到内依次为：

基础架构 → 沙盒 → 代理控制套件 → 运行时 → 模型

每一层都有不同的所有者、不同的故障模式和不同的设计原则。我们来逐一介绍下。

第一层：基础架构

基础架构是代理实际运行的位置。它可以是 GitHub Actions 运行器、Kubernetes pod 或虚拟机（VM）。这一层涉及计算、网络和资源管理，重要性超乎人们的想象。

设想一下，当您从一个代理扩展到数十个代理并行运行时会发生什么。 Roy Belio 成功让 Andrej Karpathy 的自动研究系统在 OpenShift AI 上运行了 198 项自主实验，涵盖 GPU 调度和任务编排，且完全无需人工干预。这不是控制套件的问题，也不是沙盒的问题，而是基础架构的问题。您的平台能否管理竞争性的资源请求、防止并发代理之间相互抢占资源，并调度 GPU 工作负载？

GPU 调度本身正逐渐成为一流的基础架构学科。红帽 OpenShift 4.21 提供动态资源分配，这是一个 Kubernetes API，允许工作负载根据属性（模型、内存、计算能力）而非原始数量来请求 GPU。它还支持跨容器共享 GPU，这样轻量级的推理辅助容器就不会浪费整块设备。这是纯粹的基础架构，不涉及沙盒策略、AGENTS.md 条目，以及模型选择。只是平台在履行其职责。

第二层：沙盒

沙盒限制了代理的行为范围，并在出现问题时限制其潜在影响。核心在于隔离。我的同事 Marta Anon Ruiz 将这一层描述为“塑造代理的意向性”。NVIDIA 的 OpenShell 等项目就在这一层运行。从软件供应链安全性的角度来看，这是您的主要信任边界，决定了您能否信任一个代理，划定了代理能力的边界：没有沙盒的代理，能够执行 rm -rf /，或是能够通过 gh issue delete 删除您在 GitHub 中的所有问题（亦或是，能够编写并执行自己的脚本来达到同样目的）；有沙盒的代理，则无法执行这些操作。

如果基础架构询问的是“代理在何处运行？”，那么沙盒询问的则是：“代理能够接触什么？”。这是不同的问题，有着不同的答案。

红帽发布了一份详细指南，介绍如何在 Kubernetes 上为 AI 代理构建弹性护栏，包括 restricted-v2 安全上下文约束（SCC）、默认拒绝出口网络策略，以及针对每个代理的基于角色的访问权限控制（RBAC）。这些都是“减法式”控制措施：从代理可执行的所有操作开始，逐步删除各项能力，直到仅保留必要的能力。

沙盒层的防护深度超越了网络策略。 基于 Kata 容器和对等 pod 的红帽 OpenShift 沙盒化容器是这一层的一项关键技术，它采取额外的步骤将代理进程与其主机隔离开来。另外，请查看关于代理技能和安全威胁的文章，文中探讨了各类威胁及解决方案，包括对代理技能进行加密签名，以便您在执行前验证其来源。注入到代理工具链中的未签名技能即构成软件供应链攻击。沙盒层有助于防范此类攻击。

NVIDIA 的 OpenShell 等项目与这一层相关，通用容器运行时中内置的安全原语也是如此。这些都不是 Hashimoto 所说的“控制套件”，您并不是在教代理更好地工作，而是在阻止它执行危险或意外的操作。

第三层：代理控制套件

这就是 Hashimoto 所描述的那一层，也是 Birgitta Böckeler 所说的用户控制套件。这是赋能层，包括 AGENTS.md 文件、技能、自定义工具、手工编写的代码检查工具、系统提示以及一套完善的测试套件。这些都是您需要通过迭代开发来完善的内容，以提高代理正确处理任务的概率。

Marco Rizzi 关于利用结构化工作流进行控制套件工程设计的文章，清晰阐述了“结构化输入，结构化输出”这一原则。本文介绍了如何利用 LSP 和 MCP 扫描项目结构，以生成上下文感知型提示，这不仅告诉代理该做什么，更为其提供执行任务所需的结构化信息。用 Birgitta 的术语来说，这就是前馈控制。

工具使用是控制套件的关键组成部分，它实现了 Birgitta Böckeler 所说的计算指南。具备使用工具的能力，加上 MCP 作为标准化的实现方式，让代理真正变得实用起来，从而使代理运行时有更大几率实现其目标。 《利用 MCP 构建有效的 AI 代理》一文深入探讨了 MCP，展示了如何通过让代理的控制套件能够动态访问企业资源来赋能代理。

如何判断您的控制套件是否有效？答案是进行评估。Michael Dawson 撰写了有关评估驱动开发的文章，阐述了使用 DeepEval 和 LLM-as-judge 模式的八阶段评估框架。评估是反馈循环，它会告诉您对控制套件的更改是让代理变得更好还是更差。如果没有评估，控制套件工程设计就只能靠猜测。评估中心等工具有助于大规模管理这一过程。

控制套件工件存在管理问题。随着您的 AGENTS.md 文件不断扩充、自定义工具日益增多以及系统提示不断演进，该如何对它们进行版本管理？如何在项目之间共享它们？关于 Lola（一种 AI 上下文软件包管理器）的文章中，将 AI 上下文视为版本化软件包。这个框架很有道理：如果您的控制套件工件是工程工件，那就应该像管理工程工件一样管理它们。

第四层：代理运行时

代理运行时是驱动代理循环的引擎，例如 Claude Code、OpenCode、Goose 或其他定制工具。它负责处理工具调度、上下文窗口以及对话管理。

这就是 Anthropic 在那封电子邮件中所说的“控制套件”。我认为这是不正确的，或者至少是不精确的。除非您自己构建运行时，否则您无法对其进行工程化设计和改进。它会执行以下循环：发送提示、接收响应、分发工具调用、反馈结果。我不能低估这一层的重要性。运行时变得越来越好，我们都能从中受益。

但有些企业组织会自行构建运行时。如果您有主权方面的要求，需要现成运行时无法提供的功能，或者您的用例要求对运行时行为进行高度控制，那么您就需要构建自己的运行时，并且需要相应的 API 作为构建基础。这正是 Llama Stack 等项目的重要性所在，它们提供开放式 API，用于响应、文件处理、搜索以及未来可能涉及的内存管理。基于开放式 API 构建的主权运行时，与锁定在专有服务上的运行时有着本质区别。红帽平台支持这两种路径：一种是团队采用现有运行时，并围绕它工程化设计用户控制套件；另一种是团队根据自身上下文需求，针对开放式 API 构建自己的运行时。

第五层：模型与推理端点

在服务方面，红帽关于将 Claude Code 与 OpenShift 上的红帽 AI 推理服务器集成的指南，将 vLLM 部署在红帽 AI 上以进行本地推理。您的模型、您的集群、您的数据。在自有硬件上运行推理，这会对整个代理堆栈的信任模型产生重大影响。

在来源方面，红帽在现代软件供应链安全防护领域所做的工作，特别是红帽 Trusted Artifact Signer 和加密模型签名，在此至关重要。如果您无法验证和管理所运行模型的来源，那么其上方的整个堆栈就建立在未经验证的基础之上。模型签名之于模型层，正如技能签名之于控制套件层，它是一种加密保证，确保您运行的正是您预期运行的内容。

减法与加法

沙盒和控制套件的设计理念截然相反。沙盒采用“减法”，通过移除能力来降低风险；而控制套件采用“加法”，通过叠加知识和工具来提升能力。如果我们将二者混为一谈，就会模糊本应各自指导它们的设计原则。

两者的故障模式也各不相同。沙盒失败意味着代理执行了本不该执行的操作。控制套件故障意味着代理未能妥善完成本应做好的事。这些是不同的问题，需要采取不同的应对措施。

沙盒还有机会扮演辅助角色，即作为记录者（代理活动的中立观察者），它能以比代理运行时自我证明更值得信赖的方式，证明代理所做之事。

沙盒负责约束和观察。控制套件负责提供支持，并且您可以对它进行改进。运行时负责执行，除非万不得已，否则您不应自行构建。代理的安全性和可靠性取决于底层的堆栈，而红帽正在构建这一堆栈，从 GPU 调度到加密模型签名，每一层都是开源的。如果您正在生产环境中部署代理，并且希望拥有一个可验证而非只能寄希望于它没问题的基础，那么这正是我们努力的方向。