企业官网建设流程全解析

《智能体式AI漫游指南》第五章，核心内容正好是RAG、记忆、上下文、技能、运行框架、设计模式、环节与评测、A2A、多智能体系统、开发框架和UI框架这一整条链路。这一章信息密度不低，一开始很容易被当成一堆名词的堆砌。但完整读下来你会发现，它实际上在回答一个问题：如果要做一套真正能完成复杂任务的智能体系统，各个模块应该怎么组织、怎么取舍。

这篇分享不打算复述目录，而是按我自己的理解和验证顺序，拆一下这一章真正值得动手的部分。如果你正在学习RAG，准备选型开发框架，或者想搞清楚多智能体系统怎么落地评测，这篇文章应该能帮你省一些折腾时间。

1. 先把智能体的四个基础模块分开理解：RAG、记忆、上下文、技能

这一章的前半部分，基本围绕四个概念展开：RAG、记忆、上下文、技能。这四个词经常被混在一起讨论，但它们解决的问题并不一样。把它们拆开理解，后面看运行框架和设计模式会轻松很多。

1.1 RAG不是知识库插件的代名词，而是“检索-增强-生成”的流程

RAG这个词现在出现频率很高，常见说法是RAG知识库、Graph RAG、Agentic RAG。它的全称是Retrieval-Augmented Generation，检索增强生成。核心思路是：让模型在生成回答前，先从外部知识库或检索系统中拿到相关资料，再把这些资料和用户问题一起交给大模型，让生成过程有据可依。

我见过不少刚接触的人，把RAG理解成“给模型挂一个数据库”。这个理解虽然直观，但不够准确。因为RAG不只是“挂库”，它是一套完整流程：

1. 对知识文档做切分和向量化，建立索引。
2. 收到用户问题后，把问题也做向量化。
3. 通过向量相似度从知识库中召回最相关的片段。
4. 把这些片段作为上下文，连同问题一起交给语言模型生成回答。

这个流程里，哪个环节没处理好，结果都会打折扣。文本切分的大小、向量模型的选择、相似度阈值、召回数量，都会直接影响最终回答质量。第五章里强调的一点我特别认同：RAG的难点不是“能不能跑通”，而是“在切分不合理、召回不准确、生成幻觉这三类问题同时出现时，你能不能定位到具体是哪个环节出的问题”。

1.2 记忆和上下文决定对话连续性，但存储和管理方式完全不同

记忆和上下文经常被混淆，但它们在Agent里承担的任务不一样。

上下文是当前这次请求里，模型能看到的所有信息。它通常包括系统提示词、用户问题、检索到的资料、历史对话片段、工具返回结果。在调用大模型时，这些内容会被拼进Prompt里，占用Token额度。上下文长度有上限，超了就会截断或报错。

记忆则更偏向一种长期存储。智能体需要跨对话保存用户偏好、历史事件、重要事实，才能在后续访问时继续使用。记忆可以有不同实现方式，比如内存里的字典、数据库记录、向量数据库存储，甚至直接写文件。

实操时要先分清，你到底需要的是短期上下文，还是长期记忆。如果只是同一个会话内让模型记住前面说过的话，那可以通过把历史消息放进上下文实现。如果希望用户隔几天再回来，还能记得之前的偏好和数据，那就要设计记忆模块，把信息按结构化或向量化方式存下来。

之前我看过很多演示，说“这个Agent可以连续对话”，其实只是把历史消息全部塞进Prompt，并没有真正记忆系统。小规模试用没问题，但一旦对话轮数变多，Token消耗会快速增长，而且超出上下文窗口后，前面的信息会被截掉。真正工程化时，要用摘要压缩、关键信息抽取、向量召回等方式，把记忆做“瘦身”。

1.3 技能封装是智能体能力的边界，别把所有逻辑都写进提示词

第五章把“技能”单独拿出来讲，这一点很重要。技能可以理解为智能体可以执行的一组工具或操作流程。比如搜索技能、调用API、操作数据库、执行代码、发送消息。技能是Agent与外部世界交互的接口。

