Anthropic团队零Rust经验起步依托Claude完成核心API跨语言重构实现CPU省40%延迟降20%

当 Claude 开始承担大量编码工作，Anthropic 的工程师正在转向哪些更难的问题？

Anthropic 最近完成了一项颇具代表性的工程改造：一个起初没有 Rust 开发者的团队，借助 Claude，将公司的 Messages API 从 Python 迁移到了 Rust。据 Anthropic 平台工程负责人 Katelyn Lesse 透露，改造后相关服务的 CPU 资源消耗减少了约 40%—50%，首 Token 延迟也改善了约 10%—20%。

在这个项目中，Claude 承担了大量代码编写工作，而人类工程师主要负责系统架构、迁移策略和验证方案。一个原本需要大量人工编码的复杂项目，如今可以借助 AI 完成。那么，当 AI 已经能够承担如此复杂的开发任务，软件工程师还能做什么？又该如何证明自己的价值？

Katelyn 对此颇为乐观。10 月 26 日，Katelyn 在 X 上发表了一篇题为《The new set of problems for engineers to solve》（《工程师需要解决的一组新问题》）的长文。文中她提到：对于软件工程师而言，现在是一个绝佳的时代。AI 虽然正在改变工程师的工作方式，但也带来了一批过去不曾面对的工程难题。

这种乐观并非没有理由。当 Agent 不再只是回答问题、执行简单任务，而是开始长时间自主运行、彼此协作，甚至参与复杂的科研和工程项目时，现有的软件基础设施、身份认证与授权、安全隔离以及监控机制，都面临新的挑战。

在 Katelyn 看来，这些挑战也意味着新的工程需求，正是软件工程师接下来值得投入精力的方向。对于那些正在思考自身职业价值的工程师而言，这或许提供了另一种看待未来的角度。

1 成千上万个 Agent 同时运行，Kubernetes 还能扛得住吗？

一个负责统筹工作的 Agent，可以将任务分配给多个子 Agent；不同 Agent 可以分别承担执行、检查、评分等工作，再将结果汇总。随着任务变得复杂，参与协作的 Agent 数量可能不断增加，部分任务甚至需要持续运行数小时或数天。当成千上万个 Agent 同时运行时，现有的基础设施能否高效地管理这些工作负载？

Katelyn 提到了 Kubernetes。作为广泛使用的容器编排平台，Kubernetes 可以管理应用部署、扩缩容和故障恢复。它既能运行无状态应用，也支持有状态工作负载，但 Agent 的运行特征给现有管理方式提出了新的要求。

Katelyn 将 Agent 描述为一种需要隔离、具有独立状态，通常以单个实例运行的工作负载。与传统在线服务相比，Agent 的运行模式存在明显差异。它可能连续执行复杂任务，也可能长时间等待模型推理、工具调用或其他 Agent 返回结果。如果每个 Agent 始终占用独立运行环境，资源利用率可能很低；但如果在空闲时释放资源，又需要解决状态保存、快速恢复和重新调度的问题。如何在启动速度、状态持久化、隔离强度和资源成本之间取得平衡，成为 Agent 基础设施的新挑战。

围绕这些问题，新的技术方案也在不断出现。Katelyn 提到，一些 AI 基础设施公司已经开始开发新的文件系统和沙箱服务，谷歌团队也在构建名为 Agent Substrate 的新运行时环境。不过，在她看来，如何为大规模 Agent 提供高效、可靠的运行环境，仍有许多问题需要工程师解决。

2 当 Agent 开始替人做事，权限究竟应该交给谁？

让 Agent 稳定运行，只是第一步。

当它们开始访问代码仓库、调用外部服务、修改文件，甚至将任务交给其他 Agent 时，另一个问题随之出现：这些 Agent 究竟应该拥有多大的权限？

