1. 为什么要在 Agent 里塞一个“判断器”1.1 从“能跑”到“跑得对”的那道坎我最早接触 Agent 这套东西的时候心态特别简单能调通工具、能循环执行、能返回结果就算成了。后来项目一上量问题全冒出来了。同一个请求Agent 有时候直接调工具有时候绕一大圈先规划再执行有时候干脆把简单问题当成复杂任务处理token 烧得飞快结果还不稳定。这时候我才意识到Agent 缺的不是能力而是一个“判断器”——在动手之前先判断这件事该不该做、该怎么做、做到什么程度。所谓“判断器”说白了就是在 Agent 的主循环里插一个决策节点。它不负责具体执行只负责回答几个关键问题这个输入属于哪一类任务需要调用工具还是直接回答需要多步规划还是单步搞定当前上下文够不够要不要先检索记忆这些问题如果交给主模型“顺手”判断往往会因为 prompt 太长、注意力分散而判断失准。单独抽出来做一个判断器本质上是一种关注点分离。这个思路和 Laya、Jev 这类模型的出现是同一个逻辑。Laya 模型主打的是轻量、快速、指令跟随稳定适合做前置判断这种“短平快”的活Jev 模型则偏向更强的推理和结构化输出能力适合做复杂任务的规划判断。把这两个放在 Agent 架构的不同位置一个当“门卫”一个当“参谋”整个系统的稳定性会有肉眼可见的提升。1.2 判断器到底解决哪些具体问题我梳理了一下自己在项目里踩过的坑判断器主要解决四类问题。第一类是路由问题。用户输入五花八门有的是闲聊有的是查数据有的是要执行一串操作。如果没有判断器主模型很容易把闲聊也走一遍工具调用流程白白浪费一次函数调用和一轮上下文。加一个轻量判断器先分类简单闲聊直接走快速通道复杂任务才进主循环整体延迟能降不少。第二类是规划粒度问题。有些任务一步就能完成有些需要拆成五步。判断器可以根据任务复杂度决定规划深度避免“杀鸡用牛刀”。我实测下来一个 7B 级别的判断器做粒度判断准确率能到 85% 以上比让主模型自己拿捏要稳。第三类是安全与边界问题。Agent 一旦能调工具就有越权风险。判断器可以在执行前做一层校验这个操作是否在允许范围内参数是否合理有没有 prompt 注入的痕迹这一层虽然不能替代完整的安全框架但作为第一道闸门非常有效。第四类是记忆调用问题。不是每次对话都需要翻历史记忆。判断器可以决定这次要不要检索长期记忆、检索多少条、要不要写入新记忆。这个判断做得好能显著减少无效检索带来的噪声。1.3 适合谁来参考这套思路这套东西不是只给大厂用的。我自己就是从一台开发机、一个 Python 环境起步的。如果你正在做 AI Agent 开发不管是个人项目还是团队产品只要遇到“Agent 行为不稳定”“token 消耗失控”“简单任务被复杂化”这类问题判断器思路都能直接套用。前端背景的同学也不用怕判断器本质上就是一个分类加决策的模块用 Python 写几十行就能跑起来后面再逐步替换成 Laya、Jev 这类专门模型即可。2. Laya 与 Jev两个模型在 Agent 里的分工2.1 Laya 模型轻量前置判断的合适人选Laya 模型给我的第一印象就是“快”。它的参数量不大推理延迟低指令跟随做得比较扎实。在 Agent 架构里我把它放在最前面当路由判断器。具体做法是用户输入进来先过 Laya让它输出一个结构化标签比如{type: chat}、{type: tool, tool: search}、{type: plan}。这个输出不需要多精细只要分类准确就行。为什么选 Laya 而不是直接上大模型因为前置判断这个环节调用频率极高几乎每次请求都要走一遍。如果用大模型成本和延迟都扛不住。Laya 这种轻量模型单次判断几十毫秒成本可以忽略不计而且分类任务本身不需要太强的推理能力Laya 完全够用。这里有个细节要注意Laya 的输出格式一定要用强约束。我一开始用自然语言让它“判断一下类型”结果它有时候返回一整句话解析起来很麻烦。后来改成让它只输出 JSON并且在 prompt 里给两三个示例稳定性立刻上来了。这个技巧对所有做结构化输出的场景都适用。2.2 Jev 模型复杂规划与结构化决策Jev 模型的定位和 Laya 不一样。它更适合做需要推理的判断比如“这个任务应该拆成哪几步”“每一步用什么工具”“依赖关系是什么”。我在项目里把 Jev 放在规划层当判断器判定为复杂任务时才交给 Jev 做详细规划。Jev 的一个优势是结构化输出能力强。让它输出一个步骤列表它很少跑偏。我通常会让它输出类似这样的结构{ steps: [ {id: 1, action: search, query: ...}, {id: 2, action: summarize, depends_on: 1} ] }这种结构直接可以被执行器消费不需要再做二次解析。相比让主模型自由发挥Jev 的规划结果更可控出错也更容易定位。Jev 的本地部署也是我比较关心的点。它的模型文件不算大在消费级显卡上能跑起来。部署方式和常见的大模型部署流程类似拉模型、配环境、起服务然后用 HTTP 接口调用。我建议先用小批量请求压测一下看看延迟和显存占用再决定并发数。2.3 两个模型怎么配合分层判断架构把 Laya 和 Jev 放在一起就形成了一个分层判断架构。第一层 Laya 做粗分类第二层 Jev 做细规划。这个架构的好处是每一层只做自己擅长的事不会互相干扰。我画不出图但可以用文字描述这个流程用户输入 → Laya 分类 → 如果是简单任务直接走快速通道 → 如果是复杂任务交给 Jev 规划 → 规划结果交给执行器 → 执行器调工具 → 结果返回。整个链路里判断器只占很小一部分但它决定了后面所有环节的走向。这个架构还有一个好处是可替换。Laya 和 Jev 都不是唯一选择你完全可以用别的轻量模型替代 Laya用别的推理模型替代 Jev。关键是这个分层思路而不是具体用哪个模型。我试过把 Laya 换成其他小模型只要分类准确率达标整体效果差不多。2.4 模型选择时的几个硬指标选判断器模型我一般看四个指标。第一是延迟前置判断不能超过 200ms否则用户体验会明显变差。第二是结构化输出稳定性能不能稳定输出 JSON这个比准确率还重要因为解析失败会直接导致流程中断。第三是分类准确率这个可以用自己业务的测试集跑不用迷信榜单。第四是部署成本显存占用、是否支持量化、能不能在边缘设备上跑这些都要提前确认。我踩过的一个坑是只看准确率忽略了解析稳定性。结果模型分类是对的但输出格式偶尔带点多余文字解析器直接报错。后来我在 prompt 里加了“只输出 JSON不要任何解释”并且加了输出后处理才把这个问题解决。所以选模型的时候一定要用真实业务数据跑一遍完整链路不能只看单项指标。3. 判断器的部署实操从环境到上线3.1 Python 环境准备与依赖安装部署判断器的第一步是把 Python 环境弄干净。我强烈建议用虚拟环境不要直接在系统 Python 上装依赖。用python -m venv agent-env建一个独立环境然后激活。这样后面装什么库都不会污染全局出问题也好回滚。依赖方面核心就是模型推理库和 Web 框架。推理库看你怎么部署如果用现成的推理服务就装对应的客户端库如果自己加载模型就装 transformers 或者对应的推理框架。Web 框架我一般用 FastAPI轻量、异步支持好、写接口快。再装个 uvicorn 当服务器基本就够了。python -m venv agent-env source agent-env/bin/activate pip install fastapi uvicorn requests如果你要用 Laya 或 Jev 的本地推理还需要装对应的模型加载库。具体装哪个看模型官网的说明。这里提醒一句模型官网地址一定要从正规渠道获取不要随便从第三方下载模型文件安全风险很大。3.2 判断器服务的接口设计判断器对外就是一个 HTTP 接口输入是用户文本加一些上下文输出是结构化判断结果。我设计的接口大概长这样from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class JudgeRequest(BaseModel): text: str context: str class JudgeResponse(BaseModel): task_type: str need_tool: bool need_plan: bool confidence: float app.post(/judge, response_modelJudgeResponse) async def judge(req: JudgeRequest): # 调用 Laya 或 Jev 做判断 result call_judge_model(req.text, req.context) return result这个接口设计的关键是字段要少而明确。task_type表示任务类型need_tool表示要不要调工具need_plan表示要不要规划confidence表示置信度。置信度低的请求可以走兜底逻辑比如直接交给主模型处理避免判断器误判导致流程走偏。接口设计还有一个经验不要把判断逻辑写死在接口里。判断逻辑应该抽成一个独立函数方便后面替换模型或者调整规则。我一开始把逻辑全写在接口函数里后来换模型的时候改得头大重构了一次才理顺。3.3 模型加载与推理配置模型加载这块核心是显存管理和并发控制。如果你的判断器模型不大可以常驻显存避免每次请求都重新加载。加载的时候注意设置合适的精度FP16 通常够用显存紧张就上 INT8 量化。推理配置里max_new_tokens要设小一点判断任务不需要长篇输出设 128 到 256 就够了。temperature设低一点0.1 到 0.3 之间保证输出稳定。top_p也可以调低减少随机性。这些参数看起来不起眼但对判断器的稳定性影响很大。并发控制方面判断器服务要设一个最大并发数超过就排队或者拒绝。我一般用信号量控制避免请求堆积把显存打爆。实测下来一个 7B 模型在单卡上并发 4 到 8 比较稳再高延迟就上去了。3.4 部署方式选择本地、容器还是边缘设备部署方式我试过三种。第一种是本地直接跑适合开发调试改代码方便但不适合生产。第二种是容器化部署用 Docker 打包环境一致性好迁移方便。第三种是边缘设备部署比如在一些专用硬件上跑轻量模型适合对延迟和隐私要求高的场景。容器化部署是我最推荐的。写个 Dockerfile把 Python 环境、依赖、模型文件都打进去然后docker run起来就行。这样换机器、扩容都很方便。边缘设备部署则要看具体硬件像 RK3588 这类芯片跑轻量模型是可以的但要注意模型格式转换和算子支持不是所有模型都能直接跑。选择部署方式的时候核心看三个因素延迟要求、成本预算、运维能力。延迟要求高就靠近用户部署成本敏感就用共享推理服务运维能力弱就选容器化加托管服务。没有绝对最优只有最适合当前阶段的。4. 判断器上线后的常见问题与排查4.1 判断不准分类错误的排查思路判断器上线后最常见的问题就是分类不准。排查的时候我一般按这个顺序来。先看测试集准确率如果测试集上就不行那是模型或 prompt 的问题。再看线上 badcase把判断错误的请求捞出来看看有没有共性。最后看置信度分布如果大量请求置信度都很低说明判断器对这类输入没把握需要补充训练数据或者调整 prompt。我遇到过一个典型问题用户输入里带否定词的时候判断器容易分错。比如“不用查了直接告诉我”判断器还是判定要调工具。后来我在 prompt 里加了否定词的示例并且让判断器先做一次意图识别再做分类准确率就上来了。这个经验说明判断器的 prompt 要覆盖边界情况不能只给正例。4.2 延迟过高性能瓶颈定位延迟高的时候先分段计时。是模型推理慢还是网络传输慢还是后处理慢。我一般会在代码里打点记录每个阶段的耗时。如果模型推理慢看是不是max_new_tokens设太大了或者并发太高导致排队。如果网络慢看是不是判断器和主服务不在同一台机器上。有个容易被忽略的点是冷启动。如果判断器服务不是常驻的第一次请求会加载模型延迟可能好几秒。解决办法是服务启动时预热一次或者用健康检查接口定期探活保持服务热着。我吃过这个亏上线第一天用户反馈“第一次特别慢”后来加了预热就好了。4.3 输出格式解析失败格式解析失败是判断器最烦人的问题之一。模型明明分类对了但输出多了一句话解析器就崩了。解决办法有三层。第一层是 prompt 约束明确要求只输出 JSON。第二层是输出后处理用正则把 JSON 部分抠出来。第三层是兜底逻辑解析失败就走默认判断不要让整个流程挂掉。我现在的做法是prompt 里给两三个 JSON 示例输出后用正则匹配第一个{到最后一个}然后尝试解析。解析失败就记一条日志走兜底。这样即使模型偶尔抽风也不会影响主流程。这个思路对所有依赖结构化输出的场景都适用。4.4 常见问题速查表问题现象可能原因排查方法解决方向分类准确率低prompt 覆盖不足看 badcase 共性补充示例、调整 prompt延迟突然升高并发过高或显存不足分段计时、看显存限流、量化、扩容输出解析失败模型输出多余内容看原始输出加后处理、加兜底服务偶尔无响应冷启动或崩溃看服务日志预热、加健康检查置信度普遍偏低模型不适配业务看置信度分布换模型或微调这张表是我自己排查时总结的实际用起来能省不少时间。遇到问题先对号入座再深入定位比盲目试错高效得多。5. 判断器架构的扩展与个人经验5.1 从单判断器到多判断器协作单判断器跑顺之后可以考虑扩展成多判断器协作。比如一个判断器专门做安全校验一个专门做任务分类一个专门做规划粒度判断。每个判断器只关注一个维度准确率会更高也更容易维护。多判断器协作的关键是编排顺序。我一般把安全校验放最前面因为安全是一票否决的。然后是任务分类再是规划粒度。每个判断器的输出作为下一个判断器的输入形成一条判断链。这条链的延迟要控制好不能因为判断器多了就拖慢整体响应。5.2 判断器与记忆系统的配合判断器和记忆系统配合好了效果很明显。判断器可以决定这次要不要检索记忆、检索哪一类记忆、要不要写入新记忆。比如用户说“上次那个方案再改一下”判断器识别出这是延续性任务就去检索相关历史记忆。如果用户说“你好”判断器直接判定不需要检索省一次查询。写入记忆也一样。不是所有对话都值得记。判断器可以判断这次对话有没有长期价值有才写入。这样记忆库不会被垃圾信息撑爆检索质量也更高。我在项目里加了这个判断后记忆检索的命中率提升了不少。5.3 我踩过的坑和总结的经验第一个坑是过度依赖判断器。有段时间我把所有决策都交给判断器结果判断器一错整个流程就崩。后来我加了兜底逻辑判断器置信度低的时候直接交给主模型处理不强行走判断结果。这个改动让系统鲁棒性提升很多。第二个坑是忽略判断器的可观测性。判断器做决策但决策过程是黑盒。后来我加了日志记录每次判断的输入、输出、置信度、耗时。出问题的时候一查日志就清楚不用猜。可观测性这东西平时觉得多余出事的时候是真救命。第三个坑是模型版本管理混乱。判断器换模型的时候没有做版本隔离新旧模型混着跑结果行为不一致。后来我给每个模型版本打了标签接口里带上版本号灰度切换才把这个问题解决。模型版本管理在 Agent 项目里特别重要因为模型行为差异会直接影响用户体验。5.4 后续可以怎么扩展判断器这套架构后面可以往几个方向扩展。一是自适应判断根据历史判断准确率动态调整判断策略准确率低的场景自动降级。二是多模态判断不只判断文本还能判断图片、语音输入的任务类型。三是判断器微调用自己业务的标注数据微调 Laya 或 Jev让判断更贴合具体场景。我现在正在试的是自适应判断。思路很简单记录每个场景下判断器的历史准确率准确率低于阈值的场景直接跳过判断器走主模型。这样既保留了判断器的效率优势又避免了它在不擅长场景下拖后腿。实测下来这个策略对整体准确率有正向帮助。判断器这个东西说到底就是给 Agent 加一层“想清楚再动手”的机制。它不复杂但很实用。Laya 和 Jev 只是当前比较合适的选择后面肯定会有更好的模型出现。关键是这个分层判断的思路以及配套的部署、排查、扩展方法。把这套东西跑通你的 Agent 会稳很多。