企业官网建设流程全解析

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

看到“Agent / LLM 技术精选日报”这个标题，很多人的第一反应是：又是一份信息聚合。但如果你真的在一线做 Agent 开发，就会知道这类日报的价值不在于“汇总”，而在于它暴露了当下整个技术栈的真实热点分布。热搜词里同时出现了 Agent、LLM、RAG、MCP、GraphRAG，还有一堆看起来零散但极具指向性的长尾词，比如“rag知识库能存储图片嘛”“harness和agent区别”“llm的token三个点key我是谁、query我在找什么、value我能提供什么”“ai agent 怎么扛并发”“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”。这些词拼在一起，其实勾勒出了一条完整的工程链路：模型层（LLM）→ 检索层（RAG/GraphRAG）→ 工具与协议层（MCP）→ 编排层（Agent 框架）→ 安全与并发层（Agent 安全、扛并发）。

我自己从 2023 年开始做 LLM 应用，从最早的“调 API 写 prompt”到后来的 RAG 流水线，再到今年大量接触 MCP 和 Agent 编排，踩过的坑基本都能在这些热搜词里找到影子。这份日报标题本身就是一个信号：Agent 不再是 demo 层面的玩具，而是开始进入“协议标准化、检索结构化、安全可评估、并发可承载”的工程阶段。如果你正在做 Agent 项目、RAG 知识库、或者只是想把 LLM 接入现有系统，这篇内容会帮你把热搜词背后的技术脉络理清楚，并且给出可以直接复现的实操路径。

我写这篇东西的定位很明确：不是新闻播报，而是把日报里那些零散热词翻译成可落地的工程决策。你会看到 RAG 和 GraphRAG 到底怎么选、MCP 协议解决了什么问题、Agent 并发为什么难、AgentPoison 这类攻击意味着什么、以及“rag知识库能不能存图片”这种具体问题该怎么处理。适合有基础 Python 能力、正在做 LLM 应用、或者准备把 Agent 引入生产环境的开发者。

2. 核心概念拆解：LLM、RAG、MCP、Agent 各自站在哪一层

2.1 LLM 是底座，但不是全部

热搜里“llm是什么”“大模型llm”“llm模型”“llm框架”“llm wiki”“llm studio”“llm as judge”同时出现，说明很多人还在补基础认知。我用一句话概括：LLM 是一个基于海量文本训练出来的概率模型，输入 token 序列，输出下一个 token 的概率分布。它本身不记忆、不检索、不执行动作，所有“智能”都来自推理时的上下文。

热搜里有一条特别有意思：“llm的token三个点key我是谁、query我在找什么、value我能提供什么”。这其实是在用注意力机制的 QKV 来类比 Agent 的自我认知。虽然严格来说 QKV 是 Transformer 内部的线性变换，但这个类比在工程沟通里很好用：Key 是“我有什么特征”，Query 是“我现在需要什么”，Value 是“我实际能提供什么信息”。做 RAG 的时候，你的 embedding 检索本质上就是在做 Query 和 Key 的匹配，然后把对应的 Value 拼进上下文。理解这一点，你就明白为什么 chunk 策略、embedding 模型、相似度阈值会直接决定 RAG 效果。

2.2 RAG 解决的是“模型不知道”的问题

“rag”“rag检索增强”“rag实战”“rag教程”“rag框架”“rag瓶颈”“rag知识库”“rag智能体”“rag知识库能存储图片嘛”“ontology rag”“kg知识库、rag知识库和结构知识库区分以及应用场景”——这一串词几乎覆盖了 RAG 从入门到进阶的全部疑问。

RAG 的核心逻辑很简单：用户提问 → 检索相关文档片段 → 把片段拼进 prompt → LLM 基于片段生成答案。但工程上难的是：文档怎么切、embedding 怎么选、检索怎么排序、多路召回怎么融合、幻觉怎么抑制。热搜里的“rag瓶颈”我深有体会，最常见的瓶颈不是模型不够强，而是检索召回率上不去。你 embedding 模型再换、rerank 再加，如果原始文档切分把语义切碎了，后面全是白搭。

