AI

I’m Boris and I created Claude Code. I wanted to quickly share a few tips for using Claude Code, sourced directly from the Claude Code team. The way the team uses Claude is different than how I use it. Remember: there is no one right way to use Claude Code – everyones’ setup is different. You should experiment to see what works for you! Do more in parallel Spin up 3–5 git worktrees at once, each running its own Claude session in parallel. It’s the single biggest productivity unlock, and the top tip from the team. Personally, I use multiple git checkouts, but most of the Claude Code team prefers worktrees – it’s the reason @amorriscode built native support for them into the Claude Desktop app! ...

.webp) 工程界有句老话：“缓存统治一切（Cache Rules Everything Around Me）”。在开发 AI 智能体（Agent）时，这句话同样适用。 像 Claude Code 这样需要长时间运行的智能体产品，之所以具有可行性，很大程度上归功于 Prompt 缓存（Prompt Caching）。它允许我们复用之前的计算结果，从而大幅降低延迟和成本。 关于 Prompt 缓存的原理和技术实现，这里不展开。在 Claude Code 团队，我们整个底层架构都是围绕 Prompt 缓存设计的。如果缓存命中率高，成本就能降下来，我们也能为订阅用户提供更宽松的使用限制。为此，我们甚至对缓存命中率设置了告警，一旦低于某个阈值，就会触发紧急故障（SEV）处理。 在优化大规模 Prompt 缓存的过程中，我们学到了很多经验。有些经验甚至有点反直觉，下面就和大家分享。 一、合理安排提示词的结构 Prompt 缓存的工作原理是“前缀匹配”（prefix matching）。API 会从请求的开头开始，一直缓存到你设置的断点。这意味着，内容的排列顺序至关重要。你希望尽可能多的请求，能够共享相同的前缀。 最好的做法是：把静态内容放在前面，动态内容放在后面。 在 Claude Code 里，我们的排列顺序是这样的： 静态系统提示词与工具定义（全局缓存） Claude.md 文件（在项目级别缓存） 会话上下文（在单个会话内缓存） 当前对话的具体消息 通过这种方式，我们能让更多的会话共享缓存命中。 但要注意，这种顺序出乎意料地脆弱！我们曾经踩过坑，破坏了这种顺序。比如：把详细的时间戳放进了静态系统提示词里、工具的排列顺序变成随机的、或者动态修改了工具的参数。这些都会导致前缀改变，缓存失效。 二、用消息来传递状态更新 有时候，你放在提示词里的信息会过期。比如，时间变了，或者用户修改了某个文件。你可能会想，那我去更新一下系统提示词吧。千万别这么做。这会导致缓存未命中，让用户付出高昂的成本。 更好的做法是：在下一轮对话中，通过“消息”来传递这些更新。 在 Claude Code 中，如果信息有更新（比如“现在是星期三了”），我们会在下一条用户消息或工具结果中插入一个 <system-reminder> 标签。这样既告诉了模型新情况，又保住了前面的缓存。 三、不要在对话中途切换模型 Prompt 缓存是和特定模型绑定的。这就导致了一个很反直觉的成本计算。 假设你正在用最强大的 Opus 模型聊天，已经积累了 10 万 token 的上下文。这时，你想问一个非常简单的问题。你可能觉得切换到便宜的 Haiku 模型会更省钱。错了。切换到 Haiku 反而更贵，因为你需要为 Haiku 重新建立那 10 万 token 的缓存。 ...

