1. 一个Java老兵的困惑：为什么Agent越做越像八股文

做了快十年Java，从SSM一路写到Spring Cloud，中间穿插着搞过规则引擎、工作流引擎，也带过几个所谓的“AI中台”项目。这两年Agent概念火起来之后，我陆陆续续接触了不少Agent框架，从早期的ReAct模式到后来的Plan-and-Execute，再到各种多智能体协作的编排方案。说实话，看多了之后有一种很强烈的既视感——这不就是我们当年搞的BPMN加规则引擎吗？只不过把“审批节点”换成了“LLM调用”，把“决策表”换成了“Prompt模板”。

直到我认真研究了Jev这个模型的设计思路，才意识到自己之前的理解可能走偏了。Jev最让我震撼的一点是：它不生成文字。一个不生成文字的模型，凭什么能颠覆Agent架构？这个问题我琢磨了很久，也动手做了一些对比实验，下面把我从Java开发者视角看到的、想到的、踩过的东西，完整地聊一聊。

如果你是一个Java后端，正在琢磨Agent开发，或者你已经被各种LLM框架的抽象层搞得头晕，那这篇内容应该能帮你省下不少试错时间。我不会讲太多数学公式，更多是从工程落地的角度，把Jev为什么“不生成文字”这件事讲透，以及它对我们做Agent架构到底意味着什么。

2. 先搞清楚Jev到底在做什么：不生成文字的决策模型

2.1 从“生成”到“决策”的范式转换

我们平时用的LLM，不管是GPT系列还是各种开源模型，本质上是一个自回归生成模型——给定上文，预测下一个token的概率分布，然后采样输出。这个机制在做对话、写文章、翻译的时候非常好用，因为任务本身就是“生成一段合理的文本”。

但Agent场景下，我们真正需要模型做的是什么？是决策。比如：

• 当前这一步应该调用哪个工具？
• 这个工具的参数应该填什么？
• 任务是否已经完成，还是需要继续循环？
• 多个候选方案中，哪个优先级最高？

这些问题的答案空间是离散且有限的。调用哪个工具，无非就是工具列表里的某一个；参数填什么，往往是从上下文中抽取的实体；是否继续，就是一个二分类。用生成模型去处理这种离散决策问题，就像用大炮打蚊子——不是打不中，而是浪费了大量算力在“生成自然语言”这件无关紧要的事情上。

Jev的核心思路就是：把决策问题从生成任务中剥离出来，用一个专门的决策模型来处理。它不输出自然语言，而是输出结构化的决策结果——一个动作ID、一组参数、一个置信度分数。这个输出可以直接被Agent的执行引擎消费，不需要再做解析、不需要处理格式错误、不需要担心模型“胡说八道”。

2.2 为什么“不生成文字”这件事如此关键

我刚开始接触这个思路的时候，第一反应是：那不就是个分类模型吗？有什么稀奇的？但仔细想下去，发现事情没那么简单。

传统的分类模型只能处理固定类别、固定输入格式的任务。而Agent的决策空间是动态的——工具列表可能随时增减，上下文长度可能变化，任务目标可能多轮迭代。Jev要解决的是：在动态变化的决策空间中，如何稳定地输出可执行的决策结果。

它不生成文字，意味着几件事：

第一，输出格式天然合法。你不需要写正则表达式去解析模型输出，不需要处理“模型今天心情不好多打了一个括号”的情况。决策结果直接就是结构化的，执行引擎拿到就能用。

第二，推理延迟大幅降低。生成模型要一个token一个token地往外蹦，哪怕只生成一个JSON，也要几十个token的生成时间。而决策模型可以一次前向传播就输出结果，延迟从秒级降到毫秒级。

第三，决策空间可以动态扩展。工具列表变了？重新编码一下工具描述就行，不需要重新训练模型。这比让LLM记住新工具的用法要可靠得多。

第四，可解释性和可控性更强。决策模型输出的置信度分数可以用于路由——高置信度直接执行，低置信度转人工或者走兜底逻辑。这在生产环境里太重要了。

2.3 和RLHF、RLCD的关系：决策模型是怎么训出来的

这里就涉及到热词里提到的RLHF和RLCD了。RLHF（基于人类反馈的强化学习）大家比较熟，ChatGPT就是靠这个对齐的。但RLHF有个问题：它需要大量人类标注的偏好数据，成本高、周期长，而且对于决策任务来说，人类标注的“哪个决策更好”往往带有主观性。

