Agent控制面只是改名的API网关？深度拆解

一个开发者上周六花了九十行代码和一张 Postgres 表，给自己的 Agent 集群加上了按运行计费的成本追踪——每次模型调用计数器加一，带上 run ID、触发的工具和发起人。丑但能用。随后同事发来开源项目 preloop，号称「Agent 控制面」：计量网关、审批队列、工具调用策略层、审计日志，四合一仓库，README 写得像产品页。

他的第一反应是有点尴尬——四个功能自己手搓了三个。第二反应更有意思：这四件事他全都在生产环境跑着，只是不这么叫。

四个支柱，逐一翻译成「无聊的词」

原文作者的论证方式很直接：把 preloop 的四大功能翻译成已有基础设施的通用说法。

计量网关 = 带计数器的 API 网关。 Envoy、Kong、Traefik、nginx，每一个都有请求级指标、限流，以及能读取响应体的插件钩子。Token 数就在响应 payload 里，乘以单价、按路由打标签、送进 Prometheus 即可。作者强调：成本计量的难点从来不是网关，而是价格表和维护打标签的纪律——这两样都不住在网关里，也不会因为网关上多了「agent」二字就变简单。

审批队列 = 带人工步骤的工作流。 Temporal、Airflow、一个双按钮的 Slack 机器人、一张带 status 字段的 Postgres 表加 cron 任务。真正有趣的设计问题是：等待期间 Agent 的上下文怎么办——整轮运行驻留内存？做检查点？能否干净恢复？没有网关替你回答这个问题，而这恰恰是会咬人的部分。

工具调用策略层 = 授权。 OPA、Cedar，或者在你规模还诚实时用朴素的 RBAC。你已经有策略引擎在决定哪个服务能调哪个端点。唯一真正的新东西是主体从「服务 A 调用路由 B」变成了「Agent X 用这些参数调用工具 Y」。

审计日志 = 结构化日志。 你已经在某处投递带保留期和查询界面的日志。审计日志就是「带 schema、并承诺不删除」的日志。这个承诺是真实的，但不是一类新软件。

四比四。每一根支柱都有久经考验的现成实现，团队已经会运维、会告警、会备份、会在凌晨三点恢复它。

Envoy、Kong、Traefik、nginx 是四种主流 API 网关/反向代理：Envoy 是 Lyft 开源的高性能边车代理，Kong 与 Traefik 分别基于 OpenResty 和 Go 构建、面向微服务与容器环境，nginx 则是应用最广的通用 Web 服务器与反向代理。它们的共同点是都支持请求级指标采集（如 Envoy 的 Stats、nginx 的 stub_status）、限流插件，以及能读取或改写请求/响应体的扩展钩子（Envoy 的 Wasm/Lua filter、Kong 的 plugin、nginx 的 lua 模块）。

Temporal 与 Airflow 是工作流编排系统。Airflow 以 DAG 描述批处理任务、偏向定时调度；Temporal 以代码定义长时运行的持久化工作流，原生支持人工审批这类需要等待外部信号的步骤，且能在进程崩溃后从检查点恢复。若审批环节只想要最小实现，一张带 status 字段的表加定时轮询也能凑合，但缺少 Temporal 那种自动持久化上下文与重试语义的能力。

OPA（Open Policy Agent）与 Cedar 是策略引擎。OPA 使用 Rego 声明式语言，可通过 sidecar 或库的形式做统一授权决策；Cedar 是 AWS 开源的授权语言，强调可分析性与形式化验证。两者都支持用主体、动作、资源、上下文四个维度表达策略，把「谁能对什么做什么」从业务代码中剥离出来。相比朴素 RBAC，它们能表达带条件的细粒度规则，比如「Agent X 只能在 /tmp/run-{id}/ 目录下读取文件」这类依赖请求参数与运行时上下文的规定。

但「换皮论」在三个地方站不住

作者很诚实地承认：「这不就是 X 吗」是互联网上最廉价的论点，通常在某些地方会出错。这里就有三处。

治理单元真的变了。 API 网关按请求和路由思考，Agent 控制面必须按「带参数的工具调用」思考。「允许 read_file」不是策略，「只允许在 /tmp/run-{id}/ 下、且只允许前二十次调用」才是。基于路由的规则表达不了这个，把参数检查硬塞进网关插件会很快变丑——作者试过，插件最后在 JSON 解析不该出现的地方解析了 JSON。

成本的形状也不同。 按请求计费扁平可预测；按 token 计费是你没控制住的输入、模型自己选的输出、以及循环决定重试次数的函数。作者上个月目睹一个 Agent 把失败的