JEV 决策建模：让 AI Agent 从能跑到跑得稳的落地实践

1. 从一次深夜调试说起：JEV 到底解决了什么问题

第一次认真关注 JEV，是在一个多智能体协作项目的联调阶段。当时我们搭了一套基于 RAG 的代码辅助系统，三个 Agent 分别负责需求解析、代码生成和测试用例补全，单跑每个环节都没问题，串起来就出乱子——需求 Agent 把“用户登录后跳转个人中心”理解成了“登录接口返回用户信息”，代码 Agent 照着这个错误前提生成了一堆无用逻辑，测试 Agent 还煞有介事地给这些逻辑写了通过用例。整条链路跑完，表面上一切正常，实际上从第一步就偏了。

这个问题不是 RAG 检索不准，也不是模型能力不够，而是多个 Agent 之间缺少一个统一的决策语义层。每个 Agent 都在自己的上下文里做局部最优判断，但没有人负责把“当前任务到底要达成什么状态”这件事说清楚。后来接触到 JEV 这个概念，才意识到它要解决的核心问题就在这里：为 AI Agent 系统提供一个可共享、可推理、可追溯的决策模型层。

JEV 这个词在不同语境下有不同的展开方式，有人把它理解为 Joint Evaluation Vector，有人叫它 Judgment-Execution-Verification 循环，也有人直接把它当作一套决策建模框架的代称。不管具体展开是什么，它的核心指向是一致的：让 Agent 不只是“执行指令”，而是能在一个结构化的决策空间里判断“当前该做什么、为什么做、做完怎么验证”。这和单纯堆 Prompt、加工具调用完全不是一个层面的思路。

我写这篇东西，不是要做什么学术综述，而是把这几个月在几个实际项目里踩过的坑、试过的方案、以及 JEV 相关思路怎么落地，原原本本讲一遍。如果你正在搭 AI Agent、做 RAG 知识库、或者搞 AI Coding 辅助工具，尤其是遇到“单点能用、串起来就崩”的情况，这些内容应该能帮你省不少时间。

2. JEV 与 AI Agent 的关系：为什么不是又一个新概念

2.1 Agent 的“决策断层”问题

现在市面上讲 AI Agent 的文章很多，从 0 到 1 搭建 AI Agent 的教程也不少，但大部分都在讲“怎么让 Agent 调用工具”“怎么设计 Prompt 模板”“怎么接 RAG 知识库”。这些当然重要，但它们解决的是执行层的问题。真正让 Agent 系统在生产环境里跑不稳的，往往是决策层的缺失。

我举个实际例子。在一个 RAG 知识库项目中，用户问“上季度华东区的退货率是多少”。检索模块返回了三段内容：一段是退货政策说明，一段是华东区销售数据，一段是全国退货率统计。一个没有决策层的 Agent 会怎么做？它可能直接把三段内容拼在一起丢给 LLM，让 LLM“综合回答”。结果 LLM 要么把全国数据当成华东数据，要么把政策说明当成实际数据，要么直接说“根据提供的信息无法确定”——但明明第二段里就有华东区的原始数据。

问题出在哪？出在检索和生成之间缺少一个判断环节：当前检索到的内容是否足以回答问题？如果不足，是继续检索还是换检索策略？如果充足，哪段内容是直接证据、哪段是背景参考？这些判断不是靠一个更大的模型就能自动解决的，它需要一个显式的决策结构。JEV 在这个场景里的价值，就是把这个决策结构从“隐式的 Prompt 技巧”变成“显式的可复用模块”。

2.2 JEV 与 RAG、AI Coding 的交叉点

RAG 和 AI Coding 是目前 JEV 思路落地最密集的两个场景，原因很简单：这两个场景都涉及多步推理 + 外部信息引入 + 结果验证，天然需要决策层。

在 RAG 场景里，JEV 主要解决三个问题：检索时机决策（什么时候该检索、什么时候该直接回答）、检索结果评估（检索到的内容质量如何、是否足够）、生成策略选择（基于检索结果该用哪种生成方式）。传统 RAG 是“检索→拼接→生成”的固定流水线，Agentic RAG 则是在每个环节加入决策判断，而 JEV 提供的就是这个决策判断的建模框架。