Katelyn 在文章中明确区分了两个概念：身份认证（Authentication）和授权（Authorization）前者回答“你是谁”，后者则决定“你能做什么”。对于前者，软件行业已经有较成熟的工作负载身份（Workload Identity）、短期证书等技术可以借鉴；真正复杂的是，当 Agent 开始代表用户长期执行任务，甚至自主创建子 Agent 时，权限应该如何分配和传递。

目前，许多 Agent 实际上是在代表人类用户工作。它们使用用户的身份和凭据访问不同系统，代替用户执行操作。问题是，当某个文件被修改、某项操作被执行时，系统如何区分，这究竟是用户本人所为，还是 Agent 代替用户完成的？

当 Agent 开始长时间自主运行，授权问题还会变得更加棘手。例如，用户授权一个 Agent 持续数周处理开发任务，Agent 又将部分工作委托给子 Agent。此时，子 Agent 能否继承原有权限、继承多少、授权有效期如何确定，都需要重新设计。尤其是当 Agent 准备执行超出用户最初预期的操作时，系统还必须判断是否需要人类再次确认。

Katelyn 特别提到了代表用户行事（On-Behalf-Of，OBO）模式。传统的 OBO 授权模式可以让服务代表用户访问其他资源，但 Agent 的自主性和任务持续时间，使权限委托变得更加复杂。系统不仅需要确认 Agent 代表谁执行操作，还需要明确授权范围、委托链条以及权限撤销后的处理方式。

更复杂的情况是，如果未来的 Agent 不再依赖人类用户的身份，而是拥有自己的独立身份，应该如何为它们分配权限？当多个 Agent 需要相互协作，一个 Agent 向另一个 Agent 发出请求时，后者又该如何确认对方的身份、判断这项请求是否获得授权？这些问题目前仍缺少成熟的解决方案，仍是工程师需要解决的新问题。

3 安全隔离：Agent 被攻击后，如何限制风险扩散？

过去几个月，尤其是最近几周，软件漏洞接连暴露，出现的速度甚至超过了行业修复漏洞的速度，其中不少涉及大量系统赖以运行的关键基础软件。

Katelyn 指出，当成千上万个 Agent 持续运行，不断编写、执行不可信代码，并读取来源不可信的内容时，基础软件中尚未修复的漏洞可能带来更大的安全风险。因此，如何加固操作系统内核、浏览器、运行时环境和常用软件库，成为软件工程师需要解决的重要问题。

此外，多智能体系统还会引入另一类风险。

假设一个 Agent 在执行任务时读取了包含恶意指令的网页或文件，并受到提示词注入攻击。如果它只是独立运行，风险可能局限于当前任务；但如果它需要与其他 Agent 协作，恶意内容就可能通过通信传递给其他 Agent，甚至进入共享记忆，影响之后的任务。

这时，攻击的影响范围（Blast Radius）就成为一个必须认真考虑的问题：如果第一个 Agent 被攻破，整个多 Agent 系统中究竟有多少部分可能受到牵连？在她看来，强隔离的执行环境是重要的基础。

实际上，早在 9 月 13 日，Katelyn 就曾专门撰文讨论 Agent 的安全架构，提出将 Agent 的“大脑”与“双手”分开。

所谓“大脑”，包括负责模型调用、工具调用和用户交互的 Agent Harness，以及需要持久保存的会话状态和访问凭据。这些组件应当运行在沙箱之外的可信基础设施中。而作为“双手”的沙箱，则负责执行 Agent 生成的代码和命令，处理可能包含恶意内容的外部数据。

这套架构的关键，是让不可信代码始终运行在权限受限的环境中。Agent 需要访问外部服务时，由沙箱外的可信代理完成凭据注入和访问控制，避免敏感密钥直接暴露给沙箱内的代码。即使 Agent 遭遇提示词注入或执行恶意代码，攻击者能够接触的资源也受到限制。

4 如何识别 Agent 是在努力完成任务，还是已经失控？

