企业官网建设流程全解析

“复杂架构的取舍”这个标题，实际上是我最近在某个知识密集型项目（就叫模拟项目X吧）里做架构选型和重构时，被反复问到最多的一个问题。我们当时手里有一批存量文档、一堆非结构化数据，还要支持问答、知识检索、内容摘要多个场景，市面上主流的RAG方案跑了几轮，答案是“能跑，但不好用”；于是团队里开始有人提Agentic RAG，有人想上LLM Wiki，还有人直接说干脆上一套Multi-Agent系统。结果开会讨论了大半个月，光概念对齐就花了好几轮。

这篇博文不打算堆术语，而是把我在模拟项目X里实际踩过的坑、做过的小规模对比测试、最后确定的取舍逻辑，尽量原样讲清楚。你会看到有多少用户场景其实不需要上Agent，也会看到一个“看起来高级”的多Agent架构是怎么把延迟和成本抬到难以接受的——以及反过来，什么时候我强烈建议上Agent。这篇文章适合谁读？给正在做RAG选型、看到Agentic、Wiki、Multi-Agent这些词就上头、但又担心过度设计的架构师/开发者。如果你只是想了解概念，网上资料多的是；但你如果是想落地一个不翻车的复杂知识系统，这篇应该能省你几个星期试错时间。

1. 三个概念到底在解决什么问题

1.1 Agentic RAG不是“给RAG加个Agent”这么简单

Agentic RAG这个词被说烂之前，大家用的基本是朴素RAG：用户问题进来，向量检索召回TopK段落，拼Prompt，丢给LLM生成答案。朴素RAG的问题很典型：它对“用户问什么”和“系统该查什么”缺少判断力。问一句“上个季度我们某个功能模块的线上故障和处理方案分别是什么”，如果按关键词切分文档，召回结果大概率是几段互不相关的内容，甚至把不同季度的内容混在一起。

Agentic RAG的核心区别，是把“检索策略”从固定流程变成模型推理后的动态决策。它不是简单地“先嵌入式检索再生成”，而是让模型根据问题去决定：要不要拆子问题、先查哪个库、查完是否需要二次检索、当前结果是否够用。说白了，它把一个一次性的RAG链路，变成了一组由Agent编排的、带反馈循环的检索动作。

但要注意，Agentic RAG不等于Multi-Agent。一个Agent在内部套循环，多轮调用工具、自己评判结果、重试或停止，这叫“单Agent多步”。只有当你同时存在多个有不同职责的Agent并行或协作时，才是Multi-Agent。这两者经常被混为一谈，会给架构选型带来不必要的复杂度。

1.2 LLM Wiki：把知识库做成“给大模型看的维基百科”

LLM Wiki不是指开个Wiki站点，也不只是知识库换了个名字。它是一套面向大模型的知识组织范式：以“页面+实体+关系+回链”为基本单元，把知识拆成可控、可更新、可校验的结构化节点。

传统RAG喜欢把PDF、Doc整篇切块塞进向量库。这种做法的隐含假设是“知识按原文切分会保持语义完整”，但实际切出来的片段往往把上下文切断，导致召回结果明明内容相关、逻辑却接不上。LLM Wiki的思路反过来：先通过模型对原始材料做理解、抽取、归纳，生成独立的知识卡片或实体条目，再通过显式关系维护它们之间的联系。

我举个例子。把一份操作手册转移到LLM Wiki后，“登录”“权限配置”“API密钥轮换”会成为独立页面，“用户”和“角色”之间会有显式关系，“权限配置”页里会回链到“角色”页。检索时命中的是这张语义卡，而不是手册里某个可能跨页的段落。这个模式对复杂知识问答尤其有效，因为它让检索单元从“物理片段”变成了“语义实体”。

但LLM Wiki也有代价。它的建库过程是重人力、重算力的。文档更新了，知识卡片不会自动刷新；实体关系错了，模型检索时可能一本正经地把错误链路走完。它本质上要求你先有一个高质量的“知识运营”机制，而不是像向量库那样扔进去就能用。

1.3 Multi-Agent的多角色协作，解决的是“一个大模型干不了所有事”的难题

我在项目里真正体会到Multi-Agent的价值，是在流程性任务里。比如一个“竞品动态监控”任务，需要同时抓取多个信源、做实体识别、做情感判断、聚合成周报。如果你用一个Agent顺序处理所有步骤，上下文会越来越长，某一步出错可能整体重来。

