本文永久链接 – https://tonybai.com/2026/09/24/jev-engineering-for-coding-agents

大家好，我是Tony Bai。

【导读】

今天的 Coding Agent 几乎陷入了同质化困境：一个围绕 LLM 的 while 循环、一个塞满工具 Schema 的巨型 Prompt，外加一条无休止向后追加的聊天记录。我们本以为模型路由能省钱，算完账却发现它更昂贵；我们以为压缩能减负，排查 Bug 时却发现关键细节被提前吃掉。本文基于 TypeSafe 创始人 Diogo Almeida 的原始设计笔记，抛出了一个发人深省的核心追问：如果语言模型没有 KV Cache，你会如何重新设计编码智能体？ 从破除“KV 缓存的暴政”出发，作者提出了以专用决策模型 Jev 为中枢的全新架构蓝图，将上下文从“被动累积”颠覆为“精密装配”，系统推导了路由数学账本、工具分级披露与高并发只读管道的实战解法。

【文章要点】

• 核心思想实验：现有 Agent 对“仅追加式上下文”的盲目依赖源自 KV 缓存的经济学诱惑，但这直接导致了模型路由反而更贵、工具挤占窗口、盲目压缩丢失线索、子智能体难以真正并发等六大系统性暗病；
• Token 消耗真相揭秘：在真实的编码 Agent 会话中，“手写代码”仅占总消耗的 4%～10%，而文件读取与代码检索占据了近 60% 的绝对主导，智能体提效的真正突破口在于检索与召回机制；
• 元注意力与可见性阶梯：放弃静态一次性压缩，由 Jev 在每轮交互中根据具体意图对语块实施“隐藏/简要/详细/全文”四级动态裁剪，实现查询感知的高密度上下文装配；
• 真·模型路由算账逻辑：单纯看单 Token 费率折扣是伪命题，必须把下游上下文重新加载与上游结果重读代价纳入公式，唯有搭配精简定制的独立切片，子智能体分流才具备商业可行性；
• 渐进式工具披露与条件化指令：采用“先代码片段、按需索取 Schema”的分级机制彻底解放工具箱容量；将 AGENTS.md 规则与具体目录和上下文触发条件深度绑定，赋予其“压缩免疫力”；
• 只读后台管道并发共享：将耗时的代码依赖与变更波及面检索做成单次开销，全量共享给后台并行运行的代码审查、进度小站和自动化测试等只读流水线，榨干并发红利。

近两年来，从 Cursor、Windsurf 到 Claude Code 和各类开源框架，编码智能体（Coding Agent）如雨后春笋般涌现。然而，当我们剥开各类华丽的包装后，会发现绝大多数 Agent 的本质极其简陋：一个围绕大语言模型的 while 循环、一个包含所有工具 Schema 的巨大 Prompt，再加上不断向后追加的上下文对话记录。

为什么模型路由经常越省越贵？为什么工具一多模型就变蠢？为什么上下文压缩（Compaction）总是在关键时刻遗漏核心细节？为什么子智能体（Sub-agent）难以真正并行？

本文翻译自一份基于 TypeSafe 创始人 Diogo Almeida 设计笔记整理的深度技术备忘录《Jev Engineering for Coding Agents》。文章抛出了一个极其尖锐的思想实验：“如果大语言模型从一开始就没有 KV Cache（键值缓存），你会如何设计编码智能体？” 由此出发，作者深入剖析了当今 Agent 架构所受到的“KV Cache规则”束缚，并提出了一套全新的 Harness（智能体运行框架）范式——以专用的决策模型 Jev 为核心，将状态完全显式化与类型化，重构上下文装配、模型路由、渐进式工具披露与并发机制。

无论你是正在一线开发 AI Agent 的工程师，还是关注底层架构演进的技术极客，这篇视角独特、算力账本清晰的深度研读笔记都不容错过。以下为中文译文全篇。

用于编码智能体的 JEV 工程学：TypeSafe 创始人基于 Jev 的构建蓝图

供学习研究之综合整理 · 基于 Diogo Almeida（TypeSafe）的设计笔记
独立整理于 2026 年 9 月。未经 TypeSafe 关联或背书