即使有了隔离措施，工程师仍然面临另一个问题：如何及时发现 Agent 已经出现异常？

假设某个 Agent 为了完成任务，不断尝试访问一个不在允许名单中的域名。它究竟是在努力寻找完成任务的方法，还是已经受到恶意指令影响，正在尝试突破限制？

这是 Katelyn 在长文中提出的一个场景。两种行为从外部看可能非常相似，而在多个 Agent 相互协作的系统中，判断异常行为就更加困难。工程师不仅需要知道每个 Agent 做了什么，还需要了解任务如何在不同 Agent 之间传递，才能排查问题。

为此，Katelyn 提到了基于 OpenTelemetry（OTel）的跨 Agent 分布式链路追踪，让工程师能够追踪整个任务的执行过程。同时，追踪记录必须保存在 Agent 无权篡改的可信系统中，防止 Agent 修改自己或其他 Agent 的操作记录，影响后续调查。

除了发现异常，系统还必须具备及时制止风险的能力。Katelyn 特别强调了紧急停止机制（Kill Switch）：一旦发现 Agent 出现危险行为，工程师应当能够从外部停止相关 Agent，必要时终止整个系统，并撤销访问凭据，防止风险继续扩大。

对于能够长时间自主运行、相互协作的 Agent 而言，如何追踪它们的行为，并在必要时及时叫停，同样是软件工程师需要解决的问题。

5 代码交给 Claude 之后，工程师在做什么？

回到文章开头，Anthropic 的 Messages API 重构项目，为观察 AI 编程如何改变软件工程实践提供了一个具体案例。

在 10 月 27 日发布的 Latent Space 播客中，Katelyn 介绍了这次迁移的具体过程。随着 API 使用规模扩大，Anthropic 原有的 Python 单体服务面临 CPU 资源效率方面的压力，团队因此决定使用 Rust 重新实现 Messages API。

但项目启动时，团队并没有 Rust 开发者。按照传统开发方式，这样的跨语言重构往往需要先补充相关人才，再逐步完成迁移。Anthropic 则选择借助 Claude 承担大量代码实现工作。

不过，这并不是简单地让 Claude 将 Python 代码翻译成 Rust。Katelyn 介绍，团队需要先确定系统架构、制定迁移计划，再利用 Claude 完成具体实现。而相比让 Claude 写出 Rust 代码，更重要的是如何证明新系统能够安全替代旧系统。团队还使用了 Shadow Traffic（影子流量）等方法，让新旧实现处理相同或等价的请求，对比输出结果，再逐步验证并切换流量。

Anthropic 的实践展示了一种正在出现的工程分工：AI 承担越来越多的代码实现工作，人类工程师则把更多精力投入系统架构、验证、可靠性和安全控制。但这种分工也意味着，工程师需要具备的能力正在发生变化。

Katelyn 提出的四类问题，恰好指向了这种变化。Agent 越来越擅长执行任务，但要让成千上万个 Agent 在真实生产环境中稳定运行、安全协作，并始终处于人类可控的范围内，还有大量基础工程问题没有解决。

在 Latent Space 的访谈中，Katelyn 还分享了 Anthropic 在 API 重构、Agent 架构设计、安全隔离和工程评估方面的具体经验。这些实践也让我们更直观地看到，当 AI 开始承担大量编码工作，工程师的工作重心究竟发生了怎样的变化。

以下精选了访谈中与上述话题最相关的六组问答，InfoQ 在不改变原意的前提下进行了编辑整理。

6 访谈精选：Anthropic 如何让 Claude 真正进入生产环境？

Q1：你们团队原本没有 Rust 工程师，为什么决定用 Claude 重写整个 Messages API？具体是怎么完成的？

Katelyn Lesse：过去，如果预算允许，你基本可以按需扩充 CPU 资源。但现在情况不同了，CPU 容量也需要提前规划，这对整个行业来说都是一个新挑战。

