在Anthropic，软件构建方式正在改变
Anthropic 的软件开发方式正在改变
AI 工具大幅改善，正在改变我们构建软件的方式。我想一窥：在这种影响下，软件工程的未来会如何展开？最好的观察点莫过于技术圈里“AI 浓度最高”的团队——AI 实验室本身。于是，我走访了两家领先的 AI 实验室，实地看看他们的团队和工程师每天是怎么工作的。在这篇文章以及后续的一篇中，我会分享我的见闻：AI 正在如何重塑许多我们习以为常的软件工程原则——以及在 AI 浪潮下，哪些东西基本没变。稍后我们还会另写一篇，对比 Anthropic 和 OpenAI 的发现，看看它们的工作方式对软件工程的总体方向意味着什么。
感谢 Anthropic 让我走进他们在旧金山的实验室。
我与四个人进行了交流：
- Katelyn Lesse，Claude 平台工程主管，她负责的团队掌管 Claude 运行的基础设施
- Jarred Sumner，Bun 的创造者，目前在 Anthropic 负责 Bun 和 Claude Code
- Thariq Shihipar，同时参与 Claude Code 工程和教育工作
- David Hershey，在 Anthropic 的应用 AI 组织担任类似销售工程师的职位，与 Cursor、Cognition、Perplexity 等客户合作
通过他们，我了解到了这家顶尖 AI 实验室的发展方向——很可能也预示着更广泛行业的走向。
在继续之前说一声：《The Pragmatic Engineer》接下来一个半星期会进入暑期休假。这意味着本周没有周四的文章，下周也没有文章。感谢大家的理解和支持！
回到今天的深度内容，我们讨论：
复杂且漫长：Claude 托管代理（Managed Agents）。Claude 平台团队最复杂的项目之一，花了六个月才交付，并在代理基础设施层创造了一种新的原语。即便在基础设施项目里，中途也需要重新架构，才能做对。
原本12个月的项目，11天完成：Bun 重写为 Rust。把超过50万行代码的项目迁移到另一种语言，以前一个小团队需要一年，根本行不通。
在 Anthropic，软件开发方式正在发生哪些变化
借助 Fable 和 16.5 万美元的 token，项目创建者最近只花了不到两周时间。
工程实践在变
在这家拥有 3500 多名员工的 AI 实验室里，原型搭建更灵活了，验证比实现更耗时，代码审查和测试越来越多地交给 AI 来完成。
团队层面的变化
设计不再是一次性定在前端，而是持续迭代；团队同时参与更多项目，每个项目最多两名工程师，诸如此类。
哪些没变
“两个披萨团队”的规模依然适用，前期的规划仍很重要，复杂项目中产品需求文档（PRD）也还有用武之地；上下文切换依然是个难题，写代码和测试的时间比例变化不大。
“顶尖”软件工程师的形象在变？
深度理解——包括对你工作内容之下那一层的理解——依然很有价值，同时还需要有协调工作的能力。
AI 会取代软件工程吗？
在实验室里，软件工程师越是用 AI 上手干活，就越不担心自己的岗位会消失。
1. 复杂且耗时：Claude Managed Agents
Claude Platform 团队过去一年最复杂的项目，就是构建 Claude Managed Agents。这是一个为生产级智能体（Agent）预置的运行环境，可以在 Anthropic 管理的云基础设施上运行，也可以部署在你团队自己的基础设施上，并搭配你选择的任何沙箱。
项目从构想到 4 月份上线，大约花了六个月时间。Claude Platform 的工程负责人 Katelyn Lesse 分享了这段经历。
与 Katelyn Lesse 的对话——Anthropic Claude Platform
这个团队处于模型/加速层（Claude 模型运行在 GPU 上）与产品/应用层（提供了诸如 Claude Code 和 Claude Cowork 这样的产品）之间：
Katelyn 这样描述 Platform 团队做什么：“我们处于‘token 热路径’上。用户的提示词（prompt）进来，我们把它分词（tokenize），然后像安全防护、计费这些功能都在我们的层里完成。”
Claude 团队所说的“Platform”，我理解更像是“API”。Claude Platform 负责运营 API，并承担 API 应有的职责。当然，这个团队做的事远不止这些，Claude Managed Agents 只是我们在这里要讲的一个案例。
目前，这个平台层正在从 Python 迁移到 Rust。
软件开发方式在Anthropic的变化
最初，这一层是用 Python 写的，原因和其他 AI 公司一样——Python 用起来顺手，AI 研究者本来就在用，迭代快。但 Python 是单线程的，一旦 API 负载高了，性能就不如 Rust。于是团队开始转向 Rust。
运行环境的需求
这个项目之所以成形，很大程度上是因为客户想要自己的“运行环境（harness infrastructure）”。Katelyn 说：“我们最初的模式是，你调用一个 API 来定义 agent，再调用另一个 API 来启动一个 session。但现在市场和客户真正需要的是自己搭建运行环境。所以我们开始构建自托管沙箱。可后来很多客户反馈说，他们正尝试自己拼凑运行环境（hack harnesses together），这让我们想到了打造 Claude Managed Agents。”
规划是最重要的一环
Katelyn 表示，整个项目中最大的部分就是规划：“有些产品你可以直接上手做原型，但有些产品必须先把架构设计清楚。比如说，如果我们要写一个 TypeScript 命令行工具——本身功能比较简单——那可以直接原型开发。但 Claude Managed Agents 不一样，得先想明白究竟要做什么。当然，我们也预先做了一些原型验证：快速试错、技术预研。但这些原型本身更多是为了理清需求。我们的规划过程很像 AI 还没流行时的传统规划流程。你知道那种情况吗？每个团队都有这样一个项目——大家各自提出类似的点子，然后反复讨论、打磨，直到最终落地。Managed Agents 对我们团队来说就是这样的项目。项目启动时，我们手上已经有长达两年的文档，里面记录了大量想法和建议。规划结束后，项目正式启动，我们撰写了一份 PRD（产品需求文档）。Katelyn 说：“最终是我们 API Agents 团队的产品经理和技术主管拍板启动了这个项目。大家坐在一起过一遍文档，对齐目标，就这样开始了。”
在 Anthropic，软件开发方式正在改变
但需要协调的不只是我们自己：我们还必须与业务部门的各个团队、其他云服务提供商以及其他工程团队对齐。举个例子，Platform 组织内有一个沙箱团队——因为 Managed Agents 这个产品会生成大量沙箱，所以团队在设计时咨询了他们。和以前一样，我们有 PRD（产品需求文档），放在 Google Doc 里。用 Google Doc 是因为需要协调所有相关人员。这个习惯并没有消失。同样，我和我的产品搭档会定期做产品评审。” 一些 AI 兴起之前的流程，比如 PRD，在今天复杂的项目中依然有用，能让一大群人达成共识。
先为内部客户构建
规划完成后，团队决定做一个“spike”（快速验证），通过先在网页端构建 Claude Code 的后台来压力测试想法和架构。用 agent 套件远程执行代码，和他们想为客户解决的问题形态相似。思路是：先为 Claude Code 团队自己解决这个问题，再以更通用的方式推广给客户。内部团队的沟通比 AI 之前更灵活了。Katelyn 说：“在 AI 之前，我们可能会给 Claude Code 团队发一大摞需求文档，他们再回我们一堆文档。现在就简单多了：我们团队有人写了几个组件，直接拿给 Claude Code 团队，他们就开始动手折腾。我们可以搞清楚这个组件怎么接进他们的产品，反过来也一样。整个过程更快、更轻松，第一个内部版本的产品很快就跑起来了。和其他团队对齐接口仍然重要，但做起来更容易了。以前，你必须带着一份完全规格好的接口去用。现在，我们可以灵活得多：先搭一个 stub 服务来镜像流量，然后在实际推进中和 Claude Code 团队逐步敲定接口。”
标题：Anthropic 的软件构建方式正在发生怎样的变化
他们动手改造了一番并给出了反馈，我们在开发接口下层服务的同时做了相应修改，然后再回头让它跑通。他们为 Claude Code 的移动应用上线了一项服务：拉起一个沙箱、启动 Claude Code 并运行。该服务正式上线后，Claude Platform 团队从中汲取了经验。
中途重新架构
许多工程师可能都遇到过类似场景：项目规划好并开始实施之后，发现架构需要调整。这个项目也不例外。Platform 团队最终基于 Claude Code“试验性项目”的反馈，对 Managed Agents 进行了重新架构。重新架构意味着将 Claude 的“大脑”及其控制框架与“手”（执行操作所需的沙箱和工具）以及“会话”（事件日志）解耦。每个部分都变成了一个对彼此几乎不做预设的接口。
重新架构后的 Claude Managed Agents 高层架构
团队还为保险库与凭据构建了一个抽象层。凭据可以安全地存储在保险库内部。所有使用凭据的调用都通过一个持有会话令牌的代理进行。正是这个代理从保险库中获取正确的凭据：代理、沙箱或会话都看不到凭据本身。仅在调用服务时，凭据才会在出口边界注入：
添加控制框架从未见过的凭据
内部“自用”测试（dogfooding）帮助暴露了一系列棘手问题。例如：
- 可靠性与可扩展性：对 agent 来说做好这两点非常困难，因为一旦与沙箱的连接断开，整个 agent 就会宕机，状态也会丢失。
- 凭据与访问控制：同样困难且问题多发，尤其是在首次构建该服务时。
Managed Agents 团队分享了关于此次重新架构项目更详细的信息。该项目耗时约六个月，绝不是一个快速的过程。Katelyn 强调，在 AI 出现之前，类似的项目大概需要两年时间。
Anthropic 的软件构建方式正在改变
Managed Agents 是 Claude Platform 团队搭建的最大项目之一，它比看上去要复杂得多——比如，要支持在 AWS、GCP 和 Azure 上运行代理。
2. 十二个月的项目，十一天完成：Bun 重写为 Rust
之前提到过，Jarred Sumner 是 Bun 的创建者。Bun 是一个流行的 JavaScript 运行时，每月下载量达 2200 万，并且 Claude Code 依赖它。
Bun 使用 Zig 编写，Zig 是一门性能优秀、产出高效的语言。但它并不内存安全，内存问题屡屡出现。Jarred 曾考虑将项目重写为同样高性能但内存安全的语言（比如 Rust）——只是过去这种重写往往以失败告终。
Jarred（他自己强调）：“从历史经验看，重写是非常糟糕的主意。不算注释的话，Bun 有 535,496 行 Zig 代码。用另一种语言重写，一个小团队需要整整一年。那意味着在这一年里，无法修复 bug、无法做安全更新、也无法开发新功能。要想拿出一个能交付的东西，风险最低的办法是机械地将 Zig 移植到 Rust，最小化行为变更，并使用我们现有的测试套件。幸运的是，Bun 自己的测试套件是用 TypeScript 写的，这意味着它不依赖运行时的编程语言。整整一年看不到面向用户的变化，是我们无法接受的选项。所以，通过代码风格来强制解决稳定性问题，是我们最好的选择。我们当时的计划是向 Bun 的代码库中添加受 Rust 启发的智能指针。但说实话，我并不想这么做。自己造的智能指针在易用性上不如 Rust，而且没法提供同样的保证。”
但后来，Jarred 想知道 AI 能不能完成这些繁重的工作，以及能否大幅加速迁移过程。最终，他从开始到合并，仅用 11 天就完成了重写——使用了 64 个并行代理，在 API 价格下花费了 16.5 万美元的 token 费用。