不要让LLM做循环判断：用Jev决策模型为Agent降本增效

我在用 Agent 处理一个超大批次任务时遇到过一个特别典型的场景：Agent 要在循环里遍历几百个文件，每处理一个文件就要让 LLM 判断一次"这个文件值不值得处理""上一步结果对不对""接下来该走哪个分支"。跑了一个多小时，Token 烧掉了好几万，结果回头一看，模型在三分之一的地方就开始反复横跳——同样的输入，前后两次给了完全不同的判断。那一刻我意识到，Agent 循环里 80% 的判断根本不该交给 LLM。那些判断不是"智能问题"，是"流程问题"。LLM 擅长的是理解模糊语义和生成方案，而不是在循环里反复做布尔判断、格式校验、状态迁移和路由分流。后来我接触到了 Jev 这套决策模型，把高确定性的判断从 LLM 里剥离出来，整个 Agent 的运行成本降了一个数量级，稳定性也彻底不一样了。

这篇东西就是把我这段时间的实践和思考完整梳理一遍。我会从最底层的成本账开始算起，讲清楚为什么 LLM 不适合做循环里的高频判断，然后拆解 Jev 决策模型的核心思路，画出一条"哪些判断留在规则层、哪些判断升级到模型层"的清晰边界。最后我会用一个文件整理 Agent 的实际改造案例和几个踩坑实录收尾，给正在搭 Agent 循环的朋友一份可以直接参考的作业。这篇文章适合两类人：一类是被 Agent 循环烧 Token 烧到肉疼的开发者，另一类是刚开始设计 Agent 架构、想把"流程确定性"和"模型智能性"分清楚的新手。

1. 先算一笔账：Agent 循环里"每个判断"到底要花多少钱

先别急着聊模型选型，我们把成本拆开了看。

一个典型的 Agent 循环长这样：读取输入 → 让模型判断这是什么 → 决定下一步动作 → 执行动作 → 检查结果 → 再判断下一步。听起来没什么问题，但你在"判断"这一步付的代价，远比你想象的高。

1.1 一次 LLM 判断的三重成本：钱、时间、不确定性

第一重成本是 Token。哪怕你用最轻量的模型，一次带上下文的判断也要消耗几百个 Token。假设你对 Agent 循环里的每一步都调用模型，一次循环少说五次调用，一小时跑几百次循环，账单数字很快就不好看了。

第二重成本是延迟。模型调用不是本地函数调用，一次请求往返普遍要一到三秒。你在循环里塞了十次判断，就是十几秒的空等。文件数量一上来，这个时间差会被无限放大。

第三重成本最容易被忽视，也是最致命的——不确定性。同一个输入，模型两次调用可能给出完全不同的判断结果。今天判断"这个文件是待处理"，明天同样条件下判断"这个文件已处理过"。这种波动会让 Agent 的循环彻底失控：状态错乱、重复处理、提前终止，什么毛病都会冒出来。

1.2 确定性判断和智能判断，根本不是一种东西

我把 Agent 循环里的判断分成了两类：一类是"确定性问题"，另一类是"开放问题"。

确定性问题比如：文件扩展名是不是.pdf？上一步返回的 JSON 里status字段是不是success？当前重试次数是不是已经超过了三次？这些问题的答案不依赖任何语义理解，规则就能解决。

开放问题比如：用户说"帮我把昨天开会提到的那个方案整理一下"，你需要理解"昨天开会提到的"到底是哪个方案、"整理一下"具体指什么动作，这才需要真正的语义理解。

问题在于，很多人在设计 Agent 的时候偷懒了，不管什么问题都一股脑丢给 LLM。明明一个if语句能解决的判断，非要让模型思考半天。结果就是前两类成本全部上升，还换来了第三类不确定性。

1.3 80/20 法则：循环里大多数判断都是流程检查

我自己统计过几个实际跑过的 Agent 项目，结论惊人地稳定：循环里有超过八成判断是纯流程性的——状态检查、格式校验、字段匹配、权限判断、路由分流。真正需要模型动脑子的，可能也就剩下不到两成。

这意味着，如果你先把这 80% 的判断用确定性的规则、状态机和轻量决策模型消化掉，Agent 的 Token 成本和延迟会断崖式下降，稳定性反而大幅上升。Jev 决策模型解决的，正是这个问题。

2. Jev 决策模型的核心：把判断拆成三层，而不是全扔给模型

Jev 决策模型的思路其实特别朴素：它不试图替代 LLM，而是给 Agent 循环里的判断建立了一个分层结构。让确定性的判断走规则层，让开放性的理解走模型层，两者通过一个清晰接口衔接。