早期很多智能体Demo把大量指令塞在系统提示词里，试图让模型“自己学会”用某个工具。这种做法的维护成本非常高。提示词一旦变长，模型容易在复杂任务里丢失关键信息，而且换一个模型，表现可能完全不同。

更好的做法是把技能做成独立的函数或服务，在提示词里只描述“什么时候该调用哪个技能”，具体实现放在外部。比如一个客服智能体，可以有一个“查询订单”技能，后端对应一个订单查询API。模型需要做的只是判断用户意图，生成调用参数，然后调用技能返回结果。这样职责清晰，调试起来也更容易。

判断一个技能封装得好不好，有一个标准：它能不能被单独测试。如果一个技能的逻辑要依赖完整对话上下文才能理解，这个技能就还不够独立。好的技能应该输入明确、输出明确、错误处理明确，就像使用一个标准API一样。

2. 运行框架、开发框架和UI框架到底各管什么

第五章进入系统层面后，出现了好几个“框架”概念：运行框架、开发框架、UI框架。很多人在选型时把这三个混在一起，结果看到一个框架就以为全包了，最后项目卡在某个环节无法推进。

2.1 运行框架负责生命周期，开发框架负责组装能力

运行框架主要管Agent的生命周期：任务如何被调度、状态如何保存、异常如何重启、并发如何控制。比如一个长时间运行的任务，运行框架要能处理Checkpoint，让任务挂掉后可以从最近状态恢复。开发框架则更偏向程序员视角，它提供各种模块和API，方便你快速组装RAG、调用模型、定义工具和编排多Agent流程。

两者边界不总是清晰。有些项目是一个框架同时承担两种角色，有些则是分开。选型时不要只看“它支持Agent”，要问清楚：它怎么管理并发任务？任务中途失败怎么处理？日志和监控怎么接入？这些都不是开发框架的默认亮点，但恰恰是生产环境最需要的东西。

我在看第五章时，发现作者反复强调“默认配置只适合学习，不适合生产”。这个观点对于运行框架尤其适用。跑通一个Demo，通常只需要一次代码调用；但要让这个Demo稳定跑上百个任务，就要额外处理重试、超时、队列、错误分类等问题。这些能力有些运行框架内置，有些需要自己实现。

2.2 UI框架不是可有可无，调试多智能体时可视化非常关键

UI框架常常被忽略，但在多智能体系统里，它的价值比单Agent大得多。单Agent的输入输出比较容易在终端查看；多智能体协作时，多个Agent之间相互发送消息、调用工具、修改状态，如果没有可视化界面，几乎很难追踪问题。

好的UI框架至少应该展示这几类信息：当前有哪些Agent在运行，每个Agent当前处于什么状态，它们之间传递了什么消息，调用工具的参数和返回值是什么，系统提示词和历史上下文长什么样。这些信息能帮你快速判断是哪个Agent产生了错误回复，或者哪一步任务编排出了问题。

有些开发框架自带简单的调试界面，比如提供一个本地网页。这类UI框架适合开发阶段。如果做独立产品，可能会单独选择一套前端UI框架来展示Agent状态，甚至将Agent能力封装成后台服务，用WebSocket或SSE把消息推送到前端。具体方案取决于你是做内部工具还是面向用户的产品。

2.3 选型前先列条件：模型接入、并发、日志、协议支持

我建议在选型之前，先列一个条件清单，不急着比较框架名气和Star数。重要条件通常包括：

• 支持哪些模型接入方式：OpenAI兼容接口、本地模型、国产模型平台。
• 是否支持自定义工具函数，以及工具参数Schema怎么定义。
• 有没有内置RAG能力，还是需要外部向量库。
• 并发任务如何管理，是否有任务队列和限流。
• 日志是否清晰，能否记录每一步的输入输出。
• 是否支持多智能体通信，以及通信协议有没有开放标准。
• UI是否有现成的调试界面，或者需要自己搭建。

如果只是学习，选择文档完善、社区活跃的框架会更顺手。如果做生产系统，要重点看框架是否允许你替换底层组件，比如替换向量库、模型客户端和消息队列。框架锁定本身不是坏事，但被锁定的部分必须是稳定的，不能因为某个模块升级就导致整个系统重写。

