## 先说一个很具体的场景

我有一批评论要处理，50 条。需要判断三件事：这条是不是在提问、该归到哪一类、回复的紧急程度。

放进 agent 里，最直接的做法是把 50 条原文全贴进对话，让它读一遍给我答案。它做得对，但代价是这个——

**那几万字从此就留在对话历史里了。**

不是这一次付费的问题。是此后每一轮对话，我都在为这 50 条原文再付一次费。我后来只是接着追问一句「那第二条为什么判成售后」，模型还得把那一大坨重新过一遍。

这件事让我意识到：**我一直在用同一个模型，干两种完全不同性质的活。**

## 生成和判断，本来就是两种活

> 把这 50 条评论总结成一段话 —— 这是**生成**。
> 这 50 条里哪些需要回复 —— 这是**判断**。

生成需要模型逐字写出来：慢、贵，吐出来的是自由文本，你还得写正则去解析它。

判断要的只是**结论**，而且结论天生有结构：选哪一个、是不是、打几分。

过去的默认做法是这两件事共用一个模型、共用一条链路。但这不是必然的。判断这件事，完全可以挪出去。

## Jev：一个只判断、不生成文本的模型

TypeSafe 有一个叫 **System One** 的模型族，其中的 **Jev** 只做判断。你给它一段状态和一个问题集，它一次并行返回**类型化答案 + 校准概率**：

| 原语 | 问什么 | 你拿回什么 |
| --- | --- | --- |
| `choice` | 从一组选项里挑一个（最多 255 个） | 选中项 + 置信度 + 各项概率 |
| `score` | 在一把有序标尺上打分（2–10 档） | 分数（可以落在档位之间）+ 概率分布 |
| `noul` | 某件事成立的概率 | 一个 0–1 的概率 |

关键在于**它的输出是 schema，不是文本**。你的代码直接读字段名，不用解析、不用担心它今天忘了加引号。

单个判断的输入量很小（约 400 token），而且结论一旦拿到，原文对主模型来说就没用了。

## agent-jev：让 agent 自己想起来用它

Jev 是个服务，agent-jev 解决的是**怎么让 agent 用上它**——而且是它自己想得起来用，不是我每次都手动去调。

