企业官网建设流程全解析

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

拿到“Agent / LLM 技术精选日报”这个标题的时候，我第一反应不是“又一份资讯汇总”，而是它背后折射出的一个现实：Agent 和 LLM 这条线上，信息密度已经高到单靠零散刷帖根本追不上了。热搜词里同时出现了 Agent、LLM、RAG、MCP、GraphRAG 这几个词，本身就说明了一件事——这个领域已经从“单点模型能力”进入了“系统工程能力”的阶段。模型只是发动机，真正让车跑起来的是围绕它搭建的整套传动、散热和控制系统。

这份日报类内容的核心价值，不在于告诉你“今天又出了个新模型”，而在于帮你把散落在各处的技术碎片串成一条可理解的脉络。它适合谁看？我的判断是三类人：第一类是正在做 Agent 应用落地的工程师，需要快速判断哪些新工具值得接入；第二类是做 RAG 知识库的产品和技术负责人，需要知道检索增强这条线又冒出了什么新玩法；第三类是刚入门、被 MCP、GraphRAG 这些缩写砸得有点懵的开发者，需要一份能看懂的技术地图。

我自己在过去一年里陆续做过几个 Agent 相关的项目，从最简单的工具调用到带记忆的多轮任务编排都踩过。最大的体会是：这个领域最贵的成本不是算力，而是“选型试错”的时间。一份好的技术日报，本质上是在帮你压缩试错成本。下面我就围绕这份日报涉及的核心技术点，把 Agent、LLM、RAG、MCP、GraphRAG 这几条线拆开讲透，顺带把热搜词里那些具体问题——比如 RAG 知识库能不能存图片、MCP 到底是什么、GraphRAG 和普通 RAG 差在哪——都落到实操层面说清楚。

2. 核心概念拆解：Agent、LLM、RAG、MCP、GraphRAG 到底是什么关系

2.1 用一条流水线理解这五个词的分工

很多人一开始会被这几个缩写绕晕，其实它们不是并列关系，而是有层次的。我习惯用一条“智能流水线”来类比：

• LLM是流水线上的“大脑”，负责理解和生成语言。它本身不会主动做事，你问它答，仅此而已。
• Agent是给这个大脑装上了“手脚和记忆”。它能自己决定调用什么工具、分几步完成任务、失败了怎么重试。热搜里“agent是什么”“agent架构”“agent框架”这些词，问的都是这层。
• RAG是给大脑配了一个“外部资料库”。模型训练时没见过的私有数据，通过检索的方式临时喂给它，解决“幻觉”和“知识过期”问题。
• MCP是给大脑和外部工具之间定了一套“标准插头”。以前每接一个工具就要写一套适配代码，MCP 想做的就是统一接口。
• GraphRAG是 RAG 的进阶版，把“资料库”从一堆散文档升级成一张有关系网的知识图谱，解决普通 RAG “只见树木不见森林”的问题。

这么一摆，关系就清楚了：LLM 是底座，Agent 是应用形态，RAG 和 GraphRAG 是知识供给方式，MCP 是工具连接协议。一份技术日报之所以要把它们放在一起，是因为真实项目里这几样东西往往是同时出现的。

2.2 为什么现在必须关注 MCP 和 GraphRAG

热搜词里 MCP 出现的频率非常高，甚至出现了“unreal 5.8 mcp”“altium designer ai接口 mcp”“ida mcp下载”“x32dbg 的mcp插件”这种非常具体的组合。这说明 MCP 已经不只是聊天机器人的事了，它正在往专业软件领域渗透。游戏引擎、电路设计软件、逆向调试工具都在接 MCP，背后的逻辑是：这些专业工具本身功能强大但操作复杂，如果能让 Agent 通过 MCP 去调用它们，就相当于给这些工具装了一个“自然语言遥控器”。