我们正在从几个方面解决这个问题。首先当然是尽可能获取更多 CPU 资源。其次是在基础设施层提高运行效率，例如让沙箱运行得更高效，同时不牺牲租户隔离等安全要求。第三个方向则是应用层，思考如何让我们的应用程序和 API 本身运行得更高效。

上周，我们刚刚完成了 Rust 版本 Messages API 的全面上线。这是 Agent 编程时代才有可能完成的一项非常大胆的工程。今年早些时候，我们就意识到 CPU 资源可能会成为瓶颈。此前我们已经完成了多区域部署等工作，但当时运行的仍然是一套 Python 单体服务，CPU 效率很低，因此我们开始考虑如何让整个系统运行得更加高效。

最终，我们选择了 Rust。从技术角度看，这个决定很容易理解，但在当时却相当大胆，因为团队里连一位 Rust 开发者都没有。不过，我们决定直接尝试让 Claude 负责写代码，人类工程师负责设计系统，毕竟这本质上仍然是一套分布式系统架构。

Claude 不仅能够编写代码，也能帮助工程师讨论设计方案、学习他们需要掌握的新知识。但整个项目中最重要的两件事，其实是制定实施计划，以及验证最终结果。具体实现工作主要由 Claude 完成。

我们最终直接用 Rust 构建了一套完整的 Messages API，然后开始向新系统导入影子流量，验证 Python 和 Rust 两套系统的输出是否一致，再逐步将实际流量切换过去。

如果是在过去，我从来不会让一个团队采用这种迁移方式。这样的项目通常需要好几年，你会把整个系统拆成很多部分，一块一块地迁移，而不会决定一次性重写整个系统，再逐步上线。但这次我们真的这么做了，而且成功了。

主持人：那你们现在有 Rust 工程师了吗？

Katelyn Lesse：现在团队成员大概都会认为自己是 Rust 工程师了。他们已经逐渐掌握了 Rust。在这个过程中，我们也招聘了几位拥有更多 Rust 经验的工程师。

主持人：CPU 资源方面大概节省了多少？

Katelyn Lesse：大约 40%—50%，这是一个相当惊人的数字。延迟也有改善，具体来说，首 Token 延迟改善了大约 10%—20%。对于一些运行时间更长的工作负载，改善幅度还会更大。

主持人：大规模重构时，人们总会忍不住想增加一些原来没有的功能。你们如何控制这种冲动？这次是一次纯粹的重写吗？

Katelyn Lesse：是的，我们刻意克制了增加新功能的冲动。我更愿意把它称为一次移植（Port）。我们专门组建了一支小团队来完成这件事，与此同时，其他团队还在继续为原有 API 开发新功能。负责迁移的团队必须持续跟进这些变化。他们使用静态分析等方法，确保其他工程师在 Python 版本中增加功能时，也考虑到 Rust 版本的对应实现。这也是整个项目需要处理的一部分复杂性。

Q2：Anthropic 为什么把 Agent 的“大脑”和“双手”分开？这种架构是如何演变出来的？

主持人：与计算资源相关的另一个问题是沙箱。现在大家都在讨论 Agent 突破沙箱限制的问题。你们是怎么处理的？目前最先进的方案是什么？

Katelyn Lesse：我们在设计 Claude Managed Agents 时，采用了一种将“大脑”和“双手”分开的架构。所谓“大脑”，就是 Agent Harness，它运行在我们自己的持久化服务器上；“双手”则是执行环境，例如沙箱或容器。

最初采用这种架构，很大程度上是出于延迟和可靠性的考虑。如果 Harness 运行在持久化服务器上，只在需要执行代码时才启动沙箱，那么用户发起请求后，我们就能很快开始返回 Token。与此同时，即使沙箱终止，整个 Agent 也不会随之终止，因为 Harness 仍然在运行，Agent 的状态也保存在其他地方。

