Claude Code 一周年复盘：工程师开始指挥 Agent 队伍
Claude Code 发布一周年，Anthropic 找来负责人 Boris Cherny 和产品负责人 Cat Wu 复盘。这期访谈信息密度很高，我认为其中最值钱的一条不是「Agent 树」的规模叙事，而是一个不起眼的小习惯：把每次犯错写回 CLAUDE.md。规模的故事听起来更振奋，但决定这套系统能不能长期跑下去的，恰恰是这个容易被忽略的细节。
从单 Agent 到 Agent 队伍：这段叙事我持怀疑态度
一年前 Boris 把 demo 发到 Slack，只有两个人点反应，Cat 委婉地说"简单任务还不错"。一年后，Boris 不再只和一个 Agent 对话，而是让 Agent 提示 Agent，分叉成一棵上千节点的树。控制台从"我写代码"变成"调度一群会写代码的执行者"。
现在我有一支 Agent 军队在做事，一个 Agent 提示另一个 Agent，像一棵有上千个 Agent 的树。
— Boris Cherny
我的看法：「上千节点的 Agent 树」这个数字很抓耳朵，但我觉得它更适合当发布会金句，不适合当能力指标。节点数量本身不代表任何产出质量——一千个 Agent 里如果有一半在重复犯同一个错，规模反而是负债。真正值得记录的信息藏在下一段，Boris 自己也承认了这一点：让规模真正有意义的，不是树有多大，而是错误有没有被写回去。
← 图片可左右拖动查看 →
错误写回 + 真实运行验证：这才是全篇真正的干货
Boris 的核心习惯：Claude 每次犯错，不告诉它"下次别这样"，而是让它把新规则写进 CLAUDE.md 或沉淀成 skill。同一个错误变成下一轮 Agent 能继承的组织记忆，工具用一次，经验留一层。
我把这条排在全篇第一，是因为它是唯一一个「不需要相信 Anthropic 的规模叙事」就能直接照搬的方法——不管你手上是一个 Agent 还是一千个，这个习惯都成立，而且成本几乎为零。相比之下，前面「Agent 树」的故事更依赖 Anthropic 的资源和场景，普通团队复制起来门槛高得多。
每次 Claude 犯错，我不会告诉它下次别这样；我会让它写进 CLAUDE.md，或者做成一个技能。
— Boris Cherny
验证也要往前走：不是单测、lint，而是真的跑起来、触发功能、看到出错再修复。验证能力直接决定授权范围——能跑起环境、复测边界的 Agent，才值得把注意力节省下来。
Everyone codes 与 Routines：听起来很美，但我想问一句谁在兜底
Anthropic 内部最有冲击感的变化是 everyone codes：PM、设计师、财务都在 Claude Code 里直接改系统，卡在排期里的改动开始被离用户最近的人直接推动。
Claude 写代码后，更重要的是你有什么想法；有产品、业务、设计和用户上下文，你会提出更好的想法。
— Cat Wu
Cat 最兴奋的是 routines：监听所有 ticket、GitHub issue、bug report，Claude 主动捡起来修、开 PR、再 ping 给他。入口每上移一层，人从执行细节里再释放一层——技能之上，真正稀缺的是想法。
但这里我想追问一句这次访谈没问的：PM 和财务写的代码，谁来 review？谁为线上事故负责？Cat 说的是「有产品、业务、用户上下文的人会提出更好的想法」，这句话本身没错，但「提出好想法」和「对改动的后果负责」是两件不同的事，访谈把它们悄悄划了等号。如果没有一个明确的责任归属机制，everyone codes 很容易变成「everyone commits，few own」。
Auto Mode 与 Context Minimalism：这条我完全同意
Boris 现在最常用 Auto Mode：不再盯每一步工具调用，启一个 Claude 就转去下一个。团队认为反而更安全——不会被"几乎都该点 yes"的请求淹没，注意力得以精确分配。
当你会接受 99% 的请求时，人的眼睛会自然失焦；Auto Mode 让你只关注最重要的那一小部分。
— Boris Cherny
Boris 与 Cat 都是 context minimalist：只给最少的 system prompt 和工具，再给一种拉取上下文的方式，让模型自己完成探索。不要把 Agent 当助手放在流程旁边——要让流程本身围着它重排。这条我没有异议，「注意力精确分配」和「让流程围着 Agent 重排」是这篇访谈里少数经得起推敲、且跟公司规模无关的通用建议。