在 AI Coding 场景里，JEV 的作用更明显。一个代码生成 Agent 不只是“根据需求写代码”，它需要判断：当前需求是否完整？如果不完整，是追问还是基于常见实践补全？生成的代码是否符合项目规范？如果不符合，是重写还是局部修改？这些判断如果全靠 LLM 的“直觉”，质量波动会非常大。JEV 的思路是把这些判断点显式建模，让 Agent 在关键节点上“停下来想一下”，而不是一路生成到底。

2.3 为什么是现在：从“能跑”到“跑得稳”的转折

JEV 相关讨论在最近几个月明显升温，我觉得和两个变化有关。一是 Agent 系统从 Demo 阶段进入生产阶段，大家发现“能跑”和“跑得稳”之间有一条巨大的鸿沟，而这条鸿沟主要卡在决策层。二是 RAG 技术本身在进化，从朴素 RAG 到 Agentic RAG 再到 GraphRAG、Ontology RAG，检索能力越来越强，但检索越强，对“什么时候该检索、检索什么、检索结果怎么用”的决策要求就越高。

还有一个很实际的推动因素：AI Coding 的普及。当越来越多团队用 AI 辅助写代码时，代码质量下降的担忧也随之而来。我见过不少项目，AI 生成的代码单看没问题，但放在一起就出现命名不一致、异常处理风格混乱、模块边界模糊等问题。这不是模型能力问题，而是缺少一个“代码生成决策规范”——什么情况下生成新模块、什么情况下复用已有代码、什么情况下应该拒绝生成并提示人工介入。JEV 的思路在这里可以直接套用：把代码生成过程中的关键决策点显式化、规范化。

3. 实战案例拆解：JEV 思路在三个项目中的落地

3.1 案例一：RAG 知识库的检索决策优化

这个项目是一个企业内部技术文档问答系统，知识库大概有 2000 多份文档，涵盖 API 文档、部署手册、故障排查记录。最初的方案是标准的 RAG 流水线：用户提问→向量检索 Top-K→拼接上下文→LLM 生成。上线第一周就发现两个典型问题：一是简单问题被复杂化，比如“如何重置管理员密码”这种有明确文档的问题，系统检索了 5 段内容，其中 3 段是无关的权限说明，LLM 反而被干扰；二是复杂问题被简单化，比如“生产环境数据库连接超时，可能原因有哪些”，系统只检索到一段泛泛的配置说明，LLM 就基于这一段编了一个答案。

引入 JEV 思路后，我们在检索和生成之间加了一个决策评估模块。这个模块不生成最终答案，只做三件事：判断问题类型（事实型、排查型、对比型、操作型）、评估检索结果覆盖度（是否包含直接答案、是否包含相关背景、是否完全无关）、决定下一步动作（直接生成、补充检索、换检索策略、提示信息不足）。

具体实现上，我们没有用复杂的模型，而是用一个轻量级的分类 Prompt 加规则引擎。问题类型判断用 Few-shot Prompt，覆盖度评估用检索分数加关键词匹配，下一步动作用一个简单的决策表。这个决策表的逻辑大概是：

这个决策表看起来简单，但效果非常明显。事实型问题的回答准确率从 72% 提升到 91%，排查型问题的“编答案”比例从 35% 降到 8%。关键不在于决策表本身多精妙，而在于把决策从隐式变成显式之后，每个环节的问题都能被定位和优化。

实操心得：决策表不要一开始就设计得太复杂，先从 3-4 个问题类型和 2-3 种覆盖度开始，跑一周看 bad case，再逐步细化。我见过有人一上来就设计 20 多个决策分支，结果维护成本比收益还高。

3.2 案例二：多智能体协作中的决策同步

第二个项目是一个多 Agent 协作的代码辅助开发系统，三个 Agent 分别负责需求分析、代码生成、代码审查。最初的架构是串行流水线：需求 Agent 输出需求文档→代码 Agent 根据文档生成代码→审查 Agent 检查代码。问题在前面已经提过：需求 Agent 的理解偏差会一路传递到最后。

我们尝试过让每个 Agent 都加一轮“自我验证”，但效果有限，因为每个 Agent 的验证标准是自己的上下文，它无法判断上游 Agent 的输出是否可靠。后来引入 JEV 的思路，在 Agent 之间加了一个共享决策状态。这个状态不是完整的上下文传递，而是一个结构化的决策记录，包含：当前任务目标、已确认的事实、待验证的假设、决策依据、置信度。