2.1 导航、路况和司机：一个能说明白 Jev 的类比

我在讲 Agent 架构的时候经常用开车类比。LLM 是那个经验丰富的老司机，它擅长理解复杂路况、处理突发情况、规划路线。但你要让老司机每到一个路口都思考"我该不该等红灯""我该不该变道"，那他也开不了车了。

正常开车靠的是什么？靠的是交规和导航——红灯停、绿灯行、走哪条车道，这些都是确定的规则。只需要一眼就能做出的判断，根本不需要经过高层认知。

Jev 在 Agent 里的角色就是这个"导航加交规"，专门负责那些看一眼就能回答的问题。司机只需要在导航判断不了的时候才介入："前方路况复杂，需要判断这个路口能不能掉头。"

这是一个非常关键的分层思想：判断比执行更接近确定性的一端，就会越靠向规则；判断越需要语义理解，就越需要模型。Jev 的价值在于，它把"判断"这件事的绝大多数据点为已知，让 LLM 只处理真正未知的部分。

2.2 key / query / value 三段式判断：我是谁、我在找什么、我能提供什么

Jev 模型在实现层面最有辨识度的一点，就是它的三段式判断结构——key、query、value。这套结构在网络上的讨论也很多，大意是：每个决策点先问三个问题。

• key（我是谁）：当前节点是什么状态？我在流程中的哪个位置？
• query（我在找什么）：当前这个判断的输入是什么？我需要匹配什么条件？
• value（我能提供什么）：当前这个节点能接受的输出是什么？下一步的分支有哪些？

用大白话翻译：一个判断要成立，必须同时搞清楚"谁在做判断、判断的原料是什么、判断完能产出什么"。这三个问题都答得上来了，这个判断就是可执行的、可校验的、可预测的。如果三个问题里有一个答不上来，那才轮到 LLM 上场。

在工程实现上，一个 Jev 节点通常用一个简单的配置结构来描述。我见过比较可用的形式是这样的：

decision_node: key: "completed_check" query: "{result.status}" rules: - "status == success: proceed_next" - "status == failed && retry_count < 3: retry" - "status == failed && retry_count >= 3: terminate_with_error" fallback: "ask_llm_interpret_error"

这个结构的含义很清楚：先用 key 定位当前环节，用 query 取出判断需要的字段，然后走规则表。只有规则表匹配不到逻辑时，才走fallback交给 LLM。

2.3 可预测性优先：循环里的判断必须稳定，哪怕简单粗暴

设计 Jev 时最重要的原则，我把排第一位的是"可预测性"。

很多工程师有一种误区：觉得规则太少会覆盖不住复杂情况，于是倾向于把判断交给模型。但实际运行 Agent 循环时，最怕的不是规则太简单，而是判断结果不稳定。你宁可让 Agent 在某个边界情况下走一条"不那么聪明"的路径，也不能让它今天走 A、明天走 B。

Jev 模型的判断逻辑必须是确定性的、自动生成日志的、可测试的。这一点和写单元测试很相似——循环的每一个状态迁移，都能用一组输入输出 pair 验证。这在纯 LLM 驱动的 Agent 里几乎是做不到的，但做了分层之后完全可以。

Jev 这类决策框架在市面上已经有现成的 SDK 和轻量实现，官网和密钥机制对应的是其控制台接入方式，在 Codex 这类 Agent 环境里也有对应的命令行工具。花点时间把 Jev 层的判断逻辑写好、把规则表打磨干净，收益会在跑大规模循环时充分体现出来。

3. 50 行以内的边界清单：这几类判断必须留在 Jev 层

哪些判断必须留在 Jev 层？我直接给你一份我自己整理的清单。这份清单的范围很小，逻辑也很清楚——凡是可以用确定性规则回答的问题，一律不出发模型调用。

3.1 结果完整性校验：模型输出不可信，必须用代码兜底

这是我在 Agent 项目里踩过最多的坑。LLM 输出 JSON 时经常莫名其妙漏字段、嵌套错结构、出现多了个逗号的非法格式。你如果让 Agent 循环靠模型自己判断"上一步结果是否合法"，它往往会说"看起来没问题"，然后进入一个根本跑不动的分支。

Jev 层的做法是强制做结构化校验。拿我常用的 Python 项目来说，直接用 Pydantic 或者 jsonschema 做 schema 校验，不合法就打回重试，重试超过 N 次就终止并记录原因。整个过程一次 LLM 调用都不用花。

from pydantic import BaseModel, ValidationError class ToolResult(BaseModel): status: str file_path: str | None = None metadata: dict = {} def validate_result(raw: dict) -> bool: try: ToolResult(**raw) return True except ValidationError as e: logger.error("schema_validation_failed: %s", e) return False

