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 决...
大语言模型为什么像人在说话和思考：语言能力、思考能力与可解释性边界
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 里描述的往往是项目建立之初的架构，经过数年迭代后与实际代码面目全非。新人按照文档理解出来的心智模型，在实际调试时...
缓存系统设计全景——从原理到生产的完整指南
缓存是提升系统性能的第一利器，但也是引发故障的第一杀手。从缓存穿透、击穿、雪崩三大经典问题，到多级缓存架构、分布式锁、热点 Key 治理，缓存设计几乎贯穿后端工程师的整个职业生涯。 本文将系统性地剖析缓存系统的设计原则与生产实践，从单机进程内缓存到分布式 Redis 集群，从理论模型到可落地的代码方案，构建一套完整的缓存知识体系。 mindmap root((缓存架构)) 何时使用 读多写少 热点集中 可容忍最终一致性 缓存层次 近端缓存 Guava Caffeine EhCache 远端缓存 Redis Memcached 核心挑战 更新策略 Cache Aside Read Through Write Through Write Behind 一致性保障 故障防护 击穿防护 雪崩防...