RLCD（基于AI反馈的强化学习）则是一种更轻量的方案。它用另一个AI模型来提供反馈信号，不需要人类逐条标注。Jev的训练流程我理解大概是这样的：

1. 预训练阶段：用大量决策轨迹数据训练一个基础决策模型，让它学会在给定上下文和工具列表的情况下，输出合理的动作。
2. RLCD微调阶段：用模拟环境生成大量决策场景，让模型尝试不同决策，然后用一个奖励模型（可以是另一个LLM）来评估决策质量，通过强化学习优化决策策略。
3. 在线学习阶段：在实际运行中收集反馈信号，持续优化决策模型。

这个流程比纯RLHF要高效得多，而且特别适合Agent场景——因为Agent的决策结果是可以被环境验证的。工具调用成功还是失败，任务完成还是没完成，这些都是客观信号，不需要人类来主观判断。

3. Java开发者看Agent架构：我们到底在解决什么问题

3.1 当前Agent框架的“七宗罪”

我用过不少Agent框架，也自己动手写过编排引擎。总结下来，当前主流Agent架构有几个让我这个Java老兵很难受的地方：

第一，抽象层太厚。很多框架为了“通用性”，搞了一大堆抽象：Agent抽象、Tool抽象、Memory抽象、Planner抽象……结果就是你想改一个简单的行为，得翻好几层源码。Java的Spring已经够重了，但这些Agent框架比Spring还重。

第二，Prompt工程不可控。整个Agent的行为逻辑都藏在Prompt里，改一个标点符号可能就导致行为完全变化。这在生产环境里是灾难——你没法做单元测试，没法做回归验证，每次改Prompt都像在赌博。

第三，错误处理极其脆弱。LLM输出格式错误、工具调用失败、上下文超长……这些问题在Demo里可能不常见，但在生产环境里天天发生。而大多数框架的错误处理就是“重试”或者“让LLM自己修”，这在Java开发者看来简直不可接受。

第四，性能瓶颈明显。每一步决策都要调用一次LLM，一次调用就是几百毫秒到几秒。一个稍微复杂点的任务，十几步下来就是十几秒。用户等不起。

第五，状态管理混乱。Agent执行过程中的状态散落在各个地方——有的在Prompt里，有的在框架的上下文对象里，有的在工具返回值里。想做个断点续跑或者状态回滚，难如登天。

第六，可观测性差。出了问题之后，你只能看到一堆Prompt和Response的日志，根本不知道模型为什么做了这个决策。想加个监控指标都无从下手。

第七，测试困难。你没法像测试普通Java方法那样测试一个Agent的行为。输入相同，输出可能完全不同。这让CI/CD变得几乎不可能。

3.2 Jev带来的架构启示：把决策和执行彻底分离

Jev的设计思路给了我很大的启发。它本质上是在做一件事：把Agent架构中的“决策”和“执行”彻底分离。

在传统Agent架构里，决策和执行是混在一起的。LLM既负责“想”，也负责“说”——它输出一段文本，这段文本既包含了决策信息（调用什么工具），也包含了执行参数（工具入参），还包含了自然语言的解释。执行引擎需要从这段文本里“猜”出决策意图。

Jev的做法是：决策模型只负责“想”，输出结构化的决策结果；执行引擎只负责“做”，根据决策结果调用工具。两者之间通过一个明确定义的接口通信。

这个思路在Java世界里其实很常见——就是命令模式（Command Pattern）。决策模型是Invoker，执行引擎是Receiver，决策结果就是Command对象。只不过在Agent场景下，这个Command是动态生成的，而不是硬编码的。

这种分离带来的好处是显而易见的：

• 决策模型可以独立优化：不用管执行细节，专注提升决策准确率。
• 执行引擎可以独立扩展：新增工具只需要注册到执行引擎，决策模型通过工具描述感知。
• 测试变得可行：决策模型可以单独测试（给定上下文，输出决策），执行引擎也可以单独测试（给定决策，执行动作）。
• 性能可以分别优化：决策模型用GPU加速，执行引擎用传统后端优化。

3.3 一个具体的对比：ReAct vs Jev-style

为了更直观地说明问题，我拿ReAct模式和Jev-style架构做个对比。ReAct是当前最流行的Agent模式之一，它的核心循环是：

Thought: 我需要查一下天气 Action: get_weather Action Input: {"city": "北京"} Observation: 北京今天晴，25度 Thought: 我已经知道天气了，可以回答用户 Final Answer: 北京今天晴天，气温25度

