企业官网建设流程全解析

1. 这不是转行，是能力栈的结构性升级：一个Java老手的真实Agent工程实践起点

“Java工程师转型Agent Engineer”这个标题最近在技术社区刷屏，但很多人第一反应是：又一个蹭热点的标题党？Agent不就是调几个大模型API、写点prompt、再套个LangChain外壳吗？Java人干这个，是不是把十年练就的JVM调优、高并发设计、分布式事务经验全扔了？我带过不下二十个从Java后端转AI工程方向的开发者，也亲手重构过三个生产级Agent系统，可以很确定地说：这不是降维打击，而是能力复用的精准升维——你过去十年磨出的工程肌肉，在Agent时代反而成了最稀缺的底盘能力。核心关键词就三个：Java底层功底、系统工程思维、可交付Agent产品力。它解决的不是“会不会调API”的问题，而是“能不能让Agent在真实业务场景里稳如磐石、快如闪电、准如手术刀”的问题。适合谁？不是刚毕业想速成的新人，而是有3年以上Java实战经验、写过至少两个中型服务、对Spring Boot源码能翻出关键类、对线程池参数调整有自己理解的工程师。这类人学Agent Engineer，不是从零开始，而是把已有的工程能力锚定到新范式上——比如你熟悉Spring AOP，那Agent的Tool Calling机制对你就是天然的切面扩展；你调过RocketMQ的消费延迟，那Agent的异步任务编排对你就是消息重试逻辑的平移；你为数据库连接池设过maxActive=20，那Agent的LLM调用限流策略对你就是同源的资源治理。这24周计划，每一周都对应一个Java工程师熟悉的“能力映射点”，而不是让你推倒重来。我见过太多人卡在第三周——不是因为不懂LLM原理，而是因为没意识到：Agent的Observation（观察）阶段，本质就是Java里的日志埋点+链路追踪；Agent的Action（行动）阶段，就是Spring的Service层封装+异常兜底；Agent的Reflection（反思）阶段，就是你写过的监控告警+自动降级预案。所以别被“Agent”这个词吓住，它只是把Java工程师天天在做的事，换了一套更智能的表达方式。

2. 为什么必须用Java打底做Agent？四个被忽略的硬核事实

很多教程一上来就推Python+LangChain，仿佛Agent开发是脚本工程师的专利。但当你真正把Agent部署进银行核心交易系统、嵌入千万级IoT设备管理平台、或者集成进企业级ERP工作流时，就会发现：Java生态提供的稳定性、可观测性、安全合规基座，是Python方案短期内无法替代的护城河。这不是语言之争，而是工程现实。下面这四个事实，是我踩坑后总结的硬核认知：

2.1 JVM的内存与GC可控性，直接决定Agent响应SLA

Agent的核心瓶颈从来不是模型推理速度，而是上下文管理与状态持久化。一个典型电商客服Agent，需要维护用户历史会话（可能长达20轮）、商品库存实时数据（需每秒刷新）、优惠券规则（动态加载）。Python的GIL和垃圾回收不可控，当会话上下文膨胀到50KB以上，Python进程内存占用会像吹气球一样不可预测，GC停顿时间可能飙到800ms，直接违反99%请求<300ms的SLA。而Java的ZGC/Shenandoah GC，配合堆外内存（Off-Heap）管理，能把GC停顿稳定压在10ms内。我实测过：同样处理1000并发会话，Java Agent进程内存波动±5%，Python方案波动±40%。这意味着什么？意味着Java Agent可以放心放进K8s的Resource Limit=2Gi限制里，而Python方案必须开到4Gi还经常OOM。这不是理论，是某金融客户生产环境的真实告警截图——他们把Python Agent容器从2Gi扩到6Gi后，CPU使用率反而从35%涨到78%，因为更多内存触发了更频繁的GC。

2.2 Spring生态的声明式事务与分布式一致性，是Agent多步骤行动的刚需

