企业官网建设流程全解析

1. 从一份日报标题说起：Agent 与 LLM 生态到底在卷什么

看到"Agent / LLM 技术精选日报"这个标题，很多人的第一反应是"又是一个信息聚合"。但如果你真的在一线做 Agent 和 LLM 相关的东西，就会明白这类日报的价值不在于"聚合"，而在于它暴露了整个生态当前最活跃的神经末梢。2026 年这个时间节点上，Agent 和 LLM 领域已经从"能不能跑通"进入到了"怎么跑得稳、跑得省、跑得安全"的阶段。热搜词里同时出现了 RAG、GraphRAG、MCP、Agent 框架、Agent 安全、并发扛压这些词，本身就说明问题——大家不再满足于 demo，而是在解决工程化落地中的硬骨头。

这份日报涉及的内容面很广：从 RAG 知识库能不能存图片这种具体问题，到 GraphRAG 和 ontology rag 这种知识组织方式的演进；从 MCP 协议到底是软件协议还是硬件协议这种概念澄清，到 AI Agent 怎么扛并发这种架构级挑战；从 langchain4j easy rag 这种框架选型，到 agentpoison 这种针对 Agent 记忆投毒的红队研究。这些词放在一起，勾勒出的是一幅完整的图景：LLM 是大脑，RAG 是记忆，MCP 是手脚，Agent 是执行体，而安全、并发、评测则是让这套系统真正能上生产环境的保障。

这篇文章适合谁看？如果你正在做 Agent 开发、RAG 知识库搭建、LLM 应用架构设计，或者只是对这个领域好奇想搞清楚这些热词到底在说什么，那这篇内容就是为你准备的。我会把这些热搜词背后的技术逻辑、实操要点、踩坑经验一条条拆开讲清楚，不堆砌概念，只讲能落地的东西。

2. RAG 与知识库：从"能检索"到"检索得对"

2.1 RAG 的本质与当前瓶颈

RAG（Retrieval-Augmented Generation，检索增强生成）这个词已经被说烂了，但真正理解它的人并不多。用生活化的类比：LLM 是一个博学但记性不太好的专家，你问它问题它能答，但它不知道你公司内部的文档、你个人的笔记、你昨天刚写的代码。RAG 就是给这个专家配了一个图书馆管理员，你提问的时候，管理员先去书架上找到相关的资料递给专家，专家再结合资料回答你。

这个流程听起来简单，但瓶颈恰恰出在"找到相关资料"这一步。热搜词里出现了"rag瓶颈"和"rag检索增强"，说明很多人已经踩到了坑。常见的瓶颈有这么几个：

• 切分粒度问题：文档切得太碎，检索出来的片段缺乏上下文；切得太大，检索精度下降，噪声增多。
• 语义鸿沟：用户提问用的词和文档里写的词不一致，纯向量检索可能召回不到。
• 多模态缺失：热搜里有人问"rag知识库能存储图片嘛"，答案是能，但需要额外的处理管线，不是默认就支持的。
• 检索结果排序：召回了 20 条，哪几条真正有用？没有好的 rerank 策略，LLM 会被噪声带偏。

我实测下来，一个 RAG 系统效果好不好，70% 取决于数据预处理和检索策略，只有 30% 取决于 LLM 本身。很多人一上来就换更大的模型，结果发现效果没提升多少，就是因为瓶颈根本不在生成端。

2.2 GraphRAG 与 Ontology RAG：知识组织方式的升级

普通 RAG 把知识当成一堆独立的文本块，检索时找最相似的块。但现实中的知识是有结构的——A 是 B 的上级，C 依赖 D，E 和 F 是同一类事物。GraphRAG 的核心思路就是把这些结构显式地建出来，用图的方式组织知识。

GraphRAG 的工作流程大致是这样的：先从文档中抽取实体和关系，构建知识图谱；然后对图谱做社区检测，把紧密相关的实体聚成簇；查询时既做向量检索，也做图遍历，把相关的实体、关系、社区摘要一起喂给 LLM。这样做的好处是能回答"全局性"的问题，比如"这份报告的主要主题是什么"，普通 RAG 很难做到，因为它只能召回局部片段。

Ontology RAG 则更进一步，它引入本体（Ontology）的概念。本体是对某个领域的概念、属性、关系的 formal 描述。比如在医疗领域，本体里会定义"疾病""症状""药物""治疗方案"这些概念以及它们之间的关系。Ontology RAG 在检索时会利用本体做推理，比如用户问"头疼吃什么药"，系统能通过本体知道"头疼"是一种"症状"，"症状"和"药物"之间通过"治疗"关系连接，从而找到正确的药物。

