三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

构建AI大模型WebBridge：打通微信读书、Kimi与企业系统的数据桥梁

发布时间：2026/8/11 2:51:05 三亩地 编程学习日记
构建AI大模型WebBridge：打通微信读书、Kimi与企业系统的数据桥梁

1. 项目概述：为AI大模型装上“眼睛”和“手”

最近在折腾AI应用开发的朋友，估计都遇到过同一个痛点：我们手里的大模型，比如GPT-4、Claude或者国内的各种大模型，虽然“能说会道”，但本质上还是个“盲人”。你问它“我微信读书里那本《三体》看到第几章了？”，或者“帮我总结一下我刚在Kimi里打开的这篇长文”，它只能一脸茫然。因为它没有权限、也没有能力去访问这些我们日常高频使用的、承载着真实信息和服务的应用。这就是所谓的“最后一公里”问题——模型能力很强，但无法落地到具体的用户场景。

这个项目，正是为了解决这个问题而生。它的核心目标，是给AI大模型接上几个关键的“真实世界入口”，让AI不仅能思考，还能“看见”和“操作”特定应用内的数据。具体来说，我实现了三个桥接器（WebBridge）：

  1. WeRead Bridge：打通微信读书。让AI可以查询你的书架、阅读进度、书籍信息，甚至进行全文检索。
  2. IMA Bridge：这是一个更具想象力的入口，我将其设计为连接内部管理系统（Internal Management Application）的通用桥梁。可以是OA、CRM、ERP等，让AI具备查询企业内部数据的能力。
  3. Kimi WebBridge：对接月之暗面的Kimi Chat。让AI能获取用户在Kimi中的对话历史、上传的文件内容，或者基于Kimi的联网搜索能力进行增强。

这不仅仅是简单的API调用包装。它涉及到对非标准接口的逆向工程、会话状态的维持、数据的安全过滤与格式化，以及如何设计一套通用的、可扩展的桥接架构。下面，我就把这一个多月从零到一的踩坑经验、技术选型和核心实现细节，毫无保留地分享出来。无论你是想自己动手搭建类似的工具，还是想深入理解如何让AI与现有系统集成，这篇文章都会给你带来实实在在的参考。

2. 核心架构设计与技术选型

2.1 为什么是“桥接器”（WebBridge）模式？

在项目初期，我评估了几种常见的集成方案：

  • 直接调用官方API：最理想，但微信读书没有开放个人书籍数据的API，Kimi的API也有限制。此路不通。
  • 浏览器自动化（如Puppeteer, Playwright）：可以模拟用户操作，获取任何可见内容。但缺点极其明显：性能差（要启动完整浏览器）、资源消耗大、不稳定（页面结构一变就失效），且无法后台静默运行。
  • 逆向工程移动端App：复杂度更高，需要处理加密协议，维护成本巨大。

因此，我选择了“桥接器”模式。它的核心思想是：在一个受控的本地或中间服务器环境中，运行一个轻量级的服务。这个服务充当“翻译官”和“代理”，它使用合法身份（如Cookie）模拟用户访问目标Web应用，解析其网络请求和数据，然后将结构化的数据通过一个标准的API（如OpenAI Plugin格式或自定义API）暴露给AI大模型。

这种模式的优势在于：

  1. 对目标应用友好：行为与真实用户浏览器访问无异，不易被风控。
  2. 高效轻量：无需渲染整个UI，只关心数据接口，资源占用极小。
  3. 可控性强：可以在桥接器内部对数据进行清洗、脱敏、格式化，再提供给AI，避免AI看到无关的广告或HTML标签。
  4. 标准化输出：向AI侧提供统一、干净的JSON数据，大大降低了AI理解数据的难度。

2.2 技术栈的抉择：Node.js + Puppeteer Core + Fastify

我选择了Node.js作为主力技术栈，原因如下：

  • 异步友好：处理大量网络I/O（请求网页、调用接口）是核心操作，Node.js的异步非阻塞模型天生适合。
  • 生态丰富：有Puppeteer、Playwright这样的顶级浏览器自动化库，也有各种HTTP请求库（如axios、got）。
  • 快速原型：JavaScript/TypeScript编写业务逻辑速度非常快。

