如果你最近觉得 Claude Code 的用量表涨得比预期快，先别急着怀疑模型涨价。
更可能的原因是：你付费的不只是“那一句 prompt”，而是一整套 Agent harness 的启动成本。
这两天 HN 上有一篇很值得看但也很容易被误读的文章。Systima 把 Claude Code 和 OpenCode 放在同一台机器、同一个模型、同类任务下，在 API 边界抓取请求与返回的 usage block，结论很刺眼：在一个只要求回答 OK 的最小任务里，Claude Code 在真正读取用户提示词之前，已经带上大约 33,000 tokens 的系统提示、工具 schema 和注入脚手架；OpenCode 大约是 7,000 tokens。换成 Claude Fable 5 后差距会收窄到约 3.3 倍，但方向没变。
我不想把这篇写成“Claude Code 不行、OpenCode 真香”的二元对立。坦白说，这样读反而会错过真正有工程价值的部分。
真正的问题是：编码 Agent 的成本，正在从模型单价问题，变成上下文装配问题。
Systima 的原文把 Claude Code 和 OpenCode 称为两个 harness。这个词很关键。模型只是发动机，harness 才是把仓库、终端、文件系统、MCP、权限、子 Agent、记忆、hooks、通知、后台任务塞进一次请求里的“车架”。你看到的聊天框是一句话，模型看到的可能是一辆满载卡车。
用人话说就是：你以为自己在问“帮我改个 bug”，但系统实际先递给模型一份厚厚的公司制度、工具手册、权限说明、项目记忆、外部系统目录，然后才轮到你的 bug 描述。
33k tokens 从哪里来？
Systima 的测法并不复杂：清空配置目录，不开 MCP，不加载用户设置和 memory，用空 workspace 跑三类任务。第一类任务最极端，只要求返回固定字符串。这样做的好处是把“任务本身的复杂度”剥掉，专门看工具启动时的固定负担。
结果是 Claude Code 的首轮请求不只是一个 system prompt。文章记录到，它还包含大量工具定义，以及注入到首个 user message 前后的 reminder、可用 agent 类型、skills 目录、用户上下文等。OpenCode 的请求更接近最小化：一个系统块、常规 coding tools，再加用户 prompt。
这不是 bug，更像产品路线差异。
Anthropic 官方文档对 Claude Code 的定位已经不是“终端里的补全工具”，而是一套横跨终端、IDE、Web、Desktop、CI/CD、Slack、Chrome extension 的开发 Agent 平台。它支持通过 MCP 连接外部工具，通过 CLAUDE.md 和 auto memory加载项目规则和经验，通过 settings管理权限、hooks、子 Agent、插件和团队策略。这些能力都很有用，但它们不会免费存在。
每个能力都要以某种形式被模型“看见”。
例如 MCP server 不是只在调用时才有成本。为了让模型知道“我可以调用哪些工具、每个工具需要什么参数、返回什么结构”，工具 schema 往往会进入上下文。你接了 5 个 MCP server，模型可能还没调用 Notion、Jira、Slack，就已经读过它们的一批说明书了。
CLAUDE.md 也是同理。官方 memory 文档明确提醒，CLAUDE.md 会在 session 开始时进入 context window，消耗 tokens；并建议每个 CLAUDE.md 控制在 200 行以内。Systima 的实验里，一个 72KB 的生产仓库 instruction file，会额外增加约 20,000 tokens。这个数字不一定能直接套到所有仓库，但方向很真实：把团队规范、架构说明、review checklist 全塞进一个文件，最后会变成每次请求都重复缴税。
说白了，Agent 成本里有一大块是“启动税”。
OpenCode 便宜，是因为它少做了什么？
OpenCode 的定位是“open source coding agent built for the terminal”。它的官方文档强调 TUI、CLI、providers、models、rules、agents、MCP、LSP 等配置能力；GitHub 仓库也显示它是真实活跃项目，截至本次检查约 185k stars，最近提交就在 2026-07-13。
但从 Systima 抓到的请求看，OpenCode 默认启动包更薄，尤其是请求前缀更稳定。这里有个比“tokens 少”更重要的点：cache stability。
Anthropic 这类 API 通常会对可复用的长前缀做 prompt caching。缓存命中时，长系统提示、工具定义、规则文件不一定每次都按完整输入价计费。但前提是前缀要稳定，字节级稳定。只要 harness 每轮都插入动态 reminder、时间戳、状态摘要、临时工具列表，缓存就可能被打碎。
Systima 的结论是，OpenCode 捕获到的 request prefix 在多次运行中 byte-identical；Claude Code 的 cache-write 行为更重，缓存经济性差。这个判断我认为比“33k vs 7k”更值得团队关注，因为真实生产环境里，很少有人只跑一次 OK。你会在同一个仓库里连续让 Agent 读文件、改代码、跑测试、修错误、再解释。缓存命中率差，成本会像复利一样放大。
这里也要补一句不那么讨喜的话：OpenCode 默认更省，不等于它在复杂企业场景里一定更好。Claude Code 带来的那些“重”能力——权限策略、自动记忆、跨端一致配置、子 Agent、团队治理、MCP 管理——在大团队里可能正是你需要的。问题不是重不重，而是你有没有意识到自己在为什么付钱。
真正危险的是“默认全开”
我最担心的不是单个开发者多花几美元，而是团队把 Agent 当成 CI 一样接进研发流程，却没有做上下文预算。
一个很常见的演化路径是这样的：
第一周，团队只是在本地用 Claude Code 改代码，成本还可控。
第二周，大家开始往 CLAUDE.md 里写规则：代码风格、目录说明、数据库约定、测试命令、release 流程。越写越长。
第三周，接上 MCP：GitHub、Linear、Notion、Slack、内部文档、监控平台。每个 server 都“以后可能用到”。
第四周，为了并行处理任务，引入 subagents。一个 parent agent 拆两个子任务，每个 subagent 再带一套启动上下文，最后 parent 还要消费子 Agent transcript。
结果呢？业务逻辑还没复杂，Agent 的固定成本先复杂了。
Systima 原文里有个例子很典型：一个直接执行约 121k tokens 的小任务，用两个 subagents fan out 后变成约 513k tokens。这个比例不是说“永远不要用子 Agent”，而是提醒我们：subagent 不是线程池，它更像新开一个带完整上下文的员工。每多叫一个人进会议室，就要重新发一遍背景材料。
人话翻译：并行不是免费的，尤其当每个并行单元都要先读一遍公司 handbook。
这和我之前写 Codex 推理 token 卡在 516？这类异常更该被当成 Agent 可靠性问题时的判断类似：Agent 系统的问题往往不在某一次生成，而在“运行时行为是否可观测、可解释、可治理”。Token overhead 也是一种运行时行为。如果你只看最终回答质量，不看请求体和 usage block，就像只看服务返回 200，不看延迟和 CPU。
团队应该怎么治理编码 Agent 成本？
我的建议很简单：先别急着换工具，先把成本拆开。
第一步，给 Agent harness 做基线测试。不要上来就跑真实需求，先建一个空目录，让它回答固定字符串，记录 input tokens、cache creation、cache read、output tokens。再逐项打开 CLAUDE.md、MCP、rules、skills、subagents。每打开一个变量，跑三次。
这听起来笨，但很有效。你会很快知道到底是工具 schema 贵、规则文件贵，还是缓存不稳定贵。
第二步，给 CLAUDE.md 减肥。官方文档建议控制在 200 行以内，我会更激进：把“每次都必须知道”的规则留在 CLAUDE.md，把长文档、业务背景、历史决策放到可检索文档或按路径加载的 rules 里。不要把 README、架构史、团队文化、所有测试命令都塞进启动上下文。
一句话：CLAUDE.md 应该像 syscall table，不应该像公司 wiki。
第三步，MCP server 按任务启用，而不是按想象启用。MCP 的价值很大，我之前写 AgentArmor 的 8 层安全框架时也强调过，工具边界和权限治理会决定 Agent 能不能进生产。但从成本角度看，MCP server 也是上下文负担。一个写 CSS 的任务不需要 Jira，一个修 SQL 的任务不一定需要 Slack。能按项目、路径、命令动态启用，就不要全局常驻。
第四步，少用“为了显得智能”的子 Agent。子 Agent 适合边界清晰、上下文可切割的任务，比如一个负责迁移 SQL，一个负责改 API，一个负责补测试。它不适合“让两个 Agent 都看看这个问题”。后者大概率只是把同一份背景读两遍，然后再让 parent 读两份解释。
第五步，把 cache hit rate 当成一等指标。很多团队会盯 API 总账单，但不看 cache write/read 分布。Claude Code 官方的成本管理文档已经提到 /usage 可以按 skills、subagents、plugins、MCP servers 查看最近 24 小时或 7 天用量占比，也建议降低 MCP overhead、把部分 CLAUDE.md 内容移到 skills、谨慎管理 agent team token costs。这个方向是对的：不要只问“模型多少钱”，要问“哪些配置在持续制造输入 tokens”。
那到底选 Claude Code 还是 OpenCode？
如果你问我的个人判断：小团队、个人开发者、成本敏感、主要在终端里做代码修改，OpenCode 很值得试。它开源、provider 选择多，默认上下文更薄，尤其适合想自己掌控 agent harness 的人。
但如果你在做企业级研发流程，Claude Code 的重型能力仍然有吸引力。跨端一致配置、权限、managed settings、MCP 管理、memory、hooks、CI/CD 和协作入口，这些东西不是 OpenCode 默认 token 少就能完全替代的。
关键不是选轻还是选重，而是别在不知情的情况下选重。
我会用下面这个粗糙但实用的判断：
- 任务短、频次高、上下文简单：优先轻 harness，避免固定启动税吃掉收益。
- 任务长、跨系统、需要权限和审计：可以接受重 harness，但必须做 token 预算和 usage 分摊。
- MCP 多、规则多、子 Agent 多：不要按“功能列表”评估，要按“每轮请求体”评估。
- 成本突然上涨：先查 cache stability 和新增配置，不要第一时间怪模型。
这件事还有一个更大的趋势：未来编码 Agent 的竞争，不会只比谁生成代码更聪明，还会比谁能更聪明地管理上下文。模型越来越强之后，系统提示、工具 schema、记忆、权限、缓存策略这些“胶水层”反而会变成主要差异。
也许几年后，我们不会再问“哪个模型写代码最好”，而会问：哪个 Agent harness 最会省上下文、最会在正确时间加载正确工具、最会把历史经验压缩成可复用记忆。
这听起来没那么性感，但更接近工程现实。
最后给一个我自己的检查清单，适合任何准备把编码 Agent 接入团队流程的人：
- 空仓库固定 prompt 基线是多少 tokens？
- 加载项目规则后增加多少？
- 每个 MCP server 增加多少工具 schema？
- cache write 和 cache read 的比例是否稳定？
- 子 Agent 是否真的减少 wall time，还是只是在复制上下文？
- 失败任务的 token 消耗是否被单独统计？
- 有没有把成本按 repo、任务类型、MCP、subagent 拆账？
能回答这 7 个问题，再谈“全面推广 Agent 编程”。答不上来，就先别把它接进高频自动化流程。
因为 Agent 的账单从来不是最后才来的。
它从还没读你的 prompt 时就开始了。