Anthropic

第一次使用 Claude Code 重构整个模块时，我有一种几乎神秘的体验。我描述了自己的需求，然后就去喝了一杯咖啡，等我回来时，眼前是一份包含14个文件更改的pull request，测试代码已更新，还有一条合格的提交消息。“这简直是魔法”，我当时想。 但这并不是魔法。这只不过是一个 while 循环。 最近，OpenAI 的 Michael Bolin 发布了一篇文章，揭秘了 Codex CLI 的内部运作方式。事实证明，那些所谓的AI 编程代理背后的秘密并不是某种革命性的算法，也不是神秘的神经网络。它实际上是一个调用 LLM 的循环，执行工具操作，然后一直重复，直到没有剩余的任务。 接下来，我们深入解析。 状态机：5个阶段和一个循环 每一个编程代理 —— 不管是 Codex、Claude Code、还是 Cursor —— 都遵循着同样的基本模式。Michael Bolin 将其描述为一个包含5个阶段的循环： flowchart TD A["1. 提示组装\n(构建 Prompt)"] --> B["2. 推断\n(发送到 LLM)"] B --> C{工具调用？} C -->|是| D["3. 工具调用\n(执行工具)"] D --> E["4. 工具响应\n(将结果返回 LLM)"] E --> B C -->|否| F["5. 助手回复消息\n(最终响应)"] F -->|新输入| A style A fill:#2d3748,stroke:#4a9eed,color:#fff style B fill:#2d3748,stroke:#4a9eed,color:#fff style C fill:#4a3728,stroke:#ed9a4a,color:#fff style D fill:#2d3748,stroke:#4a9eed,color:#fff style E fill:#2d3748,stroke:#4a9eed,color:#fff style F fill:#283d28,stroke:#4aed5c,color:#fff 通俗点说： ...

几周前我写了一篇文章，解释了为什么你发给Claude的99%数据已经在缓存里。KV张量、VRAM、本地SSD——所有的内部机制。但我遗漏了最痛的部分：账单。 因为prompt缓存是那种看起来像超值优惠的东西，但一旦仔细看看数字，你就会发现为了节省成本，你竟然被要求付更多的钱。 成本悖论 让我们用一些数字来说明。在Claude Sonnet的定价中： 项目 每百万tokens价格 常规输入 $3.00 缓存写入 $3.75 (1.25倍) 缓存读取 $0.30 (0.10倍) 注意一件事：写入缓存的成本比直接处理输入高25%。你为了让下一次使用更便宜而需要额外付费。 这就像加入Costco那样。年费有点心疼。但如果买得足够多，就会值回票价。 问题是，“足够多”取决于你能在缓存过期前读取它的次数。 什么时候你会亏钱？ 假设你用cache_control发了一个100K tokens的prompt。第一次请求： 100,000 tokens × $3.75/M = $0.375 (缓存写入) 如果你没有用缓存发送它： 100,000 tokens × $3.00/M = $0.300 (常规输入) 你额外多付了$0.075，比常规价格高出25%。你亏钱了。 现在第二次请求，同样有100K tokens的前缀： 100,000 tokens × $0.30/M = $0.030 (缓存读取) 对比来看： 100,000 tokens × $3.00/M = $0.300 (常规未缓存输入) 你节省了$0.27。两次请求的总成本不仅回本了之前多支付的$0.075，现在还实现了盈亏平衡。 盈亏平衡点是1.4次读取。 用更直白的话说：如果你计划在接下来的5分钟内至少重复使用该前缀两次，缓存就是值得的。 为什么对Claude Code来说使用缓存是明智选择 在Claude Code的一次会话中，每条消息都会包含system prompt、工具定义以及整个对话历史。每条消息都在重复发送相同的上下文。如果没有缓存，每次发送“把这个按钮换个颜色”，你都需要为相同的150K tokens上下文支付$3.00/M。 没人能负担得起这个。 而有了prompt缓存，你只需为写入缓存支付一次费用，之后每次读取只需要$0.30/M。在包含150K上下文的50条消息会话中，差距很明显： 无缓存: 50 × 150,000 × $3.00/M = $22.50 有缓存: 1 × 150,000 × $3.75/M + 49 × 150,000 × $0.30/M = $2.77 从$22.50降到$2.77。节省了88%。这就是为什么Anthropic默认在Claude Code中启用缓存。如果不这样做，从经济角度看是不可行的。 ...

