当我们谈论编码智能体的时候绝大多数人的第一反应都会聚焦到大语言模型本身。大家会对比不同模型的代码能力测试模型能不能写出复杂业务逻辑讨论上下文窗口到底能拉到多大仿佛只要拿到更强的基座大模型编码智能体的体验就会自然而然实现质的飞跃。过去两年我看过非常多编码智能体项目的迭代路径团队把大部分研发资源投入在模型调优提示词工程还有各类工具的接入上。可实际落地之后总会遇到各种各样拧巴的现实问题。同样一个模型短会话里表现惊艳一旦项目规模变大会话轮次变多就开始出现幻觉无效调用工具成本不受控制子任务调度频繁失效。很多开发者会把问题简单归罪于模型不够聪明却很少向内追问会不会从架构根源上我们就走错了方向。一份来自TypeSafe创始人Diogo Almeida的设计笔记抛出了一个很反直觉的观点编码智能体的瓶颈往往不在生成代码的大模型而在于每一轮循环我们究竟给模型喂进去了什么样的上下文。这份笔记以假想实验为起点提出了名为Jev的决策层设计思路它没有追求发明新一代大模型而是把重心放在智能体的执行框架也就是Harness之上重新定义状态管理上下文组装任务路由整套体系。读完这份材料之后我最大的感受是很多行业里习以为常的设计选择并不是技术上的最优解只是KV缓存带来的经济约束逼迫我们做出的妥协。KV缓存被我们忽略的隐形枷锁做过大模型推理的开发者对KV缓存都不会陌生。模型在处理对话序列的时候会把历史token对应的key value向量缓存下来后续轮次就不需要重复计算已经处理过的内容以此大幅降低推理成本和延迟。正是这项技术塑造了现在几乎所有编码智能体的会话形态。为了最大化复用KV缓存智能体会话普遍采用追加式日志的设计。每一轮用户输入工具返回结果模型输出全部直接追加到对话序列的末尾。我们尽量不去修改上下文靠前的内容因为一旦改动前面任意一小段文本整个KV缓存就会直接失效后续全部token都需要重新计算算力开销会急剧飙升。绝大多数开发者在搭建智能体的时候会直接接受这套模式作为既定事实很少停下来思考如果把KV缓存这个前提拿掉我们的智能体又该如何构建。这个思想实验就是Jev整套设计的起点笔记中将其称为KV缓存的暴政。缓存本身是一项优秀的推理优化手段但它潜移默化绑架了上层应用架构衍生出一系列我们习以为常却充满缺陷的设计范式。这些缺陷不是某一个产品的bug而是整个行业继承下来的共性问题。第一个痛点就是模型路由的失效。行业内很流行一种设计思路使用能力更强单价更高的前沿大模型负责整体任务规划规划完成之后把执行工作交给价格更低的次一级模型执行结束之后再切回前沿模型做结果审核。直觉上来看规划轮次少执行轮次多把大量执行工作下沉应该可以省下不少token成本。但真实测算的结果往往事与愿违。笔记中使用两组真实的API报价做过演算Opus输入为5美元每百万token输出25美元每百万tokenSonnet输入3美元每百万token输出15美元每百万token。我们设定X代表已有上下文token规模Y代表模型生成输出tokenZ代表任务运行过程中读取文件和命令输出新增的token。全程使用Opus完成任务的成本可以简写为cost 5*Z 25*Y而Opus规划Sonnet执行再切回Opus复核的混合链路成本公式会变成cost 3*X 15*Y 3*Z 5*(YZ)代入真实CLI编码会话的典型参数X等于0.65Y等于0.12Z等于0.23之后全程前沿模型的相对成本是4.15混合路由方案的相对成本达到6.19。原本为了省钱设计的分层路由实际开销反而高出接近百分之五十。为什么会出现这样反直觉的结果核心就在于KV缓存。当我们把任务交给廉价模型廉价模型需要完整加载整段会话上下文。当结果交还前沿模型审核的时候又需要重新读取子任务产生的全部输出内容。两次上下文的重加载成本直接吞噬掉单token单价上带来的全部优势。这并不代表模型路由本身是错误的它告诉我们一件事单纯按照单token价格做路由决策是片面的。路由决策必须把上下文重建的开销纳入评估。只有框架能够给下游模型提供裁剪完成的专用小上下文并且子任务结果可以结构化合并而不是以完整对话文本的形式回传路由才具备实际的经济价值。除了路由失效之外KV缓存衍生出的第二个问题就是工具调用的臃肿。当下绝大多数智能体实现会把全部可用工具的完整JSON Schema全部写进系统提示词无论当前任务会不会用到这些工具。这么做的原因也和缓存机制强相关如果工具定义放在会话中间动态加载会破坏已经建立好的KV缓存。于是我们宁愿每一轮都把几十上百个工具描述全部塞进上下文窗口。这样做会带来双重损失大量token被消耗在本轮完全无关的工具定义之上挤压有效上下文空间。同时面对高数量级的工具集合模型的工具选择准确率也会下降。这也解释了为什么很多实践当中轻量级的能力描述也就是Skills实际表现会优于完整的原始工具列表。随之而来的还有传统上下文压缩的固有缺陷。当会话越来越长token逼近窗口上限智能体会执行压缩也就是Compaction逻辑把一大段历史会话总结成简短文本。现有压缩逻辑最大的问题在于压缩行为发生在用户提出下一个查询之前框架并不知道接下来要解决什么样的问题。它只能做通用化的无损程度有限的摘要很容易把后续任务至关重要的细节丢弃掉。子智能体的落地困境同样来源于这套追加式会话体系。理论上子智能体可以并行处理多个子任务提升整体处理效率但是现实生产环境中子智能体很少真正被触发。阻碍它的不是模型理解能力而是状态管理的巨大负担。父智能体需要仔细筛选哪些历史上下文要传递给子任务子任务完成之后又要思考如何把返回结果合并回主会话。整个流程实现复杂出错风险高模型会倾向于回避调用子智能体。会话重启也是我们天天会遇到的妥协方案。会话运行一段时间对话日志不断累积腐化产生大量无效、矛盾的历史信息智能体开始持续输出错误内容开发者最直接的处理手段就是重启整个会话。但重启操作是粗暴的它会清空全部会话状态有用的历史信息和已经腐化的垃圾状态被一并丢掉。我们不得不重复很多已经完成的工作。最后一个行业内持续争论的议题就是内置能力的取舍。智能体到底应该预装多少工具和能力一部分产品选择深度内置大量能力上手简单但上下文负担沉重。另一类产品追求轻量化能力交由外部插件拓展但上手门槛变高。这个两难的根源同样是每一项内置能力都要常驻在系统提示词之中永久消耗上下文token。如果可以做到能力按需加载任务结束之后就释放上下文这场争论本身也就不复存在。综合来看这六大问题并不是大模型本身的缺陷而是适配KV缓存推理优化之后上层应用架构付出的代价。如果我们希望突破这些限制就需要跳出追加式对话日志的思维转向显式可寻址的状态架构。Jev决策层把决策逻辑和生成逻辑分离开这里就要介绍整套架构的核心角色Jev。很多人第一眼看到材料会误以为Jev是一个专门用来写代码的大模型这是非常大的误解。Jev不负责生成业务代码它是一套独立的决策层。在整套Harness执行框架之中Jev接收系统结构化的状态输入包括当前任务目标已有上下文片段运行规则可用工具集合历史执行动作再配合预设好的问题输出强类型的结构化结果结果附带概率信息。真正写代码调用工具生成长文本的工作依旧交给前沿大模型子智能体或者其他确定性代码完成。强类型输出是Jev设计的精髓。传统方案里我们把问题抛给大模型模型返回自由格式的自然语言文本程序需要写复杂的解析逻辑从大段文字里抠出需要的指令很容易遇到解析失败格式错乱的问题。而Jev返回的是限定枚举结果比如隐藏简短摘要允许拒绝这类确定选项。上层Harness框架可以直接对返回值做校验设置置信度阈值直接走分支逻辑完全不需要解析自然语言。在一整个智能体会话的生命周期之中Jev会被调用成千上万次处理大量高频细碎却至关重要的决策。这些决策点决定了整套智能体最终的体验上限。比如面对每一段上下文片段Jev需要判断针对当前用户查询这个片段的可见等级是直接隐藏还是输出简短摘要详细摘要或是完整展示原文。处理缓存的时候Jev需要评估是复用现有的KV缓存前缀还是直接放弃缓存重新组装一份全新的上下文。做任务路由时评估当前子任务是否可以交给成本更低的模型同时输出成本预估数值。工具调用环节根据任务意图对可用工具做排序输出top‑k候选工具。执行系统命令前判断命令是允许直接执行需要向用户确认还是直接拒绝。安全层面预判本次任务会触碰哪些文件输出文件敏感度评分。过去这些决策很多是写死在代码里的硬编码规则或是混杂在系统提示词之中依靠生成模型的自觉。现在把这些决策统一收敛到Jev整个智能体的行为就变得可观测可调试可迭代。很多开发者会有疑问这样频繁调用决策层会不会带来巨大的额外成本。这里要区分开任务的规模Jev处理的都是选择打分这类轻量级判断不需要生成长文本和生成业务代码相比它的token开销是可控的。而它带来的收益是整个会话token总消耗的大幅下降。看懂Token开销分布找对优化的主战场想要做好编码智能体的架构改造我们首先要看清楚在真实编码会话之中token到底消耗在了什么地方。很多人想当然认为写代码是智能体最主要的工作也会占据绝大多数token开销但实际统计结果会颠覆这个认知。针对典型CLI编码智能体会话以输入token为统计口径重复读取的内容会重复计入统计各个环节的占比分布很值得我们细细琢磨。文件读取是占比最高的部分达到百分之三十到四十在长会话当中同一个文件会被反复加载进上下文。紧随其后的是代码库搜索grep检索目录遍历这类操作占比百分之十到十八检索返回的文本往往带有大量噪声。命令输出同样是吞token的大户程序报错产生堆栈运行日志一旦爆发token会快速膨胀占比维持在百分之十到二十。系统提示词工具SchemaAGENTS.md配置文件属于每一轮都要加载的固定开销占据百分之五到十二。历史对话回放则起到放大器的作用上面所有的内容会随着会话轮次推进一遍一遍被重新读取。推理和规划在普通任务占比百分之五到十五复杂调试场景占比会提升。而我们最关心的代码编辑修改仅仅占总token的百分之四到十。面向用户的解释输出占比只有百分之二到五。微软fastcontext项目的公开数据也印证了这个结论在GPT‑5.4的编码轨迹当中读取和搜索操作占据全部工具调用轮次的百分之五十六点二消耗主智能体总token的百分之四十六点五。把读取搜索命令输出三项加在一起整体会吃掉接近三分之二的token预算真正用于生成修改代码的token占比还不到百分之十。这个数据给我们的启示非常明确。编码智能体最大的性能优化空间不在于追求更强的代码生成基座模型也不是打磨更优秀的diff代码片段格式。真正的主战场是检索与上下文管理。如何减少无效的文件重读过滤检索输出的噪声按需向模型推送信息才是降本增效同时减少幻觉的核心。理解了token开销的真实构成之后我们就可以理解Harness框架当中各项设计的价值。整个框架分为两层一层是可以兼容现有智能体改造的基础能力另一层是面向全新架构的元注意力动态上下文体系。在基础层当中第一项是可编程权限管控。市面上不少智能体依靠简单的分类器判断命令是否放行这套方案的颗粒度还是太粗。笔记提出的思路是使用可编程的规则表达式做权限管控不仅仅匹配命令名称还会读取脚本文件的内部内容做判断。举一段规则的示例策略exec: 如果命令访问 ~/.ssh 或者 .env* 文件 → 拒绝 如果脚本包含网络外调逻辑并且任务不是部署任务 →拒绝 如果命令属于只读集合 →允许 如果在tests目录符合预期退出码 →允许 如果写操作输出到仓库根目录以外 →询问确认 其余情况拒绝。我们可以针对文件路径脚本内容任务标签多个维度组合条件实现细粒度的安全控制。基础层第二个能力是把Harness框架充当工具路由层。不再把上百份完整工具Schema全部塞给大模型。模型只需要用自然语言描述自己想要达成的意图框架调用Jev完成工具匹配筛选候选工具组装调用参数。工具参数的合法性校验由框架负责参数错误直接返回校验异常而不是交由模型默默吞下错误产生难以排查的静默失败。这套改造甚至不需要彻底重构整套智能体现有项目就可以借鉴落地。查询感知的动态上下文跳出静态窗口的桎梏元注意力是整套架构最核心的创新它彻底推翻上下文是静态不变的固有认知。每接收到一轮用户查询Harness框架会交给Jev两个核心问题。第一现有的KV缓存前缀是否值得继续复用如果重建上下文综合成本和收益会不会更好。缓存复用不再是无条件的默认行为而是一次成本收益权衡之后做出的显式决策。第二我们要如何组装本轮的上下文保留全部对当前查询有价值的信息过滤掉无关的内容。会话运行过程当中所有的工具输入输出模型推理片段用户交互记录都会以可寻址的分块也就是Chunk形式保存在存储当中不会随便删除。针对每一个ChunkJev会根据当前查询给出可见性等级也就是笔记中提到的可见性阶梯一共分为四个档位完全隐藏简短摘要详细摘要完整原文。同样一份2400行的grep检索输出处理A问题的时候它可以只展示12条命中的关键行做简短摘要。处理另外一个完全无关的B查询的时候这一大段检索结果可以直接设置为隐藏完全不进入本轮上下文。原始的数据块依旧完整保存在存储层不会被丢弃。对比传统的会话压缩二者有着本质区别。传统压缩发生在用户提出问题之前我们不知道模型接下来要解决什么任务只能做通用性摘要不可避免丢失潜在关键信息。而基于可见性阶梯的查询感知压缩是拿到查询目标之后才完成信息裁剪。知道需要什么再决定展示什么。框架甚至还可以对工具返回的长文本做热度热力标记根据当前token预算灵活的保留相关片段丢弃无关文本。动态可组装的上下文才让模型路由和子智能体真正具备实用价值。当我们需要把任务交给次级模型执行Harness不需要把完整的全量会话塞给下游模型而是专门为这个子任务组装一份精简的上下文。子任务执行完毕之后返回结果不是直接追加到主会话日志而是处理成为一个带评分的Chunk写入状态存储。主智能体需要的时候再按需加载不需要完整重读子任务产生的全部输出。这样就绕开了之前提到的路由成本陷阱。一旦生成子任务的开销被大幅压低我们就可以大量启用子智能体做并行处理同时也会带来并发系统的一系列挑战。大量子任务同时读写共享代码仓库和会话状态会出现写冲突任务同步智能体之间通信的各类问题。笔记给出的思路是引入带锁的共享状态严格区分读操作和写操作。只读类任务不会争夺写锁可以大规模并发运行。同时增加子目标去重机制每发起一个子任务就把子目标注册到全局注册表。启动新任务之前先做比对如果相同任务已经完成或者正在后台运行就不会重复发起避免大量重复工作消耗资源。分层工具披露与条件化指令解开内置能力的两难工具体系层面Jev架构提出分层披露的设计思路处在永久全量加载工具和临时按需唤起能力的中间地带。模型上下文当中只保存工具简短的描述摘要让模型知道市面上存在哪些能力。只有当模型选定了某一项工具之后框架才会把这份工具完整的Schema定义加载进上下文。当工具调用流程结束对应的完整定义就会从上下文当中清理出去。这套模式直接消解了内置能力的两难困境。智能体出厂可以预置几百个工具海量的参考文档但是这些内容不会常驻占用宝贵的上下文窗口。只有用到的时候才加载细节用完就释放。第三方工具集成的门槛也随之降低不用担忧大量集成带来的固定token开销。更进一步原生Harness框架还可以为每一个内置工具配套专属提示词相当于给工具绑定一个微型子能力引导模型正确调用工具工具的专属逻辑不会污染整个会话的上下文环境。条件化指令加载则重新设计了AGENTS.md这类配置文件的使用方式。现在大部分编码智能体会在会话启动的时候把AGENTS.md完整全部加载进入系统提示词。但文件里面很多规则只针对特定场景生效。比如前端代码的编码规范 billing业务目录下的开发注意事项文学写作的风格约束并不是所有任务都需要这些内容。条件化指令会给每一段规则片段绑定触发条件。当任务编辑tsx前端文件就自动加载前端风格指南。当工作目录切换到billing文件夹自动读取该目录下的风险提示文档。当任务是文本创作加载写作风格样本和避坑清单。这里要区分条件化指令和Skills能力二者的不同。Skills偏向执行动作意思是现在立刻去做某件事。条件化指令代表一套需要被记住的约束规则只要条件匹配就需要生效。更关键的一点条件绑定的指令片段具备抗压缩的特性不会被上下文摘要压缩吃掉只要触发条件成立就会重新加载。这套能力不止局限于编码场景普通对话同样可以受益。当用户要求生成摘要自动加载摘要格式要求用户需要仿写特定文风自动拉取风格样例。顺着这个思路延伸还可以实现结构化Skills行为逻辑会跟随条件自动挂载条件消失就自动卸载而不是一旦加载就永久驻留在会话当中。更远的演化方向就是递归语言模型思路把会话状态保存在命名变量之中而不是淹没在无序追加的对话文本流里面。不止看难度引入数据敏感等级的安全路由过往大家谈论任务路由评估维度只有两个任务难度模型token成本。任务简单交给廉价模型复杂任务交给昂贵的前沿大模型。但在企业生产环境之下还有一个不可忽视的维度数据可信等级。很多低价开源模型的第三方托管服务商没办法承诺输入数据的隐私隔离。如果我们把包含密钥业务核心机密代码的任务随意路由到不受信任的模型端点会带来巨大的数据泄露风险。Jev架构下的路由策略会预先评估子任务大概率会触碰哪一类文件结合文件敏感等级执行路由策略。如果任务只接触公开文档和开源依赖没有内部业务数据就可以任意选择模型优先选用成本最低的选项。如果处理普通业务应用代码只能选择经过安全审核的服务商。一旦任务涉及密钥环境变量基础设施配置这类高敏感文件就强制限定只能使用官方前沿模型。针对企业私有研究代码还可以自定义策略直接排除特定的外部厂商。整套路由规则全部以配置策略驱动不需要修改业务代码。团队出于合规商业竞争等原因想要屏蔽部分模型服务商只需要调整配置而不是靠开发人员人为记牢纪律约束。后台只读任务一次检索多方复用在实际项目之中越来越多的工作需要后台任务支撑。跨模型的代码评审后台自动生成测试评估用例把项目架构通俗化解释生成实时进度网页微仿真模拟这些任务有一个共同特征它们都是只读任务只会读取代码库和会话状态不会做任何修改写入。按照传统实现每一个后台任务启动都要独立执行一遍完整的检索流程重新查找本次变更相关的文件符号diff差异。而我们已经知道检索操作是token开销的最大来源大量后台任务并行会带来非常恐怖的重复计算。Jev的显式状态体系可以很好解决这个痛点。Harness框架执行一次检索找出当前变更对应的全部相关材料这份检索结果被全局共享。所有后台只读任务直接复用这份检索产出不需要各自重新执行检索。一次检索多方消费。区分读写状态共享检索结果能够把大量后台任务的运行成本压到很低。也让我们可以放心的同时运行更多辅助后台作业拓展编码智能体的能力边界。现实落地的思考不要陷入架构完美主义通读整套设计之后我们很容易被一整套优美的架构吸引但我们也要清醒看到落地过程之中的现实约束。Jev并不是一个开箱即用的开源库它来自一套设计笔记很多细节没有给出成熟工程实现方案。首先显式分块状态管理可见性阶梯条件指令共享检索这些能力都需要Harness执行框架深度改造。如果我们基于现有主流Agent框架二次开发很多底层能力会受限于框架本身的抽象改造难度不小。其次Jev本身如何实现材料没有给出确定答案。Jev本身可以是小模型也可以是提示词驱动的大模型甚至混合部分硬编码规则。高频调用带来的延迟置信度阈值调参都是工程上需要啃的硬骨头。每一次上下文组装放弃KV缓存重建上下文本身也会带来推理成本我们需要做好成本权衡不是任何场景都无条件放弃缓存。同时整套架构给工程调试带来新挑战。会话状态不再是简单可读的对话日志而是一堆带元信息的Chunk集合。排查问题的时候开发者需要工具查看每一个Chunk的属性Jev每一轮的决策结果可见性打分。可观测性工具必须配套跟上否则一旦出问题排查难度会急剧上升。但这份设计笔记最大的价值并不是提供一套可以直接复制粘贴的代码方案而是帮我们打破固有的思维定势。很长一段时间行业陷入模型迷信总觉得只要基座模型更强智能体的全部问题就迎刃而解。可编码智能体是一套完整的系统大模型只是系统当中的一个组件。我们常常忽略上下文组装状态管理任务调度安全策略这些周边体系的力量。很多产品体验上的顽疾根源不在于模型不够聪明而是追加式会话KV缓存的约束下做出的层层妥协。Jev带给我们最重要的启示编码智能体真正的杠杆点不在循环调用模型的那一层而在于每一轮循环我们究竟选择把什么样的信息递交给模型。上下文窗口不应该是会话运行过程当中被动累积出来的流水账它应该是框架主动有意识组装出来的工作视野。即便不完整落地整套Jev架构其中很多思路查询感知的上下文裁剪分层工具暴露安全维度的路由共享检索的后台任务都可以拆解出来融入到当下的项目迭代当中。技术的迭代往往是这样有时候困住我们的不是技术上限而是我们从未怀疑过的既有范式。敢于做思想实验把已经习以为常的底层假设拿掉重新推演往往就能看到过去看不见的优化方向。