大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



 
【导语】
 

对 Agent 进行初步学习与实践尝试后，我认识到 Agent 的本质是利用软件工程对大模型能力、外部工具与控制流的工程化编排，为此，除去编程能力的学习，想更好更清晰的进行Agent的相关学习与开发，我先将大模型相关的关键知识点，特点与各种“黑话”和专业术语理解清楚。随记旨在将大模型从各种名词与黑话中层层剖析，解剖它的每一个关节，希望能在开发中将项目组装成一个能干活、会思考、可协作的智能体。求做到：原理不放过一个细节，工程不遗漏一个坑点，思考不回避一个问题。

---

热衷于搭建复杂的Agent系统，却连大模型“怎么吐出下一个字”都一知半解，就像造火箭却不懂热力学定律，最终只会陷入调参玄学和黑话堆砌。本卷将解析AI圈的概念包装，还原大语言模型最底层的运转规则，搞懂Agent架构的“物理基石”——对底层规则的理解深度，直接决定了搭建的Agent系统的上限。

1. 概念祛魅：从 LLM 到 Agent，AI 圈的黑话到底在说些什么？

AI行业的“造词运动”，本质上是把基础软件工程操作，包装成了充满科幻感的新概念。我们把所有高频黑话一次性打回原形：

• LLM（大语言模型）：本质是一个超大规模的“文字接龙概率模型”。它没有自主意识，没有真实记忆，核心能力只有一件事：根据上文，预测下一个Token出现的概率，逐字生成文本。它天生只能一问一答，无法自主追问，更无法主动改变外部世界。
• Prompt（提示词）：给大模型下达的指令与约束。分为两层：
  • System Prompt：给模型定下的底层人设与规则，相当于员工入职时的岗位说明书；
  • User Prompt：用户每次输入的具体需求，相当于单次任务工单。
• Context（上下文）：每次请求中，一并喂给大模型的所有背景信息。你以为模型“记住了之前的对话”，本质是聊天程序把历史聊天记录，偷偷拼接到了新请求的末尾，一次性打包发给了模型——所谓的记忆，全靠上下文拼接实现。
• Memory（记忆）：为了让无状态的大模型看起来“有记忆”，而设计的上下文管理机制。核心就是把历史对话、工具执行结果等信息，按规则整理后塞进上下文，伪装成模型的长期记忆。
• Function Calling（函数调用）：大模型与外部程序的“沟通协议”。模型和代码无法直接对话，于是双方约定了一套固定的JSON格式：模型按格式输出要调用的函数名和参数，外部程序解析后执行代码，再把结果返回给模型。这套格式约定，就是Function Calling。
• Agent（智能体）：给关在小黑屋里的大模型，装上“四肢与感官”的中间程序。纯大模型只能输出文本，无法联网、无法读写本地文件、无法执行代码；而Agent就是那个中间人，它负责和大模型对话，解析模型的指令，替它完成所有外部操作，再把结果反馈回去。Agent的本质，就是大模型+外部执行程序的组合体。

2. 运转引擎：大模型到底怎么吐出下一个字？

大模型的生成过程，本质是一套严丝合缝的数学流水线，全程分为三个核心环节，没有任何玄学：

第一步：Tokenizer——人类语言与模型之间的翻译官兼无损压缩机

大模型的底层全是矩阵运算，只认识数字，根本不认识文字。Tokenizer就是两者之间的桥梁，核心负责编码与解码两个动作：

• 编码（Encoding）：把人类文字转换成模型能读懂的数字
  • 切分（Tokenize）：把输入的句子，切成一个个最小的语义碎片，这些碎片就是Token。切分规则不是人工写的，而是通过BPE（字节对编码）算法训练出来的：先把海量文本打散成单字，再把高频同时出现的字/词不断合并，最终形成一套词表与合并规则。
  • 映射（Mapping）：把每个切好的Token，对应到词表里唯一的数字编号（Token ID），一句话最终变成一串纯数字数组，喂给模型。
• 解码（Decoding）：把模型输出的数字，反向映射回人类文字。模型每次只会吐出一个Token ID，Tokenizer拿着这个数字查表，转回对应的Token文本，显示在屏幕上。

 核心本质：Tokenizer不只是翻译机，更是无损压缩机。比如“你喜欢人工智能吗？”9个汉字，会被合并成「你」「喜欢」「人工智能」「吗？」4个Token，直接把输入长度压缩了一半以上，大幅降低算力成本，提升推理速度。

业界通用换算规则：

• 1个Token ≈ 1.5~2个汉字
• 1个Token ≈ 0.75个英文单词（4个英文字母）
• ⚠️ 实战预警：上下文窗口是上限，不是建议值。实际使用时，建议保留20-30%的余量给模型的输出和中间推理。塞满窗口会导致推理速度急剧下降，且模型容易“晕车”失忆。

第二步：Softmax——把分数转换成可抽奖的概率分布

模型拿到Token数组后，经过内部Transformer层的矩阵运算，会遍历整个词表，给每个可能接在下文的Token打出一个原始分数（Logits）。比如输入“推荐一个讲AI的频道”，模型会输出：

[马克: 2.1分, 科技: 2.0分, AI: 1.8分, 自行车: -1.2分, hello: -1.5分]

这些分数有正有负，总和也不等于1，无法直接用来采样。此时Softmax函数登场：它会把所有原始分数，转换成加起来等于100%的概率分布。上面的例子经过Softmax转换后，会变成：

[马克: 36%, 科技: 32%, AI: 26%, 自行车: 3%, hello: 2%]

第三步：加权采样——轮盘抽奖决定下一个字

模型绝不会“谁分高就永远输出谁”——否则所有回答都会千篇一律。它会在0-100%之间生成一个随机数，落在哪个概率区间，就输出对应的Token。

这个过程会不断循环：输出一个Token后，把它拼回上文，再重新计算下一个Token的概率，直到输出终止符，整个生成过程结束。

3. 创造力控制台：如何精准控制模型的“性格”？

Temperature与Top-p，是控制模型生成行为的两大核心旋钮。它们看似都能调节“随机性”，但下刀位置、作用逻辑完全不同，用错了就会出现要么死板、要么胡言乱语的问题。

Temperature（温度）：缩放概率差距的放大器

Temperature直接作用在Softmax函数的分母上，核心公式为：调整后分数 = 原始Logits / Temperature。它的本质，是拉大或缩小不同Token之间的概率差距，就像物理学里的温度控制分子运动：

• 低温模式（T=0.1~0.3，冰冻状态）：分数被放大10倍以上，原本微小的分差会被指数级拉大，形成赢家通吃的局面。比如原本36%概率的“马克”，概率会暴涨到71%，其他词的概率暴跌。
  • 宏观表现：模型极度保守、严谨、输出稳定，几乎不会跑偏。
  • 实战场景：代码生成、数学计算、合同审核、数据报表等零容错场景。
