一句话：智能体越铺越多，企业连它们到底调了什么、花了多少钱都看不清
10 月 1 日，安全厂商 Tuskira 发布了一个开源、可自托管的 AI Agent Gateway，思路很务实：在智能体（Claude Code、Cursor、Codex、Claude Desktop 以及企业自建的智能体）和它们所调用的模型、MCP 服务器、工具之间，插进一个统一网关。团队不再需要在每个智能体里分别配置密钥、权限与日志，而是在一处做模型路由、MCP 访问控制、活动记录与 token 花费追踪，需要换模型也不必重写智能体。它跑在自家环境里，不强制注册 Tuskira 账号。这件事小看是个开源工具，放大看，是在把「智能体的可见性与控制力」当成基础设施工具来供给。
为什么是网关：问题不在Agent够不够聪明，而在它太散
过去一年，企业里冒出来的智能体越来越多：编码助手接模型，桌面助手接工具，自建流程接内部系统。每家各自配一套密钥、一套权限、一套日志，结果就是没人能回答最基本的问题——这些 Agent 到底连了谁、动了什么、花了多少钱。Tuskira 的判断是，可见性与控制力本该是基础设施，而不是等智能体上线后再补的监控系统。网关恰好卡在「Agent 与模型／工具」之间的必经之路上，天然适合做这件事：它能在每次调用前评估要不要放行、把 token 用量按 Agent 与模型拆开、把每条动作留痕，并把这些记录留在组织自己的环境里。
网关具体管什么：路由、权限、留痕、计量四件事
落到能力上，它做了四件工程上很朴素但分散时极难的事。其一，模型路由：把对 Anthropic、OpenAI、Gemini、AWS Bedrock 的调用收到一个端点，用组织自己的密钥，并逐笔捕获 token 与花费。其二，MCP 访问控制：用集中式画像决定每个 Agent 能用哪些 MCP 服务器与工具。其三，按调用鉴权：每一次工具调用都对照 Agent 的画像执行，未授权的直接拒绝并留记录。其四，活动记录与计量：记录模型与工具调用、Agent 接触的系统与尝试的动作，并把记录导出到既有的日志与分析系统。这些能力单独看都不新，难的是把它们合到一个自托管、可审计的开口里。
增量认知：治理的重心，正从「控制面 SaaS」转向「可自托管的基础设施」
和此前覆盖的 OneTrust AI Control Plane（把治理做成运行时控制面）对照，Tuskira 走的是另一条路：不是再卖一个 SaaS 控制面，而是把同样的能力开源、交给组织自己跑。这个分叉值得记下来——当企业把智能体接进核心系统，很多人并不愿意把「谁调用了什么、花了多少」再交给第三方的云端。开源自托管把审计边界拉回组织内部，也降低了中小团队尝试治理的门槛。它不是把 OneTrust 的故事重讲一遍，而是把同一道题用更接近基础设施的方式解了一遍。
边界：网关能看清调用，却看不见智能体在想什么
要诚实标注局限。网关管的是「链路层」：它知道哪个 Agent 调了哪个工具、花了多少 token，却看不到智能体内部的推理与决策质量。换句话说，它能防住越权调用与凭据泄露这类「行为问题」，但防不住智能体在授权范围内做出的错误判断。此外，把网关设为必经之路，本身也制造了一个集中式瓶颈与攻击面——一旦网关被攻破，它手里的画像与凭据会比单个 Agent 更值钱。关于它的性能上限、对长连接与流式调用的支持、以及与既有身份系统的对接细节，官方及行业暂未披露更多细节。
结语
Tuskira 这步棋，把「看清并管住智能体」从监控大屏降级成了一个可以自己部署的管道零件。当组织里的 Agent 越来越散，这类开源、自托管的网关可能不是最炫的方案，却很可能是最先把治理真正落地的那种。智能体的下半场，胜负未必在谁的模型更强，而在谁先把失控的链路收进可控的范围。