最近给自己的 Agent 做了一次关键的改造。表面上看，只是新增了一个 Skill Search 工具，但真正改变的，是 Agent 的工作方式。 以前 Skill 的调用非常不稳定。明明已经很明确告诉它"搜索天气"“搜索新闻”，也提供了相应的工具，但它就是不能自动触发。尝试优化提示词、改进 Skill 描述，做了很多尝试，效果都不理想。 后来看到 Claude Code 的源码，里面有一个 Tool Search 机制：每次使用工具之前，先查询一下有没有可用工具。受这个启发，我做了一个 Skill Search 工具，希望在 Agent 触发能力边界时——比如需要搜索网络、写脚本、调用外部命令时——先检查有没有现成 Skill 可以用，而不是从头造轮子。 核心问题 原来的 Skill 调用机制是这样的：把所有 Skill 的名字和描述都塞进系统提示词里，然后告诉模型"如果当前任务适合某个 Skill，就优先使用"。 这个思路一开始是成立的，模型确实"看得到"这些 Skill，也能在某些场景下主动调用。但真正用久了之后，问题就暴露出来了。 只有显式调用才稳定。当直接输入 /web-search 或明确指定某个 Skill 时，没问题——因为这时候不是模型在判断，而是用户替它做了决策。但真实使用中，用户更常见的表达是： “帮我搜一下这个话题” “去网上查一下最近有什么信息” “看看有没有现成工具能做这件事” “帮我处理一下这个文件” 这些输入对人类来说已经足够明确，大家都知道这时候应该优先检查 Skill。但模型不是每次都这么做。很多时候，明明已经有现成 Skill，它还是直接跳过去，自己动手。 根本原因不是 Skill 描述不够好，而是机制本身有问题。 原来的调用流程太长了：模型先看用户输入，再判断是否需要执行任务，再回忆提示词里有没有对应 Skill，再匹配描述，最后才决定要不要调用。只要其中任何一步松掉，它就会进入更省事的路径：自己来做。 随着 Skill 越来越多，问题还会继续恶化。Skill 越多，提示词越长，模型越容易漂移。这些 Skill 只是混在上下文里的动态信息，对模型来说不是强制执行的流程，只是可能参考的背景材料。 改造方案 核心上做了三件事。 1. 从隐式到显式 把 Skill 从"提示词中的隐式能力"变成"运行时中的显式能力"。新增真正的 skill_search，让 Agent 在面对非纯文本任务时，不是默认自己动手，而是先查有没有现成 Skill。 ...

我一开始以为，给 Agent 加 Sandbox 这件事并不复杂： 把 bash 套进隔离层 限一下文件系统 限一下网络 再处理一下环境变量 但真把它放进一个真实产品里，问题马上就不是“能不能隔离”，而是： 既要让 Agent 真能干活，又不能让它顺手把宿主机掀了。 这次我在自己的 Agent Runtime 里，先后被两个非常具体的场景逼着重构权限模型： curl 在沙箱里访问网络，一直报错 agent-browser 要打开网页并截图，但它本质上不是普通网络请求，而是宿主浏览器能力 最后我做出来的，不只是一个 Shell Sandbox，而是一整套： bash 执行边界 Host Capability 审批 白名单复用 自动续跑 配置脱敏 多渠道结构化审批 这篇文章，我就完整讲讲这套东西是怎么从真实问题里长出来的。 我在真实 Agent 产品里落地 Sandbox 的全过程 从 curl 报错，到 agent-browser 审批升级，我是怎么把权限、审批、配置安全真正做成产品能力的 如果你最近在做 Agent，而且这个 Agent 不是纯聊天，而是真的会： 调 bash 装依赖 读写文件 连网 调本机工具 打开网页、截图、控制浏览器 那你迟早会遇到一个问题： “让 Agent 能干活”和“让 Agent 不乱来”之间，根本不是加一个开关就能解决的。” 一开始我也以为，所谓 Sandbox，无非就是： 把 bash 套进一个 OS-level sandbox 限文件系统 限网络 再处理一下环境变量 听上去很合理。 但真把它放进一个真实产品里，你很快就会发现： ...