具体到库的选择：

  • puppeteer-core而非puppeteer：这是关键细节。puppeteer会默认下载一个完整的Chromium浏览器，体积庞大（300MB+）。而puppeteer-core是一个轻量版，它允许你连接到一个已有的、或远程的Chrome实例。在我们的场景下，可以在服务器上单独安装一个Chrome，然后所有桥接器服务都通过puppeteer-core连接到它，实现资源共享，节省了大量磁盘空间和内存。
  • fastify作为Web框架：我们需要暴露HTTP API给AI调用。Fastify相比Express，性能更高（底层基于http模块优化），对JSON Schema的原生支持非常好，这对于定义清晰的API输入输出格式、自动生成文档和验证请求非常有帮助。
  • redis用于会话管理：用户登录目标应用（如微信读书）后，产生的Cookie或Token需要持久化，以便下次请求时无需重复登录。Redis非常适合存储这种有过期时间的会话数据，并且能支持多个桥接器实例共享会话状态。

注意：使用puppeteer-core时，你需要确保运行环境有一个可用的Chrome或Chromium。在Docker部署时，通常使用selenium/standalone-chrome这样的镜像作为独立服务。

2.3 安全与伦理考量：必须坚守的底线

在开发这类“桥接”工具时，安全与合规是生命线，必须从一开始就设计进去。

  1. 用户授权先行：任何桥接器在访问用户数据前，必须获得用户的明确授权。例如，需要用户手动在微信读书网页版登录，并将浏览器中的Cookie通过我们提供的安全方式导入到桥接器中。我们绝不存储、也不应询问用户的账号密码。
  2. 数据最小化原则：桥接器只获取完成AI指令所必需的最少数据。例如，当AI问“我最近在看什么书？”，桥接器只返回书名、作者和阅读进度，而不是获取所有书籍的全文内容。
  3. 本地化优先部署：建议将桥接器部署在用户自己的电脑或内网服务器上，确保敏感数据（如Cookie、书籍列表）不流出个人可控的环境。我们的代码设计应支持一键本地部署。
  4. 清晰的免责声明：在项目文档和交互界面中，需要明确告知用户：此工具为个人学习项目，使用需遵守目标平台的服务条款，开发者不对因使用此工具导致的账号问题负责。

3. 三大入口的实战拆解与核心实现

3.1 WeRead Bridge：逆向微信读书的“书架”

微信读书的网页版（r.qq.com）没有公开的API，但其数据是通过标准的XHR/Fetch请求加载的，这给了我们突破口。

核心实现步骤：

  1. 登录态获取与维持：

    • 引导用户打开微信读书网页版并登录。
    • 用户使用浏览器开发者工具（F12），在“网络”(Network)选项卡中，找到一个获取书籍列表的请求（通常包含bookshelf字样），将其中的Cookie请求头复制出来。
    • 桥接器提供一个安全的配置界面（或通过环境变量），让用户填入这个Cookie字符串。
    • 桥接器启动时，会将这些Cookie设置到puppeteer-core启动的浏览器上下文中，或者直接在axios等HTTP库的请求头中携带。

  2. 数据抓取与解析：

    • 监听网络请求：使用Puppeteer的page.on('response')事件监听器，拦截所有XHR请求。当发现URL模式匹配*bookshelf*或*bookinfo*时，获取其响应内容。
    • 解析JSON数据：微信读书的响应通常是JSONP或纯JSON。我们需要提取核心字段，如bookId,title,author,coverUrl,progress（阅读进度）,format（格式）等。
    • 模拟翻页：书架数据是分页加载的。需要分析“加载更多”的请求参数（通常是start和limit），然后循环发起请求，直到获取全部书籍。

  3. 暴露标准化API：

    • 设计一个RESTful端点，例如GET /weread/bookshelf。
    • 该端点内部调用上述抓取逻辑，返回一个结构化的JSON数组。
    • 为了提升体验，可以加入缓存机制（如Redis缓存书架数据5分钟），避免每次AI询问都去实时抓取，减少对目标服务器的压力和自己账号的风险。
// 伪代码示例：Fastify路由处理函数 fastify.get('/weread/bookshelf', async (request, reply) => { // 1. 从Redis或配置中获取用户Cookie const userCookie = await redis.get(`user:${userId}:weread_cookie`); if (!userCookie) { throw new Error('未找到微信读书登录态，请先配置Cookie'); } // 2. 使用带Cookie的HTTP客户端获取数据（这里简化，实际可能需用Puppeteer） const apiUrl = 'https://i.weread.qq.com/user/books'; const response = await axios.get(apiUrl, { headers: { 'Cookie': userCookie }, params: { count: 200 } // 假设一次获取200本 }); // 3. 解析并格式化数据 const books = response.data.books.map(book => ({ id: book.bookId, title: book.title, author: book.author, cover: book.coverUrl, progress: `${book.progress}%`, lastReadTime: new Date(book.lastReadTime * 1000).toLocaleString() })); // 4. 返回给AI return { books, total: books.length }; });

