企业官网建设流程全解析

1. 从一份日报标题说起：Agent 与 LLM 技术生态的当下切面

看到"Agent / LLM 技术精选日报"这个标题，我第一反应不是"又一份资讯汇总"，而是它背后折射出的技术节奏——这个领域的迭代速度已经到了需要"日报"这种粒度来跟踪的程度。我做 AI 应用开发差不多有几年时间，从最早拿 LLM 当个高级文本补全工具，到现在天天跟 Agent 编排、RAG 检索链路、MCP 工具协议打交道，中间踩的坑和交的学费，足够写好几篇复盘。这篇博文我不打算复述某一天的新闻，而是借这个标题和它关联的一批热搜词，把 Agent、LLM、RAG、GraphRAG、MCP 这几条主线串起来，讲清楚它们各自解决什么问题、彼此怎么配合、实际落地时哪些地方最容易翻车。

如果你正在做 AI 应用、准备搭自己的知识库、或者只是被"Agent""MCP"这些词刷屏刷得有点懵，这篇内容应该能帮你把概念地图理清楚。我会尽量用大白话加实际案例来讲，不堆术语，但该有的技术细节一个不少。核心关键词 Agent、LLM、RAG、GraphRAG、MCP 会自然贯穿全文，你读完至少能判断：手上这个需求到底该用 RAG 还是 GraphRAG，Agent 的容错该怎么设计，MCP 到底值不值得接。

先说结论性的判断：2026 年这个时间点，单纯"调个 LLM API 做问答"已经不算技术活了，真正的分水岭在于系统级工程能力——检索质量、Agent 的自主容错、工具协议标准化、以及知识表示方式的选择。下面我按这个逻辑一层层拆。

2. LLM 与 Agent：从"会说话"到"会做事"的那道坎

2.1 LLM 的本质局限，决定了 Agent 必须存在

很多人一开始会把 LLM 当成万能大脑，觉得只要模型够强，什么都能干。我早期也这么想，直到发现一个尴尬的事实：LLM 本质上是个无状态的函数——你给它一段输入，它吐一段输出，仅此而已。它不会主动去查数据库，不会记住上一轮对话之外的东西，更不会在发现自己答错时停下来重新想办法。

这就是 Agent 存在的根本理由。Agent 不是"更聪明的 LLM"，而是在 LLM 外面套了一层控制循环：让模型能调用工具、能观察结果、能根据反馈调整下一步动作。用生活化的类比，LLM 像是一个知识渊博但只能坐在椅子上说话的人，Agent 则是给这个人配了手、脚、眼睛和一张任务清单，让他能站起来去干活。

热搜词里有个"harness 和 agent 区别"，这个问题问得很到位。Harness（测试夹具/执行框架）通常指的是固定流程的编排——你预先定义好步骤 A 到 B 到 C，模型只在每个步骤里做局部决策。而 Agent 的核心特征是自主决定下一步做什么，路径不是写死的。两者的边界其实模糊，我的经验判断是：如果流程分支超过三层、且分支条件依赖运行时数据，那就该考虑 Agent 化；如果流程稳定可预测，用 harness 反而更可控、更好调试。

2.2 Agent 架构的几种主流形态与选型逻辑

实际项目里我见过、也用过的 Agent 架构大致分三类，选错了会直接导致项目复杂度爆炸。

第一类是ReAct 式单循环：模型思考（Reason）→ 行动（Act）→ 观察（Observe）→ 再思考，循环直到任务完成。结构简单，适合工具数量少（5 个以内）、任务链路短的场景。缺点是长任务容易"跑偏"，因为每一步都依赖上一步的输出，误差会累积。

第二类是Plan-and-Execute：先让模型生成一个完整计划，再逐步执行，执行中允许修订计划。适合步骤多、需要全局视野的任务，比如"帮我调研三个竞品并生成对比报告"。代价是前期规划消耗的 token 多，且计划质量高度依赖模型能力。

第三类是多 Agent 协作：把任务拆给不同角色的 Agent（比如一个负责检索、一个负责写作、一个负责审核），通过消息传递协作。这种架构听起来很美，但我实测下来，除非任务本身天然可并行且角色边界清晰，否则多 Agent 带来的通信开销和状态同步问题，往往超过它带来的收益。热搜里"agent 架构""agent 框架"这类词热度高，但别被"多 Agent"的叙事带偏，先从单 Agent 跑通再说。

