最近调 Agent 系统的时候我栽了不少跟头。最典型的一个用户让 Agent 查一笔订单的物流信息Agent 绕来绕去最后居然打算调用“创建退款”的工具。模型本身没有错它只是把用户意图和工具参数搞混了。真正缺的是一个在动手之前踩刹车的组件——我给这种东西起了个名字判断器。判断器是一个独立的决策节点Agent 的每个动作在真正执行前都要先过它这一关。围绕这个思路我先后对比了 Laya 和 Jev 两套方案也踩了一堆部署和选型的坑。这篇文章就把这些实战经验完整记录下来给正在做 Agent 治理、工具调用安全或者想本地部署判断器的朋友做个参考。1. 判断器到底在解决什么问题1.1 Agent 失控通常不是模型的锅很多人以为 Agent 出问题是大模型能力不够比如智商低、理解差。但我在实际项目里发现真正翻车的场景往往是“模型什么都懂但没有边界感”。一个能写代码、能调用 API 的 Agent和一把没有保险栓的电锯一样危险。典型的 Agent 执行链路是任务解析 - 规划 - 工具选择 - 工具调用 - 观察结果 - 继续循环 - 输出大多数安全问题发生在“工具选择”和“工具调用”之间。模型选择了错误的工具或者正确工具配了危险参数这时候如果没人拦一下后果就不可控了。判断器就放在这个位置相当于给执行链路加了一道审批闸门。我总结过常见的失控类型工具误用把“查询账单”理解成“发起退款”把“读文件”理解成“删除文件”。死循环Agent 反复调用同一个工具参数不变、结果不变白白消耗 token。越权操作删除数据、发送邮件、对外写入消息这类动作一旦执行很难撤销。低质量输出Agent 跑了半小时返回的结果和用户最初目标完全对不上。这些问题里只有一部分是模型推理能力问题剩下大多是缺少判断机制。你可以把 Agent 想象成刚入职的实习生活能干但不知道什么时候该请示、什么时候该停手。判断器就是那个负责审批的主管。1.2 判断器的两条路线规则优先还是模型判断判断器不是某种单一技术而是一类组件的统称。我把它分成两条路线。第一条是规则/启发式路线。用正则、白名单、黑名单、阈值、状态机这些东西做拦截。优点是延迟低、完全可解释、误判可以精准修正缺点是很傻碰到语义复杂的话就失灵。比如你写一条规则“凡是调用删除接口都拒绝”那 Agent 想删临时文件也被拒业务就崩了。第二条是模型判断路线。用一个小的分类模型或者一个大模型作为 judge对 Agent 的动作做语义级别的评估。它能理解“这个删除操作针对的是临时目录可以放行”“那个查询动作带上了支付参数有问题”。缺点是重、慢、可能有幻觉自己也会出错。实际上成熟方案不会只用一种。我在项目里同时用了两套东西恰好对应两条路线Laya偏轻量动作审查适合做第一道闸Jev偏深度评估适合做复杂判断。接下来分别展开讲。2. Laya轻量级动作审查器2.1 Laya 的定位和输入输出Laya 在我这边定位是“轻量级动作审查器”。它不做复杂的任务规划也不替 Agent 写代码只回答一个问题这个动作能不能做。Laya 的模型量级不大量化后可以跑在边缘设备上比如 Jetson Orin、RK3588甚至纯 CPU 环境也能跑。这不是因为它弱而是设计目标就是低延迟、高吞吐。它要挡的是“明显不该做”的动作而不是去评判整个任务的好坏。它的输入设计很关键。我在接入的时候没有把完整对话历史丢进去而是做了一个结构化输入{ action: create_refund, action_params: { order_id: 20241101-001, amount: 499.00 }, context_summary: 用户要求查询物流信息未提及退款, sensitive_flags: [payment, refund, write] }输出是固定 JSON{ label: reject, score: 0.92, reason: 用户目标是查询物流未授权退款操作 }label 分三档accept、needs_review、reject。score 表示置信度。把输入输出结构定死后续接任何 Agent 框架都方便。2.2 部署 Laya 的完整步骤部署 Laya 我用的是 GGUF 量化版。模型本身如果直接跑 FP16边缘设备扛不住量化到 Q4_K_M 之后体积和显存占用都下来了精度损失对判断任务来说基本可以接受。第一步是准备模型文件。从模型仓库拉取量化后的 GGUF 权重找 Q4_K_M 或者 Q5_K_M我这边实测 Q4_K_M 是性价比比较高的档位。文件大小大概在 3GB 到 5GB 之间取决于模型原始参数量。第二步用 llama.cpp 起一个本地推理服务./server \ -m laya-7b-q4_k_m.gguf \ --host 127.0.0.1 \ --port 8081 \ -c 4096 \ --temp 0.1-c 4096是上下文长度。判断器不需要读完整对话4K 足够。--temp 0.1是为了让输出尽量稳定判断任务不应该有创造性。第三步写一个 Python 客户端把接口包一层import requests class LayaClient: def __init__(self, endpointhttp://127.0.0.1:8081): self.endpoint endpoint def review(self, action, params, context_summary, sensitive_flags): payload { action: action, action_params: params, context_summary: context_summary, sensitive_flags: sensitive_flags } resp requests.post(f{self.endpoint}/completion, json{ prompt: build_prompt(payload), temperature: 0.1, max_tokens: 128, stop: [\n] }) return parse_response(resp.json())这里我没有直接用 llama.cpp 原生接口而是中间加了一层 Python。原因很简单Agent 主链路是 Python 写的统一用 Python client 能省掉很多类型转换和错误处理的麻烦。显存估算方面可以按这个公式粗略计算模型显存 ≈ 权重文件大小 KV Cache 运行时开销Q4_K_M 的 7B 模型权重约 4.2GB4K 上下文的 KV Cache 大约 0.5GB再加上推理框架自身占用总需求大概 5GB 到 6GB。这意味着 8GB 显存的 Jetson Orin 能跑16GB 内存的 RK3588 开发板也能通过 CPU 方式跑只是速度会慢一些。2.3 怎么接入 Agent 而不把链路拖垮位置很重要。判断器应该放在“工具调用参数组装完成之后”“真正执行 API 调用之前”。如果放在 Agent 模型内部那你换一个模型就得重写如果放在太外层比如放在用户请求入口又拦不到中途产生的工具调用。我用的接入方式是写一个装饰器统一包住所有工具函数def guarded_tool(func): wraps(func) def wrapper(*args, **kwargs): action func.__name__ params kwargs result laya_client.review(action, params, build_context_summary()) if result.label reject: raise ToolRejected(result.reason) if result.label needs_review: return escalate_to_human(action, params, result.reason) return func(*args, **kwargs) return wrapper这里有个非常重要的设计被 reject 之后不是直接把错误抛给用户而是把 reason 变成一条“观察结果”返回给 Agent让 Agent 重新规划。比如 Agent 要创建退款被拦了reason 是“用户目标是查询物流”Agent 看到之后就会修正成查询接口。这比硬切断体验好很多。还有兜底策略。判断器本身的延迟如果超过阈值不能让它把 Agent 整个拖死。我的做法是分场景高风险操作删除、转账、发消息超时默认拦截低风险操作查询、读取超时默认放行同时记录一条 warning。默认全拦会误伤正常流程默认全放又会失去保护意义必须按风险分级。3. Jev重判断模型负责多轮评估3.1 Jev 擅长的事情如果说 Laya 是“交警”那 Jev 更像“项目评审”。它不盯着单次动作而是评估整个 Agent 行为序列是否合理。Jev 能处理三类问题目标一致性、冲突检测、结果质量评估。目标一致性是指 Agent 做了一连串操作之后到底有没有在朝用户最初的目标前进。比如用户说“分析这份销售数据并做图表”Agent 中途开始调整数据源、删列、改格式这些单看都没问题但放在一起可能已经偏离目标。Jev 能结合多轮上下文给出“当前行为与原始目标匹配度 70%”这样的判断。冲突检测是看多步操作之间是否互相矛盾。Agent 先删除了某个临时表后面又去查这个表Jev 能发现这种前后冲突提醒 Agent 修正路径。结果质量评估则更像质检。Agent 生成了一段 SQL、一份摘要、一个图表配置输出前用 Jev 检查一下“是否满足用户需求、有没有明显错误、缺不缺关键信息”。社区里有人用 Jev 构建数据系统本质就是每完成一个数据处理步骤让 Jev 判断一下中间结果还能不能往下走省去人工盯过程。3.2 Jev 的获取与部署Jev 的权重和 API 不是随手就能拿到的很多项目需要走申请流程。这是模型厂商控制使用场景的常见做法申请时说明用途、部署环境、数据量一般几天内会有反馈。拿到之后有两种部署模式托管 API 和本地权重。托管 API 最省心直接在代码里配一个 endpoint 和 key 就能调用。但数据要过第三方敏感业务不太合适。本地部署我主要用 vLLM。因为 Jev 的输入输出都比较长推理引擎必须支持 continuous batching否则并发一高就卡死。Windows 上部署时需要注意几点Python 3.10 以上、CUDA 12 环境、显存足够。以 34B 量级模型为例bf16 精度大约需要 70GB 显存单张 80GB 的卡能跑或者用两张 40GB 卡做 tensor parallel。启动命令大致如下python -m vllm.entrypoints.openai.api_server \ --model jev-model \ --dtype bfloat16 \ --tensor-parallel-size 2 \ --max-model-len 32768 \ --port 8000启动之后它就暴露一个 OpenAI 兼容接口调用方式和 ChatCompletion 一样。这对接现有框架非常方便。在 Codex 这类 Agent 工具里用 Jev我采取的方式是把 Jev 封装成一个自定义判断插件。Codex 本身不强制判断器但它开放了接口让外部逻辑注入。配置层面大概是custom_judge: name: jev endpoint: http://127.0.0.1:8000/v1 review_after_each_tool: true review_conditions: - tool_result_contains_error - proposed_tool_is_sensitive - task_branch_depth_greater_than_3这个配置表示每次工具执行后都让 Jev 看一眼但为了控制成本只有出现错误、敏感操作或者分支深度太高时才做完整评估。3.3 Jev 的参数与调用技巧Jev 这类重模型调用参数直接决定输出质量。我踩过几个坑总结成三条经验。第一temperature 必须设成 0或者直接关闭采样。判断任务是确定性问题不需要“创造性”。temperature 高了同一个动作可能这次判通过下次判拒绝用户会被搞疯。第二强制输出 JSON 结构。我在 prompt 里明确要求只在固定 schema 的 JSON 里输出不允许输出任何解释性废话。解析失败的样例我会扔进 few-shot模型会很快学会。{ verdict: allow | deny | review, confidence: 0.0, evidence: [用户未授权退款, 工具参数包含金额] }第三给 Jev 提供轻量级“评审手册”。与其让它自由发挥不如把评分标准写清楚什么情况必须拒绝、什么情况需要人工、什么情况可以放行。few-shot 示例放三到五条就够了太多反而会干扰判断。3.4 分层判断把 Laya 和 Jev 组合成一套管线单用一个判断器要么太快但不准要么太准但太慢。我的做法是分层。第一层全量走 Laya。因为它便宜、快任何 Agent 动作都先过一遍挡掉明显的高风险动作和格式错误。第二层只处理“需要关注”的样本。Laya 的判定结果如果是 needs_review或者 Agent 执行过程中出现了多次重试、报错、分支异常再由 Jev 做深度判断。伪代码大概是for action in agent_actions: quick laya_client.review(action) if quick.label accept: execute(action) elif quick.label reject: raise ToolRejected(quick.reason) else: deep jev_client.review(action, full_context) if deep.verdict allow: execute(action) elif deep.verdict deny: raise ToolRejected(deep.evidence) else: escalate_to_human(action, deep.evidence)这套分层管线跑下来Laya 拦截了大约 70% 的明显问题Jev 只处理剩下 30% 的疑难杂症。整体延迟增加控制在 20% 以内但安全事件少了非常多。4. 选型与部署决策Laya 还是 Jev或者都要4.1 一张表帮你快速决策判断器选型不能只看模型能力要结合硬件、延迟、数据敏感度、运维成本。我把决策因素整理成一张速查表场景延迟要求硬件预算数据敏感度推荐方案边缘设备、IoT毫秒级低Jetson/RK3588高仅 Laya普通 API 网关百毫秒级中单卡 GPU中仅 Laya复杂业务工作流秒级可接受高多卡 GPU高Laya Jev 分层快速原型验证不敏感无 GPU依赖 API低托管 Jev API数据系统、数据分析管线秒级中高高Laya 过滤 Jev 阶段性评估从这个表也能看出来判断器不是越重越好。很多场景只需要 Laya 就够了强行上 Jev 反而把延迟和成本都拉上去。4.2 Agent 并发怎么扛判断器也不能掉链子很多人只关心 Agent 主模型怎么扛并发忽略了判断器也可能成为瓶颈。实际上判断器是串联在 Agent 链路里的它一卡整个 Agent 都卡。计算并发能力的公式很简单单实例 QPS ≈ 并发数 / 单请求耗时举个例子Jev 在 A100 上处理一个复杂判断请求平均耗时 1.5 秒。如果只开单线程跑QPS 只有 0.67基本不可用。开到 8 并发QPS 到 5.3才开始有点实战价值。业务侧如果要求 50 QPS那就得部署 10 个实例或者用 continuous batching 把吞吐打上去。Laya 因为模型小情况好很多。llama.cpp 服务在 CPU 上单次推理可能只有 20 到 50 毫秒开多进程做负载均衡单机扛几百 QPS 问题不大。还有一个容易忽略的优化缓存。Agent 的动作如果重复率很高比如很多人都用同一个“查询订单”工具上下文也相似判断结果完全可以缓存。我用 Redis 做了一层缓存key 是“动作名 参数摘要哈希 上下文摘要哈希”命中率大约 30%延迟直接从 20 毫秒降到 1 毫秒。4.3 本地部署和 API 托管怎么选本地部署和 API 托管不是对立关系而是资源约束下的取舍。本地部署适合三类情况数据不能出内网、硬件已经到位、需要长期大规模调用。缺点是运维成本高模型更新、bug 修复、性能调优全得自己来。我团队里没有专门的推理运维工程师所以本地部署只放了 LayaJev 直接用托管 API 兜底。API 托管适合快速原型和小流量场景。不需要管 GPU不用处理 CUDA 版本冲突按量付费。但单量上来之后费用会变得很吓人。一个判断请求如果消耗几千 token一天跑十万次日成本可能就顶一台 GPU 的月租了。我的建议业务规模还不确定的时候先走 API验证判断器确实有效、拦截率稳定之后再考虑把流量大的部分迁到本地。4.4 不同 Agent 框架的接入差异接入判断器之前先要搞清楚 Agent 和 harness 的区别。Agent 是那个能推理、能调用工具的模型harness 是控制 Agent 循环执行的框架外壳。判断器应该挂在 harness 层而不是塞进 Agent 模型内部。这样做的最大好处是解耦。今天用 DeepSeek 做 Agent 底座明天换成别的模型harness 不动判断器也不用动。我在 LangGraph 里接判断器就是在每个节点执行的守卫函数里调 Laya在 OpenAI function calling 场景里就是在 tool call 之前加一道拦截自研的 Codex 类工具也是在工具执行网关里挂 Jev。统一的接入抽象可以做成这样class ReviewProvider(Protocol): def review(self, action, params, context) - ReviewResult: ...LayaProvider 和 JevProvider 都实现这个接口Agent 框架只依赖接口不依赖具体实现。这样后面想换判断器、加判断器都是配置级别的事情。5. 实操中的踩坑记录与排查技巧5.1 判断器误杀太多怎么办判断器上线第一周最常听到的反馈是“这玩意儿把正常请求也拦了”。误杀是判断器最严重的问题因为它直接伤害用户体验。我踩坑之后的做法是先不拦截只看结果。判断器全量接入但 reject 的时候不阻断而是打日志。跑三天之后统计动作判断器拒次数人工复核正确次数准确率误杀次数查询订单11327%8创建退款423993%3删除临时文件575596%2统计完发现“查询订单”被误杀特别多。原因是上下文摘要截断策略有 bug把用户历史里的退款意图错误地带到了当前查询场景。修正截断逻辑之后准确率立刻上来了。在调整阈值时我也发现不要只看总准确率要分动作单独看。危险动作哪怕准确率 90% 都值得拦普通查询动作准确率不到 95% 就别上生产。5.2 上下文太长导致延迟爆表Jev 这类重模型对输入长度特别敏感。输入 8K token 可能只要 0.8 秒输入 32K token 可能要 3 秒以上。如果每次判断都塞完整对话延迟直接爆表Agent 体验接近不可用。我采用的截断策略分三层保留最底层的 system prompt里面写清楚任务边界。保留用户最初的那条原始指令这是目标一致性的锚点。保留最近 3 轮对话和当前动作相关的工具结果去掉历史里的无关中间过程。截断之后Jev 的输入长度稳定控制在 4K 到 6K token延迟下降了大半判断准确率反而提升了。原因是信息密度更高噪声更少。5.3 判断器自己也会产生幻觉模型判断器不是神它一样会一本正经地胡说八道。我遇到过 Jev 把一次正常的数据库查询判成“敏感操作”原因竟然是 prompt 里出现了“银行”两个字它自动关联到了金融风险。对抗幻觉的方法有三个。一是给评分标准加上严格定义比如“只有满足以下至少一项才允许 reject涉及资金变动、涉及删除/覆盖、涉及外发消息”。二是让模型输出 evidence必须引用具体上下文片段禁止空泛描述。三是做对抗测试上线前准备 100 条正常请求和 100 条恶意请求混在一起跑准确率达不到 95% 不上线。还有一招很实用在判断结果里加一个confidence字段。置信度低的判断结果不再自动执行而是进入人工队列。宁可多一次人工确认也不要放掉一次危险操作。5.4 边缘端部署的特殊问题在 Jetson Orin 上部署 Laya最痛苦的是从 PyTorch 格式转到 TensorRT 引擎。直接用开源的 GGUF 加载是能跑但推理速度一般跑不满 Orin 的算力。我后来用 TensorRT 重新编译图把延迟压到了 10 毫秒以内。RK3588 上的情况更麻烦。它的 NPU 工具链只支持特定格式转换过程容易出现算子不支持的问题。我的经验是先把模型在 CPU 上跑通验证输出结果没问题再切 NPU。不要一上来就做格式转换否则你分不清是模型效果差还是转换精度丢失。边缘端还有一个容易忽略的问题内存紧张。Q4 量化模型虽然小但推理时的临时变量、KV Cache、运行时框架都需要额外内存。8GB 内存的开发板如果同时跑 Agent、OCR、判断器很容易 OOM。解决办法是按优先级做内存预留或者直接用更小的量化档位比如 Q2_K但精度就不好说了。5.5 澄清一个概念harness 和 Agent 的区别和不少朋友交流时发现很多人把 Agent 和 harness 混为一谈。Agent 是指模型本身具备的推理和工具调用能力harness 是包在模型外面的一整套控制逻辑包括任务循环、上下文管理、工具管理、错误恢复。判断器天然属于 harness 层。它管的是 Agent 的行为不是模型的参数。想明白这一点你就能理解为什么判断器必须独立部署而不是把判断逻辑写进 system prompt。曾有人在 prompt 里写“不要调用危险工具”模型偶尔还是闯祸因为提示词对大模型来说是软约束而判断器是硬约束两者不在一个层级。6. 一个可以抄作业的最小接入模板6.1 目录结构篇幅有限我直接给一个最小可跑的工程结构你照着复制就能用。agent-judge/ ├── laya_client.py ├── jev_client.py ├── judge_gateway.py ├── main.py └── config.yamllaya_client 封装轻量判断器jev_client 封装重判断器judge_gateway 做分层路由main.py 起一个 FastAPI 服务config.yaml 放阈值和开关配置。整个工程不依赖任何特定 Agent 框架任何语言写的 Agent 都可以通过 HTTP 调用它。6.2 核心代码先看 judge_gateway 的核心逻辑class JudgeGateway: def __init__(self, config): self.laya LayaClient(config[laya_endpoint]) self.jev JevClient(config[jev_endpoint]) self.default_policy config.get(default_policy, reject) self.timeout config[timeout_seconds] def review(self, action, params, context_summary): try: quick self.laya.review( action, params, context_summary, timeoutself.timeout ) except TimeoutError: return self.apply_timeout_policy(action) if quick.label accept: return ReviewResult(allow, quick.score, quick.reason) if quick.label reject: return ReviewResult(deny, quick.score, quick.reason) # needs_review 时交给重判断器 deep self.jev.review(action, params, context_summary) return ReviewResult(deep.verdict, deep.confidence, deep.evidence)timeout 策略单独抽出来def apply_timeout_policy(self, action): if action in high_risk_actions: return ReviewResult(deny, 1.0, timeout_high_risk) if self.default_policy reject: return ReviewResult(deny, 1.0, timeout_default_reject) return ReviewResult(allow, 0.0, timeout_default_allow)main.py 里暴露一个 HTTP 接口app.post(/v1/review) def review(request: ReviewRequest): result gateway.review( request.action, request.params, request.context_summary ) return {verdict: result.verdict, reason: result.reason}Agent 框架只需要在工具调用前POST /v1/review拿到deny就阻止执行。整个接入成本很低不需要改 Agent 模型本身。6.3 上线前检查清单我把最后检查清单列在这里每一条都是踩坑换来的判断器超时后是拒绝还是放行按动作风险级别区分不能一刀切。判断器挂掉时有没有降级开关我建议默认降级为“人工确认”不要自动放行。每次判断结果是否完整落日志不落日志等于没做判断后面没法优化。是否有监控面板看拦截率、误杀率、延迟至少要有三个指标P50 延迟、拒绝率、人工升级率。有没有人工审阅入口needs_review 的判断结果必须能流转到人工系统。判断器 prompt 或模型升级后是否跑过回归测试别改完就上线前一天好用的模型可能第二天就抽风。个人在实际操作中的体会是判断器这东西真不是越重越好。先用规则加上 Laya 挡住八成明显的坑等业务复杂度上来、出现真正的多步冲突时再上 Jev 做深度评估既能控制成本又能把安全边界打磨得比较稳。最后分享一个小技巧把判断器的每一次决策都落成结构化日志攒一个月数据之后拿去做二次微调或者阈值优化效果比手动拍脑袋调参数好得多。