热搜里同时出现"graphrag"和"llm ontology"，说明这两个方向正在融合。我的经验是：如果你的知识库是结构化的、领域明确的（比如法律、医疗、金融），Ontology RAG 值得投入；如果知识比较杂、结构不明显，GraphRAG 的通用性更好。但两者都有代价——构建图谱和本体的成本远高于普通 RAG，而且维护起来更复杂。

2.3 多模态 RAG：图片到底能不能存

"rag知识库能存储图片嘛"这个问题，答案是能，但要看你怎么定义"存储"和"检索"。

最简单的做法是把图片转成文字描述（用多模态模型生成 caption），然后按文本处理。缺点是丢失了视觉细节。进阶做法是用 CLIP 这类模型把图片编码成向量，和文本向量放在同一个空间里做检索。这样用户用文字搜"一只橘猫在沙发上"，能召回对应的图片。再进一步，可以用多模态 LLM 直接处理图文混合的文档，比如 PDF 里的图表、扫描件里的手写内容。

实操中要注意：图片的向量维度和文本向量维度可能不一致，需要做对齐；图片检索的评估比文本更难，因为没有标准的 ground truth；存储成本也更高，一张高清图的向量可能比一段文本大几十倍。

2.4 零基础可复制的本地 RAG 方案

热搜里有一条"ollama + 简易本地 rag 知识库【零基础可复制教程】"，这个组合确实是最适合入门的。Ollama 负责跑本地 LLM，配合一个向量数据库（比如 Chroma 或 Qdrant），再加上一个嵌入模型，就能搭起最小可用的 RAG。

具体步骤我拆一下：

1. 安装 Ollama，拉取一个模型，比如ollama pull llama3或ollama pull qwen2。
2. 安装向量数据库，Chroma 最省事，pip install chromadb就行。
3. 准备嵌入模型，可以用 Ollama 自带的nomic-embed-text，也可以用 sentence-transformers。
4. 写一个脚本：读取文档 → 切分 → 生成嵌入 → 存入 Chroma。
5. 查询时：把问题转成嵌入 → 在 Chroma 里检索 top-k → 把检索结果和问题一起拼成 prompt → 发给 Ollama。

import chromadb import ollama client = chromadb.Client() collection = client.create_collection("my_docs") # 入库 docs = ["文档片段1", "文档片段2"] for i, doc in enumerate(docs): emb = ollama.embeddings(model="nomic-embed-text", prompt=doc)["embedding"] collection.add(ids=[str(i)], embeddings=[emb], documents=[doc]) # 查询 q = "你的问题" q_emb = ollama.embeddings(model="nomic-embed-text", prompt=q)["embedding"] results = collection.query(query_embeddings=[q_emb], n_results=3) context = "\n".join(results["documents"][0]) prompt = f"根据以下资料回答问题：\n{context}\n\n问题：{q}" print(ollama.chat(model="llama3", messages=[{"role": "user", "content": prompt}]))

这个方案跑起来大概半小时，适合验证想法。但要注意：本地模型的检索和生成质量都比不上云端大模型，别拿它做生产。

提示：切分文档时，建议按语义切分而不是固定字数。比如按段落、按标题层级切，保留上下文。固定 512 字符切分是最省事但效果最差的做法。

3. MCP 协议：Agent 的"USB 接口"到底怎么用

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

MCP（Model Context Protocol）是热搜里出现频率最高的词之一，甚至有人问"mcp 是软件协议还是硬件协议那个概念叫什么来着"。这里明确一下：MCP 是软件协议，不是硬件协议。它定义的是 LLM 应用和外部工具、数据源之间的通信标准。

用类比来说：在 MCP 出现之前，每个 LLM 应用要接一个工具（比如数据库、文件系统、API），都得自己写一套适配代码。这就像每个手机厂商都用不同的充电接口，用户得备一堆线。MCP 想做的是 USB-C——统一接口，任何支持 MCP 的工具都能被任何支持 MCP 的 LLM 应用调用。

MCP 的核心概念有三个：Server（提供工具和数据的一方）、Client（LLM 应用这一方）、Transport（通信方式，支持 stdio 和 HTTP）。Server 暴露 resources（资源，比如文件）、tools（可调用的函数）、prompts（预设提示模板）。Client 连接 Server 后，能列出这些能力，并在需要时调用。

3.2 MCP 的实操接入：以几个热搜场景为例

热搜里出现了"codex 接入 figma mcp 怎么授权"、"cheat engine 桥接 mcp教程"、"x32dbg 的 mcp插件"、"ruoyi-vue-pro合并mcp功能"这些具体场景。这些场景的共同点是：把一个原本独立的工具通过 MCP 暴露给 LLM 使用。

