现在我们已经不只是让模型补全一段代码，而是直接让 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.htmlstyle.cssgame.js
Claude 在分析任务后，开始把用户需求转成实际文件。
在 ccglass 的记录里，可以看到 Claude 的 response 和后续状态。最后它总结已经创建了三个文件，并提示下一步在浏览器中打开index.html测试。