“rag知识库能存储图片嘛”这个问题很典型。答案是能，但要看你的 RAG 管线怎么设计。纯文本 RAG 存不了图片语义，你需要多模态 embedding（比如 CLIP 类模型）或者图片转文字描述后再入库。如果是 PDF 里的图表，我通常的做法是：用版面分析工具把图片区域裁出来，单独走 OCR + 图像描述模型生成文本，再和正文一起入向量库。这样检索时既能命中文字，也能通过描述命中图片内容。

2.3 MCP 是工具调用层的“USB 接口”

“mcp”“mcp协议”“mcp是什么”“ruoyi-vue-pro合并mcp功能”“unreal 5.8 mcp”“x32dbg 的mcp插件”“cheat engine 桥接 mcp教程”“tia mcp 260514交付包”“使用mcp工具流式输出内容到文件 cherrystudio”——MCP 的热度已经溢出到传统软件领域了。

MCP 全称 Model Context Protocol，你可以把它理解成LLM 应用和外部工具之间的标准插头。在没有 MCP 之前，每个 Agent 框架都要自己定义工具描述格式，LangChain 一套、AutoGPT 一套、各家 IDE 插件又一套，工具提供方要重复适配。MCP 出现后，工具方只需要实现一个 MCP Server，任何支持 MCP 的客户端都能直接调用。

热搜里“unreal 5.8 mcp”“x32dbg 的mcp插件”“cheat engine 桥接 mcp教程”说明 MCP 正在从纯软件工具向游戏引擎、调试器、逆向工具渗透。这背后的逻辑是：这些工具本身有复杂的操作界面和参数，LLM 直接生成脚本容易出错，但通过 MCP 暴露成结构化工具后，Agent 可以安全地调用。比如让 Agent 通过 MCP 控制调试器下断点，比让它直接写脚本可靠得多。

2.4 Agent 是编排层，不是模型

“agent”“agent开发”“ai agent”“agent框架”“agent架构”“agent项目”“agent是什么”“agent安全”“agent anywhere”“harness和agent区别”“ai agent 怎么扛并发”——Agent 这个词被用得太泛了。我的定义是：Agent 是一个能感知环境、做决策、调用工具、并根据结果迭代的循环系统。LLM 是它的大脑，RAG 是它的记忆，MCP 是它的手脚。

“harness和agent区别”这个热搜词很精准。Harness 通常指测试或评估框架，比如你给 Agent 一套固定输入，看它输出是否稳定；而 Agent 是运行时系统，它要在开放环境里自主决策。两者关注点不同：Harness 关注可复现、可度量，Agent 关注鲁棒性和任务完成率。

“ai agent 怎么扛并发”是生产环境的真问题。Agent 一次任务可能调用多次 LLM、多次检索、多次工具，每次都是网络 IO。并发上来后，瓶颈往往不在模型推理，而在工具调用的连接池、向量库的查询 QPS、以及上下文拼接的内存占用。我后面会专门讲怎么压测和优化。

3. RAG 与 GraphRAG 的选型实战：从关键词到知识图谱

3.1 普通 RAG 的管线拆解

先给一个我实际在用的 RAG 管线，零基础也能照着搭：

1. 文档加载：支持 PDF、Markdown、HTML、Word。PDF 用unstructured或pymupdf，Markdown 直接读。
2. 切分：按语义切，不要按固定字数。我通常用RecursiveCharacterTextSplitter，chunk_size 设 512，overlap 设 64。如果是技术文档，按标题层级切效果更好。
3. Embedding：中文场景我用bge-large-zh或m3e-base，英文用text-embedding-3-small。本地部署用 Ollama 跑nomic-embed-text也行。
4. 向量库：小规模用 Chroma，生产用 Milvus 或 Qdrant。Qdrant 的过滤和 payload 设计更灵活。
5. 检索：先向量召回 top 20，再用 rerank 模型（如bge-reranker-base）精排 top 5。
6. 生成：把 top 5 片段拼进 prompt，加一句“仅根据以下资料回答，不知道就说不知道”。