选型时我会问自己三个问题：任务能不能一次规划清楚？工具调用会不会互相干扰？失败后能不能局部重试？这三个问题的答案基本能定位到该用哪种架构。

2.3 Agent 自主容错：可靠 AI 系统的工程命门

热搜里有一条"识的 llm 智能体自主容错控制：构建可靠 ai 系统的工程实践"，这个方向我认为是当前 Agent 落地最被低估的环节。Demo 阶段 Agent 看起来很惊艳，一上生产就各种翻车，核心原因就是没有容错设计。

我踩过最典型的一个坑：Agent 调用某个查询工具时，工具返回了空结果，模型没有意识到"空结果意味着查询失败"，而是基于空结果继续编造答案，最后输出了一段看起来合理但完全错误的内容。这就是所谓的"幻觉级联"——一步错，步步错。

我的容错设计通常包含四层：

• 输入校验层：工具调用前检查参数是否合法，比如日期格式、ID 是否存在，避免把垃圾参数喂给下游。
• 结果校验层：工具返回后判断结果是否"合理"，空结果、异常码、超长输出都要触发特殊处理，而不是直接塞回模型。
• 重试与降级层：失败时先重试（换参数或换工具），重试仍失败则降级到保守策略（比如明确告诉用户"我没查到"而不是硬编）。
• 循环熔断层：设置最大步数上限，防止 Agent 陷入"调用-失败-再调用"的死循环，这个上限我一般设 10 到 15 步，超过就强制中断并返回当前最佳结果。

提示：容错逻辑不要全交给模型判断，能用代码写死的规则就用代码写死。模型判断"结果是否合理"这件事本身就不稳定，把确定性逻辑交给程序，把模糊判断留给模型，这是分工的基本原则。

3. RAG 的瓶颈与 GraphRAG 的破局思路

3.1 传统 RAG 到底卡在哪里

RAG（检索增强生成）这个词现在几乎成了 AI 应用的标配，但热搜里"rag 瓶颈"这个词说明大家已经开始撞墙了。我做了几个 RAG 项目后，总结出传统 RAG 的三个核心瓶颈。

第一个是切块（chunking）的两难。切得太碎，单块信息不完整，检索出来答非所问；切得太大，噪声多，模型抓不住重点。我试过固定长度切、按段落切、按语义切，没有一种能通吃所有文档类型。技术手册适合按章节切，聊天记录适合按对话轮次切，法律条文适合按条款切——切块策略必须跟着数据形态走，没有银弹。

第二个是检索的语义漂移。向量检索本质是找"语义相似"的片段，但"相似"不等于"相关"。用户问"这个功能怎么退款"，检索可能召回一堆讲"退款政策"的段落，但真正需要的是"退款操作步骤"。语义相似度高的内容，未必是回答问题所需的内容。

第三个是多跳推理的缺失。很多问题需要串联多个信息片段才能回答，比如"我们公司去年 Q3 的营收比前年同期增长了多少"，这需要先找到两年的数据，再做计算。传统 RAG 一次性检索 top-k 片段，很难覆盖这种跨片段的推理链。

3.2 GraphRAG 用图结构补上关系推理的短板

GraphRAG 的思路很直接：既然文本片段之间的关系用向量表达不清楚，那就显式地把实体和关系抽出来，建成知识图谱，检索时沿着图结构走。热搜里"graphrag""kg 知识库、rag 知识库和结构知识库区分"这些词，说的就是这件事。

我拿一个实际场景对比过。假设知识库是一堆项目文档，用户问"负责支付模块的工程师还参与过哪些项目"。传统 RAG 检索"支付模块"相关片段，可能召回一堆技术文档，但很难回答"这个人还做过什么"。GraphRAG 则会把"工程师-参与-项目"这种关系抽成图上的边，查询时从"支付模块"节点出发，找到关联的人，再找这个人关联的其他项目，路径清晰。

但 GraphRAG 不是免费的午餐，它的代价很实在：