过去一年，Agent 的能力边界被迅速拉高。它不再只是“会聊天的大模型”，而是在越来越多的场景里真正拥有了“手脚”：能写代码、改文件、跑测试、装依赖、发请求，甚至直接操作本地终端。 但问题也恰恰出在这里。 一旦 Agent 可以直接在开发机上执行命令，它就不再只是一个推理系统，而变成了一个半可信执行体：正常情况下它是高效助手，异常情况下它也可能是一个“拿着系统权限的自动脚本”。模型幻觉、Prompt Injection、第三方仓库里的恶意指令、错误的工具调用路径，都会把风险从“回答错了”升级为“真的把你的环境改坏了”。 于是，一个绕不开的问题摆在所有 Agent 产品面前： 怎么让 Agent 真正自动化地干活，同时又不把宿主机暴露在不可控风险里？ 这就是 Agent Sandbox 的价值所在。 “系统安全能力的下限，决定了 Agent 自动化能力的上限。” 问题 在没有成熟沙箱之前，最常见的办法是“人工确认”：Agent 每执行一步命令，每改一次文件，都弹窗询问用户要不要继续。 这种做法看起来安全，但实际上只解决了心理安慰，并没有真正解决底层风险。 第一，它会快速演变成严重的中断疲劳。一个稍微复杂一点的重构任务，可能要经历十几次读写文件、数十次 shell 调用、若干次网络请求。每一步都确认，Agent 的自动化价值会被彻底抵消。 第二，它对真实攻击并不可靠。开发者并没有足够的时间在一秒钟内审完一长串 bash 命令，更不可能靠肉眼持续识别被混淆过的脚本、链式调用或隐蔽的外带逻辑。换句话说，弹窗确认本质上是在把安全责任转嫁给用户，而不是在系统层面建立边界。 真正可持续的方案不是“每一步都问你”，而是： 默认把 Agent 放进一个边界明确的运行区域； 边界内自动执行，不打扰用户； 一旦越界，由底层机制直接拦截，而不是事后追责。 这就是现代 Agent 沙箱的核心设计目标：把安全从“交互层提醒”下沉到“执行层约束”。 方案演进 从当前行业实践看，Agent 沙箱大致形成了三条路线。它们并不是谁绝对淘汰谁，而是分别适合不同的产品形态。 1. 容器型沙箱 这一类方案通常基于 Docker 或容器池，把代码执行环境封装进独立容器，再通过 API 或任务调度系统与 Agent 主流程解耦。 它的优势很明显：环境一致性好，依赖管理成熟，易于做多租户调度，也方便把环境变量、文件系统和网络策略统一配置。很多云端 Agent 平台、代码执行服务、Browser + Code 一体化沙箱都属于这一路线。 但它的局限同样明显： 如果你的目标是“让 Agent 直接辅助用户本地开发”，Docker 会显得偏重。你需要处理 volume 映射、UID/GID、路径同步、宿主文件状态与容器视图的一致性，以及本地开发工具链与容器内部环境的错位问题。它更适合“把任务送进一个隔离盒子里执行”，而不天然适合“在用户当前工作区无缝协作”。 2. MicroVM 型沙箱 这一类典型代表是 Firecracker 体系或基于它的代码执行平台。它的优势是隔离强度极高，接近虚拟机级别，天然适合云端多租户场景，也更适合执行不可信代码。 ...

