Jev最佳实践：手把手教你改进现有工作流

摸鱼巨匠🔨·约 9 分钟阅读

2026年9月27日9月27日

文章目录

先说结论：Jev的出现，不是替代大语言模型，而是需要嵌入和改进原有工作流。

Jev 出现后，我把完整的工作流拆分成了以下四部分：

写计划、代码或文字等，继续交给 LLM；
选择下一步工作器、判断工具调用是否安全、筛选上下文等决策，交给专门的决策模型 Jev；
次数和费用上限等明确规则，则直接用代码处理；
由人工处理需要批准的操作，以及系统无法可靠判断的情况。

以下是结合我自己的经验写出的最佳实践指南。

一、先看清Agent究竟在做什么

假设你交给一个 agent 这样的任务：

搜集三款新 AI 智能体工具的资料，写一份明天的晨间简报，把草稿保存下来供我审阅。不要发布。

真正写简报之前，系统会反复遇到小判断：

来源够了吗？下一步由研究员还是撰稿员处理？某篇文章值得放进上下文吗？工具调用会不会造成不可逆修改？草稿到底存好了没有？

这些问题并不都需要生成一段文字。有些需要从候选项里选择，有些需要对相关性或风险评分，还有些只是“是／否”判断。

同时，“最多调用十次工具”“预算已用尽”“草稿文件是否存在”属于确定性规则，直接用代码判断即可。

把这些步骤混在同一个大模型调用里，LLM 也能做，但每次判断都可能携带额外的上下文、产生要解析的文本，并占用一次生成式模型的响应时间。

把任务拆分为以下几部分，分工会更清楚：

工作	合适的执行者	例子
开放式生成	LLM	制订计划、写简报、生成代码、填写网页文本
有边界的判断	Jev	选工作器、选操作、评估相关性、判断是否升级
确定性规则	代码和工具	预算上限、去重、保存文件、检查文件是否存在
有后果的授权	人工	发布、付款、对外发送或其他需审批的动作

二、决策层在Agent Loop中的位置

一套实用的 Loop 可以按如下顺序运行：

用户目标与约束

↓

生成模型规划任务

↓

代码读取当前状态，列出此刻真正可用的选项

↓

Jev 判断下一步与相关风险

↓

代码检查预算、权限和置信度阈值

↓

工作器或工具执行，并保存进度

↓

代码独立核验实际结果

↓

继续循环，或停在人工审核

以刚刚的晨间简报为例： Jev 可以决定把任务交给研究员、撰稿员或审核者；它的回答只是循环中的一次分派。

初次接入时，先让这个决定形成一份可查看的交接文件。等分派表现稳定，再让工作器领取任务、执行并返回结果。

这样可以逐步看清判断是否合适、任务是否执行、目标是否达成。

三、三种问题，组成大部分决策

Jev有 3 种问题类型：

Choice：从明确列出的候选项中选择，适合任务派工、模型路由或动作选择。

Score：按预设等级评价内容，适合资料相关性、紧急程度或风险评分。

Noul：回答是非问题，返回“是”的概率。

在实践中，Jev 的问题类型可以按答案的形状来选：

类型	适合的问题	返回结果
Choice	“下一步由谁处理？”“这属于哪个主题？”	选中的选项、各选项概率、置信度
Score	“这份资料有多相关？”“风险有多高？”	沿自定义档位的分数、概率分布、置信度
Noul	“是否需要人处理？”“是否涉及个人数据？”	“是”的概率，介于 0 与 1 之间

例如，系统判断晨间简报的例子中，可以定义三个 Choice 选项：

research：仍缺少完成目标所需的证据，继续收集资料；

write：已有足够证据，可以开始起草；

review：目标不清、超出范围，或工作已可交付审核。

选项名主要供程序读取；真正帮助模型区分情形的是选项描述。research 一词本身信息很少，“仍缺少完成目标所需的证据”则给出了可判断的边界。

Score 适合有顺序的档位。比如把检索资料分为 “不相关”、“只可作背景”、“直接回答问题”，结果就能用于选择保留全文、只保留摘要或丢弃。