这段代码的意义不光是省 Token，更关键的是给了循环一个绝对可靠的"闸门"。模型说得天花乱坠也没用，校验不通过就走重试路径。任何 Agent 循环都需要这样的闸门。

3.2 流程状态机迁移：重试、超时和终止判断绝不交给语义

Agent 循环的本质是一个状态机：初始化、执行中、等待输入、重试、成功、失败终止。状态迁移是纯确定性的，跟语义理解一毛钱关系都没有。

我见过一个很离谱的案例：有团队让 LLM 来决定"当前任务是否需要重试"，结果模型把"任务失败"描述成"需要重新思考策略"，然后在循环里无限自我反思，永远不重试也不终止。这就是典型的把状态机判断交给语义理解后的灾难。

在 Jev 层你必须定义清楚状态迁移表。什么时候重试、重试几次、超过多少秒算超时、超时后走哪个分支，全部用规则固定死。LLM 永远不应该关心"我现在该不该重试"这样的问题，它只应该在 Jev 的规则表匹配失败后，被调用来解释失败原因、给出修正方案。

3.3 权限和安全检查：工具白名单只能用硬编码规则

如果你的 Agent 要调用外部工具或访问文件系统，权限检查这一层绝不能用 LLM 来下判断。模型可能被提示词注入诱导，也可能意图判断失误，把敏感路径放行。

Jev 层要做的权限检查非常简单粗暴：工具白名单、路径前缀检查、外发域名校验，全部硬编码。

allowed_tools = ["list_files", "read_file", "rename_file", "create_folder"] allowed_base_dir = "/data/user_files"

凡是超出白名单和目录范围的调用，在工具执行之前就拦掉。这一步的判断必须做到 100% 确定，不需要任何"智能"参与。安全边界的本质是确定性，不是概率。

3.4 路由分流：关键词与规则能把 95% 的意图分对，剩下的才交给模型

Agent 对话场景里的路由分流，是另一个经常被误解的地方。很多人以为意图识别一定要用 LLM，其实在大多数垂直场景里，关键词和正则就能解决问题。

用户说"我想查一下昨天的报表"，你不需要理解"想"和"一下"这些词，你只需要匹配到关键词"报表"或"下载"。用户说"你好""谢谢"或者只是打招呼，也不需要语义分析，几个常见词就能挡住。

我在实际项目里把路由分为两层：Jev 层先按规则表匹配高频意图，匹配不到再升级给 LLM。这样做的结果很有意思——80% 的流量在 Jev 层就被消化掉了，LLM 的调用量骤减。模型只处理那些真正的长尾输入，比如"帮我找一下上个月供应商发来的那个带附件的邮件"这种需要综合理解的复合指令。

3.5 循环终止条件：计数器、空集合检查，这些本该是几行代码

很多 Agent 循环跑飞，问题都出在终止条件上。明明已经处理完所有文件了，模型还在那煞有介事地说"我继续再检查一下其他可能性"；明明已经重试了二十次，模型还在说"换个办法再试一次"。

终止条件天生就属于确定性判断。候补列表为空了吗？计数器到达上限了吗？已完成数量达到目标了吗？这几行代码的事，交给 LLM 就是在烧钱制造不确定性。

def should_terminate(pending: list, done_count: int, target_count: int) -> bool: if not pending and done_count >= target_count: return True return False

4. 用 Jev 重写循环的一次完整改造：文件整理 Agent 的 Token 账本

理论讲了不少，我拿一个实际的"文件整理 Agent"来演示一下整个改造过程。这个场景小而完整，最适合说清楚 Jev 层和 LLM 层的职责边界怎么切。

4.1 改造前的噩梦：每个文件五次模型调用

假设你要做一个自动整理下载文件夹的 Agent，把散乱的文件按类别放进对应目录。文件类型包括 PDF、Word、图片、压缩包、代码文件，以及一堆不知道是什么的东西。

改造前的"典型实现"长这样：

1. 读文件扩展名，调用 LLM 判断"这是什么类型的文件"
2. 扫描文件名，调用 LLM 判断"这个文件名是否包含有意义的关键词"
3. 决定目标目录之前，调用 LLM 判断"这个文件应该放到哪个分类"
4. 检查目标目录是否已有同名文件，调用 LLM 判断"这两个文件是否重复"
5. 执行移动之后，调用 LLM 判断"移动操作是否成功"