实操心得：

  • Cookie会过期：微信读书的Cookie有效期可能只有几天或几周。最佳实践是设计一个“刷新”机制，当发现请求返回401或数据为空时，通知用户重新获取Cookie。
  • 频率限制：抓取请求不要太频繁，模拟真人操作间隔，比如每次请求间隔1-2秒，避免触发微信读书的反爬机制。
  • 错误处理要细致：网络超时、JSON解析失败、Cookie失效等错误情况必须妥善处理，并给AI返回明确的错误信息，而不是让AI面对一堆乱码。

3.2 IMA Bridge：通向企业数据的通用管道

IMA（Internal Management Application）桥接器的设计更具挑战性，因为目标系统千差万别。我们的目标是设计一个可配置、可扩展的通用框架。

核心设计思路：

  1. 配置驱动：用一个配置文件（如ima-config.yaml）来定义如何连接一个内部系统。
  2. 认证抽象层：支持多种认证方式（Cookie、JWT、OAuth2.0、Basic Auth、API Key）。
  3. 数据连接器：支持多种数据获取方式（直接调用Restful API、解析HTML页面、连接数据库【需极端谨慎】）。
  4. 查询翻译器：将AI的自然语言查询（如“张三上个月的销售额是多少？”）翻译成目标系统能理解的参数（如{employee: “张三”, month: “2023-10”, metric: “sales”}）。

一个简化的配置示例：

# ima-config.yaml connections: - name: "内部CRM系统" type: "rest_api" baseUrl: "https://crm.internal.com/api/v1" auth: type: "bearer_token" token: "${env:CRM_TOKEN}" # 从环境变量读取 endpoints: - name: "查询销售记录" path: "/sales" method: "GET" description: "根据员工姓名和月份查询销售额" # 定义如何将AI的查询参数映射到API参数 parameterMapping: ai_param_employee: "staffName" ai_param_month: "queryMonth" responseMapping: # 定义如何将API返回的复杂JSON映射为给AI的简洁描述 - from: "data.list[].amount" to: "salesAmount"

实现难点与解决方案：

  • 动态查询翻译：这是最复杂的部分。我们可以利用大模型自身的能力！当AI收到用户问题“帮我查一下张三的销售额”时，IMA Bridge可以将问题连同可用的endpoints描述一起，发送给一个大模型（比如GPT-3.5），让大模型“思考”并输出应该调用哪个endpoint，以及参数是什么。这相当于让大模型自己学会了使用我们的“工具”。
  • 数据安全与脱敏：企业数据极其敏感。必须在桥接器层实现严格的字段过滤和脱敏规则。例如，在responseMapping中，可以配置mask: true对手机号、身份证号等字段进行部分隐藏（138****1234）。

3.3 Kimi WebBridge：与长上下文助手的联动

Kimi Chat本身就是一个强大的AI工具，拥有长上下文和联网搜索能力。Kimi WebBridge的目标不是替代Kimi，而是将Kimi作为一个“信息源”或“处理器”集成到更大的AI工作流中。

主要实现功能：

  1. 对话历史获取：通过模拟用户访问Kimi网页版，获取最近的对话列表和内容。这需要处理Kimi的页面身份验证（可能也是Cookie或Token）。
  2. 文件内容提取：如果用户在Kimi中上传了文件（PDF、Word、TXT），桥接器可以尝试获取该文件在Kimi服务器上的临时链接（如果可访问），或者至少获取Kimi解析后的文本摘要。
  3. 指令透传：设计一个机制，让主AI（例如你在用的ChatGPT）可以将一个复杂问题“委托”给Kimi处理。例如，主AI收到指令“请分析一下最近关于半导体行业的三篇权威报道，并总结趋势”。主AI可以调用Kimi Bridge，指令为：“请在Kimi中开启联网搜索，搜索‘半导体行业 2024 趋势 权威报道’，阅读前三篇结果，并总结核心观点”。然后Kimi Bridge将Kimi返回的结果再传递给主AI进行最终整合。