实际上，我们经历过一个完整的产品架构演进过程。最早，我们构建 Agent API 的方法非常直接：把 Claude Code 放进一个沙箱，然后在外面封装一层 API。但这种方案存在明显的问题，每次用户发起请求，都必须先启动沙箱，再启动 Claude Code，之后才能返回第一个 Token。而且，一旦沙箱终止，整个 Agent 就会丢失，这样的可靠性达不到我们的要求。

所以，我们最终采用了现在这种架构，最初主要是为了改善延迟和可靠性。不过，有意思的是，从项目一开始，负责这项工作的产品经理就一直强调，这套架构最重要的特性其实是安全性。当时大家都认同这一点，但我们的注意力更多放在延迟和可靠性上。

现在回过头来看，这位产品经理完全是对的。我昨天还专门向他道歉，因为如今我几乎在向每一个人解释，他几个月前就一直强调的那个观点。把 Agent 的执行环境与 Harness 分开，确实带来了非常重要的安全优势。

Q3：Agent 需要访问外部 API、MCP Server 和其他工具，如何防止敏感凭据被不可信代码获取？

Katelyn Lesse：这种架构有一个非常重要的特性，就是能够隔离凭据。当 Agent 需要访问 MCP Server、使用 CLI 或调用其他 API 时，通常都需要进行身份认证，因此必须在某个地方保存凭据。我们的设计是将这些凭据保存在完全独立的 Vault 中。当 Agent 决定调用某个外部服务时，它看到的始终只是一个占位符。等到请求真正离开执行环境时，我们会通过一个代理，从 Vault 中取出正确的凭据并注入请求，然后再把请求发送出去。这意味着，Agent 与真实凭据永远不会处于同一个执行环境中。

在过去那种将整个 Agent 放进沙箱运行的架构里，你必须把凭据也传进去。接下来就会面临各种问题：如何清理凭据，如何确保 Agent 不会拿着凭据去执行未经授权的操作。而现在，我们直接通过基础设施建立了一道隔离墙，让 Agent 无法访问这些凭据。

另一个优势是，我们能够在沙箱基础设施层实施严格的出站网络控制。例如，可以配置域名白名单，也可以完全关闭网络访问。假设 Agent 编写了一段不可信代码，并在沙箱中执行，过去这段代码可能直接访问互联网；但在我们的架构中，它只能访问你明确允许的目标。

通过这些架构设计和沙箱配置，我们可以让系统默认就具备较强的安全保护。现在，我们经常遇到一些客户，他们希望在自己的产品中运行 Agent，或者在企业内部部署 Agent，但又担心最近听到的各种沙箱逃逸事件。

对于这些客户，我认为最重要的是两件事。第一是架构设计，要尽可能通过基础设施约束，让 Agent 无法执行不被允许的操作。第二是沙箱配置，包括网络访问权限等具体控制措施。

Claude Managed Agents 的一个优势，就是开发者可以直接获得这些能力，而不必从头构建整套安全基础设施。随着我们继续发现新的问题、改进系统，这些改进也会体现在平台能力中，让开发者受益。

如果倒退九个月，我们可能根本不会频繁讨论“大脑与双手分离”“凭据注入”“出站网络控制”这些概念。但现在，这些已经成为我们必须解决的问题。

Q4：对于 Agent 和 Harness 的评估，你们有哪些最佳实践建议？

主持人：你刚才提到团队会进行大量评估。对于 Agent 和 Harness 的评估，有什么建议或最佳实践？

Katelyn Lesse：评估有很多不同类型，而且不同评估方法适用于不同的场景。你可以使用静态的确定性测试，也可以使用 LLM-as-a-Judge，还有其他各种方法。但根据我们的观察，大多数团队需要的评估数量往往比他们想象的更多。你不可能只建立几组完美的评估，就获得改进系统所需的全部答案。我们发现，团队最终通常需要一套规模相当大的评估体系。而且，随着系统不断演进，你还可以让 Agent 帮助你持续完善评估集。从我们看到的情况来说，评估投入不足可能是最常见的错误。

