Jev Harness十步蓝图：读取比写入贵

TypeSafe 创始人 Diogo Almeida 放出了一份 12 页 PDF，讲怎么给 coding agent 搭一个 Jev Harness。@0xMovez 把它压缩成一份十步蓝图，标题写得很直白：让 coding agent 快 200 倍、便宜 400 倍。 第 1 步先把架构定死：LLM 负责写，harness 负责执行，Jev 决定每一轮看到什么、路由到哪里、要不要真的执行。 第 2 步是全篇的思考起点，也是我最喜欢的一句：如果 LLM 根本没有 KV cache，你会怎么设计 agent？ 一旦不再假设"上下文可以廉价复用"，很多设计都得推翻重来。 第 3 步给了一个反直觉的数据：Opus → Sonnet → Opus 的路由成本是 6.19，全程都用 Opus 只要 4.15。原因是任务交回来时，整个上下文被重新处理了一遍——省下的模型单价，又被重复的上下文吃掉了。这解释了为什么"用便宜模型做路由"经常不省钱。 第 4 步是 token 的去向：读取和搜索占了工具轮次的 56.2%、token 的 46.5%，而写代码不到 10%。换句话说，Agent 的时间主要花在"看"上，而不是"写"上。 后面几步都围绕这个事实展开。第 5 步让每个内容块按当前问题打分——隐藏、短摘要、长摘要还是给全文，而且在提问之后压缩，不是之前；第 6 步把工具分档披露，几百个工具只给一行摘要，schema 按需取、文档留给一次性查询；第 7 步按条件加载指令，碰到 *.tsx 才加载样式指南、进到 billing/ 才加载它的坑点文件，而且压缩也抹不掉。 第 8 步值得单独说：按信任路由，而不只是按难度——密钥和基础设施留在第一方前沿模型上，公开文档丢给最便宜的模型。这比"贵的干难活"更实际，因为很多成本出在"不该给它看的东西也一起给了"。 第 9 步是共享一次检索：跨模型评审、eval 生成、ELI5 解释、实时进度页，都在后台只读地复用同一遍检索结果。 我的看法是，这份蓝图的真正价值在于把"省 token"从技巧问题变成架构问题：先承认读取比写入贵、上下文复用不是免费的，再据此设计每一层（压缩时机、工具披露、指令加载、路由依据）。第 2 步那个反问就是钥匙——不假设 KV cache 免费，才会想到"每一轮重新决定上下文"这种设计。 边界：这是一份方法论文档，里面的倍数和费用对比来自作者的场景与计价，换项目、换模型、换缓存策略都会变；"把 PDF 丢给 agent 让它照做"这种用法，效果也取决于你的任务结构和预算。