我的判断标准是：如果用户的问题大量涉及"谁和谁的关系""A 影响了 B 的什么"，那 GraphRAG 值得投入；如果主要是"某概念是什么""某操作怎么做"，传统 RAG 加好的切块策略就够了。别为了追新概念硬上 GraphRAG，建图和维护的成本会教你做人。

3.3 知识库选型：RAG 知识库、KG 知识库、结构知识库怎么分

热搜里"kg 知识库、rag 知识库和结构知识库区分以及应用场景"这个问题，我用一张表说清楚，这也是我在选型时实际用的判断框架。

• RAG 知识库：底层是向量库，存的是文本片段的向量。适合非结构化内容，比如文档、FAQ、聊天记录。优点是搭建快、维护简单，缺点是关系推理弱。
• KG 知识库（知识图谱）：底层是图数据库，存的是实体和关系。适合关系密集的领域，比如组织架构、供应链、医疗诊断。优点是推理强，缺点是构建和维护成本高。
• 结构知识库：底层是关系型数据库或表格，存的是结构化字段。适合数值查询、统计报表，比如"上季度销售额"。优点是精确，缺点是无法处理模糊语义。

实际项目里这三者经常混用。我的常见组合是：结构化数据走 SQL 查询，非结构化文档走 RAG，关键实体关系再抽一层轻量图谱做补充。热搜里"ontology rag"也是这个思路的延伸——用本体（ontology）来约束和增强检索，让检索结果更符合领域逻辑。

注意：RAG 知识库能不能存图片？能，但通常不是直接存图片本身，而是存图片的向量表示（用多模态模型编码）或图片的文字描述。检索时匹配到相关图片，再返回图片链接。纯图片检索的效果目前还远不如文本检索稳定，别抱太高期待。

4. MCP：工具调用的标准化尝试

4.1 MCP 是什么，为什么突然火了

MCP（Model Context Protocol）这个词在热搜里出现频率极高，还带着一堆具体场景："unreal 5.8 mcp""altium designer ai 接口 mcp""ida mcp 下载""x32dbg 的 mcp 插件"。这说明 MCP 已经从概念走向了具体工具的接入。

简单说，MCP 是一套让 LLM 应用和外部工具/数据源通信的协议标准。在 MCP 之前，每个 AI 应用要接一个工具，都得自己写适配代码——接数据库写一套，接文件系统写一套，接某个软件写一套，重复劳动且互不兼容。MCP 想做的就是统一这层接口，让工具提供方按协议暴露能力，AI 应用按协议调用，双方解耦。

用类比讲：MCP 之于 AI 工具，有点像 USB 之于外设。以前每个设备一个专用接口，现在统一成 USB，插上就能用。热搜里"mcp 是什么"这个问题，答案就是这个——它是 AI 与工具之间的通用插头标准。

4.2 MCP 的实际接入流程与踩坑点

我实际接过几个 MCP 服务，流程大致是：找到目标工具的 MCP Server（可能是官方提供，也可能是社区实现）→ 在 AI 客户端里配置 Server 地址和启动方式 → 客户端启动时连接 Server，拉取可用工具列表 → 模型根据任务选择工具调用。

听起来简单，但坑不少。热搜里"codex 无法找到 mcp""codex 接入 figma mcp 怎么授权""使用 mcp 工具流式输出内容到文件 cherrystudio"这些，全是真实踩坑现场。我总结几个高频问题：

• 连接失败：多数是 Server 没启动、端口占用、或路径配置错误。排查时先手动跑一遍 Server 启动命令，看能不能独立起来。
• 授权问题：涉及第三方服务（如设计工具、代码平台）的 MCP，通常需要 OAuth 或 API Key 授权。授权流程走不通时，检查回调地址和权限范围是否配置正确。
• 工具列表为空：Server 连上了但拉不到工具，一般是协议版本不匹配或 Server 实现有 bug，换个版本或换实现试试。
• 流式输出异常：往文件写流式内容时，注意缓冲和编码问题，中文内容尤其容易乱码，统一用 UTF-8。

提示：MCP 生态目前还在快速演进，不同客户端的兼容性参差不齐。生产环境接入前，务必在测试环境把"连接-授权-调用-异常"全链路跑一遍，别等上线才发现某个环节不通。