这个循环里，LLM每一步都要生成一段文本，然后解析器从文本里提取Action和Action Input。问题在于：

• 解析器要处理各种格式变体，正则表达式越写越长。
• LLM有时候会“忘记”格式，输出一段自然语言而不是结构化内容。
• 每一步都要等LLM生成完整文本，延迟高。
• Thought部分虽然有助于推理，但也消耗了大量token。

Jev-style的做法是：

决策模型输入：当前上下文 + 可用工具列表 决策模型输出：{action_id: "get_weather", params: {city: "北京"}, confidence: 0.95} 执行引擎：调用get_weather("北京")，返回结果 决策模型输入：更新后的上下文 + 工具列表 决策模型输出：{action_id: "finish", params: {answer: "北京今天晴，25度"}, confidence: 0.98}

没有Thought，没有自然语言，没有解析器。决策模型直接输出结构化结果，执行引擎直接消费。整个流程干净利落。

当然，有人会说：没有Thought，模型的推理能力会不会下降？这个问题Jev的解决方案是：把推理过程内化到决策模型的隐层表示中。模型在训练时已经学会了“隐式推理”，不需要显式地生成Thought文本。这就像一个有经验的Java开发者，看到需求就能直接写出代码，不需要先在纸上画流程图。

4. 动手实践：用Java模拟一个Jev-style决策引擎

4.1 整体架构设计

光说理论没意思，我动手用Java写了一个简化版的Jev-style决策引擎。整体架构分三层：

• 决策层：负责调用决策模型，输出结构化决策结果。在实际生产中，这一层可以对接Jev模型，也可以先用一个规则引擎或者小模型模拟。
• 执行层：负责根据决策结果调用具体工具，管理工具注册和生命周期。
• 编排层：负责管理整个Agent的执行循环，处理状态、错误、超时等。

这个分层和Spring的Controller-Service-DAO三层架构很像，只不过把“业务逻辑”换成了“决策逻辑”。

4.2 核心接口定义

先定义决策结果的数据结构：