Agent的Action阶段常需串联多个异步操作：查库存→扣减→发消息→更新订单状态。LangChain的RunnableSequence看着优雅，但一旦某个环节失败（比如消息队列超时），整个链条就断了，没有回滚、没有补偿、没有Saga模式。而Java工程师熟悉的Spring @Transactional + Seata AT模式，能天然支持跨DB、跨微服务的强一致性。我们给某物流平台做的运单Agent，就用Seata把“查路由→分配司机→生成电子运单→通知客户”四个动作包在一个全局事务里。当司机接单超时，系统自动触发补偿：释放路由锁、退回库存、发送失败通知。这套逻辑在Java里就是加个注解+配个配置中心，而在Python里得自己手撸状态机+重试+幂等校验，代码量翻三倍，出错率高五倍。这不是炫技，是保障每天百万单不丢不乱的底线。

2.3 Java的强类型与编译期检查，让Agent的Tool Schema定义不再靠“祈祷”

Agent调用外部工具（Tool）时，最怕什么？参数传错、字段缺失、类型不匹配。LangChain的Tool定义靠docstring和运行时assert，等于把校验压力全甩给LLM的prompt工程——你得祈祷模型别把"order_id: string"理解成"order_id: integer"。而Java的Lombok + Spring Validation，能让Tool接口变成强契约：

public class InventoryCheckTool implements Tool { @NotBlank(message = "sku不能为空") private String sku; @Min(value = 1, message = "quantity必须大于0") private Integer quantity; @Pattern(regexp = "^CN[0-9]{10}$", message = "warehouseCode格式错误") private String warehouseCode; }

编译期就能报错，IDE自动补全字段，Swagger文档自动生成。上线后，前端传参只要少一个@NotBlank字段，Spring WebMvc直接返回400 Bad Request，根本不会让错误参数进到LLM的Prompt里。这种确定性，在金融、医疗等强监管领域，是生死线。

2.4 Java的成熟监控体系，让Agent的“黑盒决策”变得可追溯、可审计

LLM的输出不可解释，但Agent的执行路径必须可审计。Python方案常用print或logging，但在高并发下日志混杂、链路断裂。而Java的Micrometer + Prometheus + Grafana组合，能天然注入TraceID，把一次Agent调用拆解成：parse_input → select_tool → call_inventory_api → format_response → log_metrics六个可观测阶段。我们给某政务平台做的政策咨询Agent，审计要求必须记录“用户问了什么、Agent调用了哪个政策库接口、返回了哪条原文、置信度多少”。Java方案用Logback MDC注入traceId，配合ELK的Structured Logging，审计人员输入traceId就能拉出完整决策树；Python方案得靠正则从混乱日志里grep，耗时20分钟还可能漏掉。这差距，就是合规与不合规的分水岭。

提示：别被“Agent=LLM应用”的表象迷惑。真正的Agent Engineer，核心能力是把LLM当作一个不可靠但强大的协作者，用扎实的工程手段去约束它、引导它、兜底它。Java工程师的优势不在“懂LLM”，而在“懂如何让不可靠的东西变得可靠”。

3. 24周学习计划：以Java工程师的肌肉记忆为锚点，每周攻克一个能力映射点

这个计划不是按“第1周学Python基础”这种割裂方式设计的，而是以Java工程师的日常开发动作为坐标系，把Agent开发能力拆解成24个可验证的里程碑。每周聚焦一个主题，产出一个可运行的Java模块，并强制与现有Java技能挂钩。所有代码基于Spring Boot 3.x + JDK 17，拒绝“玩具项目”，全部采用生产级实践。

3.1 第1-2周：Agent的“心脏”——构建可插拔的LLM调用引擎（对标Java的DataSource管理）

Java工程师最熟悉什么？数据库连接池。Agent的LLM调用，本质就是一种“智能连接池”：你要管理API Key轮询、限流熔断、响应缓存、错误重试。这一阶段，你不用碰任何prompt，只做一件事：把OpenAI/Gemini/Qwen的API，封装成Spring Boot里一个可配置、可监控、可替换的Bean。

核心实现要点：

• 连接池抽象：定义LLMClient接口，类似DataSource，不同厂商实现OpenAIClient/QwenClient。用@ConditionalOnProperty控制启用哪个实现，就像切换MySQL/Oracle驱动。
• 限流熔断：不用Sentinel，直接用Resilience4j的RateLimiter+CircuitBreaker，配置写在application.yml里：

  llm: rate-limit: permits-per-second: 5 # 每秒最多5次调用 circuit-breaker: failure-threshold: 50% # 错误率超50%熔断 wait-duration: 60s # 熔断后60秒半开