我正在构建 Tokamak，一个监控 Claude Max 配额的 macOS 菜单栏应用。几周前，Anthropic 在他们的服务条款中发布了这样的条文： “您不得使用 OAuth 或类似的授权机制来允许第三方应用程序代表用户访问 Claude。” 而我，正在使用浏览器 cookies 调用一个未公开的端点来读取 Claude Max 配额，盯着屏幕想：“现在怎么办？” 今天的工作方式（有用的权宜之计） Tokamak 需要知道你的配额百分比。就是当你在 claude.ai 上用了一段时间后看到的那个 42%。问题是Anthropic 没有公开的配额 API。没有一个带 API key 的文档化的 GET /api/quota。 但确实存在一个 claude.ai 网站自己使用的内部端点： GET /api/organizations/{org_id}/usage 返回类似这样的内容： 1 2 3 4 { "five_hour": { "utilization": 42, "resets_at": "2026-02-22T18:00:00Z" }, "seven_day": { "utilization": 19, "resets_at": "2026-02-28T14:59:59Z" } } 要调用这个端点，你需要已登录用户的会话 cookies。Tokamak 用一个隐藏的 WKWebView 解决这个问题：用户在应用内的 claude.ai 中登录，cookies 保留在 WebView 中，应用每 30 秒使用这些 cookies 进行轮询。 ...

我正在构建一个应用来监控我在Claude Code中的token消费。几天前，查看原始数据时，我遇到了这样的情况： cacheReadInputTokens: 4.241.579.174 inputTokens: 1.293.019 从缓存中读取的四十二亿个tokens。一百三十万个"新鲜"tokens。这是**99.97%**的缓存命中率。 我的第一反应是认为出了什么问题。没人能达到99%的缓存率。Redis不行。Cloudflare不行。你妈妈说她已经知道你要吃什么的时候也不行。 但事实证明它没有坏。就是这样工作的。而原因既优雅又反直觉。 缓存的不是文本 这里是大多数解释都不够深入的地方。当你看到"提示词缓存"时，你会想到类似Redis的东西：保存问题，保存答案，如果有人问同样的问题就返回同样的答案。 完全不是这样。 缓存的是KV张量——transformer在预填充阶段计算的Key和Value矩阵。用通俗的话说：当LLM收到你的提示词时，它首先要做的是将所有这些文本转换为内部数字表示（embeddings），然后与权重矩阵相乘，得到注意力机制生成响应所需的"键"（K）和"值"（V）。 这种计算是极其昂贵的。在一个200,000个tokens的提示词中（在Claude Code中很常见，对话历史会累积），我们谈论的是数十亿次矩阵乘法运算。这是最消耗GPU的部分，最耗时的部分，成本最高的部分。 这就是巧妙之处：在你的一条消息和下一条消息之间，99%的提示词不会改变。系统提示词是相同的。之前的对话历史是相同的。它读取的文件是相同的。唯一新的是你的最后一条消息。 为什么要重新计算你30秒前已经计算过的东西呢？ 匹配机制的工作原理 仅仅缓存是不够的。你必须知道缓存什么时候有用。这里Anthropic使用了一个优雅的技巧：按前缀的累积哈希。 提示词的每个块（system、tools、消息）生成一个哈希。但不是单独的哈希：是累积哈希。第3块的哈希包括第1、2、3块的内容。如果前面任何块中的任何东西发生变化，后面所有块的哈希也会改变。 当新请求到达时，系统从标记有cache_control的点开始向后搜索，逐块比较哈希，直到找到匹配的最长前缀。所有匹配的→从缓存读取。只有新的→重新计算。 这就像一部你已经看了40遍的电影。你不需要看完整部电影就知道会发生什么。你只需要从与你记忆中不同的点开始看。 注意这个数据：系统只向后检查最多20个块。超过这个范围，它就停止搜索。这是一个实用的决定，避免花在搜索缓存上的时间超过直接计算张量的时间。 为什么Claude Code有99%的缓存命中率 现在你知道匹配是如何工作的了，99%就不再神秘了。看看Claude Code中典型会话发生的情况： 消息1（会话中的第一条）： 系统提示词 (8K tokens) + 工具 (2K tokens) + 你的消息 (500 tokens) = 10,500 tokens → 全部计算，全部写入缓存 消息2： 系统提示词 (8K) + 工具 (2K) + 消息1 (500) + 响应1 (3K) + 你的消息2 (500) = 14,000 tokens → 前面的10,500个 → 缓存命中（我们之前已经计算过） → 新的3,500个 → 计算并添加到缓存 缓存命中率：75% 消息10： 系统提示词 + 工具 + 9条消息 + 9个响应 + 你的消息10 = ~150,000 tokens → 前面的~149,500个 → 缓存命中 → 新的~500个 → 计算 缓存命中率：99.7% 看到了吗？对话历史只是增长。每条新消息都是累积总数的微小部分。缓存比率以自然对数的确定性收敛到99%。 ...