• 高温模式（T=1.5~2.0，沸腾状态）：分数被大幅缩小，所有Token的概率被拉平，原本只有3%概率的“自行车”，可能会涨到9%。
  • 宏观表现：模型脑洞大开、发散性强、不可预测性高，容易出现新奇的表达。
  • 实战场景：小说创作、头脑风暴、文案创意、提示词生成等需要创造力的场景。

Top-p（核采样）：砍掉垃圾词的冷酷保安

哪怕Temperature设置正常，词表里依然有大量低概率的长尾垃圾词，只要生成的字数足够多，总有概率抽中这些词，导致模型幻觉和跑题。Top-p就是专门解决这个问题的闸门，核心逻辑是：

1. 把词表里的所有Token，按概率从高到低排序；
2. 从最高概率开始累加，直到累加和达到你设定的Top-p阈值（比如0.9，即90%）；
3. 立刻关门，把排在后面的所有长尾词全部砍掉，只保留累加范围内的Token，再把这些Token的概率重新归一化到100%，进行采样。

比如Top-p=0.9时，36%+32%+26%=94%，超过了90%的阈值，保安会直接砍掉“自行车”“hello”等所有低概率词，只在前三个词里抽奖；如果Top-p=0.6，累加完前两个词就达到了68%，连“AI”都会被砍掉，只能在前两个词里二选一。

终极实战准则

• 两者的核心区别：Temperature控制的是“概率差距的缩放”，决定了模型创意的幅度；Top-p控制的是“垃圾词的截断门槛”，决定了模型跑题的底线。
• 官方**实践：不要同时大幅调整两个参数，优先固定一个，只调另一个。想控制创意幅度，就动Temperature；只想防止胡言乱语，就压低Top-p。
• 极端场景避坑：Temperature=0时，模型永远输出概率最高的Token，回答完全固定；Top-p=0时，等价于Temperature=0的效果；Top-p=1时，等于不做任何截断，完全放开所有词的采样。

---

哪怕是支持百万Token上下文的大模型，也无法解决两个致命问题：知识永远停留在训练截止日，以及上下文越长、推理成本越高、越容易失忆。就像人类的大脑记不住所有知识，需要图书馆、笔记本作为外脑，RAG（检索增强生成）就是大模型的专属外脑。本卷将从语义的数学化底层，到完整的代码实战，带你彻底掌握给大模型构建永久、精准、低成本外部记忆的全流程。

1. 语义的数学化：计算机如何听懂人话？

计算机是纯粹的“数字脑”，它根本无法直接理解人类的文字、图片、音频等非结构化数据。想要让计算机“听懂人话”，核心就是把人类的语义，转换成计算机能计算的数字——这就是 Word Embeddings（词嵌入） 的核心使命。

嵌入的本质：把语义翻译成高维空间的坐标

Embedding不是随便给词语分配一个数字编号，而是把每个词、每句话，转换成一个固定维度的高维向量（一组浮点数数组）。它遵循一个铁律：语义越相近的内容，在高维空间里的向量距离就越近；语义相反或无关的内容，向量距离就越远。

比如：

• “马克爱吃水果”和“马克喜欢吃水果”的向量，在空间里几乎挨在一起；
• 国王 - 男人 + 女人 = 女王这个经典类比，本质就是向量在高维空间里的加减法运算；
• 哪怕是“银行”这个多义词，在“去银行存钱”和“坐在河岸边”两个语境里，也会被转换成完全不同的向量，精准区分语义。

词嵌入的技术演进：从静态死数字到动态活语义

• 第一代：基于频率的静态嵌入（TF-IDF）

核心逻辑：一个词在单篇文章里出现频率越高、在所有文档里出现频率越低，就越重要。它只能统计词频，完全无法理解语义，比如“苹果”在水果和手机两个语境里，只会得到同一个分数。

• 第二代：基于预测的静态嵌入（Word2Vec、GloVe）

2013年Word2Vec的发布，是NLP领域的里程碑。它通过海量文本训练，学习词与上下文的同现关系，把词转换成固定的向量。比如模型会从“狗叫得很响”“狗摇着尾巴”里，学会把“狗”和“叫”“尾巴”关联起来。

但它依然有致命缺陷：一个词永远只有一个固定向量，无法解决一词多义的问题——存钱的“银行”和河边的“银行”，向量完全一样。

• 第三代：基于Transformer的上下文动态嵌入

这是如今大模型与RAG系统的核心基石。它不再给词分配固定的死向量，而是根据整句话的上下文，动态计算出对应的向量。同一个词，在不同语境里会得到完全不同的向量，彻底解决了一词多义的问题，真正实现了对语义的精准捕捉。

2. 记忆的藏宝阁：向量数据库是如何跨越“语义鸿沟”的？

传统的关系型数据库，只能处理结构化数据和关键词匹配，无法解决“人类理解的语义”和“计算机存储的数据”之间的脱节——也就是语义鸿沟。比如你搜“高山日落的暖色调图片”，传统数据库只能匹配带“日落”“橘色”标签的文件，无法理解“暖色调”“山脉起伏”这种抽象语义。向量数据库，就是专门解决这个问题的核心载体。

向量数据库的核心本质

它不是一个简单的“存向量的硬盘”，而是一个自带高维语义检索引擎的专用数据库。它的核心工作流是：

1. 把文本、图片、音频等非结构化数据，通过Embedding模型转换成高维向量；
2. 把向量和对应的原始数据，一并存入数据库；
3. 检索时，把用户的查询也转换成向量，通过计算向量之间的距离，快速找出和查询语义最相似的内容。

性能黑科技：ANN近似最近邻索引

当你的数据库里有几百万、上千万个高维向量时，如果每次检索都和所有向量挨个计算距离，系统会慢到崩溃。向量数据库的核心性能优化，来自ANN（Approximate Nearest Neighbor，近似最近邻）算法——牺牲极其微小的准确率，换取成千上万倍的检索速度提升。

业界最主流的两种索引机制：

• HNSW（分层可导航小世界）：在向量之间构建多层的网状关系图，就像查地图一样，先在高层快速锁定大致区域，再逐层下沉逼近目标，检索速度极快，支持高维向量，是目前的主流方案。
• IVF（倒排文件索引）：先把整个向量空间划分成多个聚类簇，就像图书馆把书分成不同的书架。检索时先判断目标向量属于哪个聚类簇，只在这个簇内部搜索，直接忽略其他不相关的区域，大幅降低计算量。

3. RAG 从痛点出发到五大核心步骤的闭环

RAG（检索增强生成）的本质，就是 “遇到问题先查图书馆，把查到的最相关内容连同问题一起递给大模型，让它基于事实作答”。它不修改大模型的任何权重，就能让大模型获得无限的、实时更新的精准知识，彻底解决知识过时、幻觉、上下文成本过高三大痛点。

一套完整的工业级RAG系统，分为数据准备和检索生成两大阶段，共五大核心步骤，环环相扣，缺一不可：

