AI 编程助手为什么跑偏？用开源 ccglass 看清 Prompt、工具调用和 Token 消耗

让 AI 编程助手修一个 bug，它读了文件、调用了工具、修改了代码，最后却改错了地方。

遇到这种情况，我们很容易继续补一句："请仔细检查""不要忽略上下文""重新分析"。

但在修改提示词之前，还有一个更值得确认的问题：模型这一轮到底收到了什么？

你在聊天框里输入的要求，只是请求的一部分。系统提示词、历史消息、工具定义、文件内容和工具执行结果，都可能影响下一步行为。只看最终回答，很难判断问题发生在哪个环节。

这篇文章介绍一个开源工具 ccglass：通过本地代理和 Web 面板，观察 AI 编程助手与模型之间的请求，给排查问题提供更直接的依据。

项目地址：jianshuo/ccglass。

1. 从"它为什么这样回答"，到"它究竟看到了什么"

以一个常见任务为例：

修复登录接口的参数校验问题，并补充测试。

一次 Agent 任务，可能会经历这样的循环：

text 复制代码

用户提出任务
    ↓
客户端组织提示词、历史消息和工具定义
    ↓
模型返回工具调用
    ↓
本地执行搜索、读文件等操作
    ↓
工具结果进入后续请求
    ↓
模型继续分析、修改和验证

如果最终结果不对，可以沿着这条链路逐步检查：

搜索结果中是否出现了真正相关的文件？
工具返回的内容有没有进入后续请求？
请求里的工具参数定义是否符合预期？
后续上下文是否保留了关键约束？

这些检查不能替你判断所有代码逻辑，却能帮助你缩小排查范围。例如，模型没有收到关键文件内容，和收到了内容却理解错误，就需要不同的处理方式。

2. ccglass 能看到哪些信息？

ccglass 的主要形态是"本地请求记录代理 + 浏览器面板"。在支持的接入方式下，它把客户端请求引到本地代理，记录流量并在面板中展示。

结合项目文档，可以把它的用途理解成下面几类：

想排查的问题	可以查看的信息
模型有没有收到必要信息？	系统提示词、消息历史和请求正文
工具为什么没按预期工作？	工具定义、调用内容和返回结果
上下文为什么越来越大？	相邻请求的差异、输入输出 Token
哪一轮开始变慢或变贵？	请求耗时、缓存信息和估算费用
如何保留排查证据？	原始请求/响应及导出内容

其中，逐轮请求对比很适合排查长任务：先找到表现异常的一轮，再看它相较上一轮增加了什么内容。

这些能力及接入方式可查阅项目 README。

3. 安装与启动

项目要求 Node.js 18 或以上版本。先准备好要观察的 AI 编程客户端及其认证配置，再安装 ccglass：

bash 复制代码

npm install -g ccglass

启动交互式选择：

bash 复制代码

ccglass

也可以直接指定客户端，例如观察 Claude Code：

bash 复制代码

ccglass claude

启动后，按照终端输出打开 Dashboard，在客户端中执行一个简单任务，就可以开始查看经过代理的请求。

建议第一次使用时选一个范围较小的任务，例如"解释某个函数的参数和返回值"。请求轮次少，更容易把输入、工具调用和结果对应起来。

4. 一个排查示例：为什么 Agent 修改了错误的文件？

下面是一个假设场景，用来说明排查思路，并非实测结果。

你要求 Agent 修复登录校验，它却修改了注册逻辑。此时可以按下面的顺序检查。

第一步：找到产生错误方向之前的请求。

不要只看最后一轮。先找到 Agent 搜索文件、读取代码的位置，确认它获得了哪些信息。

第二步：检查工具调用的参数和结果。

例如，搜索范围是否过大？关键词是否同时命中了登录和注册模块？返回内容是否足以区分两个模块？

如果搜索本身就偏离了目标，那么继续强化最终回答的格式，通常解决不了这个问题。

第三步：确认工具结果进入了后续请求。

本地执行过一次读取操作，并不等于你可以直接认定模型在后续每一轮都保留着相关内容。应该以捕获到的实际请求为依据。

第四步：比较前后两轮上下文。

观察新增了哪些消息，关键约束是否仍然存在。如果输入 Token 明显增长，再检查是否引入了大段无关内容。

第五步：根据证据调整。

如果缺少关键文件，就补充路径或缩小任务范围；如果工具描述存在歧义，就调整工具定义；如果上下文完整但推理仍有问题，再考虑提示词、任务拆分或模型选择。

这样做的价值在于：每一次调整都有明确依据，也更容易验证是否有效。

5. 接入前，先确认客户端的工作方式

不同客户端的接入条件并不完全相同。这里有两个容易影响首次体验的地方。

Codex：注意认证模式。

按照 ccglass 当前 README，Codex 的流量捕获适用于 API Key 模式；ChatGPT 登录模式的连接方式可能绕过它使用的 Base URL 配置。因此，面板没有请求时，应先核对接入条件。详见Provider 说明。

IDE：需要支持自定义 API Base URL。

对于支持该配置的 IDE 或插件，可以启动独立代理：

bash 复制代码

ccglass proxy --provider openai

然后将 IDE 的 API Base URL 设置为终端打印的代理地址，并打开对应的 Dashboard。

这种方式有明确前提：客户端需要使用可配置地址的模型接口。不能据此推断所有 IDE 内置订阅模型都能接入。具体条件见IDE 接入文档。

6. 把观察结果变成可复用的调试记录

一次排查结束后，可以保存一份简短记录：

text 复制代码

任务：修复登录接口的参数校验
异常：Agent 转而修改注册模块
证据：某轮搜索结果混入了两个模块，后续只读取了注册文件
调整：明确登录模块路径，缩小搜索范围
验证：检查新的请求内容，并运行相关测试

这种记录比"模型今天状态不好"更容易复现，也更适合在团队中讨论。

如果还想分析资源消耗，可以把请求内容与 Token、缓存和耗时信息结合起来看。费用字段应作为估算参考，最终账单仍以服务商为准。

分享日志或截图时，也要留意其中的代码和业务内容。项目会默认遮蔽认证 Token，但这不等于请求正文中的所有敏感信息都会自动脱敏。相关行为见日志说明。

7. 从一个小任务开始体验

如果你正在使用 AI 编程助手，或者正在开发需要调用模型和工具的 Agent，可以先挑一个容易复现的小任务，用 ccglass 观察完整的请求过程。

重点看三件事：模型收到了哪些信息、工具结果如何进入下一轮、请求内容如何随任务推进而变化。

当这些过程变得可见，很多原本模糊的"AI 跑偏了"，就能转化成具体、可验证的问题。

GitHub：jianshuo/ccglass

如果它对你的调试工作有帮助，欢迎 Star 支持；遇到兼容性问题或有功能建议，也欢迎提交 Issue，附上客户端类型、接入方式和脱敏后的复现信息。