上次做 Jev AI Playground 时，我一直在想一个问题： Jev 这种 decision model 真正接进 Agent 后，能不能减少 LLM 在信息不确定时擅自做决定？ 后来我把它接进了一个 AI 日程助手，专门做了一轮对照实验。 一个典型场景： “我 8:00 就到单位，具体讨论时间看您方便即可。” 这里 8:00 是到单位的时间，不是双方已经确定的会议时间。 我测试了三个 workflow： A：现有流程 原来的 time guard + LLM 。 B：改善上下文 不加 Jev ，只解决原流程中过早切割上下文的问题。 C：B + Jev 在 B 后增加 Jev ，进一步判断 action 、time role 、time of day 、relation 、date basis 。 48 个独立 case family 的结果： Workflow Exact match Action match A：现有流程 42/48 42/48 B：改善 context 46/48 46/48 C：B + Jev 38/48 39/48 结果和我最初的预期相反：改善原 LLM 的 context ，比增加 Jev decision layer 效果更好。 在 24 个 holdout case 里，B 是 23/24 ，B + Jev 是 17/24 。这次集成中，Jev 没有修正 B 的错误，反而在 B 原本匹配的 case 中增加了 8 个 mismatch 。 粘贴的 Markdown (1) 复盘以后，我觉得问题不应该简单归结成“Jev 有没有用”。 我们这次 C 一次让 Jev 判断了 action 、时间角色、时段、relation 、date basis 等多个东西，而且直接采用这些判断，没有做 calibrated abstention / fallback 。这实际上是一个耦合比较重的 integration 。 粘贴的 Markdown (1) 如果再做下一轮，我会先把 decision 缩得非常窄，比如只问： “这段消息是否明确确定了双方约定的会议开始时间？” 而不是再让第二个模型重新判断整个 Agent 应该做什么。 另外多一层模型确实也增加了 latency： Better context：p50 4.32s / p95 7.54s Better context + Jev：p50 5.20s / p95 8.43s 所以目前我的实践结论更接近： 先把 evidence / context flow 做对，再判断 Agent 里是否真的存在一个足够窄、值得交给 decision model 的判断点。 完整实验、失败案例、成本、延迟和下一步准备怎么测，我都整理在这里： Does Jev Improve an AI Scheduling Agent? A Three-Arm Test https://tryjevai.com/blog/jev-ai-agent-scheduling-test 想听听也在做 Agent / Workflow 的人的经验： 你们处理“信息其实不够，但 LLM 已经准备执行”的情况，一般是 prompt 、rule/validator ，还是单独增加 decision model ？

  • 情报分类：技术学习与提效
  • 分类依据：内容涉及技术、AI、软件工具或工程实践
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/10/8 15:36:52