阶段一：提问前的准备——构建知识库

• 步骤1：分片（Chunking）

把长篇文档、手册、书籍等原始资料，切成大小合适的文本块。这是RAG系统的第一个生死关：

• 切得太粗：一个块里包含太多主题，检索时会带入大量无关信息，污染上下文；
• 切得太细：语义被拆得支离破碎，模型无法理解完整的上下文，回答质量暴跌。
• 主流分片策略：
  • 固定字符数切分：简单，但容易切断句子。
  • 按段落/章节切分：保语义完整，但块大小可能差异很大。
  • 递归字符文本分割器：优先按段落、句号、问号、空格等递进切分，尽量保语义完整（LangChain的RecursiveCharacterTextSplitter就是这种思路）。
  • 语义切分：根据语义相似度自动拆分，成本高但效果好。
• 核心原则：保证每个块的语义完整独立，块与块之间尽量不要有上下文依赖。

• 步骤2：索引（Indexing）

把切好的文本块，通过Embedding模型转换成高维向量，连同原始文本、元数据（比如文档名、页码、分片ID），一并写入向量数据库，构建索引。这一步是给知识库建好“检索目录”，后续的所有检索都基于这个索引完成。

阶段二：提问后的响应——检索与生成

• 步骤3：召回（Retrieval）

用户发起提问后，先把用户的问题通过同一个Embedding模型，转换成问题向量；再用ANN算法，在向量数据库里快速匹配出和问题语义最相似的Top-N个文本块（通常是Top10~Top20）。

• 核心定位：粗筛，就像HR筛选简历，从成千上万份简历里快速挑出10个基本符合要求的候选人，特点是快、成本低，但精度有限。
• 常见坑：纯向量相似度检索，很容易把真正匹配的答案排在后面，出现“检索准度翻车”的问题。

• 步骤4：重排（Reranking）—— RAG系统的点睛之笔

这是决定RAG系统最终效果的核心环节。召回阶段挑出的Top-N个文本块，会被送入一个更高级、更精准的Cross-Encoder（交叉编码器）模型，让它把问题和每个文本块两两配对，进行深度语义匹配，重新打分排序，最终只保留Top3~Top5个最精准的文本块。

• 核心定位：精选，就像老板亲自终面，从HR筛出的10个候选人里，深度面试后只录用最匹配的3个，特点是精度极高，但速度更慢、成本更高。
• 为什么必须加重排：向量相似度是“双塔模型”，分别给问题和文本块算向量，再算距离，无法捕捉深层的语义匹配关系；而Cross-Encoder是“单塔模型”，把问题和文本块放在一起做注意力计算，能精准判断“这句话到底能不能回答用户的问题”，彻底解决召回阶段的准度翻车问题。

• 步骤5：生成（Generation）

把重排后筛选出的高质量文本块，作为参考资料，和用户的原始问题、指令要求，一起拼装成Prompt，喂给大模型。指令里会明确要求：必须严格基于参考资料作答，资料里没有的内容，必须明确说明“我不知道”，禁止编造信息。

最终，大模型会基于事实资料，生成精准、无幻觉、有溯源依据的回答，完成整个RAG闭环。

4. 代码实战：如何用 Python 从零手搓一个带重排的极简 RAG 系统？

我们将用最轻量化的技术栈（ChromaDB + SentenceTransformers），从零实现一套完整的RAG系统，全程无黑盒，每一步都可追溯。

第一步：环境搭建

使用uv极速安装核心依赖（也可用pip替代）：

# 初始化项目与虚拟环境 uv init rag_demo cd rag_demo uv venv source .venv/bin/activate # Windows: .venvScriptsactivate # 安装核心依赖 uv add sentence-transformers chromadb python-dotenv

第二步：准备测试数据

创建doc.md，写入一段自定义的测试文本（确保内容不在大模型的训练数据里，验证RAG的有效性）：
 

# 哆啦A梦、大雄与超级赛亚人合力打败黑暗势力 在这场跨次元的冒险中，三人使用了三个核心秘密道具： 1. 次元穿越手表：可以自由穿梭不同的动漫宇宙，实现跨世界联动 2. 赛亚人能量增幅器：能把超级赛亚人的战斗力放大10倍，同时不会消耗体力 3. 谎言成真扩音器：可以把说出来的谎言变成现实，仅限对抗黑暗势力时使用 最终，三人在2077年的赛博朋克城市里，用三个道具的组合技，彻底封印了黑暗势力。

第三步：核心代码实现

创建rag.py，完整实现五大核心步骤：

 from sentence_transformers import SentenceTransformer, CrossEncoder import chromadb # ---------------------- 1. 模型初始化 ---------------------- # 加载Embedding模型（用于向量化，768维） embed_model = SentenceTransformer("all-MiniLM-L6-v2") # 加载重排模型（Cross-Encoder，用于精筛） rerank_model = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2") # ---------------------- 2. 文档分片 ---------------------- def split_into_chunks(file_path: str, chunk_size: int = 100) -> list[str]: """简单按行分片，可替换为更高级的语义分片策略""" with open(file_path, "r", encoding="utf-8") as f: text = f.read() # 按换行符拆分，过滤空行（生产环境建议用更智能的分片器） chunks = [line.strip() for line in text.split(" ") if line.strip()] return chunks # 读取并分片文档 chunks = split_into_chunks("doc.md") print(f"文档分片完成，共{len(chunks)}个分片") # ---------------------- 3. 向量化与索引入库 ---------------------- # 初始化ChromaDB内存客户端（测试用，重启后数据销毁） chroma_client = chromadb.EphemeralClient() # 创建集合 collection = chroma_client.create_collection(name="rag_demo_collection") # 批量向量化并写入数据库 collection.add( documents=chunks, embeddings=embed_model.encode(chunks).tolist(), ids=[f"chunk_{i}" for i in range(len(chunks))] ) print("向量索引构建完成，已入库") # ---------------------- 4. 召回与重排 ---------------------- def retrieve_and_rerank(query: str, top_k_recall: int = 5, top_k_rerank: int = 3) -> list[str]: """召回+重排核心逻辑""" # 步骤1：问题向量化 query_embedding = embed_model.encode(query).tolist() # 步骤2：向量召回（粗筛） recall_results = collection.query( query_embeddings=query_embedding, n_results=top_k_recall ) recall_chunks = recall_results["documents"][0] print(f"召回完成，共{len(recall_chunks)}个候选分片") # 步骤3：Cross-Encoder重排（精筛） # 构造【问题-分片】配对 query_chunk_pairs = [[query, chunk] for chunk in recall_chunks] # 批量打分 scores = rerank_model.predict(query_chunk_pairs) # 按分数降序排序 scored_chunks = sorted(zip(scores, recall_chunks), key=lambda x: x[0], reverse=True) # 截取Top-K final_chunks = [chunk for score, chunk in scored_chunks[:top_k_rerank]] print(f"重排完成，最终保留{len(final_chunks)}个最优分片") return final_chunks # ---------------------- 5. 生成回答 ---------------------- def generate_answer(query: str, context_chunks: list[str]) -> str: """拼装Prompt，生成最终回答（这里用打印模拟，可接入OpenAI/DeepSeek/Gemini API）""" prompt = f""" 请严格基于以下参考资料，回答用户的问题。如果参考资料里没有相关内容，请直接回答"我不知道"，禁止编造信息。 【参考资料】 {chr(10).join(context_chunks)} 【用户问题】 {query} 【最终回答】 """ # 这里可替换为大模型API调用 print("="*50 + "最终Prompt" + "="*50) print(prompt) return "回答生成完成，可接入大模型API输出最终结果" # ---------------------- 完整流程测试 ---------------------- if __name__ == "__main__": user_query = "使用的三个秘密道具分别是什么？" # 召回+重排 final_context = retrieve_and_rerank(user_query) # 生成回答 answer = generate_answer(user_query, final_context) print("="*100) print(answer)

