企业官网建设流程全解析

1. 项目概述：一个无需API密钥的本地网页搜索MCP服务器

如果你正在本地运行大语言模型（比如 Ollama 或 LM Studio），或者在使用 Claude Code，想给它们加上联网搜索的能力，第一反应是不是去找个搜索 API？然后发现要么要花钱，要么有速率限制，要么对某些网站（比如韩国的 Naver）支持不好。我之前也在这个坑里折腾了很久，直到我决定换个思路：为什么不让 LLM 像真人一样，直接“操作”浏览器去搜索呢？

这就是AgentWebSearch-MCP项目的核心。它彻底抛弃了传统的搜索 API 模式，转而通过Chrome DevTools Protocol直接控制真实的 Chrome 浏览器窗口。这意味着，你的 LLM 发出的搜索请求，最终是由一个实实在在的、有完整浏览器指纹和 Cookie 会话的 Chrome 来执行的。没有 API 密钥，没有调用次数限制，更重要的是，它能完美绕过那些针对自动化脚本的检测机制，因为从网站的角度看，这就是一个普通用户在浏览。

这个项目最初是为了解决在韩国使用 Naver 搜索的痛点而设计的。Naver 对自动化请求的检测非常严格，常规的 headless 浏览器或者 requests 库很容易被识别并屏蔽。但用真实浏览器去访问，就畅通无阻了。后来我发现，这个思路对 Google、Brave 等其他搜索引擎同样有效，甚至更通用。于是，我把它打包成了一个MCP 服务器，这样就能无缝集成到 Claude Code、Cursor、LM Studio 或者 OpenClaw 这类支持 MCP 协议的开发环境中，让你的本地 AI 助手瞬间获得“上网冲浪”的能力。

2. 核心原理与架构设计：为什么选择真实浏览器？

2.1 传统方案的瓶颈与真实浏览器的优势

在深入代码之前，我们先聊聊为什么“真实浏览器”这个选择如此关键。市面上常见的 LLM 联网搜索方案，大致分为三类：

1. 付费搜索 API：如 Tavily、Brave Search API。优点是稳定、快速，但需要付费，有额度限制，并且对于 Naver 这类区域性搜索引擎支持有限或没有。
2. 自建搜索引擎聚合：如 SearXNG。免费、开源，可以聚合多个搜索引擎。但问题在于，它本质上还是一个网络服务，其后端爬虫同样面临被目标网站（尤其是 Naver）屏蔽的风险。
3. Headless 浏览器自动化：使用 Puppeteer、Playwright 等工具控制无头浏览器。这已经接近我们的方案了，但“无头”模式（没有图形界面）的浏览器指纹与普通浏览器仍有差异，一些高级的反爬策略依然能将其识别出来。

AgentWebSearch-MCP选择了第四条路：控制带有完整图形界面的真实 Chrome 实例。这带来了几个决定性的优势：

• 零成本与无限制：你不需要为搜索次数付费，就像你自己上网搜索一样，唯一的“成本”是你的带宽和一点点电费。也没有每秒请求数的限制。
• 极强的抗检测能力：网站用于识别机器人的技术，如检测 WebDriver 属性、检查浏览器指纹（字体、Canvas、WebGL 等）、分析用户行为模式，在真实的、正在渲染页面的 Chrome 窗口面前几乎全部失效。因为它就是一个“真人”。
• 完整的会话持久性：每个 Chrome 实例都使用独立的用户数据目录（Profile）。这意味着你可以登录你的 Google 账号，启用同步。之后的所有搜索都会携带登录态，不仅能使用“用 Google 账号登录”第三方网站，还能获得更个性化的搜索结果。Cookie、本地存储都会在浏览器重启后保留。
• 对特定网站的无敌兼容性：正如项目初衷，像 Naver 这样对爬虫严防死守的网站，也能被轻松驾驭。

2.2 系统架构与数据流拆解

整个系统的运行，可以理解为一场由 MCP 协议指挥、CDP 协议执行的多浏览器协同搜索任务。

用户/LLM 提出问题 | [MCP 服务器] | (解析请求，调用对应工具) | [核心工具集] ├── web_search: 仅执行并行搜索，返回摘要。 ├── smart_search: 搜索 + 自动抓取目标网页正文。 └── agentcpm: 由 AgentCPM-Explore 模型智能规划搜索策略后执行。 | [CDP 并行搜索引擎] | (通过 WebSocket 同时向三个端口发送指令) | [Chrome 实例 9222] [Chrome 实例 9223] [Chrome 实例 9224] Naver Google Brave | | | (同时执行搜索，渲染页面，提取结果) | [结果聚合与后处理] | 返回格式化的答案与引用来源