GraphRAG 则是另一个方向的信号。普通 RAG 用久了都会遇到一个瓶颈：当你问一个需要“跨多个文档综合推理”的问题时，向量检索只能召回相似片段，拼不出完整答案。比如问“A 项目和 B 项目之间有哪些人员重叠”，普通 RAG 很难答好，因为它不理解实体之间的关系。GraphRAG 通过预先构建实体关系图，把这类问题变成图上的路径查询，效果提升明显。热搜里“rag瓶颈”“kg知识库、rag知识库和结构知识库区分”这些词，问的正是这个痛点。

3. RAG 知识库实操：从能存什么到怎么存好

3.1 RAG 知识库到底能不能存图片

这是热搜里一个非常具体的问题：“rag知识库能存储图片嘛”。答案是能，但要看你怎么定义“存”和“用”。这里必须把三种情况分清楚，否则很容易踩坑。

第一种是只存图片文件本身。你把图片当普通文件塞进知识库，检索时只能靠文件名或人工打的标签。这种方式基本等于网盘，RAG 的价值没体现出来。

第二种是图片加文字描述一起存。用多模态模型给每张图片生成一段文字描述，把描述文本做向量化，图片原文件作为附件关联。检索时命中描述文本，再把图片返回给用户。这是目前最实用的做法，成本可控，效果也够用。

第三种是图片直接向量化。用 CLIP 这类多模态嵌入模型，把图片和文本映射到同一个向量空间，实现“以文搜图”和“以图搜图”。这种方式效果最好，但对存储和算力要求高，而且中文场景下的多模态嵌入模型选择还比较有限。

我自己的经验是：绝大多数业务场景用第二种就够了。给图片配描述这一步，可以用多模态 LLM 批量生成，提示词里明确要求“描述图片中的主体、场景、关键文字和可能的用途”，生成质量比想象中好。唯一要注意的是，描述文本要控制长度，太长会稀释向量语义，一般 100 到 200 字比较合适。

3.2 普通 RAG 的三个典型瓶颈

热搜里“rag瓶颈”这个词很值得展开。我踩过的坑主要集中在三个地方：

瓶颈一：切分粒度两难。切得太碎，单块信息不完整，检索出来答非所问；切得太粗，一块里混了多个主题，向量被平均掉，检索精度下降。我的做法是先用语义切分，再对超长块做二次拆分，同时给每块加上“所属章节标题”作为上下文前缀，这样即使块被切碎，语义也不会丢太多。

瓶颈二：检索召回不准。纯向量检索对“关键词精确匹配”不友好，比如查一个产品型号，向量可能召回一堆语义相近但型号不同的内容。解决办法是混合检索：向量检索加 BM25 关键词检索，两路结果用 RRF 融合排序。实测下来，混合检索比纯向量在专业领域文档上的召回准确率能提升不少。

瓶颈三：多跳问题答不了。这就是 GraphRAG 要解决的问题。普通 RAG 是“一次检索一次生成”，遇到需要串联多个信息点的问题就歇菜。GraphRAG 通过实体关系图，支持“先找到实体，再沿关系扩展，最后综合生成”的多跳流程。

3.3 一个可复现的 RAG 知识库搭建流程

下面这套流程是我在多个项目里验证过的，适合中小规模知识库（几千到几万文档）。

第一步，文档预处理。把 PDF、Word、Markdown 统一转成纯文本，保留标题层级信息。这一步用现成的解析库就行，关键是别丢结构。

第二步，语义切分。按标题层级切，一级标题下的内容如果超过 800 字，再按段落切。每块前面拼上“文档标题 > 一级标题 > 二级标题”作为上下文。

第三步，向量化入库。嵌入模型选中文效果好的，维度不用追求最高，768 或 1024 维通常够用。入库时同时存原文、向量和元数据（来源、标题路径、时间）。

第四步，混合检索。查询时同时跑向量检索和关键词检索，各取前 20 条，用 RRF 融合后取前 5 条。

第五步，重排序。用一个轻量重排模型对前 5 条重新打分，把最相关的放前面。这一步对最终答案质量影响很大，别省。