技术实现注意点：

  • Kimi的接口可能变动：与微信读书类似，Kimi的网页接口没有公开文档，且可能频繁更新。代码需要有一定的容错性，关键元素选择器（CSS Selector）最好做成可配置的。
  • 处理流式输出：Kimi的回复是流式的（一个字一个字出现）。我们的桥接器需要能够捕获这种流式响应，并将其整合成完整文本，再返回给主AI。这需要用到Puppeteer监听页面DOM的实时变化。
  • 避免滥用：明确告知用户，此桥接器应合理使用，避免向Kimi发送大量自动化请求，这可能违反Kimi的使用条款。

4. 桥接器的部署、集成与调优

4.1 本地化部署方案

为了让用户用得放心，我强烈推荐并设计了本地一键部署方案。

使用Docker Compose：

# docker-compose.yml version: '3.8' services: chrome: image: selenium/standalone-chrome:latest shm_size: 2gb ports: - "4444:4444" networks: - ai-bridge-net redis: image: redis:7-alpine ports: - "6379:6379" volumes: - redis_data:/data networks: - ai-bridge-net web-bridge: build: . ports: - "3000:3000" environment: - CHROME_WS_URL=ws://chrome:4444 - REDIS_URL=redis://redis:6379 - NODE_ENV=production volumes: - ./config:/app/config # 挂载配置文件目录 depends_on: - chrome - redis networks: - ai-bridge-net volumes: redis_data: networks: ai-bridge-net:

用户只需要安装Docker和Docker Compose，然后docker-compose up -d，三个服务（Chrome浏览器、Redis缓存、桥接器主程序）就会自动运行。桥接器的服务地址是http://localhost:3000。

配置管理：通过挂载./config目录，用户可以在宿主机上方便地编辑config.yaml文件，填入各自的Cookie等敏感信息，而无需修改容器内的代码。

4.2 与AI平台的集成：OpenAI Plugin 与 Function Calling

如何让ChatGPT这样的AI知道并使用我们的桥接器？有两种主流方式：

  1. OpenAI Plugin标准：这是OpenAI推出的官方方案。你需要提供一个ai-plugin.json文件（描述插件元数据）和openapi.yaml文件（描述API接口）。ChatGPT Plus用户可以在插件商店安装。但对于我们这种本地服务，需要解决复杂的网络暴露（localhost如何让OpenAI访问）和认证问题，对普通用户门槛较高。

  2. Function Calling（函数调用）：这是更通用、更推荐的方式。几乎所有主流大模型（OpenAI GPT, Claude, 国内深言、智谱等）都支持。其流程是：

    • 定义“工具”：在调用大模型的API时，在请求体中附带一个tools参数，描述你的桥接器有哪些功能（对应哪个API端点，需要什么参数）。
    • 模型决策：大模型根据用户问题，判断是否需要调用你的工具。如果需要，它会在回复中返回一个特殊的结构，指明要调用哪个函数，以及参数是什么。
    • 执行并返回：你的程序收到这个调用请求后，去执行对应的桥接器API，拿到结果。
    • 再次请求模型：将工具执行的结果作为新的上下文，再次发送给大模型，让它基于这个结果生成最终的回答给用户。
// 伪代码：使用OpenAI API的Function Calling const messages = [{ role: 'user', content: '我微信读书里有哪些未读完的书？' }]; const tools = [{ type: 'function', function: { name: 'getWereadBookshelf', description: '获取用户在微信读书书架上的书籍列表及其阅读进度', parameters: { /* JSON Schema 定义参数 */ } } }]; // 第一次请求，让AI决定是否调用 const firstResponse = await openai.chat.completions.create({ model: 'gpt-4', messages, tools, tool_choice: 'auto', }); const toolCall = firstResponse.choices[0].message.tool_calls[0]; if (toolCall.function.name === 'getWereadBookshelf') { // 执行我们的桥接器API const bookshelfData = await fetch('http://localhost:3000/weread/bookshelf').then(r => r.json()); // 将结果附加到对话中，进行第二次请求 messages.push(firstResponse.choices[0].message); // 添加AI的回复（包含工具调用） messages.push({ role: 'tool', tool_call_id: toolCall.id, content: JSON.stringify(bookshelfData), // 工具执行结果 }); const finalResponse = await openai.chat.completions.create({ model: 'gpt-4', messages, }); // finalResponse就是AI根据真实书籍数据生成的最终回答 console.log(finalResponse.choices[0].message.content); }

