现在几乎所有"AI Agent"框架——不管是 Claude Code、各种 Agent 编排工具，还是自己写的一个几十行的工具调用脚本——底层跑的都是同一个骨架：模型不是一次性把答案吐出来，而是反复经历"想一步、做一步、看结果、再想下一步"，直到任务完成。这个骨架有个具体的名字，叫 ReAct（Reasoning + Acting），来自 Yao 等人 2022 年的论文《ReAct: Synergizing Reasoning and Acting in Language Models》。这篇聊聊这个循环具体是怎么回事、现代 LLM API 是怎么实现它的，以及实践中最容易踩的几个坑。
“AI 要取代程序员了"这句话已经被说了三年多，热度不减，但也越说越空。它更像一句情绪表达，而不是一个可以拿来做决策依据的判断。与其纠结这个非黑即白的问题，不如换个更具体的问法：在后端、企业级开发这个具体场景里，AI 已经实际改变了什么，还没有改变什么，正在改变什么。这篇笔记只谈这个。
大语言模型本质上是无状态的——每次调用，模型对"你是谁"“上次聊了什么"“你喜欢什么风格"一无所知，除非这些信息被显式塞进当前的上下文窗口。这和 RAG 要解决的问题不是一回事：RAG 补的是模型"没见过的知识”，而这里要聊的是模型"没记住的经历”——同一个用户、同一个项目，换一次会话就打回原形，昨天纠正过的错误今天还会再犯一遍。
这两年"多智能体"（Multi-Agent）几乎成了 AI 应用绕不开的话题——Claude Code 里的 subagent、n8n 里的多节点工作流、各种 Agent 编排框架，本质上都在回答同一个问题：一个大模型上下文搞不定的任务，能不能拆成几个更小的、各司其职的智能体来协作完成？
大语言模型（LLM）虽然拥有海量的通用知识，但它的知识边界止于训练数据的截止日期，也无法访问企业内部文档、私有数据库这类"没见过"的信息。想让模型回答这些问题，通常有两条路：**微调（Fine-tuning）把新知识"炼"进参数里，或者RAG（Retrieval-Augmented Generation，检索增强生成）**在回答前先把相关资料"喂"给模型。本文重点讲后者——它的基本原理、数据切片（Chunking）与向量化（Embedding）的具体做法，以及一个经常被混淆的问题：向量化和大模型训练到底是不是一回事。
在使用 MCP（Model Context Protocol，模型上下文协议）构建 AI 应用的过程中，上下文管理是绕不开的核心话题。无论是对话系统、代码助手还是知识库问答，上下文的质量直接决定了 AI 响应的准确性和连贯性。本文结合实际使用经验，聊一聊在 MCP 体系下做好 AI 上下文管理的一些心得。
