- 博客(74)
- 收藏
- 关注
RSS订阅原创 D1 · 融合蓝图：Spring AI + 虚拟线程 + 服务网格——现代后端统一底座
系列第 15 篇 / D 线第 1 篇（全系列收官）视角：架构师选型 · 深度长文 · 总纲14 篇分开看是 14 个选型决策，合起来是一座现代后端系统的骨架。
2026-08-20 09:22:18
345
原创 C4 · Serverless 与 Java 冷启动——C 线收官
系列第 14 篇 / C 线第 4 篇（C 线 4/4 收官）视角：架构师选型 · 深度长文Java 开发者被「JVM 不适合短生命周期计算」这句话骗了十年。真相不是 JVM 不行，是你的部署模型选错了——而 2026 年，冷启动这道题有了三种成熟解法，不再是非此即彼。
2026-08-20 09:21:44
312
原创 C3 · 适度微服务——反过度拆分的务实回归
不是「按文件夹分模块」的约定（约定会在 6 个 sprint 后腐化），而是在代码层面强制模块边界/src/billing/internal # 其他模块禁止 importapi.ts # 唯一公开面/catalog/internalapi.ts/shipping/internalapi.ts规则：每个模块只暴露一个api.ts作为公开面；任何其他模块不得 import。用 lint 规则（ESLint boundaries 插件）或构建期检查在 CI 里让违反边界的提交直接失败。
2026-08-18 08:55:34
324
原创 C2 · OpenTelemetry 统一可观测——Trace/Metric/Log 一把梭
系列第 12 篇 / C 线第 2 篇（云原生治理 2/4）视角：架构师选型 · 深度长文衔接：C1 服务网格（网格追踪天然 OTLP）→ B6 AI 护栏与可观测（gen_ai.*GenAI 约定）→ A 线 Java 后端演进（虚拟线程 / GraalVM 原生镜像）
2026-08-18 08:53:30
405
原创 C1 · 服务网格 2026 怎么选——Ambient、eBPF 与 Linkerd 三足鼎立
过去五年，"服务网格 = 每 pod 注入一个 Envoy sidecar"是默认答案。空闲 RAM 乘法：500 个 pod = 500 个代理，每个 50–150MB，仅 idle 就吃掉几十 GB；每跳延迟：一次跨三服务的请求，sidecar Istio 付 3–9ms（每跳 1–3ms）；运维摩擦：istiod 把一堆 CRD 编译成 Envoy 配置推下去，路由不灵时调试面很重；故障排查更难：多了好多"会动的零件"。正是因为这些成本，加上最普遍的用例（L4 mTLS）其实用共享组件。
2026-08-17 09:03:20
578
原创 B6 · AI 护栏与可观测——生产化的最后一道门
怎么把 AI 系统搭起来。B1 说架构比模型重要，eval harness 是七动作之首；B2 把检索卫生拆成工程手册；B3 把后端能力用 MCP 标准化成可被调用的工具；B4 把一堆 MCP Server 编排成多智能体，Control Plane 管治理；B5 在 Control Plane 里做模型路由，把成本砍 60–80%。但搭起来 ≠ 能上生产。上生产的真正门槛，是"搭起来之后怎么不翻车"。
2026-08-17 08:57:34
590
原创 B5 · 模型路由与成本——架构师的省钱放大器
把本篇 §7 的四个坑和 B4 的可观测/评估收口成"护栏 + 评估 + 追踪"的生产化体系——guardrails、LLM-as-judge、OTel GenAI 语义约定、回退与红线。B 线在此收官，再进 C 线（云原生治理）。回扣全系列：架构优先于模型（B1）。路由是这句话的财务表达——
2026-08-17 08:54:46
163
原创 B4 · Agentic 与多智能体 Control Plane——多智能体 = 新型微服务，编排面才是护城河
系列第 8 篇 · B 线（AI 工程化）第 4 篇定位：架构师选型视角 · 深度长文承接：B1（架构优先）/ B2（RAG 知识层）/ B3（MCP 工具层）衔接：B5（模型路由与成本——Control Plane 里的 Model Gateway 正是其落点）
2026-08-13 14:45:51
337
原创 B3 · MCP 通解——把后端工具/数据用统一协议喂给大模型
系列第 7 篇 · B 线（AI 工程化）第 3 篇定位：架构师选型视角 · 深度长文承接：B1《架构优先于模型》（架构优先）、B2《RAG 实战》（检索即能力）衔接：B4《Agentic 与多智能体 Control Plane》（MCP 服务 = 新型微服务）
2026-08-13 14:45:24
445
原创 B2 · RAG 实战——检索卫生决定 80% 效果
RAG 的成败，80% 写在检索这一半。分块定边界、embedding 定召回地基、混合检索补漏、rerank 定精度、GraphRAG 只在多跳长尾上买单。把这些关逐一钉死、逐一度量，demo 才变成系统。赢在 RAG 的不是模型最好的团队，是检索卫生最好的团队。本篇为系列第 6 篇（B 线第 2 篇）。已交付：A1–A4 + B1 + B2。下一篇：B3《MCP 通解——把后端工具/数据用统一协议喂给大模型》。
2026-08-12 16:12:53
282
原创 B1 · 架构优先于模型——AI 工程化的最大认知误区
A 线我们解决了"底座稳不稳"（Java 后端演进）；B 线要解决"增量大不大、ROI 高不高"。模型会趋同、会降价、会被替换；你围绕它建的系统，才是别人抄不走的护城河。记住这张判断树——换模型救不了的，去改架构；会被模型耦合的，去做抽象层。剩下的 B2–B6，都是把这六层一层层钉死的工程细节。本篇为系列第 5 篇（B 线首篇）。已交付：A1–A4（Java 后端演进）+ 本篇。下一篇：B2《RAG 实战——检索卫生决定 80% 效果》。
2026-08-12 16:06:01
248
原创 A4 · Spring Boot 4 迁移清单——架构师的平滑升级作战手册
升级从来不是纯技术问题，是时间窗口问题。老版本的安全补丁正在消失：Spring Framework 6.2.x 的社区开源支持已于2026-06 终止，不再有公开安全更新。停在 6.x 意味着你的底座在合规视角上已"裸奔"。官方缓冲带还在3.5.x 的支持期到 2026-11。这是你现在能安全停留的最晚版本——错过这个窗口，再想升级就要面对更严重的技术债。新底座能力是对齐的。
2026-08-12 16:01:21
375
原创 Java 后端 2026 演进（三）：GraalVM 原生镜像与 AOT——架构师的云成本杀手锏
普通 JVM：启动时加载类 → JIT 编译热点 → 预热后达峰值性能。在构建期做 AOT 编译，把可达代码直接编译成机器码，产出自包含二进制。核心约束叫封闭世界假设（Closed-World Assumption）：编译器在构建时必须知道"哪些类会被加载"。凡是它证明不可达的，就被丢弃——这正是体积小、内存低的原因，也是反射/动态代理/运行时类加载需要显式声明的原因。
2026-08-12 16:00:47
390
原创 Java 后端 2026 演进（二）：JDK 21/25 升级实战与 GC 选型——架构师决策手册
系列定位：Java 后端演进主线 · 第 2 篇 · 面向架构师选型视角读者：负责 JDK 升级治理、GC 调优与稳定性保障的技术负责人 / 架构师接上篇：A1《虚拟线程落地——架构师并发模型选型与 ROI》
2026-08-11 08:49:57
872
原创 Java 后端 2026 演进（一）：虚拟线程落地——架构师的并发模型选型与 ROI
系列定位：Java 后端演进主线 · 第 1 篇 · 面向架构师选型视角读者：需要做技术选型、评估改造成本与收益的技术负责人 / 架构师配套热点：2026 后端与 AI 工程热点技术地图（见对话首图）
2026-08-11 08:49:45
450
原创 基础概念：基座是什么（Base Model ）
下面结合你一直在看的 Qwen、Llama、GLM、Ollama、Agent、Function Calling 把概念拆透。基座（Base Model / 预训练基座）：只经过海量文本预训练、没有针对 “对话” 微调的原始大模型。我们日常聊天用的模型，是基座二次加工后的成品。① 基座 Base Model。1、两个核心名词区分。
2026-08-11 08:49:28
438
原创 基础概念：Ollama & vLLM 完整讲解
UC Berkeley 开源的高吞吐LLM推理服务引擎，面向线上API服务，目标榨干NVIDIA GPU算力。底层基于PyTorch，原生支持HuggingFace格式模型（FP16、AWQ、GPTQ量化），不原生支持GGUF。
2026-08-10 08:46:39
283
原创 第九章：总结——一张图回顾 + 优缺点直说 + 决策清单
写这个系列的时候，我想起 2015 年刚接触 Spring Boot 的感觉——当时大家还在纠结 XML 配置、Tomcat 部署，Spring Boot 说"别折腾了，一行命令跑起来"。它把 AI 能力从"算法工程师的玩具"变成了"后端工程师的工具"。你不需要学 Transformer 原理、不需要研究采样策略、不需要手写 JSON 解析。你只需要一行的ChatClient、一行的@Tool、一行的——剩下的，专注写你的业务逻辑。当然，它不完美。Agent 编排不够强、文档案例偏少、社区还在成长。
2026-08-10 08:46:03
515
原创 第七章：多模态——图片理解、语音转文字
上一章做完 RAG，你的 AI 已经能"读文档"了。这一章再给它装上"眼睛"和"耳朵"——让它能看图、能听语音。：多模态在实际业务中的使用频率远低于 Chat + RAG + Function Calling。但有些场景不用它还真不行，所以这一章轻量但实用。
2026-08-10 08:45:21
427
原创 第六章：RAG 实战——让你的 AI 能“读“你的文档
这是全系列最重的一章，也是落地价值最大的章节。前面五章，AI 一直在"用自己的知识"回答问题。它不知道你的公司内部规定、不知道你的产品文档、不知道你的项目代码。这一章，我们给它装上一双"眼睛"——让它能读你的文档，基于你的资料回答问题。
2026-08-08 13:38:55
187
原创 第五章：Function Calling——让 AI 能调用你的业务接口
Service@Tool(description = "根据订单号查询订单详情，返回订单状态、金额、物流信息")@ToolParam(description = "订单号，通常是ORD开头的字符串") String orderNumber) {@Tool(description = "根据用户ID查询该用户最近的所有订单")@ToolParam(description = "用户ID") Long userId,
2026-08-08 10:35:39
153
原创 第四章：结构化输出——让 AI 返回 Java 对象，别再自己正则解析
JsonProperty("sentiment") String sentiment, // 正面/负面/中性@JsonProperty("confidence") double confidence, // 置信度 0~1@JsonProperty("brief_summary") String briefSummary // 一句话总结) {}用明确指定 JSON 字段名，因为 Java 的驼峰命名和 JSON 的下划线命名不一致时，AI 可能搞混。
2026-08-07 23:03:51
191
原创 第三章：Prompt 管理——别再拼字符串了
如果只是写个 Demo，这足够了。这一章教你从"拼字符串"进化到"像管 SQL 一样管 Prompt"。
2026-08-07 23:03:20
313
原创 第一章：先唠明白，Spring AI 到底是个啥？
我带你一句话搞清楚它的定位——说白了，你写 Spring Boot 项目，想接大模型（ChatGPT、通义千问、DeepSeek……），以前你怎么办？自己写 HTTP 请求，拼 JSON，处理流式响应，适配各家不同的 API 格式，写一堆工具类。如果明天你觉得 OpenAI 太贵要切到 DeepSeek，改一行配置完事，业务代码零改动——这就是 Spring AI 最大价值。
2026-08-07 22:39:36
401
原创 第40章 Spring AI 实战：企业级 AI 应用架构
前面6个阶段的代码示例，Python 占了大多数。但如果你是 Java 后端团队——团队会的是 Spring Boot，运维的是 JVM，积累的是 Spring Cloud 生态——那你的 AI 应用开发主战场应该是 Spring AI。Spring AI 是 Spring 官方推出的 AI 应用开发框架，2024年正式发布1.0正式版。它的定位很明确：让 Java 开发者用 Spring 的方式开发 AI 应用。Spring AI vs LangChain（Python）对比维度Spring
2026-08-06 08:39:50
330
原创 第39章 评估迭代：上线只是开始，迭代才是关键
先说一个让很多人不舒服的事实：AI系统不是"建好就完事"的项目，而是"养一辈子"的孩子。传统软件的逻辑是：需求分析→开发→测试→上线→维护。上线之后只要不改代码，系统行为就是确定的。AI系统的逻辑是：数据训练→部署上线→监控→发现问题→调数据/调Prompt/调参数→重新评估→灰度上线→监控……永远循环。为什么AI系统会"自己变坏"？一个健康的AI系统迭代流程长这样：每个环节都不可或缺，跳过任何一步都会出问题：下面逐个环节展开讲。上一章讲了可观测性，这里讲怎么从监控数据中发现需要迭代的信号。39.4
2026-08-06 08:39:34
324
原创 第38章 可观测性：上线了出问题怎么查
AI可观测性的核心认知：四大支柱缺一不可— 指标、追踪、日志、质量监控。前三者是传统系统也有的，第四个（质量监控）是AI系统特有的，也是最容易被忽略的。静默故障是最危险的— AI系统不会报500错误，但它会"一本正经地胡说八道"。没有质量监控，你根本不知道出了问题。链路追踪是排障利器— AI请求内部有预处理→检索→重排序→生成→后处理多个阶段，不看链路追踪你永远不知道是哪个环节慢。质量监控三层体系— 实时信号（用户行为）→ 采样评估（LLM-as-Judge）→ 定期全量（测试集），三个层次互补。
2026-08-06 08:39:18
322
原创 第37章 安全防护：有人会故意“骗“你的AI
先看一个真实场景。你的客服AI有这样一个System Prompt：正常用户问"我的额度是多少"，AI回答"请告诉我您的客户等级"。但攻击者来了：三句话，攻击者就把你的内部规则全套出来了。这不是代码漏洞，不是SQL注入，不是XSS——是你的模型"太配合了"。这就是AI安全的核心挑战：攻击面从"代码"变成了"语言"。大白话： 传统安全是"城墙防御"——堵住已知漏洞就行。AI安全是"社交工程防御"——你防的不是技术攻击，是话术攻击。攻击原理： 在用户输入中嵌入指令，覆盖或绕过System Prompt的约束
2026-08-06 08:39:00
416
原创 第36章 性能优化：用户等3秒就跑了，别让AI太慢
流式输出是第一优先级— 不是真的变快，而是让用户感觉不慢。首字500ms出来，用户就觉得"开始了"量化几乎必选— INT4让速度提升2-3倍、显存省75%，效果只差1-2%。不量化就是浪费Continuous Batching是吞吐量杀手锏— vLLM的动态批处理让GPU利用率从15%提升到68%，吞吐量提升5-10倍缓存是性能倍增器— 精确缓存+语义缓存，30%+的请求直接返回，零延迟零成本Prefix Caching是免费午餐。
2026-08-06 08:38:38
396
原创 第35章 成本控制：一次调用几分钱，量大了一月烧几万
先加缓存、再分级路由、然后精简Prompt——这三板斧下去，成本至少降50%，而且用户体验几乎无感知。
2026-08-05 09:50:17
221
原创 第34章 架构设计：别让大模型成为系统单点
Component@Autowired// 1. 关键词匹配FROM faqLIMIT 1""";// 提取关键词ps -> {},));if (!// 去停用词，提取核心词List<String> stopwords = List.of("的", "了", "是", "在", "我", "你", "他","什么", "怎么", "如何", "为什么", "请问", "一下");？!！]+"))
2026-08-05 09:45:22
303
原创 第33章 实战案例：从零搭建一个完整的Agent系统
先定义Agent要用的4个工具。工具描述写得好，Agent就聪明；写得烂，Agent就犯蠢。# 工具1：搜索引擎"""搜索互联网获取相关网页列表。何时使用：当你需要查找某个主题的信息时。何时不用：当你已经有足够的资料时，不要重复搜索。参数：query: 搜索关键词，要具体明确，比如"Rust语言 2024 发展趋势"num_results: 返回结果数量，默认5条，最多10条返回：搜索结果列表（标题+URL+摘要），JSON格式"""
2026-08-05 09:42:07
218
原创 第32章 记忆机制：让Agent不只是“金鱼脑“
先看一个真实场景：这就是没有记忆的Agent——每轮对话都是"新的一天"。用技术话说：每次请求都是独立的，上下文窗口之外的对话全部丢失。记忆要解决的核心问题：大白话： 记忆让Agent从"接客服电话的临时工"变成"跟了你三年的私人助理"。Agent的记忆系统跟人脑的记忆系统很像——也分短期记忆和长期记忆，只不过多了个"工作记忆"的概念。是什么： 就是当前对话窗口里的内容，模型天然能"看到"最近几轮对话。原理： 大模型推理时，把历史对话拼在Prompt里一起输入。上下文窗口越大，能记住的对话越多。特点：大
2026-08-05 09:36:41
185
原创 第31章 工作流编排：多个Agent组队干活
不是所有任务都需要多Agent。但当你发现单Agent的Prompt越来越长、工具越来越多、效果越来越差时，就该考虑拆分成多Agent了。
2026-08-05 09:18:13
150
原创 第30章 ReAct模式：想一步做一步看结果，跟人干活一个套路
ReAct让Agent从"反射式"（刺激→反应）升级为"反思式"（刺激→思考→行动→观察→再思考）。
2026-08-04 09:32:27
160
原创 第29章 Function Call：给AI一把瑞士军刀
工具定义是Function Call中最关键的部分。模型完全靠你的描述来决定用不用这个工具、怎么传参数。描述写得烂，模型就会乱用或不用。"name": "search_products", // 1. 函数名：简洁明确"description": "根据关键词搜索商品，返回商品列表。支持按价格、销量排序。当用户想找商品、比价、查看商品信息时使用。", // 2. 描述：说清楚干什么+什么时候用"parameters": { // 3. 参数Schema：每个参数的类型和描述。
2026-08-04 09:27:24
264
原创 第28章 Agent概念：让AI学会用工具干活
Function Call是让大模型输出"我要调用某个函数+参数"的能力，而不是输出一段文字。普通对话：用户：明天北京天气怎么样？模型：我无法获取实时天气信息，建议您查看天气预报。用户：明天北京天气怎么样？模型：[调用 get_weather(city="北京", date="2026-08-05")]系统：[执行函数，返回结果] 晴，25℃模型：明天北京晴天，气温25℃，适合出行。对话太长时，自动把旧对话压缩成摘要。# 超过最大消息数，触发摘要"""把旧消息压缩成摘要"""
2026-08-04 09:22:25
325
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人