企业官网建设流程全解析

这周在 GitHub 上逛了一圈热门榜单，能明显感觉到一个变化：大家开始从“调大模型聊天”转向“让大模型干正经事”了。上榜的不是又一个套壳 ChatBot，而是向量库、AI协作、浏览器控制这一类能直接进入生产链路的基础组件。这篇我挑四个实测过、或者至少仔细研究过的开源项目来拆解，它们覆盖了 RAG 知识库、多智能体协作、浏览器自动化，最后一个项目又把这三条线串成了可视化平台。无论你是做 AI 应用的工程师，还是准备从零入手 RAG/Agent 的开发者，这四件套都值得花一个下午过一遍。

我会按“解决什么问题 → 核心概念 → 最小可用示例 → 踩坑注意”的顺序来讲，所有代码都以我本地跑通的版本为参考，版本变了的地方会额外标注。先声明一下，四个项目分别对应 Qdrant、CrewAI、browser-use、Dify，它们不是同一层级的工具，但放在一起刚好能拼出一条完整的“AI 应用落地链路”。

1. 本周 GitHub 热门项目盘点：为什么是向量库、AI协作和浏览器控制

1.1 从对话到干活：AI 工具链正在补上的三个短板

大模型本身已经不太稀缺了，稀缺的是让模型可靠地接入真实世界的“管道”。对话产品大家都会写，但一旦涉及私有知识、复杂流程、真实软件操作，单靠 Prompt 远远不够，这就是本周热门项目集中在三个方向的原因。

第一个短板是记忆。大模型训练完之后知识就冻结了，你公司的内部文档、最新的产品手册、几万条工单记录，它一概不知道。向量库解决的就是这件事：把文档切片、向量化、存起来，用户提问时先做语义检索，再把这些相关内容拼进 Prompt，让模型基于真实资料回答。这也就是 RAG 知识库的基本形态。

第二个短板是单 Agent 能力的边界。让一个大模型同时做调研、写代码、做测试、写总结，它很容易顾此失彼，而且上下文窗口也扛不住。多智能体协作的思路是把一个复杂任务拆成多个角色，各自负责一段，再按流程拼接结果。这就像你不可能让一个人既当产品经理又当架构师还当测试，但可以让三个人配合。

第三个短板是操作真实软件。很多业务系统没开放 API，或者开放成本极高，但网页大家都能打开。浏览器控制类项目等于给 AI 装了一双手，让模型自己看页面、自己点按钮、自己填表单。三个短板合起来，就是“从知道到做到”的完整链路。

1.2 四个项目怎么选：先看定位表，再看取舍

先把四个项目放进同一张表里，方便你判断哪个是你当前最需要的。

选 Qdrant 而不是直接上 Milvus，是因为 Qdrant 对个人开发者和中小团队更友好。它用 Rust 写的，单个 Docker 容器就能跑起来，不需要额外依赖 ZooKeeper、S3 这些基础设施。Chroma 虽然更轻，但 Qdrant 的 payload 过滤能力和分布式扩展上限明显更强，后续文档量上来不需要推翻重来。

选 CrewAI 而不是 AutoGen，是因为 CrewAI 的声明式 API 更容易理解。Agent、Task、Crew 三个概念就能描述绝大多数协作场景，心智负担小，代码也好维护。AutoGen 更灵活，但也更容易写出自己都看不懂的复杂交互逻辑。如果你第一次接触多智能体，从 CrewAI 入手会顺很多。

选 browser-use 而不是 Playwright，是因为两者设计起点不一样。Playwright 是传统测试工具，每一步点击、输入、等待都要写死。browser-use 从底层就是面向 LLM 的，它让模型阅读页面状态后自主决定下一步动作，更像一个“能自我纠错”的自动化流程。最后加个 Dify，是因为它可以把前面三件事用可视化界面组合起来，团队里不擅长写代码的成员也能参与维护知识库和流程。

2. 向量库实战：用 Qdrant 把私有知识装进 RAG 流水线

2.1 向量库到底在解决什么问题

先想一个场景：你在公司知识库里搜“上个月的支付故障复盘”，传统数据库用关键词匹配，只能找到同时包含“支付”和“故障”的文档。但如果某篇复盘写的是“交易成功率骤降”，没有出现“支付故障”这四个字，关键词搜索就漏掉了。语义检索不一样，它先把文本变成向量，然后计算用户问题和文档向量的余弦相似度，意思相近的内容即使字面不同也能被召回。

