1. 为什么 Agent 循环里的判断不该全交给 LLM1.1 一个被忽视的成本黑洞做过 Agent 项目的人大概都有这种体验一个任务跑下来LLM 调用次数动辄几十上百次账单蹭蹭往上涨延迟还高得让人抓狂。更让人头疼的是明明有些判断简单得不能再简单——比如这个工具调用返回的是不是空结果当前步骤是不是已经完成了——却偏偏要绕一圈去问 LLM。我最早做 Agent 的时候也是这样什么都往 LLM 里塞觉得大模型无所不能。结果一个中等复杂度的任务光判断类调用就占了总调用量的七成以上真正干活的调用反而没几次。后来复盘才发现这里面绝大部分判断根本不需要 LLM 参与用规则、状态机或者轻量分类器就能搞定而且更快、更稳、更便宜。这就是 Jev 决策模型要解决的核心问题在 Agent 循环里把判断分成该交给 LLM 的和不该交给 LLM 的后者用确定性逻辑处理前者才动用大模型。听起来简单但真正落地的时候怎么分、分完之后怎么编排、边界情况怎么处理全是坑。1.2 Jev 决策模型到底是个什么东西先把概念说清楚。Jev 决策模型不是某个具体的开源框架也不是一个可以直接 pip install 的库它更像是一套决策分层的方法论配合一套可落地的编排模式。核心思想可以用一句话概括在 Agent 的每一步循环中先判断这一步的决策类型再决定由谁来执行这个决策。决策类型大致分三类确定性决策有明确规则、可以用布尔逻辑或状态机表达的判断。比如工具返回码是不是 200重试次数是不是超过上限当前 token 预算还剩多少。半确定性决策有一定模糊性但可以用轻量模型或启发式规则处理的判断。比如这个搜索结果和问题相关吗用户这句话是追问还是新问题。开放性决策需要理解语义、推理、规划的判断。比如下一步该调用哪个工具这个任务应该拆成几个子任务用户真正想要的是什么。Jev 的核心主张是第一类和第二类判断80% 的情况下不该交给 LLM。只有第三类才值得动用大模型。1.3 为什么是 80% 这个数字这个比例不是拍脑袋来的。我统计过自己手上几个 Agent 项目的调用日志把每一步的判断按类型打标结果大致是这样的判断类型占比是否必须用 LLM工具返回状态检查约 25%否循环终止条件判断约 15%否重试与降级决策约 12%否参数格式校验约 10%否上下文相关性粗筛约 18%可用轻量模型任务规划与工具选择约 15%是语义理解与意图识别约 5%是加起来前五类占了大约 80%这些判断用确定性逻辑或轻量模型就能处理。真正需要 LLM 的只有最后两类占 20% 左右。当然不同项目比例会有浮动但量级上差不多。这个数字背后的逻辑是Agent 循环里大量的判断本质上是控制流问题不是语义问题。控制流问题用代码解决语义问题才用模型解决。把控制流问题交给 LLM就像用计算器去开灯——不是不行是浪费。2. Jev 决策模型的核心原理拆解2.1 决策分层把判断拆成三层Jev 模型的第一层设计是决策分层。在 Agent 的每一步循环开始前先对当前这一步要做的判断进行分类然后路由到对应的执行器。具体来说分三层第一层规则层Rule Layer这一层处理所有可以用确定性规则表达的判断。实现方式就是普通的 if-else、状态机、或者简单的查表。特点是零延迟、零成本、100% 可预测。比如工具调用返回后先检查返回状态def check_tool_result(result): if result is None: return Decision.RETRY if result.get(status) error: if result.get(retryable): return Decision.RETRY return Decision.ABORT if not result.get(data): return Decision.SKIP return Decision.CONTINUE这段代码做的事情如果交给 LLM至少要几百毫秒和几百个 token。而用规则层微秒级完成还不会出错。第二层轻量层Light Layer这一层处理半确定性的判断用轻量模型、embedding 相似度、或者启发式规则。特点是成本低、延迟可控、准确率够用。比如判断新返回的搜索结果和当前问题相关吗可以用 embedding 算余弦相似度设个阈值就行。不需要动用 LLM 做语义推理。第三层LLM 层LLM Layer只有前两层处理不了的开放性判断才交给 LLM。这一层是成本大头所以要尽量少调用、调用时尽量给足上下文。三层之间的关系不是串行的而是路由关系每个判断先尝试规则层规则层处理不了降级到轻量层轻量层处理不了才升到 LLM 层。2.2 状态机驱动让循环有记忆Jev 模型的第二个核心设计是状态机驱动。Agent 循环不是简单的 while True而是有一个显式的状态机在管理。为什么需要状态机因为很多判断依赖于当前处于哪个阶段。比如在规划阶段判断重点是任务拆解是否完整在执行阶段判断重点是工具调用是否成功在验证阶段判断重点是结果是否满足要求如果不用状态机这些判断逻辑会混在一起LLM 每次都要重新理解上下文既浪费又容易出错。状态机的实现可以很简单class AgentState: PLANNING planning EXECUTING executing VERIFYING verifying DONE done FAILED failed def route_decision(state, context): if state AgentState.PLANNING: return planning_decisions(context) elif state AgentState.EXECUTING: return executing_decisions(context) elif state AgentState.VERIFYING: return verifying_decisions(context)每个状态下的判断逻辑是独立的规则层可以针对性地写LLM 调用也可以针对性地给 prompt。这样既清晰又高效。2.3 决策缓存同样的判断不重复做Jev 模型的第三个设计是决策缓存。Agent 循环里有很多重复判断比如当前 token 预算够不够这个工具是否可用这些判断在短时间内结果是一样的没必要每次都重新算。缓存策略分两种短期缓存在单次任务内缓存任务结束就清空。适合当前步骤是否完成这类判断。长期缓存跨任务缓存适合工具能力描述模型参数配置这类稳定信息。缓存 key 的设计很关键。我一般用(决策类型, 关键上下文哈希)作为 key避免缓存污染。2.4 与 RLHF、RLCD 的关系热词里提到了 RLHF 和 RLCD这两个和 Jev 模型的关系值得说一下。RLHF基于人类反馈的强化学习解决的是怎么让 LLM 的输出更符合人类偏好它优化的是 LLM 层内部的决策质量。而 Jev 模型解决的是哪些决策该进 LLM 层它优化的是决策的路由。两者是互补的Jev 把该给 LLM 的判断筛出来RLHF 让 LLM 在这些判断上做得更好。RLCD基于对比的强化学习类似也是优化 LLM 层内部不改变路由逻辑。所以如果你在做 Agent 项目Jev 模型和 RLHF 不冲突可以同时用。先用 Jev 把 80% 的判断拦在 LLM 外面剩下的 20% 再用 RLHF 调优过的模型处理整体效果和成本都会好很多。3. 实操怎么在 Agent 项目里落地 Jev 模型3.1 第一步给现有 Agent 做决策审计落地 Jev 模型的第一步不是写代码是审计。把你现有 Agent 的每一步判断列出来打上标签。具体做法在 Agent 循环的每个决策点加日志记录这一步做了什么判断判断结果是什么耗时多少消耗多少 token。跑一批典型任务收集日志。人工或半自动地给每个判断分类确定性、半确定性、开放性。统计各类占比和成本占比。我自己的经验是第一次做审计的时候会惊讶地发现很多你以为必须用 LLM的判断其实用规则就能搞定。比如用户的问题是不是和上一个问题相关用 embedding 相似度加个阈值准确率能到 85% 以上剩下的 15% 再降级到 LLM 处理就行。审计表格大概长这样决策点当前实现类型调用次数平均耗时平均 token工具返回检查LLM确定性120800ms350循环终止判断LLM确定性45750ms280下一步工具选择LLM开放性301200ms800结果相关性判断LLM半确定性60900ms400看到这张表优化方向就一目了然了。3.2 第二步重构决策路由审计完之后开始重构。核心是引入一个决策路由器所有判断先经过路由器再决定由谁执行。路由器的伪代码class DecisionRouter: def __init__(self): self.rule_handlers {} self.light_handlers {} self.llm_handler None def register_rule(self, decision_type, handler): self.rule_handlers[decision_type] handler def register_light(self, decision_type, handler): self.light_handlers[decision_type] handler def route(self, decision_type, context): # 第一层规则 if decision_type in self.rule_handlers: result self.rule_handlers[decision_type](context) if result is not None: return result # 第二层轻量 if decision_type in self.light_handlers: result self.light_handlers[decision_type](context) if result is not None: return result # 第三层LLM return self.llm_handler(decision_type, context)关键点是规则层和轻量层返回 None 表示处理不了才降级到下一层。这样每层只需要处理自己擅长的部分。3.3 第三步写规则层的判断逻辑规则层是 Jev 模型的重头戏因为 80% 的判断都在这里。我整理了几类常见的规则判断可以直接抄。工具返回状态检查def check_tool_status(context): result context.get(tool_result) if result is None: return Decision.RETRY if isinstance(result, dict): if result.get(error): if result.get(retryable, False): return Decision.RETRY return Decision.ABORT if not result.get(data): return Decision.SKIP return Decision.CONTINUE循环终止条件def check_termination(context): if context[step_count] context[max_steps]: return Decision.TERMINATE if context[token_used] context[token_budget]: return Decision.TERMINATE if context[consecutive_failures] 3: return Decision.TERMINATE if context.get(task_completed): return Decision.TERMINATE return None # 继续重试与降级def check_retry(context): retry_count context.get(retry_count, 0) if retry_count context.get(max_retries, 3): return Decision.FALLBACK if context.get(last_error_type) rate_limit: return Decision.BACKOFF return Decision.RETRY这些逻辑写起来不复杂但能拦下大量 LLM 调用。3.4 第四步轻量层的实现选型轻量层的实现方式有几种选哪种取决于你的判断类型判断类型推荐实现理由文本相关性Embedding 相似度快、便宜、够用意图粗分类小模型如 0.5B-1B比 embedding 准比 LLM 快情感倾向规则 词典简单场景够用格式校验正则 Schema确定性最强优先级排序加权打分可解释、可调参我一般优先用 embedding因为大部分场景够用而且部署简单。只有 embedding 搞不定的才上小模型。3.5 第五步LLM 层的 prompt 优化经过前三层过滤到 LLM 层的判断已经不多了。这时候可以给 LLM 更充足的上下文、更详细的 prompt让它做得更好。一个技巧是在 prompt 里明确告诉 LLM 这是哪一类判断。比如你正在处理一个【任务规划】类判断。 当前状态规划阶段 已有信息... 请判断下一步应该调用哪个工具或者是否需要拆解任务。这样 LLM 不需要自己推断我在做什么直接进入判断准确率和速度都会提升。4. 常见问题与排查技巧4.1 规则层误判怎么办规则层最大的风险是误判。比如工具返回了一个空列表规则层判断为 SKIP但实际上空列表是有效结果应该 CONTINUE。排查思路加日志每次规则层判断都记录输入和输出方便回溯。设阈值对于边界情况规则层返回 None降级到轻量层或 LLM 层。定期审计每周抽一批规则层判断人工检查准确率。我的经验是规则层的准确率要做到 95% 以上才值得保留低于这个值就说明规则写得太粗需要细化或者降级处理。4.2 轻量层和 LLM 层结果不一致有时候轻量层判断相关LLM 层判断不相关。这种不一致怎么处理我的做法是以 LLM 层为准但记录不一致的 case。定期分析这些 case如果发现轻量层经常误判某一类就调整轻量层的阈值或规则。4.3 状态机状态爆炸状态机用久了状态会越来越多最后变成一团乱麻。避免方法状态数量控制在 5-7 个超过就考虑合并或分层。状态转换要有明确条件不能有模糊转换。定期重构每季度 review 一次状态机合并冗余状态。4.4 缓存污染决策缓存用久了会出现缓存了错误结果的情况。避免方法缓存 key 要包含足够上下文不能只用决策类型做 key。设置 TTL短期缓存设 5-10 分钟长期缓存设 1 天。提供手动清除接口出问题时能快速清缓存。4.5 常见问题速查表问题可能原因解决方法规则层准确率低规则太粗细化规则或降级LLM 调用还是很多路由逻辑有问题检查是否有判断漏路由延迟没降下来轻量层太慢换更轻的实现成本没降下来LLM 层 prompt 太长精简 prompt状态机混乱状态太多合并状态或分层缓存命中率低key 设计不合理调整 key 粒度5. 一个完整的落地案例5.1 场景描述假设你在做一个资料检索 Agent用户输入一个问题Agent 自动搜索、筛选、总结。这个 Agent 的循环里有很多判断正好适合用 Jev 模型优化。5.2 优化前的调用分布优化前所有判断都走 LLM每次搜索后判断结果是否相关LLM 调用判断是否需要继续搜索LLM 调用判断信息是否足够总结LLM 调用判断总结是否完整LLM 调用一个任务平均 8 次搜索每次 4 个判断共 32 次 LLM 调用。加上搜索本身的调用总共 40 次左右。5.3 优化后的调用分布用 Jev 模型重构后结果是否相关embedding 相似度轻量层是否需要继续搜索规则层搜索次数 信息覆盖率信息是否足够总结规则层关键信息命中率总结是否完整LLM 调用但 prompt 更聚焦LLM 调用从 32 次降到 8 次左右总调用从 40 次降到 16 次。延迟从平均 45 秒降到 18 秒成本降了六成。5.4 关键代码片段规则层判断是否需要继续搜索def should_continue_search(context): search_count context[search_count] coverage context[info_coverage] # 0-1 max_searches context.get(max_searches, 10) if search_count max_searches: return Decision.STOP if coverage 0.85: return Decision.STOP if context[last_search_new_info_ratio] 0.1: return Decision.STOP return Decision.CONTINUE轻量层判断结果相关性def check_relevance(context): query_emb context[query_embedding] results context[search_results] threshold 0.65 relevant [] for r in results: sim cosine_similarity(query_emb, r[embedding]) if sim threshold: relevant.append(r) if len(relevant) 0: return Decision.NO_RELEVANT return Decision.HAS_RELEVANT这两个函数加起来不到 30 行替代了原来十几次 LLM 调用。6. 一些踩过的坑和心得6.1 不要一开始就追求完美分层我最早做 Jev 落地的时候想把每个判断都精确分类结果花了两周做审计和设计代码一行没写。后来发现先粗分再迭代才是正确姿势。先按确定性/非确定性二分跑起来看效果再逐步细化。6.2 规则层要留逃生通道规则层再完善也会有覆盖不到的情况。所以每个规则判断都要有返回 None 降级的选项不能硬编码所有情况。我见过有人把规则层写成密不透风的 if-else结果遇到新情况直接崩还不如全交给 LLM。6.3 监控比优化更重要Jev 模型落地后一定要加监控。监控指标包括各层判断的调用次数和占比各层的准确率需要人工抽样各层的平均耗时降级率规则层降级到轻量层、轻量层降级到 LLM 层的比例没有监控你根本不知道优化有没有效果也不知道哪里出了问题。6.4 和团队对齐什么算确定性确定性这个词在不同人眼里含义不一样。有人觉得90% 情况能用规则处理就算确定性有人觉得要 99% 才算。落地前一定要和团队对齐标准否则审计结果没法用。我的标准是规则层准确率 95% 以上轻量层 85% 以上低于这个值就降级。这个标准不一定适合所有团队但至少是个起点。6.5 别忘了 prompt 也是成本优化 LLM 调用次数的时候别忘了 prompt 长度也是成本。有时候减少调用次数但每次 prompt 变长总成本反而上升。所以优化的时候要同时看调用次数和 token 总量。7. 后续可以怎么扩展Jev 模型本身是个方法论落地方式可以有很多变体。我目前在做的一个扩展是动态分层根据任务类型和历史表现动态调整每层的阈值和路由策略。比如简单任务多用规则层复杂任务多用 LLM 层。另一个方向是决策学习记录每次判断的结果和后续影响用这些数据反过来优化路由策略。哪些判断规则层处理得好哪些处理得差用数据说话而不是靠拍脑袋。还有一个方向是跨 Agent 共享决策缓存多个 Agent 共享一套决策缓存减少重复判断。这个在 Agent 集群场景下特别有用。这些扩展都还在实验阶段等有稳定结果了再单独写一篇分享。