DeepSeek V4 接入 Claude Code:Anthropic 兼容 API + 原生 Web Search

TL;DR — DeepSeek 提供了一个 Anthropic 兼容的 API 端点,让 Claude Code 可以把 DeepSeek V4 Pro 当作 Claude Opus 的直接替代。配置只需八个环境变量,支持 tool calling、子 agent 派生和原生 web search。输入 token 价格 $0.435/M(永久定价),比 Claude Opus 4.7 便宜约 4–17 倍。本文基于我们日常运行的真实配置。 为什么这件事重要 Claude Code 是 Anthropic 的终端 AI 编程 agent。它读你的代码、跑 bash 命令、派生子 agent、写代码——全部通过 Anthropic API。问题是:它只说 Anthropic 的消息格式。你没法直接把它指向 OpenAI、Gemini 或本地 Ollama,除非加一层翻译。 DeepSeek 用了最直接的方式解决:搭了一个 Anthropic 兼容的 API 端点 https://api.deepseek.com/anthropic,并在第一天就提供了 Claude Code 的接入文档。不需要代理、不需要 wrapper、不需要 fork SDK。改几个环境变量就行。 我们已经在生产环境跑这套配置——管理一个有六个活跃子项目、MCP server、每天编程的工作区。以下是哪些能用、哪些不能用、以及精确的配置方法。 第一步:获取 DeepSeek API Key 在 platform.deepseek.com 注册并创建 API Key。DeepSeek 使用预付费余额——充多少用多少,没有订阅。 ...

2026-05-29 · 4 分钟 · RedDragonHQ

逆向 Claude Code 源码:它的 Agent 架构是怎么设计的,以及我们如何用同样思路给泰拉瑞亚做了个 AI 助手

TL;DR — 我们逆向了 Claude Code 的 TypeScript 源码,搞清楚了它的 Agent 架构如何处理安全、复杂任务和工具权限。然后把这些模式用到了一个开源项目上——让玩家在泰拉瑞亚游戏里跟 AI 聊天,AI 还能给道具、改天气、传送玩家。以下是我们的发现、实现过程和踩坑总结。 为什么要拆 Claude Code 的源码 Claude Code 不只是个编程助手。底层它是一个 Agent 运行时——会 spawn 子 Agent、管理文件权限、跑 bash 命令、判断什么时候该问用户什么时候该直接做。我们想搞清楚它的内部机制,然后把这些想法用到一个完全不同的场景:泰拉瑞亚游戏服务器。 我们的项目 terra_llm_bridge 把泰拉瑞亚 TShock 服务器接到了一个 LLM 上。玩家在聊天框打 @ai 就能跟 AI 对话——但 AI 不止能聊天,还能做事:给道具、改天气、传送玩家,甚至能切换困难模式。最后那条就是我们翻车的地方。 第一次有玩家让 AI 设成雨天,LLM 自作主张调了 terra_world_hardmode(confirm=True)——把整个服务器的世界不可逆地切成了困难模式。没人要求它这么做。模型自己觉得该做就做了。 我们需要一个真正的权限系统。于是去翻 Claude Code 的源码。 Claude Code 的 7 层权限架构 通读 src/utils/permissions/permissions.ts 的约 1500 行代码,加上 Agent 工具的基础设施(约 3800 行),一套清晰的架构浮现出来。Claude Code 不是靠单点检查做安全——它有七层: Layer 1a: 拒绝规则 → "永远不允许 Bash(git push --force)" Layer 1b: 询问规则 → "Bash(curl *) 总是弹窗确认" Layer 1c: 工具自检 → 每个工具 checkPermissions() 自己的逻辑 Layer 1d: 工具自拒 → Read 工具白名单特定路径 Layer 1f: 内容规则 → "就算 bypass 模式,npm publish 也要弹窗" Layer 1g: 安全检查 → ".git/、.claude/ 永远不能绕过用户确认" Layer 2: 模式旁路 → bypassPermissions / auto / acceptEdits / dontAsk Layer 3: YOLO 分类器 → AI 读全文 transcript,判断是否安全 最有意思的是 YOLO 分类器——一个独立的小模型,读取完整对话记录,把每次工具调用分类为安全或危险。两阶段系统:快速分类器处理明显 case,深度思考分类器处理边界情况。 ...

2026-05-27 · 3 分钟 · RedDragonHQ

RAG vs Agent:什么时候用哪个(结合我们自己的实战)

一句话 — RAG 从文档里找答案。Agent 去做事。真实系统几乎都是两者结合:RAG 提供上下文,Agent 基于上下文行动。难点不是选哪个,而是分清楚你问题的哪一层属于哪种模式。 为什么这个对比在现在很重要 过去半年发生了两件事,让 RAG vs Agent 不再是纸上谈兵。 第一:coding agent 在 2025 年 11 月跨过了质量门槛。Simon Willison 在 PyCon 闪电演讲里把这个时刻总结为 agent 从"经常能用"到"基本都能用"——可以作为日常生产力工具了,不再只是 demo。同一个月里 Anthropic、OpenAI、Google 之间的"最强模型"头衔换手了 5 次。 第二:模型实验室自己在转型。Greg Brockman 直说:“模型本身已经不再是产品。” AI21 关闭了模型团队转去做 agent。DeepSeek 第一次组建了 “Harness 团队”。Latent Space 把这个趋势总结为 “所有模型实验室现在都是 agent 实验室”。 当训练模型的人都开始说"模型不是产品"的时候,怎么把模型接到系统里就成了真正的工程问题。RAG 和 Agent 是两个主流答案,解决的问题不一样,选错了会浪费大量 token。 心智模型 RAG:先检索,再生成 RAG 是固定的四步流水线: 用户提问 │ ▼ Embedding 模型 → 向量 │ ▼ 向量库 / 搜索索引 → 取最相关的 top-K 片段 │ ▼ 片段拼进 LLM prompt 作为上下文 │ ▼ LLM 基于检索内容写一次答案 一次检索,一次生成。便宜、确定性高、易于 debug。 ...

2026-05-25 · 5 分钟 · RedDragonHQ