这里提到的“向量”，可以理解成把一段文字压缩成一串几百维的浮点数，高维空间里距离越近，语义越相近。你当然可以把这些向量塞进 MySQL 或者 PostgreSQL，但普通数据库没有为海量高维向量提供高效的索引结构，数据量一上来，全表扫描算相似度会慢到没法用。专门的向量库会构建 HNSW、IVF 这类近似最近邻索引，让检索时间从秒级降到毫秒级。

一个完整的最小 RAG 流水线是这样：文档加载 → 文本切分 → embedding 向量化 → 存入向量库。用户提问时，同样把问题向量化，到向量库里检索最相似的若干片段，把这些片段、问题、系统提示词一起交给大模型生成回答。向量库在这条链路里的角色，就是模型的“外置记忆体”。

2.2 本地跑通 Qdrant 的最小步骤

先把服务拉起来。Qdrant 官方提供 Docker 镜像，一条命令就能跑，容器退出后数据默认还在，不过为了演示方便，我用“前台运行 + 挂载目录”的常见方式：

docker run -d \ --name qdrant-demo \ -p 6333:6333 \ -p 6334:6334 \ -v $(pwd)/qdrant_data:/qdrant/storage \ qdrant/qdrant

然后安装 Python 客户端和 embedding 组件。我这里用sentence-transformers里的小模型做向量化，纯本地推理，不需要额外申请 API：

pip install qdrant-client sentence-transformers

接着写一个完整的入库和检索脚本。为了让新手也能直接跑通，我故意把代码写得直白一些，生产环境再封装：

from qdrant_client import QdrantClient from qdrant_client.models import Distance, VectorParams, PointStruct from sentence_transformers import SentenceTransformer model = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2") client = QdrantClient(host="localhost", port=6333) # 1. 创建集合，向量维度必须和模型输出维度一致 client.recreate_collection( collection_name="tutorial", vectors_config=VectorParams(size=384, distance=Distance.COSINE), ) # 2. 准备三条测试文档并向量化 docs = [ "向量数据库把文本变成高维向量，用向量相似度做语义检索。", "RAG 流程是先检索再生成，让大模型基于私有知识回答问题。", "Qdrant 支持 payload 过滤，可以按元数据缩小检索范围。", ] vectors = model.encode(docs).tolist() # 3. 写入向量库，payload 里存原始文本和来源 points = [ PointStruct( id=i, vector=vectors[i], payload={"text": docs[i], "source": "tutorial.md"}, ) for i in range(len(docs)) ] client.upsert(collection_name="tutorial", points=points) # 4. 用一句意思相近但字面不同的话去检索 query = "语义检索怎么实现" results = client.search( collection_name="tutorial", query_vector=model.encode(query).tolist(), limit=2, ) for res in results: print(round(res.score, 4), res.payload["text"])

运行后能看到，即使问题里没有“数据库”这个关键词，排在最前面的依然是第一条“向量数据库把文本变成高维向量”，这就是语义检索和关键词检索的本质差别。这里有两个细节要记住：集合的向量维度必须和 embedding 模型的输出维度严格一致，all-MiniLM-L6-v2 输出 384 维，你换别的模型就要同步改；距离度量用 COSINE 而不是 DOT PRODUCT，除非你已经对向量做了归一化处理。

2.3 让检索结果更准的 4 个参数

第一个是 embedding 模型选择。通用小模型跑得快，但对某个垂直领域的理解往往不够。我的习惯是先用通用模型搭通链路，确认效果瓶颈在检索而不是 Prompt 之后，再换成领域数据微调过的中文模型，比如 bge-base-zh-v1.5 这类，召回率通常能提升一截。

第二个是文本切分策略。很多新手把整篇文档直接塞进向量库，结果检索出来的片段又长又杂，模型没法定位重点。一般建议先按段落切，再限制每块 256 到 512 个 token，并且相邻块之间留 20 到 50 个 token 的 overlap，避免一句话被硬生生切断。切分粒度要到什么程度，取决于文档类型：合同条款适合小块精确匹配，技术博客适合稍大的块保留上下文。

