Claude Code上下文预填充技术实测：单次请求33K tokens远超OpenCode

Claude Code 在代码执行前主动发送 33K tokens，远超 OpenCode 的 7K。Hacker News 上有开发者实测确认：这不是偶发抖动，而是稳定复现的通信模式。

比如你提交一个 50 行 Python 函数的修改请求，Claude Code 客户端向 Anthropic API 发出的第一个请求就携带 32,841 tokens——包含完整项目结构树、最近 12 个文件的摘要、Git diff 上下文，以及三层嵌套的 AST 注释。OpenCode 同样场景只发 6,921 tokens。这叫上下文预填充（context pre-filling），不是推测性解码，也不是缓存回填。日志清楚显示：这个 payload 在任何代码生成动作开始前就已完整发出，不依赖模型响应触发。它跳过标准 RAG 流程，直接把本地工程元数据序列化成 prompt 前缀，强迫模型“先读档案，再看代码”。

预加载不是优化，是成本黑洞

33K tokens 中只有 11% 参与最终生成（实测平均 token 利用率 10.7%），其余 29K 用于构建“伪全局上下文”。OpenCode 采用按需切片：只加载当前文件 + 引用链 ≤3 跳的依赖。Claude Code 的预加载让单次编辑请求的 API 费用飙升 4.2 倍（按 Claude-3.5-Sonnet $3/M input tokens 计算）。延迟更致命：33K payload 触发 Anthropic 服务端自动启用流式分块校验，首 token 延迟从 OpenCode 的 1.8s 拉长到 4.7s。对高频迭代的 Agent 系统（比如龙虾的 /dev/run 实时调试模式），交互节奏直接被打断。

响应延迟背后是可观测性断层

Hacker News 帖子里有开发者一针见血：“我们以为慢在模型，结果发现 90% 时间花在客户端序列化 project.json + .git/index + pyproject.toml 的哈希计算上。” 日志证实：Claude Code 客户端调用 API 前会重建完整本地索引——扫描 .venv 目录、排除二进制文件，全程无进度提示。后果很实在：

• 工程师无法判断是网络卡、模型慢，还是本地预处理堵住了；
• CI/CD 流水线里集成 Claude Code 后，token 计费和实际代码产出严重脱钩；
• Agent 系统调试时，传统 llm.request_time 监控完全失效——真正瓶颈在 pre_context.build() 阶段。

对 AI 编码工作流的真实影响

这不是功能差异，是设计哲学冲突。OpenCode 把上下文裁剪权交给开发者：支持 --context-depth=1，也支持手动 .codecontext 配置。Claude Code 默认开启“全栈镜像”模式。实测 Django 项目中修改 views.py，它会静默上传 manage.py、settings/base.py、requirements.txt 全文，还有 migrations/ 目录结构摘要——哪怕改动只是一行 @login_required。这种冗余直接抬高中小团队的 AI 运维门槛：某 SaaS 公司反馈，切换到 Claude Code 后，月度 Anthropic 账单里“非生成类 token”占比从 12% 跃升至 63%，且没有审计日志能追溯来源。

龙虾生态的应对实践

OpenClaw v0.8.3 已将该现象纳入 agent-tracer 模块默认检测规则（rule:context-bloat）。当检测到单请求 input >20K tokens 且 X-Request-Source: claude-code 时，自动触发上下文压缩代理：剥离注释、折叠长字符串、替换路径为符号哈希。实测降低 token 消耗 37%，首 token 延迟回落至 2.1s。更重要的是，龙虾 CLI 新增 --trace-context-flow 开关，可实时输出每毫秒的 token 流向图——让“看不见的预加载”变成可调试的信号流。

下次遇到“Claude 突然变慢”，别急着调模型参数。先抓包看 POST /v1/messages 的 body size。那 33K tokens 里，可能有 28K 是你从未授权上传的工程快照。

立刻验证：

curl -v https://api.anthropic.com/v1/messages \
  -H "x-api-key: ..." \
  -d '{"model":"claude-3-5-sonnet-20241022","messages":[{"role":"user","content":"..."}]}' 2>&1 | grep -A 10 "Content-Length"

再用 jq 统计实际负载：

# 假设你已保存请求体到 request.json
jq '.content | length' request.json

看清它发了什么、何时发、为什么发——再决定要不要让预加载替你做主。