2026-05-10 22:02:00
时间进入到 2026 年 5 月，软件工程领域已经全面引入 Coding Agent，目前一线生产力用得最多的是 Claude Code、Codex、OpenCode。我之前也介绍过我自己现在在本地编程的场景是通过 VS Code 使用 Claude Code 和 Codex。
我到底用了多少 token？花了多少钱？(虽然基本都是Coding Plan，但如果按原价看，会感觉赚了)
我还经常想知道「某个项目到底吃了多少 token」。但三个 Agent 各自存数据，散落在硬盘的不同角落。写个脚本统计？能用，但太折腾了。每次想看数据都得重新跑。
TokenScope 是一个 macOS 原生应用。SwiftUI 写的，零外部依赖。
核心思路就一句话：把常用的 Coding Agent 的用量数据拉到一起，统一展示。
它目前支持三个数据源：Claude Code、Codex、OpenCode。原理也不复杂——这些工具在本地都会留下 session 日志，TokenScope 直接读这些日志，解析 token 用量，然后汇总。
不需要 API key，装上就能用。基本功能也不需要联网。
打开 App 第一个看到的就是 Dashboard。
最上面是几个关键数字：总会话数、总 token 数、输入 token、输出 token、费用估算（美元）。
下面按来源拆开。Claude Code 用了多少，Codex 用了多少，OpenCode 用了多少。点一下就能筛选。
再往下是柱状图。按天展示 token 消耗，不同颜色代表不同模型。鼠标悬停能看到每天的详细拆解：用了哪些模型，每个模型花了多少钱。
还可以按月展开，看到每个月的总 token、费用、消息数。点开就是每一天的数据。
筛选器很灵活。按日期、来源、模型、token 类型，想怎么看就怎么看。
我每次打开 App 第一件事就是看这个柱状图。哪天用得多，哪天用得少，一眼就能看出来。
这是我自己用得最多的功能。
Claude Code、Codex、Z.ai 三个来源的配额和使用量，实时展示。进度条直接告诉你还剩多少。重置倒计时也有。
以前用着用着突然到 limit，或者就是隔一会儿去刷一下各家的 Usage 页面看看剩余额度。现在随时在 TokenScope 看一眼进度条就心里有数了。
还有费用统计。今天花了多少，最近 30 天花了多少。
如果你有多个 Codex 账号——比如工作账号和个人账号分开——TokenScope 支持多账号切换。OAuth 登录，直接在 App 里搞定。
所有 Coding Agent 的会话都在一个列表里。按时间、来源、项目、消息数、token 数、费用，想怎么排就怎么排。
搜索也方便。想找某个项目的会话，搜项目名就行。
双击一个会话，能看到完整的对话记录。每条消息的 token 拆解都在：输入多少、输出多少、缓存读取多少、缓存创建多少、消耗多少费用。
能看到哪些对话特别费 token。有时候一个复杂任务，Agent 反复尝试，token 就蹭蹭涨。看到具体数字之后，我会更有意识地控制对话长度和 prompt 质量。
我在 TokenScope 内置了 20 多个模型的定价数据。Anthropic 全系、OpenAI 全系、GLM 全系都有。
所以每个视图都带费用估算。从 Dashboard 到会话详情，token 数旁边永远跟着一个美元数字。
觉得内置价格不准？可以自己覆盖，改成你使用的 API 的实际价格。
数据存在本地。第一次打开会扫描所有日志文件，之后有缓存，秒开。后台自动刷新新数据。
API key 存在 macOS Keychain 里。这点我很在意，密码类的东西不应该明文存在配置文件里。
纯 Swift 实现，零外部依赖。最低支持 macOS 14。
下载地址：https://github.com/aooyoo/TokenScope/releases
目前仅支持 M 芯片的 Mac 电脑
这个项目还在持续开发中。感兴趣的话，或者有什么功能建议，欢迎告诉我。
2026-04-28 20:56:00
本文首发于公众号：未来科技
DeepSeek 团队近期发布的 DeepSeek-V4 系列（包括 1.6T 参数的 Pro 版与 284B 参数的 Flash 版）将开源大模型的能力边界推向了百万 token 上下文时代。这份技术报告中最值得深入探讨的，一是其在模型架构层面对长上下文效率瓶颈的系统性突破，二是其在后训练阶段为 Coding Agent 场景所做的针对性优化。本文围绕这两条主线展开。
DeepSeek-V4 在保留 DeepSeek-V3 的 MoE 框架与 MTP（Multi-Token Prediction）的基础上，引入了三项关键的架构升级：混合注意力机制（CSA + HCA）、流形约束超连接（mHC）以及 Muon 优化器。这三者共同构成了 V4 系列在效率与稳定性上的护城河。
长上下文场景下，注意力机制的二次复杂度是绕不开的瓶颈。V4 没有选择单一路线，而是设计了两种压缩注意力机制并以交错方式部署。
Compressed Sparse Attention（CSA） 走的是”先压缩、再稀疏”的路线。它首先用一个 token 级压缩器将每 个 token 的 KV 缓存合并为一条 entry（V4 中 ），随后通过一个轻量级的 Lightning Indexer 计算压缩 KV 块与 query 的相关性分数，并通过 top-k 选择器（Pro 版选 1024 条）保留最相关的压缩块进行核心注意力计算。值得注意的是，CSA 使用的是 Multi-Query Attention 形式，且 query 的 latent 向量在 indexer 与主注意力之间共享，进一步压缩了计算量。此外，由于 query 的输出维度 较大，V4 还引入了 grouped output projection——先将 个头分成 组，每组先投影到中间维度 ，再合并为最终输出，避免了出口投影成为新的瓶颈。
Heavily Compressed Attention（HCA） 则走极致压缩路线，将每 个 token 合并为一条 entry，但放弃稀疏选择，对所有压缩后的 entry 执行 dense attention。由于压缩比足够大，dense 形式的开销也已被摊薄。
CSA 与 HCA 在 Transformer 层之间交错部署：CSA 保留了局部精细度但有 top-k 上限，HCA 提供了全局视野但分辨率较粗，两者形成互补。再叠加几个工程细节——RoPE 仅作用于最后 64 维并对核心注意力输出施加 位置的逆向 RoPE 以恢复相对位置关系；额外的滑动窗口分支（）补偿压缩带来的局部信息损失；可学习的 attention sink logit 允许查询头将总注意力分数压低至接近 0。
效率收益是惊人的。在 1M token 上下文下，V4-Pro 的单 token 推理 FLOPs 仅为 V3.2 的 27%、KV 缓存仅为 10%；V4-Flash 更进一步降至 10% 与 7%。配合 RoPE 维度用 BF16、其余维度用 FP8 的混合存储格式，以及 Lightning Indexer 内部的 FP4 计算，V4 的 KV 缓存在 1M 场景下被压到了 BF16 GQA8 基线的约 2%。
残差连接是 Transformer 信号传递的”高速公路”。Hyper-Connections（HC）通过将残差流的宽度从 扩展到 （V4 中 ）提供了一个独立于 hidden size 的扩展轴，但实测中堆叠多层 HC 会出现数值不稳定。
V4 提出的 mHC 的核心思想是将残差变换矩阵 约束在双随机矩阵流形（Birkhoff polytope）上，即满足行和列之和均为 1 且元素非负。这一约束保证了 ，使残差变换是非扩张的（non-expansive），前向与反向传播的数值稳定性都得到加强；同时双随机矩阵集合在乘法下封闭，深层堆叠依然稳定。具体实现上，未约束的原始矩阵 先经过指数变换确保正性，然后用 Sinkhorn-Knopp 算法做 20 次行列交替归一化收敛到流形上；输入与输出映射 、 则用 Sigmoid 限制非负有界。
这种约束同时解决了 HC 的稳定性问题，又保留了它独立于 hidden size 提供额外容量的优势。
V4 在大部分模块上将 AdamW 替换为 Muon——这是 Muon 第一次被用在万亿参数 MoE 模型的全规模训练上。Muon 的关键步骤是对动量矩阵做近似正交化（通过 Newton-Schulz 迭代），其更新方向接近 的形式，相当于把奇异值都拉到 1 附近。V4 采用了两阶段混合 Newton-Schulz 迭代：前 8 步用激进系数 快速逼近，后 2 步用稳健系数 精确收敛到 1。AdamW 仅保留给 embedding、prediction head、RMSNorm 权重以及 mHC 的静态偏置和门控因子。
Muon 与 ZeRO 的兼容性是工程难点——ZeRO 假设元素级优化器允许参数矩阵切片更新，而 Muon 需要完整梯度矩阵做正交化。V4 的解法是 dense 参数用背包算法做矩阵级分桶分配，MoE 参数则按专家粒度展平、跨 rank 均匀分配；MoE 梯度同步还用了随机舍入到 BF16 + 两阶段 all-to-all + 本地 FP32 求和的方案，把通信量减半的同时维持了数值稳健性。
万亿参数 MoE 训练的不稳定性几乎是普遍现象。V4 报告了两个有效但理论尚未完全清晰的技巧：
V4 的后训练流水线整体采用”专家培养 → 统一蒸馏”两阶段范式：先针对数学、代码、agent、指令跟随等不同领域分别训练专家模型（SFT + GRPO 强化学习），再通过多教师 On-Policy Distillation（OPD）将能力合并到统一模型中。这一节聚焦其中与 Coding Agent 直接相关的优化。
V4 同时提供 Non-think、Think High、Think Max 三种推理模式，每种模式在 RL 训练时使用不同的长度惩罚和上下文窗口，使得同一模型可以根据任务难度选择”思考预算”。对于 coding agent 这种本质上需要长链路推理与多步工具调用的场景，Think Max 模式额外注入一段系统提示，明确要求模型穷尽推理、压力测试逻辑、显式记录所有中间步骤与被否定的假设。从评测结果看，Terminal Bench 2.0 上从 None 模式的 59.1 提升到 Max 模式的 67.9，说明这种推理预算的弹性对 agent 任务有显著收益。
V4 用一套基于 <|DSML|> 特殊 token 的 XML 风格调用格式替代了传统的 JSON 调用约定。文中明确指出，XML 格式可以有效缓解转义失败、减少工具调用错误——这在长链路 coding agent 中尤其关键，因为单一调用错误会让整条轨迹失败。
更重要的是 Interleaved Thinking 的管理策略升级。V3.2 在每个新用户回合到来时会丢弃之前所有的思考链，每次都要从头重建上下文。V4 利用百万 token 上下文窗口，在 Tool-Calling 场景下完整保留所有回合（包括跨用户消息的）思考内容，让模型在长 horizon 的 agentic 任务中维持累积的、连贯的推理脉络；只在不涉及工具的纯对话场景沿用旧的丢弃策略。对 coding agent 来说，这意味着模型在调试一个长达数十个步骤的修复流程时，不必每次重新理解项目结构与已尝试的方案。
OPD 的目标是让学生模型 在自己生成的轨迹上学习多个教师专家（包括 coding 专家）的输出分布，目标函数是加权反向 KL：
以往工作通常将这个 KL 退化为 token 级估计并塞进 RL 框架，但这会带来高方差和训练不稳定。V4 坚持全词表 logit 蒸馏——保留完整 logit 分布做反向 KL，梯度估计更稳，教师知识保留更忠实。
这背后的工程支撑相当扎实：超过十个万亿级教师模型的权重被 offload 到分布式存储按需 ZeRO 式加载；为避免 词表的 logit 物化爆显存，V4 只缓存教师最后一层 hidden state 到中央 buffer，训练时按需通过 prediction head 重建 logits；训练样本按教师索引排序，保证每个 mini-batch 至多一个 prediction head 驻留 GPU。最终 KL 散度由专门的 TileLang kernel 计算。
对 coding agent 而言，这意味着代码专家通过强化学习获得的细粒度能力（错误处理、API 调用习惯、重构判断）能够以接近无损的形式融合进统一模型，而不是被 token 级近似稀释掉。
Coding agent 的训练 rollout 经常涉及 50 万 token 以上的长轨迹，且单次 rollout 可能需要数百次工具调用。V4 在基础设施上做了几项关键优化：
FP4 量化集成到 rollout：rollout 与所有 inference-only 前向（包括教师与参考模型）直接使用原生 FP4 权重，而训练步骤用 FP4→FP8 无损反量化模拟，复用现有 FP8 mixed-precision 框架。这显著降低了 rollout 阶段的显存占用与采样延迟。
Token 粒度 Write-Ahead Log 容错：每生成一个 token 立即追加到该请求的 WAL。被抢占时暂停推理引擎、保存 KV 缓存；恢复时基于持久化的 WAL 与 KV 缓存继续解码；即使硬件错误也能通过 WAL 重建 KV 缓存继续。从头重生成会引入长度偏差（短响应更容易在中断中存活，导致模型偏向短输出），WAL 机制从数学上保证了正确性。
DSec 沙箱平台：为 coding agent 的执行环境提供了四种执行底座（Function Call、Container、microVM、fullVM）的统一接口。Container 用 EROFS 按需加载基础镜像，microVM 用 overlaybd 实现快照链，单集群可管理数十万并发沙箱实例。轨迹日志支持抢占恢复时的客户端快进——已完成的命令直接重放缓存结果，避免非幂等操作的重复执行（这在涉及文件系统、网络请求的 coding agent 中至关重要）。
V4-Pro 在 Codeforces 上拿到 3206 Elo（人类排名约第 23 位），LiveCodeBench Pass@1 达 93.5，是首个在编程竞赛上对标 GPT-5.4 的开源模型。SWE Verified 80.6、SWE Multilingual 76.2、Terminal Bench 2.0 67.9（其 Verified 子集约 72.0），与 K2.6、GLM-5.1 处于同一梯队。
但更值得关注的是 DeepSeek 团队自建的 R&D Coding Benchmark——从 50+ 内部工程师收集 200 个真实任务，覆盖 PyTorch、CUDA、Rust、C++ 跨技术栈的功能开发、bug 修复、重构、诊断，经过质量筛选保留 30 个评测任务。在这个更接近真实工程的基准上：
| 模型 | Pass Rate |
|---|---|
| Haiku 4.5 | 13% |
| Sonnet 4.5 | 47% |
| DeepSeek-V4-Pro-Max | 67% |
| Opus 4.5 | 70% |
| Opus 4.5 Thinking | 73% |
| Opus 4.6 Thinking | 80% |
V4-Pro 显著超越 Sonnet 4.5、接近 Opus 4.5。在对 85 名 DeepSeek 内部研究员与工程师的调研中，52% 表示 V4-Pro 已可作为日常默认编码模型，39% 倾向于是，反对者不到 9%。被反复提及的不足是偶发的低级错误、对模糊指令的误解与过度思考——这恰好指向后续迭代的方向。
DeepSeek-V4 的架构创新可以概括为用结构化压缩换取长上下文效率，用流形约束换取深层稳定性，用矩阵级优化换取收敛速度。CSA + HCA 的混合注意力是当前开源社区在百万 token 上下文方向最系统的工程化方案；mHC 用 Birkhoff polytope 这一漂亮的数学工具解决了 Hyper-Connections 的实战痛点；Muon 在万亿参数规模的成功部署也为后续模型提供了重要参考。
后训练侧，V4 并没有押注单一的 RL 算法奇迹，而是用专家培养 + 全词表 OPD 的两阶段范式，配合 XML 工具调用、跨回合思维保留、token 级 WAL、DSec 沙箱等组合拳，把 Coding Agent 这一长链路、强工程依赖的能力做扎实。R&D 内部基准 67% 通过率与开发者 91% 的正向反馈，比任何公开 benchmark 都更能说明问题。
对从业者而言，V4 给出的最大启示或许是：长上下文与 agent 能力不是独立追求的两件事——只有当注意力效率足够高、推理状态能够持续保留、训练基础设施能容忍长 rollout 与频繁抢占时，agentic AI 才真正具备规模化训练的可能。V4 把这条路径完整地走通了一次。
2026-04-17 22:52:00
本文翻译自Claude官方Blog：https://claude.com/blog/best-practices-for-using-claude-opus-4-7-with-claude-code
了解如何利用重新校准的effort级别、自适应思考以及新的默认设置,优化你在 Claude Code 中使用 Opus 4.7 的体验。
Opus 4.7 是我们目前正式发布的最强模型,适用于编码、企业工作流以及长时间运行的智能体(agentic)任务。它比 Opus 4.6 更善于处理模糊性,在查找 bug 和代码评审方面能力大幅提升,跨会话保留上下文更可靠,并且能够在更少指引下推理出含糊任务的解决方案。
在我们的发布公告中,我们提到两个变化会影响 token 用量:更新后的分词器(tokenizer),以及在更高 effort 级别下(尤其是较长会话的后续轮次)更倾向于深入思考的特性。因此,从 Opus 4.6 切换到 Opus 4.7 时,可能需要做一些调优才能达到最佳性能。对提示词(prompt)和编排框架(harness)进行少量调整,就能带来显著差异。
本文将介绍这些变化,以及如何在 Claude Code 中最有效地使用 Opus 4.7。
Opus 4.7 的 token 用量和行为表现,会因部署形式不同而有所差异:是部署为单轮用户输入的、更自主的异步编码 agent;还是部署为多轮用户输入的、更交互的同步编码 agent。在交互式场景中,它会在用户每轮输入后投入更多推理:这能在长会话中提升其连贯性、指令遵循度和编码质量,但同时也倾向于消耗更多 token。
要在 Claude Code 中充分发挥 Opus 4.7 的能力,我们建议把 Claude 当作一位你正在委派任务的能干工程师,而不是一位需要你逐行指导的结对编程伙伴:
Claude Code 中 Opus 4.7 的默认 effort 级别现在是 xhigh。这是一个介于 high 和 max 之间的新级别,让用户在难题上能更精细地权衡推理深度和延迟。我们建议大多数智能体编码工作使用 xhigh,尤其是对智能要求高的任务,例如设计 API 和 schema、迁移遗留代码、评审大型代码库。
各 effort 级别的进一步指引如下:
medium 和 low:适用于对成本敏感、对延迟敏感或范围明确的工作。模型在更难的任务上能力会比高级别时弱,但仍优于同 effort 级别下的 Opus 4.6——有时还会消耗更少 token。high:在智能与成本之间取得平衡。如果你在并发运行多个会话,或想在质量没有大幅下降的前提下节约开销,可选择 high。xhigh(默认,推荐):大多数编码和智能体使用场景的最佳设置。它具备强自主性和高智能,又不会像 max 那样在长 agent 运行中产生失控的 token 消耗。max:在真正困难的问题上能再榨出一些性能,但回报递减,且更容易出现过度思考。建议有意识地用于例如:在 evals 中测试模型能力上限、对智能极度敏感且不计成本的任务等。如果你正在升级到新模型,我们建议你尝试不同 effort 级别,而不是简单沿用旧设置。同一任务期间也可以在不同 effort 级别间切换,以更高效地管理 token 用量和推理深度。
我们之所以将 Opus 4.7 的默认 effort 设为 xhigh,是因为我们认为这是绝大多数编码任务的最佳设置。如果你是已有的 Claude Code 用户但没有手动设置 effort 级别,系统会自动将你升级到 xhigh。你仍然可以手动调整。
Opus 4.7 不支持带固定思考预算的 Extended Thinking。 取而代之的是自适应思考(adaptive thinking)。它让”思考”在每一步都成为可选项,模型可以根据上下文自行决定何时投入更多思考。它能快速回应简单查询、在某一步用不上思考时跳过思考,并把思考 token 投入到最可能产生价值的地方。在一次完整的 agent 运行中,这能积累成更快的响应速度和更好的用户体验。
本次版本中,自适应思考有显著改进——尤其是 Opus 4.7 不再那么容易过度思考。
如果你想更精细地控制思考频率,可以直接在 prompt 中明确要求:
Opus 4.6 与 4.7 之间有一些默认行为发生了变化。如果你为旧模型精心调校过 prompt 或编排框架,这些变化值得关注。
回复长度会按任务复杂度校准。 Opus 4.7 不像 Opus 4.6 那样默认啰嗦。简单查询会得到更短的答案,开放式分析则会得到更长的回应。如果你的使用场景依赖特定的长度或风格,请在 prompt 中明确说明。我们发现,提供你想要的语气的正面示例,比”不要这样做”的负面指令效果更好。
模型调用工具的次数变少,推理变多。 在很多情况下这反而带来更好的结果。如果你想要更多的工具使用(比如在 agent 工作中更激进地搜索或读取文件),请明确说明何时以及为何应该使用该工具。
默认情况下,它派生子 agent 的次数变少。 Opus 4.7 在何时把工作委派给子 agent 这件事上更加审慎。如果你的使用场景能从并行子 agent 中受益(例如对多个文件或独立条目并行处理),建议明确写出来。例如:
不要为单次响应中可以直接完成的工作派生子 agent(例如重构一个你已经能看到的函数)。当需要并行处理多个条目或读取多个文件时,在同一轮中派生多个子 agent。
Opus 4.7 在长时间运行的任务上比此前模型表现更好。这让它非常适合那些过去因为需要持续监督而成为瓶颈的任务,比如复杂的多文件改动、含糊的调试问题、跨服务的代码评审,以及多步骤的智能体工作。
我们建议把 effort 保持在 xhigh,看看你的第一轮输入能把任务推进到多远。
更多内容请参阅我们的 Opus 4.7 提示词指南,以及关于 Claude Code 中上下文与会话管理的文章。
2026-03-10 19:09:00
大家好，我是 Jerry 
今天想跟大家分享一个我刚发布的小工具——Coding Agent Communicator。
痛点相信很多同学在使用 AI 编程助手（比如 Cursor、Claude Code）的时候，会有这种感觉：
“AI 生成的代码是能跑，但我想在某个具体位置加个标注，告诉它’这里要改’，该怎么表达？”
截图画红圈？贴代码？描述具体位置？
太累了。
解决方案Coding Agent Communicator 就是来解决这个问题的。
它是一个 Chrome 插件，安装之后，你可以：
在页面上直接选取元素并标注，指出要修改的地方
添加可视化注释
把这些信息一键复制后发送给你的 Coding Agent就像这样：
点选一个元素：”这里改成圆角” → 复制 → 发送 → AI 自动理解并修改
所见即所得，所想即所得。指哪改哪。
像谁？如果你用过 VisBug，可能会有熟悉感。但它的定位更偏向”设计debug”，而 Coding Agent Communicator 是专门为 AI 协作场景设计的：
怎么用？完全免费，无需配置，装好就能用。
未来计划目前是 v1.0，基本功能已经跑通。
如果你有想法，欢迎来 GitHub 提 Issue 
GitHub – aooyoo/coding-agent-communicator
最后做这个插件的契机很简单：我在用 Cursor/Claude Code 的时候，总觉得”表达我要什么”比”写代码”还累。
希望能帮到有同样困扰的同学。
如果你觉得有意思，求个转发～ 
谢谢大家！
2026-02-24 12:34:00
正月初八，开工大吉！
Claude Code 发布正好一周年了。
这一年，CLI Agent 帮我们搞定了不少 coding 和系统维护工作。
直到上个月 OpenClaw 爆火，我们正式进入了个人 Agent 时代。
但说实话，OpenClaw 使用门槛有点高。
安装部署麻烦，用起来也偏技术，普通人根本玩不转。
春节期间突发奇想，我就做了这个东西。
TurboClaw 是最新的个人 Agent 客户端。
说白点，把用 OpenClaw 类 Agent 的门槛直接降到 0。
安装包只有 10MB，下载就能用。
自带免费基础模型，不用配置大模型 API Key 也能跑。
内置实用热门skills，开箱即用。
本地文件访问、编辑、整理、系统级命令行权限，这些都有。
你可以用它整理桌面、清理缓存、操作任意文件夹。
它支持个性定制、长期记忆、主动性的心跳机制、定时任务。
多会话管理、多模型、多语言，也都支持。
最爽的是，可以用你熟悉的聊天 App 随身控制。
Telegram、Discord、飞书、钉钉、QQ，这些消息应用都支持。
设置里填个 Token 或 App ID，就能开启远程控制模式，立即拥有随时待命的AI同(niu)事(ma)。
新手友好，连 @BotFather 创建机器人都有提示。
支持 Zhipu（智谱）、OpenAI、Anthropic、DeepSeek、OpenRouter 这些主流供应商。
默认内置 glm-4.7-flash，开箱就能免费体验。
目前只支持 Apple Silicon 的 Mac。
下载地址：https://github.com/aooyoo/TurboClaw/releases/tag/v1.0.0（点击阅读原文直接前往）
安装很简单，双击解压，把 app 拖到应用程序文件夹就行。
首次打开如果提示「无法验证开发者」，点击「完成」后到系统设置-隐私与安全性中选「仍要打开」就行。
源码我也开源了：https://github.com/aooyoo/TurboClaw
有问题或者有功能建议，欢迎交流。
2026-01-27 23:30:00
在本文截稿时，Clawdbot官方已经宣布更名为MoltBot，如果接下来你在其它地方看到MoltBot，那也是它。
上个月在 X 上就刷到过 Clawdbot 的讨论，那时候 Claude Cowork 都还没出。
说实话，第一眼看到这个项目时，我有点怀疑：又是哪个轮子？
真正让我决定试试的，是 Youtube 上看到一个硅谷的博主推荐，他专门买了个mac mini来跑。
于是我在一台老 Intel MacBook 上装了 Clawdbot。（先说，不用另买mac mini，老mac/vps/树莓派/WSL2都行。至于为什么不推荐在主力电脑上安装，主要是因为它权限太高，容易把你的工作环境弄坏。）
然后就开始踩坑。
官方的安装命令在 macOS 11.7 上直接编译失败，Node.js 依赖各种报错。折腾了一晚上，最后手动装了 nvm 和 Node.js 22.0 搞定。
如果你也遇到了同样的问题，直接跳到「安装前准备」那一节，我写了详细的解决方案。
装完之后，我真香了。
Clawdbot 本质上是一个基于 CLI 的桌面 Agent，但它打通了 Telegram、WhatsApp 这些消息服务。
啥意思呢？
你可以在手机上给 Telegram 发一条消息，家里的电脑就开始干活了。
和 Claude Code 的核心区别：
| 特性 | Clawdbot | Claude Code |
|---|---|---|
| 消息集成 |
 Telegram/WhatsApp/Discord等 |
 无 |