核心效果验证

运行代码后，你会看到：

1. 向量召回阶段，包含正确答案的分片，大概率不会排在第一位；
2. 经过Cross-Encoder重排后，包含核心答案的分片，会被精准提到第一位；
3. 最终拼装的Prompt，只会包含最相关的3个分片，大幅降低上下文长度，同时保证回答的精准性。

 思考：生产环境的分片策略需要根据文档类型精心设计。例如，对于代码文档，可以按函数或类切分；对于长篇小说，可以按章节切分，并保留章节标题作为元数据。切分的好坏，直接影响RAG效果的上限。

---

有了聪明的大脑和精准的外脑，Agent依然只是关在小黑屋里的“纸上谈兵者”——它无法感知外部世界，更无法改变外部世界。本卷将解决两大核心问题：第一，如何防止Agent在长任务中失忆、跑偏、失控；第二，如何给Agent接上“四肢”，让它能稳定、安全地调用外部工具，完成真实世界的任务。

1. 失忆与跑偏：为什么 Agent 架构中必须要有“上下文工程”？

在正式讲解工具调用之前，我们必须先解决Agent架构的头号杀手：上下文爆炸与任务跑偏。

首先要明确一个事实：大模型是完全无状态的，它没有任何原生的记忆能力。你看到的“连续对话”，本质是每次请求时，客户端都把完整的历史对话、工具调用记录、工具返回结果，全部拼接到上下文里，一次性喂给大模型。

在普通的聊天场景里，这不会有太大问题。但在Agent架构中，灾难会被无限放大：

• Agent为了完成任务，会自主调用大量工具：比如联网搜索会返回几万字的HTML源码，读取文件会返回长篇的代码/文档，连续3次工具调用，就会让上下文膨胀到几万、几十万Token；
• 上下文越长，大模型的注意力就越分散，很容易彻底忘记用户最开始的核心任务，陷入“为了调用工具而调用工具”的死循环；
• 同时，上下文膨胀会导致推理成本指数级上升，推理速度大幅下降，甚至直接超出模型的上下文窗口限制，导致报错。

上下文工程，就是一套程序化的规则，用来动态管理、裁剪、优化Agent的上下文，确保在长任务执行中，Agent永远不会忘记核心目标，不会被垃圾信息淹没，始终在正确的轨道上运行。

2. 牵引风筝的线：4 种防止 Agent 失控的硬核解法

以下4种方法，是业界经过生产环境验证的、最有效的上下文管理方案，可根据任务复杂度组合使用：

方法一：让 AI 学会“记笔记”—— 永久置顶的核心目标锚点

这是防止Agent跑偏最有效的手段之一：

• 核心逻辑：给Agent提供一个专属的记笔记工具，在System Prompt里强制要求：
  • 拿到任务后，必须先拆解成可执行的任务清单（Checklist），写入笔记；
  • 每完成一个步骤，必须调用笔记工具，更新任务状态（标为已完成/未完成），记录关键结论；
  • 每一次思考前，必须先查看笔记，确认当前的核心任务和进度。
• 物理外挂：客户端程序会把这本笔记，永远强制置顶在上下文的最开头或最末尾——Transformer架构对文本的开头和结尾信息敏感度最高，只要核心任务清单始终在最显眼的位置，Agent就绝对不会跑偏。
• 适用场景：所有长周期、多步骤的复杂任务，是Agent系统的必配功能。

方法二：简单暴力的“滑动窗口”—— 丢弃无效历史

• 核心逻辑：直接设定一个窗口阈值（比如保留最近10轮交互），只保留最新的工具调用与对话记录，超出阈值的老历史直接丢弃。唯一例外：最开头的System Prompt和用户的原始需求，永远不能丢。
• 优点：实现简单，零额外成本，能有效控制上下文的总长度；
• 缺点：会丢失早期的关键信息，只适合简单的、短链路的任务，不适合复杂的长任务。

方法三：优雅的“总结压缩”—— 用低成本模型瘦身历史

• 核心逻辑：当历史对话积累到一定长度（比如超过20轮），程序自动调用一个低成本、小参数量的大模型，把冗长的历史对话、工具执行过程，总结成一段精炼的核心信息，用这段总结，替换掉原来臃肿的历史记录。
• 进阶优化：只总结工具执行的中间过程，保留用户的核心需求、关键结论、已完成的任务节点，进一步提升压缩效率；
• 适用场景：中等复杂度的任务，兼顾上下文长度和信息完整性，是性价比最高的方案。

方法四：动态 RAG —— 知识库外包，解决长文本污染

这是最高级、最适合处理海量信息的方案，能彻底解决工具返回长文本导致的上下文爆炸问题。

• 核心逻辑：当工具返回一篇超过阈值的长文本（比如上万字的网页、文档、代码库），程序绝对不会把它直接塞进上下文：
  • 后台自动把这篇长文本，存入一个临时的向量数据库；
  • 篡改工具的返回结果，只在上下文里告诉大模型：“这篇文章太长，我已经帮你存入临时知识库了，我给你提供了一个query_document工具，你可以随时用它查询你需要的片段”；
  • 只有当大模型主动调用查询工具时，才会把对应的片段提取出来，塞入上下文。
• 效果：上万字的长文本，瞬间变成了一句话的说明，上下文负担几乎降为0，同时大模型依然能获取到它需要的任何信息。
• 适用场景：需要频繁读取长文档、网页、代码库的Agent，比如代码助手、文档分析助手、研究报告助手。

3. 武器库协议：MCP (模型上下文协议) 到底是个啥？

MCP（Model Context Protocol，模型上下文协议），是Anthropic在2024年11月发布的、如今AI Agent领域最主流的工具调用标准。它被无数人包装得高大上，本质上，它就是一套大模型与外部工具之间的统一通信规范——就像家电的插座标准，不管什么品牌的家电，只要符合这个标准，就能插上电正常工作。

