AI代理上下文审计：首条消息前烧掉9万Token

一场被忽视的上下文浪费危机

Reddit 的 r/mcp 板块曾有一个帖子直指痛点：运行 15 个以上的 MCP 服务器，AI 代理在读取用户第一条消息之前，就可能消耗掉 60,000 个 Token。评论区里充斥着各种零敲碎打的修补方案——懒加载技巧、自制的 get-tool-help 工具、手动 grep /context 输出。但没有人构建一个真正意义上的诊断工具。

开发者 princejain756 决定自己动手，于是 ctxvitals 诞生了。他的自检结果令人震惊：92,413 个 Token 在首条消息前就被烧掉了。

AI 代理上下文审计工具截图

ctxvitals 到底测什么

据作者在 GitHub 上的说明，ctxvitals 会启动配置中的每个 stdio MCP 服务器，发送真实的 initialize 和 tools/list 请求，并计算每个服务器实际注入到上下文中的 schema Token 数量。

它不只盯着 MCP 服务器。该工具还会扫描 Claude Code、Cursor、Windsurf、Copilot、Codex 和 Devin 等主流 AI 编程工具的配置，统计技能、规则文件、命令和钩子各自占用了多少 Token。这种跨平台的覆盖能力，让它成为目前少有的能给出完整上下文画像的诊断工具。

MCP（Model Context Protocol） 是由 Anthropic 于 2024 年底提出的开放协议，用于让 AI 代理以标准化方式连接外部工具、数据源和服务。每个 MCP 服务器都会向客户端声明自己的工具列表（即 tools/list），并附带每个工具的名称、描述、参数 schema 等元数据。这些元数据不是按需加载的——它们会在会话初始化时被完整注入到模型的上下文窗口中，模型每一轮推理都会重新读取这些内容。这意味着 MCP 服务器越多、工具越复杂，被“固定占用”的 Token 就越多，留给实际对话和文件内容的可用窗口就越小。

MCP 支持两种传输方式：stdio（通过标准输入输出与本地进程通信）和 SSE/HTTP（远程连接）。ctxvitals 主要审计的是 stdio 类型，因为它们是最常见的本地配置方式，也最容易在多个工具间产生重复注册和版本漂移问题。

作者的审计结果：F 级评分

作者公布了自己的审计数据，每一项都值得 AI 代理用户对照检查：

指标	数值
安装的技能数	901
技能描述 Token（始终加载）	39,402
MCP 服务器数	15
每轮对话烧掉的 Token	92,413
评级	F

真正令人尴尬的不是这个数字本身，而是背后的原因：

同一个 MCP 服务器以 3 个不同名称重复配置——为同一份 schema 支付了 3 次 Token 成本
一个明文 API 密钥堂而皇之地躺在环境变量块里
一个服务器指向的二进制文件早已不存在

更离谱的是，在作者发布按工具粒度的排名功能后，他发现 claude-code 的 Read 工具一个工具的 schema 就消耗了 7,487 个 Token。一个工具，七千多 Token。

"技能（Skill）" 是 Claude Code 等工具引入的扩展机制，通常以 Markdown 或 YAML 文件形式存在，定义了一段可被代理自动加载的指令、规则或行为模板。关键问题在于：技能描述默认是始终加载的，无论该技能在当前会话中是否会被用到。901 个技能就意味着 901 段描述文本常驻上下文，39,402 个 Token 的占用正是由此而来。

与之类似的还有规则文件（如 .cursorrules、CLAUDE.md）、命令和钩子，它们都会在会话启动时被注入。这些机制单个看起来开销很小，但累积效应极为显著。ctxvitals 将它们分别计量，正是为了让用户看到“能力扩展”背后的真实上下文账单。

安全风险：不只是浪费 Token

ctxvitals 的第二个核心能力是安全检查。它会在配置文件、技能文件和 MCP 配置中查找以下问题：

