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 里描述的往往是项目建立之初的架构,经过数年迭代后与实际代码面目全非。新人按照文档理解出来的心智模型,在实际调试时...