具体来说，需求 Agent 在输出需求文档时，必须同时输出一个决策状态，标明哪些需求是用户明确提出的（高置信度）、哪些是基于常见实践推断的（中置信度）、哪些是存在歧义的（低置信度）。代码 Agent 在生成代码前，先检查决策状态：如果有低置信度的需求项，它可以选择追问、或者基于最常见实践生成但标注风险。审查 Agent 则重点检查低置信度需求对应的代码实现。

这个改动带来的最大变化是：错误不再被静默传递，而是在每个环节都被显式标记和处理。需求 Agent 的“登录后跳转个人中心”被标记为低置信度后，代码 Agent 会追问“跳转是前端路由跳转还是后端重定向”，而不是自己猜一个。审查 Agent 也会重点检查这个跳转逻辑是否符合项目现有模式。

3.3 案例三：AI Coding 中的生成决策规范

第三个项目是一个前端代码生成工具，输入是设计稿描述或组件需求，输出是 React 组件代码。最初的版本是“给需求→出代码”，生成速度很快，但代码质量参差不齐。有的组件用了项目里已经废弃的旧版 UI 库，有的组件命名风格和项目不一致，有的组件没有处理边界情况。

我们后来制定了一套代码生成决策规范，本质上就是把 JEV 的思路应用到代码生成场景。规范的核心是三个决策点：

第一，复用决策。生成新代码前，先检索项目现有组件库和工具函数，判断是否已有可复用实现。如果有，优先复用；如果没有但类似，基于现有模式扩展；如果完全没有，才生成全新代码。这个决策靠一个检索加相似度判断模块实现，检索范围包括组件目录、工具函数目录、以及最近三个月的代码提交记录。

第二，风格决策。生成代码时，从项目配置中读取命名规范、目录结构、导入顺序、注释风格等约束，作为生成时的硬性条件。这些约束不是写在 Prompt 里让模型“尽量遵守”，而是作为后处理步骤，对生成结果进行格式化和校验。比如命名规范，生成后用 ESLint 自动修复；导入顺序，用 Prettier 自动排序；注释风格，用自定义规则检查。

第三，边界决策。生成组件时，必须显式处理空状态、加载状态、错误状态三种边界情况。这个决策不是靠 Prompt 提醒，而是在生成模板中强制包含这三个分支，模型只负责填充具体逻辑。如果模型判断某个边界情况不适用，必须输出理由，由人工确认。

这套规范落地后，生成代码的首次审查通过率从 45% 提升到 78%，返工率明显下降。更重要的是，代码风格一致性问题基本消失，因为风格决策被后处理步骤强制保证了。

4. JEV 落地的关键技术细节与参数选择

4.1 决策状态的表示与传递

JEV 思路落地的第一个技术问题：决策状态用什么格式表示、怎么在 Agent 之间传递。我们试过三种方案，各有优劣。

第一种是纯文本摘要。每个 Agent 输出一段自然语言描述，说明自己的决策依据和置信度。优点是实现简单，LLM 直接能读；缺点是结构不稳定，不同 Agent 输出的格式差异大，下游 Agent 解析成本高。

第二种是结构化 JSON。定义固定的字段：task_goal、confirmed_facts、assumptions、decision_basis、confidence。优点是结构清晰、易于程序化处理；缺点是 LLM 生成 JSON 时容易出错，需要额外的校验和修复步骤。

第三种是混合模式。核心决策字段用 JSON，补充说明用文本。JSON 部分只包含最关键的决策信息，文本部分提供上下文和解释。这是我们最终采用的方案，兼顾了结构稳定性和表达灵活性。

具体字段设计如下：

{ "task_goal": "当前任务的目标描述", "confirmed_facts": ["已确认的事实列表"], "assumptions": [ { "content": "假设内容", "confidence": 0.7, "basis": "假设依据" } ], "decision_basis": "本次决策的主要依据", "next_action": "建议的下一步动作" }

置信度用 0-1 的浮点数表示，0.8 以上为高置信度，0.5-0.8 为中置信度，0.5 以下为低置信度。这个阈值不是拍脑袋定的，是我们统计了 200 多个决策样本后，根据实际准确率反推的。高置信度决策的实际准确率在 92% 左右，中置信度在 75% 左右，低置信度在 50% 以下。

注意事项：置信度不要用 LLM 自己“感觉”的数字，要用可验证的指标反推。比如“检索结果包含直接答案”对应高置信度，“检索结果只有相关背景”对应中置信度，“检索结果完全无关”对应低置信度。这样置信度才有实际参考价值。

4.2 决策评估模块的实现方式

