我让 Claude 写了一个贪吃蛇游戏，然后用 ccglass 看清它发给模型的真实请求

AI 编程 Agent 越来越强。

现在我们已经不只是让模型补全一段代码，而是直接让 Claude Code、Codex、OpenCode 这类工具读项目、写文件、调用命令、修改代码、完成一整个开发任务。

但随之而来的问题是：Agent 的执行过程越来越像黑箱。

我们通常只能看到最后结果，却不容易知道：

• 它到底把什么内容发给了模型？
• system prompt 里有哪些规则？
• 当前任务的上下文是怎么组织的？
• 模型看到了哪些工具？
• 它如何决定写入文件？
• token、cache、latency 这些指标到底是多少？

为了把这个过程看清楚，我用一个很小的 demo 做了一次实验：让 Claude Code 从零生成一个贪吃蛇小游戏，同时用 ccglass 记录整个请求过程。

ccglass 项目地址：

https://github.com/jianshuo/ccglass

补充说明：这次演示里，我使用的是第三方模型 API，上游是阿里云 DashScope 的 Anthropic 兼容接口，并不是直连 Anthropic 官方 API。ccglass 在本地作为代理接入 Claude Code，记录本地代理收到的请求，再转发到配置好的上游服务。因此，截图里可以看到 Claude Code、Anthropic 兼容协议和阿里云上游一起出现。

这次 demo 做什么？

这次任务很简单：让 Claude Code 在 demo-snake 目录里从零创建一个可以直接打开的贪吃蛇小游戏。

我给 Claude 的要求是：

请在当前目录 demo-snake 里从零创建一个可以直接打开的贪吃蛇小游戏。

要求：
1. 使用纯 HTML/CSS/JavaScript，不依赖外部框架。
2. 生成 index.html、style.css、game.js 三个文件。
3. 支持方向键控制。
4. 显示当前分数和最高分。
5. 撞墙或撞到自己后游戏结束。
6. 支持点击按钮重新开始。
7. 页面风格做得稍微精致一点，适合截图展示。
8. 完成后告诉我如何在浏览器打开测试。

这次 demo 的记录重点不是游戏本身，而是 Claude 生成这个游戏时，ccglass 看到什么。

先启动 ccglass，选择 Claude Code，然后在 Claude 里输入这段任务。

从终端可以看到，ccglass 读取到 Claude Code 配置中的上游地址，并将请求转到本地代理。这里的上游是：

https://dashscope.aliyuncs.com/apps/anthropic

也就是说，这次 demo 的调用链路大致是：

Claude Code -> ccglass 本地代理 -> 阿里云 DashScope Anthropic 兼容接口 -> 模型

这里的重点不是“Claude 能不能写一个小游戏”。这个任务足够简单，很多 AI 工具都能完成。

真正值得看的，是它在生成这个游戏时，背后发给模型的请求到底长什么样。

用 ccglass 观察 Claude Code 的请求

ccglass 是一个面向 AI 编程 Agent 的本地观测工具。它通过“本地代理 + Web Dashboard”的方式，记录 Claude Code、Codex、DeepSeek、Kimi、OpenCode 等工具实际发给模型 API 的请求和响应。

启动后，ccglass 会把 Claude Code 的请求转到本地代理，再转发给真实上游。这样我们就能在 Dashboard 里看到请求内容。

在这次 demo 中，ccglass 记录到了多轮请求。左侧可以看到每一轮请求的模型、耗时、消息数量、工具数量和 HTTP 状态。

这张图里有几个信息很关键：

• provider 是 Anthropic 兼容接口；
• 上游模型来自第三方 API，这次使用的是阿里云 DashScope；
• 请求不是一次性的，而是多轮追加；
• 每一轮都有 latency；
• 请求里包含 messages；
• 后续请求里包含 tools；
• Claude 在过程中出现了 Write 工具调用，准备写入文件。

这就把“Agent 在背后做了什么”从猜测变成了可观察事实。

不只是用户 prompt，还包括系统上下文

很多人以为 AI Agent 发给模型的内容就是“用户输入的那句话”。

但实际请求远比这复杂。

在 ccglass 的 messages 视图里，可以看到这次请求包含了系统提醒、当前日期、用户任务，以及后续的 assistant 内容。

可以看到，Claude 收到的不只是“写一个贪吃蛇游戏”。

请求里还会包含类似这样的上下文：

• 当前日期；
• system-reminder；
• 用户完整需求；
• 工作目录信息；
• 前几轮 assistant 内容；
• 已发生的工具调用结果；
• 后续模型需要继续处理的上下文。

这也是为什么 AI Agent 有时候表现得像“知道很多现场信息”：它不是凭空知道的，而是这些上下文被组织进了模型请求。

对于开发者来说，这一点非常重要。

如果 Agent 跑偏了，我们不能只看最后回复，而应该回到请求里检查：模型到底看到了什么？它是不是缺了关键上下文？是不是带了太多无关信息？是不是工具结果影响了下一轮判断？

ccglass 的价值就在这里。

模型看到了哪些工具？

AI 编程 Agent 和普通聊天机器人最大的区别之一，是它可以调用工具。