有些问题看起来很小。 比如这次，表面上只是 Skill Draft 的 name 不好用。 但顺着查下去，它其实暴露了一个更底层的问题：我们到底是在“记录一次对话”，还是在“沉淀一个以后能复用的工作流”？ 这两件事长得很像，但对系统来说完全不是一回事。 改动前：草稿名来自用户原话 之前 Molibot 会在一次复杂运行成功后，自动保存一个 Skill Draft。 它的目标是把这次跑通的流程沉淀下来，之后遇到类似任务时，不用每次都重新摸索。 问题出在草稿 metadata，尤其是 name。 当用户发出这样的消息： 为什么没有昨日数据回顾，只有今天的数据，我这个是要有昨日数据回顾的，要在第一条就列出来昨日数据 系统生成的草稿名会接近： name: 为什么没有昨日数据回顾-只有今天的数据-我这个是要有昨日数据回顾的-要在第一条就列出来昨日数据 另一个更典型的例子是： 重试一下 它也可能变成： name: 重试一下 这显然不是一个 Skill 名。 Skill 的 name 应该是稳定的功能标识，比如： name: yesterday-data-review 用户原话可以保留，但它应该出现在触发描述、示例、上下文里，而不是变成 Skill 的主标识。 为什么必须改 Skill Draft 不是聊天记录。 聊天记录关心的是“用户当时怎么说”。 Skill Draft 关心的是“这次跑通了什么可复用能力”。 如果 name 直接来自用户原话，会带来几个实际问题。 第一，名字不可读。 长句、抱怨、纠错、口语化表达都会进入 name。设置页里扫一眼，根本看不出这是哪个能力。 第二，后续触发不稳定。 Skill 的 metadata 是触发系统理解它的重要入口。重试一下 这种名字既不能描述能力，也不能帮助模型判断什么时候该用它。 第三，草稿无法自然升级成正式 Skill。 草稿阶段可以粗糙一点，但不能粗糙到主标识不可用。否则每次 Review 都要人工重命名，自动沉淀的价值就打折了。 第四，和 skill-creator 规范不一致。 项目里已经声明创建 Skill 要遵守 skill-creator 规范：name 是 skill identifier，description 才负责说明功能和触发场景。 ...

从原始数据到智能对话——ChatGPT、DeepSeek、Qwen 这类大模型是怎么"炼"出来的？ 当你在手机上向 AI 助手提问，它能流畅地回答、写代码、做分析，这背后是一套复杂而精密的训练工程。本文将从工程视角，完整拆解大语言模型（LLM）的训练过程，包括每一步在做什么、需要哪些数据、依赖哪些技术基础设施。 一、先搞清楚两个大阶段 LLM 的训练通常分为两大阶段： 预训练（Pre-training）：让模型"博览群书"，获得通用知识与语言能力 后训练（Post-training）：让模型"上岗培训"，学会按指令回答、安全礼貌地与用户交流 后训练的计算量只有预训练的约 5%，但它决定了模型的实际可用性，也是近年来研究最活跃的方向。[1] 二、六大训练步骤详解 第一步：数据收集与预处理 一切从数据开始。训练一个现代大语言模型，需要数万亿（Trillions）个 Token 的文本语料。[2] 数据来源包括： 通用网页文本：Common Crawl、C4 等互联网爬虫数据集 书籍与学术文献：Books3、ArXiv、PubMed 等 代码：GitHub 公开代码仓库、Stack Overflow 问答 百科全书：多语言 Wikipedia 原始数据质量参差不齐，必须经过严格的清洗流程： 去重：使用 MinHash / SimHash 去除重复内容，防止模型过拟合 质量过滤：基于困惑度（Perplexity）、规则过滤低质量内容 语言识别与分类：按语言比例混合多语言数据 Tokenizer 训练：使用 BPE（字节对编码）或 SentencePiece 训练分词器 这一步的产出： TB 级别的清洁语料库 + 训练好的 Tokenizer。 第二步：大规模预训练 这是整个流程中计算量最大、成本最高的环节，通常需要数千块 GPU 运行数周甚至数月。 核心原理： 自回归语言建模（Autoregressive Language Modeling）——给模型看一段文本，让它预测下一个 Token 是什么。通过在海量文本上反复迭代，模型逐渐学会了语言规律、世界知识、逻辑推理。[3] 关键技术组件： 组件 作用 Transformer 架构 多头注意力（Multi-head Attention）+ 前馈网络（FFN） RoPE 位置编码 让模型理解 Token 之间的位置关系 RMSNorm 归一化 稳定训练过程，替代传统 LayerNorm Flash Attention 2/3 IO 感知的高效注意力算法，2-4 倍提速 GQA 分组查询注意力 减少 KV Cache 占用，提升推理效率 混合精度训练（BF16） 节省显存，加速计算 这一步的产出： 基础模型（Base Model）。它掌握了丰富的知识，但只会续写文本，不会听指令。 ...

