我让 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测试。