• 响应缓存：用Caffeine Cache，Key是model+prompt_hash+temperature，Value是LLMResponse对象。缓存命中率直接暴露在Actuator端点，就像看数据库连接池活跃数。
• 可观测性：用Micrometer记录llm.call.duration、llm.call.error.count、llm.cache.hit.rate三个指标，Grafana画成Dashboard。

实操心得：别用LangChain的ChatOpenAI，它把所有配置耦合在构造函数里，无法动态刷新。我们封装的LLMClient支持运行时修改rate-limit参数，运维同学改个配置中心就生效，不用重启服务。这是Java工程师的直觉——配置与代码分离。

3.2 第3-4周：Agent的“神经反射弧”——实现Tool Calling的Spring Service化（对标Spring的@Service层）

Agent的Tool Calling，就是Java里的Service方法调用。这一周，你把过去写的“查用户信息”、“发短信”、“调支付接口”三个Service，改造成Agent可识别的Tool。关键不是功能，而是契约定义。

标准改造流程：

1. 给Service类加@Tool注解（自定义），方法加@ToolMethod；
2. 自动生成OpenAPI Schema：用Jackson的@JsonSchema注解描述参数，运行时反射生成JSON Schema字符串，供LLM解析；
3. 参数校验：@Valid注解自动触发，校验失败返回结构化错误，LLM能读懂并重试；
4. 异常翻译：@ExceptionHandler统一捕获ToolException，转成LLM友好的错误消息：“库存不足，请换SKU”。

示例：一个真实的库存查询Tool