起因 前几天，Karpathy 发了一条推。 他讲自己怎么用 LLM 管个人知识库，用了一个词：编译（Compile）。意思是，把原始资料"编译"成结构化知识。Obsidian Vault 是代码仓库，LLM 就是编译器。 我看完愣了一下——这不就是我最近几个月一直在折腾的事吗？我一直在做一个流程，把 raw 资料变成 wiki 条目，只是一直没找到一个好的词来概括。现在有了：知识编译。 然后我就做了一个程序员会做的事：把它做成了 Obsidian 插件。 思路 传统管理知识库的方式，大家应该都不陌生：你积累了 500 篇笔记，然后加标签、建链接、分类整理，再然后……三个月后放弃了，笔记库慢慢腐烂。 编译方式不一样。你只管把原始资料丢进 raw/ 目录，LLM 负责读取、提炼、交叉引用，自动产出结构化的 wiki 页面。你只需要做两件事：喂料，提问。 这跟写代码一模一样。raw/ 是源码，wiki/ 是编译产物，index.md 是目录清单，log.md 是构建日志，编译器是 LLM。你不会手动把 .java 文件逐行翻译成 .class——同理，你也不应该手动给 500 篇笔记加标签。 三层目录，各管各的 先看一下目录结构： Vault/ ├── raw/ # 原始资料，人类添加，LLM 自动归类 │ ├── tech/ # 技术文章、论文、教程 │ ├── work/ # 工作相关文档 │ ├── reading/ # 读书笔记、播客笔记 │ ├── general/ # 其他内容 │ └── assets/ # 图片附件 │ ├── wiki/ # 编译产物，完全由 LLM 维护 │ ├── summaries/ # 每篇源文件的结构化摘要 │ ├── concepts/ # 概念页面（跨源综合） │ ├── entities/ # 人物/工具/框架页面 │ ├── comparisons/ # 对比分析 │ └── analysis/ # 深度分析（从好的问答中沉淀） │ ├── legacy/ # 已有的旧笔记库，冻结存档 ├── drafts/ # 碎片想法，人类专属 ├── CLAUDE.md # LLM 的"编译规范" ├── index.md # Wiki 主索引 └── log.md # 操作日志 我定了一个很严格的 ownership 规则： ...

 开发一个智能体（Agent）系统，最难的部分之一，就是怎么给它设计"工具箱"（Action Space）。 Claude 是通过调用工具（Tool Calling）来做事的。但在 Claude API 里，有各种各样的工具构建方式，比如执行 bash 命令、调用 Skills，或者最近新出的代码执行功能。 面对这么多选择，你怎么给 Agent 设计工具？是只给它一个全能工具（比如直接执行代码或 bash），还是给它 50 个工具，覆盖它可能遇到的每一种场景？ 为了弄明白这个问题，我喜欢把自己代入模型。想象一下，如果给你一道很难的数学题，你希望手头有什么工具？这其实取决于你自己的能力！ 给你一张纸是最低配置，但你只能手算。给你一个计算器会好很多，前提是你得知道怎么按那些高级功能键。最快、最强大的工具是一台电脑，但这要求你必须懂编程，能写代码来解题。 这是一个设计 Agent 时非常有用的思维框架。你给它的工具，必须跟它的能力相匹配。 可是，你怎么知道它有多大能耐呢？答案是：去观察它，去读它的输出，去不断实验。你要学会"用 Agent 的眼光看世界"。 在开发 Claude Code 的过程中，我们一直在观察 Claude。下面是我们学到的一些经验。 改进提问方式与 AskUserQuestion 工具 我们在开发 AskUserQuestion 这个工具时，目标是让 Claude 更擅长向用户提问（这通常被称为激发，elicitation）。 虽然 Claude 本来就能用纯文本问问题，但我们发现，回答这些问题通常很费时间。我们该怎么降低这种摩擦，让用户和 Claude 的沟通更高效呢？ 尝试 1：修改 ExitPlanTool 我们最初的想法是，在现有的 ExitPlanTool（退出并输出计划的工具）里加一个参数，让它在输出计划的同时，也输出一组问题。这是最容易实现的方法，但它把 Claude 搞糊涂了。因为我们让它同时做两件事：一边给计划，一边问跟计划相关的问题。如果用户的回答和计划冲突了怎么办？Claude 是不是得再调用一次 ExitPlanTool？显然，这条路走不通。 尝试 2：改变输出格式 接着，我们尝试修改 Claude 的系统提示词，让它输出一种特定格式的 Markdown，用来表示问题。比如，我们可以要求它输出一个列表，括号里写上可选项。然后我们通过解析这个格式，在终端里渲染出一个漂亮的提问界面。 这看起来是个通用的改动，Claude 似乎也能做到，但这并不可靠。Claude 有时会多加几句话，有时会漏掉选项，或者干脆用了别的格式。 尝试 3：推出 AskUserQuestion 工具 ...

