基本概念 1.工作流 (Workflow) 与 Agent 的异同 Workflow（工作流）： 在 Java 生态中，Workflow 的本质是有限状态机 (FSM) 的高级抽象。无论是传统的 Activiti/Flowable，还是现代的分布式工作流引擎 Temporal，其核心逻辑都是预定义的。 技术本质：它是 Graph-based 的。开发者在编码阶段就定义好了 $Next = f(State, Input)$。 工程优势： 幂等性与重试机制：由于路径确定，我们可以轻松实现节点级别的事务回滚（Saga 模式）或断点续传。 可观测性：每一个 State 的流转都在数据库中有明确记录，审计和排障极其简单。 Java 类比：就像是一个严谨的 Switch-Case 逻辑或 Chain of Responsibility（责任链模式），虽然复杂，但永远在控制之中。 然后比如我们常用的langgraph，Spring AI alibaba graph这些都是基于工作流的。是智能体早期的一个实现。就是相当于把AI作为我们平常链路的一个部分，去调用了下API做推理的任务 然后在工 ...

1. 引言：理解大模型交互的本质 在实际业务场景中，与大语言模型（LLM）的交互，本质上是基于无状态API调用的概率推断过程。由于模型具有发散性思维，如果我们仅提供简单的指令，往往会得到非结构化的长文本、低质量的发散性内容，甚至是“模型幻觉”（Hallucination）。 为了让AI在逻辑推理、内容生产和信息提取等业务流中稳定发挥作用，我们必须通过工程化的手段来约束其输出。提示词（Prompt）就是我们控制大模型输出格式、规范业务逻辑、处理异常边界的核心工具。 2. 提示词的二元结构解析 为了让AI准确理解并执行任务，我们在工程上通常将提示词划分为两个核心层级，它们在模型的注意力权重和功能定位上截然不同： 系统提示词（System Prompt）：定规矩（高权重） 这是智能体的“底层操作系统”。它具有全局最高权重，负责定义AI的角色设定、思维链路（CoT）、可用工具集、硬性规则约束以及异常处理的兜底机制。 用户提示词（User Prompt）：派任务（动态权重） 这是具体的“业务工单”。它结合历史上下文（Memory），告诉AI当前具体的业务诉求是什么、执行任务所需的背景数据在哪里 ...

待思考： 什么是Skills？ 他的好处？为什么这么设计？跟我们直接将提示词按文件划分有什么区别 渐进式披露在skills上怎么体现的，有什么好处？ skills的拆分，我如何确定一个东西可以作为一个skills 然后我提示词命中了多个skills怎么处理？ 跟skills绑定的工具我怎么处理?怎么去按需加载 1.什么是skills？ 在 AI 架构（特别是类似 Semantic Kernel 或各类 Agent 框架）中，Skill（技能/插件）是一个封装了特定领域能力的独立模块。它不仅仅是一段提示词，它是**“意图（Prompt）+ 动作（代码/工具/API）+ 数据结构（输入/输出 schema）”**的集合体。 一个比较完整的 Skill 往往包含： 意图描述：它解决什么问题（适用范围），不解决什么（边界） 触发信号：什么样的用户请求应该命中它（关键词/语义/结构） 工作流程：步骤化 SOP（先做什么、再做什么、失败怎么办） 输入输出契约：需要哪些输入、输出长什么样（模板/字段/格式） 工具策略：需要哪些工具、何时用、参数怎么填、如何校验结果 质量控制：检查清单（自检点） ...

工作流解析 整体工作流的流程图: 123456789101112131415161718192021222324252627flowchart TD A[IntentRecognition] -->|数据分析| B[EvidenceRecall] A -->|闲聊/无关| Z[END] B --> C[QueryEnhance] C --> D[SchemaRecall] D --> E[TableRelation] E --> F[FeasibilityAssessment] F -->|数据分析| G[Planner] F -->|非数据分析| Z G --> H[PlanExecutor] H -->|SQL| I[SqlGenerate] H -->|PYTHON| M[PythonGenerate] H -->|REPORT| R[ReportGenerator] H -->|HumanReview| K[HumanFeedback] K -->|approve| ...