Multi-Agent的解法，是把角色拆开：规划Agent负责拆任务，检索Agent负责查不同数据源，分析Agent负责产出结论，审查Agent负责查漏和纠错。每个Agent职责单一、上下文可控，任务可以被并行执行，也可以被独立调试。这个点在工程上价值巨大——一个纯RAG链路出了问题，你只能从头到尾排查；多Agent系统里，你直接把某个Agent的输入输出拉出来看，问题定位边界就非常清晰。

不过，Multi-Agent带来的最显著副作用，是局部可控、全局难控。Agent之间通过消息协作，消息格式一旦不统一，就可能出现“A理解了B的错误输出然后继续往下传”的情况。我在项目中见过一个典型现象：审查Agent本意是发现检索结果不足，结果它和检索Agent互相踢了四五轮皮球，直到触发最大迭代数才终止，而最终输出质量并不比单Agent好多少。这种“协作反而退化”的场景，后面我会展开讲。

所以三者的定位需要先认清：Agentic RAG擅长动态检索和多步推理，LLM Wiki擅长高质量的知识表示和检索单元设计，Multi-Agent擅长任务分解和多方协作。它们不是同类事物，不能用一个替代另一个，只能互相嵌套。

2. 为什么“复杂架构”必须做取舍，而不是做叠加

2.1 每一层复杂度都有明确的代价

很多团队陷入“架构竞赛”的误区：RAG效果不好，就加Agent；Agent调度乱，就上多Agent编排框架；知识表示不准，就建Wiki。问题是，他们没有问一句“当前效果不好的根因到底在哪”。我是一个“先做代价分析再看收益”的人，所以在项目里做了个简单对比：

这张表不是理论推演，是我们在模拟项目X里压测二十几条真实问题的平均体感。多Agent系统因为涉及多轮模型调用和Agent间消息传递，单次请求跑了五十多秒的情况非常常见；而朴素RAG即使召回效果一般，4秒内也肯定返回了。

对C端体验来说，十秒和四秒的体感差异是颠覆性的。对内部知识问答来说，几十秒勉强能忍，但成本模型往往扛不住。所以架构取舍的第一条原则是：延迟和成本不允许你无限制地加层。

2.2 问题场景决定架构形态，而不是反向推导

我先给你看看我在模拟项目X里是怎么分类问题的。我们当时梳理了四类核心场景：

1. 事实型问答：比如“某个接口的超时时间是多少”。这类问题通常是单跳检索，朴素RAG基本能解决。
2. 多跳推理问答：比如“A服务和B服务的认证机制分别是什么，它们之间有什么共同点”。这需要多次检索并交叉对比。
3. 知识运营与更新：比如“新增了一套部署规范，后续所有相关问答都要基于新规范回答”。这需要知识表示层面的更新机制，单靠改向量库不靠谱。
4. 流程型任务：比如“每天汇总外部资讯并生成周报”。这需要多步处理、跨源聚合，是典型的多Agent任务场景。

顺带说一下，在整理这个分类表时，我发现团队里很容易出现一个偏见：我们总希望用一个架构解决所有问题，于是倾向于给所有场景都上多Agent。但细看就知道，场景1用朴素RAG加一点关键词路由就够了；场景2需要Agentic RAG；场景3最合适的其实是LLM Wiki；场景4才值得上Multi-Agent。

所以架构选型的正确姿势是“场景反推架构”，而不是“架构先定，再看场景怎么兼容”。我们当初差点干出后者，还好第二轮讨论时把需求清单摊开了，才发现真正需要上Agent的场景连三成都不到。

2.3 我在模拟项目X里的实际决策路径

具体流程是这样的。第一轮，我们把存量问答数据做了一次分类统计，发现事实型问题占68%，多跳问题占22%，流程型任务占10%。第二轮，我们判断事实型问题用朴素RAG加一个轻量级意图路由就能到85分，多跳问题用Agentic RAG能到90分，流程型任务用单Agent跑通闭环也能到80分。第三轮，我们直接做了一个结论：用“意图路由 + 朴素RAG”承接大部分请求，用Agentic RAG处理困难子集，LLM Wiki作为知识底座，多Agent只用于真正的并行采集流程。这个组合看起来甚至有些“不酷”，但它在真实负载下延迟平均控制在5秒内，成本可控，且每个模块都可以独立调优。

这里面最反直觉的一个决策，是“放弃把Multi-Agent做成核心链路”。做出这个决定的原因不是技术不成熟，而是可运维性。多Agent链路一旦出了坏case，你在日志里要同时翻四五个Agent的输入输出来回比对，排查效率极低。我们当时只有两个后端工程师，撑不起这种排查成本。