决策评估模块是 JEV 落地的核心组件，它负责在关键节点上判断“当前状态是否满足继续推进的条件”。实现方式有三种，适用于不同场景。

规则引擎方式：用 if-else 或决策表实现，适合决策逻辑明确、边界清晰的场景。比如 RAG 检索覆盖度评估，可以用检索分数阈值加关键词匹配来实现。优点是响应快、可解释、成本低；缺点是无法处理模糊情况，规则覆盖不到的场景会直接失效。

小模型分类方式：用一个轻量级模型（如 7B 参数的模型）做分类判断，适合决策逻辑复杂但判断标准相对固定的场景。比如问题类型判断，用 Few-shot Prompt 加小模型就能达到不错的效果。优点是泛化能力比规则强；缺点是需要额外的推理成本，且分类边界可能不稳定。

大模型推理方式：用大模型做开放式推理判断，适合决策逻辑复杂且需要灵活应对的场景。比如多 Agent 协作中的假设验证，需要理解上下文并做出判断。优点是灵活性强；缺点是成本高、速度慢、结果不稳定。

我们的实践是分层使用：能用规则解决的用规则，规则解决不了的用小模型，小模型也搞不定的才用大模型。这样在保证效果的前提下，把成本和延迟控制在可接受范围内。具体来说，RAG 检索覆盖度评估用规则，问题类型判断用小模型，多 Agent 假设验证用大模型。

4.3 决策日志与回溯机制

JEV 思路的一个隐性价值是可追溯性。传统 Agent 系统出问题时，你只能看到最终输出，中间发生了什么全靠猜。引入决策状态后，每个关键决策都被记录下来，出问题时可以回溯到具体环节。

我们的做法是：每次决策评估模块做出判断时，都记录一条日志，包含时间戳、Agent 标识、决策类型、输入摘要、输出决策、置信度、后续结果。这些日志存在一个独立的存储中，不参与主流程，但支持按任务 ID 或时间范围查询。

这个机制在排查问题时非常有用。有一次代码生成 Agent 连续生成了几个不符合项目规范的组件，我们回溯决策日志发现，风格决策模块读取项目配置时，配置文件路径写错了，导致读取到的是默认配置而不是项目配置。这个问题如果只看最终输出，很难定位到是配置读取环节的问题。

日志的另一个用途是决策质量分析。我们定期统计各类决策的准确率，找出低准确率的决策类型，针对性优化。比如发现“复用决策”的准确率只有 65%，进一步分析发现是相似度判断阈值设得太低，导致很多不相关的组件被判定为可复用。调整阈值后，准确率提升到 82%。

5. 常见问题与排查技巧实录

5.1 决策模块“过度决策”导致流程变慢

这是最常见的问题。引入决策评估后，每个环节都加判断，整体延迟明显上升。我们最初在一个 RAG 项目里加了 5 个决策点，平均响应时间从 1.2 秒涨到 3.8 秒，用户明显感知到卡顿。

排查下来发现，有些决策点其实可以合并或跳过。比如“问题类型判断”和“检索策略选择”可以合并成一个决策，因为问题类型直接决定了检索策略。另外，对于高置信度的简单问题，可以跳过部分决策点，直接走快速路径。

优化后的策略是：决策点分级。一级决策点必须执行，二级决策点根据一级决策结果决定是否执行，三级决策点只在特定条件下执行。这样在保证关键决策质量的前提下，把平均响应时间压回 1.8 秒左右。

5.2 决策状态在 Agent 间传递时“信息衰减”

多 Agent 协作时，决策状态经过多次传递后，信息会衰减。上游 Agent 标记的低置信度假设，传到第三个 Agent 时可能被当成确定事实。这个问题在串行流水线中特别明显。

我们的解决方案是：决策状态不传递，只传递决策日志的引用。每个 Agent 不直接读取上游的决策状态，而是通过任务 ID 查询完整的决策日志。这样每个 Agent 看到的都是原始决策记录，不会因为中间环节的转述而失真。

另外，在关键决策点上，下游 Agent 必须显式确认“已读取上游决策日志”，并在自己的决策状态中引用上游的决策 ID。这样形成一条完整的决策链，任何环节出问题都能追溯到源头。

5.3 决策评估模块本身出错怎么办

决策评估模块也不是万能的，它自己也会出错。比如问题类型判断错了，后续所有决策都会跟着错。我们的处理方式是：决策评估模块的输出必须带置信度，低置信度的决策触发人工确认或降级处理。