| 远程控制 |
随时随地 |
只能本地 |
| 记忆系统 |
改进版 |
会话级 |
| 本地权限 |
更多 |
受限/请求授权 |
| 费用 |
使用现有订阅（ChatGPT/GLM等） |
Cowork 需会员 |
说白了，它就是一个「随时能联系上的 AI 助手」。
常见坑：Node.js 版本问题如果你用的是老版本 macOS（11.7 或更早），官方安装命令大概率会失败。
我的报错是这样的：
gyp ERR! build error
gyp ERR! stack Error: `make` failed with exit code: 2解决方案：手动安装 Node.js 22
# 1. 安装 nvm
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
# 2. 重新加载终端配置
source ~/.bashrc # 或者 source ~/.zshrc
# 3. 安装 Node.js 22
nvm install 22
nvm use 22
# 4. 验证版本
node --version # 应该显示 v22.x.x为啥不用官方的 Node.js 安装包？
因为老版本 macOS 上，某些原生依赖编译不过。官方安装包24+在老版本上也不支持。nvm 会下载预编译的二进制文件，直接绕过这个问题。
curl -fsSL https://clawd.bot/install.sh | bash或者用 npm：
npm install -g clawdbot@latestWindows 用户（PowerShell）：
iwr -useb https://clawd.bot/install.ps1 | iexclawdbot --version如果能看到版本号，说明安装成功了。
Clawdbot 提供了一个 onboarding wizard，会一步步引导你配置：
clawdbot onboard --install-daemon向导会让你选择：
我用的是 GPT-4，直接用 ChatGPT 登录授权就行。
强烈推荐先用 Telegram 试手，因为配置最简单。
向导会问你要不要安装后台服务（launchd/systemd），建议选 Yes。
这样 Clawdbot 会开机自启动，不用每次手动运行。
@BotFather
/newbot
MyClawdbot）1234567890:ABCdefGHIjklMNOpqrsTUVwxyz复制这个 Token，一会要用。
如果你用了 onboarding wizard，直接在向导里输入 Token 就行了，超简单。
如果已经完成了向导，想手动加一个 Telegram Bot，可以这样：
# 编辑配置文件
nano ~/.clawdbot/clawdbot.json添加 Telegram 配置：
{
"channels": {
"telegram": {
"token": "你的_Bot_Token"
}
}
}clawdbot gateway --port 18789 --verbose如果安装了后台服务，Gateway 应该已经在运行了。可以用这个命令检查：
clawdbot statushello
重点来了：第一次对话会返回一个 pairing code（配对码）。
别慌，这是正常的。Clawdbot 默认开启安全模式，陌生 DM 需要手动批准。
批准配对：
clawdbot pairing approve telegram <配对码>然后你再发一条消息，Bot 就会正常回复了。
# 查看 Gateway 状态
clawdbot status
# 健康检查
clawdbot health
# 安全审计
clawdbot security audit --deepClawdbot 提供了一个 Web 控制面板：
clawdbot dashboard然后在浏览器打开 http://127.0.0.1:18789/
你可以在 Dashboard 里：
现在你可以：
在手机上给 Telegram Bot 发消息：
帮我看看 ~/Documents 里有什么文件家里的电脑就会执行这个命令，然后把结果发回给你。
这太爽了。
如果你用的是 macOS，后台服务会自动管理。
如果想手动启动：
# 前台运行（调试用）
clawdbot gateway --verbose
# 后台运行
clawdbot gateway --daemon# 实时查看日志
tail -f /tmp/clawdbot/gateway.log
# 或者用 clawdbot 命令
clawdbot logs --follow~/.clawdbot/clawdbot.json
~/clawd（存放你的 skills、prompts、memories）~/.clawdbot/credentials/
~/.clawdbot/agents/<agentId>/sessions/
# 如果你用的是安装脚本
curl -fsSL https://clawd.bot/install.sh | bash
# 如果你用的是 npm
npm update -g clawdbot@latest原因 1：没批准配对码（最常见）
clawdbot pairing list telegram
clawdbot pairing approve telegram <配对码>原因 2：Gateway 没运行
clawdbot status
# 如果显示 "stopped"，启动它
clawdbot gateway --daemon原因 3：没配置模型授权
clawdbot onboard # 重新配置模型和授权编辑配置文件：
nano ~/.clawdbot/clawdbot.json修改模型配置：
{
"models": {
"defaults": {
"provider": "openai",
"model": "gpt-5.2" // 或其他模型
}
}
}然后重启 Gateway：
clawdbot gateway restart可以。
Clawdbot 支持同时连接 WhatsApp、Telegram、Discord 等多个渠道，想配几个配几个。
配置方式都和 Telegram 类似，在 onboarding wizard 里依次配置就行了。
| 场景 | Clawdbot | Claude Code |
|---|---|---|
| 远程任务 |
手机随时发任务 |
必须在电脑前 |
| 24/7 待命 |
家里电脑一直开着 |
同上 |
| 消息集成 |
Telegram/WhatsApp |
无 |
| 编程能力 |
完整文件操作 |
同样强大 |
| Skills 生态 |
兼容 MCP |
更成熟 |
我的结论：
这是两个不同的技术路线：
| Clawdbot | 豆包手机 | |
|---|---|---|
| 路线 | CLI Agent | GUI Agent |
| 操作方式 | 命令行 | 图形界面 |
| 适用场景 | 开发者、系统操作 | 普通用户、手机操作 |
它们不是竞争关系，而是互补。
我相信未来会出现两者结合的方案。
推荐人群 不推荐人群装好 Clawdbot 之后，我最大的感受是：
随时能联系上的 AI，真的不一样。不是一点点的不同，是「完全不同物种」的那种不一样。
以前用 Claude Code，我得：
现在用 Clawdbot：
体验完全不同。
听起来好像差别不大？
但你试过在外面突然想起来「哎呀，家里有个脚本没跑」，掏出手机就能操作，就知道有多爽了。
而且它本身完全开源且免费，用你现有的AI订阅连接上即可。
如果你之前对 Claude Code、Claude Cowork 又爱又恨，那 Clawdbot 值得认真试一试。
安装（10 分钟左右，需要本地编译依赖）：
curl -fsSL https://clawd.bot/install.sh | bash配置向导（3 分钟）：
clawdbot onboard --install-daemon启动 Gateway：
clawdbot gateway --daemon然后在 Telegram 上给你的 Bot 发第一条消息。
试试看，你会有惊喜。
作者的话：这篇文章是基于我的真实安装经历写的。如果你在安装过程中遇到问题，欢迎在评论区交流。