Noul 则适合判断单一命题；如果你关心的是“风险有多高”，就不应把一个是／否概率误读为风险程度。

详细的可以查看下官方文档，Score 文档与 Noul 文档对这两种输出作了区分。

概率不能直接充当行动许可。 对于 Choice 和 Score，confidence 反映概率分布是否集中；对于 Noul，返回值就是“是”的概率，没有单独的 confidence 字段。
阈值应按错误后果设置。 低风险、可撤销的操作可以更积极；对外发布或资金操作应由明确政策和人工审批控制。

四、先做一个能保存交接任务的路由器

千万不要第一天上来就想着改造整个工作流！

我这里的建议是先从一个独立的小程序开始：输入目标和已完成工作，让 Jev 从研究、写作、审核三个去向中选择，再把选择写成 JSON 文件。这样可以先检查决策质量，再接入真正的工作器。

在晨间简报这个例子中，我挑选了一个最常重复的判断：资料还不够，就继续研究；资料够了，就开始写；目标不清或已经完成，就交给审核。

我把这一步单独写成一个小程序，先观察 Jev 的分派是否合理，再考虑连接研究和写作工作器。

import json
import os
from getpass import getpass
from pathlib import Path
from uuid import uuid4

from typesafe_sdk import Choice, TypeSafeClient

if not os.environ.get("TYPESAFE_API_KEY"):
    os.environ["TYPESAFE_API_KEY"] = getpass("TypeSafe API key: ").strip()

goal = input("任务目标：").strip()
if not goal:
    raise SystemExit("请先输入任务目标。")

completed_work = input("已完成工作：").strip() or "尚未开始。"
state = {
    "goal": goal,
    "completed_work": completed_work,
    "constraint": "保存草稿供审核，不要发布。",
}

with TypeSafeClient() as client:
    response = client.system_one(
        model="jev-latest",
        state=state,
        questions={
            "next_worker": Choice(
                instructions="为这项研究简报任务选择下一步。",
                criteria={
                    "research": "仍缺少完成目标所需的证据，继续收集资料。",
                    "write": "证据已经充分，开始起草简报。",
                    "review": "目标不清、超出范围，或工作已可交付审核。",
                },
            )
        },
    )

answer = response.answers["next_worker"]
destination = "review"
if answer.choice in {"research", "write"} and answer.confidence >= 0.85:
    destination = answer.choice

queue_dir = Path(__file__).resolve().parent / "queue" / destination
queue_dir.mkdir(parents=True, exist_ok=True)
job_path = queue_dir / f"{uuid4().hex}.json"
payload = {
    **state,
    "choice": answer.choice,
    "confidence": answer.confidence,
    "destination": destination,
    "status": "queued",
}
job_path.write_text(
    json.dumps(payload, ensure_ascii=False, indent=2),
    encoding="utf-8",
)
print("交接任务已保存：", job_path)

这个分流器的输入只有任务目标和已完成工作。我把两者连同“保存草稿供审核，不要发布”的约束交给 Jev，让它在 research、write、review 中选一个去向。

为了让不确定的判断停下来，我把默认去向设为 review：即使 Jev 选了研究或写作，只要置信度低于示例阈值 0.85，任务仍会进入审核目录。

然后，我让程序把目标、选择、置信度和最终去向写成 JSON 文件，放入 queue/research、queue/write 或 queue/review。这些目录目前只是本地待处理文件夹；这一步还不会启动工作器或生成草稿。 “不要发布”在这里是交给 Jev 的任务约束，真正的发布限制要在后续执行程序中实现。

验证这个例子时，我会用同一个目标做两轮输入：先写“比较三款 AI 智能体工具，准备晨间简报”，并注明“尚未收集来源”；再保持目标不变，把已完成工作换成具体的来源和研究结论，观察去向是否随证据变化。

运行后，程序会给出类似 “ queue/research/某个随机编号.json” 的文件路径。我不会只写“研究员已完成”，因为那是结论，无法让模型判断证据是否足够。