Angela Jiang：我觉得还应该从简单的评估开始。有些人看到各种评估方法，就开始研究究竟哪种最好，应该选择什么框架、采用什么策略。结果他们花了大量时间比较这些选项，真正建立起来的评估数量却是零。与其这样，不如先做一些简单的测试，即使很简单，也能提供帮助。

主持人：我经常告诉别人，我现在越来越倾向于把工程开发当成研究工作。当你用研究的方式做工程时，自然会进行更多评估、数据标注、原型实验，以及扩大实验规模。你并不是在训练模型，而是在开发 Harness 或产品，但你采用的是研究的方法。你需要提前定义目标，尽可能将其转化为评估指标，然后再分析为什么系统没有达到目标。有时候，问题出在评估方法本身；有时候是环境有问题；还有时候才是模型的问题。我觉得这正是 AI 工程正在发生的变化。

Katelyn Lesse：完全同意。我们也会继续为 Claude Managed Agents 增加相关工具，让开发者能够更方便地完成这些工作。未来，你可能会看到我们提供一些帮助开发者为 Managed Agents 创建评估的产品或功能，而且使用这些工具的过程也会很像与 Claude 一起工作。

Q5：Agent 的 Dreaming 机制究竟如何工作？为什么 Anthropic 近期减少了对 Skills、Memory 等功能的投入？

主持人：今年上半年，记忆相关功能似乎是 Anthropic 的重要研发方向，包括 Memory 和 Dreaming。现在这些工作是否放缓了？团队的重点发生了什么变化？

Katelyn Lesse：这些仍然是我们工作的重要组成部分。我们推出 Managed Agents，是为了帮助那些不希望自己构建所有底层组件的开发者。他们可以直接使用我们提供的 Agent 平台，而我们的团队会持续进行评估和优化，确保 Harness 能够充分发挥 Claude 的能力。

Memory 和 Dreaming 的核心目标是让 Agent 能够随着时间推移不断改进。不过，正如我们前面讨论的，模型发布在安全方面变得越来越复杂。因此，相比继续增加各种优化 Agent 表现的新功能，我们现在把更多精力投入了如何让这些系统更加安全。

对我们来说，最重要的事情是让用户能够使用强大的模型能力，同时确保这些能力可以安全地提供出去。所以，与今年早些时候相比，我们确实相对放缓了 Skills、Dreaming、Memory 等方向的部分工作。但这并不意味着我们放弃了它们。我们仍然非常看好 Skills，也仍在持续更新这些功能。

Angela Jiang：我们非常看好在 Harness 层进行持续优化。我们自己也做了大量这样的工作，但我们提供的基础 Harness 在某种意义上是刻意保持简单的，因为不希望它过度规定开发者应该如何构建 Agent。

基础 Harness 应该整合一些经过验证的最佳实践，提供那些相对通用、但开发者自己实现起来比较麻烦的组件。在这个基础上，开发者可以进一步构建各种优化策略，Dreaming 就是其中一个例子。

Dreaming 的底层其实是一个多 Agent 系统。我们在 Claude Managed Agents 之上构建了这一策略，本质上可以理解为用 Managed Agent 来管理另一个 Managed Agent。具体来说，系统会启动另一个 Managed Agent，让它检查前一个 Managed Agent 的执行经历，然后为后者写入记忆。

这种设计是有意为之的。我们希望这些组件能够像模块一样组合起来，支持开发者构建不同的策略。Dreaming 只是其中一个例子，你还可以采用 Best-of-N 策略，让多个 Agent 并行尝试不同方案，再从中选择较好的结果；也可以使用专门负责验证的 Agent，检查任务是否达到目标。

我们已经看到一些开发者构建了非常有意思的系统。例如，有些 Harness 会在大量并行 Agent 之间共享记忆。这让我们意识到，应该让开发者更容易构建自己的多 Agent 策略。