上图是Jev Harness 运行框架。显式状态（左）以可寻址、带类型的语块（Chunks）形式存储。Jev（右）回答每轮交互中的决策问题：展示哪些语块、是否复用缓存、使用哪个模型与工具、以及命令是否允许执行。上下文装配（Context Assembly）与路由器（Router）为运行时（Runtime）提供输入，运行时在安全策略约束下，以“先代码片段、按需提供模式（Snippet-first, Schema on demand）”的方式调用数百种工具，并将任务路由至前沿模型、子智能体、轻量模型或后台审查模型。

摘要——编码智能体（Coding Agent）的本质出奇地简单。绝大多数都只是一个围绕模型与少数工具运行的 while 循环，除模型自身能力的演进外，框架层鲜有实质性创新。本文基于 TypeSafe 创始人 Diogo Almeida 的设计笔记，系统梳理了围绕 Jev 构建编码智能体的思路。Jev 是 TypeSafe 推出的专用决策模型，能将结构化状态转换为类型化输出（如选择、评分以及 noul 判定等）。笔记始于一个发人深省的问题：如果语言模型没有 KV Cache（键值缓存），你会如何设计编码智能体？这一问题揭露了当前各类智能体未经深思便继承的六大设计缺陷：导致成本不降反升的模型路由、挤占上下文的工具调用、盲目丢失关键信息的压缩机制、极少真正被触发的子智能体、丢失全部良性状态的会话重启，以及内置功能（Batteries）与上下文容量的权衡争论。我们在此呈现该笔记提出的替代架构：一个围绕显式、类型化状态构建的 Harness 运行框架，由 Jev 负责每轮推理的决策调度——每个上下文语块均针对当前查询动态打分，路由成本计入重新处理开销，工具按层级渐进披露，指令依条件动态加载，且只读后台任务共享单次检索通道。我们系统推导了路由的数学算账逻辑、真实智能体交互中的 Token 消耗分布，以及基于文件敏感度而非单纯难度的安全路由设计。

索引词——Jev，TypeSafe，编码智能体，Harness 工程学，KV 缓存，上下文工程，模型路由，子智能体，工具调用，上下文压缩，AGENTS.md，后台智能体。

一、为什么还需要另一款智能体？

设计笔记首先提出了四个先决假设：

第一，编码智能体本质非常简单，尤其是其 Agentic 核心逻辑：一个循环、一个模型，再加上几个工具。

第二，现有智能体中最优秀的部分可以直接复用。前沿模型皆可通过 API 接入，开源项目提供了源源不断的灵感乃至 UI 组件，仅有少数领域（例如 MCP 服务器的身份验证）存在真正的工程复杂度。

第三，官方原生智能体（First-party agents）的成本优势可能正在逐步缩水，因为用户使用习惯正在从打包订阅制转向按需付费的 API 计费模式。

第四，也是最重要的一点：某些核心能力只能原生构建。它们无法作为插件挂载到别人的智能体中，因为它们必须在每一轮交互中完全掌控上下文的装配过程。

这第四个假设正是本文的核心论点：如果一个智能体仅仅是一个循环，那么核心杠杆并不在这个循环本身；真正的杠杆在于每次循环流转时，框架究竟向模型投喂了什么。

A. Jev 的定位

Jev 并不是负责编写具体业务代码的模型，而是坐镇其旁的决策层。

Harness 框架会将当前的应用状态（目标、上下文、规则、可用操作、历史操作）连同预设的决策问题一并提交给 Jev，Jev 则返回类型化（Typed）的明确答案：一个选项、一个分值、或是一个附带概率分布的 noul 判定。随后，由前沿大模型、子智能体、具体工具或确定性代码去执行实际的工作。正因为其输出是强类型的而非自由文本，运行框架可以直接进行校验、施加阈值限制并据此分流，完全无需解析自然语言文本。

本文中提及的每一项原生特性，其底层都是在极高频的决策节点上向 Jev 抛出的一个问题：下一轮交互应该包含哪些语块？当前子任务是否应当脱离前沿模型处理？哪一个工具最符合当前意图？这条命令是否允许运行？在单个会话中，这类微小决策会被调用数千次，而设计笔记认为，架构的巨大杠杆正是蕴藏在这些微小决策之中。

表 I：编码智能体中的 Jev 决策问题

B. 统领全局的核心之问

笔记中记录了一个作者最喜欢拿去启发其他工程师的问题：如果大语言模型没有 KV Cache，你会如何设计编码智能体？