一个 100MB 的 CLI 二进制文件 Anthropic 刚刚宣布 Claude Code 现在可以作为原生构建使用。翻译一下：这是一个可以通过 curl 安装的二进制可执行文件，不需要 Node.js。 听起来不错，对吧？一条命令，无依赖，后台自动更新。任何 CLI 工具的梦想。 但有一个细节：二进制文件大小为 100MB。 为了给你一个参考，git 二进制文件大约 3MB。curl 不到 1MB。即使是以生成大二进制文件著称的 Go，也很少超过 15-20MB。 这 100MB 里到底装了什么？ 不是 Rust，是穿着可执行文件外衣的 Bun 当我看到这个公告时，我的第一个想法是：“他们用 Rust 重写了一切。“这很有道理，不是吗？如果你想要一个原生的、快速的、无运行时的二进制文件，Rust 是明显的选择。 结果不是这样。 Claude Code 仍然是 TypeScript。他们所做的是使用 bun build --compile 将其打包为可执行文件。 bun build --compile 是如何工作的 这个神奇的命令是： 1 bun build ./src/index.ts --compile --outfile claude 它具体做了什么？三件事： 1. 打包 首先，Bun 充当打包器。它获取你的入口文件（index.ts），解析所有的 import，并生成一个包含所有代码串联的单一 JavaScript 文件。包括你的 node_modules 依赖，解决tree-shaking以消除死代码，并压缩结果。 ...