3. Agentic RAG的实操要点

3.1 核心组件拆解

如果你决定上Agentic RAG，我建议按这五个组件来做，而不是直接套某个全家桶框架：

• Router（路由）：负责把用户问题分类，判断该走“朴素RAG”还是“Agentic RAG”，以及是否需要查Wiki。路由可以用轻量模型，甚至用关键词规则先兜底，因为它的错误会放大到下游。
• 查询改写（Query Rewriter）：负责把模糊的原始问题转成适合检索的多个子查询。这里的关键是不要求它输出复杂JSON，只要让它列出检索关键词即可，减少LLM输出不稳定的概率。
• 检索器（Retriever）：这是可插拔的接口，可以是向量检索、BM25、或者查LLM Wiki的知识卡片。项目里我建议把检索器抽象成“服务”而非“函数”，因为Agent循环可能多次调用它，服务可以对结果做缓存。
• 重排序（Re-ranker）：负责对多路召回结果做融合排序，控制进入上下文的内容数量。
• 验证器（Verifier）：负责判断结果是否真的回答了用户问题。这是Agentic RAG能“循环”的关键，也是最容易写废的一环。验证Prompt如果写得太粗糙，Agent会频繁做无意义重试。

3.2 一个可落地的Agentic RAG流程

我的核心流程一般这样编排：

1. 用户问题进入Router，先做场景分类。
2. 如果判定为多跳推理问题，进入Agentic RAG主流程。
3. 主流程先做查询改写，拆出2到3个子查询。
4. 子查询并行检索，设置最大并发数和超时时间，超时部分直接跳过并记录。
5. 多路结果经过Re-ranker合并，保留TopK段。
6. 生成初步答案，交给Verifier。
7. Verifier判断信息充分性和一致性，充分则输出，不充分则触发最多两轮补充检索。
8. 如果两轮后仍未通过，退回最接近的答案并给出置信度提示。

这里我想强调一个参数：最大迭代轮次，我习惯直接定成2。太少了，Agentic跟普通RAG没区别；太多了，会出现“答案没变好，费用翻三倍”的情况。两轮意味着单次问题最多会触发三组检索，这已经在成本和效果之间比较平衡了。

3.3 成本与延迟的四个控制手段

第一个手段是路由用小模型。很多团队让主对话模型一上来就做Agent规划，成本高且慢。我给模拟项目X配了个轻量分类模型专门做Router，它只输出一个类别标签，准确率依靠人工标注和持续清洗，实测延迟在毫秒级。第二个手段是缓存。同一个问题在一段时间内的改写结果和检索结果可以做缓存，尤其是热点问题，命中缓存后整体响应能直接降到1秒内。第三个手段是限制工具数量。Agent能调用的检索源最多四个，每多一个源，模型在选择时就越容易出错。第四个手段是并行化。多子查询如果串行跑，延迟是累加的；改成并发后，总延迟从“所有查询之和”变成“最慢查询”加上重排时间，这个优化非常关键。

3.4 质量评估和评测集设计

Agentic RAG的最大风险是“看起来答得很好，实际是幻觉”。所以我做了一套固定的离线评测流程，它包含三个指标：召回完整性（必要信息点是否都被检索到）、答案忠实度（生成内容是否都有引用支撑）、无益重试率（多少case触发了补充检索但答案并未变好）。无益重试率特别重要，它直接反映Verifier和检索器的匹配度。如果无益重试率超过30%，大概率是Verifier写得太宽松或检索器召回范围选错了。

评测集设计建议至少覆盖三类样本：真实用户问题、由文档反推的模拟问题、跨主题的复合问题。前两类保证基础准确性，第三类才是Agentic RAG发挥优势的地方。如果没有第三类样本，你根本测不出Agentic RAG比朴素RAG强在哪，那也就别急着上线了。

4. LLM Wiki的设计与落地

4.1 核心设计：Page、Entity、Relation、Backlink

LLM Wiki里最基础的单元是Page，每个Page对应一个主题词或实体。比如“登录认证”是一个Page，“API密钥管理”是另一个Page。Page之间通过Relation关联，比如“API密钥管理依赖于登录认证”。Backlink在系统中的价值非常大：它可以帮你反查“哪些知识卡片引用了这个页面”，当某条知识过期时，你可以顺着回链批量检查受影响的内容。

我强烈建议Page内部结构保持固定：摘要（200字内）、核心内容、变更记录、适用场景、相关页面。固定结构的好处是，你可以对知识卡片做批量校验，还能保留全文检索能力，而不是只依赖向量搜索。