KV Cache 是当今所有智能体皆被设计为“仅追加式交互记录（Append-only Transcripts）”的根本原因。复用已缓存的前缀成本极低；而一旦修改了上下文早期的任何内容，缓存即告失效，模型不得不从修改点开始重新处理之后的所有内容。

这一单一的经济学规律，在无人明言的情况下，默默塑造了现有智能体几乎所有的架构决策。

在思想实验中剥离缓存的存在，会带来两个结果：

第一，它使得为 Jev 量身定制的“显式状态设计”成为可能——此时上下文是**动态装配（Assembled）的，而非被动累积（Accumulated）**的；第二，它揭示了为什么许多看似符合直觉的策略（例如将简单任务路由给便宜的模型）在实践中往往彻底失败。笔记将这种现象称为“KV 缓存的暴政（Tyranny of the KV Cache）”。

二、KV 缓存的六大症状

表 II：现有智能体继承的六大设计缺陷

A. 路由为什么不可行

直觉上的降本方案通常是：让前沿模型负责规划，将具体执行下放给便宜的模型，最后再让前沿模型复核收尾。笔记基于公开标价进行了算账：假设 Opus 的输入和输出分别为每百万 Token $5 和 $25，Sonnet 为 $3 和 $15。令 $X$ 为上下文 Token 数，$Y$ 为生成的输出 Token 数，$Z$ 为任务执行期间额外读取的 Token 数（例如命令输出与文件读取内容）。

路径 1：纯 Opus 方案
 生成：25·Y
 读取：5·Z
 总计：25Y + 5Z

路径 2：Opus → Sonnet → Opus 混合路由
 Sonnet 加载上下文：3·X
 Sonnet 生成：15·Y
 Sonnet 读取：3·Z
 Opus 重新载入变更内容：5·(Y + Z)
 总计：3X + 20Y + 8Z

只要会话上下文较长（X 较大），或者执行过程中读取的内容远多于输出内容（Z 远大于 Y），或者二者兼有时，路径 2 的开销反而会显著高于路径 1。代入一组贴近真实会话的数据分布（X = 0.65, Y = 0.12, Z = 0.23），纯 Opus 路径的相对成本仅为 4.15，而混合路由路径的成本却高达 6.19。直接全程使用前沿模型，成本仅约为那个“自以为能省钱的路由方案”的三分之二。

路由陷阱将执行委托给轻量模型，既在下游引入了新的上下文加载成本，又在上游回传时带来了重新处理开销，两者叠加直接抵消并超过了单 Token 费率的折扣。

这一对比得出的结论并非“路由本身是错的”，而是：脱离上下文重建开销、单纯按单 Token 费率计价的路由机制是错的。

只有当运行框架能够为轻量模型提供一份小巧且专门构建的独立上下文（而非丢给它完整的交互历史），且结果返回时无需迫使前沿模型通读助手生成的所有冗余细节，模型路由才具备真正的商业可行性。

B. 工具调用：一个奇怪的妥协

在当前的范式下，所有工具都必须在系统消息（System Message）中提前声明，并带上完整的参数 Schema，无论当前这一轮交互中是否需要用到它们。这不仅占用了大比例的上下文空间，而且在笔记看来，也并未带来多么聪明的工具选择表现。

一个工作假设是：模型在面对**高基数工具集（一次性面对过多工具）与非标准工具调用格式（使用模式有别于模型预训练语料中的标准调用）**的交织场景时，理解能力会严重下滑。

这也在一定程度上解释了，为什么采用“加载简短描述、延迟展开细节”的 Skill（技能）机制，其效果往往显著优于罗列大量原始工具清单和挂载臃肿的 MCP 服务器。

C. 上下文压缩的盲区

如果未来的每一个交互轮次都需要完全相同的共享状态，那么上下文压缩（Compaction）是完全合情合理的。

然而，笔记质疑了这一基本假设。

通用的摘要压缩极为困难且极易造成关键信息丢失。相比之下，面向查询的动态压缩（Query-aware compression）要容易得多：只要你知道下一个问题具体是什么，你就清楚究竟该保留哪些上下文。而在下一个问题提出之前就生成的静态摘要，几乎注定会漏掉后续排查所必须的关键线索。

D. 子智能体为何反响平平

