Anthropic近期完成了一项具有标志性的工程改造：一个最初缺少Rust开发者的团队，利用Claude，将公司的Messages API从Python迁移至Rust。Anthropic平台工程负责人Katelyn Lesse表示，改造后相关服务的CPU使用量下降了大约40%至50%，首Token延迟也缩短了约10%至20%。
在此项目中，Claude承担了大部分代码编写任务，而人类工程师主要负责系统架构、迁移策略和验证方案。一个通常需要大量人工编码的复杂项目，如今可以借助AI完成。那么，当AI已经能处理如此复杂的开发任务，软件工程师还能做什么？他们又该如何证明自身价值？
Katelyn对此持乐观态度。10月26日，她在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在文章中明确区分了两个概念：身份认证和授权。前者回答“你是谁”，后者则决定“你能做什么”。对于前者，软件行业已经有较成熟的工作负载身份、短期证书等技术可以借鉴；真正复杂的是，当Agent开始代表用户长期执行任务，甚至自主创建子Agent时，权限应该如何分配和传递。
目前，许多Agent实际上是在代表人类用户工作。它们使用用户的身份和凭据访问不同系统，代替用户执行操作。问题是，当某个文件被修改、某项操作被执行时，系统如何区分，这究竟是用户本人所为，还是Agent代替用户完成的？
当Agent开始长时间自主运行，授权问题还会变得更加棘手。例如，用户授权一个Agent持续数周处理开发任务，Agent又将部分工作委托给子Agent。此时，子Agent能否继承原有权限、继承多少、授权有效期如何确定，都需要重新设计。尤其是当Agent准备执行超出用户最初预期的操作时，系统还必须判断是否需要人类再次确认。
Katelyn特别提到了代表用户行事的OBO模式。传统的OBO授权模式可以让服务代表用户访问其他资源，但Agent的自主性和任务持续时间，使权限委托变得更加复杂。系统不仅需要确认Agent代表谁执行操作，还需要明确授权范围、委托链条以及权限撤销后的处理方式。
更复杂的情况是，如果未来的Agent不再依赖人类用户的身份，而是拥有自己的独立身份，应该如何为它们分配权限？当多个Agent需要相互协作，一个Agent向另一个Agent发出请求时，后者又该如何确认对方的身份、判断这项请求是否获得授权？这些问题目前仍缺少成熟的解决方案，仍是工程师需要解决的新问题。
3 安全隔离：Agent被攻击后，如何限制风险扩散？
过去几个月，尤其是最近几周，软件漏洞接连暴露，出现的速度甚至超过了行业修复漏洞的速度，其中不少涉及大量系统赖以运行的关键基础软件。
Katelyn指出，当成千上万个Agent持续运行，不断编写、执行不可信代码，并读取来源不可信的内容时，基础软件中尚未修复的漏洞可能带来更大的安全风险。因此，如何加固操作系统内核、浏览器、运行时环境和常用软件库，成为软件工程师需要解决的重要问题。
此外，多智能体系统还会引入另一类风险。
假设一个Agent在执行任务时读取了包含恶意指令的网页或文件，并受到提示词注入攻击。如果它只是独立运行，风险可能局限于当前任务；但如果它需要与其他Agent协作，恶意内容就可能通过通信传递给其他Agent，甚至进入共享记忆，影响之后的任务。
这时，攻击的影响范围就成为一个必须认真考虑的问题：如果第一个Agent被攻破，整个多Agent系统中究竟有多少部分可能受到牵连？在她看来，强隔离的执行环境是重要的基础。
实际上，早在9月13日，Katelyn就曾专门撰文讨论Agent的安全架构，提出将Agent的“大脑”与“双手”分开。
所谓“大脑”，包括负责模型调用、工具调用和用户交互的Agent Harness，以及需要持久保存的会话状态和访问凭据。这些组件应当运行在沙箱之外的可信基础设施中。而作为“双手”的沙箱，则负责执行Agent生成的代码和命令，处理可能包含恶意内容的外部数据。
这套架构的关键，是让不可信代码始终运行在权限受限的环境中。Agent需要访问外部服务时，由沙箱外的可信代理完成凭据注入和访问控制，避免敏感密钥直接暴露给沙箱内的代码。即使Agent遭遇提示词注入或执行恶意代码，攻击者能够接触的资源也受到限制。
4 如何识别Agent是在努力完成任务，还是已经失控？
即使有了隔离措施，工程师仍然面临另一个问题：如何及时发现Agent已经出现异常？
假设某个Agent为了完成任务，不断尝试访问一个不在允许名单中的域名。它究竟是在努力寻找完成任务的方法，还是已经受到恶意指令影响，正在尝试突破限制？
这是Katelyn在长文中提出的一个场景。两种行为从外部看可能非常相似，而在多个Agent相互协作的系统中，判断异常行为就更加困难。工程师不仅需要知道每个Agent做了什么，还需要了解任务如何在不同Agent之间传递，才能排查问题。
为此，Katelyn提到了基于OpenTelemetry的跨Agent分布式链路追踪，让工程师能够追踪整个任务的执行过程。同时，追踪记录必须保存在Agent无权篡改的可信系统中，防止Agent修改自己或其他Agent的操作记录，影响后续调查。
除了发现异常，系统还必须具备及时制止风险的能力。Katelyn特别强调了紧急停止机制：一旦发现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代码，更重要的是如何证明新系统能够安全替代旧系统。团队还使用了影子流量等方法，让新旧实现处理相同或等价的请求，对比输出结果，再逐步验证并切换流量。
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：是的，我们刻意克制了增加新功能的冲动。我更愿意把它称为一次移植。我们专门组建了一支小团队来完成这件事，与此同时，其他团队还在继续为原有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表现的新功能
近期文章