硬编码密钥：明文密码、API Key 直接写在配置里
数据外泄模式：同一文件中同时出现凭据存储和网络调用，高度可疑
curl | sh 安装器：直接从网络管道执行脚本的安装方式
提示注入短语：可能被恶意利用来劫持代理行为的文本
未锁定版本的 npx/uvx 包：依赖版本漂移带来的供应链风险
重复注册指向不同二进制：同一个工具名被多个服务器注册，实际调用哪个取决于加载顺序，堪称供应链轮盘赌

这些检查项覆盖了 AI 代理配置中最常见的安全盲区。尤其是重复注册问题，在多人协作或长期维护的项目中极易被忽视，但后果可能是代理执行了非预期的代码。

curl | sh 安装器是一种将远程脚本直接通过管道传给 shell 执行的安装方式，例如 curl -fsSL https://example.com/install.sh | sh。它的风险在于：你无法在执行前审查脚本内容，服务器可以在任意时刻返回不同的代码，且没有版本校验和签名验证。对于 MCP 服务器这类拥有文件系统访问和网络调用权限的组件，一次被篡改的安装脚本就可能导致凭据泄露或恶意代码持久化。

未锁定版本的 npx/uvx 包指的是配置中写死了包名但未指定精确版本（如 npx some-mcp-server 而非 npx [email protected]）。每次启动时，包管理器都可能拉取到最新版本，这意味着一个上游的破坏性更新或被劫持的发布版本会直接进入你的代理运行环境。这是供应链攻击中最常见的入口之一，而 AI 代理配置恰恰普遍缺乏这种版本锁定意识。

如何使用 ctxvitals

上手非常简单，零依赖，需要 Node 18+：

npx ctxvitals

支持的参数包括：

--html report.html：生成可分享的 HTML 报告
--json：输出 JSON 格式，方便管道处理
--no-probe：如果你不想让它实际启动服务器
内置 Claude 技能，让代理能够自我审计

项目已开源，地址为 github.com/princejain756/ctxvitals。

为什么这件事值得每个 AI 代理用户关注

作者的审计暴露了一个行业性的结构问题：AI 代理工具的上下文成本缺乏可见性。

当你安装一个技能、添加一个 MCP 服务器、配一条规则文件时，你看到的是“我又多了一个能力”。你看不到的是“我又多烧了几千 Token”。当这些配置累积到几十上百个时，上下文窗口就被后台加载的 schema 和描述占满，留给实际对话的空间被严重压缩。

这与传统软件的性能优化有本质区别。传统应用的性能问题会直接表现为卡顿和崩溃，用户能感知到。AI 代理的上下文浪费却是静默的——你只会觉得模型“好像变笨了”“回答慢了”“记不住上下文了”，但很难定位到根因。

ctxvitals 的价值在于把这个问题量化了。它让你第一次能看清楚：你的代理在开始工作之前，到底背了多重的包袱。

作者在文末提出的问题也值得每个从业者思考：你的技术栈烧掉了多少 Token？他看到过 92k，想知道天花板在哪里。

如果你的代理配置已经积累了相当数量的技能和 MCP 服务器，花几分钟跑一下 npx ctxvitals，结果可能会让你重新审视自己的配置策略。

上下文窗口（Context Window） 是模型单次推理能处理的最大 Token 数量，包括系统提示、工具 schema、对话历史和当前输入。主流模型目前支持 128K 到 200K Token，看起来很大，但当技能描述、MCP 工具 schema、规则文件等固定开销累积到 90K 以上时，真正可用于对话和代码分析的空间就被压缩了一半以上。

更隐蔽的是，上下文浪费对模型表现的影响是非线性的。研究表明，随着上下文中无关内容的增加，模型对关键信息的注意力会下降，出现“迷失在中间”（lost in the middle）现象——即位于上下文中段的信息更容易被忽略。这意味着浪费 Token 不只是成本问题，更是准确率和推理质量问题。ctxvitals 把这种不可见的损耗变成可测量的数字，正是它最大的价值所在。