第六步，生成。把重排后的内容拼进提示词，明确要求“只根据给定资料回答，资料中没有的信息不要编造”。

提示：重排序模型和嵌入模型最好用同一家或同一系列的，语义空间更一致，效果更稳。

4. MCP 协议深入：它解决了什么问题，怎么用

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

MCP 全称是 Model Context Protocol，翻译过来叫“模型上下文协议”。热搜里“mcp是什么”“mcp协议”问的就是它。用一句话说：它是一套让 LLM 应用和外部工具、数据源之间标准化通信的协议。

在 MCP 出现之前，每接一个工具都要写适配代码。你想让 Agent 读数据库，写一套；想让它调某个 API，再写一套；换个模型框架，这些适配可能还要重写。MCP 的思路是把“工具提供方”和“工具使用方”解耦：工具方按 MCP 标准暴露自己的能力，使用方按 MCP 标准去调用，中间不用关心对方是谁。

这就像以前每个电器都有自己的充电口，现在统一成 Type-C。热搜里“unreal 5.8 mcp”“altium designer ai接口 mcp”“ida mcp下载”这些词，说的就是这些专业软件开始提供 MCP 接口，让 Agent 能直接操作它们。

4.2 MCP 的核心概念：Server、Client 和 Tool

MCP 的架构不复杂，三个角色：

• MCP Server：工具提供方。它把自身能力包装成一个个“Tool”，每个 Tool 有名字、描述和参数定义。
• MCP Client：工具使用方，通常就是你的 Agent 框架。它连接 Server，获取 Tool 列表，按需调用。
• Tool：具体的能力单元。比如“查询数据库”“发送邮件”“读取文件”都是一个 Tool。

调用流程是这样的：Client 启动时连接 Server，拉取 Tool 列表；LLM 根据用户需求决定调用哪个 Tool，生成参数；Client 把调用请求发给 Server；Server 执行后返回结果；结果再喂回 LLM 继续推理。

这个流程的关键在于：Tool 的描述质量直接决定 LLM 会不会正确调用。描述要写清楚“这个工具做什么、什么时候用、参数什么含义”，写得含糊，LLM 就会乱调或漏调。

4.3 自己写一个 MCP Server 的实操要点

假设你要把一个内部查询接口包装成 MCP Server，步骤大致如下：

首先定义 Tool。给每个能力写清楚名称、描述和参数 schema。参数 schema 用 JSON Schema 描述，类型、是否必填、取值范围都写明白。

然后实现执行逻辑。收到调用请求后，解析参数，执行实际查询，把结果整理成结构化文本返回。返回内容要简洁，别把整个数据库 dump 回去，LLM 的上下文窗口很贵。

接着处理错误。工具执行失败时，返回明确的错误信息而不是抛异常，让 LLM 知道“这次调用失败了，原因是 X”，它才能决定重试还是换方案。

最后做连接管理。MCP 支持多种传输方式，本地工具用标准输入输出，远程工具用 HTTP。选哪种取决于你的部署形态。

注意：MCP Server 的 Tool 数量别一次暴露太多。我试过暴露 30 多个 Tool，结果 LLM 选择困难，调用准确率明显下降。按场景分组，一次只给相关的 5 到 10 个，效果更好。

4.4 MCP 与 Agent 框架的配合

热搜里“agent框架”“agent架构”“harness和agent区别”这些词，其实都在问同一个问题：Agent 框架和 MCP 怎么配合。我的理解是，Agent 框架负责“决策和编排”，MCP 负责“能力接入”。框架决定下一步做什么，MCP 提供做这件事的工具。

“harness 和 agent 区别”这个问题也值得说一句。Harness 通常指“测试和评估 Agent 的脚手架”，它不参与实际任务执行，而是用来跑评测、对比不同 Agent 表现。Agent 是干活的，Harness 是考核的，两者别混。

5. GraphRAG 与知识图谱：什么时候该上，什么时候别硬上

