Claude Code

TL;DR — AI-Native Workspace 是一个开源框架，用来把 AI coding agent 真正接入长期运行的研究或工程工作区。它的核心思路很简单：把 Model、Agent、Protocol、Application 四层拆开，让 Claude、DeepSeek、Codex、Cursor、MCP 服务、项目文档和知识管理流程可以独立替换，而不是绑死在同一个生态里。 大多数 AI coding 工作流一开始都像一堆有用但松散的碎片：一个 CLAUDE.md，几段 prompt，几个 shell 脚本，也许还有 .cursorrules，再加一句“记得更新 TODO”。 单项目时这能跑。等工作区长到五六个项目、三四个模型供应商、一个 wiki、一个 inbox、几组本地服务和几个月的历史决策时，它就开始变形。 AI-Native Workspace 是我们把这堆经验整理成架构的尝试。 它不是另一个 dotfiles dump。它的出发点是：把 workspace 本身看成操作系统；model 提供推理能力，agent 像进程一样运行，protocol 是系统调用，application layer 才是真正的工作产物。 这个比喻听起来有点抽象，但它解决的是一个很实际的问题：当模型、agent 和工具每几个月就变化一次时，怎样让一个 AI 工作区保持可迁移？ 问题：大多数 Agent 工作流耦合太重 现在很多 “AI workflow” 配置都绑定在一个单一生态里： 一个模型供应商， 一个 coding agent， 一种配置格式， 一套项目结构， 一组工具集成。 这能让你很快开始，但后续成本会慢慢出现。模型涨价了，脚本要改。agent 换了配置格式，规则要改。加第二个项目后，根目录说明开始变成垃圾桶。聊天记录断了，agent 就失去了过去决策的原因。 AI-Native Workspace 从相反的假设出发： workspace 应该比任何单个模型、agent、供应商或工具活得更久。 所以它把整个系统拆成四层。 四层架构 1 2 3 4 5 6 7 8 9 10 11 12 13 ┌─────────────────────────────────────────────────────────┐ │ Application │ │ Projects · Inbox · Wiki · workflows │ ├─────────────────────────────────────────────────────────┤ │ Protocol │ │ CLAUDE.md conventions · CLI tools · MCP servers │ ├─────────────────────────────────────────────────────────┤ │ Agent │ │ Claude Code · Codex · Cursor · markdown-aware agents │ ├─────────────────────────────────────────────────────────┤ │ Model │ │ DeepSeek · Claude · Qwen · OpenAI · local models │ └─────────────────────────────────────────────────────────┘ 每层只负责一件事。更重要的是，每层都可以替换，而不强迫其他层一起重写。 ...

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 使用预付费余额——充多少用多少，没有订阅。 ...

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，深度思考分类器处理边界情况。 ...

一句话 — 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。 ...