Agent

引言 在《Claude Code 高效使用指南》里，讲了 CLAUDE.md、Skills、Hooks、Subagents 这些上层扩展能力怎么配置和组合。 但你有没有想过一个问题：这些东西底下，Claude Code 到底是怎么跑起来的？ 一个几百万行的 monorepo，Claude Code 怎么知道该读哪个文件？一个长会话跑了几百轮，为什么不会越来越慢、越来越贵？为什么 Claude Code、Codex 这些最火的 Agent 产品，不约而同都选了命令行？ 这三个问题，指向同一个答案：Agent 的底层工程，才是真正拉开差距的地方。 这篇文章就把这三层机制拆开讲清楚。 一、大代码库：Claude Code 不靠索引，靠 Agentic Search 很多人第一反应是：大代码库是不是要先建索引、做向量化、上 RAG？ Anthropic 给了一个很明确的答案：不是。 为什么索引方案在大代码库里容易失效 索引方案有一个致命的假设——代码是静态的。但大规模活跃代码库里，几千个工程师每天都在改代码：函数今天改名，模块明天迁移，旧服务后天删掉。如果索引管线跟不上，模型拿到的是旧世界的地图——它可能引用一个两周前已经改名的函数，也可能调一个上个 sprint 已经删掉的模块。 更麻烦的是，召回结果本身不会告诉你：“我过期了。” Agentic Search：像工程师一样边搜边读 Claude Code 的思路更像一个真实工程师的工作方式： 先看报错关键词 用 grep 找相关接口 读调用链上的关键文件 找到核心逻辑 看测试怎么覆盖 修改最小范围 跑对应测试 它不是在某个中心索引里检索答案，而是在开发者机器上的实时代码库里工作。用 Anthropic 的话说，这叫 Agentic Search——不是"先把答案搜出来给模型"，而是让 Agent 自己根据当前任务，一步一步决定下一步该搜什么、读什么、验证什么。 大代码库的关键不是"看更多"，而是"找得准" 很多人觉得大代码库需要更大的上下文窗口。窗口大当然有用，但真正的问题不是"放不下全部代码"——因为无论窗口多大，你都不应该把整个仓库塞进去。 真正的问题是：Claude Code 能不能在读很少文件的情况下，找到真正相关的那几个文件？ 所以大代码库要做的是上下文治理： 该加载的规则提前加载 不相关的目录不要读 生成代码和构建产物要排除 测试命令要按子目录收敛 同名函数要靠 LSP 区分 大范围探索交给 subagent 太多上下文会降低性能，太少上下文会让 Claude 盲搜。 这句话很适合放到团队规范里。 ...

引言 这个系列已经讲了 Claude Code 的底层机制、扩展能力的工程演进、以及自动编排与防失控。但一直缺一个东西：真实的、大规模的生产案例。 Anthropic 最近两篇博客正好补上了这个缺口。一篇讲他们怎么用 Claude Code 把百万行代码从 Zig 迁到 Rust；另一篇讲他们新推出的 Managed Agents——一套帮团队把 Agent 从原型变成生产级服务的基础设施。 这两篇放在一起看，就是 Claude Code 从"个人工具"走向"生产平台"的完整路线图。 一、百万行代码迁移：不是翻译，是生产线 先看几个数字： Bun 的 Jarred Sumner 用 Claude Code 把项目从 Zig 迁到 Rust，不到两周产出 100 万行代码，合并前 CI 中所有原有测试通过。另一个案例，Anthropic Labs 的 Mike Krieger 用一个周末，把 Python 代码库迁成了 16.5 万行 TypeScript，跑了数百个 Agent、8 道阶段闸门、3 轮对抗审查。 Anthropic 过去一个月一共迁了 10 个代码包，每个都有数万到数十万行。 注意，这不是"Claude 一次把代码翻译对了"。真正让规模迁移成立的，是它把迁移改造成了一条可以反复运行、机械验收、失败后继续收敛的生产线。 人不再追着每个文件改。人负责规则、裁判和异常模式，Agent 负责把队列烧完。用原文里最值钱的一句话：别修代码，修产生代码的循环。 为什么代码迁移特别适合多 Agent 大规模迁移刚好满足 Agent 最喜欢的几个条件： 工作能并行：上千个文件可以切成独立批次 旧代码就是规格：原程序已经把行为写出来了，Agent 可以同时对照源语言、目标语言和真实输出 有机械裁判：编译器、冒烟测试、完整测试套件、命令输出 diff，都能明确告诉 Agent 对还是错 规则可以向后传播：一个 Agent 发现边界问题，不是只补当前文件，而是把解法写回迁移规则，后面所有 Agent 都按新规则执行 这也是它和普通"批量翻译代码"的根本区别：并行只负责提速，统一规则和机械验收才负责不失控。 ...