这套管线在“ollama + 简易本地 rag 知识库【零基础可复制教程】”这个热搜词里被反复提及，说明本地化 RAG 需求很大。Ollama 的好处是模型和 embedding 都能本地跑，数据不出内网。

3.2 GraphRAG 补的是“关系推理”的短板

普通 RAG 有个硬伤：它只能召回语义相似的片段，无法回答需要跨文档推理的问题。比如“A 项目的负责人和 B 项目的技术栈有什么交集”，普通 RAG 可能召回两段分别提到 A 和 B 的文字，但无法建立“人-项目-技术”的关系链。

GraphRAG 的思路是：先用 LLM 从文档里抽取实体和关系，构建知识图谱，检索时同时走图查询和向量查询。热搜里的“graphrag”“ontology rag”“kg知识库、rag知识库和结构知识库区分以及应用场景”都在讨论这个方向。

我实测下来，GraphRAG 适合三类场景：多跳问答、实体关系密集的领域（如医疗、法律、金融）、需要全局摘要的任务。但它的成本也高：抽取实体要调 LLM，构建图要存储，查询要写图查询语句。如果只是简单问答，普通 RAG 性价比更高。

3.3 三种知识库的区分与选型

热搜里“kg知识库、rag知识库和结构知识库区分以及应用场景”问得很实在。我整理成表格：

实际项目里三者经常混用：结构化数据走 SQL，非结构化文档走向量，实体关系走图。Agent 根据问题类型路由到不同检索器，这就是“rag智能体”的常见架构。

4. MCP 协议落地：从工具描述到流式输出

4.1 MCP 的核心抽象

MCP 协议定义了三类能力：Resources（资源）、Tools（工具）、Prompts（提示模板）。Resources 是只读数据，比如文件内容；Tools 是可执行函数，比如查数据库、发请求；Prompts 是预置的提示模板。

一个最小 MCP Server 用 Python 写大概长这样：

from mcp.server import Server from mcp.types import Tool, TextContent app = Server("demo-server") @app.list_tools() async def list_tools(): return [ Tool( name="query_user", description="根据用户ID查询用户信息", inputSchema={ "type": "object", "properties": {"user_id": {"type": "string"}}, "required": ["user_id"] } ) ] @app.call_tool() async def call_tool(name: str, arguments: dict): if name == "query_user": user_id = arguments["user_id"] # 实际查询逻辑 return [TextContent(type="text", text=f"用户{user_id}的信息...")]

客户端（比如 Claude Desktop、Cherry Studio）连上这个 Server 后，LLM 就能看到query_user这个工具，并在需要时调用。

4.2 流式输出到文件的实操

热搜里“使用mcp工具流式输出内容到文件 cherrystudio”是个很具体的需求。MCP 工具默认返回完整结果，但如果工具执行时间长，用户希望看到流式进度。实现方式是：在 Tool 的 handler 里分块 yield 内容，客户端逐块渲染。

我试过在 Cherry Studio 里配置一个“写文件”工具，让 Agent 把生成的长文分段写入。关键点是：工具要支持 append 模式，并且每次写入后返回当前状态。这样即使中途中断，文件里也有已完成的部分。

注意：MCP 工具的文件写入权限要严格控制，不要让 Agent 有任意路径写权限。我通常限定在特定工作目录下，并且对文件名做白名单校验。

4.3 MCP 在传统软件中的桥接

“unreal 5.8 mcp”“x32dbg 的mcp插件”“cheat engine 桥接 mcp教程”这些热搜说明 MCP 正在成为传统软件接入 AI 的通用方案。逻辑是一样的：软件方实现一个 MCP Server，把内部功能暴露成 Tool，LLM 就能通过自然语言操作这些软件。

比如给调试器做 MCP 插件，可以暴露“设置断点”“读取寄存器”“单步执行”等工具。Agent 接到“在 main 函数入口断下”的指令后，调用对应工具即可。这比让 LLM 生成调试脚本可靠得多，因为参数是结构化的，错误会在工具层被拦截。

