MyBatis 内部架构深度解析：从 Mapper 方法到 JDBC 执行链
MyBatis 的内部结构并不复杂，但很容易被看散：SqlSession、MapperProxy、MappedStatement、Executor、StatementHandler、TypeHandler、一级缓存、二级缓存、插件链分别出现在不同包里，单看任何一个类都像是局部技巧。把它们放回完整调用链之后，MyBatis 的设计会变得很清楚： MyBatis 的核心不是“把对象自动映射成表”，而是“把 Java 方法稳定地映射到一条可执行的 SQL 描述，再把执行过程拆成可替换的流水线组件”。 本文以 MyBatis 3.5.19 的官方文档与源码 XRef 为基准，重点讨论 MyBatis 运行时内部架构，不展开 MyBatis-Spring 的事务同步、Spring Boot 自动装配，也不讨论 MyBatis-Plus 等增强框架。 总体架构 MyBatis 可以分成两条主线：构建期主线和执行期主线。 构建期负责把 XML、注解、类型别名、类型处理器、插件、缓存配置等材料编译成一个 Configuration 对象。执行期从 SqlSessionFactory 打开 ...
Agent 全景指南：从必要性、范式演化到高可用落地
导语 Agent 在过去三年从概念走向生产，但围绕它的讨论一直分散在三个不同的层面：什么是 Agent、Agent 形态如何演化、以及如何把 Agent 真正构建成可用产品。这三个问题彼此独立又互相支撑——不理解定义就难以分辨技术争议，不理解演化就把握不到当前最佳实践，不理解落地就停留在 Demo 阶段。 本文把这三层一次梳理清楚：第 1-2 章解决"是什么、为什么"，第 3-4 章解决"演化到了哪里、每个模块发生了什么变化"，第 5-6 章解决"实际怎么构建一个高可用 Agent"。 第 1 章 Agent 概念与争议 1.1 Agent 的本义：代理 vs 智能体 Agent 这个词在英文语境下的原义是"代理人"，但也带有"代理"的含义。国内学术界、工业界很多翻译为"智能体"，强调其"智能化"和"自主决策"能力；另一派则倾向译为"代理"，更贴合英文中"代理人做某件事情"的本意。 ...
模块化与动态加载的跨平台对照：从 ClassLoader 到 BEAM、ALC、dlmopen
写在前面 这篇是 《从 OSGi 到 Jigsaw：Java 模块化、SPI 与类加载器切换的真相》 的续篇。前文只在 Java 一个语种内部比较 OSGi、JBoss Modules、JPMS 三套方案。这篇把视野拉宽——其他主流平台对"模块化、动态加载、热替换"这套问题各自给出了怎样的回答，谁的方案到工业级别还活着，谁干脆放弃了。 讨论的对象是六家：.NET（CoreCLR）、Erlang/BEAM、Node.js（ESM）、Python（CPython）、C/C++（dlopen 系）、Go。每一家都拿同一组问题去问：模块身份是什么、谁来隔离、能不能加新版、能不能卸老版、老对象怎么办、SPI 怎么做。 一、坐标系：把"模块化"切成五件事 跨平台比较最容易陷入"功能罗列"。先把坐标系定清楚，对照表才有意义。模块化这个词在工程上至少要拆成五件事： 隔离单元：什么是平台眼里的"一个模块"？文件、命名空间、加载器、还是进程？ 命名空间：同名符号能不能在系统里同时存在两份？ 可见性：模块内部的东西，能...
AgentScope 上手教程：从空仓库到 Multi-Agent 工单系统（循序渐进九层架构）
把 AgentScope 当成"另一个 LangChain"是上手时最常见的误区。AgentScope v1.x 的设计取向与 LangChain / LangGraph 不同——它假设你从一个 ReActAgent 开始，逐层往外加东西：先有一个 agent 能跑，再共享 LLM 单例，再装工具，再装 MCP，再往上做多 agent 路由，最后接观测和部署。这种"渐进式装配"的次序不是教学方便，是它的实际工程姿态——每一层都能独立验证、独立失败、独立替换。 本文把这个层级骨架完整走一遍，配套代码可在空仓库上从零跑通到一个具备路由能力的 multi-agent 工单系统。所有业务术语都已通用化处理（订单工单 / 配送单 / 售后单 / 客服坐席），不绑定任何具体行业。 如果你需要先理解 AgentScope 的设计哲学（v0 actor → v1 ReAct 的范式翻转、与 LangGraph / CrewAI 的差异），先读 《AgentScope 深度解析：Python 智能体框架的 ReAct 与 MsgHub 范式》。 本文采用一个...
Spring AI 深度：把 LLM 抽象成新一代 JDBC（兼论 LangChain4j 与 Java 智能体框架路线）
把 Spring AI 放进 2026 年的智能体框架版图里看，一个反直觉的事实是：Spring 团队刻意没把它做成一个 agent framework。这个项目的官方使命是"connecting your enterprise Data and APIs with the AI Models"——不是"让你的 Java 系统拥有自主智能体"，而是"让 LLM 像 JDBC、JMS、WebClient 那样成为企业系统里一个可插拔的中间件"。理解这一刻意克制，才能理解 Spring AI 与 LangChain4j 的差异、Spring AI 与 Spring AI Alibaba 的分工、以及为什么 Java 圈的智能体路线天然分成"原子能力 SDK"与"行为预设 framework"两层。 本文以 Spring AI 1.x 为主轴，覆盖 LangChain4j、Spring AI Alibaba、Microsoft Semantic Kernel 在 JVM 生态里的实际位置...
从 Java 8 到 Java 25 的迁移与 Spring 升级指南
Java 8 发布于 2014 年，距今已逾十年。尽管 Oracle 对 Java 8 的商业支持延续至 2030 年，但语言特性、运行时性能、安全补丁以及生态兼容性已显著落后于当前主流版本。Spring Boot 3.0 起将基线提升至 Java 17，Spring Framework 6 全面转向 Jakarta EE 命名空间，这意味着继续使用 Java 8 的团队将在框架升级、依赖兼容性以及云原生部署方面面临越来越高的隐性成本。 本文梳理从 Java 8 迁移到 Java 25（当前最新 LTS）的完整路径，并同步覆盖 Spring Boot 2.x 到 3.x 的升级要点。内容基于 Oracle 官方迁移指南、Spring 项目 Wiki、OpenJDK JEP 文档以及生产环境的实际迁移案例。 LTS 版本路线图与迁移节奏 Java 采用严格的半年发布周期，每三年指定一个 LTS（Long-Term Support）版本。从 Java 8 到 Java 25，历经四个 LTS 节点： 版本 发布时间 LTS 状态 关键特性 Java 8 2014-0...
从 OSGi 到 Jigsaw：Java 模块化、SPI 与类加载器切换的真相
写在前面 本文回答三件事。第一件，为什么 Java 在 classpath 之上又要造 OSGi、JBoss Modules、Jigsaw（JPMS）这些"模块化"层；它们各自把哪一类问题摆在最高优先级。第二件，"切换类加载器"这件事到底是什么意思——是切线程上下文，是用新加载器装新类，还是把老的整个加载器换掉；不同的语义下，老的对象实例分别会发生什么。第三件，SPI（service-provider interface）为什么是模块化和 CL 切换的真正交汇点——ServiceLoader 默认靠 TCCL 找实现，DriverManager 是反 SPI 的活化石，JPMS 把 SPI 直接编进了 module-info，OSGi 干脆用 Service Registry 替换了它。 后两件事是工程里反复出问题的源头：Tomcat reload 之后类没卸掉、OSGi 升级 bundle 之后老对象 ClassCastException、JDBC Driver 把整个 webapp 钉在内存里、Spring Boot DevTools ...
大语言模型为什么像人在说话和思考：语言能力、思考能力与可解释性边界
2026 年 5 月 17 日，新浪转载了李航、张少华、林苑的一篇文章《大语言模型为什么能像人一样说话和思考？》。这篇文章有一个很好的切入点：它没有停在“LLM 是不是鹦鹉学舌”这种二元争论里，而是把问题拆成三层：LLM 表现出来的语言与推理能力是什么；这些能力如何由训练目标、模型结构、算法和数据共同形成；现有可解释性研究能否从模型内部看到一些机制证据。 这篇文章最值得延展的地方，不是“LLM 已经像人一样思考”这个标题式问题，而是它背后的一个判断：Next Token Prediction 只是表层形式，真正的能力来自大规模统计学习在语言结构中压出的高阶模式。但这里还需要再补一层区分：语言能力和思考能力不是同一件事。语言能力负责理解、组织和生成符号；思考能力负责在符号背后维持目标、约束、变量、因果关系和推理路径。二者在人类身上高度纠缠，在 LLM 身上也高度纠缠，但机制分析时必须分开。否则很容易把“说得像人”误判成“想得像人”，也容易把“推理失败”误判成“语言能力失败”。如果把这个判断继续往下挖，会看到 2022 年以来 mechanistic interpretability...
递归语言模型 RLM 推理范式深读
一句话结论 Recursive Language Models（RLM）不是一种新的模型架构，而是一种推理时的脚手架（inference-time scaffold）：它把长 prompt 当作 REPL 环境里的一个变量，让根 LLM 通过写 Python 代码去切片、检索、并递归地把片段交给子 LLM 处理，最终再把答案聚合回来。它和 Mixture-of-Recursions（MoR）等"递归 Transformer 架构"是两类完全不同的工作，常被混淆。 来源：Alex L. Zhang、Tim Kraska、Omar Khattab，MIT CSAIL，arXiv:2512.24601（v1 2025-12-31，v3 2026-05-11）；同名博文 2025-10。 问题背景：为什么"长上下文"研究让人不满意 社区里有一个"context rot"的提法，Anthropic 给出的口径是：随着上下文 token 数增长，模型从上下文中准确召回信息的能力会下降。但 RLM 论文一开篇就指出，这个口径并不完全...
用 Skill 和 Agent 攻克老旧历史项目的学习与分析难题
接手一个有年头的项目，最令人头疼的从来不是代码本身，而是代码背后那些无处可查的决策脉络。文档年久失修甚至不存在，当年的设计者早已离职，模块之间的耦合关系像一团纠缠的毛线——拉一根就牵动一片。Infosys 的研究数据显示，开发者 35% 的工作时间花在理解已有系统上，而非编写新功能。ThoughtWorks 技术雷达也明确推荐用 GenAI 理解那些"低自描述性、低凝聚力"的遗留代码库。 2025-2026 年间，AI 编码工具从补全助手演变为自主 Agent，Skill 机制又让这些 Agent 的行为变得可编排、可复用、可版本控制。这两者的结合，正在从根本上改变"读懂老项目"这件事的效率天花板。 老项目学习的四重困境 Martin Fowler 团队在一篇关于 AI 辅助入职的文章中，把遗留代码库的学习困境归纳得相当准确。结合多个来源的观察，核心痛点可以归结为四类。 文档与代码的脱节。入职文档、wiki 页面、README 里描述的往往是项目建立之初的架构，经过数年迭代后与实际代码面目全非。新人按照文档理解出来的心智模型，在实际调试时...