4.3 MCP 与 Agent 的关系：别混淆层次

有个常见误解是把 MCP 和 Agent 当成同一层的东西。实际上它们解决的是不同问题：Agent 决定"做什么"，MCP 解决"怎么连工具"。一个 Agent 可以完全不使用 MCP，自己写工具调用逻辑；一个 MCP 服务也可以被非 Agent 的普通 LLM 应用调用。

我的实践建议是：如果工具数量少且固定，自己写调用逻辑更直接；如果工具多、需要频繁增删、或者希望复用社区现成的工具实现，那 MCP 的价值就体现出来了。热搜里"agent skill 教程""agent 项目""ai agent 搭建"这些，很多最终都会落到"工具怎么接"这个问题上，MCP 是目前比较省心的答案之一。

5. 实操：从零搭一个带容错的 RAG Agent

5.1 整体架构与组件选型

讲了这么多概念，落到实操。我以一个"企业文档问答 Agent"为例，把完整链路走一遍。这个 Agent 要能：接收用户问题、检索知识库、必要时调用工具、生成带引用的回答、失败时优雅降级。

组件选型上，我的原则是优先选成熟稳定、社区活跃的方案，别在基础设施上造轮子：

• LLM：选一个支持工具调用（function calling）的模型，这是 Agent 的基础能力。本地部署还是 API 调用看数据敏感度，敏感数据必须本地。
• 向量库：中小规模用轻量方案即可，规模上来了再考虑分布式向量库。
• Embedding 模型：中文场景务必选中文优化过的，直接用英文模型效果会打折扣。
• 编排框架：可以用现成框架，也可以自己写控制循环。我倾向自己写，因为容错逻辑需要深度定制，框架的抽象反而碍事。

5.2 检索链路的关键参数与调优

检索质量直接决定回答质量，这块我花的时间最多。几个关键参数：

Top-K 的选择。K 太小召回不全，K 太大噪声多。我的经验值是先用 5 到 10 试，然后看召回内容的相关性调整。如果发现正确答案经常排在第 8、第 9 位，说明 K 要加大或者检索策略要改。

相似度阈值。设一个最低相似度门槛，低于阈值的片段直接丢弃，避免把不相关内容喂给模型。阈值多少合适？没有固定值，我一般从 0.7 开始试（具体取决于 embedding 模型的分布），观察召回质量再调。

重排序（Rerank）。向量检索召回 top-20，再用一个重排序模型精排出 top-5，这个两步走策略实测能明显提升相关性。重排序模型比 embedding 模型慢，但只处理少量候选，总体开销可接受。

混合检索。纯向量检索对关键词匹配不敏感，比如用户搜一个专有名词，向量检索可能召回一堆语义相近但不含该词的片段。加一路关键词检索（如 BM25），两路结果融合，能补上这个短板。

5.3 容错与降级的具体实现

前面讲了容错四层，这里给具体的实现思路。

输入校验层，我会写一个参数校验函数，对每个工具调用的参数做类型和范围检查。比如日期参数必须能解析成合法日期，ID 参数必须符合格式规范。校验不通过直接返回错误给模型，让它重新生成参数。

结果校验层，对工具返回做"合理性判断"。空结果、错误码、超长文本（可能是把整个数据库 dump 出来了）都要拦截。拦截后不是简单报错，而是给模型一个明确的信号："这次调用没拿到有效结果，你可以换个方式试试"。

重试与降级层，设置重试次数上限（我一般设 2 次），重试时改变策略——换关键词、换工具、或缩小查询范围。两次都失败就降级，明确告诉用户"这个问题我暂时查不到准确答案"，而不是硬编一个。

循环熔断层，用一个步数计数器，每轮循环加一，超过上限（10 到 15 步）强制中断。中断时返回当前已获得的最佳结果，并说明"任务未完全完成"。