多模型并行化的实际普及度远低于人们的预期。笔记推测其根本原因在于状态管理的失控：决定到底将父级会话的哪部分上下文裁剪给子节点，以及如何将每个子智能体的探索发现抽丝剥茧地合并回主分支，极其困难。

当这一决策过程变得高昂且极易出错时，模型本身就会倾向于回避生成并行任务。

E. 会话重启的存在

当交互上下文产生幻觉漂移或遭遇污染时，用户最常规的应对手段往往是直接重启会话。这种做法极为粗暴，它将有用状态与劣质状态一并抹除。如果能将系统状态抽象为相互独立的可寻址语块，替代方案便是干净地重新拉起会话，并仅按需重新挂载那些依旧相关的有效历史语块。

F. “自带电池”的两难博弈

智能体究竟应不应该内置大量现成能力？业界对此长期存在争论。如今这变成了一种零和博弈：一端是追求开箱即用、功能繁复的“重装集成型智能体”；另一端则是像 Claude Code 和 Codex 这类将控制权留给高阶用户的精简极简工具。这种对立之所以存在，纯粹是因为在旧架构下，每一项内置功能都意味着要对上下文空间施加永久的 Token 税。一旦消除这一永久占用成本，两难之争自然冰消瓦解。

三、Token 究竟消耗在何处？

在重新设计Harness运行框架之前，首先必须搞清楚在一次完整的开发会话中，Token 预算究竟被哪些环节瓜分殆尽。下表基于典型的 CLI 编码智能体会话，对不同子任务在总处理 Token 消耗中的占比进行了测算。该测算基于输入权重视角（Input-heavy view），即重复读取的上下文在每一轮中均累积计算。

表 III：各子任务 Token 消耗份额（输入加权视角）

最引人注目的数据恰恰落在表格底部：编写代码——这个编码智能体赖以存在的立身之本——竟然是占比最小的消耗项之一。代码检索与文件读取牢牢占据了绝对主导。

第三方独立调研也印证了这一事实：微软的 fastcontext 项目在针对 GPT-5.4 运行轨迹的分析中指出，文件读取与搜索占用了所有工具调用轮次的 56.2%，并消耗了主智能体总 Token 量的 46.5%。

如果该结论具备普适性，那么编码智能体领域最大的能效提升突破口，绝不在于换用稍微强大一点的模型或微调 Diff 输出格式，而在于更智能的代码检索与召回机制。

四、基础层：权限控制与工具路由

有两个基础改进可以被直接无缝集成到任何现存的编码智能体中，无论其底层是否基于原生 Jev。

A. 可编程权限引擎

智能体意图运行的每一条终端命令，都必须回答一个基本问题：它到底该不该被执行？Claude 的自动模式目前依赖一个内部分类器来判断。而笔记主张推进得更深一步：将权限转化为基于规则的可编程查询，并在高风险操作时进行深度静态分析——例如在运行某个 Python 或 Shell 脚本前，先静态扫描其脚本内部代码，而非仅仅根据命令名称本身草率放行。

policy "exec":
 deny if command touches ~/.ssh or .env*
 deny if script contents contain network egress
 and task.scope != "deploy"
 ask if command writes outside repo root
 allow if command in read_only_set
 allow if tests/ and exit code is expected

B. 作为工具路由器的 Harness

不必将每一个工具的庞大 Schema 都全量暴露给大模型，Harness 运行框架完全可以横亘在“意图表达”与“具体调用”之间。

主模型仅需用自然语言清晰描述它试图做什么。随后，Harness 会调用一系列类型化的 Jev 判定，从中筛选出最匹配的一款工具（或前几个候选工具），并自动化组装其输入参数。这样一来，主模型完全不必在上下文里常驻成百上千个工具描述，而一旦参数类型不匹配，系统会直接抛出类型校验错误，杜绝了模型在黑盒中发生静默失败。

五、元注意力（Meta-Attention）：将上下文视作决策

该方案的核心主张在于彻底颠覆“上下文是静态累加的”这一传统认知。每当用户输入一条新 Prompt 时，框架都会向 Jev 抛出两个核心决策：

第一，评估上一轮上下文的留存价值：究竟是继续复用现有的 KV Cache 前缀在经济与性能上更划算，还是彻底抛弃旧缓存、从零组装一个全新上下文更加经济高效？这被确立为一次显式且具备成本感知的计算决策，而非随波逐流的默认行为。