5.1 GraphRAG 和普通 RAG 的本质区别

普通 RAG 的检索单元是“文本块”，GraphRAG 的检索单元是“实体和关系”。这个区别带来两个直接后果：

第一，GraphRAG 能回答“关系型问题”。比如“哪些人和哪些项目有关联”“A 事件导致了哪些后续事件”，这类问题在图上就是一次路径查询，在普通 RAG 里却很难拼出答案。

第二，GraphRAG 能做“全局摘要”。普通 RAG 只能召回局部片段，问“这批文档整体讲了什么主题”，它答不好。GraphRAG 可以在图层面做社区发现，把相关实体聚成簇，再对每个簇生成摘要，最后汇总。

但 GraphRAG 的代价也很明显：构建图谱需要额外的实体抽取和关系抽取步骤，成本比普通 RAG 高不少，而且抽取质量直接决定最终效果。热搜里“ontology rag”这个词，说的就是用本体（Ontology）来约束实体和关系类型，提升抽取质量。

5.2 知识图谱、RAG 知识库和结构化知识库的区别

热搜里“kg知识库、rag知识库和结构知识库区分以及应用场景”这个问题很典型，我用一张表说清楚：

实际项目里这三者经常混用。比如一个企业知识助手，底层用结构化库查数据，中间用 RAG 查文档，上层用图谱做关系推理，Agent 负责根据问题类型选择走哪条路。

5.3 GraphRAG 的落地步骤与成本控制

如果你决定上 GraphRAG，我建议按这个顺序来：

先做小范围验证。选一个文档子集，跑一遍实体和关系抽取，人工检查抽取质量。如果抽取准确率不到 80%，先别急着全量构建，调提示词或换模型。

再定本体。明确你要抽哪些实体类型、哪些关系类型。本体定得越清晰，抽取越稳定。别一上来就追求大而全，先覆盖核心的几类。

然后构建图谱。用 LLM 批量抽取，抽取结果存进图数据库。这一步可以并行，但要注意去重和实体对齐，同一个实体不同叫法要合并。

最后接检索。查询时先做实体识别，定位到图中节点，再沿关系扩展，把子图转成文本喂给 LLM 生成答案。

成本控制的关键在于：别对所有文档都建图。只对关系密集、查询频繁的那部分文档建图，其余走普通 RAG。我见过有团队一上来就全量建图，结果成本爆炸，效果还没普通 RAG 好。

6. Agent 工程化：并发、容错与安全

6.1 Agent 怎么扛并发

热搜里“ai agent 怎么扛并发”是个非常实际的问题。Agent 和普通 API 不一样，它一次任务可能包含多轮 LLM 调用和多次工具调用，单次请求耗时可能是普通接口的几十倍。扛并发的核心思路是“异步加队列加限流”。

具体做法：把 Agent 任务提交到消息队列，由 worker 异步消费。worker 数量根据 LLM 接口的并发上限来定，别超过上游限制。每个任务内部的多步调用用异步方式串起来，避免阻塞。对外接口只返回任务 ID，客户端轮询或走回调拿结果。

限流要分两层：一层是 LLM 接口的调用限流，防止把上游打挂；一层是工具调用的限流，防止某个外部服务被压垮。两层都要有退避重试机制。

6.2 Agent 的容错设计

“识的llm智能体自主容错控制”这个热搜词说的就是 Agent 容错。Agent 出错的地方太多了：LLM 输出格式不对、工具调用失败、参数解析错误、陷入死循环。容错设计要覆盖这几类。

格式错误用结构化输出约束，让 LLM 按 JSON Schema 输出，解析失败就重试并附上错误信息。工具失败要区分“可重试”和“不可重试”，网络超时可重试，参数错误重试也没用，要让 LLM 换方案。死循环要设最大步数，超过就强制终止并返回当前进展。

我自己的经验是：给 Agent 加一个“反思”步骤很值。每完成几步，让它自己检查一下“当前进展是否符合目标、有没有走偏”，能显著减少跑飞的情况。