引言 这个系列已经讲过 Claude Code 的底层运行机制和四层扩展能力的分工。但到这里还有一个问题没解决：当任务复杂到单个 Agent 扛不动，你怎么编排？编排完了，你怎么保证它不跑偏、不偷懒、不越界？ 这两个问题，对应 Claude Code 最近两个最重要的能力：动态工作流（Dynamic Workflows）和 Loop Engineering。 一、动态工作流：Claude 自己写 harness，你只负责目标和边界 harness 是什么？就是控制 Claude 读什么、什么时候动手、产出怎么验证的那层编排。Claude Code 自带的默认 harness 打磨得很好，但它是冲着"写代码"这件事调出来的。 而你实际让 Claude Code 干的活远不止写代码：深度调研、安全审计、代码迁移、多人评审。这些任务的"最佳跑法"和写代码不一样。过去要把它们做到极致，你得自己手搓一套 harness。 动态工作流的意思就一句话：这套针对任务的 harness，不用你手搓了，Claude 自己现场写。 工作流是真代码，不是提示词 关键区别：动态工作流是 Claude 现场生成、然后真的拿去执行的 JavaScript 文件，不是"一段精心调过的提示词"。它有三个基本积木： agent(prompt, opts)：开一个子 Agent，给它独立上下文窗口，还能用 JSON Schema 约束输出结构 parallel(...)：栅栏——几个任务全跑完才放行 pipeline(items, ...)：流水线——让一批东西过几道工序，A 项先走，B 项慢一点也不挡道 Claude 拿这几块积木，针对你的任务搭出一套编排：要不要开子 Agent、开几个、哪步用强模型哪步用便宜模型、要不要用 git worktree 把不同方案隔开、哪些并行哪些串行——这些不是你预先规定死的，是 Claude 分析完任务自己定的。 为什么非得这么折腾？单个上下文扛不动 长任务里，一个 Claude 单挑全部时，老三样毛病会准时冒出来： 偷懒：审 50 个文件审到 35 个就说"干完了"——不是模型坏了，是上下文塞满了，它把"差不多"当成了"做完" 自夸：让 Claude 验自己的活，它会偏向维护自己之前的结论 跑偏：对话拉长，反复压缩摘要，把边界要求、约束条件一点点丢掉 动态工作流的解法是结构性的——与其让一个 Claude 扛全部，不如开一堆互相隔离、各自上下文干净、只盯一件事的子 Agent。隔离让偷懒无处藏，独立的验证 Agent 让自夸自然消失，每个窗口都短让跑偏被摁住。 ...

引言 Claude Code 作者 Boris Cherny 说过一句话：“我已经不写 Prompt 了，我写 Loop。” 这句话被很多人转发，但少有人真正解释清楚它到底意味着什么。Prompt 和 Loop 的差别，不是写一句话还是写一段话的差别——而是两种完全不同的工程思维。 这篇文章就顺着这条线，把三个核心问题讲清楚：Loop 到底是什么、四层扩展能力（CLAUDE.md / Hooks / Skills / Subagents）怎么分工、以及 Skills 到底怎么写才不是废纸。 一、为什么只写 Prompt 不够了？ Prompt 当然有用。你问一个概念、贴一段代码让它改写、让它生成一个 SQL——这些场景里，Prompt 就够了。因为任务短、边界清楚、结果也容易人工判断。 但真实项目不是这样。你让 Claude Code 修一个登录 Bug，往往不是一句话能完成的：先读代码，定位调用链，判断哪个文件该改哪个不能动，修改实现，跑测试——测试失败了还要回头看日志，日志里可能暴露了另一个问题。 这时候你会发现：Prompt 只是任务的起点，不是任务的完成机制。 你只给了它目标，但没告诉它去哪里找入口、哪些文件不能动、怎么判断修好了、测试失败怎么办、什么时候必须停下来。如果这些都靠模型自己猜，它就会浪费大量上下文摸索，或者看起来很努力，最后朝错方向越走越远。 二、Loop 到底是什么 一个最小的 Agent Loop 大概长这样： 目标 → 计划 → 执行 → 观察 → 验证 → 反馈 → 下一步 验证通过就停止。验证失败就把失败信息带回去，重新计划。触碰边界就暂停，让人决策。 这和普通 Prompt 的差别很大。Prompt 是"我说一句，你答一句"。Loop 是"我给你目标、工具、规则和验收标准，你自己推进，但每一步都要留下证据"。 但坏 Loop 比坏 Prompt 更危险。一个坏 Prompt，最多回答不理想。一个坏 Loop，会一直跑、一直改、一直消耗 token，还可能把项目改乱。 ...