企业架构、智能体设计 TypeSafe放出Jev编程智能体笔记：没空亲自做，等社区玩疯 #AI人工智能指南 #AI智能体Agent #Jev分类模型 2026-09-22 5K banq
这篇文章提供了一系列切实可行的思路，帮助你将 Jev 集成到你的代理系统中!

TypeSafe公司最近发布了Jev编程智能体笔记，这是一个重大的突破。通过类型化状态图重构编程助手，解决了编程助手越用越贵的问题，并大幅降低了路由成本。Jev模型通过压缩聊天记录和工具描述，只保留关键信息，从而减少了上下文的长度，使得大语言模型能够更有效地处理任务。此外，Jev模型还引入了即时工具加载机制，使得工具按需出现，大大提高了效率。后台守护进程的设计使得多个小大语言模型可以并行工作，进一步提高了性能。这些创新使得Jev模型在编程助手领域脱颖而出，为开发者提供了更好的选择。

--91likeyou---

这些编程助手把每次对话、每次文件读取、每次命令输出，全按时间顺序塞进一个巨大文本流，这个文本流叫上下文（context）。

为什么这么干，因为API服务商搞了提示词缓存（prompt caching），上一轮文字只要下一轮开头一样，就按一到两折收费，底层靠的是键值缓存（KV cache），也就是大语言模型算过的中间结果存起来下次不重算，但省着省着就变味了！

一个会话到三十轮，前面堆了十万token历史，里面全是没用的编译错误、失败命令输出、啰嗦思考过程，按理说该清掉，但工程师不敢清，因为一清缓存前缀就变了，下一轮按原价付费，于是为了保住打折券，明知道上下文是垃圾也要拖着走，大语言模型在垃圾堆里找信息，注意力被稀释，回答质量下降，用户再花更多token纠正，垃圾越滚越大，这就叫被缓存绑架！

Jev模型干的第一件事，就是把这几​​十轮聊天记录全部扔掉，只保留类型化状态图（typed state graph），让状态从聊天流里剥离出来，变成可查询、可投影、可复用的对象，Claude Code和Cursor还在拖着垃圾走，Jev模型已经轻装上阵了！


省钱路由原来是个数学幻觉

被缓存绑架之后，工程师想出聪明补救叫路由（routing），把简单任务分给便宜的小大语言模型比如Claude Sonnet，复杂任务留给贵的大语言模型比如Claude Opus，听起来合理对吧。

来算账，假设Opus每百万输入五美元、输出二十五美元，Sonnet每百万输入三美元、输出十五美元，会话历史上下文有X百万token，需要生成Y百万输出，中间还要产生Z百万中间调用比如读文件和跑命令。

纯Opus成本是二十五乘以Y加五乘以Z，混合路线是Sonnet加载上下文花三乘以X，Sonnet生成中间结果花十五乘以Y，Sonnet读工具输出花三乘以Z，最后Opus重新加载所有上下文加中间产物花五乘以Y加Z，加起来一比，如果上下文很长，混合路线反而比纯Opus贵，假设X等于零点六五、Y等于零点一二、Z等于零点二三，混合路线总成本大约是纯Opus的一点五倍，省钱路由越省越贵，这就怪了！

问题出在切换大语言模型时缓存前缀被打破，Sonnet算过的东西Opus用不上，反过来也一样，只要中途换大语言模型就等于把打折券撕了，Claude Code和Cursor的用户都踩过这个坑。

Jev模型的解法是不要把原始历史上下文传给下游大语言模型，而是先压缩成类型化状态，只保留当前修改的代码语法树差异、最近一次运行的错误堆栈、目标函数的签名，这三样加起来可能只有五千token，比原始十万token小了二十倍，Sonnet只处理这五千token，跑完返回结构化补丁，主大语言模型把补丁应用到自己的状态里，路由成本直接压到纯Opus的十分之一！


工具描述塞满屏幕大语言模型反而变傻

Jev模型砍完聊天记录，第二刀砍向工具描述膨胀，现在通过模型上下文协议（Model Context Protocol，简称MCP）能挂载的工具动辄几十上百个，每个工具都要在系统提示词里写清楚名字、参数、用途，一套下来轻松吃掉五千到一万五千token，Claude Code用户装一堆MCP服务器之后经常发现大语言模型开始胡言乱语。

