告别文字解析：Jev如何用结构化决策重构Agent架构

1. 一个Java老兵的困惑为什么Agent总在“说废话”我第一次接触Agent这个概念的时候脑子里想的是这不就是个高级版的状态机吗我写了十年代码从Servlet到Spring Boot从JDBC到MyBatis什么流程编排没见过。状态流转、条件分支、异常兜底这些东西在Java世界里早就被抽象得明明白白。但当我真正开始用LLM驱动的Agent框架去搭东西的时候我发现事情不对劲了。最让我抓狂的一点是几乎所有的Agent框架都在让模型“生成文字”。你问它一个问题它输出一段文字你让它调用工具它输出一段JSON你让它规划下一步它输出一段自然语言描述。然后框架再拿这段文字去解析、去匹配、去执行。整个链路里模型的核心动作就是“说话”而框架的核心工作就是“听懂它在说什么”。这就有问题了。做过Java服务端开发的人都知道让一个不可靠的组件承担核心决策职责是架构设计的大忌。LLM的输出天然具有不确定性同样的输入可能产生不同的措辞同样的意图可能用完全不同的句式表达。你让这样一个组件去决定“下一步该调用哪个工具”“该传什么参数”然后靠正则或者JSON parser去提取这跟用字符串匹配做路由有什么区别我踩过的坑包括但不限于模型输出了合法的JSON但字段名跟预期不一致模型在JSON外面包了一层“好的我来帮你调用”的前缀模型把参数值写成了自然语言描述而不是结构化数据模型在应该返回单个工具调用的时候返回了三个在应该返回三个的时候只返回了一个。每一次出问题你都得去调prompt加few-shot示例加格式约束加后处理逻辑。你花在“让模型好好说话”上的时间比花在业务逻辑上的时间还多。直到我看到了Jev这个思路才觉得有人真的想明白了这件事。2. Jev到底在做什么不生成文字的决策模型2.1 核心思路拆解Jev的核心主张可以用一句话概括决策模型不应该生成自然语言而应该直接输出结构化的决策信号。什么意思传统的Agent架构里决策层和执行层之间是通过“文字”来通信的。模型说“我需要查询天气”框架解析出“查询天气”这个意图然后映射到对应的工具。Jev的做法是决策模型直接输出一个决策向量或者决策编码这个编码直接对应到具体的动作空间不需要经过自然语言的中间层。打个比方。传统Agent就像你让一个翻译官帮你点菜你用中文说“我想吃辣的”翻译官翻译成英文告诉服务员服务员再理解。Jev的做法是你直接指着菜单上的图片说“这个”不需要翻译。这个思路在Java开发者看来其实非常熟悉。这就是接口契约的思想。传统Agent的决策层和执行层之间的接口是“自然语言”这是一个极其模糊、极其不稳定的契约。Jev把这个契约改成了“结构化决策信号”这是一个明确的、可验证的、类型安全的契约。2.2 为什么Java开发者应该关注这个你可能会问这跟我写Java有什么关系关系大了。Java生态里有一套非常成熟的接口驱动设计方法论。我们定义Service接口定义DTO定义枚举定义状态机。这些东西的本质是什么是把不确定性约束在最小的范围内。Jev的思路本质上就是把Agent架构里的不确定性从“决策层和执行层的通信”这个环节移除掉。决策模型内部可以是不确定的但它输出的东西必须是确定的、结构化的、可直接消费的。这跟我们在Java里做的一样Controller层可以处理各种奇怪的HTTP请求但它调用Service层的时候传的参数必须是类型安全的DTO。而且Jev的决策模型不生成文字意味着推理成本大幅降低。生成文字需要自回归地一个token一个token往外蹦而输出一个决策信号可能只需要几个token甚至可以直接通过分类头输出。这对于需要高频决策的Agent场景来说延迟和成本的优化是数量级的。3. 传统Agent架构的“文字依赖”到底卡在哪里3.1 文字作为中间表示的三大原罪我梳理了一下传统Agent架构里用自然语言作为决策层和执行层之间的中间表示至少有三大问题。第一解析成本高且不可靠。模型输出一段文字你得写parser去解析。JSON parser算是好的至少格式相对固定。但很多时候模型输出的不是纯JSON而是夹杂着解释文字的混合体。你得写正则去提取写fallback逻辑去兜底。每加一个工具就得加一套解析规则。工具多了之后解析逻辑的复杂度是线性增长的而解析失败的概率是指数增长的。第二语义漂移。同一个意图模型可能用“查询”“获取”“检索”“查找”等不同的词来表达。你的映射表得覆盖所有可能的表达方式。但语言是开放的你永远覆盖不全。今天模型说“查询天气”明天可能说“看看天气怎么样”后天可能说“帮我查一下今天的气温”。你得不断地加同义词加示例加约束。第三无法做类型检查。自然语言没有类型系统。模型说“温度设为25度”这个25是整数还是浮点数单位是摄氏度还是华氏度如果工具期望的是华氏度模型给的是摄氏度框架没法在编译期发现这个问题只能在运行时报错。而运行时报错意味着用户已经感知到了。3.2 一个真实的翻车案例我之前搭过一个客服Agent需要根据用户问题决定调用哪个后端服务。工具有三个查订单、查物流、查退款。模型输出的格式要求是JSON包含tool和params两个字段。测试的时候一切正常。上线之后大概每100次调用会出现3到5次解析失败。我拉日志一看失败的情况五花八门模型输出了{tool: 查订单, params: {order_id: 12345}}但我的映射表里写的是query_order中文没匹配上。模型输出了{tool: query_order, params: {orderId: 12345}}字段名用了驼峰我期望的是下划线。模型输出了好的我来帮您查询订单{tool: query_order, params: {order_id: 12345}}前面多了一段话。模型输出了{tool: query_order, params: {order_id: 12345}}order_id是数字不是字符串。每一个问题单独看都很蠢但组合在一起你的解析逻辑就得写成这样先去掉可能的前缀然后尝试解析JSON如果失败就尝试用正则提取提取到之后做字段名归一化再做类型转换再做枚举值映射。这一套下来代码量比业务逻辑还多。这就是“文字依赖”的代价。你把大量的工程复杂度花在了“让模型好好说话”和“听懂模型说的话”上面而不是花在业务本身。4. Jev的决策模型是怎么工作的4.1 从“生成文字”到“输出决策”Jev的决策模型不生成自然语言它输出的是一个决策表示。这个表示可以是一个离散的动作ID对应到预定义的动作空间。一个固定维度的向量每个维度对应一个决策维度。一个结构化对象但字段是预定义的、类型安全的。关键在于这个输出是直接可消费的不需要经过自然语言解析这一层。我理解这个思路的时候想到了Java里的枚举。传统Agent就像用字符串来表示状态String status ACTIVE你得担心大小写、拼写错误、前后空格。Jev就像用枚举Status status Status.ACTIVE编译器帮你检查IDE帮你补全不可能出错。4.2 决策空间的预定义Jev要求你在搭建Agent之前先定义好决策空间。也就是说这个Agent可能做出的所有决策你都得提前枚举出来。这听起来像是限制但做过Java开发的人都知道预定义接口和实现类是保证系统可靠性的基本手段。你不可能让一个Service随便返回什么类型你得定义好返回值的类型。同样你不可能让决策模型随便输出什么动作你得定义好动作空间。决策空间的定义包括动作列表这个Agent能执行哪些动作。每个动作的参数schema每个动作需要哪些参数参数的类型是什么取值范围是什么。动作之间的约束哪些动作可以连续执行哪些动作互斥。这些定义在Java里可以用枚举、注解、JSON Schema等方式来表达。定义好之后决策模型的输出就被约束在这个空间里不可能跑偏。4.3 训练方式的差异传统Agent的决策模型通常是通过prompt engineering来引导的。你写一段系统提示词告诉模型“你是一个Agent你可以调用以下工具请以JSON格式输出你的决策”。然后靠few-shot示例来教模型怎么输出。Jev的决策模型是通过强化学习来训练的。具体来说它不依赖于人类对“好文字”的偏好而是依赖于决策结果的好坏。你执行一个动作环境给你一个反馈根据反馈来调整决策模型的参数。这就绕开了RLHF的一个核心问题人类标注的是文字的质量而不是决策的质量。在传统Agent里你用RLHF训练模型人类标注员看到的是模型输出的文字他们评判的是“这段文字看起来对不对”。但文字看起来对不代表决策是对的。模型可能输出了一段非常漂亮的JSON但选错了工具。Jev的思路是直接对决策结果做强化学习。选对了工具奖励选错了惩罚。不需要人类去评判文字质量因为根本没有文字。5. 为什么这个思路能颠覆Agent架构5.1 架构层面的简化传统Agent架构通常包含这些组件Prompt构造器把当前状态、历史对话、工具描述拼成prompt。LLM推理层调用LLM生成文字。输出解析器从文字里提取决策。决策执行器根据决策调用工具。状态更新器把执行结果更新到状态里。Jev架构下这些组件变成了状态编码器把当前状态编码成决策模型能接受的输入。决策模型直接输出决策信号。决策执行器根据决策信号调用工具。状态更新器把执行结果更新到状态里。Prompt构造器和输出解析器消失了。这两个组件在传统架构里往往是最复杂、最容易出bug的部分。去掉它们整个系统的可靠性上了一个台阶。5.2 延迟和成本的优化生成文字是自回归的一个token一个token往外蹦。输出一个决策信号可能只需要几个token甚至可以通过分类头直接输出。这意味着推理延迟降低不需要等模型生成完整的文字描述。推理成本降低token数少了API调用费用或者自托管算力都省了。吞吐量提升同样的算力可以支撑更多的并发决策。对于需要高频决策的Agent场景比如实时对话、游戏AI、自动化运维这个优化是决定性的。5.3 可靠性的提升没有文字解析就没有解析失败。决策模型的输出直接对应到动作空间要么是合法的动作要么是非法动作。非法动作可以在执行前就被拦截不会造成副作用。而且决策模型的输出可以做类型检查。参数的类型、范围、约束都可以在编译期或者加载期验证。这跟Java的静态类型系统是一个道理把错误暴露在运行之前。6. 从Java视角看Jev的工程实现6.1 决策空间的定义在Java里你可以用枚举来定义动作空间public enum AgentAction { QUERY_ORDER(OrderParams.class), QUERY_LOGISTICS(LogisticsParams.class), QUERY_REFUND(RefundParams.class); private final Class? paramType; AgentAction(Class? paramType) { this.paramType paramType; } public Class? getParamType() { return paramType; } }每个动作对应一个参数类参数类用Java的record或者Lombok的Data来定义public record OrderParams( NotNull String orderId, Min(1) Max(100) int pageSize ) {}这样决策模型的输出就可以直接映射到AgentAction和对应的参数对象。如果模型输出的动作不在枚举里直接拒绝。如果参数不符合约束直接拒绝。所有的校验都在执行之前完成。6.2 决策模型的集成决策模型可以是一个本地的小模型也可以是一个远程的API。在Java里你可以定义一个接口public interface DecisionModel { AgentAction decide(AgentState state); T T getParams(AgentAction action, AgentState state); }然后根据具体的实现来选择。如果是本地模型可以用ONNX Runtime或者DJL来加载。如果是远程API可以用HTTP客户端来调用。关键在于决策模型的输出是类型安全的。你不需要解析文字不需要做字符串匹配不需要担心格式问题。6.3 状态编码决策模型的输入是Agent的当前状态。状态可以包括对话历史当前任务目标已执行的动作序列环境反馈在Java里你可以把状态定义成一个对象然后编码成决策模型需要的格式。如果是神经网络模型可能需要编码成向量如果是基于规则的模型可能直接传对象就行。6.4 执行与反馈决策执行器根据决策模型输出的动作和参数调用对应的工具。执行结果更新到状态里然后进入下一轮决策。这个循环在Java里可以用一个简单的while循环来实现AgentState state initialState; while (!state.isTerminal()) { AgentAction action decisionModel.decide(state); Object params decisionModel.getParams(action, state); ActionResult result executor.execute(action, params); state state.update(result); }这个循环非常清晰没有任何文字解析的环节。决策模型负责决策执行器负责执行状态负责记录。各司其职。7. 实操中需要注意的坑7.1 决策空间的粒度决策空间的粒度是一个需要仔细权衡的问题。粒度太粗决策模型的选择太少灵活性不够。粒度太细决策空间太大训练难度增加而且容易出现无效决策。我的经验是从粗粒度开始根据实际需求逐步细化。比如一开始只定义“查询”“修改”“删除”三个动作发现“查询”下面有太多不同的查询类型再拆分成“查询订单”“查询物流”“查询退款”。7.2 冷启动问题决策模型需要通过强化学习来训练但冷启动阶段没有足够的反馈数据。这时候可以用一些启发式规则来引导或者用传统Agent的日志来初始化训练数据。我试过的一个方法是先用传统Agent跑一段时间把决策日志收集起来然后用这些日志来预训练决策模型。等模型有了基础能力之后再切换到强化学习模式。7.3 与现有Java生态的集成Jev的思路虽然新但落地的时候还是要跟现有的Java生态集成。比如用Spring Boot来管理Agent的生命周期。用Spring StateMachine来管理状态流转。用Micrometer来监控决策延迟和执行结果。用Resilience4j来做熔断和降级。这些集成工作不难但需要你对Java生态有足够的了解。7.4 决策的可解释性不生成文字的一个副作用是决策的可解释性变差了。传统Agent至少能看到模型输出的文字知道它“为什么”这么决策。Jev的决策模型输出的是一个信号你很难直接理解它的决策逻辑。解决方法是在决策模型之外单独训练一个解释模型或者用SHAP、LIME等方法来解释决策。但这会增加系统的复杂度需要权衡。8. 常见问题速查问题可能原因排查思路解决方案决策模型输出非法动作决策空间定义不完整检查动作枚举是否覆盖所有情况补充动作定义重新训练决策延迟高模型推理慢检查模型大小和推理框架模型量化、剪枝或换更小的模型决策准确率低训练数据不足检查训练样本数量和分布增加训练数据调整奖励函数与现有系统集成困难接口不兼容检查接口定义和数据类型写适配器层做类型转换决策不可解释模型是黑盒检查是否有解释机制加解释模型或日志记录9. 我对这个方向的一些个人判断我在Java后端领域干了十多年见过太多“新概念”来了又走。Jev这个思路让我觉得有意思的地方在于它不是在现有架构上打补丁而是从根上重新思考了决策层和执行层的关系。传统Agent架构的问题在于它把LLM当成了一个“万能翻译器”既要理解用户意图又要生成决策文字还要让框架能解析。这就像让一个翻译官同时做同声传译和会议纪要还要保证纪要格式能被机器读取。要求太多出错是必然的。Jev的做法是把职责拆开LLM或者决策模型只负责决策不负责表达。表达的事情交给结构化的接口来做。这跟Java里Controller和Service的职责分离是一个道理。Controller负责处理HTTP协议Service负责业务逻辑。你不会让Service去解析HTTP报文也不会让Controller去写业务规则。当然这个思路也不是银弹。决策空间的预定义需要你对业务有深入的理解强化学习的训练需要大量的反馈数据可解释性的问题也需要额外的机制来解决。但至少它指出了一个正确的方向让决策模型做决策让工程框架做工程。对于Java开发者来说这个方向尤其值得关注。因为Java生态里有一套非常成熟的接口驱动设计方法论有一套非常完善的类型系统和校验机制。这些东西在传统Agent架构里用不上因为中间隔了一层自然语言。但在Jev架构下这些工程实践可以直接复用。我最近在尝试用Java写一个简单的决策模型框架把动作空间定义、参数校验、执行反馈这些环节都做成可复用的组件。踩了一些坑也积累了一些经验。等成熟了再单独写一篇分享。如果你也在做Agent相关的开发建议你花点时间研究一下Jev的思路。不一定非要完全照搬但至少可以借鉴它的核心思想把不确定性约束在最小的范围内让系统的其他部分保持确定和可靠。这个原则在Java世界里被验证了二十年在Agent时代同样适用。