核心组件解析：

1. Chrome Launcher (chrome_launcher.py): 这是系统的“底盘”。它的职责是以调试模式启动多个 Chrome 进程，每个进程监听不同的端口（如 9222, 9223, 9224），并为其分配独立的数据目录。这确保了 Naver、Google、Brave 的登录会话互不干扰。
2. CDP 搜索核心 (cdp_search.py): 这是与浏览器直接对话的“驾驶员”。它利用websockets库连接到每个 Chrome 实例的 DevTools 端口，发送模拟用户操作的 CDP 命令（如导航到搜索 URL、填写搜索框、点击按钮、滚动页面、提取 DOM 内容）。它实现了并行搜索，同时向多个引擎发起请求，最后聚合结果。
3. MCP 服务器 (mcp_server.py): 这是对外的“统一接口”。它遵循 Model Context Protocol 规范，将底层的搜索能力封装成几个标准的工具（Tools），供 Claude Code 等客户端调用。它处理 JSON-RPC 格式的请求和响应。
4. LLM 适配器 (llm_adapters/): 主要为独立 CLI 模式服务，提供了连接不同 LLM 后端（SGLang, Ollama, LM Studio, OpenAI）的适配层，让search_agent.py可以灵活切换大脑。
5. AgentCPM-Explore 集成: 这是一个可选的“智能调度员”。当使用agentcpm工具时，查询会先发给本地的 AgentCPM-Explore 模型（通过 SGLang 服务器）。这个专门为搜索任务微调的模型会自主拆解复杂问题，生成多个搜索关键词，然后调用cdp_search执行，最后综合信息生成答案。这实现了真正的智能体（Agent）行为。

关键设计抉择：为什么不用一个浏览器开多个标签页？最初我也考虑过，但很快否定了。不同网站（尤其是需要登录的）在同一个浏览器的不同标签页里共享 Cookie 和本地存储，这会导致会话串扰。例如，你在标签页1登录了 Naver，可能会影响标签页2的 Google 会话。为每个搜索引擎分配独立的浏览器实例，是保证隔离性和稳定性的最干净利落的方式。虽然多消耗一些内存，但换来了绝对的可靠性。

3. 从零开始的详细部署与配置指南

纸上谈兵终觉浅，我们来一步步把它跑起来。这里我会补充很多原文档中一笔带过，但实际操作中至关重要的细节。

3.1 基础环境准备与依赖安装

首先，确保你的系统满足以下条件：

• 操作系统：Linux (推荐 Ubuntu/Debian), macOS，或 Windows (通过 WSL2 获得最佳体验)。
• Python：版本 3.10 或更高。这是必须的，因为项目可能使用了较新的语法特性。
• Chrome/Chromium：浏览器必须已安装。在终端输入google-chrome --version或chromium --version检查。

# 1. 克隆项目代码 git clone https://github.com/insung8150/AgentWebSearch-MCP.git cd AgentWebSearch-MCP # 2. 创建并激活虚拟环境（强烈推荐，避免污染系统Python） python3 -m venv venv # 在 Linux/macOS 上激活 source venv/bin/activate # 在 Windows (CMD) 上激活 venv\Scripts\activate # 3. 安装 Python 依赖 # 这里有个小坑：requirements.txt 可能不会列出所有间接依赖。 # 更稳妥的方式是使用 pip 的完整安装模式，或者手动补充。 pip install -r requirements.txt # 如果遇到某些包缺失错误，常见需要补充安装的包有： # pip install websockets aiohttp beautifulsoup4 lxml

实操心得：虚拟环境与依赖管理一定要用虚拟环境！这类项目依赖的包版本可能和你全局环境中的冲突。激活虚拟环境后，你的命令行提示符前通常会显示(venv)，这表示你正工作在隔离的环境中。项目结束后，只需deactivate即可退出。

3.2 启动与管理 Chrome 实例

这是整个项目正常工作的基石。chrome_launcher.py脚本是关键。

# 启动三个 Chrome 实例（分别对应 Naver, Google, Brave） python chrome_launcher.py start

执行这个命令后，你应该会看到三个 Chrome 浏览器窗口弹出来。不要关闭它们！它们正在监听各自的 DevTools 端口。