3. 从单Agent到多智能体：设计模式与A2A协议

第五章后半部分，焦点转向了设计模式和多智能体系统。单Agent能解决简单任务，但遇到需要分工协作、上下文过长、多个专业角色协同的场景，多智能体系统就变得有必要。

3.1 先掌握几个基础设计模式：ReAct、Plan-and-Execute、工具调用

设计模式不是某个框架特有的语法，而是一种任务编排思路。第五章比较强调的是三个基础模式。

ReAct模式，全称是“Reason + Act”，也就是在推理和行动之间交替。模型先思考当前需要做什么，然后调用一个工具，得到结果后再继续思考，直到任务完成。这个模式适合需要多次调用工具、逐步排查问题的任务。比如让Agent查询多个数据库并汇总结果，用ReAct会很自然。

Plan-and-Execute模式，则是先把任务拆成一个计划列表，再按顺序执行每个步骤。它比ReAct更早做全局规划，适合任务步骤清晰、需要稳定执行的场景。缺点是如果计划本身不合理，后续执行会跟着错，所以通常要有重新规划机制。

工具调用模式，可以理解为让模型在每次生成时，根据用户意图选择一组可用工具，并输出结构化的调用参数。框架根据模型输出调用对应函数，再把结果返回给模型。现在多数Agent框架都支持这个模式，它和ReAct并不冲突，ReAct偏重推理流程，工具调用偏重函数接口设计。

学习设计模式时，不要只记名字，要亲手分别用ReAct和Plan-and-Execute跑同一个任务，对比它们在不同任务上的表现。你会发现，没有一个模式是万能的，关键是根据任务特点选择。

3.2 为什么多智能体系统需要A2A这类通信协议

A2A，即Agent-to-Agent，是最近讨论度很高的概念。通俗理解是给多个智能体之间定义一种标准化的通信方式，让它们可以互相发现对方、发送请求、返回结果。就像Web服务之间有HTTP协议一样，多智能体系统也需要一套成熟的交互协议。

在只有一个Agent时，所有组件的调用都是内部函数，不需要网络协议。但一旦拆成多个Agent，并且它们可能运行在不同进程甚至不同机器上，就需要明确的消息格式、会话标识、权限校验和错误返回。A2A协议尝试把这些问题标准化。相关热搜词里“谷歌刚发布了一个a2a(agent2agent)协议”关注度很高，也说明了这类标准在社区里的价值。不过这里我不准备把某个具体协议版本当绝对事实，因为协议迭代较快，落地时还是要以你使用的框架文档为准。

对普通开发者来说，A2A带来的最直接变化是：将来Agent之间的通信可能像调用API一样规范。一个Agent只需要知道另一个Agent的地址、能力和请求格式，就能调用它，而不需要为每个Agent定制一套内部函数接口。

3.3 一个多智能体协作流程的拆解示例

多智能体系统的设计，往往从业务流程开始。比如做一个“企业知识问答系统”，可以拆成三个Agent：

• 接口人Agent：负责接收用户问题，判断该交给哪个专业Agent。
• 检索Agent：专职对接RAG知识库，负责搜索文档、整理摘要。
• 汇总Agent：整合多个来源的信息，生成最终回答。

实际运行时，用户先问接口人Agent，接口人Agent通过A2A协议把请求发给检索Agent，检索Agent访问向量数据库拿回相关片段，再返回给接口人Agent。如果问题还涉及数据分析，接口人Agent还可以调度另一个工具Agent去执行Python代码，并把执行结果一并汇总。

这个流程里，每个Agent只做一件事，内部逻辑清晰，也方便单独测试和替换。比如你想把RAG的向量库从A换成B，只需要改检索Agent内部实现，接口人Agent和汇总Agent不受影响。这就是多智能体系统的一个明显优势：模块解耦。

但也要注意，多智能体系统不是随便拆就能提升效果。拆得越细，通信开销越大，失败概率也越高。设计时应遵循一个原则：如果一个Agent的任务足够简单，不依赖外部环境，那就没必要拆出来。拆分的价值在于减少单个Agent的上下文负担，而不是制造一堆互相等待的调用链。