10GB的意外发现 你在Mac上安装了Claude Desktop。一切正常，应用程序看起来很小。但有一天你查看磁盘空间，发现了这个： ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle 10.8 GB。 什么？一个聊天机器人要占用十个G？这里面装的什么，《指环王》三部曲加长版？ 不是。装的是Ubuntu。 Claude产品三巨头 在解释"是什么"之前，让我先解释"为什么"。Anthropic有三种方式让你访问Claude： 产品 运行位置 目标用户 claude.ai Anthropic服务器 所有人 Claude Desktop + Cowork 你Mac上的虚拟机 专业人士 Claude Code 直接在你的系统上 开发者 网页版是安全选择：一切都在Anthropic的云端进行，不会接触你的机器。但如果你想让Claude在你的电脑上做真正的事情——创建文档、执行代码、移动文件——你需要其他解决方案。 这就是Cowork和Claude Code的用武之地，两种完全不同的哲学。 Cowork：普通人的Claude Code Cowork是Anthropic在2026年1月12日发布的智能体名称。它的官方标语是： “Claude Code for the rest of your work”（为你其他工作准备的Claude Code） 虽然Claude Code是为生活在终端里的开发者设计的，但Cowork是为你不编程时设计的。想要整理合同的律师。需要从50个PDF中提取数据的分析师。想要把笔记转换成演示文稿的教师。 它能做什么 你授予它访问Mac上某个文件夹的权限 Claude在该文件夹内读取、编辑和创建文件 可以创建Office文档（Word、Excel、PowerPoint），无需你安装任何软件 如果需要，可以执行Python或JavaScript代码 可以并行启动多个"子智能体"处理繁重任务 实际例子 “嘿Claude，我在这个文件夹里有30张收据截图。给我做一个包含每张收据日期、概念和金额的电子表格。” Claude就会去做。读取图像，用OCR提取数据，创建Excel文件，然后放在那里给你。 有趣的事实 Cowork几乎完全由Claude Code在1.5周内构建完成。Claude在编写下一代Claude产品。《盗梦空间》但是少了迪卡普里奥多了tokens。 虚拟机：安全技巧 这就是精妙之处。当Cowork执行代码或操作文件时，它不是直接在你的Mac上做的。而是在一个完全隔离的Ubuntu虚拟机内完成。 为什么？因为让AI在你的系统上执行任意代码就像把你家钥匙给一个很聪明的陌生人。他们可能值得信任，但最好不要让他们接触刀具抽屉。 这10GB里有什么 组件 大小 用途 Ubuntu 24.04 ~3 GB 操作系统 Chromium + Playwright ~920 MB 用于爬虫和网页自动化 LibreOffice ~148 MB 创建Office文档 Node.js, Python, Java ~600 MB 执行代码 CJK字体 ~305 MB 中文/日文/韩文支持 Pandoc, LaTeX ~450 MB 文档转换 用通俗的话说：这是一个装在安全盒子里的完整办公环境。 ...

没人预料到的新闻 上周，当你我还在安静地与 node_modules 搏斗时，Anthropic 丢出了一颗炸弹：他们收购了 Bun。 是的，Claude 背后的公司决定他们的未来要依靠一个用 Zig 编写的 JavaScript 运行时，这是一个想着"要是 Node，但是快"的家伙写的。Claude Code 刚刚达到 10 亿美元的收入，显然当你有多余的钱时，第一件事就是购买开发工具。 为什么？因为 Claude Code 疯狂执行 JavaScript，当你有数百万用户时，每一毫秒都很重要。通俗地说：如果你的业务依赖于快速执行代码，你就买最快的运行时。 但够了企业八卦。让我们来看你感兴趣的：什么是 Bun，为什么你应该关心。 什么是 Bun（对于我们这些来自 Node 的人） Bun 就像有人看着 Node 生态系统说：“要是我们做一个工具来替换这十五个工具会怎样？” 之前你有： node → 运行时 npm/pnpm/yarn → 包管理器 webpack/esbuild/vite → 打包器 jest/vitest → 测试运行器 ts-node/tsx → 执行 TypeScript 现在你有： bun → 以上所有功能 这是电动滑板车对比拖着拖车的汽车。更少的部件，更少可能出错的东西，奇怪的是还更快。 重要的数字 我不喜欢做基准测试，因为总是可以被操纵。但这些数字太残酷了，值得一提： 操作 Node + pnpm Bun 差异 install（中等项目） ~25s ~3s 快 8 倍 运行时启动 ~50ms ~5ms 快 10 倍 执行测试 基线 快 2-3 倍 明显 转译 TypeScript 需要工具 原生支持 ∞ 为什么这么快？因为它用 Zig 而不是 C++ 编写，因为 Jarred Sumner（创造者）是那种把优化代码当作兴趣爱好的程序员。这家伙在 Stripe 工作，决定世界上最重要的问题是 npm install 花费太长时间。 ...