具体来说，如果决策评估模块的置信度低于 0.6，系统不会直接执行该决策，而是走一个降级路径：要么用更保守的策略（比如直接返回“信息不足，建议人工确认”），要么触发人工审核。这个机制在早期阶段会降低自动化率，但能有效避免“错误决策被静默执行”的问题。

还有一个技巧是决策评估模块的 A/B 测试。对于关键决策点，同时跑两个不同版本的评估逻辑，对比输出差异。如果差异大，说明决策逻辑不稳定，需要进一步优化。我们在一开始做问题类型判断时，用两套不同的 Prompt 同时跑，发现 15% 的样本判断结果不一致，分析后发现是 Few-shot 示例覆盖不全导致的，补充示例后不一致率降到 4%。

5.4 常见问题速查表

实操心得：决策日志的存储策略很关键。我们一开始全量记录，一个月就存了 200 多万条，查询变慢。后来改成“关键决策全量记录，非关键决策按 10% 采样”，存储量降到 30 万条，查询速度恢复正常，且不影响问题排查。

6. 从 JEV 视角看 AI Agent 开发的几个认知转变

6.1 从“让模型更聪明”到“让决策更清晰”

刚开始做 Agent 时，遇到效果不好，第一反应是换更大的模型、加更多的 Prompt 示例、调更高的 temperature。后来发现，很多问题的根源不在模型能力，而在决策结构。模型再聪明，如果决策点没设计好，它也不知道该在什么时候做什么判断。

JEV 思路带来的最大认知转变是：与其让模型在模糊的指令下“猜”，不如把决策点显式化，让模型在明确的判断节点上做选择。这就像带新人，你告诉他“把项目做好”，他可能无从下手；你告诉他“先检查需求文档是否完整，如果不完整就追问，如果完整就按模块拆分”，他就能一步步推进。

6.2 从“端到端优化”到“分段优化”

传统 RAG 或 Agent 系统喜欢讲“端到端优化”，但实际做下来，端到端优化很难定位问题。JEV 思路强调把流程拆成决策段，每段独立评估和优化。这样虽然看起来不够“优雅”，但实际效果更好，因为每个环节的问题都能被单独发现和解决。

比如 RAG 系统，拆成“检索决策段”“覆盖度评估段”“生成策略段”后，我们可以分别统计每段的准确率，针对性优化。检索决策段准确率低，就优化检索策略；覆盖度评估段准确率低，就调整评估规则；生成策略段准确率低，就改进生成 Prompt。这种分段优化的效率比端到端调参高得多。

6.3 从“追求全自动”到“接受人机协同”

JEV 思路落地后，一个自然的结论是：不是所有决策都适合自动化。低置信度的决策、涉及高风险操作的决策、边界模糊的决策，都应该触发人工确认。这不是系统能力不足，而是合理的风险控制。

我们在代码生成项目中就设置了几个强制人工确认点：生成全新模块时、修改核心工具函数时、涉及权限或支付逻辑时。这些确认点会增加人工成本，但避免了更大的返工成本。实际跑下来，人工确认的比例大概在 15% 左右，但代码审查通过率提升了 30% 以上，整体效率反而是提升的。

7. 几个可以直接抄作业的落地建议

如果你正在做 AI Agent 或 RAG 项目，想试试 JEV 思路，我建议从最小可行的决策点开始。不要一上来就设计完整的决策框架，先找一个当前最痛的环节，加一个决策评估模块，跑一周看效果。

具体来说，RAG 项目可以从“检索覆盖度评估”开始，判断检索结果是否足以回答问题，不足时触发补充检索或提示信息不足。AI Coding 项目可以从“复用决策”开始，生成代码前先检索现有实现，避免重复造轮子。多 Agent 项目可以从“决策状态共享”开始，让每个 Agent 输出结构化的决策记录，下游 Agent 读取并确认。

决策状态的格式不用太复杂，一开始用 JSON 加文本混合模式就够了。置信度用可验证的指标反推，不要用模型自己“感觉”的数字。决策日志一定要记，但不用全量记，关键决策全量、非关键决策采样就行。

最后分享一个我踩过的坑：不要试图用 JEV 思路解决所有问题。有些场景就是简单的“输入→输出”，加决策层反而增加复杂度。判断标准很简单：如果这个场景的 bad case 主要是“执行错误”而不是“决策错误”，那优化执行层就够了，不需要引入决策层。只有当 bad case 的根源是“不知道该做什么”或“做了不该做的事”时，JEV 思路才真正有价值。