企业技术人员看过来,以OpenClaw为例,在红帽AI上实现“自带智能体”

作者：Adel Zaalouk，红帽首席产品经理

AI智能体的世界现在真的有点乱。团队有人用LangChain、LlamaIndex、CrewAI、AutoGen，也有人干脆从零开始打造一套自己的方案。没关系——在探索与创意爆发的阶段，本来就应该百花齐放。

但问题来了：当智能体不再只是跑在开发者的笔记本电脑上，而是开始接触生产环境的资料、调用外部API、甚至运行在共用的基础架构上时，没有任何限制的“完全自由”就不再是优点，反而会带来潜在风险。

我们看到产业经历了一波又一波的演进：模型API（如聊天完成功能）、Agent API（例如助手功能，以及之后的OpenAI Responses API）、框架时代、再到如今的框架工具和与编码代理时代。最上层不断在变化，逐渐变得可替代。但始终不变的，是从「在我笔记本电脑上可以跑」到「在生产环境中安全、可扩展、可审计追踪地运行」之间那道鸿沟。

我们的AgentOps策略建立在一个核心原则上：Bring Your Own Agent（BYOA，自带智能体）。

这个平台不依赖于任何特定的框架。真正重要的是：智能体必须具备明确身份、在最小权限下运行、可被监控、能通过安全检查，并能在事后进行审计。平台提供的是安全性、治理、可观察性和生命周期管理，而智能体本身仍然属于你。

红帽AI提供什么

这系列文章将介绍BYOA在实际场景中的运作方式，介绍目前已经可用的能力，以及我们正在构建的下一步。

拿OpenClaw做例子——它是一个个人AI助理，可以把智能体在不同渠道（WhatsApp、Telegram、Slack、Discord等）的互动，通过中央WebSocket Gateway统一管理。我们在红帽AI上把它落地实现。这里不是把它套进某个专有框架，而是直接运行在平台基础设施上。OpenClaw只是一个示例，这种做法其实适用于任何Agent runtime。

OpenClaw默认没做太多沙箱隔离，也不会强制RBAC（基于角色的权限控制）、追踪工具调用，或者限制对外部服务的访问。红帽AI利用红帽OpenShift和红帽OpenShift AI的原生能力，在完全不改Agent代码的情况下，把这些安全和治理机制都加上了。

接下来，我们会一一介绍这些层。

我们并不是从零打造智能体基础设施，而是将OpenShift已有的工具与部署模式重新应用，扩展为可支撑智能体工作负载的环境——这正是红帽AI的价值。

智能体需要隔离：OpenShift提供基于Kata Containers的沙箱容器（已正式商用发布），再结合即将推出的agent-sandbox整合能力，可为每个Agent会话提供内核级隔离的运行环境。即使某个智能体被攻破，也不会影响主机或其他智能体的数据安全。

智能体需要身份验证：通过范围受限的service account token，并结合SPIFFE/SPIRE实现工作负载的加密身份。没有硬编码的秘钥，而是由平台统一完成身份验证，并动态注入短期、权限受控的token。该能力未来将通过Kagenti整合，在红帽AI中支持完整的Agent生命周期管理。

智能体需要多租户能力：通过Namespace隔离、NetworkPolicy和ResourceQuota等机制，实现多租户资源与网络的有效隔离，并通过对抗性测试验证隔离边界的可靠性。

智能体需要多层策略护栏：在Kubernetes层，结合OPA/Gatekeeper与Kyverno进行策略管控；在工具调用层，通过Model Context Protocol（MCP）Gateway实现访问授权；在模型推理层，则由Guardrails Orchestrator与NeMo Guardrails提供安全防护（下一节将详细说明）。

对许多企业团队来说，安全性正在成为智能体和模型进入生产环境的首要阻碍。不是效能、不是成本，而是信任。企业必须确保AI符合监管要求，并能保护企业品牌免受声誉与法律风险，尤其当AI会被外部用户使用时。

红帽AI提供一套覆盖完整生命周期的安全组合策略，从上线前的检测、测试、风险缓解，到运行时的威胁防护都涵盖在内。

在智能体上线前：Garak（规划纳入红帽AI）可在模型层进行对抗式脆弱性扫描，覆盖越狱、提示注入等常见攻击场景。通过TrustyAI Operator集成，并可结合EvalHub（评估控制平台）和Kubeflow Pipelines使用，使团队能够在CI/CD流程中完成安全测试后再进入生产环境。

