Agent 开发没有那么难。这篇按问题走一遍：每一步碰到什么问题，模型外面那层工程代码（Harness）怎么解，模型自己又学会了什么。

对 DeepSeek Harness 的一次 deepseek：过度工程，还是为自进化而建？

最近关于一些职业发展和未来的感想

本文写于 2026 年 6 月。retypeset-odyssey、HeroUI 这些项目都在快速迭代，下面引的字段名、行为和做法以当时为准。

我的博客主题 retypeset-odyssey 现在是个 npm 包：装上、写份 YAML，就能搭一个站。但它到底有哪些合法配置，只活在源码里：src/config-schema.ts 的 Zod schema，和 src/content.config.ts 里的 frontmatter 定义。我自己配站翻得到，可 AI agent 不会去翻我的源码，只能照着"一般博客主题大概长这样"猜。它猜出来的 site.logo、theme.darkMode、posts.perPage 听着都合理，我却一个都没定义过——这种 key 写进 retypeset.config.yaml，构建当场 Zod 校验报错。猜七成对、三成错，那三成刚好够让构建挂掉。

agent 够不到这些约定，怪不得它。主题的真实配置面从没在源码之外完整写过一遍，它无处可读。要让它用对，我得把这些约定从 Zod schema 和 frontmatter 定义里搬出来，放到它读得到的地方。这两天我把这事补上了，顺手也看了别人是怎么做的。

我有两个离不开的本地小工具。一个是 Headroom：它给 Claude Code 发出去的请求做上下文压缩，对话越长省得越多，token 账单能砍掉一大截。另一个是 cc-switch：一个图形界面，点一下就能把 Claude Code 切到不同的 provider——官方、DeepSeek、各种第三方中转。

这两个东西单独用都很顺。可当我想同时用——既要 Headroom 压缩、又要随时用 cc-switch 切 provider——它们就开始打架。我以为是个十分钟的配置问题，结果整整搞了一天。

这篇文章想讲的是怎么一步步找到它的：我先后试了哪些方案、每个卡在哪、靠哪两个实验把错误假设戳穿、结论又是怎么修正的。重点是这段过程，那 30 行代码反而是最不重要的部分。

本文写于 2026 年 6 月，基于 Claude Code 2.1.178、Headroom 0.23/0.25、cc-switch v3.x。这几个工具迭代很快，下面引的源码行号和行为都只是当时的快照，过段时间很可能就对不上了。

本文写于 2026 年 5 月。内容都是调研结论，还没有在项目中实际落地。这个领域变化极快，读的时候请注意时效性。

全文约 20,000 字，阅读大约需要 30-40 分钟。

• Coding Agent 的成本大头是 input token（占 token 总量的 93-99%），因为每轮 API 调用都重发完整上下文
• 最有效的省钱手段是 Prompt Cache（命中 cache 的 input 便宜 10 倍），做好缓存纪律（固定前缀顺序、清理多余 MCP）一次配置就能持续受益
• Context Engineering 四个方向：Select（让正确的代码进来）、Compress（压缩已有上下文）、Isolate（拆任务、换模型）、Write（把信息存到文件系统）
• 模型分级（Haiku 做探索、Sonnet 做实现、Opus 做架构）可以在 token 总量不变的情况下把成本降几倍
• 写到文件的外置记忆（SPEC.md、planning-with-files、session handoff）可以让工作跨 session 延续，但维护成本是一个 open problem（代码变了文档没跟着变）
• 用我今天的真实 session token 数据（Input 1.62M, Output 128.1K, Opus 4.6）做粗算：从什么都不做的 $11.30 到假设全部优化措施到位后的 $4-5。这是基于合理假设的估算（70% cache 命中率等），不是实测结果

本文写于 2026 年 4 月，最后更新于 5 月。GitHub Agentic Workflows（gh-aw）还在 technical preview，下文涉及的 API 和编译行为随时可能变。