核心角色拆解：Client、Server、Host

MCP的整个生态，只有三个核心角色，关系极其清晰：

1. MCP Host（宿主）：就是你使用的客户端软件，比如Claude Desktop、Cursor、VS Code的Cline插件。它是整个流程的总指挥，负责和大模型对话，同时管理所有的MCP Server。
2. MCP Client（客户端）：宿主内置的、符合MCP协议的通信模块，负责和MCP Server对话，发送指令，接收结果。
3. MCP Server（服务端）：这是最容易被误解的角色——它不是云端服务器，本质就是一个符合MCP通信规范的本地程序，你可以用Python、Node.js、C++等任何语言编写。一个MCP Server里，封装了一个或多个工具（Tool），说白了，就是一个个可被调用的函数。

底层通信逻辑：一次完整的MCP调用，到底发生了什么？

我们以“查询纽约明天的天气”为例，拆解MCP的完整通信流程，全程没有任何黑盒：

1. 唤醒与握手：Host启动后，通过配置的终端命令，唤醒本地的天气MCP Server（Python程序）。Client和Server通过标准输入输出流（stdio）完成握手，互相确认协议版本，Server告诉Client：“我准备好了，我有get_forecast和get_alerts两个工具”。
2. 用户提问：你在Host里输入：“纽约明天天气怎么样？”
3. 模型决策：Host把【你的问题】+【可用工具列表】一起打包发给大模型。大模型判断：“我不知道天气，但我可以调用get_forecast工具，参数是纽约的经纬度”，然后按约定格式输出工具调用指令。
4. 指令转发：Host拿到大模型的指令，通过MCP Client，把调用指令以JSON格式，发送给对应的MCP Server。
5. 工具执行：MCP Server收到指令，解析参数，执行对应的Python函数，调用气象局API，拿到天气数据。
6. 结果返回：MCP Server把执行结果，以JSON格式返回给Client，Host再把结果喂给大模型。
7. 生成回答：大模型基于返回的天气数据，用自然语言组织成最终回答，展示给你。

硬核抓包：MCP协议的JSON真面目

MCP的底层通信，全程都是格式化的JSON字符串，没有任何玄学。我们通过拦截脚本，就能看到完整的通信内容：

• 握手阶段：

  // Client -> Server {"jsonrpc": "2.0", "id": 1, "method": "initialize", "params": {"protocolVersion": "2024-11-05", "capabilities": {}}} // Server -> Client {"jsonrpc": "2.0", "id": 1, "result": {"protocolVersion": "2024-11-05", "capabilities": {"tools": {}}, "serverInfo": {"name": "weather", "version": "1.0.0"}}}

• 工具列表查询：
  // Client -> Server {"jsonrpc": "2.0", "id": 2, "method": "tools/list"} // Server -> Client , "longitude": {"type": "number", "description": "经度"}}, "required": ["latitude", "longitude"]}}]}}
   
  
  
• 工具调用：

  // Client -> Server }} // Server -> Client {"jsonrpc": "2.0", "id": 3, "result": {"content": [{"type": "text", "text": "纽约明天晴天，气温10-18℃，西北风3级，建议穿薄外套"}]}}

 终极真相：MCP协议，根本和大模型没有直接关系。它只定义了Client和Server之间的通信规范，完全不涉及Client和大模型之间的交互。它的核心价值，就是给所有Agent工具，制定了一套统一的“插座标准”，让开发者不用再为每个工具单独写适配代码，大幅降低了Agent工具的开发与集成门槛。

4. 规则的形状：Agent Skill 与 MCP 有何本质区别？

Agent Skill是Anthropic在2025年末发布的开放标准，很多人会把它和MCP混淆，甚至觉得两者功能重叠。但实际上，它们的定位、底层逻辑、适用场景，有着天壤之别。

Agent Skill 的核心本质：大模型的“按需加载说明书”

Agent Skill的本质，是一套给大模型看的、带触发规则的说明文档，核心解决的是“重复粘贴Prompt”的痛点，同时通过渐进式披露机制，极致节省Token。

它采用三层渐进式披露结构，只有在需要的时候，才会加载对应的内容，没有被用到的部分，连1个Token都不会消耗：

1. 第一层：元数据层（Metadata）

1. 所有Skill的名称和一句话描述，始终会加载给大模型，相当于大模型的“技能目录”。大模型只会看目录，判断用户的需求需要用到哪个Skill。

1. 第二层：指令层（Instruction）

1. 对应Skill的skill.md文件的核心内容，包含详细的执行规则、输出格式、少样本示例。只有当大模型从目录里选中了这个Skill，系统才会加载这一层的内容，喂给大模型。

1. 第三层：资源层（Resource）

1. 包含两种核心资源，只有当指令层的触发条件被满足时，才会被加载/执行：
   • Reference（参考文件）：本质是“读”。比如《集团财务手册》《法务合规规则》，只有当用户的问题里提到了钱、合同等触发词时，系统才会读取这个文件，把内容塞进上下文。如果没有触发，文件永远躺在硬盘里，不消耗任何Token。
   • Script（脚本）：本质是“跑”。比如upload.py上传脚本，只有当用户提到“上传”“同步”等触发词时，系统才会执行这个脚本。模型根本不会读取脚本的内容，哪怕脚本有1万行，消耗的上下文Token几乎为0，模型只关心“怎么运行它”和“运行的结果是什么”。

终极辨析：Agent Skill 与 MCP 的核心区别

Anthropic官方用一句话点明了本质：MCP connects Claude to data... Skills teach Claude what to do with that data.

 **实践：在真实的生产环境中，两者是互补关系，而非替代关系。用MCP搭建坚固、安全的底层数据与工具管道，用Agent Skill给大模型制定处理这些数据的规则与SOP，两者结合，才能搭建出既稳定又灵活的Agent系统。

---

有了大脑、记忆、四肢，Agent还需要一套成熟的“思维模式”，才能完成复杂任务；当任务超出单体智能的能力边界时，还需要搭建多智能体的“组织架构”，让多个Agent分工协作，像公司一样运转。本卷将从单体智能的ReAct循环，到多智能体的LangGraph拓扑架构，彻底讲透Agent的思考与协作逻辑。

1. 单体智能的崛起：彻底拆解大模型如何使用工具（ReAct 模式）

ReAct（Reasoning and Acting，思考与行动），是目前业界应用最广、最成熟的Agent架构，几乎所有的Agent产品，底层都是基于ReAct模式构建的。它的核心，就是模拟人类“边想边干”的行为模式，通过“思考-行动-观察”的循环，一步步完成任务。

ReAct 模式的核心循环

ReAct的完整流程，是一个闭环的四步循环，直到任务完成才会终止：