因此，我们计划进一步开放底层能力，让开发者能够组合这些组件，构建自己的 Harness 优化方案。我们也会提供一些模板，例如展示 Dreaming 最初是如何实现的，让开发者在此基础上进行修改和扩展。

Katelyn Lesse：我觉得更准确的说法是，我们已经建立了一批基础能力，现在可以让开发者利用这些能力继续探索。我们会继续提供构建多 Agent 策略所需的工具，同时把团队更多的注意力转向安全问题，确保开发者能够安全地使用这些越来越强大的模型能力。

Q6：当 Claude 已经能够承担大量代码实现工作，Anthropic 如何避免产生低质量代码和产品？工程师还需要做什么？

主持人：你们如何防止团队产生大量低质量的 AI 生成内容？

Katelyn Lesse：这是我们团队内部一直在讨论的问题，而且我们和其他公司没有什么不同。假设你正在制作一份文档，或者编写一段准备交给其他人使用的代码，你当然应该使用 Claude 来帮助完成这些工作。但如果你直接让 Claude 生成全部内容，自己完全不阅读，也不检查质量，就把它交给其他人，那么实际上是把额外的工作负担转嫁给了接收者。对方需要花大量时间理解和检查你交付的东西，这非常不合理，也不公平。

因此，我们一直要求团队成员：可以使用 Claude，但必须确保最终交付的内容达到足够高的质量标准。不过，这里也存在一个有意思的问题。有时候，工程师确实花了大量时间检查和修改 Claude 生成的内容，最终质量也很好，但由于其中保留了一些明显的 Claude 写作特征，例如某些标点或表达方式，读者就会立刻觉得这是一份 AI 生成的东西，进而产生反感。

这同样不是我们希望看到的。所以，我们希望团队建立一种平衡：充分利用 Claude 提高效率，但始终对最终质量负责。对于接收者来说，如果内容确实质量很差，就应该直接退回，不要浪费时间；但也不必因为一些细微的 AI 写作痕迹，就认定内容没有价值。

主持人：那工程代码呢？你们如何防止产生大量低质量的 AI 代码？

Katelyn Lesse：原则其实一样。不过，我认为我们现在已经找到了一种相对不错的工作方式。人类工程师在系统设计中仍然发挥着重要作用，而具体实现工作越来越多地交给 Claude。对于大量生成的代码，我们并不一定需要工程师逐行深入审查。有时候，只需要相对快速地确认，就可以继续推进。我们更关心的是整体计划是否合理、系统设计是否正确，而不是每一行代码的实现是否都完美无缺。

当然，这建立在拥有大量验证机制的基础上。我们需要通过这些验证，确保最终交付的系统达到足够高的质量标准。现在，我们已经没有过去那么频繁地讨论 AI 代码质量低下的问题。一方面是因为 Claude 本身变得更强了，另一方面是因为我们建立了合适的验证机制，能够确保交付质量。

主持人：那产品开发呢？现在你们可以在一天之内完成很多功能，会不会出现大量低质量的产品功能？我最近看到一个观点：使用模型能力的正确方式，并不是把生产环境中的功能数量增加十倍，而是应该花更多时间理解用户、开展实验，并认真决定要构建什么。

Katelyn Lesse：我经常谈到这个问题。软件和产品从规划到开发、再到交付，有很多非常基础的原则。这些原则不会因为 Agent 加快了其中某些环节，就突然变得不重要。但现在，一些人开始产生一种惰性。他们觉得既然 Agent 已经能够帮助完成某些工作，那么自己就不需要再认真思考那些环节了。实际上，那些仍然是整个软件开发过程中非常基础、非常重要的部分，工程师依然应该投入时间和精力。AI 可以让我们更快地完成实现，但这不意味着我们可以省略规划、设计、判断和质量控制。