第二，如果需要新建上下文，如何精准构建一个“包含所有相关内容、同时剔除一切无关噪音”的全新上下文？

在其最基础的实现形态下，这相当于针对上下文中的每一个基本语块实施一次 noul 判定：每一组工具调用的输入、输出、每一段内部推导过程，以及可能包含的与用户的每一轮问答。在进阶演进版本中，这一判定由单一布尔打分扩展为多级的可见性阶梯（Visibility Ladder）。

上图展示了针对当前查询，同一个语块可以根据相关度被完全隐藏、提取极简摘要、生成详细摘要、或是全量展开展示。这赋予了系统“查询感知型压缩（Query-aware compression）”能力，彻底补足了传统固定压缩的缺陷。

这一机制的巨大回报在于：既完整保留了上下文压缩的初衷，又彻底根除了其固有缺陷。 传统压缩在问题未知时就草率执行了一次性压缩；而可见性阶梯则是在明确了当前具体问题之后，按需实施动态剪裁。一段长达 2400 行的 grep 检索记录，在面对一个具体排查时可以被精准提炼为 12 条高度相关的关键行，而在下一轮无关询问中则完全静默隐藏——但它自始至终未曾从系统的全局状态存储中被物理删除。

笔记还提出了一个颇具极客美感的设想：如果框架能够以热力图（Heatmap）的形式精准计算出 grep 输出中哪些代码段最具参考价值，它便能在预算允许的任意精度内对该段输出进行动态抽稀截断。“而且毫无疑问，”笔记补充道，“这在界面呈现上也会显得非常酷。”

六、重构模型路由与子智能体

一等公民级别的动态上下文组装能力，是重新盘活模型路由技术的关键钥匙。

一旦 Harness 框架能够为某个细分子任务量身组装出一份精简、高密度的上下文切片，将该子任务下放给廉价或极速模型处理便不再需要让这些小模型去硬吞整个长篇历史；而处理完毕的结果，能以打分语块的形态干净利落地合并回主干，无需前沿模型去被迫重读整个低端模型的生成过程。一切运转皆严格遵循成本感知与智能感知。

这套机制同样彻底解放了子智能体（Sub-agent）的应用天花板。笔记推测，如今子智能体调用成本之所以居高不下，其大头往往消耗在“决定向它传递哪些上下文”的踌躇与开销上，而用户本身的输入往往只是一句简短指令。倘若这类执行上下文的构建能够变得极其廉价且全自动化，子智能体的调用频次便能迎来数量级的提升。这同时为产品交互赋予了直接的调控旋钮：用户既可以设置“加大预算以追求更极致的速度与效果”，也可以选择“保守运行以尽可能缩减每一分开支”。

A. 极致并行与并发控制

一旦任务派生（Spawn）的边际成本趋近于零，系统将不可避免地迎来高并发任务的群组执行。此时 Harness 便会自然接管经典并发系统面临的挑战：同步原语、智能体间通信通道，以及多个 Agent 并发访问共享工作区时的写冲突。

笔记给出的架构建议是：采用附带读写锁的共享状态存储。由于框架对状态访问进行了显式的读写类型区分，这一机制将具备极高的可工程化落地性——因为纯只读类任务之间永远不会发生锁竞争。

B. 目标去重机制

在类似 /goal 这类目标导向的自驱循环中，一个长期存在的隐患是智能体是否会陷入重复劳动。笔记提出了一套对冲缓解方案：在派生任何子任务之前，必须先将其登记为一个具名子目标（Subgoal），并在全局范围内与历史子目标进行去重对比。凡是已经完成的、或是当前已处于执行流中的同类工作，严禁被二次重复触发。

七、从第一性原理重构工具与技能

笔记主张在当今“全量加载的静态工具”与“完全按需调用的技能（Skills）”之间，建立一个全新的缓冲层。

如果一个模型根本不知道某种操作的存在，它自然无法主动发起调用，因此系统必须为其提供一份简述各能力的“极简摘要片段”，其形态类似于 Skill 技能简介。但这类片段根本不需要常驻在系统提示词中，完全可以在检测到潜在意图时再动态加载。