第三个是 top_k 和分数阈值。检索返回多少条、要不要对分数设下限，直接影响生成质量。返回太少可能漏掉关键信息，返回太多又会让模型注意力分散。我一般先设limit=5，观察召回结果的score分布，再决定要不要加一个 0.3 或者 0.5 的阈值，把明显不相关的片段过滤掉。

第四个是 payload 过滤。业务系统里的文档通常带时间、来源、部门、文档类型这些元数据，把它们写进 payload，检索时用must条件提前过滤，既能提高准确率又能减少计算量。比如“只看最近 30 天的公告”，直接加一个datetime范围过滤，效果比把时间范围写进查询语句再让模型自己判断好得多。

3. AI 协作实战：用 CrewAI 搭一组会分工的智能体

3.1 把多智能体理解成一家小型公司

CrewAI 的核心概念就三个：Agent 是员工，Task 是任务卡，Crew 是团队。每个 Agent 要有明确的角色、目标和背景设定，否则模型会“表演”得很用力但方向偏掉。每个 Task 要写清楚要做什么、产出什么、交给谁做，没有明确产出标准的任务，多智能体会互相编造结果。

我用一个类比来解释流程：你开了一家内容外包公司，接到一个“写一篇向量数据库选型报告”的订单。项目经理决定先让研究员去收集竞品资料，等报告交上来了，再让技术写手改写成博客。这就是 CrewAI 里Process.sequential的顺序协作模式。如果任务复杂到需要有人实时调配，还可以用Process.hierarchical，让一个 manager Agent 负责拆分和分发任务。

关键点在于，多智能体协作不是几个 LLM 的简单叠加。好框架能把角色边界、任务依赖、输出格式这些约束落到代码层面，减少 Agent 之间的“扯皮”。CrewAI 的声明式写法在这方面做得很好，你不需要自己维护复杂的消息循环，只要把“谁做什么、产出什么、按什么顺序”写清楚，框架自己会处理内部的消息传递。

3.2 一个双 Agent 最小示例

下面这个例子我本地跑通过，逻辑是让“研究员”先做素材调研，再让“技术写手”把调研结果落成博客开头。两个 Agent 一个任务，按顺序执行，非常适合第一次试水多智能体。

pip install crewai

from crewai import Agent, Task, Crew, Process researcher = Agent( role="行业研究员", goal="深入分析向量数据库的选型要点", backstory="你做了十年数据库相关研发，擅长从性能、功能、社区生态三个角度对比技术方案。", llm="gpt-4o-mini", ) writer = Agent( role="技术写手", goal="把调研结论改写成结构清晰的技术短文", backstory="你是一位面向开发者的技术博主，文字直接、有干货。", llm="gpt-4o-mini", ) research_task = Task( description="对比 Qdrant、Milvus、Chroma 三个开源向量数据库，输出选型建议。", expected_output="一份 500 字左右的对比结论，包含推荐项和理由。", agent=researcher, ) writing_task = Task( description="把上一篇调研结论改写成一篇技术博客开头，要求适合开发者阅读。", expected_output="一段 300 字左右的博客开头。", agent=writer, ) crew = Crew( agents=[researcher, writer], tasks=[research_task, writing_task], process=Process.sequential, ) result = crew.kickoff() print(result)

实际跑完你会发现，expected_output是决定整个流程质量的关键。第一次我把写作任务的预期输出写成“一段博客”，结果写手自由发挥写了一千多字，还把调研结论里没出现的信息也编了进来。改成“一段 300 字左右的博客开头，必须包含 Qdrant 和 Milvus 的对比结论”之后，输出才变得可用。你给 Agent 的约束越具体，它给你的结果越接近预期。

3.3 多 Agent 协作最容易翻车的三个地方

第一是“幻觉传播”。Agent 之间传递的是文本，如果研究员给的结论本身就有猜测成分，写手会把它当成事实继续加工，最后出来的内容看起来逻辑自洽但全是编的。拆解办法是在关键任务描述里加上“只能基于给定的资料，不确定的内容标记为待验证”，或者增加一个专门负责审核的 Agent。

第二是上下文窗口爆炸。任务链一旦超过二十步，前面任务的中间结果都会堆积在上下文里，很快顶满大模型的窗口。我的经验是长流程不要做成一个大 Crew，拆成多个 Crew 分段跑，每一段只把上一段的最终结论传下去，而不是把中间过程全带上来。

