作者｜林绮蓓
编辑｜蔡芳芳
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 看来，这些挑战也意味着新的工程需求，正是软件工程师接下来值得投入精力的方向。对于那些正在思考自身职业价值的工程师而言，这或许提供了另一种看待未来的角度。
成千上万个 Agent 同时运行，Kubernetes 还能扛得住吗？
一个负责统筹工作的 Agent，可以将任务分配给多个子 Agent；不同 Agent 可以分别承担执行、检查、评分等工作，再将结果汇总。随着任务变得复杂，参与协作的 Agent 数量可能不断增加，部分任务甚至需要持续运行数小时或数天。当成千上万个 Agent 同时运行时，现有的基础设施能否高效地管理这些工作负载？
Katelyn 提到了 Kubernetes。作为广泛使用的容器编排平台，Kubernetes 可以管理应用部署、扩缩容和故障恢复。它既能运行无状态应用，也支持有状态工作负载，但 Agent 的运行特征给现有管理方式提出了新的要求。
Katelyn 将 Agent 描述为一种需要隔离、具有独立状态，通常以单个实例运行的工作负载。与传统在线服务相比，Agent 的运行模式存在明显差异。它可能连续执行复杂任务，也可能长时间等待模型推理、工具调用或其他 Agent 返回结果。如果每个 Agent 始终占用独立运行环境，资源利用率可能很低；但如果在空闲时释放资源，又需要解决状态保存、快速恢复和重新调度的问题。如何在启动速度、状态持久化、隔离强度和资源成本之间取得平衡，成为 Agent 基础设施的新挑战。
围绕这些问题，新的技术方案也在不断出现。Katelyn 提到，一些 AI 基础设施公司已经开始开发新的文件系统和沙箱服务，谷歌团队也在构建名为 Agent Substrate 的新运行时环境。不过，在她看来，如何为大规模 Agent 提供高效、可靠的运行环境，仍有许多问题需要工程师解决。
当 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 发出请求时，后者又该如何确认对方的身份、判断这项请求是否获得授权？这些问题目前仍缺少成熟的解决方案，仍是工程师需要解决的新问题。
安全隔离：Agent 被攻击后，如何限制风险扩散？
过去几个月，尤其是最近几周，软件漏洞接连暴露，出现的速度甚至超过了行业修复漏洞的速度，其中不少涉及大量系统赖以运行的关键基础软件。
Katelyn 指出，当成千上万个 Agent 持续运行，不断编写、执行不可信代码，并读取来源不可信的内容时，基础软件中尚未修复的漏洞可能带来更大的安全风险。因此，如何加固操作系统内核、浏览器、运行时环境和常用软件库，成为软件工程师需要解决的重要问题。
此外，多智能体系统还会引入另一类风险。
假设一个 Agent 在执行任务时读取了包含恶意指令的网页或文件，并受到提示词注入攻击。如果它只是独立运行，风险可能局限于当前任务；但如果它需要与其他 Agent 协作，恶意内容就可能通过通信传递给其他 Agent，甚至进入共享记忆，影响之后的任务。
这时，攻击的影响范围（Blast Radius）就成为一个必须认真考虑的问题：如果第一个 Agent 被攻破，整个多 Agent 系统中究竟有多少部分可能受到牵连？在她看来，强隔离的执行环境是重要的基础。
实际上，早在 9 月 13 日，Katelyn 就曾专门撰文讨论 Agent 的安全架构，提出将 Agent 的“大脑”与“双手”分开。
所谓“大脑”，包括负责模型调用、工具调用和用户交互的 Agent Harness，以及需要持久保存的会话状态和访问凭据。这些组件应当运行在沙箱之外的可信基础设施中。而作为“双手”的沙箱，则负责执行 Agent 生成的代码和命令，处理可能包含恶意内容的外部数据。
这套架构的关键，是让不可信代码始终运行在权限受限的环境中。Agent 需要访问外部服务时，由沙箱外的可信代理完成凭据注入和访问控制，避免敏感密钥直接暴露给沙箱内的代码。即使 Agent 遭遇提示词注入或执行恶意代码，攻击者能够接触的资源也受到限制。
如何识别 Agent 是在努力完成任务，还是已经失控？
即使有了隔离措施，工程师仍然面临另一个问题：如何及时发现 Agent 已经出现异常？
假设某个 Agent 为了完成任务，不断尝试访问一个不在允许名单中的域名。它究竟是在努力寻找完成任务的方法，还是已经受到恶意指令影响，正在尝试突破限制？
这是 Katelyn 在长文中提出的一个场景。两种行为从外部看可能非常相似，而在多个 Agent 相互协作的系统中，判断异常行为就更加困难。工程师不仅需要知道每个 Agent 做了什么，还需要了解任务如何在不同 Agent 之间传递，才能排查问题。
为此，Katelyn 提到了基于 OpenTelemetry（OTel）的跨 Agent 分布式链路追踪，让工程师能够追踪整个任务的执行过程。同时，追踪记录必须保存在 Agent 无权篡改的可信系统中，防止 Agent 修改自己或其他 Agent 的操作记录，影响后续调查。
除了发现异常，系统还必须具备及时制止风险的能力。Katelyn 特别强调了紧急停止机制（Kill Switch）：一旦发现 Agent 出现危险行为，工程师应当能够从外部停止相关 Agent，必要时终止整个系统，并撤销访问凭据，防止风险继续扩大。
对于能够长时间自主运行、相互协作的 Agent 而言，如何追踪它们的行为，并在必要时及时叫停，同样是软件工程师需要解决的问题。
代码交给 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 在不改变原意的前提下进行了编辑整理。
访谈精选：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 可以让我们更快地完成实现，但这不意味着我们可以省略规划、设计、判断和质量控制。
相关链接：
1.https://x.com/katelyn_lesse/status/2114542280535318557?s=46
2.https://www.katelynlesse.com/blog/secure-agents-architecture-and-sandboxing
本文由 AI图鉴自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Author Zilong Lin
Editor Cai Fang
Anthropic recently completed a very representative engineering exercise: a team that initially did not have a Rust developer, which, with Claude, moved Messages API from Python to Rust. According to Katelyn Lesse, the head of the work on the Anthropic platform, CPU resource consumption for the retrofit related services decreased by about 40-50 per cent and the first token delay improved by about 10-20 per cent.
In this project, Claude has undertaken a great deal of code writing, while human engineers are primarily responsible for systems architecture, migration strategies and validation programmes. A complex project that would otherwise require a large number of manual codings can now be completed with AI. So, what else can software engineers do when AI has been able to undertake such a complex development? How can you prove your worth?
Katelyn is optimistic about this. On October 26, Katelyn published on X a long article entitled The new set of issues for engineers to solve. She mentioned that for software engineers, this is an excellent time. AI, while changing the way engineers work, also presents a set of engineering challenges that were not previously faced.
This optimism is not unreasonable. The existing software infrastructure, identification and authorization, security isolation, and monitoring mechanisms face new challenges when Agent no longer merely answers questions, performs simple tasks, but begins to operate autonomously for a long time, collaborates with each other and even engages in complex scientific and engineering projects.
In Katelyn, it appears that these challenges also imply new engineering needs, which are precisely the direction that software engineers are going to need to invest in. This may provide another perspective on the future for those engineers who are thinking about the value of their profession.
Thousands of Agents running at the same time. Can Kubernetes handle it?
An Agent, who is responsible for the integration, can assign tasks to several sub-units; different Agent can take on tasks of execution, inspection, scoring, etc., and then aggregate the results. As the task becomes more complex, the number of Agents involved in collaboration may increase, and some tasks may even require hours or days of continuous operation. Can existing infrastructure efficiently manage these loads when thousands of Agents are running simultaneously?
Katelyn mentioned Kubernetes. As a widely used packaging assembly platform, Kubernetes can manage applications for deployment, convulsion and failure recovery. It can run both non-state applications and supports a state load, but Agent's operational features create new requirements for existing management.
Katelyn describes Agent as a task load that needs to be isolated and in a separate state, usually running on a single example. There is a marked difference in the operational model of Agent compared to the traditional online service. It may perform complex tasks on a continuous basis or may wait long for model reasoning, tool call or other Agent returns. The resource utilization rate may be low if each Agent is always occupying a separate operating environment; however, if resources are released during free time, the issue of state preservation, rapid recovery and redeployment needs to be addressed. How to balance the speed of start-up, the durability of the state, the intensity of isolation and the cost of resources becomes a new challenge for Agent infrastructure.
New technology programmes are also emerging around these issues. Katelyn mentioned that some AI infrastructure companies have started developing new documentation systems and sandbox services, and Google teams are building a new time environment called Agent Substrate. However, in her view, many problems still needed to be addressed by engineers in providing an efficient and reliable operating environment for large-scale Agent.
When Agent started working for someone, who was it supposed to be?
Let Agent run steady, just the first step.
When they start accessing the code warehouse, calling external services, modifying files, and even handing over tasks to other Agents, another question arises: How much permission should these Agents have?
In his article, Katelyn clearly distinguished between two concepts: Identification, which answered “Who are you”, and Authorization, which determined “what you can do”. For the former, the software industry already has more sophisticated workloads such as workload capacity, short-term certificates, etc.; what is really complex is how permission should be distributed and communicated when Agent begins to carry out long-term assignments on behalf of users and even create its own son, Agent.
Now, many Agent actually works on behalf of human users. They use user identities and documented access to different systems to perform operations instead of users. The question is, when a document is modified and an operation is executed, how does the system distinguish between the actions of the user itself and the actions of Agent instead?
When Agent begins to operate on its own for a long time, the issue of authorization becomes even more difficult. For example, the user authorized an Agent to deal with development tasks for several weeks, and Agent entrusted part of the work to his son Agent. At this point, whether or not Mr. Agent inherited the original permission, how much he inherited and how the validity of the authorization was determined would need to be redesigned. In particular, when Agent is prepared to perform operations that exceed the initial expectations of the user, the system must also judge whether human confirmation is required.
Katelyn referred in particular to the On-Behalf-Of, OBO model. The traditional OBO mandate model allows users of services to access other resources, but Agent ' s autonomy and duration of the mission complicates permission missions. The system needs not only to identify who Agent is carrying out the operation on behalf of, but also to clarify the scope of the authorization, the chain of authority and the post-permission approach.
More complicated is how should permission be allocated to future Agent if it no longer depends on the identity of human users, but instead has its own independent identity? When multiple Agents need to collaborate, one Agent sends a request to another Agent, how does the latter identify the other and judge whether the request is authorized? These issues still lack mature solutions and remain new issues for engineers to address.
Safety isolation: How can the spread of risk be limited following the attack on Agent?
Over the past few months, and particularly in recent weeks, software gaps have been exposed consecutively, at a faster rate than the industry can even repair them, many of which involve critical basic software on which a large number of systems operate.
Katelyn stated that while thousands of Agents were running on an ongoing basis, developing, implementing untrustworthy codes and reading untrustworthy content from sources, unrecovered loopholes in basic software could pose greater security risks. Thus, how to strengthen the nuclear, browser, running-time environment and common software libraries within the operating system is an important issue to be addressed by software engineers.
In addition, the multi-AI agent system introduces another type of risk.
It is assumed that in the course of his mission, Agent had read pages or documents containing malicious orders and was attacked by prompt injections. If it operates independently, the risk may be limited to the current mission; but if it needs to collaborate with other Agent, malicious content may be communicated to other Agent, or even into shared memory, affecting the post-mission.
At this point, the impact of the attack (Blast Radius) becomes an issue that must be carefully considered: If the first Agent is broken, how many parts of the whole Agent system could be implicated? In her view, the enforced environment of isolation was an important basis.
In fact, as early as September 13, Katelyn wrote about the security architecture of Agent, proposing to separate Agent's “brain” from “hands”.
The so-called “brain”, which includes those responsible for model calls, tool call and interactive user Agent Harness, as well as conversational status and access documents that need to be permanently preserved. These components should operate in a credible infrastructure outside the sandbox. The sandbox, which is the “hands”, is responsible for enforcing codes and commands generated by Agent and processing external data that may contain malicious content.
The key to this architecture is to keep untrustworthy codes in the restricted environment of permission. When Agent requires access to external services, a credible agent outside the sandbox completes proof injection and access controls to avoid the sensitive key being exposed directly to the code inside the sandbox. Even when Agent was exposed to prompt injections or malicious code enforcement, the resources available to the attackers were restricted.
How do you know that Agent is trying to do his job, or is it out of control?
Even with quarantine measures, engineers still face another problem: How did it happen in time to find out that Agent had an anomaly?
Assume that in order to fulfil its mandate, an Agent is constantly trying to access a domain name that is not on the permitted list. Is it trying to find a way to accomplish its mission, or is it already affected by malicious instructions and is it trying to break through?
This is a scene presented by Katelyn in the long paper. The two acts may be very similar from an external perspective, and it is even more difficult to judge abnormal behaviour in multiple Agent collaborating systems. Engineers need to know not only what each Agent does, but also how the mission is transmitted between different Agents in order to sort out the problem.
To this end, Katelyn referred to the cross-Agent distributed link tracking based on OpenTelemetry (Otel), which enabled engineers to track the entire mission. At the same time, tracking records must be kept in a credible system that Agent does not have the power to tamper with to prevent Agent from modifying his own or other Agent's operating records and influencing subsequent investigations.
In addition to detecting anomalies, the system must have the capacity to deter risks in a timely manner. Katelyn placed particular emphasis on the emergency cessation mechanism (Kill Switch): once Agent was found to be in danger, engineers should be able to stop the relevant Agent from outside, terminate the entire system if necessary, and withdraw access documents to prevent the risk from continuing to expand.
For Agent, which is able to operate autonomously over a long period of time and collaborates with each other, how to track their behaviour and, if necessary, stop it in a timely manner is also a matter for software engineers to address.
What did the engineer do after he gave Claude the code?
Back to the beginning of the article, the Messages API Reconstruction Project of Anthropic provided a concrete case for observing how AI programming changed software engineering practices.
On October 27th, in publish's Latin Space podcast, Katelyn described the specific process of the move. With the expansion of API use, the original Python mono-service was under pressure from CPU resource efficiency and the team decided to use Rust to re-establish Messages API.
But when the project started, the team did not have Rust Developer. In accordance with traditional development patterns, such cross-linguistic re-engineering often requires the addition of relevant talent before the migration is phased out. Anthropic chooses to do a lot of work with Claude.
However, this is not simply about Claude translating Python into Rust. Katelyn described the need for the team to define the architecture of the system, develop a migration plan, and use Claude to make it happen. And more important than having Claude write Rust code, how to prove that the new system can safely replace the old system. The team also used such methods as Shadow Traffic (shadow flow) to enable old and new requests to be processed at the same or equal prices, to compare output results and to gradually verify and switch flows.
The practice of Anthropic demonstrates an emerging division of engineering: AI is taking on an increasing number of code realizations, while human engineers are investing more energy in system architecture, validation, reliability and security controls. However, this division also means that the capabilities required by engineers are changing.
The four categories of issues raised by Katelyn coincided with this change. Agent is becoming increasingly good at carrying out its tasks, but there are a number of basic engineering issues that remain unresolved to allow thousands of Agents to operate in a stable and safe environment of real production and remain within human control.
In an interview with Latent Space, Katelyn also shared specific experiences of Anthropic in API re-engineering, Agent architecture design, security isolation and engineering evaluation. These practices also give us a more intuitive view of how the work of engineers changed when AI started taking on a lot of coding.
The following is a selection of the six sets of questions and answers most relevant to the above-mentioned topics from the interviews, which InfoQ edited without changing its intentions.
Interview: How does Anthropic actually get Claude into the production environment?
Q1: Why did you decide to rewrite the messages API with Claude?
Katelyn Lesse: In the past, if the budget allows, you can basically expand CPU resources as needed. But now that things are different, CPU capacity needs to be planned ahead, which is a new challenge for the whole industry.
We are addressing this issue in several ways. First of all, of course, getting as many CPU resources as possible. The second is to improve operational efficiency at the infrastructure level, for example by making sandboxes more efficient, without sacrificing safety requirements such as tenant segregation. The third direction is the application layer, thinking about how to make our applications and the API themselves work more efficiently.
Last week, we just finished the Rust version of Messages API fully online. This is a very bold project that was possible in the Age of Agent programming. Earlier this year, we realized that CPU resources could become bottlenecks. We had already completed multi-regional deployments and so on, but we were still running a single Python service, and CPU was inefficient, so we started thinking about how to make the system work more efficiently.
Eventually, we chose Rust. From a technical point of view, the decision was easy to understand, but it was rather bold at the time, because there was not even a Rust developer in the team. But we decided to try to get Claude to write the code, and human engineers to design the system, which is essentially a distributed architecture.
Claude is not only able to write codes, but also to help engineers discuss design options and learn the new knowledge they need. But the two most important elements of the project as a whole are the development of an implementation plan and the validation of the final results. Claude is the main source of practical realization.
We eventually built a complete messages API directly with Rust, and then started importing shadow traffic into the new system to verify whether Python and Rust output is consistent and gradually switch the actual flow over.
In the past, I would never have let a team do this. Such a project would usually take years, and you would break the whole system into parts, move it together, and not decide to re-write the system once and gradually. But this time we did, and we did.
Do you have any engineers now?
Katelyn Lesse: Now the team members probably think they're Rust engineers. They've come to grips with Rust. In the process, we also recruited several engineers with more Rust experience.
Moderator: What are the likely savings in CPU resources?
Katelyn Lesse: about 40-50 percent, that's quite an amazing number. Delays have also improved, specifically, the first token delay has improved by about 10-20 per cent. For some of the longer-duration loads, the improvement would be even greater.
Moderator: When large-scale re-engineering takes place, people can't help but try to add functions that they didn't have. How do you control this impulse? Is this a pure rewriting?
Yes, we deliberately restrained the urge to add new functions. I prefer to call it a transplant. We have formed a small team to do this, while other teams continue to develop new features for the original API. The teams responsible for relocation must follow up on these changes on a continuous basis. They use methods such as static analysis to ensure that other engineers also take account of the equivalent of Rust when adding functions to the Python version. This is also part of the complexity of the project as a whole.
Q2: Why does Anthropic separate Agent's brain from his hands? How has this structure evolved?
Moderator: Another issue related to the calculation of resources is the sandbox. Now everybody's talking about Agent breaking the sandbox limits. What did you do? What are the most advanced options?
Katelyn Lesse: In designing Claude Managed Agents, we have adopted a structure that separates the brain from the hands. The so-called “brain” is Agent Harness, which runs on our own durable servers; the “hands” are the operating environment, such as sandboxes or containers.
The initial adoption of such a structure was largely due to delays and reliability considerations. If Harness is running on a durable server and the sandbox is activated only when code execution is required, then we can start returning to Token soon after the user has initiated the request. At the same time, even if the sandbox is terminated, the entire Agent will not end with it, because Harness is still running and Agent's state is kept elsewhere.
In fact, we have experienced a complete product architecture evolution. First of all, the way we build Agent API is very straightforward: put Claude Code in a sandbox and then seal an API outside. However, there is a clear problem with this type of programme, and each time a user requests a sandbox must be activated before Claude Code can return to the first Token. And, once the sandbox is over, the entire Agent will be lost, and this reliability will not meet our requirements.
That is why we have finally adopted the present structure, initially primarily to improve delay and reliability. It is interesting, however, that the product manager responsible for this work has emphasized from the outset that the most important feature of the architecture is actually security. That was accepted by all at the time, but we focused more on delay and reliability.
Turning back now, the product manager is absolutely right. I also apologized specifically to him yesterday, because now I'm explaining to almost everyone that point he has been emphasizing for months. The separation of Agent's operating environment from Harness did bring very important security advantages.
Q3: Agent needs access to external API, MCP Server and other tools to prevent sensitive documents from being untrustworthy in code?
Katelyn Lesse: There's one very important feature of this structure, which is that it can isolate evidence. When Agent needs to access MCP Server, use CLI or call other API, it is usually required to authenticate and must preserve the document somewhere. Our design is to keep these documents in completely independent Vault. When Agent decides to call an external service, it always sees a placeholder. By the time the request actually leaves the execution environment, we'll take the correct evidence from the Vault and inject the request through an agent before sending it out. That means that Agent will never be in the same execution environment as the true evidence.
In the past, you had to put the whole Agent in a sandbox, and you had to pass the evidence in. Then there are questions: how to clean up the evidence and how to make sure that Agent does not carry out unauthorized operations with it. And now, we've built a wall directly through infrastructure, preventing Agent from accessing the evidence.
Another advantage is that we are able to enforce strict out-of-station network controls on the sandbox infrastructure. For example, a white list of domain names could be configured or access to the network could be completely closed. Assuming that Agent has prepared an untrustworthy code and implemented it in the sandbox, the past code may have directly accessed the Internet; but in our architecture, it can only access what you clearly allow.
Through these architecture designs and sandbox configurations, we can provide greater security by default. Now, we often meet clients who want to run Agent in their own products or deploy Agent within the enterprise, but who are concerned about recent cases of sandbox escape.
For these clients, I think the most important thing is two things. The first is structure design, which, as far as possible, constrains the infrastructure so that Agent is unable to perform unauthorized operations. The second is sandbox configuration, including specific control measures such as network access to permission.
One advantage of Claude Managed Ages is that developers have direct access to these capabilities without having to build the entire security infrastructure from scratch. As we continue to identify new problems and improve systems, these improvements will also be reflected in the platform ' s capacity to benefit developers.
If we go back nine months, we probably won't talk about the concept of “brain-to-hand” “supported” “post-site network control” at all. But now, these have become the issues that we must address.
Q4: What are your best practice suggestions for the assessment of Agent and Harness?
You just mentioned a lot of evaluation by the team. What are the recommendations or best practices for the assessment of Agent and Harness?
Katelyn Lesse: There are many different types of assessment and different assessment methods apply to different scenarios. You can use static certainty tests, LLM-as-a-Judge, and other methods. But according to our observations, most teams tend to have more assessments than they think. You cannot create just a few sets of perfect assessments and get all the answers needed to improve the system. We have found that teams usually end up in need of a system of assessments of considerable size. And, as the system evolves, you can also get Agent to help you continuously improve the assessment set. From what we have seen, inadequate assessment input may be the most common error.
Angela Jiang: I think we should start with a simple assessment. Some see various assessment methods and begin to look at which is best, which framework should be chosen and which strategies should be used. As a result, they spent a great deal of time comparing these options, and the number of assessments that were actually established was zero. Instead, some simple tests would help, if not simply.
Moderator: I've often told people that I'm increasingly looking at engineering development as research work. When you do engineering in research, you naturally do more assessment, data labelling, prototype experiments, and scale-up. You're not training models, you're developing Harness or products, but you're doing research. You need to define the objectives in advance and translate them, to the extent possible, into indicators of assessment before analysing why the system is not meeting its objectives. Sometimes the problem lies in the assessment methodology itself; sometimes in the environment; and sometimes in models. I think that's what's happening with the AI Project.
Katelyn Lesse: All in full agreement. We will also continue to add tools to Claude Managed Ages to enable developers to do this more easily. In the future, you might see some of the products or functions that help developers create assessments for Managed Ages, and the process of using these tools will be like working with Claude.
Q5: How does the Dreaming mechanism of Agent work? Why did Anthropic recently reduce its input into the Skills and Memoory functions?
Moderator: In the first half of this year, memory-related functions appeared to be an important development orientation for Anthropic, including Memoory and Dreaming. Are these jobs slowing down now? What happened to the focus of the team?
These are still an important part of our work. We introduced Managed Ages to help those who do not want to build all their own bottom components. They can directly use the Agent platform we provide, and our team will continuously assess and optimize to ensure that Harness is able to fully utilize Claude's capabilities.
The central goal of Memoory and Dreaming is to enable Agent to improve over time. However, as discussed earlier, model publish is becoming increasingly complex in terms of security. So, instead of continuing to add new features that optimize the performance of Agent, we are now investing more energy in how to make these systems safer.
For us, the most important thing is to enable users to use robust modelling capabilities while ensuring that they are safely available. So, compared to earlier this year, we did slow down part of the work in the direction of Skills, Dreaming, Memoory. But that doesn't mean we give them up. We are still very keen on Skills and are constantly updating these functions.
Angela Jiang: We're looking forward to continuous optimization at Harness level. We've done a lot of this ourselves, but the basis we're providing Harness is to keep it simple in a sense, because it doesn't want to overstate how developers should build Agent.
The foundation, Harness, should consolidate some proven best practices and provide components that are relatively common but that developers themselves can achieve more troublesome. And on this basis, developers can further construct optimisation strategies, and Dreaming is one example.
The bottom of Dreaming is actually a multiAgent system. We built this strategy on Claude Managed Ages, which is basically understood as the use of Managed Agent to manage another Managed Agent. Specifically, the system activates another Managed Agent, allowing it to check the previous Managed Agent implementation experience, and then write to the latter.
This design is intentional. We want these components to be combined like modules and support developers in building different strategies. Dreaming is just one example of how you can use the Best-of-N strategy to allow multiple Agents to try different options in parallel, and then choose better results; it can also use Agent, which is dedicated to validation, to check whether the mission has met its objectives.
We've seen some developers build very interesting systems. For example, some Harness will share memories between a lot of parallel Agents. This makes us realize that it would be easier for developers to build their own many Agent strategies.
Therefore, we plan to further open the bottom capacity so that developers can combine these components and build their Harness optimization programmes. We will also provide templates, such as a demonstration of how Dreaming was first achieved, where developers can modify and expand.
Katelyn Lesse: I think more precisely, we've built up a base of capabilities that can now be used by developers to continue to explore. We will continue to provide the tools needed to build a multi-Agent strategy, while turning more of the team ' s attention to security issues and ensuring that developers can safely use these increasingly powerful modelling capabilities.
Q6: How does Anthropic avoid producing low-quality codes and products when Claude has been able to undertake a lot of code realization? What more do engineers have to do?
Moderator: How do you prevent teams from producing a lot of low-quality AI content?
This is what we've been discussing within our team, and we're no different from other companies. Suppose you're making a file, or you're writing a code for others, you should certainly use Claude to help do that. But if you just let Claude generate all the content, you don't read it at all, you don't check the quality, and you give it to someone else, then you actually transfer the extra workload to the recipient. It is very unreasonable and unfair that the other party spends a great deal of time understanding and examining what you deliver.
Therefore, we have always asked team members to use Claude, but to ensure that the content of the final delivery meets sufficiently high quality standards. However, there is also an interesting problem here. Sometimes engineers do spend a lot of time checking and modifying the content generated by Claude, and eventually the quality is good, but because they retain some obvious Claude writing features, such as some markers or expressions, readers immediately feel that this is an AI-generated thing, and that it is offensive.
Again, that is not what we want to see. So we want the team to strike a balance: make the best use of Claude to improve efficiency, but always be responsible for the final quality. For recipients, if the content is indeed of poor quality, it should be returned directly and should not be wasted; however, it should not be deemed worthless because of some subtle AI writing traces.
What about the project code? How do you prevent the generation of a large number of low-quality AI codes?
The principle is the same. However, I think we have now found a relatively good way of working. Human engineers continue to play an important role in the design of the system, and concrete realization is increasingly entrusted to Claude. We do not necessarily require in-depth review by engineers on a line-by-line basis for a large number of generated codes. Sometimes, it takes relatively quick confirmation to move forward. We are more concerned about the soundness of the overall plan and the correct design of the system than about the perfectness of each line of codes.
Of course, this is based on the existence of a large number of certification mechanisms. Through these validations, we need to ensure that the systems ultimately delivered meet sufficiently high quality standards. Now, we haven't discussed the low quality of AI codes as often as in the past. On the one hand, Claude itself has become stronger, and on the other hand, we have the right certification mechanism to ensure the quality of delivery.
What about product development? Now you can do a lot of functionality in one day. Will there be a lot of low-quality product functions? I have recently seen the view that the right way to use modelling capabilities is not to increase the number of functions in the production environment tenfold, but to spend more time understanding users, experimenting and making serious decisions about what to build.
I talk about this a lot. There are many very basic principles for software and products, from planning to development to delivery. These principles do not suddenly become irrelevant because Agent has accelerated some of them. But now some people are beginning to develop a inertia. They think that now that Agent has been able to help do something, they don't need to think about it. In fact, engineers should still invest time and effort in those very basic and very important parts of the entire software development process. AI can make it happen faster, but this does not mean that we can omit planning, design, judgement and quality control.
Related links:
1.https://x.com/katelyn_lesse/status/2114542280535318557?s=46
2.https://www.katelynlesse.com/blog/secure-agents-architecture-and-sandboxing
Auto-fetched and translated by AI Atlas. All rights belong to the original author.