1. 项目概述与核心价值最近在折腾一些AI应用的时候发现一个挺有意思的需求能不能让New Bing现在叫Copilot这类AI助手摆脱地域和浏览器的限制在任何地方都能方便地调用这听起来像是个“伪需求”毕竟官方应用和网页版已经很成熟了。但当你真正深入一些开发场景、自动化流程或者只是想在一个更纯净、更可控的环境里集成AI能力时这个需求就变得非常真实了。ha0z1/New-Bing-Anywhere这个项目正是瞄准了这个痛点。它不是一个简单的网页封装而是一个旨在将New Bing/Copilot的核心对话能力通过API等形式暴露出来的工具。简单来说它的目标是把一个需要通过特定浏览器、特定网络环境访问的Web服务变成一个可以像调用本地函数一样使用的“服务”。这对于开发者、对于想要构建个性化AI工作流的朋友来说价值巨大。想象一下你可以直接在命令行里问AI问题可以在你的笔记软件里一键调用AI总结甚至可以让你的智能家居在特定条件下向AI寻求建议——这一切的前提就是有一个稳定、可编程的接口。这个项目的核心价值在于“解耦”和“赋能”。它将AI能力从具体的应用界面中剥离出来变成了一个可组合的“积木”。无论你是想研究AI对话的原理还是想开发一个集成AI功能的第三方应用或者只是想摆脱浏览器在终端里更高效地和AI交互这个项目都提供了一个可能的起点。当然这条路并不好走需要处理反爬机制、模拟用户行为、维持会话状态等一系列复杂问题这也正是我们接下来要深入拆解的内容。2. 核心思路与技术架构拆解要实现“Anywhere”的目标项目的技术架构必然要解决几个核心矛盾如何模拟一个真实用户与New Bing网页端的交互如何维持会话状态尤其是那种多轮对话的上下文如何将网页的流式响应就是那种一个字一个字蹦出来的效果转换成API友好的数据流以及如何应对服务端可能存在的访问频率限制和反自动化检测2.1 逆向工程与协议模拟这是整个项目的基石。New Bing的网页端不是一个简单的HTTP接口它背后有复杂的认证流程、WebSocket连接用于接收流式消息、以及一系列用于维持会话和上下文的请求。New-Bing-Anywhere需要做的第一件事就是通过浏览器开发者工具仔细抓取和分析从打开网页到完成一次对话的全链路网络请求。这个过程通常包括登录态获取分析Cookie、LocalStorage或SessionStorage中哪些是关键令牌如_Ucookie。项目可能需要提供一种方式让用户注入这些凭据或者模拟登录流程后者难度和风险极高通常不推荐。对话初始化找到创建新对话或连接现有对话的API端点。这个请求往往包含了模型参数、对话风格创意、平衡、精确等设置。流式通信核心中的核心。New Bing的回复是服务器推送的通常通过Server-Sent Events (SSE) 或 WebSocket 实现。项目需要能够建立并监听这个流式连接将接收到的事件如“部分内容更新”、“引用添加”、“对话结束”实时地解析并转发给API调用者。上下文管理多轮对话时需要将历史消息ID或上下文标识符在请求中传递以维持对话的连贯性。注意直接对生产环境的网页进行逆向工程存在法律和道德风险且接口可能随时变更。此类项目通常声明为“仅供学习和研究用途”并强烈依赖社区维护来跟进官方的改动。2.2 服务层封装与API设计在成功模拟底层通信协议后下一步就是构建一个易于使用的服务层。一个良好的架构会将底层的网络请求、流式解析、错误处理等脏活累活封装起来向上暴露简洁清晰的编程接口。典型的API设计会包括POST /chat/completions仿照OpenAI API格式接收用户消息、对话历史、选择模型风格返回一个流式响应或一次性完整响应。WebSocket连接为需要真正实时交互的客户端提供双向通信通道。会话管理接口允许创建、查询、删除独立的对话会话实现多用户或多线程隔离。在这一层项目需要处理诸如请求排队避免触发频率限制、自动重试应对网络波动或临时错误、响应格式化将New Bing特有的回复格式如包含引用链接的[1]标记转换为通用格式等工程问题。2.3 部署与运行环境为了让服务“Anywhere”部署方式必须灵活。一个成熟的项目通常会提供多种部署选项本地运行作为命令行工具或本地HTTP服务供开发者快速测试和集成。容器化部署提供Docker镜像可以一键部署到任何支持Docker的环境包括个人服务器、云服务器或NAS。云函数/Serverless适配云平台的无服务器函数按需调用成本低。但这通常需要项目代码有良好的无状态设计或者将会话状态存储到外部数据库。浏览器扩展另一种思路不是提供后端API而是通过浏览器扩展注入脚本直接增强网页本身的功能比如添加自定义快捷键、导出对话历史等。但这与“Anywhere”的初衷略有不同更侧重于增强原有体验。New-Bing-Anywhere很可能采用了Node.js或Python作为后端语言因为它们拥有丰富的网络请求和Web框架生态非常适合做这类爬取和封装的工作。3. 关键实现细节与实操要点理解了宏观架构我们深入到代码层面看看几个最关键的部分是如何实现的以及实操中会遇到哪些“坑”。3.1 会话保持与Cookie管理这是项目稳定性的生命线。没有有效的登录态一切无从谈起。实现方式手动注入最常见也是最推荐的方式。项目会要求用户在配置文件或环境变量中提供从浏览器中复制出来的关键Cookie尤其是_U。项目代码会将这些Cookie附加到后续的所有请求头中。# 示例在环境变量中设置 export BING_COOKIES_U你的很长一串cookie值; other_cookievalue配置文件在config.json或config.yaml中设置。{ credentials: { cookies: _U... } }自动化获取高风险有些项目尝试通过无头浏览器如Puppeteer, Playwright自动登录并获取Cookie。这违反了服务条款极易被检测和封禁且需要处理验证码不推荐在生产环境使用。实操要点与避坑Cookie过期Cookie会过期。你需要定期比如每周从浏览器重新获取一次。在代码中最好加入Cookie失效的检测逻辑当收到401或403错误时能给出明确的提示而不是返回难以理解的“服务器错误”。Cookie隔离如果你部署的服务要给多人使用必须实现会话隔离。不能所有人共享一套Cookie。简单的做法是为每个用户或每个对话会话分配独立的Cookie池或者更安全地引导每个用户使用自己的账户凭据。安全存储Cookie是敏感信息绝不能明文写在代码或日志里。务必使用环境变量或安全的密钥管理服务。3.2 流式响应Server-Sent Events的处理New Bing网页端使用SSE来推送AI的思考过程和回复。处理SSE是项目实现“打字机效果”和实时性的关键。实现方式发起请求向特定的对话端点发送一个POST请求其中包含消息和参数并设置请求头Accept: text/event-stream。监听事件流服务器返回的响应体是一个持续开放的流。你需要逐行读取。SSE的数据格式是event: event_name data: {key: value}空行表示一个事件块的结束。解析事件常见的事件类型包括update部分内容更新data里包含新增的文本。done回复完成。error发生错误。citation添加了一个引用。实时转发每收到一个update事件就解析出新的文本片段通过你提供的API如WebSocket或HTTP流立即发送给客户端。代码示例Node.js伪代码async function streamChatCompletion(message) { const response await fetch(BING_CHAT_ENDPOINT, { method: POST, headers: { Cookie: cookies, Accept: text/event-stream }, body: JSON.stringify({ message }) }); const reader response.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value); const lines chunk.split(\n); for (const line of lines) { if (line.startsWith(data: )) { const eventData JSON.parse(line.slice(6)); // 处理 eventData例如eventData.type, eventData.text // 将 eventData.text 的增量部分发送给客户端 ws.send(JSON.stringify({ delta: eventData.text })); } } } }实操要点与避坑连接超时与重连网络不稳定时SSE连接可能中断。客户端和服务端都需要有重连机制。服务端在向客户端转发时如果连接断开应能缓冲或丢弃后续数据并记录错误。数据拼接SSE的data行可能被分到多个TCP包中解析时要注意跨chunk的数据拼接确保拿到完整的JSON字符串再解析否则会报错。心跳机制长时间没有数据连接可能被代理或服务器关闭。服务器可以定期发送冒号开头的注释行如:keepalive\n\n作为心跳。3.3 请求频率限制与队列管理为了避免被New Bing的服务端视为攻击而封禁IP或账号必须实施严格的频率限制。实现策略令牌桶算法这是控制平均速率的最佳实践。例如设定每分钟最多发送10个请求包括创建对话和发送消息。维护一个令牌桶以固定速率如每6秒一个添加令牌桶有最大容量。每个请求消耗一个令牌如果桶空则请求必须等待。请求队列当并发请求超过当前可用令牌时将请求放入队列按顺序处理。这保证了服务的公平性和稳定性避免了突发流量导致的集体失败。用户级限流如果支持多用户应为每个用户或每个Cookie实施独立的限流策略防止单个用户行为影响全体。实操要点参数可配置将限流参数如RATE_LIMIT_REQUESTS_PER_MINUTE做成配置项方便根据实际情况调整。初期可以设置得保守一些。优雅降级与反馈当请求被限流排队时应向API调用者返回明确的等待状态如HTTP 429 Too Many Requests并可以提示预计等待时间而不是直接拒绝或超时。监控与告警记录被限流的请求数量如果长期处于高水位可能意味着需要扩容增加Cookie池或优化请求模式。4. 部署实践与配置详解理论说再多不如动手部署一遍。我们以最常见的Docker部署方式为例走通一个完整的流程。4.1 环境准备与配置假设项目代码托管在GitHub并且提供了Dockerfile。获取Cookie在浏览器中登录https://bing.com/chat。打开开发者工具F12切换到Application或存储标签页。在Cookies下找到https://www.bing.com复制_U这个Cookie的值。它的值很长是一串看起来像乱码的字符。这是你的通行证请妥善保管不要泄露。克隆项目与配置git clone https://github.com/ha0z1/New-Bing-Anywhere.git cd New-Bing-Anywhere查找项目中的配置文件通常是config.yaml.example或.env.example。复制一份并重命名如config.yaml或.env。编辑配置文件填入你的Cookie。配置项可能叫BING_COOKIES或cookies。# config.yaml 示例 server: port: 3000 bing: cookies: _U你的很长一串cookie值 style: balanced # creative, balanced, precise rate_limit: requests_per_minute: 104.2 Docker构建与运行如果项目根目录有Dockerfile可以按以下步骤操作。构建Docker镜像docker build -t new-bing-anywhere .这个过程会安装项目依赖。如果网络不好可能需要配置镜像加速。运行容器docker run -d \ --name bing-api \ -p 3000:3000 \ # 将容器内3000端口映射到宿主机3000端口 -v $(pwd)/config.yaml:/app/config.yaml \ # 挂载配置文件 new-bing-anywhere-d表示后台运行。-v挂载卷让你可以在宿主机修改配置而无需重建镜像。使用Docker Compose更推荐 如果项目提供了docker-compose.yml部署会更简单。# 编辑 docker-compose.yml确保配置路径正确 version: 3 services: new-bing-anywhere: build: . container_name: bing-api ports: - 3000:3000 volumes: - ./config.yaml:/app/config.yaml restart: unless-stopped # 容器退出时自动重启然后一键启动docker-compose up -d4.3 服务验证与基础测试容器运行起来后如何知道它工作正常查看日志docker logs -f bing-api观察启动日志看是否有报错如Cookie无效、网络连接失败。健康检查 很多项目会提供一个/health或/端点。用curl测试一下curl http://localhost:3000/health如果返回OK或类似信息说明服务进程正常。发起一次测试对话 使用curl或 Postman 调用聊天接口。curl -X POST http://localhost:3000/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 你好请介绍一下你自己。}], stream: false, // 先测试非流式 model: gpt-4 // 这里可能是一个映射具体看项目API定义 }如果返回了JSON格式的AI回复恭喜你部署成功了测试流式接口 对于流式接口curl可能不太直观。你可以使用一个能处理流式响应的客户端或者写一段简单的Python/Node.js脚本。以下是Python使用requests库的简单示例import requests import json url http://localhost:3000/v1/chat/completions headers {Content-Type: application/json} data { messages: [{role: user, content: 写一首关于春天的诗}], stream: True } response requests.post(url, headersheaders, jsondata, streamTrue) for line in response.iter_lines(): if line: decoded_line line.decode(utf-8) if decoded_line.startswith(data: ): # 注意有些实现可能直接返回JSON行没有“data: ”前缀 event_data decoded_line[6:] if event_data ! [DONE]: try: json_data json.loads(event_data) # 打印回复的增量内容 if choices in json_data and len(json_data[choices]) 0: delta json_data[choices][0].get(delta, {}) if content in delta: print(delta[content], end, flushTrue) except json.JSONDecodeError: print(f解析失败的行: {event_data}) print() # 最后换行运行这个脚本你应该能看到诗句被逐字打印出来。5. 高级集成与应用场景部署好服务只是第一步如何把它用起来集成到你的工作流中才是发挥其价值的关键。5.1 与现有开发工具集成命令行工具 (CLI) 你可以将API封装成一个命令行工具。例如创建一个bingchat脚本#!/bin/bash # bingchat 脚本示例 QUESTION$* curl -s -X POST http://localhost:3000/v1/chat/completions \ -H Content-Type: application/json \ -d {\messages\: [{\role\: \user\, \content\: \$QUESTION\}], \stream\: false} \ | jq -r .choices[0].message.content然后就可以在终端里直接bingchat 如何修复这个bash脚本的错误。代码编辑器插件 为VS Code、Vim/Neovim等编辑器开发插件。例如在VS Code中你可以选中一段代码右键选择“用New Bing解释”插件会将代码和指令发送给你的本地API并把结果插入到注释或新文件中。这需要一些编辑器扩展开发的知识但核心就是调用HTTP API。自动化脚本 (Python/Node.js) 这是最强大的集成方式。你可以写一个脚本自动处理文件、调用AI、并根据结果执行操作。# 示例批量总结日志文件中的错误 import os import requests from pathlib import Path API_URL http://localhost:3000/v1/chat/completions def summarize_errors(log_file_path): with open(log_file_path, r) as f: log_content f.read()[:3000] # 限制长度 prompt f请分析以下日志片段列出所有错误类型及其可能的原因\n\n{log_content} response requests.post(API_URL, json{ messages: [{role: user, content: prompt}], stream: False }) summary response.json()[choices][0][message][content] # 将总结写入新文件 summary_path log_file_path.with_suffix(.summary.txt) with open(summary_path, w) as f: f.write(summary) print(f总结已保存至: {summary_path}) # 遍历日志目录 log_dir Path(./logs) for log_file in log_dir.glob(*.log): summarize_errors(log_file)5.2 构建个性化AI应用有了这个API你几乎可以构建任何你想要的AI小应用。智能邮件/消息助手 连接你的邮箱或即时通讯工具如Slack、钉钉的机器人让AI帮你起草回复、总结长邮件、甚至根据邮件内容判断优先级并创建待办事项。知识库问答机器人 将你的公司文档、个人笔记向量化存储。当用户提问时先通过向量搜索找到相关文档片段然后将“片段问题”一起发给New Bing API让它生成基于你私有知识的精准回答。这就是一个简易版的私有化ChatGPT。创意写作与内容生成 结合模板和变量批量生成社交媒体文案、产品描述、博客大纲等。你可以设定不同的“风格”参数创意/平衡/精确来获得不同调性的内容。5.3 性能优化与高可用考量当从个人使用转向团队或轻度生产环境时需要考虑更多。多Cookie池与负载均衡 单个Cookie有请求频率限制。要提升整体吞吐量可以维护一个Cookie池从池中轮询或按策略选择Cookie来发起请求。这需要在服务层实现一个简单的负载均衡器。# config.yaml 进阶配置 bing: cookie_pool: - _Ucookie1... - _Ucookie2... - _Ucookie3... selection_strategy: round_robin # 或 least_used同时需要监控每个Cookie的健康状态是否失效、是否被限流自动从池中剔除故障项。缓存策略 对于一些常见的、结果不变的查询例如“Python的创始人是谁”可以引入缓存如Redis。在向Bing API发起请求前先检查缓存。这能显著减少不必要的请求提升响应速度并节约配额。注意缓存AI的创造性回答要谨慎避免返回过时或不准确的答案。最好只为事实性、确定性高的问题设置缓存并设置较短的过期时间。异步处理与队列 对于非实时性要求很高的任务如批量处理文档可以采用“请求-响应-回调”的异步模式。用户提交任务后立即返回一个任务ID服务端将任务放入队列如RabbitMQ, Redis Queue异步处理处理完成后通过Webhook或让用户轮询结果。这能避免HTTP请求超时提升系统吞吐能力。6. 常见问题、故障排查与维护心得在实际运行中你一定会遇到各种各样的问题。这里记录一些典型场景和解决思路。6.1 典型错误与解决方案速查表问题现象可能原因排查步骤与解决方案启动服务后调用API返回401 Unauthorized或403 Forbidden1. Cookie已过期或无效。2. Cookie格式错误可能缺少了必要的字段或分号。3. 请求头中Cookie设置不正确。1.重新获取Cookie在浏览器中确认能正常访问bing.com/chat然后重新复制_U值。2.检查格式确保Cookie字符串是完整的如_Uxxx; MUIDyyy;。可以直接从浏览器开发者工具复制整个Cookie字符串而不是手动拼接。3.查看服务日志确认服务启动时是否正确加载了配置的Cookie。流式响应中断连接提前关闭1. 网络不稳定或代理问题。2. 服务端Bing主动断开连接可能因为内容策略、频率限制。3. 客户端读取超时。1.检查网络在服务器上curl测试其他网站确保网络连通。2.查看完整日志关注服务日志中Bing返回的错误信息。可能是回复内容触发了安全策略。3.调整超时设置在客户端和服务端配置更长的读写超时时间。对于服务端确保在转发SSE流时HTTP连接保持活动状态。响应速度极慢或长时间无响应1. 请求被Bing端排队或限流。2. 本地服务或网络存在瓶颈。3. 对话历史过长导致请求/响应体积过大。1.降低请求频率检查并调低配置中的requests_per_minute参数。2.监控资源查看服务器CPU、内存、网络IO。如果部署在低配VPS上可能资源不足。3.精简上下文在API请求中只发送最近几轮对话或者使用项目可能支持的“总结上下文”功能。回复内容不完整或被截断1. Bing服务本身对单次回复有长度限制。2. 流式响应解析错误丢失了部分数据块。3. 客户端或服务端缓冲区大小限制。1.分步询问对于复杂问题拆分成多个小问题。2.检查解析逻辑确认处理SSE事件的代码能正确处理数据块拼接和[DONE]事件。3.验证原始响应通过日志输出原始的、未经处理的SSE事件流看是否是Bing就没有返回完整内容。服务运行一段时间后崩溃1. 内存泄漏常见于未正确关闭连接、缓存无限增长。2. Cookie全部失效且无重试或降级机制导致大量请求失败堆积。3. 外部依赖如Redis连接断开。1.查看崩溃日志使用docker logs --tail 100 bing-api查看崩溃前的最后日志。2.引入进程管理使用docker-compose的restart: unless-stopped或使用pm2、systemd管理进程实现自动重启。3.完善错误处理在代码中捕获所有可能的异常至少记录日志避免进程因未处理异常而退出。6.2 长期维护与更新策略这类项目最大的挑战在于“对抗性维护”——官方前端一变你的模拟就可能失效。关注项目动态Star并Watch项目的GitHub仓库开启通知。维护者通常会在官方更新后第一时间提交修复。理解错误模式当API开始返回奇怪的错误或完全不通时先别急着改代码。打开浏览器手动使用一次New Bing用开发者工具抓包对比一下现在的请求URL、参数、Headers和之前有什么不同。很多时候只是某个接口路径或请求头字段变了。社区协作如果发现了问题并且自己找到了修复方法积极向原项目提交Pull Request。如果无法修复在Issue里详细描述问题现象附上错误日志和抓包对比帮助维护者定位问题。备份与回滚在更新项目版本尤其是主版本更新前备份当前的配置和数据。如果新版本有问题可以快速回滚到旧版本容器。考虑备选方案理解这类项目的脆弱性。对于关键业务流最好有备选方案比如降级到使用官方API如果可用且符合需求或者使用其他更稳定的AI服务作为备份。6.3 安全与合规提醒最后也是最重要的必须时刻绷紧安全和合规这根弦。密钥管理Cookie是最高机密。永远不要提交到Git仓库。使用.env文件并加入.gitignore或云服务商提供的密钥管理服务如AWS Secrets Manager, Azure Key Vault。访问控制你的API服务不应该暴露在公网而不加保护。至少应该使用防火墙规则只允许特定的IP地址如你的办公网络、家庭IP访问。或者为API添加简单的认证比如一个固定的API Key在请求头中携带。curl -H Authorization: Bearer YOUR_API_KEY http://your-server:3000/v1/chat/completions ...合规使用严格遵守Microsoft的服务条款。此类项目通常用于个人学习、研究和效率提升。不要将其用于任何商业盈利性的大规模自动化。生成垃圾邮件、虚假信息或恶意内容。绕过官方的付费限制或服务条款。对New Bing服务进行压测或攻击。数据隐私你通过此API发送的所有对话内容理论上都会经过你部署的服务器。确保服务器本身是安全的。如果处理敏感信息这一点尤为重要。部署和维护New-Bing-Anywhere这样的项目就像在维护一座自己搭建的、与官方服务连接的桥梁。它给了你极大的灵活性和控制力但也需要你承担起“桥梁养护工”的责任。这个过程充满技术挑战但当你成功地将AI能力无缝嵌入到自己的工作流中并看着它高效运转时那种成就感和效率的提升绝对是值得的。
New Bing Anywhere：逆向工程与API封装实现AI助手随处调用
发布时间：2026/5/17 6:30:38
1. 项目概述与核心价值最近在折腾一些AI应用的时候发现一个挺有意思的需求能不能让New Bing现在叫Copilot这类AI助手摆脱地域和浏览器的限制在任何地方都能方便地调用这听起来像是个“伪需求”毕竟官方应用和网页版已经很成熟了。但当你真正深入一些开发场景、自动化流程或者只是想在一个更纯净、更可控的环境里集成AI能力时这个需求就变得非常真实了。ha0z1/New-Bing-Anywhere这个项目正是瞄准了这个痛点。它不是一个简单的网页封装而是一个旨在将New Bing/Copilot的核心对话能力通过API等形式暴露出来的工具。简单来说它的目标是把一个需要通过特定浏览器、特定网络环境访问的Web服务变成一个可以像调用本地函数一样使用的“服务”。这对于开发者、对于想要构建个性化AI工作流的朋友来说价值巨大。想象一下你可以直接在命令行里问AI问题可以在你的笔记软件里一键调用AI总结甚至可以让你的智能家居在特定条件下向AI寻求建议——这一切的前提就是有一个稳定、可编程的接口。这个项目的核心价值在于“解耦”和“赋能”。它将AI能力从具体的应用界面中剥离出来变成了一个可组合的“积木”。无论你是想研究AI对话的原理还是想开发一个集成AI功能的第三方应用或者只是想摆脱浏览器在终端里更高效地和AI交互这个项目都提供了一个可能的起点。当然这条路并不好走需要处理反爬机制、模拟用户行为、维持会话状态等一系列复杂问题这也正是我们接下来要深入拆解的内容。2. 核心思路与技术架构拆解要实现“Anywhere”的目标项目的技术架构必然要解决几个核心矛盾如何模拟一个真实用户与New Bing网页端的交互如何维持会话状态尤其是那种多轮对话的上下文如何将网页的流式响应就是那种一个字一个字蹦出来的效果转换成API友好的数据流以及如何应对服务端可能存在的访问频率限制和反自动化检测2.1 逆向工程与协议模拟这是整个项目的基石。New Bing的网页端不是一个简单的HTTP接口它背后有复杂的认证流程、WebSocket连接用于接收流式消息、以及一系列用于维持会话和上下文的请求。New-Bing-Anywhere需要做的第一件事就是通过浏览器开发者工具仔细抓取和分析从打开网页到完成一次对话的全链路网络请求。这个过程通常包括登录态获取分析Cookie、LocalStorage或SessionStorage中哪些是关键令牌如_Ucookie。项目可能需要提供一种方式让用户注入这些凭据或者模拟登录流程后者难度和风险极高通常不推荐。对话初始化找到创建新对话或连接现有对话的API端点。这个请求往往包含了模型参数、对话风格创意、平衡、精确等设置。流式通信核心中的核心。New Bing的回复是服务器推送的通常通过Server-Sent Events (SSE) 或 WebSocket 实现。项目需要能够建立并监听这个流式连接将接收到的事件如“部分内容更新”、“引用添加”、“对话结束”实时地解析并转发给API调用者。上下文管理多轮对话时需要将历史消息ID或上下文标识符在请求中传递以维持对话的连贯性。注意直接对生产环境的网页进行逆向工程存在法律和道德风险且接口可能随时变更。此类项目通常声明为“仅供学习和研究用途”并强烈依赖社区维护来跟进官方的改动。2.2 服务层封装与API设计在成功模拟底层通信协议后下一步就是构建一个易于使用的服务层。一个良好的架构会将底层的网络请求、流式解析、错误处理等脏活累活封装起来向上暴露简洁清晰的编程接口。典型的API设计会包括POST /chat/completions仿照OpenAI API格式接收用户消息、对话历史、选择模型风格返回一个流式响应或一次性完整响应。WebSocket连接为需要真正实时交互的客户端提供双向通信通道。会话管理接口允许创建、查询、删除独立的对话会话实现多用户或多线程隔离。在这一层项目需要处理诸如请求排队避免触发频率限制、自动重试应对网络波动或临时错误、响应格式化将New Bing特有的回复格式如包含引用链接的[1]标记转换为通用格式等工程问题。2.3 部署与运行环境为了让服务“Anywhere”部署方式必须灵活。一个成熟的项目通常会提供多种部署选项本地运行作为命令行工具或本地HTTP服务供开发者快速测试和集成。容器化部署提供Docker镜像可以一键部署到任何支持Docker的环境包括个人服务器、云服务器或NAS。云函数/Serverless适配云平台的无服务器函数按需调用成本低。但这通常需要项目代码有良好的无状态设计或者将会话状态存储到外部数据库。浏览器扩展另一种思路不是提供后端API而是通过浏览器扩展注入脚本直接增强网页本身的功能比如添加自定义快捷键、导出对话历史等。但这与“Anywhere”的初衷略有不同更侧重于增强原有体验。New-Bing-Anywhere很可能采用了Node.js或Python作为后端语言因为它们拥有丰富的网络请求和Web框架生态非常适合做这类爬取和封装的工作。3. 关键实现细节与实操要点理解了宏观架构我们深入到代码层面看看几个最关键的部分是如何实现的以及实操中会遇到哪些“坑”。3.1 会话保持与Cookie管理这是项目稳定性的生命线。没有有效的登录态一切无从谈起。实现方式手动注入最常见也是最推荐的方式。项目会要求用户在配置文件或环境变量中提供从浏览器中复制出来的关键Cookie尤其是_U。项目代码会将这些Cookie附加到后续的所有请求头中。# 示例在环境变量中设置 export BING_COOKIES_U你的很长一串cookie值; other_cookievalue配置文件在config.json或config.yaml中设置。{ credentials: { cookies: _U... } }自动化获取高风险有些项目尝试通过无头浏览器如Puppeteer, Playwright自动登录并获取Cookie。这违反了服务条款极易被检测和封禁且需要处理验证码不推荐在生产环境使用。实操要点与避坑Cookie过期Cookie会过期。你需要定期比如每周从浏览器重新获取一次。在代码中最好加入Cookie失效的检测逻辑当收到401或403错误时能给出明确的提示而不是返回难以理解的“服务器错误”。Cookie隔离如果你部署的服务要给多人使用必须实现会话隔离。不能所有人共享一套Cookie。简单的做法是为每个用户或每个对话会话分配独立的Cookie池或者更安全地引导每个用户使用自己的账户凭据。安全存储Cookie是敏感信息绝不能明文写在代码或日志里。务必使用环境变量或安全的密钥管理服务。3.2 流式响应Server-Sent Events的处理New Bing网页端使用SSE来推送AI的思考过程和回复。处理SSE是项目实现“打字机效果”和实时性的关键。实现方式发起请求向特定的对话端点发送一个POST请求其中包含消息和参数并设置请求头Accept: text/event-stream。监听事件流服务器返回的响应体是一个持续开放的流。你需要逐行读取。SSE的数据格式是event: event_name data: {key: value}空行表示一个事件块的结束。解析事件常见的事件类型包括update部分内容更新data里包含新增的文本。done回复完成。error发生错误。citation添加了一个引用。实时转发每收到一个update事件就解析出新的文本片段通过你提供的API如WebSocket或HTTP流立即发送给客户端。代码示例Node.js伪代码async function streamChatCompletion(message) { const response await fetch(BING_CHAT_ENDPOINT, { method: POST, headers: { Cookie: cookies, Accept: text/event-stream }, body: JSON.stringify({ message }) }); const reader response.body.getReader(); const decoder new TextDecoder(); while (true) { const { done, value } await reader.read(); if (done) break; const chunk decoder.decode(value); const lines chunk.split(\n); for (const line of lines) { if (line.startsWith(data: )) { const eventData JSON.parse(line.slice(6)); // 处理 eventData例如eventData.type, eventData.text // 将 eventData.text 的增量部分发送给客户端 ws.send(JSON.stringify({ delta: eventData.text })); } } } }实操要点与避坑连接超时与重连网络不稳定时SSE连接可能中断。客户端和服务端都需要有重连机制。服务端在向客户端转发时如果连接断开应能缓冲或丢弃后续数据并记录错误。数据拼接SSE的data行可能被分到多个TCP包中解析时要注意跨chunk的数据拼接确保拿到完整的JSON字符串再解析否则会报错。心跳机制长时间没有数据连接可能被代理或服务器关闭。服务器可以定期发送冒号开头的注释行如:keepalive\n\n作为心跳。3.3 请求频率限制与队列管理为了避免被New Bing的服务端视为攻击而封禁IP或账号必须实施严格的频率限制。实现策略令牌桶算法这是控制平均速率的最佳实践。例如设定每分钟最多发送10个请求包括创建对话和发送消息。维护一个令牌桶以固定速率如每6秒一个添加令牌桶有最大容量。每个请求消耗一个令牌如果桶空则请求必须等待。请求队列当并发请求超过当前可用令牌时将请求放入队列按顺序处理。这保证了服务的公平性和稳定性避免了突发流量导致的集体失败。用户级限流如果支持多用户应为每个用户或每个Cookie实施独立的限流策略防止单个用户行为影响全体。实操要点参数可配置将限流参数如RATE_LIMIT_REQUESTS_PER_MINUTE做成配置项方便根据实际情况调整。初期可以设置得保守一些。优雅降级与反馈当请求被限流排队时应向API调用者返回明确的等待状态如HTTP 429 Too Many Requests并可以提示预计等待时间而不是直接拒绝或超时。监控与告警记录被限流的请求数量如果长期处于高水位可能意味着需要扩容增加Cookie池或优化请求模式。4. 部署实践与配置详解理论说再多不如动手部署一遍。我们以最常见的Docker部署方式为例走通一个完整的流程。4.1 环境准备与配置假设项目代码托管在GitHub并且提供了Dockerfile。获取Cookie在浏览器中登录https://bing.com/chat。打开开发者工具F12切换到Application或存储标签页。在Cookies下找到https://www.bing.com复制_U这个Cookie的值。它的值很长是一串看起来像乱码的字符。这是你的通行证请妥善保管不要泄露。克隆项目与配置git clone https://github.com/ha0z1/New-Bing-Anywhere.git cd New-Bing-Anywhere查找项目中的配置文件通常是config.yaml.example或.env.example。复制一份并重命名如config.yaml或.env。编辑配置文件填入你的Cookie。配置项可能叫BING_COOKIES或cookies。# config.yaml 示例 server: port: 3000 bing: cookies: _U你的很长一串cookie值 style: balanced # creative, balanced, precise rate_limit: requests_per_minute: 104.2 Docker构建与运行如果项目根目录有Dockerfile可以按以下步骤操作。构建Docker镜像docker build -t new-bing-anywhere .这个过程会安装项目依赖。如果网络不好可能需要配置镜像加速。运行容器docker run -d \ --name bing-api \ -p 3000:3000 \ # 将容器内3000端口映射到宿主机3000端口 -v $(pwd)/config.yaml:/app/config.yaml \ # 挂载配置文件 new-bing-anywhere-d表示后台运行。-v挂载卷让你可以在宿主机修改配置而无需重建镜像。使用Docker Compose更推荐 如果项目提供了docker-compose.yml部署会更简单。# 编辑 docker-compose.yml确保配置路径正确 version: 3 services: new-bing-anywhere: build: . container_name: bing-api ports: - 3000:3000 volumes: - ./config.yaml:/app/config.yaml restart: unless-stopped # 容器退出时自动重启然后一键启动docker-compose up -d4.3 服务验证与基础测试容器运行起来后如何知道它工作正常查看日志docker logs -f bing-api观察启动日志看是否有报错如Cookie无效、网络连接失败。健康检查 很多项目会提供一个/health或/端点。用curl测试一下curl http://localhost:3000/health如果返回OK或类似信息说明服务进程正常。发起一次测试对话 使用curl或 Postman 调用聊天接口。curl -X POST http://localhost:3000/v1/chat/completions \ -H Content-Type: application/json \ -d { messages: [{role: user, content: 你好请介绍一下你自己。}], stream: false, // 先测试非流式 model: gpt-4 // 这里可能是一个映射具体看项目API定义 }如果返回了JSON格式的AI回复恭喜你部署成功了测试流式接口 对于流式接口curl可能不太直观。你可以使用一个能处理流式响应的客户端或者写一段简单的Python/Node.js脚本。以下是Python使用requests库的简单示例import requests import json url http://localhost:3000/v1/chat/completions headers {Content-Type: application/json} data { messages: [{role: user, content: 写一首关于春天的诗}], stream: True } response requests.post(url, headersheaders, jsondata, streamTrue) for line in response.iter_lines(): if line: decoded_line line.decode(utf-8) if decoded_line.startswith(data: ): # 注意有些实现可能直接返回JSON行没有“data: ”前缀 event_data decoded_line[6:] if event_data ! [DONE]: try: json_data json.loads(event_data) # 打印回复的增量内容 if choices in json_data and len(json_data[choices]) 0: delta json_data[choices][0].get(delta, {}) if content in delta: print(delta[content], end, flushTrue) except json.JSONDecodeError: print(f解析失败的行: {event_data}) print() # 最后换行运行这个脚本你应该能看到诗句被逐字打印出来。5. 高级集成与应用场景部署好服务只是第一步如何把它用起来集成到你的工作流中才是发挥其价值的关键。5.1 与现有开发工具集成命令行工具 (CLI) 你可以将API封装成一个命令行工具。例如创建一个bingchat脚本#!/bin/bash # bingchat 脚本示例 QUESTION$* curl -s -X POST http://localhost:3000/v1/chat/completions \ -H Content-Type: application/json \ -d {\messages\: [{\role\: \user\, \content\: \$QUESTION\}], \stream\: false} \ | jq -r .choices[0].message.content然后就可以在终端里直接bingchat 如何修复这个bash脚本的错误。代码编辑器插件 为VS Code、Vim/Neovim等编辑器开发插件。例如在VS Code中你可以选中一段代码右键选择“用New Bing解释”插件会将代码和指令发送给你的本地API并把结果插入到注释或新文件中。这需要一些编辑器扩展开发的知识但核心就是调用HTTP API。自动化脚本 (Python/Node.js) 这是最强大的集成方式。你可以写一个脚本自动处理文件、调用AI、并根据结果执行操作。# 示例批量总结日志文件中的错误 import os import requests from pathlib import Path API_URL http://localhost:3000/v1/chat/completions def summarize_errors(log_file_path): with open(log_file_path, r) as f: log_content f.read()[:3000] # 限制长度 prompt f请分析以下日志片段列出所有错误类型及其可能的原因\n\n{log_content} response requests.post(API_URL, json{ messages: [{role: user, content: prompt}], stream: False }) summary response.json()[choices][0][message][content] # 将总结写入新文件 summary_path log_file_path.with_suffix(.summary.txt) with open(summary_path, w) as f: f.write(summary) print(f总结已保存至: {summary_path}) # 遍历日志目录 log_dir Path(./logs) for log_file in log_dir.glob(*.log): summarize_errors(log_file)5.2 构建个性化AI应用有了这个API你几乎可以构建任何你想要的AI小应用。智能邮件/消息助手 连接你的邮箱或即时通讯工具如Slack、钉钉的机器人让AI帮你起草回复、总结长邮件、甚至根据邮件内容判断优先级并创建待办事项。知识库问答机器人 将你的公司文档、个人笔记向量化存储。当用户提问时先通过向量搜索找到相关文档片段然后将“片段问题”一起发给New Bing API让它生成基于你私有知识的精准回答。这就是一个简易版的私有化ChatGPT。创意写作与内容生成 结合模板和变量批量生成社交媒体文案、产品描述、博客大纲等。你可以设定不同的“风格”参数创意/平衡/精确来获得不同调性的内容。5.3 性能优化与高可用考量当从个人使用转向团队或轻度生产环境时需要考虑更多。多Cookie池与负载均衡 单个Cookie有请求频率限制。要提升整体吞吐量可以维护一个Cookie池从池中轮询或按策略选择Cookie来发起请求。这需要在服务层实现一个简单的负载均衡器。# config.yaml 进阶配置 bing: cookie_pool: - _Ucookie1... - _Ucookie2... - _Ucookie3... selection_strategy: round_robin # 或 least_used同时需要监控每个Cookie的健康状态是否失效、是否被限流自动从池中剔除故障项。缓存策略 对于一些常见的、结果不变的查询例如“Python的创始人是谁”可以引入缓存如Redis。在向Bing API发起请求前先检查缓存。这能显著减少不必要的请求提升响应速度并节约配额。注意缓存AI的创造性回答要谨慎避免返回过时或不准确的答案。最好只为事实性、确定性高的问题设置缓存并设置较短的过期时间。异步处理与队列 对于非实时性要求很高的任务如批量处理文档可以采用“请求-响应-回调”的异步模式。用户提交任务后立即返回一个任务ID服务端将任务放入队列如RabbitMQ, Redis Queue异步处理处理完成后通过Webhook或让用户轮询结果。这能避免HTTP请求超时提升系统吞吐能力。6. 常见问题、故障排查与维护心得在实际运行中你一定会遇到各种各样的问题。这里记录一些典型场景和解决思路。6.1 典型错误与解决方案速查表问题现象可能原因排查步骤与解决方案启动服务后调用API返回401 Unauthorized或403 Forbidden1. Cookie已过期或无效。2. Cookie格式错误可能缺少了必要的字段或分号。3. 请求头中Cookie设置不正确。1.重新获取Cookie在浏览器中确认能正常访问bing.com/chat然后重新复制_U值。2.检查格式确保Cookie字符串是完整的如_Uxxx; MUIDyyy;。可以直接从浏览器开发者工具复制整个Cookie字符串而不是手动拼接。3.查看服务日志确认服务启动时是否正确加载了配置的Cookie。流式响应中断连接提前关闭1. 网络不稳定或代理问题。2. 服务端Bing主动断开连接可能因为内容策略、频率限制。3. 客户端读取超时。1.检查网络在服务器上curl测试其他网站确保网络连通。2.查看完整日志关注服务日志中Bing返回的错误信息。可能是回复内容触发了安全策略。3.调整超时设置在客户端和服务端配置更长的读写超时时间。对于服务端确保在转发SSE流时HTTP连接保持活动状态。响应速度极慢或长时间无响应1. 请求被Bing端排队或限流。2. 本地服务或网络存在瓶颈。3. 对话历史过长导致请求/响应体积过大。1.降低请求频率检查并调低配置中的requests_per_minute参数。2.监控资源查看服务器CPU、内存、网络IO。如果部署在低配VPS上可能资源不足。3.精简上下文在API请求中只发送最近几轮对话或者使用项目可能支持的“总结上下文”功能。回复内容不完整或被截断1. Bing服务本身对单次回复有长度限制。2. 流式响应解析错误丢失了部分数据块。3. 客户端或服务端缓冲区大小限制。1.分步询问对于复杂问题拆分成多个小问题。2.检查解析逻辑确认处理SSE事件的代码能正确处理数据块拼接和[DONE]事件。3.验证原始响应通过日志输出原始的、未经处理的SSE事件流看是否是Bing就没有返回完整内容。服务运行一段时间后崩溃1. 内存泄漏常见于未正确关闭连接、缓存无限增长。2. Cookie全部失效且无重试或降级机制导致大量请求失败堆积。3. 外部依赖如Redis连接断开。1.查看崩溃日志使用docker logs --tail 100 bing-api查看崩溃前的最后日志。2.引入进程管理使用docker-compose的restart: unless-stopped或使用pm2、systemd管理进程实现自动重启。3.完善错误处理在代码中捕获所有可能的异常至少记录日志避免进程因未处理异常而退出。6.2 长期维护与更新策略这类项目最大的挑战在于“对抗性维护”——官方前端一变你的模拟就可能失效。关注项目动态Star并Watch项目的GitHub仓库开启通知。维护者通常会在官方更新后第一时间提交修复。理解错误模式当API开始返回奇怪的错误或完全不通时先别急着改代码。打开浏览器手动使用一次New Bing用开发者工具抓包对比一下现在的请求URL、参数、Headers和之前有什么不同。很多时候只是某个接口路径或请求头字段变了。社区协作如果发现了问题并且自己找到了修复方法积极向原项目提交Pull Request。如果无法修复在Issue里详细描述问题现象附上错误日志和抓包对比帮助维护者定位问题。备份与回滚在更新项目版本尤其是主版本更新前备份当前的配置和数据。如果新版本有问题可以快速回滚到旧版本容器。考虑备选方案理解这类项目的脆弱性。对于关键业务流最好有备选方案比如降级到使用官方API如果可用且符合需求或者使用其他更稳定的AI服务作为备份。6.3 安全与合规提醒最后也是最重要的必须时刻绷紧安全和合规这根弦。密钥管理Cookie是最高机密。永远不要提交到Git仓库。使用.env文件并加入.gitignore或云服务商提供的密钥管理服务如AWS Secrets Manager, Azure Key Vault。访问控制你的API服务不应该暴露在公网而不加保护。至少应该使用防火墙规则只允许特定的IP地址如你的办公网络、家庭IP访问。或者为API添加简单的认证比如一个固定的API Key在请求头中携带。curl -H Authorization: Bearer YOUR_API_KEY http://your-server:3000/v1/chat/completions ...合规使用严格遵守Microsoft的服务条款。此类项目通常用于个人学习、研究和效率提升。不要将其用于任何商业盈利性的大规模自动化。生成垃圾邮件、虚假信息或恶意内容。绕过官方的付费限制或服务条款。对New Bing服务进行压测或攻击。数据隐私你通过此API发送的所有对话内容理论上都会经过你部署的服务器。确保服务器本身是安全的。如果处理敏感信息这一点尤为重要。部署和维护New-Bing-Anywhere这样的项目就像在维护一座自己搭建的、与官方服务连接的桥梁。它给了你极大的灵活性和控制力但也需要你承担起“桥梁养护工”的责任。这个过程充满技术挑战但当你成功地将AI能力无缝嵌入到自己的工作流中并看着它高效运转时那种成就感和效率的提升绝对是值得的。