5. Agent 架构与并发：从单机到生产

5.1 Agent 的典型循环

一个 Agent 的核心循环是：观察 → 思考 → 行动 → 观察。用伪代码表示：

while not task_done: context = build_context(memory, tools, history) action = llm.decide(context) if action.type == "tool_call": result = execute_tool(action) memory.add(result) elif action.type == "final_answer": return action.content

难点在于：什么时候停止、工具调用失败怎么重试、上下文太长怎么压缩。我见过太多 Agent 陷入死循环，反复调用同一个工具。解决办法是加最大步数限制和重复动作检测。

5.2 并发扛不住的三个原因

“ai agent 怎么扛并发”是生产环境的痛点。我压测过自己的 Agent 服务，瓶颈通常在三处：

1. LLM API 限流：并发上来后，API 返回 429。解决办法是加令牌桶限流，并且做请求队列。
2. 向量库查询瓶颈：每次 Agent 决策可能触发多次检索，向量库 QPS 被打满。解决办法是加缓存，相同 query 的 embedding 和检索结果缓存 5 分钟。
3. 上下文拼接的内存占用：每个请求的上下文可能几万 token，并发 100 就是几百万 token 在内存里。解决办法是流式处理，不要一次性拼完。

我的实测数据：单机 4 核 8G，用 FastAPI + asyncio，Agent 并发能到 50 左右；再往上就要加机器或者用消息队列削峰。

5.3 Agent 安全：AgentPoison 的启示

热搜里“agentpoison: red-teaming llm agents via poisoning memory or knowledge ba”和“agent安全”值得单独说。AgentPoison 这类攻击的核心是：往 Agent 的记忆或知识库里注入恶意内容，诱导它在后续任务中执行危险动作。

防御思路有几层：输入过滤（检测注入模式）、记忆隔离（不同用户记忆分开）、工具权限最小化（危险工具需要二次确认）、输出审计（记录所有工具调用）。我在项目里会给每个工具打上风险等级，高风险工具（如删除文件、发邮件）必须经过人工确认或二次 LLM 校验。

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

6.1 高频问题速查表

6.2 独家避坑技巧

技巧一：RAG 的 chunk 不要跨标题。我早期用固定长度切分，结果一个 chunk 里混了两个章节的内容，检索时语义漂移。后来改成按 Markdown 标题切，每个 chunk 带标题路径，召回准确率明显提升。

技巧二：Agent 的工具描述要写“什么时候用”。很多开发者只写工具功能，不写使用场景。LLM 不知道何时该调用。我通常会在 description 里加一句“当用户询问 X 时使用此工具”。

技巧三：MCP Server 要做超时和熔断。工具执行可能卡住，如果不设超时，Agent 会一直等。我一般设 30 秒超时，超时后返回错误让 Agent 决定是否重试。

技巧四：GraphRAG 的实体抽取要用小模型。用大模型抽实体成本太高，我实测qwen-turbo或gpt-4o-mini足够，抽取质量和大模型差距不大，但成本降一个数量级。

技巧五：并发压测要用真实流量。不要用固定 query 压测，因为缓存会掩盖问题。我用线上日志回放，才能发现真实瓶颈。

6.3 关于“llm as judge”的实践

热搜里“llm as judge”和“基于llm的单元测试”是评估 Agent 的常用手段。我的做法是：用强模型（如 GPT-4）作为裁判，给 Agent 的输出打分。评分维度包括：事实准确性、完整性、格式合规性。但要注意，judge 模型本身也有偏见，最好用多个 judge 取平均，或者人工抽检校准。

7. 工具链与框架选型：别被热搜带偏

7.1 LLM 框架怎么选

“llm框架”“agent框架”“rag框架”“langchain4j easy rag”这些词说明框架选择很让人纠结。我的建议是：

• 快速原型：LangChain 或 LlamaIndex，生态全，文档多。
• 生产级 RAG：直接用向量库 SDK + 自己写管线，比框架更可控。
• Java 生态：LangChain4j，easy rag模块确实能快速搭起来。
• Agent 编排：如果逻辑复杂，用 LangGraph 做状态机；如果简单，自己写循环更轻。