public class DecisionResult { private String actionId; // 动作ID，对应工具名或"finish" private Map<String, Object> params; // 动作参数 private double confidence; // 置信度 private String reasoning; // 可选：决策理由（用于调试） // getters and setters }

然后是决策模型的接口：

public interface DecisionModel { DecisionResult decide(AgentContext context, List<ToolDescriptor> tools); }

执行引擎的接口：

public interface ExecutionEngine { ToolResult execute(String actionId, Map<String, Object> params); void registerTool(Tool tool); List<ToolDescriptor> listTools(); }

编排器的核心循环：

public class AgentOrchestrator { private DecisionModel decisionModel; private ExecutionEngine executionEngine; private int maxSteps = 10; public AgentResult run(AgentContext context) { for (int step = 0; step < maxSteps; step++) { List<ToolDescriptor> tools = executionEngine.listTools(); DecisionResult decision = decisionModel.decide(context, tools); if ("finish".equals(decision.getActionId())) { return AgentResult.success(decision.getParams()); } if (decision.getConfidence() < 0.6) { // 低置信度，走兜底逻辑 return handleLowConfidence(decision, context); } ToolResult result = executionEngine.execute( decision.getActionId(), decision.getParams() ); context.addObservation(result); } return AgentResult.failure("超过最大步数"); } }

这个代码结构非常Java——接口清晰、职责分明、易于测试。你可以给DecisionModel写Mock实现，给ExecutionEngine写单元测试，整个Agent的行为变得可预测、可验证。

4.3 工具注册与描述生成

工具注册这块，我借鉴了Spring的Bean注册机制。每个工具实现一个Tool接口：

public interface Tool { String getName(); String getDescription(); Map<String, ParameterDescriptor> getParameters(); ToolResult execute(Map<String, Object> params); }

工具描述会自动生成，用于传给决策模型：

public class ToolDescriptor { private String name; private String description; private List<ParameterDescriptor> parameters; public static ToolDescriptor fromTool(Tool tool) { // 自动从Tool接口提取描述信息 } }

这里有个关键点：工具描述的质量直接影响决策模型的准确率。描述要清晰、参数要明确、边界要写清楚。我踩过的坑是：工具描述写得太模糊，导致决策模型经常选错工具。后来我把每个工具的描述都当成API文档来写，准确率明显提升。

4.4 决策模型的模拟实现

在没有Jev模型的情况下，我用一个简单的规则引擎模拟决策行为：

public class RuleBasedDecisionModel implements DecisionModel { @Override public DecisionResult decide(AgentContext context, List<ToolDescriptor> tools) { // 简化版：根据上下文关键词匹配工具 String lastObservation = context.getLastObservation(); for (ToolDescriptor tool : tools) { if (matches(tool, lastObservation)) { DecisionResult result = new DecisionResult(); result.setActionId(tool.getName()); result.setParams(extractParams(tool, lastObservation)); result.setConfidence(0.8); return result; } } // 没有匹配的工具，返回finish DecisionResult finish = new DecisionResult(); finish.setActionId("finish"); finish.setParams(Map.of("answer", context.getSummary())); finish.setConfidence(0.9); return finish; } }

这个模拟实现当然很粗糙，但它验证了架构的可行性。在实际生产中，你可以把这个RuleBasedDecisionModel替换成Jev模型，其他代码完全不用改。这就是接口分离的好处。

4.5 状态管理与上下文设计

AgentContext的设计我参考了Java的ThreadLocal和Spring的RequestContextHolder：

public class AgentContext { private String taskId; private String userInput; private List<Observation> observations; private Map<String, Object> variables; private long startTime; private int currentStep; public void addObservation(Observation obs) { this.observations.add(obs); this.currentStep++; } public String getLastObservation() { return observations.isEmpty() ? "" : observations.get(observations.size() - 1).getContent(); } public String getSummary() { // 生成上下文摘要，用于传给决策模型 } }

这里有个设计决策：上下文要不要做摘要？如果直接把所有历史Observation都传给决策模型，上下文会越来越长，决策延迟越来越高。我的做法是：保留最近N条Observation的完整内容，更早的做摘要压缩。这个N可以根据任务复杂度调整，一般5-10条比较合适。

5. 实操中的坑与经验：从Demo到生产还有多远

5.1 决策模型的冷启动问题

Jev模型虽然好，但训练它需要大量决策轨迹数据。对于刚起步的项目，没有足够数据怎么办？我的经验是：先用规则引擎+小模型混合方案过渡。

具体做法是：高频、固定的决策用规则引擎处理（比如“用户问天气就调天气工具”），低频、复杂的决策用小模型处理。同时，把所有决策轨迹记录下来，积累到一定量之后再训练专门的决策模型。

这个过渡方案的好处是：系统能先跑起来，同时数据也在积累。等数据够了，平滑切换到Jev模型。

5.2 工具描述的质量决定一切

我前面提过工具描述的重要性，这里再展开说一下。决策模型选错工具，90%的情况是工具描述写得不好。好的工具描述应该包含：

• 功能说明：这个工具是干什么的，一句话说清楚。
• 适用场景：什么情况下应该用这个工具。
• 不适用场景：什么情况下不应该用这个工具（这个很重要，但经常被忽略）。
• 参数说明：每个参数的类型、含义、是否必填、取值范围。
• 示例：一个典型的调用示例。

我踩过的坑是：两个工具的功能有重叠，描述又都写得很模糊，导致决策模型经常选错。后来我把两个工具的边界写清楚，准确率从60%提升到90%以上。

5.3 置信度阈值的调优

决策模型输出的置信度分数怎么用？我的经验是设置三档阈值：

这个阈值不是拍脑袋定的，要根据实际业务场景调整。比如金融场景可能要求置信度>0.95才执行，而内部工具场景0.7就可以执行。

5.4 错误处理与重试策略

Agent执行过程中出错是常态。我的错误处理策略分三层：

第一层：参数校验。决策模型输出的参数在执行前先做校验，类型不对、必填缺失的直接拦截，不浪费工具调用。

第二层：工具级重试。工具调用失败（比如网络超时），自动重试2-3次，指数退避。

第三层：决策级重试。如果工具调用失败是因为决策错误（比如选错了工具），把错误信息反馈给决策模型，让它重新决策。

这里有个关键点：重试要有上限。我见过有的系统无限重试，结果陷入死循环。我的做法是设置全局最大步数和最大重试次数，超过就终止并返回错误。

5.5 性能优化实战

性能这块我做了几个优化，效果很明显：

第一，决策模型批处理。如果多个Agent实例同时需要决策，可以把请求攒一批一起送给决策模型，GPU利用率更高。

第二，工具调用并行化。如果决策结果显示可以并行调用多个工具（比如同时查天气和查航班），就用CompletableFuture并行执行。

第三，上下文缓存。决策模型的输入上下文如果变化不大，可以缓存KV Cache，减少重复计算。

第四，决策结果缓存。相同的上下文和工具列表，决策结果应该是一样的，可以缓存起来直接复用。

实测下来，这几个优化加起来，端到端延迟从平均3秒降到了800毫秒左右。

5.6 可观测性建设

可观测性这块我借鉴了Java的Micrometer和Spring Boot Actuator：

• 决策指标：决策次数、决策延迟、置信度分布、工具选择分布。
• 执行指标：工具调用次数、成功率、平均耗时、错误类型分布。
• 业务指标：任务完成率、平均步数、用户满意度。

这些指标通过Prometheus采集，Grafana展示。有了这些数据，调优就有依据了。

6. 常见问题速查与避坑指南

6.1 决策模型相关

问题：决策模型总是选同一个工具怎么办？

这是典型的训练数据不均衡问题。解决方案是：在训练数据里增加其他工具的正样本，或者在推理时对高频工具做惩罚。我试过在置信度分数上乘以一个衰减因子，效果不错。

问题：决策模型对新增工具无感知怎么办？

Jev-style架构的好处就是新增工具不需要重新训练模型。你只需要把新工具的描述加到工具列表里，决策模型就能感知到。但如果新工具和旧工具功能相似，可能需要微调一下模型。

问题：决策模型输出的参数格式不对怎么办？

在决策模型和执行引擎之间加一层参数校验和转换。校验规则可以用JSON Schema定义，转换逻辑用策略模式实现。这样即使模型输出有点小问题，也能被修正。

6.2 执行引擎相关

问题：工具执行超时怎么处理？

设置合理的超时时间，超时后取消任务并返回超时错误。如果工具支持异步，可以用Future模式，超时后不阻塞主流程。

问题：工具之间有依赖关系怎么处理？

在决策模型层面处理。决策模型可以看到之前的Observation，根据依赖关系决定下一步调用哪个工具。执行引擎不需要知道依赖关系，只管执行。

问题：工具执行结果太长，上下文放不下怎么办？

对工具结果做摘要或者截断。摘要可以用小模型生成，截断要保留关键信息。我的做法是：结果超过一定长度就自动摘要，摘要后再放入上下文。

6.3 架构相关

问题：决策模型和执行引擎之间的接口怎么定义？

接口要足够简单，只包含决策必需的信息：actionId、params、confidence。不要在这个接口里塞太多东西，否则又变成紧耦合了。

问题：多个Agent实例如何共享决策模型？

决策模型可以部署为独立服务，通过gRPC或者HTTP调用。这样多个Agent实例可以共享同一个决策模型，提高利用率。

问题：如何做A/B测试？

把决策模型做成可插拔的，通过配置切换不同版本的模型。A/B测试时，一部分流量走旧模型，一部分走新模型，对比指标。

7. 我对Agent架构未来的一些个人判断

写了这么多，最后聊点个人看法。我在实际项目中最大的体会是：Agent架构的瓶颈不在模型能力，而在工程架构。现在大家都在卷模型参数、卷训练数据，但真正落地的时候，卡住你的往往是状态管理、错误处理、性能优化这些“脏活累活”。

Jev给我的启发不是“不生成文字”这个具体做法，而是它背后的架构思想：把复杂问题拆解成简单问题的组合。决策归决策，执行归执行，各司其职，通过清晰的接口通信。这个思想在Java世界里已经被验证了无数次——微服务、领域驱动设计、命令查询分离，本质上都是这个思路。

所以我觉得，Agent架构的未来大概率会走向“专业化分工”：决策模型专门做决策，执行引擎专门做执行，记忆模块专门做记忆，规划模块专门做规划。每个模块都可以独立优化、独立替换、独立扩展。而不是像现在这样，把所有东西都塞给一个LLM，让它既当大脑又当手脚。

对于Java开发者来说，这其实是个好消息。因为我们在构建可扩展、可维护、高可用的系统方面，有十几年的经验积累。这些经验在Agent时代不仅没有过时，反而会变得越来越重要。LLM负责“智能”，我们负责“工程”，两者结合才能做出真正能落地的Agent系统。

最后分享一个小技巧：如果你现在正在做Agent项目，不妨试试把决策逻辑从Prompt里抽出来，用一个独立的模块来处理。哪怕一开始只是简单的规则引擎，也能让你更清楚地看到系统的瓶颈在哪里。等决策模块稳定了，再考虑替换成Jev这样的专业决策模型。这个渐进式的路径，比一上来就追求“全LLM驱动”要靠谱得多。