token浪费还只是表面问题，更严重的是前沿大语言模型在可选工具数量超过十到十五个之后，选对工具的准确率会明显下降，这个现象叫高基数问题，大语言模型看着一百个工具反而不知道该调哪个，经常调错、调偏、调不到点子上，Anthropic在2025年推出的技能机制之所以比传统工具调用效果好，就是因为技能只提供一个这里有这么个能力的短提示，而不是把完整schema塞进系统消息，技能的成功恰恰暴露了传统工具调用的失败！

Jev模型把工具系统改成两层结构，第一层系统提示词里只放两三个元工具：跑命令、读写文件、搜索可用工具；第二层当大语言模型判断需要某个具体能力时，先调搜索工具去查，比如我想给PDF加水印，搜索工具返回三个候选工具的名字和一句话描述，大语言模型选中一个之后，那个工具的完整参数schema才被临时注入到当前这一轮的上下文里，用完立刻丢掉不进入历史记录，这个机制叫即时工具加载（JIT tool loading），Cursor和Aider还在往系统提示词里塞几百个工具定义，Jev模型已经让工具按需出现了！

这个机制的好处是系统提示词永远精简，缓存前缀稳定，大语言模型每次只看到少数几个高度相关的工具，选择准确率飙升，想象一下一个编程助手里内置了一百个工具一千份文档，但是常态下上下文里一个都不占位置，这就叫优雅！


上下文编译器是Jev模型的心脏

砍完聊天记录和工具膨胀，Jev模型的核心引擎亮相了，叫上下文编译器（context compiler），传统编程助手把消息数组直接喂给大语言模型，Jev模型把状态图、当前目标、预算参数一起送进编译器，编译器根据这一轮到底要干什么，动态拼出一份最小可用的上下文，Claude Code的压缩机制在这里显得笨拙不堪。

每一块历史信息在Jev模型里都是一个带元数据的对象：包括相关性分数、token大小、生成时间、结构标识，编译器根据当前任务需要决定每一块用什么形式呈现，具体分四档：活跃焦点用原文和原始差异，比如当前正在改的那个函数；外围上下文用抽象语法树轮廓（AST outline），只保留函数名参数返回类型；历史上下文用类型化结果摘要，比如运行pytest三个失败已在提交4a2b1中修复；冷上下文完全清除，只留一个URI或哈希值供后续需要时再拉回。

这个分级机制彻底消灭了压缩这个老问题，传统编程助手在上下文塞满时，会把前面的对话统一摘要一遍，但是压缩假设所有未来轮次都要共享一份状态，这个假设根本不成立，每一轮的关注点都不一样，用一份摘要糊弄所有轮次等于把所有细节都丢掉，Jev模型的上下文编译器每一轮现算需要什么拉什么，从根本上不需要压缩。

而且为了保住提示词缓存的打折，Jev模型采用稳定前缀分层，把上下文分成四层：前两层是静态系统提示词和项目架构清单永远不变，缓存命中率百分之百；后两层是动态上下文和当前轮指令，根据任务动态生成，这样既拿到了打折又拿到了灵活性，Cursor的缓存策略在这里被彻底比下去了！


后台守护进程让DeepSeek盯Claude的活

Jev模型的第三大突破是后台守护进程（background daemon），传统编程助手严格串行，用户说一句助手回一句，中间时间全在等，有了类型化状态图之后，可以在主会话跑的同时，让一堆便宜的小大语言模型在后台并行做只读任务，Claude Code和OpenHands都还没有这种能力。

具体有三个场景最值钱：
第一个是跨大语言模型代码审查：Opus在写业务代码，DeepSeek V3.2在后台盯着每一次git提交，自动跑OWASP十大漏洞检查、未使用变量检测、风格回归检查，发现问题立刻弹提示；
第二个是推测式测试合成：主助手一接到需求，后台就派一个worker去解析需求写对抗性测试用例，等主助手写完代码，测试已经准备好了；
第三个是代码库结构索引：微软开源的FastContext项目做过一个分析，读文件和搜索占了主助手全部工具调用轮次的百分之五十六点二，占主助手总token消耗的百分之四十六点五，如果把这部分工作全部剥离到后台守护进程，主助手的成本能直接砍半！