4.2 从存量文档构建LLM Wiki的流程

我们当时不是从零开始写Wiki，而是有700多篇存量文档。构建流程大概分五步：

1. 文档分域解析。先按业务线或文档类型归类，做粗粒度聚类，避免全量解析后主题混乱。
2. 实体识别。用抽取型模型识别每个文档里的关键实体和候选标题。
3. 关系抽取。判断实体间是“属于”“依赖”“同义”“冲突”中的哪种关系。这一步可以自动化，但必须人工抽检。
4. 知识卡片生成。用LLM为每个实体生成结构化卡片，并保留原始文档ID作为溯源。
5. 人工校准。我不建议指望全自动。挑出高频被检索到的实体卡片人工审核，低频卡片可以先用着，后续被检索到了再补充审核。

这套流程的产出不只是“知识库更规整”，更核心的收益是：它让检索单元从“物理切块”变成了“语义卡片”。向量化卡片标题加摘要进行检索，召回精度比切块法高很多，而且因为卡片自带关系链，下游Agent能顺着关系继续探索。

4.3 LLM Wiki和RAG检索的结合方式

在我最终选型的架构里，LLM Wiki不是替代检索，而是优化知识底座。具体做法是：文档经过处理进入Wiki知识卡片，卡片会以结构化字段形式存一份，同时以摘要和标题生成向量；检索阶段先召回卡片，再用卡片关联的原始段落做扩展上下文。这相当于把“一次模糊的全文检索”拆成“先找实体，再扩展细节”。

这样做最大的收益是解决召回结果“上下文割裂”问题。切块法会把“API密钥轮换步骤”从操作手册里硬切出来，丢掉了前置的“触发条件”，LMM Wiki则通过卡片关系把触发场景、操作步骤、验证方式放在同一知识单元下，Agent拿到的是完整语义链。这个体验差异我们让好几个业务方盲测，普遍反映Wiki方案的答案逻辑完整度更高。

4.4 维护难题，不藏着掖着

LLM Wiki最大的坑就是“建库一时爽，维护火葬场”。文档一旦更新，卡片不会自动同步。我们当时做了一个折中方案：每天定时跑增量抽取，把新增或修改的文档和现有卡片做diff，产生“待确认卡片”列表，由运营人员一键确认或驳回。虽然做不到全自动，但至少把人工工作量收敛到了只有发生变更的内容上。

另一个棘手的是冲突消解。两份文档对同一个功能给出了互相矛盾的说明，LLM Wiki会同时挂上这两个结论。我的做法是给Page增加“状态”字段：有效、过期、冲突。冲突状态的卡片不会被默认检索到，而是会触发人工复核。这个机制看起来很简单，但它极大降低了Agent拿错误知识去回答问题的概率。

5. Multi-Agent架构的设计与协调

5.1 角色拆分的两种风格，和我的选择

Multi-Agent落地时，最常见的两个方向是垂直领域拆法和水平编排法。垂直领域拆法，比如检索Agent只负责检索，分析Agent只负责分析，每个Agent都是一个领域的“专家”。水平编排法则像一个主管Agent带着一堆执行Agent，主管做决策，执行Agent做具体动作。我在模拟项目X里的做法是两者结合：主流程采用主管Agent统一调度，底层再按领域拆检索Agent和审查Agent。因为纯垂直拆法会出现复杂的Agent间协作协议，而纯水平编排又会把大量任务压力压在主Agent上，让它最终成为性能和上下文瓶颈。

5.2 Agent之间的协作模式

实际项目里常见的协作模式有三种：顺序流水线、并行与汇总、辩论式协作。顺序流水线适合那些步骤天然有强依赖的任务，比如“先抓取资讯，再分析观点，最后生成报告”。并行与汇总适合多个独立信源同时采集，然后再由汇总Agent融合。辩论式协作则会增加“提出观点—反驳—再评估”的环节，适合高风险决策，但代价是好几轮模型调用，项目里我们几乎不主动用。

我建议刚上手时只做两种：顺序流水线和并行汇总。我相信你也会发现，任务一旦进入辩论模式，prompt里任何含糊的描述都会被放大，Agent会开始重复已经说过的内容，系统自然变慢变贵。

5.3 编排框架选型与一段伪代码