另外，代码中的 “0.85” 是我为了说明 “默认走审核” 设置的演示阈值，并不表示 85% 的准确率。真正接入工作流前，我会用已标注的历史任务检查哪些本应研究、哪些可以写作、哪些必须送审，再根据错分代价调整它。

五、从Demo到可长期运行的工作流

上一步结束后，我手里只有一份状态为 queued 的 JSON 文件。

要让它成为真正的工作流，还需要让研究和写作处理器分别领取对应目录中的任务，执行后把结果写回任务记录；进入 queue/review 的文件则交给审核环节。

每完成一步，再用更新后的状态决定下一步。这样，交接文件才从一次选择变成整个循环的起点。

仍以晨间简报为例，这个过程可以这样走：

Jev 判断资料不足，程序在 queue/research 中保存一份任务文件。
负责检索的程序读取这份文件，寻找三款工具的资料，并保存来源、价格和发现。它完成后，把这些结果加入任务记录。
我把更新后的任务记录再次交给 Jev。如果证据已经足够，Jev 可选择 write；负责写作的程序这时才开始起草，并保存草稿。
草稿生成后，程序检查文件是否真的存在，再把它交给人审核。只有经过另设的发布审批，内容才可能对外发布。

这个例子说明了为什么要反复更新任务记录。

这里我会写下 “已找到工具 A 和 B 的资料，仍缺工具 C 的价格”，让 Jev 根据事实判断下一步；如果只写 “研究完成”，它无法知道缺口是否仍在。

接入真实系统时，还有以下几项需要注意

选择前更新可用名单。如果检索程序正在忙，就不把它列为当前可用；网页点击后按钮变了，也应重新读取页面，再决定下一次操作。
防止重复执行并限制花费。程序要记录每项任务是否已领取、正在执行或已经完成；中断后先查上一步有没有成功，再决定是否重试。随机文件名只能避免重名，不能识别同一任务。调用次数、费用上限和发布权限也都由代码检查。
检查真实产出。Jev 选择 write，不等于草稿已经写出；写作程序报告“已保存”，也不等于文件一定存在。我会检查文件是否存在、内容是否非空，再让人看内容是否符合要求。Browser Use 也在模型选择 DONE 后独立核验页面结果。

等基本循环可靠之后，还可以把 “下一步交给谁”“任务是否紧急”“是否需要审核”这些读取同一份记录的问题放进一次 Jev 请求，由代码挑选当前需要的答案。如果后一个判断依赖刚获得的搜索结果，就先完成搜索，再发下一次请求。

六、决策层还能接入哪里

根据不同博主的实践，我总结了以下 11 类决策层可逐步接入的位置：

模型路由。根据当前任务选择足够胜任且成本合适的生成式模型。简单提取和复杂架构设计，不必始终交给同一档模型。
工具调用审查。 在运行命令或使用工具前判断风险，再由程序规则决定放行、阻止或请人确认。检查不能只看命令名称；可用时还应检查将被执行的文件内容。
上下文筛选。按当前目标评价历史消息、工具结果等片段的相关性，决定保留全文、简述或不再提供。这里判断的是“现在需要什么”，而不是一味把全部历史重写成摘要。
卡壳检测。定期检查近期行动是否在重复失败、是否真正接近目标，避免代理看似忙碌却持续消耗预算。
下一位工作者选择。在研究、写作、复核等处理者之间派工。
从实时菜单中选择动作。每轮都根据当前可用的工具、工作者或页面控件重新建立候选项。环境已变化时，沿用启动时的菜单会让判断失去意义。
完成判断。Jev 可以判断工作“看起来完成”，但程序还要独立检查交付物是否真实存在、内容是否达到基本要求。
升级人工处理。根据可逆性、费用、对外影响和不确定性决定是否停下来请人处理。涉及花钱或对外发布的规则，不应只靠模型置信度。
检索判断。在候选资料中评价哪些真正回答了问题，而不只依赖词语或向量相似度。
运行记录评估。回看已完成任务的操作记录，判断目标是否满足、路径是否浪费，以及错误来自选错工具、反复尝试、过早停止还是越界行动。
流程中的分类。将邮件、工单、文档或日志分到相应处理路径，并把不确定项目交给更强的模型或人工。