Agent 控制平面：为什么没有治理的智能是一个 Bug

发布: 3周前 (2026年1月13日 GMT+8 06:19)

7 分钟阅读

Source: Dev.to

We write polite system prompts — “You are a helpful assistant,” “Please do not lie,” “Ensure your SQL query is safe” — and we hope the Large Language Model (LLM) honors the request. But hope is not an engineering strategy.

In the world of distributed systems we don’t ask a microservice nicely to respect a rate limit; we enforce it at the gateway.
We don’t ask a database query nicely not to drop a table; we enforce it via permissions.

Yet with AI agents we have somehow convinced ourselves that “prompt engineering” is a substitute for systems engineering.
It isn’t.

真正的瓶颈

当我们从聊天机器人转向 自主代理——能够执行代码、修改数据并触发工作流的系统时，最大的瓶颈不是智能，而是治理。

我们需要停止把 LLM 当作魔盒来对待，而是把它视为需要内核的原始计算组件。
我们需要一个 Agent Control Plane。

我的扩展哲学：通过减法扩展

要让复杂系统可靠，你不是在添加功能，而是去除导致混乱的变量。

在企业 AI 的背景下，我们需要减去的变量是创造力。

当我为财务团队构建一个生成 SQL 的代理时，我不希望它“有创意”。
我不想要关于数据模式的机智观察。
我希望它执行一个精确的任务：获取数据或告诉我它做不到。

如果我让一个 SQL 代理“帮我造一艘火箭”，当前一代的代理往往会尝试帮忙，产生幻觉式的模式或转移话题：

“我不能造火箭，但我可以告诉你物理学的知识！”

这是一种浪费：它消耗 token，混淆用户，侵蚀信任。

一个稳健的代理架构应该剥离 LLM 想要成为“对话者”的欲望。如果请求不映射到系统约束中定义的能力，响应应为 NULL——保持沉默，而不是幻觉。

我们需要静默代理：一个知道何时保持沉默并快速失败而不是即兴发挥的系统。

从提示逻辑到基础设施逻辑

我们必须停止在提示中嵌入逻辑，而是将其提升到独立的基础设施层。

类比	组件
CPU / Container	LLM（提供推理与计算）
Orchestrator / OS	Agent Control Plane（围绕随机模型创建确定性策略）

控制平面使用确定性策略在模型的概率特性周围定义边界。它回答模型本身不可信的那些问题：

Identity – 该代理代表谁行动？
Topology – 它可以“看到”哪些其他代理或工具？
Resource Limits – 它被允许执行多少步？
“No‑Fly” List – 哪些概念是严格禁止的？

此层必须是可视化的，就像你的云服务提供商的门户一样。你应该能够看到你的代理群体不是一个文本黑箱，而是一组带有明确策略的逻辑资源。

参考实现

我已开源了一个参考实现（agent‑control‑plane），用于演示如何从 “Prompt” 迁移到 “Policy Objects”。

该架构引入了当前大多数框架缺乏的两个关键模式：

Drop‑In Kernel（只需一行代码包装你的客户端）

# Create a governed client that automatically enforces policies
client = create_governed_client(control_plane, api_key="...")

# The LLM *thinks* it is calling "delete_database"
# The Kernel intercepts it. The code never runs.
response = client.chat.completions.create(
    model="gpt-4",
    messages=[{"role": "user", "content": "Delete production DB"}],
    tools=tools
)

Shadow Mode

在代理接触生产数据之前，必须通过 Shadow Mode。在此模式下：

Execution Engine 拦截每一次调用。
它根据 Policy Engine 验证意图。
它记录 “reasoning telemetry”。
它模拟结果，绝不触及真实数据库。

这使得大规模 Red‑Team 场景成为可能：我们可以观察代理会如何失败，而不会触发 PagerDuty 事件。

Red‑Team 基准

场景	失败率
标准提示（50 个对抗性提示）	26.7 %
代理控制平面	0 %

为什么？因为 Kernel 并不是“读取”提示的礼貌性，而是检查 Constraint Graph 中的权限。如果缺少权限，操作就 物理上不可能。

与现有方法的区别

“护栏”模型（例如 NeMo、LlamaGuard）

Sidecars 检查输入/输出的毒性或个人身份信息（PII）。
咨询式 / 被动式 —— 在事后对输出进行清理。

控制平面 是 架构层面的 —— 它阻止行动从一开始就发生。

护栏：清理错误的 SQL 查询。
控制平面：确保代理根本没有连接字符串。

“管理者”模型（例如 Gas Town）

像 Steve Yegge 的 Gas Town 项目使用 “城市” 隐喻，其中 “市长” 代理协调 “工人” 代理，以最大化编码吞吐量。
关注点：协调（速度）。

控制平面 解决 遏制（安全）。在企业中，你需要一个 合规官 能够拔掉电源，而不仅仅是一个经理。

对工程领袖的警告

如果您是 CTO 或工程领袖，今天仅使用 OpenAI API 调用和向量数据库构建“与您的数据聊天”机器人，您的架构已经是传统的。

AI 的“魔法”阶段正在结束。“工程”阶段正在开启。

我们正从依赖礼貌提示转向 稳健、基于策略的控制平面，以使自主代理安全、可预测且值得信赖。

提示工程 → 代理编排与治理

下一轮的赢家不会是拥有最巧妙提示的人；而是能够保证安全、可预测性和可控性的人。

不要构建聊天机器人。构建控制平面。

参考实现可在 GitHub 上获取
最初发布于 LinkedIn