原文：/Users/zongxiaocheng/Library/Mobile Documents/iCloudmdobsidian/Documents/AI 常见名词解释.md 重写说明：基于原文重写，去掉了学术和翻译腔。梳理了从基础概念、模型训练到 Agent 工程化的逻辑线，用大白话解释了这些常见的 AI 术语，让内容更易读。   用大白话解释常见的 AI 术语 你最近肯定听过很多 AI 词汇。你大概知道它们是什么意思，但可能又没那么确定。 这篇文章用最通俗的话，把这些满天飞的 AI 黑话解释清楚。下次开会再听到这些词，你就不用一头雾水了。 基础与核心概念 什么是模型（Model）？ AI 模型就像一个模仿人脑工作的计算机程序。你给它一个输入，它处理一下，然后给你一个输出。 模型像小孩子一样，通过看大量例子来“学习”。看得多了，它就能认出模式、理解语言，并给出合理的回答。 模型有很多种。处理文字的叫大语言模型（LLM），比如 ChatGPT。处理视频的叫视频模型，比如 Sora。还有传统的用来推荐内容和识别垃圾邮件的模型。 大语言模型（LLM） 全称是大语言模型（Large Language Model）。它专门用来理解和生成人类能看懂的文字。 现在大多数 LLM 已经不只懂文字了。它们变成了“多模态”模型，可以同时看懂图片、听懂声音，甚至直接用语音和你对话。 Transformer 架构 这是 Google 在 2017 年发明的一种算法，也是现代 AI 爆发的基础。 它引入了“注意力机制”。以前的 AI 只能挨个看句子里的词，而 Transformer 可以同时看完所有词，并理解词和词之间的关系。这就让它能更好地把握上下文和细微差别。 它还能“并行处理”。这意味着只要堆算力和数据，就能训练出更大、更聪明的模型。如今几乎所有主流 AI 模型都是基于它构建的。 Token（词元） Token 是 AI 理解文字的最小单位。 对于英文来说，一个 Token 有时是一个词，有时只是词的一部分。比如“ChatGPT”可能会被切成“Chat”和“GPT”两个 Token。把它切碎，是为了让模型处理起来更高效。 现在还都在争论 Token 怎么翻译的问题，暂时可以先忽略这个中文翻译 模型是怎么变聪明的？ 训练（Training / Pre-training） 训练就是让模型看海量的数据，比如整个互联网的网页、所有的书。这个过程可能要花几个月，烧掉几亿美金。 ...