深入chrome_launcher.py：让我们看看它背后做了什么。它大致执行以下操作：

1. 定义三个配置，每个包含：浏览器路径、用户数据目录（/tmp/chrome-*-profile）、监听的端口号（9222, 9223, 9224）。
2. 使用subprocess.Popen启动 Chrome 进程，并传递一系列命令行参数：
   • --remote-debugging-port=9222：开启 CDP 调试端口。
   • --user-data-dir=/tmp/chrome-naver-profile：指定用户数据目录，用于保存会话。
   • --no-first-run：跳过首次运行向导。
   • --no-default-browser-check：不检查默认浏览器。
   • --disable-blink-features=AutomationControlled：重要！这个标志用于隐藏自动化控制特征，是“反反爬”的关键之一。
   • --start-maximized：窗口最大化启动。
3. 将进程 ID 保存到文件，以便后续管理。

# 检查运行状态 python chrome_launcher.py status # 预期输出会显示三个实例的 PID 和端口，以及它们是否存活。 # 停止所有实例 python chrome_launcher.py stop

注意事项：临时目录与持久化默认配置使用/tmp/下的目录，这意味着系统重启后，你的登录信息、Cookie 都会丢失。对于长期使用，强烈建议修改chrome_launcher.py中的profile_dir，将其指向一个永久路径，例如~/.config/agentwebsearch/chrome-naver-profile。这样，你只需要登录一次，后续就能一直保持会话。

3.3 登录与同步：提升搜索体验的关键步骤

虽然不登录也能用，但登录后体验提升巨大。

1. 在启动 Chrome 实例后，手动点击弹出来的 Chrome 窗口。
2. 在地址栏访问accounts.google.com并登录你的账号。
3. 登录后，Chrome 通常会提示你“开启同步功能”，点击确认。这样，你的书签、历史记录、密码等信息（如果你选择同步）就会保存在这个独立的配置文件里。

这样做的好处：

• OAuth 通行证：很多网站支持“用 Google 账号登录”。一旦这个 Chrome 实例登录了 Google，访问这些网站时就能自动完成 OAuth 授权，无需再次输入密码。
• 个性化结果：登录状态下的 Google 搜索，结果会更贴合你的历史偏好和地理位置，质量更高。
• 密码自动填充：在需要登录的搜索结果网站（如 Stack Overflow, GitHub）上，保存的密码可以自动填充，方便后续的fetch_urls操作。

3.4 配置 MCP 服务器并与 Claude Code 集成

MCP 服务器是连接你的 AI 工作流和搜索能力的桥梁。

首先，测试 MCP 服务器是否能独立运行：

# 确保 Chrome 实例已在运行 (chrome_launcher.py start) # 然后在项目根目录下运行： python mcp_server.py

如果运行后没有报错，并且程序没有退出（可能在等待输入），说明服务器启动成功。按Ctrl+C退出测试。

与 Claude Code 集成（这是最常用的场景）：Claude Code 通过编辑其配置文件来注册 MCP 服务器。

1. 找到 Claude Code 的配置目录。通常位于：

   • macOS:~/Library/Application Support/Claude/claude_desktop_config.json
   • Windows:%APPDATA%\Claude\claude_desktop_config.json
   • Linux:~/.config/Claude/claude_desktop_config.json

2. 编辑claude_desktop_config.json文件。如果文件不存在，就创建它。添加以下内容，注意将/path/to/AgentWebSearch-MCP替换为你电脑上的实际项目路径。