1. Thought（思考）：大模型先分析当前的状况，明确“我现在要做什么？为什么要做？下一步该调用什么工具？”。这一步是Agent的大脑，决定了整个流程的走向。
2. Action（行动）：大模型按照约定的格式，输出工具调用指令，明确要调用的工具名称、对应的参数。
3. Observation（观察）：外部程序执行工具，把执行结果（比如文件写入成功、API返回的数据、搜索到的网页内容），以固定格式返回给大模型。这一步是Agent获取外部反馈的核心环节。
4. 循环/终止：大模型基于观察到的结果，再次进入思考环节，判断任务是否完成。如果没完成，就继续下一轮“思考-行动-观察”循环；如果完成了，就输出Final Answer（最终答案），终止循环。

硬核揭秘：如何逼迫模型严格遵守 ReAct 格式？

很多人以为ReAct是大模型天生就会的能力，其实完全不是。ReAct模式的落地，核心靠的是System Prompt的威逼利诱，通过严格的格式约束，强制大模型按照循环流程输出。

一段极简的ReAct System Prompt示例：

你是一个专业的任务执行助手，必须严格按照以下格式进行思考和行动，禁止任何偏离格式的输出：
1. 每次思考，必须用 标签包裹，内容是你对当前任务的分析和下一步计划；
2. 如果你需要调用工具，必须用 标签包裹，里面只输出工具调用的JSON格式，包含tool_name（工具名）和arguments（参数）；
3. 工具执行后，我会用 标签给你返回执行结果，你必须基于结果继续思考；
4. 只有当任务完全完成时，你才能用 标签，输出最终的结果，终止流程。 可用工具列表： - read_file：读取本地文件，参数：file_path（文件路径） - write_file：写入本地文件，参数：file_path（文件路径）、content（文件内容） - execute_command：执行终端命令，参数：command（要执行的命令）












通过这套Prompt，哪怕是没有经过ReAct微调的开源模型，也能严格按照循环流程执行任务。我们甚至可以手动扮演“电脑”，在模型输出 后，手动回复 ，就能逼着模型一步步完成复杂的代码编写、文件操作等任务。

极简Python实现：手搓一个ReAct Agent

核心的ReAct循环，用一个While循环就能实现，核心代码逻辑如下：

 import openai import re from tools import read_file, write_file, execute_command # 自定义的工具函数 # 工具映射表 TOOL_MAP = { "read_file": read_file, "write_file": write_file, "execute_command": execute_command } # 系统提示词 SYSTEM_PROMPT = """上面的ReAct系统提示词""" def run_agent(user_task: str): # 初始化消息列表 messages = [{"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_task}] # ReAct核心循环 while True: # 1. 调用大模型 response = openai.chat.completions.create(model="deepseek-v3", messages=messages) assistant_content = response.choices[0].message.content messages.append({"role": "assistant", "content": assistant_content}) print(f"模型输出： {assistant_content} ") # 2. 匹配最终答案，终止循环 final_answer = re.search(r" 
      
    
        
          (.*?) 
        ", assistant_content, re.S) if final_answer: print("任务完成！最终结果：", final_answer.group(1).strip()) break # 3. 匹配工具调用，执行工具 action_match = re.search(r" 
      
    
        
          (.*?) 
        ", assistant_content, re.S) if action_match: # 解析工具调用JSON try: tool_call = eval(action_match.group(1).strip()) tool_name = tool_call["tool_name"] arguments = tool_call["arguments"] except Exception as e: observation = f"工具调用格式错误：{str(e)}，请严格按照JSON格式输出" messages.append({"role": "user", "content": f" 
      
    
        
          {observation} 
        "}) continue # 执行工具 if tool_name not in TOOL_MAP: observation = f"工具{tool_name}不存在，可用工具：{list(TOOL_MAP.keys())}" else: try: result = TOOL_MAP[tool_name](arguments) observation = f"工具执行成功，结果： {result}" except Exception as e: observation = f"工具执行失败：{str(e)}" # 把工具结果返回给模型 messages.append({"role": "user", "content": f" 
      
    
        
          {observation} 
        "}) # 启动Agent if __name__ == "__main__": run_agent("写一个贪吃蛇游戏，HTML/CSS/JS分开放，保存到当前目录的snake文件夹里")

这段代码，就是市面上绝大多数代码助手、自动化Agent的底层核心逻辑。

2. 从摸着石头过河到深谋远虑：Plan and Execute（先规划再执行）的高级双脑模式

ReAct模式是“摸着石头过河”，走一步看一步，适合简单的短链路任务。但当任务复杂度提升，比如“写一份2026年AI行业研究报告，包含市场规模、技术趋势、头部厂商分析、未来预测”，ReAct模式很容易陷入死循环、跑偏、遗漏关键环节，最终产出的内容质量极低。

此时，就需要 Plan and Execute（先规划再执行） 架构，它模拟了人类处理复杂任务的模式：先做整体规划，拆解成可执行的小步骤，再一步步执行，同时根据执行结果动态调整计划。

Plan and Execute 的核心架构

它本质是“Agent套Agent”的双脑模式，包含三个核心角色，形成完整的闭环：

1. Plan 模型（规划师）：负责接收到用户的大目标后，把它拆解成一个结构化、可执行的步骤清单，相当于项目的产品经理。比如用户要写一份行业报告，规划师会拆解成：
   1. 搜索2025-2026年AI行业的整体市场规模数据
   2. 梳理2026年AI领域的核心技术突破与趋势
   3. 收集头部厂商（OpenAI、Anthropic、字节跳动等）的核心动态与产品布局
   4. 基于以上信息，撰写行业未来3年的发展预测
   5. 整合所有内容，生成完整的研究报告
2. 执行 Agent（执行者）：底层的打工仔，通常就是一个标准的ReAct Agent。主程序把规划好的“单个步骤”丢给它，它负责调用工具、完成这个子任务，返回执行结果。
3. Replan 模型（复盘师）：拿到上一步的执行结果后，重新审视全局的计划，根据最新的信息，动态修改、调整、补充后续的步骤。比如原本的步骤是“查对应年份的市场规模”，现在已经明确了是2026年，复盘师就会把步骤修改得更精准，让后续的执行更高效。

完整的循环流程

1. 接收用户的大目标，Plan模型生成初始的执行计划；
2. 从计划中取出第一个待执行的步骤，交给执行Agent完成；
3. 拿到执行结果，Replan模型基于最新信息，复盘并修改后续的计划；
4. 重复步骤2-3，直到计划里的所有步骤全部完成；
5. 整合所有步骤的执行结果，生成最终的答案，交付给用户。

核心优势与适用场景

• 优势：大幅提升复杂任务的完成度，避免ReAct模式的跑偏和死循环；通过规划拆解，把复杂大任务变成可控的小任务，同时通过动态复盘，随时调整方向，适配突发情况；
• 适用场景：长周期、多步骤、需要全局把控的复杂任务，比如行业研究报告撰写、多文件代码项目开发、复杂的数据分析、自动化办公流程等。

3. 从单兵作战到多智能体公司：LangGraph 架构解析