而在这些片段背后，则是一套在需要时能够导出可用操作完整 Schema 的机制，类似于“工具元搜索”能力。将这套架构严丝合缝串联起来的核心约束在于：无论调用了多少工具与文档，一旦任务结束，这些内容绝不允许对主上下文造成永久性污染。

模型首先查阅一张覆盖全部能力的廉价全景图谱，仅对自己选中的极少数工具按需支付获取 Schema 的成本，并在任务执行完毕后立即从当前上下文彻底卸载这些细节。

如果这一机制切实运转起来，第二节中提及的“内置功能之争”将不复存在。因为当一项内置能力的闲置待机成本趋近于零时，智能体完全可以出厂直接内置数以百计的专用工具与成千上万页的技术文档。笔记还顺带指出了一项附带收益：这类近乎零成本的外部生态整合，本身就是极佳的商业联合营销（Co-marketing）渠道，同时能够带给用户无缝丝滑的“开箱即用”体验。

A. 打造更高质量的原生能力

开源社区中许多号称能提升 Agent 表现的辅助工具，在实际部署中往往并不灵光。笔记以“工具输出压缩器”为例，指出了背后的核心痛点：基座模型在原生层面上往往缺乏对这些奇特工具输出格式的先验理解。一个设计优良的原生 Harness 框架，应当为每一个收纳的工具配备经过官方微调的一方 Prompt，专门教会模型如何高效操纵该工具——这实际上相当于为每个工具量身定制了一个微型的内置子智能体或专用 Skill；加之拥有动态隔离的整洁上下文环境，这些专有逻辑绝不会向会话的其余部分扩散污染。这里同样蕴含着敏锐的市场考量：对业内当下最流行工具的快速官方接入与支持，能让智能体始终保持在开发者的焦点话题中心。

八、条件化指令加载

当今的 AGENTS.md 规范通常是将整个文件一股脑全盘加载。笔记提出应当采用按条件分块加载机制。比如：当且仅当涉及到前端界面代码的修改时，才载入前端样式规范指南；当且仅当终端路径深入到特定子目录下时，才载入该目录专属的“踩坑避雷指南（Footguns file）”——笔记甚至建议项目的每一个关键子目录都理应标配一个避雷清单。

指令规则与具体的上下文触发条件绑定，而非硬编码绑定在整个会话上；条件片段被深度锁存，彻底免疫被全局压缩机制误删的风险。

这种设计乍看类似于技能机制，但笔记清晰划定了两者的本质界限：技能（Skills）的语义倾向于 “现在执行这个操作”；而条件化指令（Conditional instructions）的语义则是 “在内存的某个角落牢牢记住这个规则”。后者天然要求具备一项当前 Skills 普遍缺失的关键特性：上下文压缩免疫力。

在一个长周期会话初期加载的 Skill，随着轮次推进，大概率最终会被压缩算法摘要丢失；而一个与条件绑定的指令规则，只要该上下文触发条件依旧成立，就会在每一轮装配中被准确重新锚定。

笔记观察到，即使在日常的非代码对话中，这种机制也同样是刚需：一个要求总结概括的 Prompt，理应自动调出用户偏好的排版模板；一个要求仿写文本的 Prompt，理应精准挂载用户的文风样张与禁忌词表；而一段要求编写业务代码的 Prompt，理应按需拉出团队的代码规范，附带一条醒目的警告：“切勿堆砌成百上千条无意义的单测断言”。

A. 结构化技能（Structured Skills）

随着 Harness 运行框架可编程能力的深化，技能本身应当能够携带更深层的运行时行为变更，而绝非仅仅提供几句被动指令，其形态类似于 Claude Code 的 Skill Hook 扩展点，但能力边界要强大得多。笔记对当今现有 Hook 系统的最大诟病在于：一旦挂载进系统，Hook 就会不可逆地永久驻留在会话中。而结构化技能则具备完全的动态生命周期：随着触发条件的满足而注入，随着条件的消失而自动优雅卸载。

B. 递归语言模型（Recursive Language Models）

另一个高度相关的演进方向是递归语言模型范式：它倾向于将智能体的绝大部分运行时状态显式剥离为一个个强类型的具名变量，而非放任它们变成一段段糊在上下文窗口里的松散 Transcript 自然语言。在一个由结构化变量来掌控状态的世界里，整个运行环境的纯净与鲁棒程度，将远远超越那个“全靠上下文窗口里残存了什么就处理什么”的混沌旧世界。