以 Figma MCP 为例，授权流程通常是这样的：Figma 的 MCP Server 需要访问你的 Figma 账号，所以会走 OAuth 流程。你在 Client 端配置好 Server 地址后，Client 会引导你打开浏览器完成授权，拿到 token 后存到本地配置里。之后 Client 就能通过 MCP 调用 Figma 的 API，读取设计稿、导出资源等。

Cheat Engine 和 x32dbg 的 MCP 桥接则更有意思——这两个是逆向工程工具，通过 MCP 把内存读写、断点设置等能力暴露给 LLM，理论上可以让 LLM 辅助分析程序行为。这类场景要注意安全边界，别让 LLM 执行危险操作。

ruoyi-vue-pro 合并 MCP 功能，则是把一个 Java 后端框架的能力通过 MCP 暴露出来，让 LLM 能直接操作数据库、调用业务接口。这种集成要特别注意权限控制，MCP Server 不应该暴露所有接口，而应该只暴露必要的、经过鉴权的工具。

3.3 MCP 的坑与注意事项

我踩过的坑有这么几个：

• Transport 选择：stdio 适合本地进程，HTTP 适合远程。但 HTTP 模式下要注意认证和加密，别裸奔。
• 工具描述质量：MCP Server 暴露的每个 tool 都要有清晰的 description 和参数 schema，否则 LLM 不知道怎么调。我见过有人把 tool 描述写成"执行操作"，LLM 完全懵。
• 错误处理：MCP 调用失败时，返回的错误信息要足够清晰，让 LLM 能理解并重试或换方案。
• 版本兼容：MCP 协议还在演进，不同版本的 Client 和 Server 可能不兼容，接入前先确认版本。

注意：MCP Server 暴露的工具越多，LLM 的选择难度越大。建议按场景拆分 Server，而不是把所有工具塞进一个。

4. Agent 架构与并发：从玩具到生产

4.1 Agent 是什么，和 Harness 有什么区别

热搜里有人问"harness和agent区别"，这个问题很关键。Agent 是一个能自主决策、调用工具、完成任务的系统。Harness 则是包裹在 Agent 外面的"测试框架"或"运行环境"，负责给 Agent 提供输入、收集输出、评估表现。

打个比方：Agent 是运动员，Harness 是训练场和裁判。Harness 不参与决策，但它决定了 Agent 在什么条件下运行、怎么衡量好坏。在 Agent 开发中，Harness 的重要性被严重低估——没有好的 Harness，你根本不知道你的 Agent 是变好了还是变坏了。

一个典型的 Agent 架构包含：规划模块（把任务拆成子任务）、记忆模块（短期和长期记忆）、工具调用模块（通过 MCP 或其他方式调用外部能力）、反思模块（评估自己的输出并改进）。热搜里的"agent架构"和"agent框架"就是在讨论这些模块怎么组织。

4.2 AI Agent 怎么扛并发

"ai agent 怎么扛并发"是生产环境必须面对的问题。Agent 的一次任务执行可能涉及多次 LLM 调用、多次工具调用，耗时从几秒到几分钟不等。如果每个请求都占一个线程，并发一上来就崩了。

我的经验是分几层来解决：

• 异步化：所有 LLM 调用和工具调用都用异步 IO，不要阻塞线程。Python 里用 asyncio，Java 里用 CompletableFuture 或 Reactor。
• 队列与限流：用消息队列（如 Redis、RabbitMQ）缓冲请求，控制同时执行的 Agent 数量。LLM API 通常有速率限制，超过就会被拒。
• 状态外置：Agent 的中间状态存到 Redis 或数据库，而不是内存里。这样服务重启不会丢状态，也方便水平扩展。
• 超时与重试：每个 LLM 调用和工具调用都要设超时，失败要有重试策略，但重试要幂等。
• 缓存：相同的查询结果可以缓存，尤其是 RAG 检索和工具调用结果。

热搜里还有一条"llm request failed: provider rejected the request schema or tool payload"，这是并发场景下的典型错误——请求格式不对被拒。排查时要检查 tool 的 schema 是否符合 provider 的要求，参数类型、必填项、枚举值都要对。

4.3 Agent 安全：AgentPoison 与记忆投毒

"agentpoison: red-teaming llm agents via poisoning memory or knowledge ba"这条热搜指向的是 Agent 安全领域的一个重要研究方向。AgentPoison 的核心思想是：Agent 依赖记忆和知识库做决策，如果攻击者能往记忆或知识库里注入恶意内容，就能操控 Agent 的行为。

攻击方式可能是：在 RAG 知识库里插入一段看似正常但实际包含恶意指令的文本；或者在 Agent 的长期记忆里注入虚假信息，让 Agent 在后续任务中做出错误决策。防御手段包括：对知识库内容做来源验证和完整性校验；对 Agent 的记忆做定期审计；在 Agent 执行敏感操作前增加人工确认环节。