五个步骤，每一个都在问模型。最离谱的是第三步，判断一个.pdf文件该进"文档"目录还是"合同"目录——这种判断明明可以在 Jev 层用文件名关键词规则先过一遍，比如文件名包含"合同""协议"就进合同目录，否则默认进文档目录。

这个 Agent 我实际跑过，结果非常惨：处理一个文件夹大约三百个文件，策略跑了一个多小时，Token 消耗大得惊人。而且因为每次判断都有随机性，运行两次结果对不上，有的文件被重复处理，有的被跳过。

4.2 改造后的核心动作：先规则、后模型、模型兜底

改造的逻辑很简单：先让规则层处理能确定的部分，处理不了的再升级给模型。我把整个流程重构了一遍。

新增一个 Jev 层的"判断漏斗"：

1. 扩展名映射表：.pdf/.docx→ 文档；.jpg/.png→ 图片；.zip→ 压缩包；.py/.js→ 代码文件。这个映射表是确定的，不需要模型。
2. 文件名关键词规则：文件名包含"合同""协议" → 合同目录；包含"简历""个人简介" → 简历目录；包含"会议""纪要" → 会议记录目录。
3. 对于扩展名和关键词规则都无法分类的文件，比如一串乱码命名的文件，才启动 LLM 理解一次，让它根据文件元数据或文件头信息给出分类建议。
4. LLM 给出的分类建议不是直接采纳，而是先过一层 Jev 的校验——分类是否在目录白名单里、路径是否合法，合法才执行移动。

改造后，三百个文件里大约有七十个通过扩展名直接分掉了，两百个通过规则关键词分掉了，真正需要 LLM 介入的可能就二十个左右。而且这二十次的 LLM 建议，还被 Jev 强制成了统一格式输出，不会出现"我觉得可以放这个目录"这种没法程序处理的废话。

4.3 账本对比：Token 消耗少了一个数量级

我做了个简单统计。改造前，每个文件的平均 LLM 调用次数是四点七次；改造后，降到了零点三次以内。

这个案例的核心结论不是"模型没用"，而是"模型被用错了地方"。判断该放哪个目录，大部分时候是规则问题，不是理解问题。你把规则该做的事做掉，模型就能把精力放在它真正擅长的那些"语义模糊的文件"上。

4.4 一个关键设计：无法判断的文件，模型才动手，但仍然要过闸

很多人会问：那 LLM 给出分类建议后，万一建议错了怎么办？

我的做法是，LLM 的建议也要经过 Jev 层的"可信度校验"。比如 LLM 返回的目录必须存在于白名单列表里，如果它给出了一个不存在的目录名，就直接重试一次；重试结果仍然异常，就进入"人工处理区"。这一步很重要，它保证了 LLM 的输出不会击穿系统的确定性边界。

5. LLM 那 20% 用在哪里：让模型只做它擅长的开放判断

讲清楚边界之后，我们再回头看 LLM 应该留在循环里的那些判断。这些判断的共同点是模糊、含混、需要语义理解，规则无法覆盖。

5.1 开放判断的典型场景：需要"理解"而非"匹配"

举几个我会真正触发 LLM 的场景：

• 用户给了一句指令："把这两天跟项目立项相关的邮件和附件整理到一个文件夹里。"这里"这两天"是一个相对时间，"相关"是模糊关联，"整理"这个动作的边界也靠语义理解。
• 系统遇到一个奇怪的错误消息，比如第三方接口返回了一个从未见过的错误码，规则表里没有。这时候才需要 LLM 帮忙解读错误和给出修复建议。
• 对一段非结构化文本（会议纪要、客户留言）做语义摘要，判断这段内容属于哪个业务主题。

这些判断的共同特征是"开放"。你不能提前枚举所有可能的结果，必须让模型在开放空间里给一个回答。这就是 LLM 该待的位置。

5.2 模型升级接口的工程化设计：强制执行合同和兜底

为了让 LLM 的"开放判断"不破坏循环的稳定性，我给这类调用建立了一套严格的"模型调用契约"。

第一，输出格式必须是结构化 JSON。例如：

{ "decision": "needs_llm", "reason": "rule_engine_no_match", "confidence": 0.85 }

第二，必须设置置信度阈值。如果模型的confidence低于某个阈值（我常用 0.7），就当作判断失败，走人工回退。第三，超时必须处理。模型可能因为网络或者其他原因迟迟不返回，Jev 层要给模型调用设置明确的超时时间，超时后按失败处理，绝不能无限等待。

这套接口相当于在"开放判断"和"确定性流程"之间修了一条有护栏的桥。模型可以自由发挥，但发挥的结果必须落在程序能处理的轨道里。

5.3 知识回流：把模型的开放判断转成 Jev 规则