后台守护进程能成立的前提是这些任务必须是只读的，只读任务不改状态，不会跟主助手抢文件抢git分支，可以随便并行，写冲突为零，那读写类型的子任务怎么办，走另一条路：在临时git工作树里执行，用严格的接口契约约束，比如主助手说实现函数X签名是Y让测试Z通过，子助手就在自己的worktree里折腾，主助手只关心最终产出一个git补丁和测试通过状态，不关心子助手内部四十轮的试错过程，这个设计彻底解决了子助手的老大难问题也就是状态合并，传统做法是子助手结束后把对话历史整段塞回主助手上下文，结果上下文被垃圾污染，Jev模型的做法是子助手的历史永远不进入主助手视野，主助手只看到一个干净的补丁，Aider的串行模式在这里彻底落后了！


便宜大语言模型到底能不能碰你的代码

Jev模型把路由和后台守护进程都跑通之后，一个几乎没人愿意公开讨论的问题浮出水面，叫安全感知路由（security-aware routing），DeepSeek V3.2的价格便宜到每百万输入token不到零点三美元，是Claude Opus的十七分之一，但是数据流经DeepSeek的API之后会发生什么，没人能给你一个具体答案，Claude Code和Cursor的用户都在纠结这个问题。

Jev模型的解法是在类型化状态图上打标签，每一块代码每一份文件都带一个敏感度分类：公开源码、商业逻辑、用户个人身份信息、密钥凭证，上下文编译器在决定路由目标时把敏感度作为硬约束，公开源码可以走DeepSeek，商业逻辑只走Anthropic或本地大语言模型，涉及密钥的绝对不出内网，这样一来便宜大语言模型能用的场景可以最大化，敏感场景也不会失控。

而且这个机制还能扩展到更多维度，比如不让Anthropic大语言模型处理涉及Anthropic自身业务的代码，不让OpenAI大语言模型处理安全敏感的研究数据，路由的决策因素从单纯的难度和成本，变成了难度加成本加安全加合规的多维矩阵，OpenHands的简单路由在这里显得幼稚！

落地Jev模型得分三个阶段走：
第一阶段是确定性核心：把git作为状态图后端追踪未提交差异和活跃抽象语法树节点，实现上下文编译器的静态前缀保护机制，集成headroom和rtk做输出过滤，用fff和ast-grep替代原始bash搜索；
第二阶段是即时工具引擎：实现两层模型上下文协议客户端，搜索工具作为入口schema按需拉取，实现路径感知的markdown规则加载，实现基于抽象语法树的快速安全检查；
第三阶段是异步多大语言模型编排：跑起后台worker做只读审查和测试生成，实现子助手的最小上下文投影，实现动态大语言模型分配，重大语言模型做规划，便宜大语言模型做探索，三个阶段走完，Jev模型才真正从一个架构设想变成能跑的生产工具！


Jev模型留给你的三道作业

审视你现在用的编程助手，看看它的上下文在长时间会话之后有多脏，如果你发现三十轮之后大语言模型开始答非所问，那就是键值缓存绑架的直接症状，考虑手动开启新会话，或者选择支持显式状态管理的工具，Jev模型的核心理念就是状态必须从聊天流里剥离出来，变成可查询可投影的类型化状态图，不做到这一步，后面所有优化都是空中楼阁。

如果你在做多大语言模型路由，别再天真地以为简单任务给便宜大语言模型就省钱，先算清楚你的X、Y、Z分布，也就是历史上下文、生成输出、中间调用各占多少，上下文越长路由越亏，只有像Jev模型那样把上下文投影成小型类型化状态再传下去，路由才划算，否则你就是在用Sonnet的价格买Opus的账单。

把只读任务和读写任务在心里分开，代码审查、测试生成、依赖分析、安全审计这些只读任务，完全可以丢给后台跑的便宜大语言模型，让主会话专注在读写决策上，这一个动作就能让你的编程助手成本砍半，响应速度翻倍，Jev模型的后台守护进程架构已经证明这条路走得通。

一个悬而未决的细节，FastContext那份报告里读和搜索占主助手总token的百分之四十六点五，但是没人算过，如果把这部分完全剥离到后台之后，主助手的决策质量会不会因为看不到搜索过程而下降，Jev模型的类型化状态图理论上可以通过显式记录搜索结果的摘要来弥补这个信息差，但是这个假设目前还没有公开的对照实验数据，是这条技术路线上最大的一个未验证假设！
 

🔥 热词：#TypeSafe发布SystemOne模型Jev