这两年我经常被 Java 工程师问到一个问题Java 这碗饭还能吃多久每次我都不太想直接回答因为真正值得聊的不是饭碗的问题而是 Java 工程师手里的技能还能不能往下一波技术浪潮上迁移。我的答案很明确能而且转型 AI Agent 可能是 Java 工程师性价比最高的方向之一。AI Agent 现在确实很热但大多数技术分享都是 Python 系的LangChain、Pydantic、FastAPI看着跟 Java 工程师没关系。可你把 Agent 拆开看它依赖的恰恰是 Java 工程师最熟悉的那套东西稳定的服务架构、可靠的系统调用、事务和并发控制、接口隔离、幂等设计。AI Agent 不是一个神秘的新黑盒它只是在传统的系统外面套了一层大模型语义层。这篇文章我就用一篇讲透的篇幅从原理到落地把 Java 工程师转型 AI Agent 这件事完整讲一遍。无论你是刚入行的 Java 开发还是已经写了十年业务代码的老兵都能找到可以直接用的东西。1. AI Agent 到底是什么先用 Java 的脑子理解一遍1.1 Agent 不是新发明它只是改变了“流程决定权”的位置传统程序是流程预先写死的。用户说“查订单”你就在 Controller 里写if (cmd.equals(查订单)) { orderService.query(); }判断条件写死在代码里。Agent 则是把“下一步做什么”的决定权交给了大模型用户说了一句话模型判断意图决定调用哪个工具拿到结果以后再决定下一步怎么做。这个“推理-行动-观察结果-再推理”的循环就是 Agent 与普通程序的核心区别。我用一个类比解释给新同学听传统程序像流水线上的机械臂每个动作都是提前编排好的Agent 像一个新来的实习生你给他一本操作手册工具清单他自己看用户要求、翻手册、选工具、执行遇到异常还会换一个方式再试一次。这个实习生干活不保证 100% 按你的预期来但你给他越清晰的手册、越明确的边界他干得就越稳。对 Java 工程师来说这意味着你的角色从“把逻辑写死”变成了“把逻辑封装成工具 定义好边界 让模型做路由”。服务还是要写接口还是要调事务和权限还是要控只是多了一个模型层在做语义分析和决策。1.2 ReAct 循环与 Function CallingAgent 得以运转的两块基石如果要给 Agent 找两个最小必要知识一个是ReAct 循环一个是Function Calling。ReAct 是 Reasoning Acting模型不是一步到位给出最终答案而是交替进行思考、行动、观察。我实际开发时会在日志里看到这样的轨迹Thought用户想查订单状态需要调用查询订单工具参数 orderId 是 2024001。Action调用 queryOrder(orderId2024001)。Observation订单已发货物流单号 SF123456。Thought可以直接根据物流信息回复用户。Final Answer您的订单已经发货物流单号是 SF123456。这套机制让模型能处理需要多步工具调用的复杂问题而不是看到一个用户问题就直接胡编答案。Function Calling是实现工具调用的具体机制。在 API 层它的原理并不复杂你在请求里用tools参数告诉模型“有哪些函数可以调用”每个函数包括名称、参数结构JSON Schema和描述。模型在推理过程中如果认为需要某个工具它并不会自己去执行而是在返回内容里输出一段结构化的tool_calls里面说明函数名和参数。框架层拿到这个结构后帮你找到对应的 Java 方法、调用它、把结果拼进对话上下文再发给模型继续生成。用 Java 工程师的话说模型相当于帮你做了一个“语义路由 参数填充”它输出的是一个符合 DTO 结构的 JSON你要做的就是把这段 JSON 反序列化然后走你熟悉的那套 Service 调用。1.3 把 Agent 系统映射成 Java 系统其实你早就接触过这些组件我在带团队做转型分享时喜欢画一张映射表Java 工程师看一眼就通了Agent 组件作用Java 世界类比大模型语义理解、推理、决策CPU 指令集Prompt给模型的指令和约束配置中心里的规则文件工具ToolsAgent 可以调用的外部能力Service / Feign Client / MQ Producer短期记忆本次对话的上下文会话对象 / RequestContext长期记忆跨会话的知识和数据Redis / 数据库规划与编排决定工具调用的顺序和条件状态机 / 工作流引擎Flowable、CamundaAgent 循环执行器控制 ReAct 循环的启动与终止消息队列的消费者循环这张表是我认为 Java 工程师转型时最重要的一张图。你会发现AI Agent 并没有发明什么全新的架构概念大模型是新的“计算单元”工具是你早就写过无数遍的 API 调用记忆是无状态的会话管理编排就是你很熟悉的流程引擎思路。你缺的只是模型侧的一些知识补齐以及“如何用 Java 把这些东西串起来”的工程经验。2. 主流 Agent 架构拆解与框架选型2.1 单 Agent 工具90% 的场景用这个就够了不要一上来就搞多 Agent。我在实际项目里的经验是绝大多数企业内部场景单 Agent 一组工具就是最优解。一个模型实例、一套系统提示词、若干工具方法模型自己规划调用顺序。架构简单意味着好排查、好评估、好维护。企业内部常见的高价值场景基本都是这个模式工单助手员工描述问题 - Agent 判断故障类型 - 调用工单系统建单或查状态。数据查询助手用户用自然语言问“上个月华南区的销售额是多少” - Agent 调用报表工具 - 返回数据。运维助手用户说“帮我查一下订单服务最近的异常日志” - Agent 调用日志查询工具 - 汇总结果。单 Agent 要注意的点是工具数量不能无限制膨胀。一个模型在一次推理中能“看到”的工具描述是有限的工具描述越长、数量越多选择错误率和 token 消耗都会上升。我一般建议工具数量控制在 20 个以内超过这个数就考虑分组或改成多 Agent。2.2 多 Agent 与图编排不要为了炫技引入复杂度多 Agent 架构主要有两种常见形态第一种是主管 执行者模式一个主 Agent 负责理解用户意图、拆分任务把子任务路由给不同的子 Agent。比如你有一个“数据分析主 Agent”下面分“SQL 生成 Agent”“图表生成 Agent”“异常解释 Agent”。这种模式适合任务边界非常清晰、需要不同系统提示词约束的场景。第二种是图编排使用 LangGraph、Java 系的 LangGraph4j 这类框架把 Agent 的流程定义成一张有向图节点是“调用模型”或“调用工具”边是“根据模型输出走哪条分支”。这套玩意儿对 Java 工程师来说其实很亲切本质上就是你用过的状态机或工作流引擎只是节点里跑的是模型调用。我给团队定的原则是单 Agent 能解决的绝不引入多 Agent多 Agent 能解决的绝不引入图编排。每多一个 Agent就多一层模型调用延迟、多一笔 token 开销、多一个评估维度排查问题的难度指数级上升。多 Agent 的价值不是在技术展示上而是在复杂的业务路径拆分上如果业务状态流转本来就很明确你直接用 Java 写状态机更稳。2.3 Java 系框架选型Spring AI、LangChain4j 还是自研这是每次技术选型都会吵一遍的问题。我按实际体感把三条路对比一下方案优势劣势适合场景Spring AI与 Spring Boot 无缝集成自动装配、Starter 机制对工具调用有良好封装版本迭代快文档有时滞后正在用 Spring Boot 的 Java 团队LangChain4j功能覆盖面广AI Service 注解模型很像写 Feign Client迁移自 Python LangChain 的经验方便概念多上手需要理解它的抽象需要复杂链式调用的团队自研 HTTP SDK完全可控、依赖少、便于理解底层原理要自己处理循环、重试、上下文管理工作量大学习阶段、或者对依赖极度敏感的项目我的建议很直接如果你所在团队还在用 Spring Boot选 Spring AI 起步因为它和现有工程体系融合成本最低。如果你想把 LangChain 那套 AI Service、Retriever 等概念平移过来LangChain4j 也很值得用。但不管选哪个框架我强烈建议你在学习阶段先自研一个最简版本——直接调大模型 API、自己写 ReAct 循环、自己解析 tool_calls。只有亲手写过一次循环你才能真正理解框架帮你做了什么。这里顺便提一句现在也有 Rust 重写的 Agent 运行时性能表现不错但对绝大多数企业 Java 团队来说生态成熟度和团队技能储备还不足以支撑替换不需要为此焦虑。3. 落地实战用 Spring AI 搭一个企业报障工单 Agent3.1 场景设定与技术选型理论说再多不如跑通一个真实业务。我拿企业内部最常见的“报障工单 Agent”举例员工在 IM 里说一句“我的订单 2024001 一直显示已支付但没有物流信息帮我查一下”Agent 需要判断这是订单问题还是物流问题必要时创建工单并且把处理结果回复给员工。为什么选工单场景因为几乎每个公司都有工单系统业务逻辑简单清晰而且天然需要工具调用、参数抽取、权限校验、状态查询非常贴近 Java 工程师的日常。你可以把这个场景平移到自己的业务里思路完全一致。技术选型上我用 Spring Boot 3 Spring AI模型走 OpenAI 兼容协议。国内很多模型服务商都提供兼容端点你用哪家都行本地调试可以用 Ollama 跑一个小模型避免过度依赖线上配额。配置如下spring: ai: openai: base-url: ${AI_BASE_URL:http://localhost:11434/v1} api-key: ${AI_API_KEY:ollama} chat: options: model: ${AI_MODEL:qwen2.5:7b} temperature: 0.2temperature 我调成 0.2因为工单场景需要确定性不需要模型发挥创造力。温度越高模型越“放飞”工具选择越容易出错这是个我在多个项目中验证过的结论。3.2 第一步把 Java 方法注册成模型的工具Agent 的第一块拼图是把 Java 方法暴露成模型可调用的工具。Spring AI 的思路非常 Java用注解声明字段用 Java 类型推导参数结构框架自动转成 JSON Schema 发给模型。Component public class WorkOrderTools { private final WorkOrderClient workOrderClient; public WorkOrderTools(WorkOrderClient workOrderClient) { this.workOrderClient workOrderClient; } Tool(description 根据订单号查询订单当前状态、支付状态和物流单号) public String queryOrder(String orderId) { OrderInfo info workOrderClient.queryOrder(orderId); return info.toJson(); } Tool(description 创建一条报障工单title为问题概述priority为优先级LOW/MEDIUM/HIGH) public String createTicket(String title, String priority) { Ticket ticket workOrderClient.create(title, priority); return 工单已创建编号 ticket.getId(); } }这一步有三个我在实操里踩过的坑第一工具描述就是接口文档甚至比接口文档更重要。模型是靠 description 来做工具选择的你写“查询订单信息”和写“根据订单号查询订单当前状态、支付状态和物流单号供客服判断超时原因”模型的选择准确率完全不一样。我事后看调用日志才发现很多“模型不调用工具直接瞎编”的问题根源就是工具描述写得太含糊。第二参数类型尽量扁平。参数用基本类型和字符串方便模型填充。如果是一个复杂嵌套对象模型在构造 JSON 时容易出错不要考验模型的 JSON 生成能力。第三返回值要结构化。工具返回的字符串会原封不动地塞回上下文给模型看你返回一大段 JSON 没问题但最好让返回结果包含可用于最终回复的信息要点。比如 queryOrder 返回物流单号模型才能顺理成章地告诉用户。3.3 第二步让 Agent 在回合中自主使用工具Spring AI 把 Agent 循环封装得很干净核心代码其实就这么几行Configuration public class AgentConfig { Bean ChatClient workOrderChatClient(ChatClient.Builder builder) { return builder .defaultSystem(你是一名企业IT支持助手。 当用户描述问题时先使用工具查询相关信息 信息不足时向用户追问不要编造 确认是故障问题时创建工单并告知用户工单编号。) .defaultTools(new WorkOrderTools(workOrderClient)) .defaultAdvisors(messageChatMemory) .build(); } }调用侧就是一个普通的 Service 方法Service public class SupportService { private final ChatClient chatClient; public String handleUserMessage(String userId, String text) { return chatClient.prompt() .user(text) .call() .content(); } }从调用方看这跟调一个普通 Service 没有任何区别。但框架内部发生的事情不少用户消息被发往模型模型返回“需要调用 queryOrder参数 orderId2024001”框架反序列化参数反射调用你的 Java 方法拿到结果拼进上下文再发给模型模型生成给用户的最终回复。这个迭代对 Spring AI 是透明完成的。如果你在自研阶段想理解这个循环核心逻辑大概是这样的伪代码ListMessage messages new ArrayList(); messages.add(systemMessage(AGENT_PROMPT)); messages.add(userMessage(text)); for (int step 0; step MAX_STEPS; step) { ChatResponse resp model.chat(messages, tools); messages.add(resp.message()); ListToolCall calls resp.toolCalls(); if (calls.isEmpty()) { return resp.content(); // 模型给出了最终回答 } for (ToolCall call : calls) { String result toolRegistry.execute(call.name(), call.arguments()); messages.add(toolResultMessage(call.id(), result)); } } throw new MaxStepExceededException(Agent 循环超过最大步骤);这里必须设置MAX_STEPS我一般设 5 到 8。不设上限的后果是模型在一个复杂任务里可能陷入语义死循环一遍遍调用工具停不下来Token 消耗和延迟都失控。3.4 第三步接入企业系统与权限校验Agent 接入真实系统最难的不是模型而是权限和边界。你的工具方法背后是真金白银的业务系统不能让任何人都借模型的手乱调。我常用的做法是把用户身份注入工具上下文。Spring AI 支持在调用工具时把会话里的用户信息一并传进去Tool(description 查询当前登录用户自己的订单状态) public String queryMyOrder(String orderId) { UserContext ctx UserContextHolder.get(); if (!orderClient.belongsTo(ctx.userId(), orderId)) { return 订单不属于当前用户; } return orderClient.query(orderId); }更关键的是敏感操作加确认。查询类工具可以直接执行但创建工单、退单、改配置这类写操作我给 Agent 的提示词里规定执行写操作前必须向用户输出“我将为您创建工单是否确认”用户确认后才调用工具。这套机制成本极低但能拦截大量模型的错误决策。再补一个工具幂等设计。模型在重试或对话多轮时有可能同一个工具被调用两次而创建类操作重复执行会造成脏数据。我的做法是让工具方法支持幂等键比如 createTicket 增加一个requestId参数由模型根据用户问题生成一个唯一 ID系统按 requestId 去重。这个思路比在模型层约束靠谱得多因为语义重复极难控制接口幂等才是硬保障。4. Java 工程师最关心的问题Agent 怎么扛并发4.1 先清醒认识新的延迟模型Java 工程师最擅长的就是高并发但 Agent 服务和传统 REST 服务的并发模型完全是两回事。传统接口耗时几十毫秒线程占用时间短大模型接口一个请求平均要 3 到 10 秒甚至更长。如果你的 Agent 服务还是“一个请求占一个线程同步等模型返回”线程池会迅速被打满哪怕只有二三十个并发请求服务可能就失去响应了。所以做 Agent 并发设计第一原则不是优化线程数而是减少线程等待。你需要从架构层面接受一个事实模型调用是慢 I/O必须用异步或虚拟线程的思路来应对。4.2 虚拟线程与异步两套可落地的方案如果你用的是 Java 21 及以上版本虚拟线程是性价比最高的方案。虚拟线程的诞生就是为了承载大量阻塞型 I/O你把模型调用放在虚拟线程里一个请求占一个虚拟线程它的创建和切换成本极低吞吐量比平台线程高一个量级。Spring Boot 3.2 里开启虚拟线程只需一行配置spring: threads: virtual: enabled: true如果你还停留在 Java 8/11就需要走异步路线。用CompletableFuture把模型调用包装成异步任务再配合thenApply编排后续处理。这套方案的问题是代码复杂度上升尤其在 Agent 循环里每一轮“模型-工具-模型”都要异步编排排查链路会费劲一些。我自己在 Java 17 的项目里用过异步方案在 Java 21 的新项目里开了虚拟线程实测对比下来虚拟线程在代码可读性和吞吐量上都明显胜出。现在新项目我的默认选项就是 Java 21 虚拟线程没有特殊情况不改。4.3 会话状态外置与水平扩容Agent 天然有状态它要记得对话历史记得上一轮查到了什么。但如果会话状态留在 JVM 内存里服务就没法水平扩容——用户可能被负载均衡打到另一台实例上Agent 就“失忆”了。生产级的做法是把会话状态外置到 Redis。Spring AI 的MessageChatMemory可以对接 Redis 实现每次对话把消息历史读出来、追加、再存回去。这样所有实例共用一套会话状态扩容就是加机器无状态化程度越高稳定性越好。但要注意Redis 里存的是多轮对话原文会持续增长需要做裁剪策略超过指定轮数后丢给一个摘要模型压缩成摘要再继续对话。工具调用侧的幂等同样要考虑。如果模型在超时后重试同一个创建类工具服务端要保证不会生成两条工单。我前面提到的 requestId 幂等键在并发场景下更要作为硬性要求来做。4.4 限流、重试与降级给模型 API 加工程兜底模型 API 不是你自己的系统它有配额、有 QPS 限制、也会偶发超时。没有工程兜底的 Agent 服务上线当天就会被教育。我的兜底三板斧信号量控制并发度。用一个Semaphore限制同时进行的模型调用数量比如 50 个超出的请求排队等待。这个比把压力直接怼到模型 API 要安全得多排队等的体验远好于全量超时。退避重试。模型 API 返回 429 或 5xx 时不能立刻重试要用指数退避加随机抖动避免所有请求在同一时刻重试产生“重试风暴”。我一般设置最大重试 3 次超过后走降级。降级预案。模型不可用时先把 Agent 的入口摘掉返回“智能助手暂时不可用请转人工服务”同时把用户问题存下来等模型恢复后补处理。工具调用失败时让 Agent 在回复中明确说“该功能暂不可用我已为您记录稍后有人跟进”这比硬报错友好得多。另外简单的请求可以加缓存。对相同问题的重复提问按用户 ID 消息内容的哈希做热点缓存TTL 设几分钟。不要觉得缓存和 Agent 不搭企业内部助手的高频重复问题可能占三成流量缓存是成本最低的优化手段。5. 常见问题与排查技巧实录5.1 模型不调用工具直接张口就来这是最常遇到的问题。你排查时不要急着改代码先抓一次请求的日志看模型返回的原始内容是什么。原因一般有三类工具描述不清晰模型不知道这个工具能干什么。把描述写得更具体包含输入参数的含义、输出结果的形态。temperature 太高模型在“自由发挥”。调到 0.2 以下确定性会显著提升。模型本身不支持 Function Calling或者走兼容网关时参数没透传。确认模型文档里支持 tools 参数有些轻量模型是明确不支持的。我排查这类问题时有一个固定动作把给模型的完整请求体打出来肉眼确认 tools 参数是否到达模型服务端。很多时候框架层已经加了工具但配置变更后没生效问题出在环境变量而不是提示词。5.2 Function Calling 返回的 JSON 解析失败模型输出的 JSON 偶尔会带上多余的说明文字或者因为输出截断而变成不完整的 JSON。这类问题我在生产里遇到过不少次。解决手段是分层的。第一层是重试框架会对解析失败自动发起一次修正调用把“上次输出 JSON 非法”作为新的提示发回去让模型重新生成。第二层是放宽解析用一个更宽松的 JSON 修复器比如在处理模型输出时先截取第一个{到最后一个}之间的内容。第三层是降低生成截断概率调高 max_tokens给完整的工具调用留足输出空间。你还要关注一个细节如果工具参数本身是枚举值模型输出越界值也会导致解析失败。比如 priority 规定 LOW/MEDIUM/HIGH模型输出 URGENT 就会挂。工具方法的实现对未知枚举值要做容错不能直接抛异常。5.3 上下文窗口爆掉之后 Agent 像失忆多轮对话后Token 累积超过了模型上下文窗口要么请求报错要么较早的对话内容被静默丢弃Agent 就会“忘掉”几分钟前用户说过的关键信息。用户感知就是“它怎么不认账了”。我的处理方案是三级策略对话轮数超过 10 轮或 Token 超过阈值时把历史消息做摘要压缩摘要本身再写入长期记忆按用户 ID 存 Redis当新一轮问题需要更早信息时用向量检索把相关历史片段拉回来拼进上下文。大部分企业内部助手的对话记忆需求做到第一级“摘要压缩”就够了不要一上来就上向量库过度设计会带来检索质量问题。5.4 并发一高就被模型 API 限流这是我把 Agent 服务扛到线上压测时遇到的第一个大坑。平时开发时一天调用不了几次一上线几十个用户同时用模型提供方立刻返回 429。原因很简单模型 API 的 QPS 配额是有限的你的服务没有做本地限流把配额打爆了。解决思路是把限流前置到你的服务层。用信号量或令牌桶控制总并发再用队列缓冲瞬时尖峰。同时给不同等级用户分配不同配额内部高管和一线客服可能要不同的容量保障。还有一点我特别强调不要把模型 API 的配额直接等同为系统容量模型调用只是链路中的一环工具服务本身的耗时和瓶颈也要一并压测。5.5 工具调用的权限与安全边界工具暴露给模型后相当于系统多了一组“人肉接口”而且这个调用方是模型不是程序员。很多人问“Agent 能不能让小红书自动发消息”“能不能拿 Agent 做交易”技术上都能实现关键是你敢不敢把写操作权限直接交给模型自动执行。我的安全设计原则是三条查询低危工具可自动执行高危写操作创建、删除、修改状态、对外发布、资金交易必须显式用户确认所有工具调用记录全链路审计日志包括调用者、时间、模型给的参数、执行结果。按这个原则划分既能保证 Agent 效率又能把风险锁在可控范围内。我整理了一份问题速查表方便团队排查时快速定位问题现象常见原因排查入口解决手段模型不调工具直接回答工具描述不清 / temperature 高 / 模型不支持看模型原始输出优化描述、降温度、换模型工具调用 JSON 解析失败输出截断 / 带多余文字 / 枚举越界看工具调用参数重试、宽松解析、加 max_tokens多轮后失忆上下文超限被裁剪看请求体的 token 量摘要压缩、向量记忆429 限流本地没有并发控制看 API 响应头信号量限流、退避重试工具被误调/越权没有权限校验和确认机制审计日志工具上下文注入用户、写操作确认6. Java 工程师的 Agent 转型路线6.1 先补三块基础知识别急着追框架AI Agent 这个领域跟 Java 后端不一样框架更迭很快概念层的东西反而稳定。我给团队定的学习顺序是先补基础再碰框架。第一块是Token 和上下文窗口。Token 是模型计费单位也是容量单位。同样一句话在模型眼里不是按字符数拆的而是按 Token 拆的。上下文窗口决定了模型一次性能“看到”多少内容。你不需要会算精确 Token 数但要理解为什么对话历史太长会爆窗口、为什么长文档要切成片段做检索。第二块是Embedding 和向量检索。这是做知识库 Agent、长期记忆的基础。本质上是把文本转成向量用余弦相似度找“语义相关的片段”。Java 工程师可以把它理解成一个推荐系统你给一个查询向量它从库里找最相近的 Top-K 片段。会调向量数据库的 API 就能干活。第三块是Prompt 的结构化设计。虽然 Java 工程师习惯写代码但 Agent 项目里 Prompt 就是代码的一部分。系统提示词、工具描述、用户消息这三层结构要分开写、分开维护。我在项目管理上把 Prompt 当接口文档一样管改 Prompt 要评审、要回归测试不能随口改。6.2 三个月上手计划从手动循环到生产级 Agent我在带人转型时常用这个三个月计划你可以直接抄第 1 个月避开框架直接用 Java 调大模型 HTTP 接口自己实现一个最简 ReAct 循环。写一个能通过 Function Calling 调用日期查询、订单查询的小工具。这个月目标是把原理打通理解模型输出和工具执行的来回过程。第 2 个月上手 Spring AI把之前手动循环做的事迁移到框架里。选一个真实业务场景比如企业知识库问答或工单助手实现工具调用、会话记忆、系统提示词管理部署到公司内网给同事试用。这个月目标是体验框架的工程化能力以及感受真实用户的提问方式。第 3 个月做并发和稳定性改造。开虚拟线程、接 Redis 会话缓存、加信号量限流、写评测用例集。上线后做灰度先给一个小组用收集对话日志分析工具选择准确率持续优化工具描述和提示词后再全面放开。这个计划里我没让你学 Python也没让你读论文。对 Java 工程师来说边做边补是效率最高的方式。但如果你对 Transformer 的内部机制有兴趣可以去了解注意力机制和大模型预测下一个 Token 的原理这对理解为什么模型会“一本正经胡说八道”很有帮助。6.3 工程化落地评测、可观测性与灰度缺一不可Agent 上线后比传统系统多了一个大麻烦它没有固定正确输出。同一个问题今天的回复和明天可能不一样。所以你不能像测接口那样断言返回结果要做 Agent 评测。我推荐的做法是准备 30 到 50 条真实历史问题标注期望的工具调用序列和答案要点。每次修改提示词、工具描述或模型版本后跑一遍测试集记录指标工具选择准确率、最终回答通过率、平均调用步骤数、平均耗时。这个测试集要持续扩充线上出现问题的案例一律回流进测试集防止同一个问题再次上线。可观测性上Agent 链路必须全链路打日志从用户消息、模型推理、tool_calls、工具执行结果到最终回复每一步都要有 trace 上下文。我通常用 OpenTelemetry 上报把这些 span 关联起来排查问题时就按 traceId 拉出完整链路一眼看出是哪一步出的问题。上线节奏也要讲究。Agent 不比普通接口不可控因素多我的做法是先灰度再全量让一个小组先试用观察两天日志确认工具选择没问题、幻觉率可控再逐步放开流量。灰度期间要保留“转人工”入口给用户一个兜底不能让 Agent 成为唯一路径。最后说点个人感受。我带过的 Java 工程师转型 Agent最短的两周就能做出一个像样的内部工具最长的一直在焦虑中犹豫不决。差别不在基础在于是否愿意先把“模型输出一段 JSON我解析后调一个 Java 方法”这个小闭环跑起来。AI Agent 没有想象中那么玄它就是把大模型这个不稳定的推理单元嵌进你熟悉的工程体系里再用工程手段把它约束住。你不需要推翻 Java 生态去追 Python也不需要重新从语法学起。把你写订单系统、做中间件、扛高并发的那套能力迁移过来第一个能跑通生产流量的 Agent 离你没有那么远。