九、面向安全策略的敏感度路由

当今的模型路由策略，其决策维度几乎完全局限于“任务难度”与“Token 成本”。笔记引入了至关重要的第三个核心维度：数据信任（Trust）。

目前市面上某些通过低成本中转 API 托管的开源权重模型，其调用成本确实远低于主流前沿模型，但笔记直言不讳地指出了安全隐患：流经这类不可信端点的数据存在严重的隐私泄露风险。为此，笔记提出的解法是：为每一个拆解出的子任务预估其潜在触及的文件类型，将安全策略与文件类型相绑定，并依此驱动下层模型的路由选择。

表 IV：基于数据敏感度的安全路由策略

表格中最后一行揭示了一个更宏观的现实：成本与难度从来都不是决定模型路由的唯二因子。一家技术公司完全有理由在开发自身模型资产时，明令禁止调用某特定竞对的模型 API；或者在处理高度敏感的核心业务时，主动规避某些特定的中转托管商。一旦路由机制彻底演进为策略驱动（Policy-driven），这些繁琐复杂的商业与安全合规考量，便能一键收敛为透明的底层配置文件，而无需再仰赖一线工程师个人的职业操守与肉肉记忆。

十、只读后台处理管线

笔记精准捕捉到了当前各大热门 Agent 工作流中正在涌现的一个共性模式：一边写代码一边并行动态更新的 HTML 进度看板；业界关于“代码理解力而非生成速度才是当今全新技术瓶颈”的论调；全天候静默跑在后台的自动化 Eval 测试生成；只用极简大图与寥寥数语向开发者直观拆解系统架构的 ELI5 解释器；以及让开发者在漫长跑测过程中能在手机端随时刷新看进度、看截图的 Web 进度小站。

一个与此高度契合的工业界实战模式是：在正式升级主力模型之前，先将线上实时流量镜像分流至候选模型，在后台默默进行为期一整天的全自动 Eval 评估。

这批五花八门的新工作流，其背后都有着惊人一致的底层物理特征：它们完全作为正常编码主流程的轻量扩展在后台异步运行，且对当前代码库的状态而言，它们是绝对纯粹的只读函数（Read-only functions）。 包括跨厂商模型的交叉代码审查（如用一家厂商的 Agent 审查另一家模型产出的代码），其本质完全符合这一物理模型。

寻找与代码变更相关的各类依赖与符号是一项昂贵的非平凡计算；该检索过程仅需执行一次，即可全量共享给所有只读后台子任务。

这正是 Jev 核心方法论展现碾压性优势的战场。一个以 Jev 为决策中枢的 Harness 框架，对上下文内的语块颗粒度以及每一次操作的“读/写属性”有着绝对精确的掌控力。

在代码库中精准定位某次修改到底波及了哪些上下文信息，是一件极度耗费算力的苦差事。如果这套沉重的检索结果能够被沉淀下来，并被所有的后台分析任务一次性全量共享，而无需让每个后台工具各自重复检索一遍，后台任务的运行成本将瞬间暴跌几个数量级，从而使得原本昂贵奢靡的深度并发分析在经济上变得完全可行。

正如设计笔记中一针见血的断言：将系统行为的读写类型严格显式化，终将赋予智能体近乎开挂的超能力（Superpowers）。

十一、候选内置工具清单

笔记在末尾梳理了一批具备极高集成潜力的优秀开源项目，并逐一附上了在 Jev 框架下对它们实施原生接入的工程设计构想。

表 V：候选原生集成工具矩阵

十二、结语

这份设计笔记抛出了一个看似极易理解、实则极难落地的深刻论点：编码智能体的核心循环出奇地简陋，而决定智能体天花板的杠杆，从来都不在循环本身。核心杠杆永远在于：每一轮循环启动时，外层的运行框架究竟向模型投喂了什么。而在当今的技术体系下，这一至关重要的决策权，却被完全默认交由一个由 KV Cache 经济学所畸形绑架的“仅追加式交互历史”来草率裁决。

只要我们在思想实验中坚决地将 KV Cache 剥离抽走，此前习以为常的六大经典顽疾瞬间呈现出了全然不同的本质面目：