热搜里的"agent安全"和"agentpoison"放在一起，说明这个方向正在从学术研究走向工程实践。做 Agent 产品的团队，安全不能等到出事再补。

5. LLM 基础与评测：Token、Judge 与榜单

5.1 LLM 的 Token 机制：Key、Query、Value 的通俗解释

热搜里有一条很有意思："llm的token三个点key我是谁、query我在找什么、value我能提供什么"。这其实是在用通俗语言解释 Transformer 的注意力机制。在注意力计算中，每个 token 会生成三个向量：Query（我在找什么）、Key（我是谁）、Value（我能提供什么）。Query 和 Key 做点积得到注意力权重，再用权重对 Value 加权求和，得到输出。

这个机制决定了 LLM 的几个特性：上下文窗口有限，因为注意力计算是 O(n²) 的；长文本中远距离的依赖可能被稀释；token 的切分方式影响模型对文本的理解。理解这些，才能明白为什么 prompt 工程里"把重要信息放前面或后面"是有道理的。

5.2 LLM as Judge：用模型评测模型

"llm as judge"是当前评测 LLM 输出的主流方法之一。思路很简单：让一个强模型（比如 GPT-4 级别）去评判另一个模型的输出好不好。相比人工评测，它便宜、快、可扩展；相比传统指标（如 BLEU、ROUGE），它更贴近人类判断。

但 LLM as Judge 有坑：评判模型可能有偏好，比如偏爱长回答、偏爱和自己风格相似的输出；评判标准如果不明确，结果不稳定；对抗性输入可能骗过评判模型。实操中建议：给评判模型明确的评分 rubric；用多个评判模型投票；定期用人工标注校准。

5.3 公开榜单与 LLM Wiki

"open llm leaderboard 等公开榜单"和"llm wiki"是了解模型能力的重要渠道。公开榜单（如 HuggingFace 的 Open LLM Leaderboard）提供了标准化的评测结果，方便横向对比。但要注意：榜单上的分数和实际业务表现可能差距很大，因为榜单的评测集和你的场景不一样。选模型时，榜单只能作为初筛，最终还是要用自己的数据做评测。

LLM Wiki 这类知识库则汇总了模型的基本信息、能力边界、使用成本等，适合快速了解一个不熟悉的模型。

6. 常见问题与排查技巧实录

6.1 Agent 与 LLM 应用的高频问题速查

6.2 独家避坑技巧

• Prompt 里别放太多工具描述：工具超过 10 个，LLM 的选择准确率明显下降。按场景分组，动态加载。
• RAG 的 top-k 不是越大越好：k=3 到 5 通常够用，太大反而引入噪声。配合 rerank 效果更好。
• Agent 的最大迭代次数一定要设：我见过 Agent 陷入循环调用同一个工具几十次，烧了一堆 token。
• 本地开发用 Ollama，生产用云端 API：本地模型适合验证流程，生产环境的质量和稳定性还是云端更靠谱。
• MCP Server 的日志要详细：出问题时，日志是唯一的线索。记录每次调用的入参、出参、耗时。

6.3 关于"codex无法发送消息，显示更新agent沙盒"的排查

这个报错通常和沙盒环境有关。Codex 这类工具在沙盒里运行 Agent，沙盒的更新可能导致通信中断。排查步骤：检查沙盒进程是否正常；查看沙盒日志有没有权限或网络错误；确认 Agent 的配置是否指向了正确的沙盒地址；必要时重启沙盒和 Agent 服务。如果沙盒是容器化的，检查容器的网络配置和挂载卷。

7. 一些实操后的个人体会

做 Agent 和 LLM 应用这两年，我最大的体会是：这个领域变化太快，但底层逻辑变化很慢。RAG 的核心是检索质量，Agent 的核心是决策和工具调用，MCP 的核心是标准化接口，这些不会因为模型换代就失效。所以与其追新模型，不如把数据管线、评测体系、安全边界这些基础设施做扎实。

另一个体会是：别迷信榜单和 demo。榜单上的高分模型在你的场景里可能一塌糊涂，demo 里流畅的 Agent 在生产环境可能因为一个超时问题就崩了。真正靠谱的做法是：用自己的数据建评测集，用真实流量做压测，用红队测试找安全漏洞。

最后分享一个小技巧：搭 RAG 或 Agent 系统时，先把"检索"和"生成"分开评测。检索的指标是召回率和准确率，生成的指标是忠实度和相关性。分开评测才能定位问题到底出在哪一环，而不是笼统地说"效果不好"。这个习惯帮我省了大量调试时间。