本文探讨在Java项目中使用编码智能体时，如何通过规范驱动开发在工程意图与开发效率之间取得平衡。作者回顾了从SLDD、OpenSpec、Spec Kit到SBCE等实践，指出规范不应只在一次变更期间发挥作用，而应成为随代码持续演进的活规范。针对大量未采用BCE架构的存量Java项目，作者提出SDD4J流程，通过架构适配器将业务能力映射到项目既有结构中，并使用可测试、可追踪的EARS需求连接规范、测试与实现。核心目标是让规范贴近代码，使偏离可见、收敛成本更低，从而帮助开发者和智能体持续理解并校验组件所承诺的行为。

文章要旨 Kubernetes中的Java/Spring Boot应用常因JVM在每次启动时重复加载数万类而延迟就绪。Docker构建的不可变镜像非常适合配合JVM的类数据共享（CDS）机制：在构建阶段执行一次训练运行，将解析好的类元数据保存为 .jsa 档案，容器启动时直接映射到内存，跳过重复解析。 Spring Boot 3.3 可通过 -Dspring.context.exit=onRefresh 在无需外部依赖的情况下完整走完启动流程并退出，从而生成CDS档案。文章给出一个多阶段Dockerfile示例：先将fat jar解包，再运行训练RUN，并通过 JAVA_TOOL_OPTIONS 指定 -XX:SharedArchiveFile。典型效果是把Spring Boot 3 Web服务从10–12秒降到5–7秒；档案可跨JVM共享，减少内存占用。需用 -Xlog:class+load 确认档案生效；训练仅覆盖启动路径，不是全流量热加载。相比GraalVM Native Image，CDS只需几行Dockerfile，保持普通JVM工作方式，并与未来Project Leyden兼容。

本文是该系列第三部分，介绍如何使用Java与Spring AI完成智能体仓储管理系统（WMS）中的执行阶段。智能体按计划依次执行任务，并通过能力绑定只开放相应工具，保证操作可控。在分析任务中，智能体通过工具获取库存、发票与库存移动等运营数据；在策略任务中，借助向量检索与RAG读取仓储委托方的自然语言业务策略；在决策任务中，结合上下文判断是否需要补货，并输出明确标记。若无需补货则跳过后续任务，否则通过工具创建补货申请并草拟通知邮件。作者还提出下一步可为智能体添加跨执行记忆，使其参考历史结果优化决策。

本文介绍如何使用Java和Spring AI构建智能体驱动的仓库管理系统第二部分的实现。内容从设计转向编码，重点说明如何定义智能体的能力与边界、如何在出库流程完成后触发智能体，以及如何由规划器将目标转化为可执行的计划。系统围绕规划器、执行器和报告器三大组件设计，并定义了分析、策略、决策、补货、通知等能力。每个能力绑定特定工具，从而限制智能体只能在其权限范围内执行操作。业务事务提交后发布事件，智能体以异步方式启动，规划器结合目标和可用能力生成带状态的任务列表，并持久化到MongoDB中。文章还展示了AgentDefinition、PlannedTask等核心代码结构和运行示例，为第三部分讲解任务执行与工具调用打下基础。

作者结合自身在银行业和物流业八年多的经验，提出了智能体仓库管理系统（Agentic WMS）的实践思路。文章以入库、出库、库存和补货请求等核心流程为例，说明传统确定性规则（如库存低于阈值即触发补货）在遇到短期促销等特殊场景时会产生误判。AI智能体不会替代既有库存计算、校验、持久化等确定性逻辑，而是在出库完成后通过规划、分析、决策、行动四个步骤，利用受控工具查看历史库存变动、未完成补货和托管方政策等上下文，判断当前是否需要补货并执行相应操作。这种方式让系统在保持核心业务可靠的同时，具备根据真实业务语境进行判断和决策的能力，也是后续用 Java 与 Spring AI 实现智能体流程的基础。

任何输入/输出操作，无论是访问文件、处理HTTP请求，还是建立数据库连接，都依赖于三个基础系统概念：文件描述符、内核内存和堆大小。这三个概念也是应用扩展时的主要瓶颈。默认情况下，单个进程可用的文件描述符数量有限，耗尽后内核只能通过队列暂存新请求；TCP读写缓冲区占用的内核内存不可交换到磁盘，海量连接会消耗大量物理内存；连接对象在应用堆中占用空间，尤其TLS连接会显著增加堆开销，高并发时容易触发GC thrashing。现代语言运行时有各自的缓解策略：Go尽量将短期对象分配在栈上，并通过sync.Pool复用缓冲区；JVM则采用G1GC、ZGC等并发收集器来减少停顿。文章最后提供了判断扩容时机的信号，包括文件描述符使用率、内核网络内存压力以及GC CPU占比等指标。

文章用一个真实的JVM缺陷做了对照实验：同一模型、同一提示，分别采用仅按堆栈和源码推理的Superpowers工作流，以及允许读取断点变量和调用栈的Explyt调试工作流。前者直接给出try/catch修复，掩盖了目录为空和无权限读取的差异，并为测试修改了公共API；后者先通过调试器复现失败，在断点处确认异常和调用栈，修复仅停留在文件系统边界。作者借此提醒：Files.isDirectory只回答是否为目录，不保证可以Files.list；Windows ACL使两个问题相互独立。两次运行分别约132k和67k token，作者认为不能据此泛化，应衡量整个Agent运行过程，并列出检查清单：Agent是否真正复现失败、是否观察到运行时事实、修复是否改变返回值语义等。

Kotlin Toolchain 0.12.0 正式发布，带来多平台库发布、Wasm 应用支持预览、命令行 Compose Hot Reload 和多项 IDE 增强。多平台库发布现已覆盖 JVM、Android、iOS 和 Wasm 等目标，并优化了 Maven Central 发布文件数量；Wasm JS 应用可直接构建并配合 kotlin run 运行。命令行 Hot Reload 还新增 MCP 服务器支持，便于 AI 代理控制应用。IDE 方面增强 Compose Preview、Compose 资源、Android Lint、Live Edit 及 iOS 运行配置。工具链最低要求更新为 JDK 17 与 Kotlin 2.2.20，内置默认版本升级至 Kotlin 2.4.10、JDK 25 等。klibs.io 已在生产环境使用该工具链。

作者讲述了为Spring Boot代码库构建静态分析器的经历，重点探讨为何分析器会错误地声称某个端点没有数据库操作。问题根源在于Spring的很多行为并不会在调用点直接显现：接口与实现类可能共同定义路由，框架会自动执行@ModelAttribute方法，Spring Data会生成源码中不存在的方法，@Transactional常声明在类上，事件监听器与异步任务也缺乏显式调用关系。文章强调，覆盖完整性只能证明未发现，而不是断言不存在；审查代码修改时，应把“这一步不会影响数据库或事务”当作需要证据支持的结论，而非默认假设。