4. 环节与评测：怎么判断智能体系统真的“好用”

“能跑通”和“好用”完全是两码事。第五章把环节与评测单独列出来，给了不少评测视角。这一部分对实际项目很有价值，因为很多团队做完Demo后，不知道下一步该怎么验收。

4.1 一个完整Agent任务要经过哪些环节

一个标准的Agent任务，通常包括这些环节：

• 任务接收：用户输入，或上游系统传入任务指令。
• 规划：Agent根据目标生成执行计划。
• 检索或工具调用：从外部获取信息或执行操作。
• 中间推理：模型根据返回结果更新当前状态。
• 生成输出：形成最终回答或写回数据。
• 错误处理：任何一步失败，都要有重试或降级策略。

评测时，不能只看最后一句话是否合理。要把每个环节单独拆出来检查。例如检索环节，要问“相关文档有没有被召回到”；工具调用环节，要问“参数是不是正确、调用是不是成功”；生成环节，要问“输出有没有忠实于检索结果，是否存在幻觉”。这样拆开评测，才能快速定位系统瓶颈。

4.2 RAG评测：检索质量、生成质量、端到端指标怎么看

RAG的评测通常分三层。

第一层是检索质量。常用指标包括召回率、精确率、命中率等。具体到RAG场景，会关注“正确答案片段是否在召回结果中”。如果召回不到，后面生成再强也没用。你可以人工构造一组问题，把每个问题对应的文档片段标出来，然后测试不同切分大小和TopK参数下的召回情况。

第二层是生成质量。在给定检索结果的情况下，生成内容是否忠于原文，是否包含伪造信息，是否回答完整。可以用人工打分，也可以用大模型评估。但用模型评估时要注意评测模型的偏好，不要盲信评分。

第三层是端到端质量。也就是用户真正感受到的最终回答好不好。这一层往往最接近业务目标，但受前面两层影响。如果端到端指标差，要逐层回溯是检索问题、生成问题，还是两者之间的衔接问题。

常见的RAG指标还有平均答案准确率、上下文相关性、忠实度等。不同框架和论文对指标定义略有差异，落地时可以先选择一套可解释的指标，持续跑一批固定测试集，观察改动前后的变化。固定测试集非常关键，没有它，你无法判断是优化有效，还是只是这次运气好。

4.3 多智能体系统还要额外关注通信和任务分配

多智能体系统的评测，比单Agent更复杂。因为它不仅要求每个Agent自身表现好，还要求协作过程正确。

要关注的指标包括：

• 任务完成率：整个流程最终是否得到正确结果。
• 通信成功率：Agent之间消息是否正确传递和解析。
• 编排正确性：任务是否被分配给合适的Agent。
• 资源消耗：调用模型次数、Token消耗、总耗时。
• 故障恢复能力：某个Agent失败后，系统能否降级或重试。

有一种现象很常见：单个Agent评测都通过，但组合起来任务失败率上升。原因通常是消息格式不一致、上下文在传递过程中丢失、或者某个Agent的输出不符合另一个Agent的输入要求。排查时，要让系统打印出每个Agent的输入和输出消息，尤其是跨Agent传递的原始数据，不要只打印最终结论。

评测数据集的构造也要符合多Agent场景。不能只准备“回答一个问题”的测试集，而要准备包含多步操作、需要切换Agent的复杂任务。比如“查询上季度销售额，对比本月销售数据，生成一份风险提示”，这种任务能更好暴露协作问题。

5. 实操复盘：从RAG单链到多智能体系统的落地步骤

这一章的内容如果只停在概念层面，很容易看完就忘。我建议按一条主线亲手做一遍：先跑通单Agent+RAG，再加记忆和技能，最后扩展成多智能体系统。下面是我自己复现时的步骤和参数参考，环境不一定和你完全一致，但思路可以直接复用。

5.1 最小环境准备：模型、向量库、依赖