模型判断多了以后，还有一个很妙的操作：把它判断过的结果沉淀回规则表。继续拿归档任务举例，如果模型连续三次遇到 "project_brief_20241022.pdf" 这类文件都判断为"项目文档"，你完全可以把"文件名包含 brief 或 project → 项目文档"写进 Jev 规则表。

这就是一个从"开放判断"到"确定性规则"的收敛过程。跑得越久，模型需要介入的地方就越少，系统整体越来越"自动化"。设计 Agent 时应把这一层回流机制默认做好——规则表允许热更新，模型判断的日志可以批量回放，定期人工审核后合并进白名单。这套能力决定了 Agent 长期运行的价值上限。

6. 踩坑实录：判断全交给 LLM 后，我遇到的四种崩溃症状

最后这部分是我最想跟正在踩坑的人分享的。判断全交给 LLM 会出的问题不是理论风险，而是我实际遇到过的四种崩溃症状。你如果自己的 Agent 跑飞过，大概率能在下面找到对应症结。

6.1 无限重试循环：模型把"失败"当成"需要继续努力"

症状：Agent 卡在一个失败的结果上，反复自我反思、反复重试，永远不向用户上报错误，直到 API 配额耗尽。

根因：循环的终止/重试判断交给了模型。模型在语义上很容易把"失败了"解释成"也许换个方式就能成功"，于是无限循环。

解法：把"重试上限"和"终止条件"搬回 Jev 层。失败次数到达上限就是失败，必须走失败分支。模型可以在失败分支里解释原因，但无权决定"要不要继续试"。

6.2 结果漂移：同一个输入，两次结果不一样

症状：批量处理任务，中间断了续跑，结果跟第一次完全对不上。有些文件被重复处理，有些被跳过，日志里看不出规律。

根因：每次调用 LLM 都有随机性。哪怕温度参数设成 0，不同批次、不同上下文，输出仍然会有波动。让 LLM 在循环里做布尔判断，等于把整个流程建立在了沙地上。

解法：判断动作尽量收敛到 Jev 层。如果某种判断规则能写出来，就不要用模型。对于模型必须参与的地方，把结果缓存住——同一个输入不重复请求，保证一致性。

6.3 Token 预算爆炸：循环跑完一看账单

症状：单个任务没跑完，Token 已经远超预估，API 报错或者账单飙高。

根因：循环里的每个"小判断"都调了一次模型。单个判断看起来只花几十个 Token，但一次循环积累起来就是几百上千 Token，批量任务再乘以文件数，数字就非常惊人了。

解法：拆分 Token 预算。我习惯按"读取/判断/写入"三类统计循环成本，重点盯"判断"这一项的占比。健康的设计里，判断类调用的 Token 占比应该远低于读取和写入。如果判断太高，大概率是判断逻辑没分到 Jev 层。

6.4 工具误调用：模型自作主张调了不该调的工具

症状：日志里出现"Agent execution terminated due to error"或者工具调用参数不符合 schema，部分框架会直接报"provider rejected the request schema or tool payload"。

根因：我把工具选择的判断也交给 LLM 了。模型在理解"当前该调哪个工具"这件事上不可靠，尤其是上下文复杂时，它会挑一个看起来合理的，但不一定是正确的工具。

解法：在 Jev 层建立工具调用的前置闸门。白色单写死哪些工具在哪些状态可调用，参数先做 schema 校验，非法就直接拦截使用规则层保底。实在需要模型决策的，让模型只返回工具名和参数，由 Jev 层执行器校验后再放行，通过这种方式把错误拦截在工具前一步。

7. 最后一点：这不是把模型赶走，而是给它降噪

我见过有人误解 Jev 这套思路，觉得"既然 80% 的判断不该交给模型，那是不是模型可有可无了"。恰恰相反。把规则判断剥离出来，模型才真正被放在了该放的开放判断上，系统整体稳定性和模型的有效利用率都大幅提升。

我在实际项目里还有一个经验：每次模型介入时，日志里记录一下"这次为什么升级给模型"。跑两周之后回看这些日志，你会看到一个规律——大量"升级"其实是可以压回规则层的。随着规则表越来越完善，"升级率"会从最初的 80% 逐步降到 20% 以下。

如果你现在正准备搭一个 Agent 循环，我的建议是别急着写提示词，先花半天把循环里所有判断点列出来，逐个标上"确定性"和"开放性"。然后为确定性判断搭一套类似 Jev 的规则层，想好开放判断的升级接口、置信度阈值和兜底路径。跑一次你就知道，这套分层省下来的不止是 Token，更是让你睡个安稳觉的确定性。