# 简化的 Agent 控制循环骨架，突出容错逻辑 MAX_STEPS = 12 RETRY_LIMIT = 2 def run_agent(query): steps = 0 context = [] while steps < MAX_STEPS: steps += 1 action = llm_decide_next(query, context) if action.type == "final_answer": return action.content # 输入校验 if not validate_params(action.tool, action.params): context.append({"error": "参数非法，请重新生成"}) continue # 执行工具，带重试 result = None for attempt in range(RETRY_LIMIT): result = call_tool(action.tool, action.params) if is_valid_result(result): break action.params = adjust_params(action.params, attempt) # 结果校验与降级 if not is_valid_result(result): context.append({"error": "工具未返回有效结果，请换策略"}) else: context.append({"tool": action.tool, "result": result}) # 熔断，返回当前最佳 return build_best_effort_answer(query, context)

这段代码是骨架，实际实现要复杂得多，但核心思想就一句：把确定性的校验和熔断用代码写死，把模糊的决策留给模型。

5.4 效果评估与迭代

Agent 上线不是终点，评估才是。我通常从三个维度看：

• 任务完成率：用户问题被正确回答的比例。这个要人工标注一批测试集来测。
• 平均步数：完成任务平均用了几步。步数突然变多，说明某环节出问题了。
• 失败类型分布：失败是检索没召回、工具调用错、还是模型推理错？分类统计才能定位优化点。

热搜里"llm as judge"是个常用的自动评估手段——用另一个 LLM 来给回答打分。但我要提醒：LLM 评委本身也有偏见，只能作为辅助，关键场景必须人工抽检。我见过 LLM 评委给明显错误的回答打高分的案例，完全依赖它会翻车。

6. 常见问题与排查速查

6.1 Agent 相关高频问题

6.2 RAG 相关高频问题

检索召回不准，先看切块策略是否匹配数据形态，再看 embedding 模型是否适合语种，最后看是否需要加重排序。这三步排查下来，八成问题能定位。

回答出现幻觉，检查 prompt 是否明确要求"只基于检索内容回答"，以及检索内容是否真的包含答案。如果检索内容里没有答案，模型硬编是必然的，这时候应该让模型明确说"未找到相关信息"。

知识库更新后检索不到新内容，检查索引是否重建或增量更新。很多向量库的增量更新有延迟，或者需要手动触发。

6.3 MCP 相关高频问题

连接类问题，先确认 Server 能独立启动，再确认客户端配置的地址和启动命令正确。授权类问题，检查 API Key 是否过期、权限范围是否覆盖所需操作。工具调用类问题，检查工具描述是否清晰、参数 schema 是否和实际匹配。

提示：MCP 的调试建议开日志，把请求和响应都打出来。很多问题看日志一眼就清楚了，比盲猜快得多。

7. 一些不那么技术但很重要的经验

做 AI 应用这几年，我最大的体会是：技术选型的重要性，往往低于对业务场景的理解。见过太多团队一上来就追求最前沿的架构，GraphRAG、多 Agent、MCP 全套上齐，结果连最基本的"用户到底要问什么"都没搞清楚，最后系统复杂到没人能维护。

我的建议是反过来的：先用最简单的方式跑通核心场景，哪怕就是"向量检索 + 单次 LLM 调用"，验证了价值再逐步加复杂度。Agent 的容错、GraphRAG 的图结构、MCP 的工具生态，这些都是"锦上添花"的能力，前提是"锦"本身得成立。

另一个体会是关于评估。AI 系统的效果很难用传统软件的测试方法衡量，因为输出是概率性的。我现在的做法是建一个持续维护的评估集，每次改动都跑一遍，看指标有没有退化。这个评估集不用很大，几十到几百条高质量样本就够，但必须覆盖真实场景的典型问题。没有评估集的 AI 项目，迭代基本靠感觉，迟早出问题。

最后说个具体的：热搜里"llm request failed: provider rejected the request schema or tool payload"这类报错，我遇到太多次了。多数是工具调用的参数 schema 和模型生成的格式对不上，或者请求体超了大小限制。排查时先把完整请求打出来，对着 schema 逐字段核对，基本都能找到问题。别一看到报错就怀疑模型，很多时候是工程细节没对齐。

这套东西我还在持续迭代，Agent 的容错策略、RAG 的检索链路、MCP 的工具接入，每一块都有大量可以深挖的细节。后面有机会再单独拆开讲，比如怎么设计一个真正好用的重排序策略，或者多 Agent 协作在什么场景下才真的划算。