最小环境需要四样东西：语言模型API或本地模型、向量数据库、Python环境、几个核心依赖。

语言模型可以用支持OpenAI接口的兼容服务，也可以直接用本地部署的量化模型。如果机器显存在8GB以下，本地模型建议选7B级别的量化版本，重点先验证流程，不要追求答案质量。向量库可以用常见的轻量级方案，比如Chroma或FAISS，它们适合学习和单机项目。如果数据量超过几十万条，再考虑更重型的向量数据库。

我整理过一个最小依赖清单，不一定完整，但能覆盖大部分流程：

pip install langchain chromadb openai

这里要说明一下，LangChain本身更新很快，API接口可能在不同版本有变化。如果你的代码报错说找不到某个类或参数，先查当前版本的文档，不要死记网上老教程里的写法。

5.2 先跑通一个带RAG和记忆的单Agent

跑通RAG链路的核心是三步：加载文档、建索引、写检索函数。以LangChain风格为例，流程大致是：

1. 把文本按固定大小切分，建议先按500到800字符切分，重叠部分控制在50到100字符。
2. 用Embedding模型对每个切片做向量化。
3. 存入向量数据库。
4. 启动一个查询函数，输入用户问题，返回TopK最相关的文本片段。
5. 把文本片段和用户问题拼进Prompt，调用大模型生成回答。

代码可以按这样组织：

from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma from langchain.llms import OpenAI # 1. 切分 text = load_your_document() # 你的文档读取逻辑 splitter = RecursiveCharacterTextSplitter(chunk_size=600, chunk_overlap=80) docs = splitter.split_text(text) # 2. 向量化 + 入库 embeddings = OpenAIEmbeddings() vectorstore = Chroma.from_texts(docs, embeddings) # 3. 检索 retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) context = retriever.get_relevant_documents("你的问题") # 4. 生成 prompt = f"根据以下资料回答问题：\n{context}\n\n问题：...\n回答：" llm = OpenAI() answer = llm(prompt)

这里的参数比较关键：chunk_size控制切分长度，太小会导致语义不完整，太大会让检索返回的内容包含大量噪音；search_kwargs中的k控制召回条数，一般先设3到5条，然后根据效果调整。

接着加入最简记忆。最简单的实现是把用户问题、Agent回复存成一个列表，下一次查询时把最近几轮对话拼接到Prompt里。这种“假记忆”适合验证流程，但要注意别超过模型上下文窗口。

5.3 引入技能与工具调用，再拆分多智能体

单Agent跑通后，可以加入一个真实工具，比如搜索接口或计算器。定义一个函数，然后在提示词里告诉模型“当你需要查询订单时，调用query_order函数，参数是订单号”。框架解析模型输出后，帮你执行函数并返回结果。

接下来再考虑拆多智能体。不要一开始就拆得很细。建议先把现有Agent拆成两个：一个负责问题理解和路由，叫“主控Agent”；另一个负责RAG知识库检索，叫“知识Agent”。主控Agent收到问题后，先判断是否需要知识Agent，如果需要，就通过内部消息调用它。

在代码层面，如果使用现成框架，通常需要定义每个Agent的Prompt和工具列表。如果没有用框架，也可以用简单条件判断模拟消息传递。例如：

class KnowledgeAgent: def handle(self, question): return retriever.get_relevant_documents(question) class MainAgent: def handle(self, question): if "知识" in question or "文档" in question: knowledge = KnowledgeAgent().handle(question) return generate_answer_with_knowledge(question, knowledge) return generate_answer(question)

这个示例非常简陋，但足够让你理解多智能体的本质：把一个大任务拆分成可独立处理的小单元，再把它们组装起来。等这个结构跑顺了，再引入A2A协议或分布式的Agent运行框架。

5.4 常见报错和排查顺序

我在复现时遇到过不少问题，这里按出现频率列一下排查顺序。