当任务的复杂度进一步提升，需要多个不同专业领域的Agent分工协作时，单体智能和简单的Plan and Execute架构，已经无法满足需求。比如开发一个完整的网站，需要产品经理Agent、前端开发Agent、后端开发Agent、测试Agent协同工作，此时就需要多智能体编排框架，而LangGraph，就是目前业界最灵活、最强大的多智能体编排框架。

LangGraph 是什么？

LangGraph是LangChain团队开发的、基于图结构的AI Agent构建框架。它的核心哲学，是把Agent的整个工作流，抽象成一张有向图，通过节点、边、状态，实现对Agent流程的绝对控制。相比于其他多智能体框架，它的最大优势是：

• 极致的灵活性：支持循环、条件分支、人类在环、并发执行等任意复杂的流程；
• 原生支持多智能体：可以轻松搭建不同拓扑结构的多智能体系统；
• 内置持久化、流式输出、异步执行、容错机制，直接适配生产环境。

LangGraph 的四大核心构建块

理解了这四个核心元素，你就掌握了LangGraph的全部灵魂：

1. State（状态）：整个系统的“共享黑板”，是一个全局的数据结构，负责存储所有的输入、输出、对话历史、中间结果、工具调用记录等。任何节点执行完后，都会把新产生的数据写回State，供下一个节点使用。
2. Nodes（节点）：具体干活的单元，每个节点里封装了一段可执行的代码，可以是调用大模型、执行工具、调用子Agent、数据处理等任何逻辑。比如“产品经理节点”“前端开发节点”“工具执行节点”。
3. Edges（边）：单向箭头，决定了图的执行顺序，执行完A节点后，强制走向B节点。
4. Conditional Edges（条件边）：整个框架的核心路由逻辑，相当于代码里的if-else分支。它会读取当前State里的数据，根据预设的判断规则，决定下一步该走哪条边、进入哪个节点。比如“如果大模型输出了工具调用，就走向工具节点；如果没有，就走向结束节点”。

三种经典的单体Agent架构模式

用LangGraph的四大积木，可以轻松拼出任意复杂的Agent架构，三种最经典的模式：

• Router（路由模式）：最简单的分发器。根据用户的输入，通过条件边，决定把请求分发给哪个对应的Prompt、子模型或子Agent。比如用户问代码问题，就走向代码专家节点；问法律问题，就走向法务专家节点。
• ReAct Agent（思考-行动模式）：最经典的循环架构。核心是两个节点：大模型思考节点、工具执行节点，通过条件边实现循环：大模型节点输出工具调用，就走向工具节点；工具执行完，结果写回State，再回到大模型节点；直到大模型判断任务完成，走向结束节点。
• Reflection Pattern（反思/自我修正模式）：双节点循环架构，实现AI的自我纠错。节点A负责生成初稿，节点B负责审查、挑错、给出修改意见，然后通过条件边，把意见打回节点A重新生成，直到审查通过，走向结束节点。这种模式，能大幅提升代码、文案、报告等内容的生成质量。

四大主流多智能体拓扑结构与优劣对比

LangGraph可以搭建任意拓扑结构的多智能体系统，以下四种是业界最主流的架构，从松散到严谨，适配不同的生产场景：

混合架构小案例：主管+反思+执行

假设我们要搭建一个“高质量代码生成系统”，目标是生成的代码既功能正确，又符合公司代码规范。我们可以设计如下混合架构：

1. 主管Agent：接收用户需求，拆解任务，决定调用哪个子Agent。
2. 代码生成Agent（执行者）：根据需求生成初版代码。
3. 代码审查Agent（反思者）：专门审查代码，检查功能正确性、代码规范、安全漏洞，输出审查报告。
4. 条件路由：
   1. 如果审查通过，代码直接输出给用户；
   2. 如果审查不通过，将审查报告打回给代码生成Agent，要求其根据意见修改，然后再次提交审查。
5. 循环：直到审查通过，或达到最大重试次数后，由主管Agent输出最终结果或请求人工介入。

这种混合架构，既保证了代码质量，又实现了流程自动化，是LangGraph擅长的场景。

4. 状态流转（State）：Agent 之间到底怎么沟通最稳妥？

多智能体系统的头号坑，不是架构设计，而是Agent之间的信息传递——一旦信息传递出问题，就会出现上下文污染、信息丢失、Agent理解偏差，最终导致整个系统崩溃。

两种核心的信息传递方式

1. 共享黑板模式（Shared State）

1. 这是最常用、最简单的模式，本质是所有Agent共用一个全局的State（共享黑板），所有Agent都可以在这个黑板上读写数据。就像公司的公共文档库，所有部门都可以查看和更新。
   • 核心优势：实现简单，信息同步高效，所有Agent都能看到全局的完整信息；
   • 致命坑点：上下文污染。如果每个Agent都把自己的内部思考、工具调用记录、试错过程，全部写到全局的消息列表里，很快就会导致全局上下文爆炸，后续的Agent会被大量无关信息淹没，彻底忘记核心任务。
   • **实践：严格隔离内部状态与共享状态。每个Agent都有自己私有的内部消息列表，用于存放自己的思考、工具调用、试错过程；只有当Agent完成了自己的子任务，输出了最终的、精炼的结论时，才把这个结论追加到全局的共享State里。这样，全局的上下文永远干净整洁，极大降低了后续Agent的认知负担。

1. 局部状态桥接模式

1. 当不同的Agent，有完全不同的内部数据结构时，共享黑板模式就会出现适配问题。比如产品经理Agent的State里，包含需求文档、原型图说明；而前端开发Agent的State里，包含代码文件、组件结构，两者的数据结构完全不同。

1. 此时，就需要用局部状态桥接模式：
   • 每个Agent都有自己独立的、私有的局部State，互不干扰；
   • 在Agent之间，设定一个约定好的共享Key（公共字段），作为信息传递的桥梁。比如，产品经理Agent干完活后，只把最终的“需求文档”写到这个共享Key里；前端开发Agent启动时，只会读取这个共享Key里的需求文档，完全不管产品经理Agent内部的其他数据。
   • 核心优势：实现了代码的完全解耦，每个Agent可以独立开发、独立维护，互不影响，哪怕替换掉其中一个Agent，只要共享Key的约定不变，整个系统就不会出问题；
   • 适用场景：大型、复杂的多智能体系统，多个Agent由不同的团队开发，需要严格的职责隔离与解耦。

---

当你掌握了从大模型底层原理、RAG外脑、上下文管理、工具调用，到单/多智能体架构的全栈知识，就已经跳出了“调包侠”的范畴，具备了AI Agent架构师的核心能力。但真正的架构师，不仅要知道“怎么搭”，更要想明白“为什么这么搭”。本卷将回归本质，探讨Agent工程化的核心哲学，以及未来的演进方向。

1. 为什么“智能体就是所有不需要智能的部分构成的”？