在运行时（模型推理层的安全护栏）：TrustyAI Guardrails Orchestrator（自OpenShift AI 3.0起正式商用）负责对模型输入输出进行实时检测；NeMo Guardrails（技术预览）则提供可编程的对话安全控制。两者共同作用于模型推理边界，对每一次LLM调用进行拦截与校验，确保结果在返回给Agent前已通过安全检查。未来，模型目录中还将引入“模型风险视图”，帮助团队在选型阶段就能评估不同模型的风险水平。

智能体具有不确定性。如果缺乏执行追踪，就难以在生产环境中进行调试，更难建立信任。

红帽AI正持续完善智能体可观察性的基础能力，其中包括对MLflow的原生支持（目前为开发者预览，预计将在后续版本正式发布）。

MLflow Tracing能够记录提示词、推理过程、工具调用、LLM API请求以及Token消耗等关键数据。所有追踪数据均兼容OpenTelemetry，可无缝对接各类OTEL后端系统。除了追踪能力，MLflow还提供评分与评估机制，用于持续衡量Agent的表现，并可通过EvalHub（OpenShift AI的一部分）统一触发与管理这些评估流程。

智能体会调用工具，关键在于如何管控这些调用。

MCP Gateway（由OpenShift网络团队基于Envoy打造，目前为开发者预览）部署在所有MCP服务器之前，作为统一的安全入口。它提供基于身份的工具过滤、支持后端范围访问的OAuth2 Token交换，以及统一的凭证管理机制，确保敏感操作都经过授权。平台负责执行访问控制，应用侧只需管理自身凭证，从而避免跨服务器的凭证泄露风险。

在授权层面，通过Kuadrant的AuthPolicy进行统一管理，并在Gateway API层整合Authorino，实现JWT校验与OPA策略评估。

对于OpenClaw而言，这意味着智能体只需配置一个MCP_URL环境变量，即可访问统一聚合的工具目录。至于具体能调用哪些工具，则由Token Claims决定，而不是由提示词控制。即使出现提示注入攻击，试图诱导Agent调用未授权工具，也会在基础设施层被拦截——因为Gateway并不解析提示内容，而是严格基于Token进行校验。

许多团队从Chat起步，逐步转向Chat Completions与OpenAI API，再到各类框架，如今正迈向Agent Harness阶段。随着演进，Agent所依赖的API也在逐渐收敛。其中，Responses API已成为最重要的接口之一，而OpenAI也通过OpenResponses规范将这一方向进一步开放。

红帽AI提供完全符合OpenResponses规范的实现，使团队能够在自托管或混合模型环境中运行智能体工作负载，而无需将每一次提示、工具调用或推理过程都依赖第三方服务。

目前，支持OpenResponses的自托管或混合运行环境仍较为有限。红帽AI提供了较为成熟的实现路径，使OpenClaw用户在保持OpenAI Responses API风格Agent行为的同时，也能将执行迁移到可控的基础设施之上。

对于希望走自托管路径、但不依赖Responses API编排层的团队，vLLM（Red Hat AI的一部分）则提供了兼容OpenAI的/v1/chat/completions接口，OpenClaw可直接接入使用。

Kagenti（规划纳入OpenShift AI）正是为了解决这一问题。

通过kagenti-operator，平台可以基于A2A标准的AgentCard CRD自动发现Agent，并借助AgentRuntime机制，在无需修改代码的情况下，为其注入身份（SPIFFE/SPIRE）、Tracing能力以及工具治理（MCP Gateway）。从发现到运行再到治理，整个生命周期都由平台统一管理。

未来，OpenShift AI的UI还将引入Agent目录与注册功能，以及MCP工具服务器目录，进一步提升管理与使用体验。

系列内容

本系列博客将以OpenClaw作为示例，逐层带你理解上述架构。每篇都独立成文，你可以依照自己的需求跳转到相应的部分观看。

全系列唯一不变的原则是：BYOA。

我们绝不会要求你重写智能体，而是将企业级严谨性带给你的智能体。

若你想进一步了解红帽AI在构建、评估与强化AI应用安全方面的产品技术栈，请点击阅读原文参考官方产品文件，以及以下构成红帽AI AgentOps核心的上游项目。