沉淀技术 · 分享成长 · 持续进化
大模型（如 ChatGPT、DeepSeek）本身只能"聊天"，它无法查数据库、发邮件、操作文件。如果给大模型装上"手和脚"（工具），再给它"大脑"（规划能力）和"记忆"（上下文），它就变成了一个能真正干活的 Agent。这篇文章梳理 AI Agent 的核心概念：从 Function Calling 到 MCP，从 Skill 到 A2A，帮你建立完整的工具生态认知。
典型回答
大模型大家都知道，比如我们常见的ChatGPT、DeepSeek等，但是，这些大模型都有一个关键的问题，那就是他们没办法用工具，比如我想要让大模型帮我查询一个接口，他是做不到的。
大语言模型（LLM）是当下技术圈最火的话题。但很多人对它的认知停留在"能聊天"的层面。作为开发者，你需要理解：大模型擅长什么、不擅长什么、幻觉怎么解决、RAG 和微调的区别、向量数据库的原理。这些知识既是面试热点，也是实际开发 AI 应用的基础。
典型回答
大模型非常擅长做生成内容、代码编写、文本处理、多模态任务，但它对高精度计算、事实准确性、实时数据获取存在局限性。
Python 有 LangChain，Java 有什么？Spring AI 是 Spring 官方推出的 AI 应用开发框架（2025年5月发布 1.0），它通过标准化的 API 封装，让 Java 开发者也能轻松对接大模型、实现 RAG、Function Calling 和对话记忆。如果你的项目是 Spring Boot 技术栈，Spring AI 就是最自然的选择。
典型回答
Spring ai是Spring官方推出的ai应用开发框架，最近（2025年5月20）刚刚发布1.0版本，他的主要作用就是通过提供各种API的封装来降低用Java开发大模型应用的门槛。
你在浏览器里输入一个网址，不到一秒钟，页面就出来了。但你有没有想过，这一秒钟里到底发生了什么？你的数据是怎么穿过网线、路由器、光缆，跑到千里之外的服务器上，又带着网页内容跑回来的？
这背后是一整套精心设计的网络体系在运作。这篇文章就来把计算机网络这件事掰开揉碎讲清楚。我们会用快递运输做类比，从整体架构讲到具体协议，让你真正理解网络通信的全貌。
要理解网络，先得理解"分层"的思想。
想象一下你要寄一个包裹。你不需要关心快递员怎么骑车、走哪条高速公路、在哪个中转站分拣，你只需要把东西打包好、填好地址就行。网络通信也是一样的道理：每一层各司其职，只和相邻层打交道。
互联网的世界并不太平。你写的每一行代码，都可能成为攻击者的突破口。SQL 注入可以让黑客拖走你的整个数据库，XSS 可以让用户的 Cookie 被偷走，CSRF 可以让用户在不知情的情况下转走自己的钱，DDoS 可以让你的服务器直接瘫痪。
好消息是，大多数攻击都有成熟的防御手段。这篇文章我们来学习最常见的 Web 攻击方式以及对应的防御策略，再聊聊加密算法的基础知识。知道怎么被攻击，才能知道怎么防御。
SQL 注入是最经典的 Web 攻击之一。它的原理简单到令人发指：攻击者在用户输入中插入恶意 SQL 代码，让数据库执行非预期的查询。
想象你是一家大型公司的 CEO。公司里有各种资源：办公室、打印机、网络带宽、会议室。员工们各自有各自的任务，他们需要公平地共享这些资源，而你需要协调一切，确保公司高效运转。
操作系统就是计算机世界里的那位 CEO。 它管理着 CPU、内存、磁盘、网络等硬件资源，协调着各个应用程序的运行，让你可以"同时"听歌、写代码、刷网页——尽管 CPU 在任意一个瞬间其实只在做一件事。
当你按下电源键，计算机会依次完成这些步骤：
先想一个问题：你有没有遇到过这样的代码——Service 层有几千行，一个方法里塞了查库、校验、计算、调用外部接口、发消息等各种逻辑，改一行代码就怕影响十行？
这就是传统 MVC 架构的典型痛点：业务逻辑全部散落在 Service 层。项目初期觉得简单直接，但随着业务复杂度增长，Service 变成了一个大杂烩——既负责流程编排，又负责业务规则，还负责数据转换。你想改一个计费规则，得翻遍整个 Service 才能确认改全了没有。
DDD（Domain-Driven Design，领域驱动设计）的核心主张是：软件开发的核心是理解业务，而不是实现技术。 先理解业务领域、建立领域模型，再考虑技术实现——而不是上来就画表、写 SQL。
你有没有遇到过这样的场景——打开一个 App 发现页面白屏，刷新几次也没用，心里默念"又挂了"？
作为用户，你只是刷新了几次然后换了个 App。但作为开发者，这几分钟的不可用可能意味着大量的订单损失、用户投诉，甚至公关危机。
高可用 (High Availability) 的目标就是：让系统在各种异常情况下，依然能够正常对外提供服务。 不是不出问题——世上没有永远不出问题的系统——而是出了问题能扛住、能自愈、能快速恢复。
就像人不可能永远不生病，但一个免疫力强的人，生了小病能自己扛过去，生了大病能快速就医恢复。高可用架构做的就是提升系统的"免疫力"。
想象一下双 11 零点的淘宝 -- 几亿用户同时点击"立即购买"，每一秒涌入的请求比平时多出几十上百倍。服务器就像一家只有 5 个服务员的餐厅，突然涌进来 500 位客人。如果没有任何应对措施，这家餐厅只会陷入混乱，谁也吃不上饭。
高并发的本质，是在有限的资源下，尽可能多地处理请求，同时保证系统不崩溃。
要做到这一点，我们有三大武器，也有三道防线。接下来一个一个聊。
在深入限流、降级、熔断之前，先了解最基础的三板斧。
去迪士尼玩过的朋友一定有这个体验：每个项目入口处都有一块小牌子，写着"预计等候时间 45 分钟"。你看到这个时间就会心里盘算 -- 45 分钟可以接受吗？要不要换个项目？
对于一个网站来说，用户做的判断和这一模一样。页面加载超过 3 秒，一半的用户就会离开。后端接口响应超过 1 秒，前端体验就会明显变差。
高性能的本质，就是让系统用最短的时间、最少的资源，处理尽可能多的请求。
要聊高性能，我们得先把几个核心指标搞清楚。