📑 目录 #1-项目概览 #2-核心竞争力分析 #3-技术架构深度解析 #4-性能基准测试详解 #5-jsonb-二进制格式详解 #6-jsonpath-高级用法 #7-feature-系统完全指南 #8-安全性设计与最佳实践 #9-框架集成指南 #10-实战代码示例 #11-性能优化技巧 #12-从其他库迁移指南 #13-常见问题解答 #14-与竞品对比 #15-总结与建议 项目概览 1.1 基本信息 FASTJSON 2 是阿里巴巴开源的新一代高性能 JSON 处理库，是 FASTJSON 1.x 的重大升级版本。 项目名称：FASTJSON2 当前版本：2.0.61 开发语言：Java 最低要求：JDK 8+ 许可协议：Apache License 2.0 代码规模：468 个核心文件，7.2MB 测试覆盖：3421 个测试文件 提交历史：5953 次提交 文档数量：190 份 Markdown 文档 1.2 设计目标 FASTJSON2 的设计目标是为未来十年提供极致优化的 JSON 库： 极致性能 - 相比 1.x 提升 2-3 倍，远超竞品 功能完整 - 支持 ...

背景 前面我们谈到了Spring boot 4.0版本的升级，然后对应的Spring AI 也进行维护两个大版本，一个是1.x的版本对应Spring boot的3.x版本，一个是我们的Spring AI 2.x对应我们Springboot的4.x版本，那我们来比较下这两个版本究竟有什么的不同吧！ 变化 Spring Boot 4.0 升级 - 从 3.5.8 升级到 4.0.0，这是一个主要版本升级 JDK 21.0.8+ 强制要求 - 通过 maven-enforcer-plugin 强制执行，开发环境必须升级 空值处理增强，多个核心 API 返回类型标记为 @Nullable： ChatModel.call() 可能返回 null ChatResponse.getResult() 可能返回 null Message.getText() 可能返回 null 这个也是Spring boot4.x版本做出的一个新的改变 比如说我们的ChatModel 接口 call(String message) 返回类型：String → @Nullable String cal ...

背景 最近Spring AI 发布了2.0.0的测试版本，标志着SrpingAi社区开始维护1.x版本和2.x版本。然后发现里面最大的一个区别就是Spring boot版本的升级，由之前的3.x版本升级到了4.x版本 我们首先来看下Spring boot的版本升级，为什么会再去开一个版本分支去维护呢？ Springboot4.0 Spring Boot 4.0.0 的发布，不仅仅是一个版本号的简单的递增，它标志着 Spring 生态系统正式迈入了基于 Spring Framework 7.0、Java 17/25 以及 Jakarta EE 11 的全新纪元。对于当前运行在 Spring Boot 3.5.8 的企业级应用而言，向 4.0.0 的迁移不仅是一次技术栈的升级，更是一次对底层基础设施、开发范式以及运维观测体系的全面现代化重构 。 新旧版本的对比： 核心组件 Spring Boot 3.5.8 (当前状态) Spring Boot 4.0.0 (目标状态) 架构影响分析 Spring Framework 6.2.x 7.0.x 引入了全新的 Bean 注册机制、 ...

