2024年被认为是AI应用落地的元年，AI开始在日常生活、智能终端落地，2025年则被行业认为是智能体（Agent）元年，AI从“听令行事”到能“主动服务”了，行业相关的产品也越来越丰富。

AI 发展很快，跟朋友交流 AI 的一些处理方案时，发现很多关于记忆、上下文不管什么语言基本都是类似套路的通用方案，朋友好奇为什么没人去沉淀为框架？
其实原因很简单，AI 发展太快了，大佬们也都在探索和尝试，现在去沉淀一是没有精力二是还不稳定，一切都是变化中。

回顾 Spring ，发展了多少年，在 Spring 之前出了多少框架，最后才让 Spring 一统江湖。

作为开发，来看看天天使用的一些开源框架怎么引入 AI ，或者来感受一下作者的 AI 焦虑感

不靠近他就没法了解他，太靠近他又会被伤害，技术学习也是一种投资，投资早了可能后面技术被淘汰了，浪费精力；投资晚了又可能别人都起飞了你还不知何物。

Arthas

Java 应用的线上诊断“瑞士军刀”，能让你在不重启服务的情况

年初看到阿里博客 arthas-agent，运维相当高效，所以想引入一下。

特意找了阿里朋友，原来 arthas-agent 只在内部使用，但外部可以借助 arthas MCP 自行搭建 agent

[Agent开发-对接arthas mcp server]

这就是引入 AI 的第一种方式：提供 MCP Server

MCP 的主要目的在于解决当前 AI 模型因数据孤岛限制而无法充分发挥潜力的难题，MCP 使得 AI 应用能够安全地访问和操作本地及远程数据，为 AI 应用提供了连接万物的接口

XXL-JOB

第一眼看到 xxljob 的 release log，就觉得很神奇，一个任务调度系统，这么纯粹的系统，怎么要引入 AI？有什么神奇的地方

从 3.1.0 开始，它多接了一类任务：到点以后，不是只去跑一段 Java 或一条 SQL，还可以去问本地大模型、去跑一条 Dify 工作流，或者把一段话交给 OpenClaw。调度中心还是原来的调度中心，变的是执行器这一侧，AI 被收成了普通的 Bean 任务

翻阅了下源码，里面只是把调用大模型底层代码做了一些封装。方便各种 AI 的调用。

比如 ollamaJobHandler： OllamaChat任务，支持自定义prompt、input等输入信息。

示例任务入参如下：

{
  "input": "{输入信息，必填信息}",
  "prompt": "{模型prompt，可选信息}",
  "model": "{模型实现，如qwen3.5:0.8b，可选信息}"
}

可以看出作者对 AI 跟踪，相当紧密。最早的 OpenClaw 都适配了

对作者这种精神很钦佩，但但个人感觉很没有必要。猜测作者有 AI 焦虑。

回头看，现在有几人还记得 OpenClaw？后面大概率还得把这个踢除

再者，一个业务系统对于 AI 的诉求怎么只会在任务调度，作为主流 Spring 体系下，引入 spring-ai 不是更香吗？谁会从一个辅助系统去引入一个未来的 AI 体系

再者，引入 AI 希望调用大模型更方便，同理，那当初为什么不去内置实现一个 ORM 来执行一次 SQL

这是引入 AI 的第二种方式：提供底层大模型调用封装

LiteFlow

发现这个，是因为之前解决 [LiteFlow线程池饥饿死锁.md] ，深入理解框架原理和特性。

发现了作者对 AI 的理解以及应用

一、首先有一个 AI Skill , How2useLiteFlow

AI 对 LiteFlow 只是「一知半解」。它的训练语料里 LiteFlow 的内容既不全也不新，遇到不确定的地方又倾向于「编一个看起来对的」，于是生成出跑不起来、甚至误导人的代码。

How2useLiteFlow 就是为了解决这个问题——它是一个让 AI 正确使用 LiteFlow（v2.16.X） 的 Agent Skill (opens new window)。装上它之后，你的 AI 在写 LiteFlow 相关代码时，会以官方文档与源码蒸馏出的知识为准，不杜撰、不拿网络内容充当 LiteFlow 的行为依据。

二、AI Agent

过去五年，LiteFlow 始终在回答同一个问题：当业务逻辑越来越庞杂，我们该如何把它组织得清晰、可控、可复用？我们给出的答案是”编排”——把一个个独立的逻辑单元，用一套简洁的表达式自由地串联、并联、嵌套起来。

整个软件世界正在被同一股力量重新塑造：AI 正在从一个可选项，变成业务系统里一个绕不开的角色

这一两年，AI 这个词已经被说烂了。但凡一个框架、一个产品，不挂上点 AI 都不好意思发版。
所以请允许我们先把丑话讲在前头：这次 2.16.0 带来的，并不是一个”大模型组件”。

其实在 2.16.0 之前，就已经有不少公司用 LiteFlow 在跑 AI 业务了——他们在自己的组件里直接调用大模型，LiteFlow 则在背后充当后端编排引擎，把一次次模型调用串成完整的业务链路。这条路一直走得通，我们也无意去抢它：今天调一次大模型实在太容易了，new 一个 client、发个请求，我们再官方包一个”大模型组件”出来，纯属画蛇添足。

我们这次想做的，是另一件本质上完全不同的事——把 Re-Act Agent 做成 LiteFlow 的组件。

总结

AI 的确加剧了人的焦虑，而且减少社会变革的适应时长。不像以前从马车到火车，有一段时间来让人类适应，而 AI 带的时间压迫很强烈。

一个要被 AI 淘汰的程序员，还得无奈研究 AI 。
像对中医和西医的区别，西医就是让人明明白白地死去，而中医却让人糊里糊涂地活着

最近看到 Kafka 有人也在暴露 MCP，未来会不会这样的，所有组件包括业务系统，都要提供 MCP，让大模型去理解和调度，在 Harness 的保障下最终系统稳定运行

码农戏码

AI加持开源系统的方式

Arthas

XXL-JOB

LiteFlow

总结