TypeSafe放出Jev编程智能体笔记：没空亲自做，等社区玩疯
内容提要
Jev模型用类型化状态图重构编程助手，解决KV缓存绑架、多模型路由成本倒挂和工具描述膨胀问题。它通过上下文编译器动态拼装最小上下文，采用即时工具加载和稳定前缀分层保住缓存折扣，并让后台守护进程用便宜模型并行处理只读任务，大幅降低成本。落地分确定性核心、即时工具引擎、异步多模型编排三阶段。
延伸解读
缓存绑架的代价与破解思路
文章指出，编程助手为保住提示词缓存折扣，不敢清理无效历史，导致上下文膨胀、模型注意力稀释。Jev模型通过类型化状态图剥离聊天流，只保留可查询的状态对象，从而轻装上阵。这提醒我们，缓存优化不应以牺牲上下文质量为代价，状态管理才是根本解。
多模型路由的成本陷阱
文章用具体算例说明，混合路由因切换模型打破缓存前缀，反而可能比纯用贵模型更贵。Jev模型的解法是先将上下文压缩成小型类型化状态再路由，使成本降至纯Opus的十分之一。这提示我们，路由省钱的前提是保持缓存连续性，否则只是数学幻觉。
工具膨胀与即时加载
文章提到，工具描述过多会占用大量token并降低模型选择准确率。Jev模型采用两层结构，系统提示只保留元工具，具体工具按需搜索并临时注入，用完即弃。这种即时工具加载机制既精简了提示词，又稳定了缓存前缀，值得在工具集成时借鉴。
安全感知路由与未验证假设
文章强调，使用便宜模型需考虑数据敏感度，Jev模型在状态图上打标签，将安全作为路由硬约束。同时，文章也指出一个未验证假设：将读和搜索任务完全剥离到后台后，主助手的决策质量是否会下降，目前尚无公开对照实验。这提醒我们，架构优化需谨慎评估信息缺失的影响。
Q&A
Jev模型是什么？它主要想解决编程助手的哪些问题？
Jev模型是用类型化状态图重构编程助手的方案，主要解决三个问题：KV缓存绑架导致上下文越拖越脏、多模型路由因缓存前缀断裂而成本倒挂、工具描述膨胀使模型选择准确率下降。
为什么说给编程助手做多模型路由反而可能更贵？
因为切换大语言模型会打破提示词缓存的前缀，Sonnet算过的中间结果Opus用不上，需要重新加载全部上下文和中间产物。当历史上下文很长时，混合路由的总成本可能达到纯用Opus的1.5倍。
Jev模型的上下文编译器是怎么工作的？
上下文编译器把状态图、当前目标和预算参数一起输入，根据本轮任务动态拼出最小可用上下文。历史信息按相关性分四档呈现：活跃焦点用原文和差异，外围上下文用AST轮廓，历史上下文用类型化摘要，冷上下文只留URI或哈希。同时采用稳定前缀分层保住缓存折扣。
Jev模型如何解决工具描述膨胀导致模型选错工具的问题？
Jev模型把工具系统改成两层：系统提示词只放两三个元工具（跑命令、读写文件、搜索工具）；当模型需要具体能力时，先调搜索工具查询，选中后该工具的完整参数schema才临时注入当前轮上下文，用完即丢。这叫即时工具加载，能保持系统提示词精简、缓存前缀稳定，提高选择准确率。
Jev模型的后台守护进程能做什么？为什么能大幅降低成本？
后台守护进程让便宜的小大语言模型并行处理只读任务，如跨模型代码审查、推测式测试合成、代码库结构索引。因为只读任务不改状态，可以并行且写冲突为零。FastContext报告显示读文件和搜索占主助手工具调用轮次的56.2%、总token的46.5%，剥离到后台后主助手成本能砍半。
Jev模型如何确保便宜的大语言模型不会接触敏感代码？
Jev模型在类型化状态图上给每块代码和文件打敏感度标签（公开源码、商业逻辑、用户个人身份信息、密钥凭证），上下文编译器把敏感度作为路由硬约束：公开源码可走DeepSeek，商业逻辑只走Anthropic或本地模型，密钥绝对不出内网。路由决策从难度和成本扩展为难度、成本、安全、合规的多维矩阵。
落地Jev模型需要分哪几个阶段？
分三个阶段：第一阶段确定性核心，用git作为状态图后端，实现上下文编译器的静态前缀保护，集成输出过滤和快速搜索工具；第二阶段即时工具引擎，实现两层MCP客户端、路径感知的markdown规则加载和基于AST的安全检查；第三阶段异步多模型编排，跑后台worker做只读审查和测试生成，实现子助手最小上下文投影和动态模型分配。
Jev模型目前最大的未验证假设是什么？
最大的未验证假设是：把读文件和搜索完全剥离到后台后，主助手因为看不到搜索过程，决策质量是否会下降。Jev模型的类型化状态图理论上可以通过显式记录搜索结果摘要来弥补信息差，但目前还没有公开的对照实验数据。