![fig1-architecture.png](https://developer.qcloudimg.com/http-save/yehe-12564146/0261b41d76b071479f6cb33f2aa778dc.png)

链路很直白，但下面这几处我不想含糊过去。

### 一、批量模式才是收益的大头，不是单次判断

单次判断当然也省，但真正的量级差在批量场景。看这张对比：

![fig2-batch-token-flow.png](https://developer.qcloudimg.com/http-save/yehe-12564146/1784ac8639b074078b39221a36300867.png)

左边和右边**都能拿到那 50 行结论**。区别在第 4 步：左边把几万字永久留在了对话里，而且此后每一轮都在为它付费；右边的原文自始至终躺在磁盘上的一个 JSON 文件里，从没进入过对话。

`jev.py` 干的事就是：读文件、批量提问、只 `print` 结论。省 token 的不是模型有多便宜，**是「什么东西留在了上下文里」**。

### 二、技能接不住的那一半

这里我要先纠正自己一个判断。

我最初的想法是「做成技能，不做 hook」，理由还写在当时的笔记里：判断下沉是 agent 主动发起的动作，而 hook 是在工具调用发生那一刻才醒过来的，它看不见 agent 的意图——所以 hook 接不上。

**这个结论是错的。**

后来我把 ZCode 的 hook 事件表读全，发现漏了两个，而它们恰好就是我一直想要的那两个位置：

| 事件 | 触发时机 | 能做什么 |
| --- | --- | --- |
| `PostToolUseFailure` | 工具**失败之后** | 追加「恢复建议、诊断或重试约束」 |
| `Stop` | 模型**准备收尾时** | 返回 `block` 可以让主循环**继续一轮**（官方最多连续 3 次） |

我当时只看了「工具调用前后」，完全没想到**失败之后**和**收尾时刻**也是钩子点。

**但技能也没做错——这两层管的是不同的判断：**

| | 技能 | hook |
| --- | --- | --- |
| 管什么 | agent **主动发起**的判断 | agent **不一定想得起来**的判断 |
| 例子 | 归类、初筛、打分、批量核查 | 工具失败怎么处置、这轮算不算真做完 |
| 谁决定调用 | agent 自己 | 宿主在固定位置**必然触发** |

**「agent 想不起来做、但又该做」的事，才是 hook 真正的位置。** 失败分诊和收工核验恰好都是这一类——每个 agent 都该做，但没一个会记得做。

### 三、和其他做法比，它差在哪

这一步值得掰开讲，因为「判断」这件事有四条路，各有各的代价：

| 做法 | 代价 |
| --- | --- |
| **写死规则 / 正则** | 便宜、快、可解释。但语义一变就废——「这条评论是不是在投诉」这种问题，正则永远写不全 |
| **让主模型顺手判** | 不用额外集成，写进 prompt 就行。但原文全留在上下文里，而且此后每轮都在付费 |
| **自己调一个大模型来判** | 灵活。但为了「选一个桶」跑一次完整推理，又慢又贵，还要解析它吐出来的文本 |
| **用 Jev 这类判断模型** | 输出结构化、不生成文本、单次输入很小。代价是你得接受一个新依赖，而且它只能判断、不能兜底 |

我的取向很简单：**能用规则解决的，用规则；规则解决不了的语义判断，交给判断模型。** 不要为了省事把两种活都塞给主模型。

## 装起来是什么样

![shot1-repo-files.png](https://developer.qcloudimg.com/http-save/yehe-12564146/c4c9bbd43156b000f00f99b0fe443a55.png)

Windows 用 `install.ps1`，Linux / macOS 用 `install.sh`，两个脚本做同一件事：把技能装到 `~/.agents/skills/agent-jev/`、引导写入密钥、跑一次冒烟测试。幂等，重复执行结果一致。

装完就能在终端里直接调：

```bash
python ~/.agents/skills/agent-jev/jev.py request.json
```

请求体长这样——一段 `state`，加上一组问题：

```json
{
  "state": {"ticket": {"text": "...", "customer": "..."}},
  "questions": {
    "category":  {"type": "choice", "instructions": "该派给哪个团队？",
                  "criteria": {"network": "...", "app": "..."}},
    "is_urgent": {"type": "noul", "instructions": "是否紧急？"},
    "frustration": {"type": "score", "instructions": "客户愤怒程度",
                    "criteria": ["平静", "不满", "愤怒"]}
  }
}
```

多个独立问题合并进一次请求，并行执行，几乎不增加延迟。`examples/comment_triage.py` 是批量初筛的完整例子。

整个调用器是**纯标准库、零依赖**的——没有 requests，没有 SDK，一个 Python 文件。

## 第二种形态：把「想不起来」的那一半也接上

技能那一半跑通之后，我把 hook 那一半也做了。现在这个项目有两种接法，共用同一份调用器：


两个 gate，各挂在一个 hook 事件上：

| gate | 挂在哪 | 做什么 |
| --- | --- | --- |
| **失败分诊** | `PostToolUseFailure` | 把报错喂给 Jev 判「该怎么处置」，**只追加一句结论**给主模型；同类失败第 3 次起额外劝阻原样重试 |
| **收工核验** | `Stop` | 判这轮是否「声称完成却没给验证证据」，是就打回一轮让它补验证 |

### 两处我一开始就想错了的地方

**一、钩子坏了必须「无害」，而不是「可见」。**

钩子是基础设施，不是功能。它自己崩了，绝不该让工具调用跟着崩。所以 `jev_hook.py` 里所有异常路径都是 `exit 0` + 空 stdout——宁可什么都不做，也绝不因为钩子故障卡住宿主。这是硬规则，不是尽力而为。

**二、只用 socket 超时兜不住上界。**

这条是踩出来的。`urllib` 的 `timeout` 按**每次 socket 操作**各自计时（连接一次、读一次），实测墙钟约为它的 1.5 倍，重试还会叠加。我一开始用 `15s × 2 次`，想着最坏 30 秒——结果网关挂死时一次调用烧掉 **42.9 秒**，已经超过宿主的 8 秒钩子上限，会被直接砍掉。

正解不是调大数字，是**换机制**：把整次调用丢进守护线程，按一个硬总预算 `join`，到点就放弃。

改完之后的实测（20 次采样）：

| 指标 | 值 |
| --- | --- |
| Jev 判定成功 | 17/20 = **85%** |
| 墙钟中位 | 1.46s |
| 墙钟最慢 | **6.13s**（上限 8s，未超） |
| 正常路径 | 1.27 ~ 2.47s |

剩下那 15% 是网关偶发的 SSL 握手挂死（单次能长挂 20~28s），这是网关侧的问题，钩子层修不了。所以设计成**失败静默**——什么都不输出，工具调用照常继续。

### 装上之后，我留了观测文件

钩子最大的问题是**它是个黑盒**：你根本不知道它有没有在干活。所以我让它把每次判断都记一笔：

```
plugins\data\agent-jev-hooks@...\
├── failure_counts.json   失败指纹计数
├── stop_checks.json      收工核验的次数与打回次数
└── debug_samples.json    仅调试开关打开时：指纹 -> 报错头 80 字符
```

真实跑下来的一周记录：

| 会话 | 不同失败指纹 | 重复告警 |
| --- | --- | --- |
| …99eda5ec… | 2 | 某指纹出现 **3 次** |
| …04cefd85… | 2 | 某指纹出现 **7 次** |
| 另外 2 个会话 | 各 1–2 | — |

**同一个失败指纹在 3 个会话里累计出现 11 次。** 这条数据比「hook 省了多少 token」更值得看——它说明那是个**该直接修根因**的问题，而不是靠钩子每次提醒「别原样重试」。

## 问题怎么设计，才不容易翻车

用下来我觉得这一段比安装重要得多。判断模型的能力是有边界的，边界之外它会给你一个看起来很确定的错答案。

**`state` 要给够。** 判断的质量取决于你喂进去的信息。多部分上下文用命名字段而不是拼一大段字符串：

```json
"state": {"ticket": {"text": "...", "customer_level": "VIP", "opened_hours": 30}}
```

嵌套字段可以用反引号路径在问题里引用，比如 `` `ticket.text` ``。

**判断写在 `instructions`，可能答案写在 `criteria`。** 这两个字段各管一件事，别混着写。

**一个问题只问一件事。** 「这条是咨询还是售后、急不急」应该拆成两个问题。拆开之后你还能分别设阈值、分别复用。专家凭直觉几秒能答的，才是它擅长的粒度。

**提问的 key 只给代码用，模型看不见它。** 所以问题的完整含义必须在 `instructions` 里说清，不能指望 key 名去暗示。

**`choice` 的选项要互斥，并且留一个兜底项。** 如果实际答案落在你给的选项之外，模型不会告诉你「都不像」，它只会在给定选项里挑一个最接近的。所以该有个 `other` / `unknown`。

**`score` 的档位要能独立成立。** 写「差 / 中 / 好」不如写「无法使用 / 偶尔出错 / 稳定可用」——后者每一档都能单独判断，不用互相比较。

## 几个真实的坑

这些不是猜的，是踩出来的：

| 症状 | 原因 |
| --- | --- |
| Python 直连报 `HTTP 403` | 网关 WAF 拦裸 urllib UA，必须带一个正常 UA |
| 之前能用的 payload 突然 `HTTP 500` | 网关偶发瞬时故障（1 秒内快速失败），重试 1–2 次即可 |
| Windows 下 `surrogates not allowed` | GBK 管道污染，得读 `sys.stdin.buffer` 自己按 UTF-8 解 |
| 密钥正常却 `HTTP 401` | 模型名写错了 —— 这个报错很容易让人去查密钥，其实是名字问题 |

前两条和第四条都已经内置在 `jev.py` 里了。

## 它不适合什么

这一点我想说清楚，免得有人用错了地方：

- **不要用它生成文字或代码。** 它不生成，只判断。
- **不要用它做需要跨多轮上下文综合的决策。** 它是无状态的——你喂什么它看什么。
- **一次性的琐碎判断别绕这一圈。** 你顺手就能定的事，调用一次反而更慢。
- **别拿它当业务分类的通解。** 它擅长「有明确选项、专家一眼能答」的判断；开放式的语义归类仍然要靠主模型。

## 最后

我做这个项目，起因特别简单：我发现自己花了不少钱，让一个很擅长生成和推理的模型，去做「这条评论归哪一类」这种它其实只需要看一眼就能答的事。

判断和生成分开之后，主模型可以专心做它擅长的长链推理和代码，而那些高频的、结构化的、有明确答案的小判断，走一条更便宜的通道。

项目地址：<https://cnb.cool/apigogo/agent-jev>（MIT）

---


我有一批评论要处理，50 条。需要判断三件事：这条是不是在提问、该归到哪一类、回复的紧急程度。

别让主模型做分类：给 agent 装一个判断层——agent-jev

人工智能

开发工具

后端

判断与生成分离：agent-jev通过Jev模型实现结构化判断，单次仅需400token，批量处理50条评论时原文不进入对话上下文，节省重复token成本。支持choice/score/noul三类输出，配合技能与hook双形态，含失败分诊与收工核验，实测中位延迟1.46s，异常静默处理不阻塞主循环。

代码解释

Windows

Python

Linux

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

别让主模型做分类：给 agent 装一个判断层——agent-jev-腾讯云开发者社区-腾讯云

别让主模型做分类：给 agent 装一个判断层——agent-jev

别让主模型做分类：给 agent 装一个判断层——agent-jev

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