这句话是Agent领域最深刻、最直击本质的论断，很多人听了觉得反直觉，但只要你真正落地过一套生产级的Agent系统，就会明白这句话的终极真相。

我们先拆解Agent系统的构成：一套完整的Agent系统，90%以上的代码，都是在做这些事情：

• 上下文的裁剪、压缩、管理，防止模型跑偏；
• 工具调用的格式解析、参数校验、异常处理、安全管控；
• RAG系统的分片、向量化、召回、重排，给模型提供精准的上下文；
• 多智能体之间的状态流转、信息传递、职责隔离；
• 流程的控制、循环的终止、异常的重试、人类在环的介入；
• MCP Server的开发、工具的封装、权限的管控。

而真正需要大模型的“智能”的部分，只有极其微小的几个点：

• 意图识别：判断用户的需求到底是什么；
• 路由决策：下一步该调用哪个工具，该派哪个Agent干活；
• 内容生成：基于上下文，生成符合要求的文本、代码、方案。

所谓的Agent智能体，本质上就是用大量的、确定的、不需要智能的代码，把大模型的模糊智能，包裹在了一个严密的、可控的框架里。

• 所有确定的、可标准化的、有固定规则的事情，全部用硬代码写死，绝对不交给大模型去决策——因为代码的执行是100%确定、100%可控、零成本的；
• 只有那些模糊的、无法用固定规则定义的、需要语义理解和决策的事情，才交给大模型的智能去处理。

就像一辆自动驾驶汽车，真正的“智能”，只有感知环境、决策路线、判断路况的那部分核心算法；而剩下的99%的部分——发动机、变速箱、刹车、转向、车身、电路，都是不需要智能的机械结构，但正是这些不需要智能的部分，构成了汽车的主体，让核心的智能算法，能够真正落地，改变现实世界。

Agent系统的架构水平，从来不是看你用了多少大模型的智能，而是看你能不能把尽可能多的事情，用不需要智能的代码搞定，只把最核心、最必要的决策，交给大模型。用最少的智能，完成最稳定的任务，这才是Agent架构师的终极能力。

2. 软硬编码的博弈：LangChain (硬) -> Workflow (拖拽) -> Skill (文档) -> Pure Agent (完全体) 的演进逻辑与适用场景

Agent工程化的整个演进历程，本质上就是一场控制权与灵活性的博弈。从完全硬编码的LangChain，到完全自然语言驱动的Pure Agent，每一个阶段的演进，都是在控制权和灵活性之间，寻找新的平衡点。我们逐个拆解每个阶段的本质、优势、劣势与适用场景：

第一阶段：LangChain 纯代码硬编码

• 核心本质：把Agent的整个工作流，用代码完全写死，每一步的执行顺序、分支逻辑、异常处理，全部提前定义好。大模型只负责内容生成，几乎没有决策的权力。
• 优势：执行100%可控，稳定性拉满，性能最优，零多余Token消耗，不会出现任何跑偏和失控的情况；
• 劣势：灵活性极差，只要业务需求有一点变化，就必须修改代码、重新发布，开发和维护成本极高；
• 适用场景：高可靠、零容错、流程固定的场景，比如银行的合规审核、财务的固定报表生成、工业场景的固定自动化流程。

第二阶段：Workflow 拖拽式工作流

• 核心本质：把硬编码的LangChain逻辑，封装成了可视化的节点，用户可以通过网页拖拽的方式，拼接工作流，定义执行顺序和分支逻辑。本质上和硬编码没有区别，只是降低了开发门槛，让不会写代码的人，也能搭建Agent流程。
• 优势：开发门槛低，可视化的流程清晰易懂，修改流程不需要改代码，比硬编码灵活；
• 劣势：依然是固定流程，只能处理提前定义好的场景，遇到计划外的情况，就会直接崩溃；灵活性依然有极大的上限；
• 适用场景：中小企业的内部自动化办公流程、简单的客服机器人、固定流程的内容生成，适合没有开发能力的业务人员使用。

第三阶段：Skill 文档式规则

• 核心本质：把固定的流程和规则，写成了带触发条件的说明文档，交给大模型去理解和执行。不再写死执行流程，只给大模型定下规则、边界、SOP，具体的执行步骤，由大模型根据实时情况自主决定。
• 优势：兼顾了稳定性和灵活性，规则和边界是可控的，不会出现严重的失控；同时又有足够的灵活性，能适配计划外的场景；修改规则只需要改文档，不需要改代码，维护成本极低；
• 劣势：对Prompt和规则的编写要求极高，规则写得不好，就会出现执行不到位、触发不精准的问题；
• 适用场景：绝大多数的商业级Agent场景，比如代码助手、企业内部的智能客服、行业专属的AI助手、内容创作助手，是目前性价比最高、平衡性最好的方案。

第四阶段：Pure Agent 完全体

• 核心本质：彻底不写死任何流程和规则，只给大模型一个核心目标、一套可用的工具，完全由大模型自主决定执行步骤、调用工具、规划流程，甚至自主拆解目标、自我修正。
• 优势：灵活性拉满，能处理完全未知的、复杂的、没有固定规则的场景，上限极高；
• 劣势：完全不可控，极易跑偏、陷入死循环、出现幻觉和错误操作，Token成本极高，稳定性极差；
• 适用场景：头脑风暴、创意创作、科研探索、完全未知领域的问题解决，绝对不适合用在需要高可靠、高稳定的生产环境中。

演进的逻辑与趋势

整个演进历程，是一个从 “完全硬编码、完全可控” 到 “完全软编码、完全灵活” 的光谱。没有绝对的好坏，只有适合不适合。真正成熟的商业级系统，从来不是走极端，而是在这个光谱上，找到最适合自己业务场景的平衡点。

很多人觉得，未来的趋势是Pure Agent完全体，所有事情都交给大模型自主决策。但恰恰相反，从工程化的角度来看，未来的主流，一定是 “硬编码兜底，软编码适配”的混合架构：

• 用硬编码，把核心的安全规则、权限管控、异常处理、流程边界，牢牢锁死，绝对不允许大模型触碰，确保系统的底线安全；
• 用Skill和软编码，给大模型足够的灵活性，去适配业务的变化和用户的个性化需求；
• 只有在极少数的、探索性的场景里，才会放开Pure Agent的完全灵活性。

而随着算力成本的持续下降，Token的价格无限趋近于零，整个行业的核心矛盾，会从“如何节省Token”，变成“如何极致降低使用门槛”。未来的Agent，不会再让用户去写代码、配JSON、拖节点、写Skill文档，而是直接通过自然语言，就能定义规则、搭建系统、完成任务。但无论上层的交互怎么变，底层的核心逻辑永远不会变：用确定的代码，包裹模糊的智能，在可控的边界里，释放最大的灵活性。

---

去解剖那些所谓的“黑科技”吧，你会发现它们都只是：

Token 的排列组合，概率的加权抽样，以及无数行 if-else 的堆砌。