4.3 性能优化与稳定性保障

  1. 连接池与复用：对于Puppeteer，不要为每个请求都启动一个新的浏览器实例。应该创建一个浏览器连接池，长时间保持几个实例待命，处理完请求后归还到池中，避免频繁的启动销毁开销。
  2. 分级缓存策略：
    • 内存缓存（短时）：对于变化不频繁的数据，如用户书架列表，缓存5-10分钟。
    • Redis缓存（中长时）：对于用户登录态（Cookie），缓存时间可以设置得长一些（如1天），并在每次成功使用后刷新过期时间。
  3. 请求重试与降级：网络请求可能失败。对于非关键请求，实现指数退避重试机制。如果桥接器完全不可用，应有一个友好的降级方案，例如告诉AI“暂时无法访问您的书架，请检查桥接器服务是否运行”。
  4. 健康检查与监控：为桥接器服务添加/health端点，返回服务状态、Chrome连接状态等。使用PM2或Kubernetes的探针进行健康检查，确保服务异常时能自动重启。

5. 常见问题排查与实战心得

在实际开发和测试中，我遇到了不少坑，这里总结出来，希望能帮你节省时间。

5.1 登录态失效与刷新

问题：用户配置的Cookie几天后就失效了，桥接器无法获取数据。排查：

  1. 首先检查请求返回的HTTP状态码，如果是401/403，基本就是认证失败。
  2. 检查响应内容，看是否有“未登录”或“请重新登录”等关键字。解决：
  • 主动通知：在桥接器API返回错误时，给出明确的提示：“微信读书登录已过期，请重新获取Cookie并更新配置”。
  • 设计刷新流程：对于支持OAuth2.0的系统（如某些企业应用），可以实现自动刷新Token的逻辑。但对于Cookie，目前仍需手动操作。

5.2 目标网站改版导致解析失败

问题：昨天还能用，今天微信读书的页面结构或接口变了，数据抓不到了。排查：

  1. 使用Puppeteer的page.screenshot()功能对页面截图，看看渲染是否正常。
  2. 使用page.on('request')和page.on('response')监听网络活动，对比之前能正常工作的请求URL和参数是否有变化。解决：
  • 关键选择器/接口URL配置化：不要将CSS选择器或API URL硬编码在代码里。将它们提取到外部配置文件中。这样当网站改版时，你只需要更新配置文件，而无需重新部署代码。
  • 增加日志与告警：记录每次抓取的关键步骤和结果。当连续多次抓取失败或返回空数据时，触发告警（如发送邮件到自己的邮箱），提醒你及时检查。

5.3 AI无法正确理解或调用工具

问题：给AI描述了工具，但AI要么不调用，要么调用时参数传错了。排查：

  1. 检查tools参数中的description和parameters的JSON Schema是否描述得足够清晰、无歧义。AI完全依赖这段描述来理解工具。
  2. 查看AI返回的tool_calls对象，确认它想调用的函数名和参数是否与你期望的一致。解决：
  • 优化工具描述：description要简洁准确地说明工具是干什么的。parameters的每个属性都要写清楚description。例如，month参数可以描述为“格式为YYYY-MM的月份字符串，例如2024-01”。
  • 提供少量示例（Few-Shot）：在系统提示词（System Prompt）中，可以给AI一两个用户问题对应工具调用的例子，这能极大地提升AI使用工具的准确性。

5.4 隐私与数据安全顾虑

问题：用户担心Cookie配置在本地服务中是否安全。解决：

  • 开源透明：将项目代码完全开源，让用户审查代码，确认没有数据上传行为。
  • 文档明确：在README中详细说明数据流向：Cookie仅存储在用户本地的Redis或配置文件中，仅用于向目标网站发起用户授权的请求，所有数据处理都在用户本地完成。
  • 提供“只读”模式：在配置中明确，本桥接器所有功能均为“只读”，不会执行任何修改、购买、删除等写操作，进一步降低用户风险感知。

这个项目从构思到实现，让我深刻体会到，让AI真正变得有用，关键不在于模型本身有多强大，而在于如何让它安全、可靠地连接到我们真实的工作和生活流中。这三个“桥接器”只是一个开始，这套模式可以扩展到任何有网页前端的服务。

编程学习 学习日记 实战经验
← 返回列表