比如读文件、写文件、运行命令、搜索代码、启动子任务等。

但模型能不能正确使用工具，很大程度取决于工具 schema 和描述写得怎么样。

在 ccglass 的 tools 视图里，可以看到 Claude Code 暴露给模型的工具定义。

这张图展示的是工具定义，而不是最终工具调用结果。

它告诉我们：模型在这一轮请求里能看到哪些工具、这些工具什么时候该用、参数 schema 是什么。

比如 Agent 工具的描述里会说明：

• 什么时候应该启动一个新 agent；
• 每种 agent type 有不同能力；
• 使用工具时需要指定参数；
• 工具结果会如何返回。

同理，Claude Code 还会向模型提供写文件、读文件、运行命令等工具。模型根据这些工具描述，决定下一步如何行动。

这对调试 Agent 很有帮助。

如果某个工具经常被误用，问题可能不在模型本身，而在工具说明、参数设计或上下文组织方式上。

从需求到文件写入

这次 demo 的任务是生成三个文件：

• index.html
• style.css
• game.js

Claude 在分析任务后，开始把用户需求转成实际文件。

在 ccglass 的记录里，可以看到 Claude 的 response 和后续状态。最后它总结已经创建了三个文件，并提示下一步在浏览器中打开 index.html 测试。

这张图里还有一个很有价值的信息：usage。

它展示了这次请求的 token 使用情况，包括：

• input_tokens
• output_tokens
• cache creation
• cache read input tokens
• cached tokens

在截图里可以看到，ccglass 记录到了输入、输出和 cache 相关 token。对于长任务、多轮对话和团队使用场景，这类信息非常有用。

因为 AI Agent 的成本经常不是一次请求决定的，而是由多轮上下文、工具结果和缓存机制共同决定。

如果你发现一次任务 token 消耗异常，就可以用 ccglass 往回看：

• 哪一轮请求变大了？
• 哪个工具结果被带进了下一轮？
• 是否重复发送了大量上下文？
• cache 有没有命中？
• 哪些请求 latency 特别高？

这比只看最终账单要具体得多。

最终生成的贪吃蛇游戏

Claude 最终在 demo-snake 目录里生成了三个文件：

demo-snake/
├── index.html
├── style.css
└── game.js

浏览器打开 index.html 后，可以看到一个完整的贪吃蛇小游戏。

它支持：

• 方向键控制；
• 当前分数；
• 最高分；
• 撞墙结束；
• 撞到自己结束；
• 重新开始；
• 空格暂停；
• 使用 localStorage 保存最高分。

这个小游戏本身不是重点。

重点是：我们不只是看到了“Claude 最后生成了什么”，还通过 ccglass 看到了它生成过程中的请求、上下文、工具定义、响应和 token 使用。

这就是 AI Agent 可观测性的意义。

这次 demo 说明了什么？

通过这次小实验，可以看到 AI 编程 Agent 的一次任务其实包含很多层内容。

第一，用户输入只是请求的一部分。

模型实际看到的内容还包括 system prompt、system reminder、当前环境、可用工具、历史消息和工具结果。

第二，工具定义会影响 Agent 行为。

模型能不能正确读文件、写文件、运行命令，取决于它在请求里看到的工具 schema 和描述。

第三，多轮上下文会影响下一步动作。

Agent 每一次工具调用后的结果，都可能进入下一轮请求，继续影响模型判断。

第四，token 和 cache 需要被观测。

AI Agent 一旦进入多轮任务，token 消耗可能很快增长。如果没有工具观测，就很难知道成本花在哪里。

第五，调试 Agent 不能只看最终答案。

当 Agent 误判、漏看文件、调用错工具或上下文膨胀时，真正的问题往往藏在请求内容里。

ccglass 适合哪些场景？

ccglass 尤其适合这些用户：

• 想研究 Claude Code、Codex 等 AI 编程 Agent 如何工作的开发者；
• 想调试 Agent 为什么选错工具、遗漏上下文或重复调用的团队；
• 想分析 token、cache、cost、latency 的重度用户；
• 想对比不同 Agent 请求结构的人；
• 想导出请求记录做复盘、分析或问题报告的人；
• 想了解 AI Agent prompt 和 tool design 的开发者。

它不是另一个 AI 编程助手，而是给 AI 编程助手配的一层“观测玻璃”。

如何安装和使用？

ccglass 是开源项目，可以通过 npm 安装：

npm install -g ccglass

安装后直接运行：

ccglass

然后选择要观察的工具，例如 Claude Code、Codex、DeepSeek、Kimi、OpenCode 等。

也可以直接指定：

ccglass claude
ccglass codex
ccglass deepseek
ccglass kimi
ccglass opencode

启动成功后，终端会显示 Dashboard 地址：

dashboard: http://127.0.0.1:PORT

打开这个地址，就可以实时查看请求流。

项目链接

GitHub：

https://github.com/jianshuo/ccglass

npm 安装：

npm install -g ccglass

如果你正在使用 Claude Code、Codex、OpenCode、DeepSeek、Kimi 或其他 AI Agent，并且想知道它们到底把什么发给了模型，ccglass 值得试试。

AI Agent 越强，可观测性就越重要。