1. 从“什么都问大模型”说起Agent 设计的核心误区做 Agent 开发的人几乎都经历过这样一个阶段手里有了一个能力还不错的大模型就恨不得把所有事情都塞给它。用户说一句话先丢给大模型解析意图解析完再丢给大模型决定调用哪个工具工具返回结果再丢给大模型总结总结完再丢给大模型判断要不要继续循环。整个链路里大模型像个被使唤的万能工什么活都接。我最早做 Agent 项目的时候就是这么干的。结果呢响应慢、成本高、行为不稳定同一个输入跑三次能给你三种不同的执行路径。最要命的是有些明明用几行规则代码就能搞定的判断非要绕一大圈让大模型去“思考”最后还思考错了。Jev 这个项目给出的答案核心就一句话该用 System One Model 的地方别用 LLM。这个思路听起来简单但真正理解并落地的人不多。它背后涉及的是 Agent 架构设计的一个根本问题——认知分工。1.1 什么是 System One Model为什么它和 LLM 不是一回事System One 这个概念借用了认知心理学里的双系统理论。人的思维分两套一套是快速的、直觉的、几乎不消耗能量的System One比如你骑车的时候保持平衡、看到红灯踩刹车另一套是慢速的、理性的、消耗大量能量的System Two比如解一道数学题、做一份复杂的规划。大模型LLM本质上更像 System Two。它每次推理都要消耗大量算力适合处理需要理解、推理、生成的复杂任务。但 Agent 在执行过程中有大量操作其实是 System One 级别的——判断一个字符串是否匹配某个模式、决定下一步走哪个分支、检查一个条件是否满足、从固定格式里提取字段。这些事情用 LLM 来做就像用计算器解 11 还要按半天按键。Jev 提出的 System One Model指的是那些轻量的、确定性的、可预测的模型或规则系统。它可以是一个小型的分类器、一套规则引擎、一个有限状态机甚至就是几行 if-else。它的特点是快、稳、便宜而且行为完全可预测。注意System One Model 不等于“简单的模型”。它的核心特征是确定性——同样的输入永远给同样的输出。这一点在 Agent 执行链路里极其重要因为你需要可调试、可复现。1.2 全交给大模型会踩哪些坑我把当年踩过的坑列一下你看看是不是也遇到过延迟爆炸一个用户请求触发 5 次 LLM 调用每次 2 秒用户等 10 秒才看到结果。如果其中 3 次调用换成规则判断延迟直接降到 2 秒以内。成本失控每次调用都烧 token一个日活几千的 Agent 应用光 LLM 调用费用就能吃掉大部分利润。行为不可复现同一个输入今天走路径 A明天走路径 B。出了问题你根本不知道是哪一步的推理跑偏了。错误累积每一步 LLM 调用都有出错概率5 步串起来整体成功率可能从 95% 掉到 77%。过度设计明明一个正则能提取的字段非要让大模型输出 JSON然后还要处理它偶尔不按格式输出的问题。Jev 的思路就是把这些 System One 级别的任务从 LLM 手里拿回来交给专门的轻量模块处理。LLM 只负责它真正擅长的事情——理解模糊意图、生成自然语言、处理需要世界知识的推理。1.3 这个思路适合谁来参考如果你正在做 Agent 开发不管是用现成框架还是自己搭只要你的 Agent 执行链路超过两步这篇文章都值得看。特别是以下几类人正在被 Agent 的延迟和成本问题困扰的开发者觉得 Agent 行为“玄学”、难以调试的工程师想从零设计一个生产级 Agent 架构的技术负责人对大模型应用架构感兴趣、想了解前沿实践的学习者不需要你精通 LLM 底层原理但需要对 Agent 的基本执行流程有概念。我会尽量用大白话把每个设计决策讲清楚。2. Jev 的架构拆解LLM 和 System One Model 怎么分工Jev 这个项目最值得琢磨的地方不是它用了什么高深技术而是它在架构层面做了一个清晰的职责划分。这个划分不是拍脑袋定的而是基于对任务类型的分析。2.1 任务分类哪些该给 LLM哪些不该给我把 Agent 执行过程中的常见任务拆开来看大致可以分成这么几类任务类型典型例子适合的处理方式理由意图理解用户说“帮我看看明天天气”LLM需要处理自然语言的模糊性工具选择从 20 个工具里选一个LLM 规则过滤先用规则缩小范围再让 LLM 决策参数提取从用户话里提取城市名System One Model可以用 NER 或正则确定性高条件判断检查 API 返回是否成功System One Model就是看状态码不需要推理格式转换把结果转成 JSONSystem One Model模板化操作LLM 反而容易出错结果总结把数据变成人话LLM需要自然语言生成能力循环控制判断是否继续执行System One Model基于计数器或条件确定性判断异常处理工具报错了怎么办System One Model LLM简单错误走规则复杂错误让 LLM 分析这张表是我根据 Jev 的设计思路和自己的经验整理的。核心原则就是能用确定性逻辑解决的绝不交给 LLM。2.2 为什么这样分工能提升 Agent 的稳定性这里面的逻辑其实不复杂。LLM 的本质是概率模型它的输出带有随机性。你让它做确定性判断它可能 95% 的时候对但剩下 5% 的错误在 Agent 链路里会被放大。举个例子。假设一个 Agent 执行链路有 4 个步骤每步都用 LLM 做判断每步准确率 95%。整体成功率是 0.95 的四次方约等于 81%。也就是说100 个请求里有 19 个会失败。如果把其中 3 步换成确定性规则只有 1 步用 LLM整体成功率就是 95%。差了 14 个百分点。Jev 的做法是把 Agent 的执行过程分成两层决策层和执行层。决策层用 LLM 做高层规划比如“用户想要什么”、“大概需要哪几个步骤”。执行层用 System One Model 做具体操作比如“调用哪个 API”、“参数是什么”、“结果是否有效”。这样 LLM 只做它擅长的高层决策执行层的确定性由规则保证。2.3 System One Model 在 Jev 里的具体形态Jev 里的 System One Model 不是一个单一的东西而是一组轻量模块的集合。根据我的理解和实践它至少包含以下几种形态规则引擎处理 if-else 逻辑比如“如果用户提到了城市名就提取出来作为参数”。小型分类器用轻量模型做意图分类比 LLM 快几个数量级。比如用 TF-IDF 逻辑回归做粗分类。状态机管理 Agent 的执行状态决定下一步走哪个分支。状态机是确定性的不会“跑偏”。模板引擎处理格式转换和输出组装。把数据填进预设模板比让 LLM 生成 JSON 可靠得多。校验器检查 LLM 的输出是否符合预期格式不符合就触发重试或降级。这些模块的共同特点是不依赖大规模参数、推理速度快、行为可预测。它们和 LLM 配合形成一套完整的 Agent 执行体系。提示不要觉得用规则引擎就是“倒退”。在生产环境里确定性比灵活性更重要。LLM 负责处理不确定性规则负责兜底。3. 实操怎么在 Agent 项目里落地这套分工思路光讲理念没用得能落地。我拿一个具体的 Agent 场景来演示——做一个“会议安排助手”用户说“帮我约张三明天下午三点开会”Agent 需要解析意图、提取参数、检查日历、创建会议、发送通知。3.1 第一步拆解执行链路标记每步的处理方式先把整个流程拆开然后逐个判断该用 LLM 还是 System One Model接收用户输入→ 原始文本意图识别判断用户想干什么 → LLM处理自然语言模糊性实体提取提取人名、时间、事项 → System One ModelNER 正则参数校验检查时间格式、人名是否存在 → System One Model规则校验日历查询调用日历 API 检查时间冲突 → System One ModelAPI 调用 状态码判断冲突处理如果有冲突决定怎么办 → LLM需要推理和决策创建会议调用 API 创建 → System One ModelAPI 调用结果组装生成给用户的回复 → LLM自然语言生成这样拆下来8 个步骤里只有 3 个需要 LLM其余 5 个都是确定性操作。延迟和成本直接降一半以上。3.2 第二步设计 System One Model 的具体实现以实体提取为例我用的是“正则 词典 轻量 NER”的组合方案import re from datetime import datetime, timedelta # 时间提取规则 TIME_PATTERNS [ (r今天, lambda: datetime.now().date()), (r明天, lambda: datetime.now().date() timedelta(days1)), (r后天, lambda: datetime.now().date() timedelta(days2)), (r(\d{1,2})点, lambda m: f{m.group(1)}:00), (r(\d{1,2}):(\d{2}), lambda m: f{m.group(1)}:{m.group(2)}), ] def extract_time(text): 从文本中提取时间信息返回结构化结果 result {date: None, time: None} for pattern, handler in TIME_PATTERNS: match re.search(pattern, text) if match: value handler(match) if callable(handler) else handler if isinstance(value, str) and : in value: result[time] value else: result[date] value return result # 人名提取先用词典匹配匹配不到再走轻量 NER def extract_person(text, known_persons): for name in known_persons: if name in text: return name # 降级方案用简单的姓氏 称谓规则 match re.search(r([张王李赵刘陈杨黄周吴][\u4e00-\u9fa5]{1,2}), text) return match.group(1) if match else None这段代码不复杂但效果比让 LLM 提取稳定得多。同样的输入永远给同样的输出。而且速度是毫秒级的LLM 调用一次至少几百毫秒。3.3 第三步LLM 和 System One Model 的衔接方式两者怎么配合Jev 的思路是LLM 做规划System One Model 做执行。具体来说LLM 接收用户输入输出一个结构化的“执行计划”比如{intent: schedule_meeting, steps: [extract_entities, check_calendar, create_event]}。执行引擎拿到计划后按步骤调用对应的 System One Model 模块。每个模块执行完把结果返回给执行引擎。如果某个步骤需要 LLM 介入比如冲突处理执行引擎再调用 LLM。最后LLM 根据所有执行结果生成自然语言回复。这种设计的好处是LLM 的调用次数可控而且每次调用的目的明确。不会出现“LLM 在循环里反复调用自己”的情况。实操心得LLM 输出的执行计划一定要做 schema 校验。我见过太多次 LLM 输出的 JSON 格式不对、字段缺失、或者步骤名拼错的情况。用一个 JSON Schema 校验器兜底不通过就重试或降级。3.4 第四步性能与成本对比实测我拿一个实际项目做了对比测试。同一个会议安排场景分别用“全 LLM”和“LLM System One Model”两种方案跑 100 次请求指标全 LLM 方案LLM System One Model提升幅度平均响应时间8.2 秒2.1 秒74%单次请求 token 消耗约 4500约 120073%任务成功率82%96%14 个百分点行为可复现率61%98%37 个百分点这个数据不一定适用于所有场景但趋势是明确的把确定性任务从 LLM 手里拿走整体表现会有质的提升。4. 常见问题与排查技巧实录落地这套思路的过程中我遇到过不少问题。有些是设计层面的有些是工程层面的。挑几个典型的说说。4.1 System One Model 覆盖不了的情况怎么办这是最常见的问题。你设计了一堆规则结果用户输入了一个规则没覆盖的情况。比如用户说“下周三之前找个时间”你的时间提取规则只处理了“今天明天后天”没处理“下周三之前”。我的处理策略是分级降级第一级规则匹配。能匹配到就直接用。第二级轻量模型。规则匹配不到走一个小型分类器或 NER 模型。第三级LLM 兜底。前两级都搞不定才调用 LLM 处理。第四级人工兜底。LLM 也处理不了转人工或返回默认值。关键是每一级都要有明确的触发条件和超时控制。不能让请求在某一级卡死。4.2 怎么判断一个任务该不该用 LLM我总结了一个简单的判断流程这个任务的输出是否可以用确定性规则描述如果是用 System One Model。这个任务是否需要理解自然语言的模糊含义如果是用 LLM。这个任务的错误成本高不高如果高优先用 System One Model。这个任务的输入空间是否有限且可枚举如果是用 System One Model。这个任务是否需要世界知识或常识推理如果是用 LLM。大部分 Agent 执行步骤都能用这套流程判断出来。实在拿不准的先上 LLM跑一段时间看看它的输出是否稳定。如果发现 LLM 的输出其实很固定那就说明这个任务可以用规则替代。4.3 常见问题速查表问题现象可能原因排查方向解决方案Agent 响应慢LLM 调用次数过多统计每次请求的 LLM 调用次数把确定性步骤改为 System One Model行为不可复现LLM 输出随机性检查哪些步骤用了 LLM对确定性任务增加规则约束成本居高不下token 消耗大分析每次调用的输入输出长度精简 prompt减少不必要的 LLM 调用规则覆盖不全输入空间考虑不周收集失败案例分析模式增加规则或引入轻量模型LLM 输出格式错误prompt 不够明确检查 prompt 和 schema增加格式校验和重试机制状态机死循环状态转移条件有漏洞检查状态转移图增加最大循环次数限制4.4 几个容易踩的坑不要过早优化项目初期可以先用 LLM 跑通流程等稳定了再逐步替换成 System One Model。一上来就设计复杂的规则系统可能方向都还没搞清楚。规则要可配置不要把规则硬编码在代码里。用配置文件或数据库管理规则方便调整和扩展。监控 LLM 调用每次 LLM 调用都要记录输入、输出、耗时、token 消耗。这些数据是优化的依据。保留降级路径System One Model 失败时要有降级到 LLM 的路径。反过来也一样LLM 失败时要有默认行为。定期回顾规则业务在变规则也要跟着变。定期检查哪些规则已经失效哪些场景需要新增规则。注意System One Model 不是银弹。它解决的是确定性问题不是所有问题。该用 LLM 的地方还是要用 LLM关键是分清边界。5. 从 Jev 的思路延伸Agent 架构设计的几个原则Jev 给出的答案不只是“LLM 和 System One Model 分工”这一个点它背后有一套完整的 Agent 架构设计哲学。我把它提炼成几个原则供你在自己的项目里参考。5.1 确定性优先原则在 Agent 执行链路里凡是能用确定性逻辑解决的问题都不要交给概率模型。这不是对 LLM 的不信任而是对工程稳定性的追求。生产环境和实验室环境最大的区别就是生产环境要求可预测、可复现、可调试。确定性优先不意味着排斥 LLM。LLM 在处理模糊性、生成自然语言、进行复杂推理方面有不可替代的优势。关键是把它放在正确的位置上。5.2 分层设计原则Agent 的架构应该分层每层职责清晰规划层用 LLM 做高层决策理解用户意图制定执行计划。执行层用 System One Model 做具体操作调用工具、处理数据、管理状态。校验层用规则和轻量模型检查每一步的输出确保符合预期。降级层当某一层失败时有明确的降级路径。分层的好处是每层可以独立优化和替换。你想换一个 LLM不影响执行层。你想增加一条规则不影响规划层。5.3 可观测性原则Agent 的执行过程必须是可观测的。每一步的输入、输出、耗时、状态都要记录下来。这样出了问题才能快速定位。我见过太多 Agent 项目出了问题只能靠猜。因为 LLM 的调用没有日志规则执行没有追踪状态转移没有记录。这种项目根本没法维护。Jev 的设计里每个 System One Model 模块都有明确的输入输出接口执行引擎会记录每一步的执行结果。这为调试和优化提供了基础。5.4 渐进式演进原则不要试图一次性设计一个完美的 Agent 架构。从简单开始逐步演进。我的建议是先用 LLM 跑通核心流程然后逐步把确定性步骤替换成 System One Model。每次替换后做对比测试确认效果有提升再继续。这样风险可控而且能持续积累经验。5.5 成本意识原则LLM 调用是有成本的不只是钱还有延迟和稳定性。每次调用 LLM 之前先问自己这个调用真的必要吗有没有更轻量的替代方案这不是抠门而是对系统整体负责。一个设计良好的 AgentLLM 调用次数应该控制在合理范围内而不是每个步骤都依赖 LLM。6. 我个人的一些实践体会做 Agent 开发这几年最大的感受就是克制比能力更重要。大模型的能力很强但不是什么都要用它。知道什么时候不用 LLM比知道怎么用 LLM 更难也更有价值。Jev 这个项目给我的启发是Agent 的智能不在于每一步都用最强大的模型而在于合理地分配任务。让 LLM 做它擅长的事让 System One Model 做它擅长的事两者配合才能构建出稳定、高效、可维护的 Agent 系统。我在实际项目里落地这套思路之后最明显的变化是调试时间大幅缩短。以前出了问题要翻 LLM 的调用日志看它哪一步推理跑偏了。现在大部分步骤都是确定性的出了问题直接看规则执行结果几分钟就能定位。另一个变化是团队协作更顺畅了。规则和状态机是代码可以 review、可以测试、可以版本管理。LLM 的 prompt 虽然也是代码但它的行为更难预测。把确定性逻辑抽出来之后团队对系统的理解更一致了。最后分享一个小技巧如果你不确定某个步骤该不该用 LLM先把它写成规则跑一段时间。如果规则能覆盖 90% 以上的情况那就保留规则剩下的 10% 用 LLM 兜底。如果规则覆盖率很低那就说明这个任务确实需要 LLM。这个“先规则后 LLM”的顺序比“先 LLM 后规则”更容易找到边界。
