AI 代理领域一片混乱。团队纷纷采用 LangChain、LlamaIndex、CrewAI、AutoGen，或者从头开始构建自定义解决方案。这很正常，也本该如此。创新阶段需要多元探索。但是，一旦代理离开开发人员的笔记本电脑，开始访问生产数据、调用外部应用编程接口（API），或在共享基础架构上运行，缺乏约束的自由就不再是优势，反而会变成隐患。
我们见证了行业经历的几波浪潮：模型 API（例如对话补全）、代理式 API（例如助手和后来的 OpenAI Responses API）、框架时代，以及如今的执行框架和编码代理时代。顶层技术不断变化，也正变得可替代。但有一点始终未变，那就是：“可以在我的笔记本电脑上运行”和“可以在生产环境中安全、大规模地运行，并具备审计跟踪”之间的差距仍未弥合。
我们的 AgentOps 策略基于一项核心原则：自带代理（BYOA）。我们的平台与框架无关。关键在于：代理具有身份、以最小权限运行，可被观测、通过安全检查，并支持事后审计。该平台提供安全防护、管控、可观测性和生命周期管理。代理则由您掌控。
红帽 AI 的核心能力
本系列将介绍 BYOA 在实际场景中的实现方式，说明当前已经可用的能力，以及我们接下来要构建的内容。
我们以个人 AI 助手 OpenClaw 为例，在红帽 AI 上将其投入生产运营。OpenClaw 通过中央 WebSocket 网关跨渠道（WhatsApp、Telegram、Slack、Discord 等）路由代理交互。我们没有将其封装在专有框架中，而是将其封装在平台基础架构中。OpenClaw 只是一个例子，这种方法适用于任何代理运行时。
OpenClaw 默认情况下几乎不进行沙盒隔离。它不会强制执行基于角色的访问权限控制（RBAC）、跟踪工具调用，也不会限制对外部服务的访问。红帽 AI 使用红帽 OpenShift 和 红帽 OpenShift AI 原生功能逐层补充上述能力，而不会修改代理的代码。本文后续将逐一介绍这些层。
从云原生走向代理原生
我们不是从头开始构建代理基础架构，而是重新利用 OpenShift 已有的工具和部署模式，并通过红帽 AI 将其扩展，以适配代理式工作负载。
代理需要隔离： OpenShift 沙盒容器（基于 Kata Containers 项目，且是正式发布的分层产品）和即将推出的代理沙盒集成可为每个代理会话提供内核级隔离执行环境。当某个代理遭到入侵时，主机和其他代理的数据仍可受到保护。
代理需要身份：结合使用带作用域的服务帐户令牌和 SPIFFE/SPIRE 实现工作负载的加密身份。没有硬编码密钥，而是由平台验证代理，并在平台级别注入短期、带作用域的服务帐户令牌。这项能力计划通过集成 Kagenti 实现，用于在红帽 AI 中支持代理生命周期管理。
代理需要多租户：通过命名空间隔离、网络策略、资源配额实现多租户，并在对抗性测试中验证边界的有效性。
代理需要多层策略防护措施： 在 Kubernetes 层使用 OPA/Gatekeeper 和 Kyverno 策略。在工具授权层使用模型上下文协议（MCP）网关。在模型推理边界使用 Guardrails Orchestrator 和 NeMo Guardrails（下一节将详细介绍）。
让代理更安全，并可在生产环境中使用
对于许多企业团队而言，安全已成为阻碍代理和模型进入生产环境的主要因素。问题不在于性能，也不在于成本，而在于信任。企业需要确保其 AI 始终符合法规要求，并保护其品牌免受声誉和法律风险的影响，尤其是在供外部用户使用时。
红帽 AI 提供涵盖整个生命周期的安全组合方法，包括在进入生产环境前进行检测、测试和风险缓解，以及防范运行时出现的威胁。
在代理上线之前： Garak（计划作为红帽 AI 的一部分）将在模型层面提供对抗性漏洞扫描，以防范越狱、提示注入和其他攻击途径。计划通过 TrustyAI Operator 实现集成，并通过 EvalHub（评估控制平面）和 Kubeflow 管道使用，从而在 CI/CD 流程中完成对抗性扫描，然后再进入生产环境。
在运行时（推理边界的防护措施）：TrustyAI Guardrails Orchestrator（自 OpenShift AI 3.0 起正式发布）可筛选模型的输入和输出。 NeMo Guardrails（技术预览版）提供可编程的对话防护规则。两者都在推理边界运行，拦截大语言模型（LLM）的单次调用，确保响应在返回给代理之前通过安全检查。模型目录中计划引入模型风险视图，其中将显示这些安全信号和模型元数据，帮助团队在选择模型之前评估用例风险。
可观测性、跟踪和评估
代理具有随机性。如果没有执行跟踪，便无法在生产中调试或信任它们。
红帽 AI 为代理可观测性奠定基础，首先是对 MLflow 的第一方支持，MLflow 目前处于开发人员预览阶段，计划在后续版本中正式发布。
MLflow Tracing 可捕获提示、推理步骤、工具调用、LLM API 请求和词元消耗。所有跟踪都与 OpenTelemetry 兼容，因此可以集成任何与 OTEL 兼容的接收器。除了跟踪之外，MLflow 的评分和评估功能也可用于评估代理质量随时间的变化，这些工作流计划通过 EvalHub 调用，EvalHub 是 OpenShift AI 中的一个评估控制平面。
大规模管控工具调用
代理需要调用工具。关键在于如何管控这些调用。
MCP 网关（由 OpenShift 网络团队基于 Envoy 构建）目前处于开发人员预览阶段，作为所有 MCP 服务器前端的单一、安全接入点。它具备基于身份的工具过滤，让代理只能看到经过授权的工具；支持通过 OAuth2 令牌交换实现对每个后端的作用域访问；并集成凭据管理，确保敏感工具调用经过适当授权。平台强制执行访问控制。应用负责管理凭据，从而杜绝跨服务器泄露风险。
授权通过 Kuadrant 的 AuthPolicy 强制执行，该策略在 Gateway API 层集成 Authorino，以实现 JSON Web Token（JWT）验证和 Open Policy Agent（OPA）规则评估。
对于 OpenClaw 而言，这意味着代理会设置一个 MCP_URL 环境变量，并获得对聚合工具目录的访问权限。它实际可以调用哪些工具由其令牌声明决定，而不是由提示决定。试图诱使代理调用未授权工具的提示注入攻击会在基础架构层被拦截，因为网关会完全忽略提示内容，并会验证令牌声明。
为生产代理选择 API 接口
许多团队从对话开始，逐步转向对话补全和 OpenAI API，再到框架，如今正迈向代理执行框架。代理使用的 API 正在走向统一。Responses API 是代理式工作负载的主流 API 之一，而 OpenAI 现在已经通过 Open Responses 规范开放了这一方向。
红帽 AI 提供的实现方案完全符合 Open Responses 规范。这让团队能够在自托管或混合模型基础架构上运行代理工作负载，而不必通过第三方服务路由每个提示、工具调用和推理工件。
目前，适用于自管式和混合环境且兼容 Open Responses 的运行时仍然有限。红帽 AI 针对这一缺口提供了该规范最成熟的实现方案之一，对于希望保留基于 OpenAI responses API 的代理行为，同时将执行转移到他们所控制的基础架构的 OpenClaw 用户来说，这是一条切实可行的路径。
对于希望采用自托管路径、但无需 Responses API 编排层的团队而言，红帽 AI 中的 vLLM 提供了兼容 OpenAI 的 /v1/chat/completions 端点，可直接供 OpenClaw 使用。
基于 Kagenti 的代理生命周期管理
许多团队在将代理从笔记本电脑迁移到生产环境时遇到了困难。 计划作为 OpenShift AI 一部分的 Kagenti 可以弥合这一差距。kagenti-operator 可通过基于 A2A 的 AgentCard CRD 自动发现代理，并利用 AgentRuntime 结构注入身份（SPIFFE/SPIRE）、跟踪和工具管控（MCP 网关），而无需更改代理代码。从发现到运行时管控的整个生命周期都由平台管理。OpenShift AI 的 UI 未来还将引入代理目录和注册表，以及工具服务器的 MCP 目录。
本系列
本博客系列将以 OpenClaw 作为代理运行时示例，逐层详细介绍上述架构。每篇文章都是独立的。您可以按顺序阅读，也可直接跳转到与您当前问题相关的内容。
贯穿整个系列的一个核心原则是 BYOA。我们从不要求您重写代理，而是为代理注入企业级严谨性，并不是反过来要求代理适配平台。
若要进一步了解用于构建、评估和加强 AI 应用安全性的红帽 AI 产品堆栈，请查看官方产品文档，以及以下对红帽 AI AgentOps 至关重要的上游项目：
关于作者
Adel Zaalouk is a product manager at Red Hat who enjoys blending business and technology to achieve meaningful outcomes. He has experience working in research and industry, and he's passionate about Red Hat OpenShift, cloud, AI and cloud-native technologies. He's interested in how businesses use OpenShift to solve problems, from helping them get started with containerization to scaling their applications to meet demand.