6.3 Agent 安全：从 AgentPoison 说起

热搜里“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”和“agent安全”指向一个严肃问题：Agent 的记忆和知识库是可以被投毒的。攻击者在知识库里埋入恶意内容，Agent 检索到之后可能被诱导执行危险操作。

防御思路有几条：知识库写入要做来源审核和内容过滤；Agent 执行敏感操作前要二次确认；记忆内容要定期审计，发现异常及时清理。这些措施不能保证百分百安全，但能大幅提高攻击成本。

7. 常见问题速查与避坑清单

7.1 高频问题速查表

7.2 几条踩坑换来的经验

第一条，别迷信框架。Agent 框架更新极快，今天的最佳实践明天可能就过时。核心是把“决策、工具、记忆、容错”这几个模块的职责想清楚，框架只是实现手段，换框架时思路不变。

第二条，评测要趁早。很多人做完 Agent 才想起来评测，结果发现效果不行又不知道问题出在哪。正确做法是搭好骨架就先跑一批测试用例，把“LLM as judge”用起来，边做边评。

第三条，上下文要省着用。LLM 的上下文窗口再大也是有限的，工具返回结果、历史对话、检索内容都在抢空间。该截断的截断，该摘要的摘要，别什么都往里塞。

第四条，日志要打全。Agent 出问题时，你需要知道每一步的输入输出是什么。把 LLM 调用、工具调用、决策结果都记下来，排查问题时能省大量时间。

7.3 关于“LLM request failed: provider rejected the request schema or tool payload”的排查

这个报错在热搜里出现，说明不少人遇到过。它通常是工具调用的参数 schema 和实际传参不匹配导致的。排查顺序：先看报错里提到的字段名，对照 Tool 定义的 schema 检查类型和必填项；再看是不是 LLM 生成了多余字段，有些模型会自作主张加字段，schema 里加additionalProperties: false能拦住；最后看嵌套结构，深层嵌套的参数最容易出错，能扁平化就扁平化。

8. 工具链与生态观察

8.1 本地模型与开发工具

热搜里“llm studio”“llm wiki”“llm框架”这些词，反映的是本地开发和知识管理的需求。LM Studio 这类工具让本地跑模型变得简单，适合做原型验证和隐私敏感场景。但要注意，本地小模型在工具调用和结构化输出上的稳定性通常不如云端大模型，选型时要按场景权衡。

8.2 从聊天记录精调模型这件事

“使用聊天记录模型精调llm”这个热搜词值得单独说。用聊天记录做精调数据，好处是数据真实、贴近业务；坑在于聊天记录噪声大、格式乱、隐私敏感。我的建议是：先做严格清洗和脱敏，再人工筛选高质量对话，最后才拿去精调。直接拿原始聊天记录喂进去，效果往往适得其反。

8.3 流式输出到文件这类小需求

“使用mcp工具流式输出内容到文件 cherrystudio”这个热搜词很具体，说明大家在用 MCP 做实际的文件操作。流式输出的价值在于：长内容生成时不用等全部完成，边生成边写文件，用户体验好，也避免内存里堆一大坨。实现上就是在 MCP Tool 里用流式接口，每收到一段就追加写入，同时处理好文件锁和异常中断。

9. 我个人的一点体会

做 Agent 和 LLM 这条线，最大的感受是“变化快但底层稳”。变化快的是工具和框架，几乎每个月都有新东西；底层稳的是那几个核心问题——怎么让模型理解任务、怎么给它接上外部能力、怎么保证它不出错。把底层问题想清楚，上层工具换得再快也不慌。

另外就是，别被热搜词带着跑。热搜反映的是关注度，不一定是你的项目该优先做的事。看到一个新概念，先问自己“它解决的是我当前遇到的哪个具体问题”，如果答不上来，就先放一放。真正值得投入的，永远是那些能直接改善你项目效果的技术点。