第三是输出格式不稳定。多步骤任务的终点通常要接下游程序或人工审核，格式一旦乱掉就很难收场。解决方式是在expected_output里给出具体格式，比如“一段 Markdown，包含 ## 对比结论 和 ## 推荐项 两个小节”，必要的时候还可以用 Pydantic 定义结构化输出模型，让最终结果直接能解析成 JSON。

4. 浏览器控制实战：用 browser-use 让 AI 自己点击和填写

4.1 browser-use 和传统自动化脚本有什么不一样

传统浏览器自动化工具的思路是写死脚本：打开页面，等待元素出现，点击某个按钮，输入内容，再点击下一个。这套路对付稳定不变的老系统没问题，但页面稍微改版，脚本就废了。browser-use 的思路完全不同，它把浏览器当作一个“环境”，大模型是决策者，通过观察页面状态决定下一步操作，做错了还能自己纠错重试。

具体实现上，browser-use 通过 CDP 和 Chrome 通信，拿到页面的可交互元素、文本内容、截图等信息，然后把这些内容交给 LLM。模型判断“当前页面是搜索结果列表，用户想要前五条结果”，就生成一条“提取当前列表所有链接”的动作，框架再去执行并返回新的页面状态。整个过程循环往复，直到任务完成。

用一句话概括：Playwright 是你给演员写好每一句台词，browser-use 是你只告诉演员“我要什么效果”，让他自己临场发挥。这种设计带来的好处非常明显，页面小改版不需要重写脚本，你要做的只是修改任务描述。

4.2 五分钟跑一个自动搜索示例

先安装依赖。browser-use 需要配合一个 LLM 调用来做决策，我直接用 LangChain 的 OpenAI 接口，你也可以换成其他兼容模型：

pip install browser-use

import asyncio from browser_use import Agent from langchain_openai import ChatOpenAI async def main(): agent = Agent( task="打开必应，搜索 GitHub 本周热门项目，把前五条结果的标题和链接提取出来。", llm=ChatOpenAI(model="gpt-4o", temperature=0), ) result = await agent.run() print(result) if __name__ == "__main__": asyncio.run(main())

temperature=0是我建议的设置，这类自动化任务要的是确定性，不需要模型发散。第一次跑的时候会弹出一个浏览器窗口，你会看到页面自己在动，那其实是模型正在执行“打开必应 → 输入关键词 → 点击搜索 → 读取结果列表”这一串决策。整个过程可能比传统脚本慢很多，因为每次决策都需要调用一次大模型，但它能适应页面变化，这一点在维护成本上非常划算。

如果你本地没有 OpenAI 的 Key，也可以用 Ollama 跑一个本地模型，只是页面理解能力会明显下降，复杂任务容易判断失误。更优雅的折中方案是用强模型做决策、用弱模型做文本抽取，但那是进阶玩法，新手先把单 Agent 调通再说。

4.3 浏览器自动化真正值得注意的坑

登录态是第一大坑。很多网页需要登录才能看到内容，而自动化启动的浏览器默认是一个全新 Profile，什么登录信息都没有。解决方式是给 browser-use 指定一个固定的用户数据目录，让它复用你日常浏览器的 Cookie 和登录状态，相关参数在 Python API 里对应user_data_dir。

第二是动态加载内容。现在的页面大量使用异步渲染，模型第一次看到的时候列表可能还没加载完，于是误判“页面没有结果”。不要急着把任务拆细，先在任务描述里加上“等待结果列表出现再提取”，给模型一个“先观察、再行动”的缓冲空间。

第三是验证码。这个真没有太好的自动化办法，遇到图形验证码，我的处理是让 Agent 停下来，输出一个“需要人工确认”的状态，再由人工在浏览器里手动过一次。与其折腾复杂的验证码识别，不如在流程设计上预留人工介入点。

第四是安全问题。给 Agent 的提示词里不要放明文密码、API Key、支付信息，因为你不知道模型在极端情况下会把这些内容输出到什么位置。我的习惯是：自动化任务只负责读和写普通业务字段，敏感操作一律人工确认，而且给 Agent 限定执行域名范围，严禁跳转到外部链接。