第一看输入格式。报错最频繁的原因是文档不是纯文本，或者路径不对。切分函数如果传入了非UTF-8编码的文件，很可能直接抛异常。第二看依赖版本。LangChain和向量库版本兼容性需要留意，很多问题升级或降级版本就能解决。第三看资源占用。本地模型跑长文本时，显存和内存占用会快速上涨，如果任务卡住，先看是不是内存溢出。第四看Prompt拼接。如果输出内容经常离题，检查上下文是不是拼接错误，比如把检索结果放到了不该放的位置。

如果某个Agent在协同任务中始终不触发，不要急着改Prompt，先打印出该Agent的输入消息。很多时候是主控Agent的意图判断不准确，或者消息格式没有按照协议字段传过去。与其猜测，不如在关键节点增加日志输出，记录每一步的输入输出。

6. 边界与避坑：这些经验不是从文档里看出来的

读第五章时，我最大的收获其实不是那些概念，而是作者对边界的强调。技术文档往往只讲“能做什么”，但实际开发更怕的是“哪些场景别这么做”。

6.1 低配置环境能跑通不代表能批量跑

很多人拿本地小模型跑通一个Demo后，就以为可以直接上生产。低配置环境的“跑通”和批量处理的“稳定”完全是两回事。本地8GB显存可以跑7B量化模型生成一句话，但连续处理100条任务，有可能因为显存碎片、温度、上下文膨胀导致进程崩溃。

批量处理时，要尤其注意输出命名和任务队列。多个Agent并发写同一个文件，会导致内容互相覆盖。更稳妥的做法是每个任务分配唯一ID，所有中间产物和最终输出都带上这个ID。另外，批量任务建议控制并发数，比如先设1，跑通后再逐步增加到2、4、8。观察吞吐量和错误率的变化，不要直接把并发拉到框架允许的最大值。

6.2 评估时别只盯着准确率，还要看失败重试和稳定性

RAG和多智能体系统的评测，很容易让人陷入“抠指标”的状态。比如检索命中率从80%提到85%，就觉得很满意。但生产系统里，真正让用户崩溃的不是那85%的成功场景，而是15%的失败场景里，系统是不是给出了错误答案、是否无限重试、是否把责任推给用户。

稳定性的判断标准包括：超时后系统是否自动停止；工具调用失败后是否有重试机制，还是直接把异常抛给用户；任务失败后，日志是否足够定位问题；长时间运行后内存和连接数是否持续增长。这些需要通过压测和长时间跑任务来验证。

6.3 不要把所有能力都塞进一个Agent

多智能体系统的价值在于解耦，但解耦的前提是模块边界清晰。我见过一些项目，名义上是多智能体，实际上把所有Prompt、工具、RAG逻辑都塞在一个Agent里，只是换了几套不同的系统提示词而已。这只能算是“可变风格”，不是多智能体协作。

一个合理的Agent，应该具备明确的能力边界、独立的输入输出格式、可复用的工具集合。如果你发现两个Agent之间总是互相传递大量原始文本，并且都依赖相同的历史上下文，那大概率说明边界没划好。建议把重复的部分抽成共享工具，或者合并成一个Agent。

6.4 选型时警惕“全能框架”陷阱

社区里经常出现一些新框架，宣称同时支持RAG、记忆、多智能体协作、可视化、A2A协议，看起来什么都能做。真正用起来，往往会发现每个模块的深度都不够，尤其在垂直场景下，自定义能力很差。

选型时要做的不是找到“最好的框架”，而是找到“最适合你主场景的框架”。如果你的核心是知识库问答，就重点评估RAG模块和检索质量；如果你的核心是多Agent任务编排，就重点评估消息传递、状态管理和可视化调试能力。与其被一个全能框架绑住，不如选择几个能互相替换的成熟组件，在关键路径上保持控制权。

第五章最后提到，智能体系统的开发本质上是一个“工程问题”，而不是“模型魔法”。我深有同感。这类系统真正落地时，最需要盯住的不是某个模型有多强，而是输入格式是否统一、上下文拼接是否正确、工具调用是否可靠、日志是否完整。这篇分享按从RAG到多智能体系统的链路走了一遍，核心是希望大家先单链跑稳，再逐步拆分和扩展。智能体系统的复杂度是指数级上升的，能在一个环节解决的问题，就不要拆成三个环节。