OpenController:统一控制平面治理所有AI Agent

OpenController是Lyzr推出的AI Agent统一控制平面,通过内联式策略拦截实现企业级治理。
随着企业内部AI Agent数量激增却缺乏统一管控,Lyzr推出了OpenController——一个定位于「控制平面」而非简单注册表的Agent治理平台。它能自动发现散布在云、SaaS、Kubernetes及终端设备上的所有Agent,并覆盖其从部署前评估到运行时监控的全生命周期。最核心的技术差异在于:OpenController部署于企业自有集群、使用自有密钥,且采用内联式策略执行——当调用违反策略时,系统在请求路径中直接拦截,而非事后审计。这一设计将治理能力从被动记录升级为主动控制,填补了传统IT工具无法理解Agent语义、AI平台又缺乏企业级管控的空白地带。产品目前在Product Hunt处于早期市场验证阶段,但其所指向的「Agent蔓延」问题是规模化使用AI的组织普遍面临的真实挑战。
当AI Agent开始失控
企业级AI落地正在遭遇一个新问题:AI Agent的数量正在失控增长。它们散布在各类云平台、SaaS工具、Kubernetes集群甚至终端设备上,却缺乏一个共同的治理层来统一管理。Lyzr团队推出的OpenController,试图正面解决这个「Agent蔓延」的痛点。
这款产品在Product Hunt上线,斩获91个投票并登上当日排名第11位,被归类于软件工程与人工智能领域。它的核心定位很直接——一个统一的控制平面(unified control plane),用来治理组织内所有的AI Agent、模型和工作流。

不只是「注册表」那么简单
市面上已有不少工具声称能管理Agent,但它们大多停留在「注册表」(registry)层面——也就是简单地列出你有哪些Agent,做一个清单式的记录。OpenController明确将自己与这类产品区分开来。
它的功能链路覆盖了Agent生命周期的多个关键环节:
- 发现(Discover):自动找出环境中每一个Agent、模型和工作流,解决「你根本不知道自己有多少Agent在跑」的可见性难题。
- 安全交付(Ship safely):在部署前引入评估(evaluation)与治理(governance)机制,确保Agent上线前经过把关。
- 实时监控(Monitor):对运行中的Agent进行实时观测。
- 信号转化(Turn signals into action):把使用过程中产生的信号数据转化为可执行的行动。
这套组合拳的意义在于,它不是被动记录,而是主动介入Agent从部署到运行的全过程。
关键差异:在请求路径上真正「拦截」
OpenController最值得关注的技术特点有两个。
第一,它部署在你自己的集群(cluster)内,运行在你自己的密钥(keys)之下。这意味着数据和控制权始终留在企业内部,而非托管在第三方平台。对于有合规和数据主权要求的企业来说,这是一个不小的加分项。
第二,也是更具分量的一点:当策略判定「不允许」时,OpenController会在请求路径(request path)中直接拒绝这次调用。这与那些只做事后审计或旁路监控的方案有本质区别——它是内联式(inline)的强制执行,而非事后追溯。策略即是护栏,能够在Agent做出违规操作之前就将其拦下。
这种「在路径上说不」的能力,正是治理从「记录」走向「控制」的分水岭。
「内联式(inline)强制执行」这一概念来自网络安全领域,与之对应的是「旁路(out-of-band)监控」。旁路监控将流量复制一份给监控系统,原始请求不受干预继续执行,因此只能事后发现问题,无法阻止违规操作已经发生。内联式部署则将控制节点插入实际的请求路径中——每一次调用都必须经过控制平面的审查,未通过策略检查的请求会在到达目标模型或工具之前被直接丢弃或返回错误。这类架构在API网关(如Kong、NGINX)和服务网格(如Istio)中已被广泛采用,代价是引入了额外的网络延迟,收益是获得了真正的实时阻断能力。OpenController将这一成熟模式移植到AI Agent调用场景,意味着「策略合规」不再依赖开发者的自觉遵守,而是由基础设施层强制保证。
为什么这类产品正当其时
随着企业内部AI Agent的规模化部署,「谁在调用什么模型」「哪个Agent访问了敏感数据」「工作流是否符合内部策略」这些问题变得越来越尖锐。传统的IT治理工具并不理解Agent的语义,而多数AI平台又缺乏企业级的管控能力。
OpenController瞄准的正是这个空白地带——它把云原生时代成熟的「控制平面」理念,迁移到了AI Agent的治理场景中。类似于Kubernetes为容器编排提供统一控制层,OpenController试图成为Agent世界的那一层基础设施。
「控制平面(control plane)」与「数据平面(data plane)」的分离是云原生架构的核心设计哲学。数据平面负责实际的流量转发与业务执行,控制平面则集中管理策略、配置和状态。Kubernetes本身就是这一思想的典型实现:kubelet在节点上执行具体的容器操作(数据平面),而API Server、Scheduler、Controller Manager构成集中的控制平面,统一下发意图和策略。服务网格Istio同样如此,Envoy代理散布在每个Pod旁(数据平面),Istiod集中管理证书、流量规则和遥测配置(控制平面)。将这一范式引入AI Agent治理,逻辑上是自然延伸:Agent和工作流是新的「执行单元」,同样需要一个独立的控制平面来管理它们的生命周期、访问权限和行为策略,而不是让每个Agent各自为政、分散管理。
小结
OpenController代表了AI Agent治理领域的一个务实方向:从被动的清单管理,转向主动的、内联式的策略执行。它强调自托管部署、密钥自主可控以及请求路径上的实时拦截,这些特性都指向企业级的严肃使用场景。
作为一款刚在Product Hunt亮相的产品,它目前的市场验证还处于早期阶段(91票、2条评论)。它能否真正成为Agent治理的标准层,仍有待更多实际部署案例来证明。但它提出的问题——Agent正在蔓延而治理层缺失——确实是每个规模化使用AI的组织都无法回避的。
相关推荐

AI Agent入门指南:零基础也能上手的智能体学习路线
AI Agent智能体到底是什么?和普通AI聊天工具有何区别?本文用大白话讲透AI Agent核心概念,并提供一套零基础免代码的分阶段学习路线,帮助小白快速上手实战。

Colibri纯C引擎爆火:25GB内存跑744B大模型
开源项目Colibri(蜂鸟)纯C编写、零依赖,已获约3.6万星标,通过VRAM/内存/磁盘三级调度,让744B参数MoE大模型在25GB内存的消费级机器上流式运行,支持GLM、Kimi、DeepSeek等9大模型家族本地部署。

本地运行Pixel 3D多视图:8GB显存免费生成高精度3D模型
Pixel 3D多视图功能已原生集成ComfyUI,8GB显存即可本地免费生成高精度3D模型。本文详解安装、模型下载、Flux免费视图生成、显存需求及单视图/多视图实测对比。