框架选型这块，我没有特别偏好某一家，评价标准也很简单：能否支持显式地定义Agent节点和转移条件，能否追踪每条任务的全局状态。市面上的开源多智能体编排框架和商业平台都可以，但最关键的是“控制流要写在代码里，而不是全交给模型”。我见过一个也采用类似框架思路的项目，把控制流完全交给自然语言，结果模型把任务A和任务B串成了错误顺序，直接就延误了整个上线计划。

下面是一段核心逻辑的伪代码，展示如何显式地定义Agent节点和它们之间简单的协作流程：

class AgentNode: def __init__(self, name, run_func): self.name = name self.run_func = run_func self.next = {} def add_next(self, condition, next_node): self.next[condition] = next_node retrieve_agent = AgentNode("retriever", run_retrieve) analyze_agent = AgentNode("analyzer", run_analyze) review_agent = AgentNode("reviewer", run_review) retrieve_agent.add_next("success", analyze_agent) retrieve_agent.add_next("empty", review_agent) def execute(start_node, initial_input): current = start_node state = {"input": initial_input, "trace": []} visits = 0 while current and visits < MAX_HOPS: output = current.run_func(state) state["trace"].append({"node": current.name, "output": output}) if not output.get("status"): break current = current.next.get(output["status"]) visits += 1 return state

这段代码的重点在于状态迁移是显式的：检索Agent返回status为empty时，系统会直接转到review_agent，而不是让模型自己决定下一步。这样你的编排框架做什么、不做什么，完全由代码保证，模型只在节点内部的run_func里做局部推理。这才是多Agent系统能稳定控制的基础。

5.4 稳定性与可观测性，这是多Agent的生存线

多Agent系统最容易出现的问题，第一是上下文污染：Agent间传递的消息里夹杂了无关历史信息，接收方被带偏。第二是任务重复：两个Agent在处理同一批数据时做了重复计算。第三是死循环：Agent互相触发补充动作，直到达到最大步数才停下。

我处理这些问题的经验是：

• 每个Agent只接收“结构化任务输入”，不接收完整聊天历史。如果需要上下文，显式传摘要。
• 全局只保留一份“状态对象”，所有Agent都向状态对象读写，而不是在消息里互相传全部信息。
• 每次Agent调用都打印trace，并把所有模型请求日志统一收集，方便事后回放。

没有可观测性的多Agent系统，我认为在真实业务里几乎不可维护，因为跑得慢和答得差的原因往往藏在多层调用里。

6. 常见问题与排查经验

6.1 问题速查表

我在项目里积累了不少问题处理清单，挑几个最高频的放出来：

这张表看起来简单，但每一项背后都对应具体的调试过程。比如“Verifier太严”那次，我统计了半天，发现无益重试率从20%涨到了40%，问题不在检索，而在验证Prompt里用了“必须完整覆盖所有要点”这种含混措辞——模型不知道“所有”到底是多少，就总想再查一次。

6.2 几个调试小技巧

第一个建议是把中间过程可视化。我给模拟项目X写了一个简单的调试面板，能展示每个查询改写结果、召回片段、验证器评分。面板上线后定位问题的效率至少提升了一倍，尤其是Agentic RAG这种多步链路，过去靠猜的日子实在难熬。

第二个建议是做最小复现用例。遇到坏case，不要直接调Prompt，先构造一个最小文档集和一个固定问题，把检索结果逐步打印出来，看到底是在哪一步开始跑偏。通常你会发现，问题不是模型能力不够，而是某个环节的输入格式不符合预期。

第三个建议是Prompt冻结。每次调Prompt前都会拍一个版本号存档，并记录修改前后的评测指标。没有版本管理的Prompt迭代，纯粹是碰运气。我在项目里吃过好几次亏——改了某处Prompt，一边效果变好，另一类问题全部崩掉。

第四个建议是渐进式回滚。当新架构上线后某类问题效果下跌，不要立刻全量回滚，可以先把它降级成老流程，观察几天。多Agent系统尤其需要这个能力，因为影响面非常广，一次错误的全量回滚代价太高。

6.3 最后想说的经验

回顾整个项目，我最大的体会是：架构的价值要放在具体的延迟、成本和可维护性约束里评估。Agentic RAG、LLM Wiki、Multi-Agent这三个词本身没有高低之分，适合的场景比先进性更值钱。我身边有不少团队本来用朴素RAG就能解决80%的问题，却因为急于引入新概念，把系统撑成了一个调试特别困难的怪物。我自己也走过这段弯路，后来学会的第一件事就是：能用一个简单方案解决的事，绝不上复杂架构；必须要复杂时，先把可观测性的架子搭好，再谈Agent协作。希望这篇复盘，能让你在选择架构时少走几个我走过的弯路。