刚好够用的 Python：为《计算的本质》准备实验语言
上一篇把《计算的本质》的主线压成了一句话：计算就是用有限规则描述可以机械执行的状态变化过程。从这一篇开始，系列进入代码实验。后面的解释器、自动机、图灵机、lambda 演算、抽象解释都需要一套很小的实验语言。 本文选择 Python。它在这里承担两个角色：一方面，代码足够短，方便把注意力留给计算模型；另一方面，Python 和 Java 的距离刚好合适，读者可以看清哪些部分属于模型本身，哪些部分只是语言样板。 本文按 Python 3.12 写代码。大部分示例在 Python 3.10 及以上也能运行，因为结构化模式匹配从 Python 3.10 开始可用。 只需要一只小工具箱 后续文章不会用到完整 Python 知识。实验语言只需要七件工具。 工具 用途 后续出现位置 Java 对照 dataclass 定义不可变语法节点 AST、图灵机配置、lambda 项 record match 按节点类型分派 解释器、规约器 switch + 模式匹配 函数对象 把规则当值传递 指称语义、lambda 演算 Function<T, R> 闭包 保...
重读《计算的本质》：给 Java 程序员的可计算性入门
《计算的本质》容易读散。它表面上在讲 Ruby、抽象语法树、自动机、lambda 演算、停机问题、类型系统，读起来像一串互不相干的经典概念；主线可以压成一句话： 计算就是用有限的规则，描述一个可以机械执行的状态变化过程。 这句话一旦立住，全书就不再是术语集合。第 2 章讲程序语义，是在回答“规则写成程序以后，它到底是什么意思”。第 3、4、5 章讲自动机，是在回答“状态机器多一点存储以后，能力会怎样增长”。第 6、7 章讲 lambda 演算和通用系统，是在回答“形式极其简单的规则，为什么也能表达通用计算”。第 8、9 章讲不可判定性和抽象解释，是在回答“即使计算模型已经足够强，为什么仍然有些问题不能精确解决”。 这套重读系列不打算复述原书。旧文《计算的本质》已经做过概念地图，这个系列换一种路线：用 Python 重写原书的核心实验，并在每一篇里把概念翻译成 Java 程序员熟悉的工程直觉。 为什么原书会显得难 这本书难在视角切换。数学和 Ruby 都会带来阻力，但它们不是最大障碍。 多数业务开发者习惯从库、框架、API、对象协作去理解程序。一个方法能不能跑，通常看参数、返...
AgentScope 全景实战：设计速读与生产级十二层装配
把 AgentScope 当成"另一个 LangChain"是上手时最常见的误区。AgentScope v1.x 在 2025 年中做过一次实质上不向后兼容的 API 重构——v0.x 的 actor-based 多机分布式被整体删除，新核心改为 async-ReAct 循环 + MsgHub 显式消息广播。它的设计取向与 LangChain / LangGraph 也不同：假设开发者从一个 ReActAgent 开始，逐层往外加东西——先有一个 agent 能跑，再共享 LLM 单例，再装工具，再装 MCP，再往上做多 agent 路由，最后接观测和部署。这种"渐进式装配"的次序不是教学方便，是它的实际工程姿态——每一层都能独立验证、独立失败、独立替换。 本文分两部分。第一部分是设计速读：把 AgentScope v1.x 的范式翻转、ReAct + MsgHub 核心抽象、与 LangGraph / CrewAI / MAF 的对位、A2A + MCP 协议化分布式、Trinity-RFT 训练集成讲清楚——理解了"为什么&q...
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 打开 ...
Harness Engineering：长程 Agent 的工程化底座
微信公众号文章《Harness Engineering：让AI Agent长程运行的秘密武器》抓住了一个很重要的行业拐点：Agent 讨论正在从“模型有多强”转向“系统怎么让模型可靠工作”。这个判断是对的，但如果只把 Harness Engineering 理解成“给 Agent 做记忆和交接班”，还是太窄。 更准确的定义是：Harness Engineering 是围绕模型构建一套可执行的工作环境、状态系统、工具边界、验证机制和反馈循环，让 Agent 能跨越单个上下文窗口，持续推进真实任务，并在失败时留下可恢复的证据。 这不是 Prompt Engineering 的升级版，也不是 Context Engineering 的别名。Prompt 解决一次请求怎么说，Context 解决一次请求里放什么，Harness 解决的是任务生命周期怎么被系统托住。 一、为什么 2026 年突然轮到 Harness OpenAI 在 2026 年 2 月发布的 Harness Engineering 文章里披露了一个内部实验：团队从空 Git 仓库开始，用 Codex 构建并发布一个内部...
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 怎么做。 一、坐标系：把"模块化"切成五件事 跨平台比较最容易陷入"功能罗列"。先把坐标系定清楚，对照表才有意义。模块化这个词在工程上至少要拆成五件事： 隔离单元：什么是平台眼里的"一个模块"？文件、命名空间、加载器、还是进程？ 命名空间：同名符号能不能在系统里同时存在两份？ 可见性：模块内部的东西，能...
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 的模块化不是从 JPMS 才开始的。很长一段时间里，classpath 像一条足够宽的路，所有 jar 都往上面放，能跑就行。等应用长大，库的版本开始冲突，内部包被外部代码依赖，插件想热更新，SPI 实现又被错误的类加载器发现，这条路才慢慢暴露出它没有边界的问题。 OSGi、JBoss Modules、Jigsaw（JPMS）都试图在 classpath 之上重新划边界，只是三者选择的边界不一样。OSGi 把运行时动态性放在第一位，JBoss Modules 更关心应用服务器内部的静态隔离，JPMS 则把强封装和可靠配置做进了 Java 平台本身。 类加载器切换是这条线上的另一面。Tomcat reload 之后类没卸掉、OSGi 升级 bundle 之后老对象 ClassCastException、JDBC Driver 把整个 webapp 钉在内存里、Spring Boot DevTools 重启后某个 SPI 实现加载了旧版本，这些现象表面上属于不同框架，根子都在 JVM 的类身份模型：一个类不只由全限定名决定，还由定义它的 ClassLoader 决...
