分类
说明： 本文根据个人学习整理，系统架构设计师 论文结构提纲，以高并发性能优化为例子，仅供大家参考，学习交流。
论文结构分为三部分：摘要+正文+结尾
简要概述论文涉及的项目，包括项目建设时间、建设背景、项目规模、开发周期及本人承担的主要职责。
说明项目面临的高并发需求，以及开展性能优化的原因，概括采用的整体优化思路和主要技术手段。
最后点明论文的论述结构，即围绕高并发性能优化，从项目实践、关键技术和问题解决三个方面展开论述。
介绍项目的建设原因、业务目标、服务对象及业务场景，说明系统为什么存在高并发访...
这两年，大语言模型发展得很快。
从最初用 DeepSeek，ChatGPT查资料，到后来使用 Cursor，Codex 等写代码，再到后来把大模型接进自己的应用里，从整接入到应用地过程中，发现一件事：让模型生成一段回答不难(先不提模型幻觉的问题)，真正让它深度参与业务中、把一件事情做完，就需要把大模型当成一个“同事”来考虑。
比如，一个销售助手不仅要回答问题，还得查询业务数据、分析客户情况，再根据结果给出建议。
光靠一次模型调用显然不够。系统需要知道什么时候该查数据、该调用哪个工具，拿到结果后还要判断下一步怎么走。
这也是我开始要深入研究 Agent 的原因。
经历了接近2年的发展，...
在学习 Agent 时，经常会遇到一些反复出现的术语，比如 LLM、RAG、Tool Calling、Workflow、MCP 。
术语多了就容易混乱，有个表多看几遍，就不容易忘记了。这份表按主题整理常见概念，重点解释“它是什么、解决什么问题”。
对术语有了清晰地认识，方便学习后续的文章，也方便后续阅读，可以随时回来查阅。
| 术语 | 英文全称 | 简要解释 |
|---|---|---|
| LLM | Large Language Model | 大语言模型，负责理解输入、生成内容，也可根据任务判断下一步操作。 |
| Prompt | — | 提示词，提供任务指令、背景信息、输出要求和行为约束。 |
| Token | — | ... |
与大模型聊天，它能告诉你 FastAPI 接口慢该查什么。它列得可能还挺专业：数据库慢查询、外部请求超时、CPU 和内存、日志、并发。然后呢？
你还得 SSH 上服务器，翻日志，跑 SQL，看接口耗时和 APM。
它没有这些工具，也没有相应授权，就只能停在“建议”这一步。
回答问题和完成任务，中间隔着工具、权限和执行。Agent 值得研究，原因就在这里。
再换个场景。让大模型总结公司最近一周销售情况，它会告诉你统计销售额、订单数、客户转化率。
它会让你提供数据，因为它访问不了业务数据库，所以到最后还是得你把数据导出来，再喂给它分析。
这类任务一旦涉及多个步骤、外部数...
上一篇文章说，Agent 是让模型在“判断下一步”和“执行一步”之间循环。
这篇把这个循环岔开看看，还是用天气提醒这个场景。
用户说：“查一下天津今天的天气，如果下雨，提醒我带伞。”
普通大预言模型接收到这个信息它会怎么处理？
它可能回你一段：“我会搜索天气网今日天津天气，你也可以打开天气应用查询天津今天天气，如果显示有雨，记得带伞。”
提醒也没建。模型生成了一段回答，任务并没有往前推进。
Agent 要做的不是生成这段回答，而是把这个任务拆成几轮，一轮一轮往前推。
用户内容输入进来之后，系统不是直接把整段话扔给模型让它“完成这个任务”。
更准确地说...
很多人在开发时，都会遇到这样一种情况：
这时候最常见的问题就是：
“如何把一个已有代码目录，配置成 Git 仓库？”
今天这篇文章，就带你完整走一遍。
适合：
全部通用。
简单理解：
Git 会在你的项目里创建一个：
.git/
隐藏目录。
这个目录会记录：
也就是说：
...
很多人觉得 Git 难，其实真正高频使用的命令可能只有几个。别一上来学分支和工作流，先完成你的第一次提交。代码管理的第一步，不是复杂，而是开始。
git --version
# 查看 Git 是否安装成功
git config --global user.name "你的名字"
# 配置 Git 用户名
git config --global user.email "你的邮箱"
# 配置 Git 邮箱
cd git-demo
# 进入项目目录
git init
# 初始化 Git 仓库
git add hello.txt
# 添加指定文件到暂存区
git ...很多人第一次用 Git 时，都会遇到一个很尴尬的问题：明明已经写了 .gitignore，为什么文件还是被提交上去了？
比如：
node_modules/
.env
dist/
看起来没毛病，对吧？
可现实往往是：node_modules 还在 Git 里，.env 也已经被提交过，甚至团队成员一拉代码，发现你的本地配置、日志文件、构建产物全都混进了仓库。
.gitignore 是 Git 里非常基础的文件，但它背后的规则并不总是直觉化。今天这篇文章，我们就用最接地气的方式，把 .gitignore 的写法、常见坑和最佳实践一次讲清楚。
| 命令 | 中文注释 |
|---|---|
gi... |
很多人学 Git 时，最先记住的命令是：
git add .
git commit -m "fix bug"
git push
可一旦项目真正开始协作，你会发现：
真正有价值的，不是“怎么提交代码”，而是“怎么理解代码为什么变成现在这样”。
这时候，git log 就开始变得重要了。
它不是一串无聊的提交记录。 它更像项目的“时间机器”。
你能从里面看到：
很多高级开发者排查问题时，第一反应不是打开 IDE，而是先看 git log。
很多人第一次学 Git 分支时，都会觉得它像一种“黑魔法”。
明明：
更离谱的是：
git checkout dev
短短一秒钟，整个项目居然就“变了”。
于是很多人开始背命令：
git branch
git checkout
git merge
git rebase
命令会用了。
但心里始终有个疑问：
Git 分支，到底是什么？
这篇文章，我们不聊复杂源码，也不讲晦涩概念。
只做一件事：
用人话，真正理解 Git 分支的工作原理。
看完之后，你会明白：