基础知识 对比分析系统调用与一般用户程序及库函数的区别。 系统调用 (System Call)：运行在内核态，通过类似硬件中断的“陷入机制（Trap）”向操作系统内核请求服务。目的是让用户程序能安全、受控地使用硬件资源。 用户程序 (User Program)：运行在用户态，执行普通指令，不能直接访问硬件。 库函数 (Library Function)：是将常用功能封装好的代码集合（如 printf），在编译阶段链接到程序中。库函数内部可能会调用系统调用，也可能不调用。 简述引导程序（Bootloader）两个阶段的主要任务。 第一阶段：主要负责硬件初始化（如关闭中断、初始化CPU），设置堆栈，并将第二阶段的代码从存储介质复制到 RAM 中。 第二阶段：负责检测系统内存映像，将内核映像和根文件系统映像读入 RAM，设置内核启动参数，最后调用内核。 论述进程与程序的区别与联系。 区别： 进程是动态的，强调执行过程，是资源分配和独立运行的基本单位。 程序是静态的，是一组指令的集合，存储在磁盘上。 联系：进程是程序的执行实例，一个程序可以对应多个进程（例如打开了三个浏览器窗口 ...

智能工具选择：利用 Spring AI 的动态工具发现功能节省 34-64% 的 Token 开销 背景 随着 AI Agent 连接的服务越来越多——Slack、GitHub、Jira、MCP 服务器——工具库也在迅速膨胀。一个典型的多服务器配置往往包含 50 多个工具，在对话开始前就可能消耗 55,000 多个 Token。更糟糕的是，当模型面对 30 多个命名相似的工具时，工具选择的准确率会显著下降。 由 Anthropic 首创的 工具搜索工具（Tool Search Tool） 模式解决了这个问题：模型不再一次性加载所有工具定义，而是按需发现工具。最初，它只接收一个搜索工具，在需要时查询相关能力，然后将相关的工具定义扩展到上下文中。这种方法在保持对数百个工具访问能力的同时，实现了 显著的 Token 节省。 关键洞察： 虽然 Anthropic 是为 Claude 引入了这种模式，但我们可以利用 Spring AI 的 递归增强器（Recursive Advisors） 为 任何 LLM 实现相同的方法。Spring AI 提供了一个可移植的抽象层，使得动态工具发现功能可以在 ...

1. 背景与痛点 随着 AI Agent 接入的业务系统越来越复杂，一个 Agent 往往挂载了数十甚至上百个工具（Tools）。在传统的实现中，我们需要将所有工具的定义（Schema）一次性注入到 Prompt 上下文中。这带来了两个严重问题： Token 消耗巨大：海量的工具描述占用了宝贵的 Context Window，增加了推理成本。 模型注意力分散：面对大量无关工具，模型容易产生幻觉或选择错误的工具。 Spring AI 社区提出了 Tool Search 模式来解决此问题。作为 Spring AI Alibaba（SAA）社区向核心标准对齐的重要一步，我们结合 SAA 自身的 Graph Agent（图计算 Agent） 架构，重新设计并实现了这一特性。与 Spring AI 原生基于 ChatClient 的实现不同，SAA 版本将逻辑封装在 Graph 节点与拦截器中，使其更适应复杂的 Agent 工作流。 2. 设计思路：Lazy Loading 与 动态注入 核心思想是**“按需加载”（Lazy Loading）**： 初始阶段：不向 LLM 暴露任何具体的业 ...

当 JSON 字符串中包含无引号的数字 key 时，fastjson2 的反序列化行为不一致 BUG描述&&原因 当 JSON 字符串中包含无引号的数字 key 时，fastjson2 的反序列化行为不一致 字段存在的时候可以正确处理无引号数字 key 的逻辑 字段不存在的时候无法处理 具体改动 在 skipObject 方法中添加对无引号数字 key 的处理逻辑 在utf16/utf-8中 新增了一个重载方法 skipNumber(..., boolean allowColon)，允许在跳过数字后紧跟着冒号（:），这在处理未加引号的数字作为键的 JSON 结构时是必需的。 在判断数字结束字符时，新增了 !(allowColon && ch == ':') 条件，即如果允许冒号且当前字符是冒号，则不抛出错误。 在解析对象键值对时，增加了对未加引号的数字作为键的处理逻辑。 如果当前字符是数字或 '-' '+'，则认为这是一个未加引号的数字键，调用 skipNumber(..., true) 来跳过数字，并手动跳过紧随其后的冒号和空白字符。 否则，退回到原 ...