5. 把前面三件事串起来：Dify 这类平台的价值

5.1 Dify 在 AI 工具链里的位置

前面三章讲的是单点工具，每个都能独当一面，但真正做产品的时候你会发现，把向量库、Agent、模型调用、日志监控、权限管理这些串起来，胶水代码写起来比功能本身还多。Dify 这类开源平台解决的就是这个集成问题。

Dify 把 RAG 知识库、Agent 编排、工作流、模型管理、API 发布做成了可视化界面。你不需要从零写一个前端来调 Qdrant，直接在控制台里上传文档、选切分策略、配置向量库，知识库就建好了。创建 Agent 时，可以把知识库检索作为一种工具拖进流程，再配上模型、设置提示词，一个带知识库增强的问答机器人几分钟就能跑起来。

这里的价值不只是“省代码”，而是让团队协作方式变好。产品和运营可以自己去维护知识库文档和调整提示词，不再每改一句话都要找开发发版。开发只需要把精力放在复杂的业务逻辑和系统集成上，而不是把时间花在重复的 CRUD 页面里。

5.2 快速部署 Dify 并接上 Qdrant

Dify 官方推荐用 Docker Compose 部署。我把最小启动步骤贴出来，假设你机器上已经装好了 Docker 和 Docker Compose：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

启动之后打开本地 Web 端，第一步是配置模型供应商。在设置里添加你的模型 API Key，选择模型，保存。接下来创建知识库，上传一批文档，选择切分策略，然后在“向量数据库”配置里选择 Qdrant，填入本地服务地址http://localhost:6333。这时候我之前在第二章里用代码做的事，在界面上用鼠标点几次就完成了。

再往前走一步，你可以创建一个“聊天助手”类型的应用，把刚才的知识库挂进去，Dify 会自动完成“用户提问 → 向量检索 → 拼接 Prompt → 模型回答”的流程。如果你想让流程更复杂一点，比如先判断用户意图，再决定走知识库还是走 Agent 工具调用，可以在“工作流”编排里画节点连线，Dify 也支持 HTTP 请求节点，这意味着你可以把 browser-use 封装成一个外部服务，在流程里直接调用，让 AI 去操作网页拿数据，再交给语言模型总结。

这套组合拳跑通之后，你的应用就具备了三层能力：知识库负责回答“我知道什么”，Agent 负责处理“需要拆解的任务”，浏览器自动化负责“需要去真实网站操作的动作”。Dify 只是把这三层像搭积木一样拼在一起，真正决定天花板的是底层这些组件选得好不好。

6. 常见问题速查与排查思路

6.1 高频问题速查表

6.2 背后通用的排查思路

很多问题表面看不相关，但排查逻辑是相通的。我自己的习惯是“从底向上，逐层隔离”。向量检索不准，先不看 Prompt 写得好不好，先把检索结果打印出来，确认召回片段里有没有正确答案，没有就回去调 embedding 和切分参数。Agent 输出乱，先不看协作逻辑，把单个 Agent 单独跑一遍，确认它单打独斗是正常的，再怀疑是不是任务依赖设计有问题。浏览器自动化失败，先手动访问一次目标页面，看看当前页面结构、登录状态和网络环境是否正常，再让模型去执行。

这种排查思路的核心是：永远先确认“上一层的输入是否可靠”。向量库返回的内容都是错的，Agent 再聪明也写不出对的东西；浏览器页面都没打开，模型决策得再精确也执行不了。把每一层都验证一遍，绝大多数问题都能快速定位，而不是盲目调 Prompt 或换模型。这也是我建议新手一开始就用这些可观测性强的开源组件的原因，Qdrant 有 Dashboard 可以看检索日志，CrewAI 可以单独跑 Agent，browser-use 能看到每一步的操作记录，排查起来比黑盒服务舒服得多。

我个人在实际操作中的体会是，这四个项目不要平均用力，先解决你当前最痛的那个点。如果你的知识库问答一直不可用，就先花时间把 Qdrant 这一层调透，再考虑要不要上多智能体；如果你的流程已经需要多个角色配合了，再引入 CrewAI 也不迟。最后再分享一个小习惯：每次部署完向量库，我都会先用一个最简单的“查-答”链路压一遍，而不是直接在上层套 Agent，先保证底座不出错，后面的楼才盖得稳。