• 路由之所以折戟，绝非因为轻量模型过于孱弱，而是因为上下文切换时的重新加载开销反噬了一切；
• 工具之所以挤占窗口，纯粹是因为当今框架强行要求所有 Schema 在开局时全盘托出；
• 压缩之所以丢三落四，是因为它在根本不知道下一个问题是什么的情况下就在盲目执行截断；
• 子智能体之所以沦为摆设，是因为父子节点之间的上下文剪裁与状态回传重重受阻；
• 会话之所以动辄重启，是因为缺乏细粒度状态管理，导致开发者不得不为了清除系统幻觉而将有价值的资产一同抛弃；
• 内置功能之所以引发无休止的争吵，唯一的原因在于每一行内置指令都构成了对宝贵上下文空间的永久性征税。

本文所勾勒的新一代 Harness 框架，旨在用一套组合拳同时击碎这六大枷锁：将整个系统的状态彻底显式化与类型化，在每一轮交互中，由专职决策模型 Jev 对上下文装配、模型路由、工具挑选与执行权限进行全方位的按需动态裁决。

语块依据可见性阶梯被动态赋予展示精度；模型路由严格基于上下文重建开销统筹算账；工具能力遵从层级划分逐步渐进披露；业务规范指令与上下文触发条件强力绑定；所有只读类后台任务完全共享底层的单次检索通道。

实现这一切，并不苛求我们立即拥有下一代更强大的基座大模型。它所真正需要的，是我们对待上下文窗口态度的根本蜕变：将上下文窗口视作一个每一处细节都因具体意图而精准装配的精密工坊，而非一个由历史垃圾因循守旧、随波逐流自然堆砌而成的意外产物。

参考文献与数据来源 (SOURCES)

本报告为独立研究整理成果，非 TypeSafe 官方出版物，未经 TypeSafe 关联或背书。关于 Jev 的架构属性，参考自 TypeSafe 公开披露的架构资料，将其定义为“输入结构化状态，输出带有置信度概率的类型化选项、评分及 noul 判定”的专业决策模型。文中的核心论点、路由算账数学模型、六大症状剖析及所提出的架构设计，均基于 TypeSafe 创始人 Diogo Almeida 共享给整理者的原始设计笔记。关于代码检索与文件读取的 Token 消耗占比数据（占所有工具调用轮次的 56.2%，占 GPT-5.4 主智能体处理 Token 的 46.5%），采纳自微软 fastcontext 开源项目的测试分析报告。各子任务 Token 消耗分布表格为 CLI 编码智能体会话的经验估算模型。递归语言模型（Recursive Language Models）理念参考自 A. Zhang, 2025 年的相关学术论文。所涉及的第三方工具参考：headroom、rtk、ast-grep、ast-outline、fastcontext、fff（均归属于 GitHub 相应开源仓库）。模型价格均基于笔记成文时各厂商的公开标准 API 标价，后续可能会有变动。文内所有架构图与示意图均为重新绘制的原创图表。

声明：本内容仅供技术研究与学习探讨。本篇非 TypeSafe、Anthropic、OpenAI、微软或文中提及之任何商业实体的官方出版物，亦未获得其官方背书或建立任何隶属关联。文中所引用的各类成本核算仅作理论推演说明，均基于原始设计笔记引述之时价。所有示意图表均为独立重构绘制。

还在为写 Agent 框架频频死循环、上下文爆炸而束手无策？我的新专栏 《从0 开始构建 Agent Harness》 将带你：

• 抛弃臃肿框架，回归“驾驭工程 (Harness Engineering)”的第一性原理
• 用 Go 语言手写 ReAct 循环、并发拦截与上下文压缩引擎等，复刻极简OpenClaw
• 构建坚不可摧的 Safety Middleware 与飞书人工审批防线
• 在底层实现 Token 成本审计、链路追踪与自动化跑分评估
• 从“调包侠”进化为掌控大模型边界的“AI 操作系统架构师”

扫描下方二维码，开启从 0 开始构建Agent Harness 的实战之旅。

还在为“复制粘贴喂AI”而烦恼？我的新专栏 《AI原生开发工作流实战》 将带你：

• 告别低效，重塑开发范式
• 驾驭AI Agent(Claude Code)，实现工作流自动化
• 从“AI使用者”进化为规范驱动开发的“工作流指挥家”

扫描下方二维码，开启你的AI原生开发之旅。

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。