{ "mcpServers": { "agentwebsearch": { "command": "python", "args": ["/absolute/path/to/AgentWebSearch-MCP/mcp_server.py"], "env": { // 可以在这里传递环境变量，如果需要的话 } } } }

重要提示：使用绝对路径！在args中，必须使用完整的绝对路径（如/home/username/projects/AgentWebSearch-MCP/mcp_server.py），而不能使用相对路径（如./mcp_server.py）。这是 Claude Code 启动子进程时的要求。

3. 重启 Claude Code。完全关闭 Claude Code 应用，再重新打开。
4. 验证集成。在 Claude Code 中新建一个对话，你应该能在工具（Tools）列表中看到agentwebsearch及其提供的工具（如web_search,smart_search）。现在，你就可以在对话中直接让 Claude 使用这些工具了，例如：“请用 web_search 帮我查一下最新的 Python 3.12 特性。”

与其他 MCP 客户端集成：

• Cursor：原理类似，需要修改 Cursor 的 MCP 配置文件。
• LM Studio：在 LM Studio 的 “Local Server” 设置中，可以配置 MCP 服务器。
• OpenClaw/Moltbot：正如项目文档所述，可以使用命令行openclaw mcp add或直接编辑其配置文件~/.openclaw/config.json。

4. 核心工具详解与实战应用场景

MCP 服务器提供了多个工具，适应不同的搜索深度和智能需求。理解每个工具的特性和适用场景，能让你事半功倍。

4.1web_search：快速获取摘要

这是最基础的工具。它接受一个查询词，然后并行地在 Naver、Google、Brave 上执行搜索，从每个搜索引擎的结果页第一页提取标题、链接和简短摘要（Snippet），然后汇总返回。

典型工作流：

1. LLM 调用web_search(query="什么是量子计算？")。
2. MCP 服务器将查询同时发送给三个 CDP 搜索线程。
3. 每个线程控制其 Chrome 实例访问搜索引擎，输入关键词，等待结果加载，然后从页面 DOM 中解析出结果列表。
4. 汇总所有结果，去重排序后，返回一个结构化的 JSON 给 LLM。
5. LLM 根据这些摘要信息来组织回答。

适用场景：

• 需要快速了解一个话题的概貌。
• 查询事实性问题，答案很可能就在搜索结果的摘要里。
• 作为更深度搜索 (smart_search) 的前置步骤，用于评估哪些链接值得进一步抓取。

参数与返回：

• 输入：query(字符串，必需)。
• 输出：一个列表，包含来自不同搜索引擎的条目，每个条目有title,link,snippet,source(搜索引擎名称) 字段。

4.2smart_search：搜索与内容抓取一体化

这是我最常用的工具，也是核心价值所在。它不仅仅是搜索，还会自动跟进，抓取搜索结果中排名靠前的网页的完整正文内容。

深度（depth）参数解析：

• simple：仅执行web_search，只返回搜索结果摘要。最快，约35秒。
• medium(默认)：执行web_search后，选取每个搜索引擎的前1-2个结果（总计约5个URL），并行抓取这些网页的正文内容。返回结果包含摘要和抓取到的正文。约50秒。
• deep：执行web_search后，选取更多的结果（总计约15个URL）进行抓取。这会显著增加时间（约170秒），但信息量最大。

正文抓取是如何工作的？工具内部会调用fetch_urls能力。对于每个目标 URL，CDP 会控制浏览器导航到该页面，等待页面加载完成（包括可能的 JavaScript 渲染），然后使用启发式算法（通常是寻找最大的文本块，并过滤掉导航栏、页脚、广告等常见噪音元素）来提取页面的核心文章内容。

适用场景：

• 需要基于多篇网页内容进行综合、深度分析的任务。
• 撰写研究报告、技术博客，需要引用多个来源。
• 回答复杂问题，其答案分散在多个网页中。

实操心得：depth的选择策略不要总是用deep。对于大多数日常查询，medium深度在速度和信息量之间取得了很好的平衡。deep模式更适合学术研究或竞争分析这类需要极其全面信息的情况。另外，注意抓取的内容会消耗大量的上下文令牌（Tokens），deep模式可能返回高达 77K 的文本，你需要确保你的 LLM 上下文窗口足够大。

4.3agentcpm：让专业搜索模型来规划

这是项目的“智能增强”模式。它不直接处理你的查询，而是先把问题抛给一个专门的搜索智能体模型——AgentCPM-Explore。

工作流程：

1. 你调用agentcpm(query=“比较 TensorFlow 和 PyTorch 在边缘设备上的部署优劣”)。
2. MCP 服务器将问题发送到本地运行的 SGLang 服务器（该服务器加载了 AgentCPM-Explore 模型）。
3. AgentCPM-Explore 模型分析问题，并可能将其分解为多个子查询，例如：
   • “TensorFlow Lite 边缘部署最新特性”
   • “PyTorch Mobile 性能基准测试 2024”
   • “边缘AI框架 内存占用 对比”
4. 模型通过工具调用，指挥 MCP 服务器执行这些子查询（使用web_search或smart_search）。
5. 模型收到搜索结果后，综合信息，生成一个结构清晰、有引用的最终答案。

为什么需要它？通用 LLM（如 Claude、GPT）也能做查询规划，但 AgentCPM-Explore 是专门在搜索工具调用数据集上微调过的。它在“何时搜索”、“搜索什么关键词”、“如何综合搜索结果”这些任务上表现更专业、更稳定，能生成更多样、更相关的搜索词，特别是中英文混合的场景。

部署难点与注意事项：

• 硬件要求：AgentCPM-Explore 是一个 40 亿参数的模型，需要至少 8GB 以上的 GPU 显存才能流畅运行。纯 CPU 推理会非常慢。
• SGLang 配置：需要额外安装 SGLang 并启动服务器，这增加了部署复杂度。第一次加载模型需要较长时间。
• 备用方案：如果不想折腾 SGLang，完全可以使用smart_search工具，然后将丰富的搜索结果交给 Claude Code 本身（或其他强大的 LLM）来处理，效果也不错。agentcpm是为追求全自动、高智能搜索体验的用户准备的。

4.4 辅助工具：状态管理与控制

• get_search_status：当一个smart_search或agentcpm任务执行时间较长时，你可以调用此工具来查看进度。它会返回已完成多少百分比、已经花费的时间、以及目前已收集到的部分结果。这在调试或处理超长任务时非常有用。
• cancel_search：如果搜索耗时太久，你想中途停止，可以调用此工具。它会终止正在进行的搜索任务，并返回所有目前已获取到的结果。

5. 独立 CLI 模式与高级用法

除了作为 MCP 服务器，项目还提供了一个命令行界面search_agent.py，让你不依赖 Claude Code 也能直接使用搜索功能，并且可以灵活切换背后的 LLM。

5.1 基础 CLI 使用

# 最基本的使用：使用默认的 SGLang + AgentCPM-Explore 后端 python search_agent.py "什么是 Rust 编程语言的安全所有权模型？" # 指定搜索深度 python search_agent.py "最新的深度学习框架" --depth simple python search_agent.py "气候变化对农业的影响" --depth deep # 交互模式，可以连续提问 python search_agent.py -i # 进入交互模式后，会提示你输入问题，直到你输入 'exit' 或 'quit'。

5.2 切换不同的 LLM 后端

这是 CLI 模式的一大亮点。你可以根据自己本地部署的 LLM 来切换“大脑”。

# 查看所有支持的后端 python search_agent.py --list-backends # 输出可能包括：sglang, ollama, lmstudio, openai # 使用 Ollama 本地模型（例如 llama3.2） python search_agent.py "解释一下量子纠缠" --llm ollama --model llama3.2:latest # 你需要确保 Ollama 服务正在运行，并且拉取了对应模型。 # 使用 LM Studio 本地服务器 python search_agent.py "写一个 Python 爬虫的注意事项" --llm lmstudio --model your-model-name # 需要在 LM Studio 中启动本地服务器，并知道其 API 地址和模型名。 # 使用 OpenAI API（虽然这违背了“本地”的初衷，但有时方便） python search_agent.py "总结一下 Web3 的现状" --llm openai --model gpt-4o-mini # 需要设置环境变量 OPENAI_API_KEY。

llm_adapters目录剖析：这个目录下的每个文件都实现了一个共同的接口（base.py中定义），负责将统一的查询转换成对应 LLM API 的调用格式。

• ollama_adapter.py：调用http://localhost:11434的 Ollama API。
• lmstudio_adapter.py：调用http://localhost:1234/v1的 LM Studio 兼容 OpenAI 的 API。
• sglang_adapter.py：调用http://localhost:30001的 SGLang 服务器（用于 AgentCPM-Explore）。
• openai_adapter.py：调用官方的 OpenAI API。

你可以参考这些适配器，编写自己的适配器来支持其他 LLM 服务。

5.3 性能调优与故障排查

常见问题与解决方案：

1. Chrome 窗口启动失败或立即崩溃

   • 检查点：确保没有其他程序占用了 9222、9223、9224 端口。使用lsof -i :9222查看。
   • 解决方案：可以修改chrome_launcher.py中的端口号。或者，先运行chrome_launcher.py stop清理可能残留的旧进程。

2. 搜索速度慢

   • 网络因素：首次搜索或访问新网站需要加载资源。确保网络通畅。
   • 页面复杂度：某些搜索结果页或目标网页包含大量 JavaScript 和广告，渲染和内容提取耗时。cdp_search.py中的等待时间（如time.sleep）可以微调，但调得太短可能导致页面未加载完。
   • 硬件限制：同时运行三个 Chrome 实例对内存有一定要求（约 1.5-2GB）。如果机器内存紧张，可以考虑在chrome_launcher.py中减少启动的实例数，只保留需要的搜索引擎。

3. 内容抓取不准确（fetch_urls返回噪音）

   • 原因：正文提取算法（通常基于readability或类似库的启发式规则）对某些网站布局失效。
   • 调试：可以临时修改代码，在抓取后打印出原始 HTML 或提取的中间结果，分析是哪个环节出了问题。
   • 定制化：对于你经常抓取的特定网站，可以在cdp_search.py的提取函数中添加针对该网站的选择器规则，进行覆盖。

4. MCP 工具在 Claude Code 中不显示

   • 检查配置文件：确认claude_desktop_config.json路径和内容完全正确，特别是args中的绝对路径。
   • 检查 Python 路径：在配置中，command是python。确保在 Claude Code 启动的环境中，python命令指向的是你项目虚拟环境中的 Python（即安装了项目依赖的那个）。有时可能需要指定全路径，如/path/to/venv/bin/python。
   • 查看日志：Claude Code 通常有日志文件。在 macOS 上，可以在~/Library/Logs/Claude/找到。查看日志中是否有 MCP 服务器启动失败的错误信息。

5. AgentCPM-Explore 模型加载失败

   • 确认 SGLang 安装：pip install sglang[all]需要 CUDA 环境。确保你的 PyTorch 等深度学习库是 GPU 版本。
   • 确认模型路径：在start_sglang.sh脚本中，MODEL_PATH必须指向你从 Hugging Face 下载的模型目录。
   • 检查端口占用：SGLang 默认使用 30001 端口，确保没有被占用。

6. 扩展与定制：添加你自己的搜索门户

项目的设计是高度可扩展的。如果你需要支持百度、Bing、DuckDuckGo 或者某个特定的垂直搜索网站，可以轻松添加。

步骤：

1. 分析目标网站：手动打开该网站，进行搜索，观察其搜索 URL 的格式。例如，Google 是https://www.google.com/search?q={query}。
2. 定位结果元素：使用浏览器的开发者工具（F12），检查搜索结果列表的 HTML 结构，找到包裹每个搜索结果项的 CSS 选择器。例如，Google 的结果可能在一个div.g元素里。
3. 修改cdp_search.py：找到文件开头的PORTAL_CONFIG字典。这是一个配置映射表。
4. 添加新配置：仿照已有的naver、google、brave配置，添加一个新条目。关键字段包括：
   • name: 门户名称。
   • url_template: 搜索 URL 模板，用{query}占位。
   • container_selector: 用于等待页面加载和定位结果列表的 CSS 选择器。
   • item_selector: 单个搜索结果项的 CSS 选择器。
   • title_selector/link_selector/snippet_selector: 从单个结果项中提取标题、链接、摘要的选择器。
   • next_page_selector(可选): “下一页”按钮的选择器，用于实现翻页（当前项目未实现，但可以扩展）。

# 示例：添加 Bing 搜索（假设结构，需实际验证） PORTAL_CONFIG = { # ... 原有配置 ... "bing": { "name": "Bing", "url_template": "https://www.bing.com/search?q={query}", "container_selector": "#b_results", "item_selector": "li.b_algo", "title_selector": "h2 a", "link_selector": "h2 a", "snippet_selector": "div.b_caption p", "requires_js": False, # 根据实际情况设置 "wait_after_navigation": 2, } }

5. 更新 Chrome 启动器：在chrome_launcher.py中，为新的门户添加一个 Chrome 启动配置，指定一个新的端口（如 9225）和独立的数据目录。
6. 更新 MCP 工具：在mcp_server.py中，确保搜索函数（如parallel_search）将新的门户名称包含在搜索列表里。

完成这些步骤后，重启 Chrome 实例和 MCP 服务器，你的新搜索引擎就应该能工作了。

这个项目把“用真实浏览器为 LLM 提供搜索能力”这个想法，做成了一个稳定、可扩展、易于集成的工具。它完美解决了我在使用本地 LLM 时对实时、免 API、抗封锁搜索的需求。从最初的 Naver 搜索痛点，到现在支持多引擎、可集成到主流 AI 助手、甚至能搭配专业搜索模型，整个过程充满了 Hack 的乐趣。最大的体会是，有时候绕过复杂的技术限制，最有效的方法反而是回归最原始、最模拟真人的方式。如果你也在为本地 LLM 的搜索功能发愁，不妨试试这个方案，它可能会给你带来意想不到的顺畅体验。