几天前我冒出一个想法：Claude Code 的 Agent 能力是我用过最强的，但它要钱；DeepSeek 网页版免费且聪明，却没有 API。
如果我在中间做一层翻译，让它们俩「以为对方就是我想要的东西」，会怎样？
问题拆解
先理清楚我到底想解决什么。
Claude Code 本质上是一个工具链调度器。它不只是在聊天——它读文件、写代码、跑测试、git commit，每一步都通过调用工具完成。这些工具调用是通过 Anthropic 的 Messages API 来驱动的：发消息→收回复（可能含工具调用）→执行工具→把结果送回→继续。
而 DeepSeek 网页版就是一个对话框。你打字，它回复。没有 API，没有工具调用，没有结构化输出。
我的目标不是「在 DeepSeek 网页上自动发消息」——那是网页爬虫的活。我的目标是让 Claude Code 把 DeepSeek 当成模型后端来用，完全 unaware 另一端是个浏览器。
所以问题变成了三层：
- 协议翻译：Anthropic Messages API（JSON 结构） ↔ DeepSeek 网页版（纯文本对话）
- 工具调用桥梁：Claude Code 需要调用工具时，怎么让 DeepSeek「学会」输出结构化工具指令
- 反爬绕过：DeepSeek 有 PoW（工作量证明）验证，怎么在不暴露自动化痕迹的前提下通过
关于「模仿」的思考
*图 1：Claude Code 的对话界面。它以为自己连的是 Anthropic API，实际背后是 DeepSeek。
做这种中转代理，本质上是一场模仿秀。
我需要让 DeepSeek 网页版模仿 Anthropic 的模型行为，同时让 Claude Code 相信它对话的对象就是 Anthropic 的 API。两边都不知道对方的存在。
这听起来复杂，但换个角度想：API 不就是定义好的输入输出格式吗？ 只要我在中间做好格式转换，两边根本不需要知道对方存在。
- Claude Code 发来的 JSON → 我翻译成 DeepSeek 能理解的文本提示词
- DeepSeek 返回的文本 → 我包装成 Claude Code 认得的 API 响应格式
- 工具调用 → 我告诉 DeepSeek「如果你想说请执行 Bash，就在回复里写
<tool_call>{...}</tool_call>」 - 工具执行结果 → 我插个
--- TOOL EXECUTED ---标记塞回对话里
每一个环节都不复杂，但合起来就是一个能跑的系统。
最大的坑：PoW
理想很美好：DeepSeek 网页版有内部 API，直接发 HTTP 请求就好了，快且轻量。
现实是：DeepSeek 每次对话前要求计算一次 Proof of Work。这个计算必须在浏览器环境里完成，不计算就不给回复。
纯 HTTP 方案直接胎死腹中。
我试了两条路：
硬刚方案：用 Playwright 开一个完整的浏览器，所有操作都在浏览器里模拟——打字、点击发送、等回复、提取内容。整个对话就是个页面自动化脚本。
这个方案的问题是太慢了。启动浏览器、加载页面、渲染 DOM —— 每一步都在等。而且浏览器占内存，开久了还会崩。
取巧方案：一个 headless 浏览器常驻后台，只干一件事——算 PoW。每次需要对话时，触发一次 PoW 计算，拿到通行证，然后真正的对话请求走 HTTP 直发。浏览器不参与对话，它就是一个 PoW 计算器。
这个方案快得多。headless 浏览器占用的资源很少，HTTP 直连几乎没有额外开销。
*图 2：DeepSeek 网页版上的同一段对话。浏览器里看就是普通聊天，实际上它在给 Claude Code 当「幕后大脑」。
让纯文本模型理解「工具调用」
这是整个项目里最「神奇」的部分。
DeepSeek 网页版是一个纯对话模型，没有 tool calling 的能力。Claude Code 却高度依赖工具调用——bash、文件操作、搜索，每一步都要调工具。
怎么让一个纯文本模型理解「你可以调用工具」这件事？
答案出乎意料地平淡：写在提示词里。
你是一个 AI 助手，你可以使用以下工具来帮助用户：
- Bash: 执行 shell 命令。当需要运行命令时，输出：<tool_call>{"name": "Bash", "arguments": {"command": "..."}}</tool_call>
- Read: 读取文件...
对，就这么简单。把工具定义写成自然语言描述，告诉模型「如果你觉得需要，就这么输出」。服务器端再解析 <tool_call> 标签，转回 Anthropic 的 tool_use JSON 结构。
这不是新技术，是提示词工程。
但有趣的地方就在这里：一个没有专门训练过 tool calling 的模型，仅仅通过提示词的引导，就能学会在合适的时机输出结构化工具调用指令。虽然偶尔会格式错误（需要加一层容错解析），但大部分时候它工作得很好。
这说明什么？说明 LLM 在对话中展现的「能力」，很多时候不是模型本身的功能边界决定的，而是你用什么样的上下文去引导它。工具调用不是 DeepSeek 的「功能」，而是提示词给它创造的一种行为模式。
关于「项目」的几点感受
这个项目从产生想法到跑通，大概花了两三个天。代码质量谈不上好——中文日志、半吊子的异常处理、不怎么样的架构。但它确实能跑，而且效果还不错。
几个我觉得值得记住的点：
最好的设计是「不用设计」的。 我没有设计什么复杂的架构。问题摆在那里，解决方案自然就浮现了——协议翻译、提示词引导、混合方案绕过 PoW。每一步都是问题驱动的，不是为了炫技。
限制反而催生了最有意思的部分。 如果 DeepSeek 有公开 API，或者 Claude Code 便宜到可以随便用，这个项目根本不会存在。正是因为两边都有「缺陷」，才有了中间这一层创新。
很多东西不是「功能」，而是「行为」。 让 DeepSeek「学会」工具调用这件事让我印象很深。模型的能力不是静态的，你给它的上下文决定了它能做什么。这不是 hack，这是对 LLM 工作方式更深的理解。
API 的本质是「约定」。 只要两边的输入输出格式能对齐，任何系统都可以互联。Claude Code 不关心另一端是不是 Anthropic 的服务器，它只关心响应结构对不对。DeepSeek 不关心提问者是真人还是程序，它只关心输入文本能不能看懂。
项目代码在 github.com/PC2005-cloud/WebAi，MIT 协议。
这就是一个周末捣鼓出来的玩具，但我觉得它很好玩。