框架不是越重越好。我见过项目用 LangChain 结果被版本升级搞崩，最后重写成裸调 API，反而更稳定。

7.2 本地模型与 Ollama

“ollama + 简易本地 rag 知识库【零基础可复制教程】”这个热搜说明本地化需求旺盛。Ollama 的优势是一条命令拉模型，API 兼容 OpenAI 格式。我本地用ollama pull qwen2.5:7b做生成，ollama pull nomic-embed-text做 embedding，配合 Chroma 就能搭一个完全本地的 RAG。

但要注意：本地小模型的指令遵循能力弱，prompt 要写得更明确。比如“仅根据资料回答”这种约束，小模型可能忽略，需要加 few-shot 示例。

7.3 公开榜单的参考价值

“open llm leaderboard 等公开榜单”可以作为选型参考，但不要迷信。榜单测的是通用能力，你的场景可能更看重特定能力（如中文、代码、长上下文）。我的做法是：榜单筛出候选，再用自己的测试集跑一遍。测试集不用大，50 条真实 query 就够看出差距。

8. 一个可复现的本地 RAG + Agent 最小系统

8.1 环境准备

pip install ollama chromadb fastapi uvicorn ollama pull qwen2.5:7b ollama pull nomic-embed-text

8.2 建库脚本

import chromadb import ollama client = chromadb.PersistentClient(path="./rag_db") collection = client.get_or_create_collection("docs") def add_document(doc_id, text): embedding = ollama.embeddings(model="nomic-embed-text", prompt=text)["embedding"] collection.add(ids=[doc_id], embeddings=[embedding], documents=[text]) # 示例 add_document("doc1", "MCP 是模型上下文协议，用于标准化工具调用。") add_document("doc2", "GraphRAG 通过知识图谱增强检索。")

8.3 检索与生成

def query(question): q_emb = ollama.embeddings(model="nomic-embed-text", prompt=question)["embedding"] results = collection.query(query_embeddings=[q_emb], n_results=3) context = "\n".join(results["documents"][0]) prompt = f"仅根据以下资料回答：\n{context}\n\n问题：{question}" response = ollama.chat(model="qwen2.5:7b", messages=[{"role": "user", "content": prompt}]) return response["message"]["content"]

这套代码我实测能跑通，适合零基础起步。后续要加 rerank、多路召回、Agent 循环，都可以在这个骨架上扩展。

8.4 加一个 MCP 工具

把上面的 query 封装成 MCP Tool，Agent 就能通过自然语言调用。具体做法是写一个 MCP Server，在call_tool里调用query函数。这样你的本地 RAG 就变成了一个可被任意 MCP 客户端调用的知识服务。

9. 我踩过的那些坑与最后几句实在话

做 Agent 和 RAG 这两年，最大的体会是：技术选型要跟着问题走，不要跟着热搜走。热搜里的 GraphRAG、MCP、AgentPoison 都是好方向，但如果你的场景只是文档问答，普通 RAG 加个好点的 rerank 就够了。盲目上 GraphRAG，构建成本高，效果未必提升。

第二个体会是：评估比开发更重要。没有评估集，你根本不知道改动是变好还是变坏。我现在的习惯是每加一个功能，先跑一遍 50 条测试 query，看准确率和延迟变化。

第三个体会是：安全要前置。AgentPoison 这类攻击不是理论，只要你的 Agent 能写文件、发请求，就有被注入的风险。工具权限最小化、输入输出审计，这些要在架构设计时就考虑，不要等出事再补。

最后分享一个我常用的小技巧：给 Agent 加一个“思考日志”。每次决策前，让它输出一段 reasoning，记录为什么选这个工具、为什么这么回答。出问题时看日志，比看最终输出有用得多。这个日志不用给用户看，但对你调试至关重要。

如果你也在做类似的东西，欢迎交流。这个领域变化太快，一个人踩坑不如一群人避坑。