@Tool(description = "查询指定仓库中商品的实时库存数量") @Service public class InventoryTool { @ToolMethod(description = "获取商品在指定仓库的可用库存") public InventoryResponse checkStock( @JsonProperty("sku") @NotBlank String sku, @JsonProperty("warehouse_code") @Pattern(regexp = "^WH[0-9]{3}$") String warehouseCode) { // 调用原有库存服务，逻辑完全不变 return inventoryService.getAvailableStock(sku, warehouseCode); } }

LLM拿到的Schema长这样：

{ "name": "checkStock", "description": "获取商品在指定仓库的可用库存", "parameters": { "type": "object", "properties": { "sku": {"type": "string", "description": "商品编码"}, "warehouse_code": {"type": "string", "description": "仓库编码，格式WH+三位数字"} }, "required": ["sku", "warehouse_code"] } }

注意：不要手写Schema！手写等于给自己挖坑。我们用注解+反射自动生成，Schema永远和代码一致。某次线上事故就是因为手写Schema里warehouse_code写成warehouseId，LLM传参错，库存服务直接500。

3.3 第5-6周：Agent的“小脑”——构建状态管理与会话持久化（对标Spring Session + Redis）

Agent必须记住上下文，但不能全放内存。Java工程师立刻想到：Session + Redis。这一周，你实现AgentSession管理器，把会话状态存Redis，用Spring Session的RedisOperationsSessionRepository做基座，但增加Agent专属能力：

• 状态分层：user_context（用户画像）、conversation_history（对话轮次）、tool_execution_log（工具调用记录）三个Hash结构，避免单Key过大；
• 自动过期：conversation_historyTTL=24h，user_contextTTL=30天，用Redis的EXPIRE命令；
• 增量同步：每次Agent回复后，只推送diff（新增的1轮对话），不是全量覆盖，减少网络IO；
• 跨实例共享：K8s多副本下，用Redis的Pub/Sub通知其他实例清理本地缓存。

关键代码：

@Component public class AgentSessionManager { private final RedisTemplate<String, Object> redisTemplate; // 存储会话状态，Key: agent:session:{sessionId} public void saveSession(String sessionId, AgentSession session) { String key = "agent:session:" + sessionId; redisTemplate.opsForHash().putAll(key, session.toMap()); redisTemplate.expire(key, Duration.ofHours(24)); } // 获取会话，自动合并user_context与conversation_history public AgentSession getSession(String sessionId) { String key = "agent:session:" + sessionId; Map<Object, Object> entries = redisTemplate.opsForHash().entries(key); return AgentSession.fromMap(entries); } }

实操心得：别用In-Memory Session！我们测试过，单机1000并发会话，内存占用飙升到4GB，GC频繁。Redis方案内存占用恒定在200MB以内，且支持水平扩展。某客户从In-Memory切到Redis后，P99延迟从1200ms降到280ms。

3.4 第7-8周：Agent的“决策中枢”——实现ReAct模式的Java版执行引擎（对标Spring Batch的Step编排）

ReAct（Reasoning + Acting）是Agent最主流的范式，但别被名字吓住——它就是Java里的状态机+责任链。这一周，你手写一个ReActExecutor，不依赖LangChain，纯Java实现：

• Reasoning阶段：调用LLM，输入system_prompt + history + user_input，输出结构化JSON：{"thought":"需要查库存","action":"checkStock","action_input":{"sku":"ABC123","warehouse_code":"WH001"}}；
• Acting阶段：解析JSON，反射调用对应Tool，捕获结果或异常；
• Observation阶段：把Tool结果格式化成{"observation":"库存剩余5件"}，追加到history；
• 循环控制：设置最大循环次数（如5次），避免LLM死循环；
• 终止判断：当LLM输出{"final_answer":"..."}时结束。

核心类图：

ReActExecutor ├── LLMClient (注入) ├── ToolRegistry (注册所有@Tool) ├── AgentSessionManager (注入) └── execute(sessionId, userInput) └── while (loop < maxLoop) ├── callLLM() → parse JSON ├── if action → callTool() ├── appendObservation() └── if final_answer → break

注意：LLM的输出必须强制JSON Schema约束！我们在system_prompt里写死：
“你只能输出严格符合以下JSON Schema的字符串，不要任何额外字符：{...}”
否则LLM可能输出“好的，我来帮你查库存——{...}”，导致JSON解析失败。这是90%新手栽的第一个坑。

3.5 第9-12周：Agent的“操作系统”——构建企业级Agent框架（对标Spring Boot Starter）

前八周是零件，这四周是组装。你把所有模块打包成agent-spring-boot-starter，像用spring-boot-starter-web一样简单：

1. pom.xml引入starter；
2. application.yml配置LLM参数、Redis地址、默认Tool；
3. 写一个@AgentController注解，自动注册HTTP端点；
4. 写一个@EnableAgent注解，自动扫描@Tool类并注册。

关键创新点：

• Tool自动注册：用ImportBeanDefinitionRegistrar扫描所有@Tool类，反射生成Schema，存入ToolRegistry单例；
• Endpoint自动暴露：@AgentController标注的类，自动生成/v1/agent/chat端点，接收{ "message": "查库存", "session_id": "abc" }，返回{ "response": "库存5件", "tool_calls": [...] }；
• 配置中心集成：支持Nacos/Apollo，LLM参数、Tool开关、限流阈值均可动态调整；
• 健康检查端点：/actuator/agent返回LLM连通性、Tool可用性、Redis状态。

示例用法：

@AgentController public class EcommerceAgent { @ToolMethod public ProductInfo searchProduct(@NotBlank String keyword) { return productService.search(keyword); } }

启动后，自动注册POST /v1/agent/chat，无需写Controller。

实操心得：Starter的spring.factories文件必须写对，否则Spring Boot不加载。我们踩过坑：org.springframework.boot.autoconfigure.EnableAutoConfiguration=后面多了一个空格，导致所有自动配置失效，调试了6小时才发现。建议用IDEA的Spring Boot插件校验。

3.6 第13-16周：Agent的“感官系统”——集成RAG与向量数据库（对标MyBatis的Mapper层）

RAG（检索增强生成）不是魔法，是Java工程师熟悉的“查库+拼装”。这一阶段，你把Elasticsearch或Milvus接入Agent：

• 索引构建：用Logstash或自研Job，把产品文档、FAQ、政策文件转成向量，存入向量库；
• 检索封装：写VectorSearchService，输入query，返回Top-K相关文档片段；
• Prompt注入：在LLM调用前，把检索结果拼进system_prompt：“参考以下政策原文回答：[文档1]...[文档2]...”；
• 结果溯源：在最终回复里标记引用来源：“根据《XX政策》第3条...”，用<sup>[1]</sup>超链接。

关键技术点：

• 向量化模型选型：中文场景别用text-embedding-ada-002！实测bge-m3模型在中文FAQ检索准确率高22%，且支持多粒度（段落/句子/词）；
• 混合检索：ES的BM25关键词检索 + 向量相似度检索，用bool should组合，召回率提升35%；
• 缓存策略：对高频query（如“怎么退货”）的检索结果，用Caffeine缓存1小时，降低向量库压力。

注意：别让LLM“自由发挥”引用来源！必须用<sup>[1]</sup>硬编码，否则LLM可能编造不存在的条款号。某政务项目因此被审计驳回，要求所有引用必须可点击跳转原文。

3.7 第17-20周：Agent的“免疫系统”——构建安全、合规、可审计的防护层（对标Spring Security）

Agent上线前最后一道关：安全。Java工程师最擅长这个。这一阶段，你加固所有环节：

• 输入净化：用OWASP Java Encoder过滤XSS，对用户输入的HTML标签全部转义；
• 输出脱敏：用自定义@Sensitive注解，自动识别身份证、手机号、银行卡号，返回***；
• 内容安全：集成百度内容安全API，对LLM输出做实时审核，拦截涉政、色情、暴力内容；
• 审计日志：用AOP切面，记录userId、sessionId、input、output、tool_calls、timestamp，存入独立审计库；
• 权限控制：继承Spring Security，Agent调用Tool前校验@PreAuthorize("hasRole('ADMIN')")。

示例脱敏：

public class UserInfo { @Sensitive(type = SensitiveType.ID_CARD) private String idCard; @Sensitive(type = SensitiveType.PHONE) private String phone; } // 返回JSON时自动变成 {"idCard":"110***********1234","phone":"138****5678"}

实操心得：内容安全审核必须同步阻断！我们最初用异步回调，结果LLM已把违规内容返回给用户。改成同步HTTP调用百度API，超时300ms直接返回“内容审核中，请稍候”，宁可慢也不能错。

3.8 第21-24周：Agent的“交付物”——部署、压测、监控全链路（对标Java应用上线SOP）

最后四周，不是写代码，是交付。你用真实业务场景（如电商客服、IT运维助手）跑通全流程：

• K8s部署：Helm Chart打包，values.yaml定义LLM API Key为Secret，CPU/Memory按压测结果配置；
• 全链路压测：用JMeter模拟1000并发，监控JVM GC、Redis QPS、LLM API成功率、P95延迟；
• 故障演练：手动kill Redis Pod，验证Agent是否自动降级为本地缓存+返回友好提示；
• 灰度发布：用Spring Cloud Gateway的WeightedRoutingFilter，5%流量走新Agent，95%走旧系统；
• 效果评估：定义核心指标：tool_call_success_rate > 99.5%、avg_response_time < 800ms、human_fallback_rate < 5%。

关键配置：

# Helm values.yaml resources: limits: cpu: "2" memory: "4Gi" requests: cpu: "1" memory: "2Gi" env: LLM_API_KEY: secretKeyRef: name: llm-secret key: api-key

注意：压测时一定要测“脏数据”！我们故意发10%的SQL注入payload、10%的超长文本（10万字）、10%的乱码，Agent必须全部拦截并返回400 Bad Request，不能崩溃。某次上线前没测乱码，导致Agent OOM，整个客服系统雪崩。

4. 避坑指南：24周里最可能让你放弃的5个“温柔陷阱”

计划很美，现实很骨感。这五个坑，我见了太多Java工程师在里面挣扎数月甚至放弃。它们不难，但极其隐蔽，专挑你放松警惕时下手。

4.1 陷阱一：沉迷Prompt Engineering，忽视工程基建（第1-3周高发）

现象：花两周时间调教LLM的system_prompt，试图让一句话指令就完美调用Tool，结果越调越乱，LLM还是把“查订单”理解成“查库存”。
真相：LLM不是万能的，它是概率模型。你的精力应该花在让Tool调用失败时有明确错误码、有重试逻辑、有降级方案，而不是指望LLM永不犯错。
正确做法：第1周就写好ToolException的全局处理器，所有Tool方法用try-catch包裹，捕获异常后返回结构化错误：“调用库存服务超时，请稍后重试”，LLM看到这个，自然会重试或换思路。Prompt再好，也抵不过一次网络抖动。

4.2 陷阱二：用Python胶水代码调Java服务，制造技术债（第4-6周高发）

现象：为了快速跑通Demo，用Flask写个API，里面subprocess.run(["java", "-jar", "tool.jar"])调Java服务，结果性能差、日志乱、无法监控。
真相：这不是“混合架构”，这是“架构污染”。Java服务的价值在于它的生态，不是它的jar包。
正确做法：把Java服务做成标准Spring Boot微服务，用Feign Client或RestTemplate调用。哪怕只是本地调用，也要走HTTP协议，这样未来拆分成独立服务毫无成本。我们有个客户，初期用subprocess，半年后想拆服务，重写调用层花了3个人月。

4.3 陷阱三：把Agent当黑盒，放弃日志与链路追踪（第7-12周高发）

现象：Agent跑起来能回答问题，但一出错就懵，不知道卡在哪一步：是LLM没返回？Tool没调用？还是Redis连不上？
真相：Agent的每个环节都可能失败，必须像查数据库慢SQL一样查Agent慢调用。
正确做法：强制要求每个关键步骤打日志，且带唯一traceId：

log.info("ReAct step {} start, traceId={}", step, MDC.get("traceId")); // ... 执行逻辑 ... log.info("ReAct step {} end, duration={}ms", step, duration);

配合SkyWalking或Pinpoint，一眼看出是LLM调用慢（2s），还是Tool执行慢（800ms），还是Redis响应慢（500ms）。

4.4 陷阱四：追求“全能Agent”，导致范围失控（第13-16周高发）

现象：想做一个能查库存、能退订单、能改地址、能开票的“超级Agent”，结果每个功能都半吊子，上线后客服投诉率飙升。
真相：Agent的价值不在于“能做什么”，而在于“在某个场景下比人做得更好”。
正确做法：MVP原则。第13周只做“查库存”，做到：

• 准确率>99%（对比人工）
• 响应时间<500ms
• 失败时自动转人工
• 审计日志100%完整
  然后第14周再加“查订单”，逐个击破。我们给某电商做的第一版Agent，只支持“查库存”和“查物流”，但这两个功能解决了60%的客服咨询，ROI立竿见影。

4.5 陷阱五：忽略LLM的“幻觉”，用技术手段兜底（第17-24周高发）

现象：LLM自信满满地编造不存在的政策条款、虚构库存数量、杜撰API参数，用户信以为真，造成实际损失。
真相：“幻觉”是LLM的固有缺陷，无法根除，只能用工程手段围堵。
正确做法：三层防御：

1. 输入侧：对LLM输出做Schema校验，强制{"answer":"...", "sources":[...]}，缺字段就报错；
2. 输出侧：对answer字段做关键词扫描，出现“根据我的知识”、“我记得”等主观表述，自动拦截；
3. 业务侧：所有涉及金额、库存、状态变更的操作，必须二次确认：“您确认要将订单状态改为‘已发货’吗？此操作不可逆。”
   某支付公司因此避免了一次重大资损：LLM曾编造“手续费减免政策”，被第三层确认拦截，人工审核后发现政策已废止。

5. 工具链与资源清单：一份Java工程师能立刻上手的“弹药库”

别再网上大海捞针找教程了。这份清单，是我从20+个生产项目里提炼出的、经过千锤百炼的Java Agent开发弹药库。所有工具都满足：有中文文档、有活跃社区、有Spring Boot Starter、无商业授权风险。

5.1 核心框架与SDK

5.2 开发与调试利器

5.3 生产必备监控组件

5.4 学习资源推荐（纯Java向）

• 官方文档：Spring AI Reference Doc（比LangChain4j文档详细3倍，且有完整Java示例）
• 实战课程：某高校《Java Agent工程实践》MOOC（讲师是Apache Dubbo PMC，全程用Java写Agent，无一行Python）
• 开源项目：spring-ai-samplesGitHub仓库（Spring官方维护，含电商、客服、运维全场景Demo）
• 避坑手册：《Java Agent生产事故汇编》PDF（内部整理，含27个真实故障案例，如“Redis连接池耗尽导致Agent集体失忆”）

最后分享一个小技巧：当你不确定某个LLM行为时，别猜，用JUnit写个测试。比如测试LLM是否遵守JSON Schema：

@Test void shouldReturnValidJsonWhenCallingTool() { String prompt = "调用checkStock工具，参数sku=ABC123"; String response = llmClient.call(prompt); assertThat(response).matches("\\{\\s*\"action\"\\s*:\\s*\"checkStock\".*}"); }

这比看10篇博客都管用。Agent Engineer的本质，就是用Java工程师的严谨，驯服AI的不确定性。