你的Agent代码80%与智能无关

80%的生产AI Agent代码是基础设施——状态管理、故障恢复、环境隔离、扩展。只有20%是Agent逻辑。Anthropic决定承担那80%。2026年4月8日，在Claude托管Agent的公开测试中，该公司发布了首个来自模型提供商的托管Agent平台。

大多数今天构建Agent的团队都在与同样的比例搏斗。数月的工作花在重试逻辑、容器、会话状态上——在任何人看到工作的Agent之前。这不是一个关于更好提示的问题。这是一个关于架构的问题。

1、失败的数学：为什么95%的可靠性不够

想象一条20个链接的链条。每个以95%的概率保持。整个链条在三分之二的情况下会断裂——0.95的20次方只是36%。失败累积——可靠性复合——是一个乘法问题，而不是加法问题。每增加一步都会乘以整个链条失败的可能性。

1.1 四类生产失败

这不是理论计算。Latitude AI的数据确定了生产中Agent失败的四个类别：

• 推理漂移——Agent逐渐偏离其原始目标
• 工具调用失败——工具错误在整个工作流中级联
• 上下文窗口饱和——上下文窗口填满，Agent忘记早期的约定
• 目标错位——Agent为字面指令而不是实际目标进行优化

可靠性数学是严酷的：每步1%的错误率超过100步，整个工作流失败的概率是63%——不是因为模型弱，而是因为错误累积。**灾难性失败的歷史告诉我们比统计数据更多。**一个Claude Code Agent陷入无限npm install循环，执行超过300次，持续4.6小时，消耗约2700万token。另一个案例涉及5小时内泄漏16.7亿token——成本在16000到50000美元之间。Kiro Agent自主删除了一个生产AWS环境，导致13小时停机。

1.2 一个类别错误

关键洞察：大多数团队将这些失败视为模型问题，并尝试用更好的提示来修复。**这是一个类别错误。**所有四类失败都是基础设施问题——它们需要状态管理、恢复机制和隔离，而不是更好的模型。80/20比例存在是因为80%的失败模式需要基础设施。

也就是说——如果你的Agent在30分钟后失败，不要寻找更好的提示。检查你是否有恢复、状态管理和隔离。

既然问题是基础设施——专门为Agent设计的基础设施应该是什么样的？

"文明通过扩展我们可以在不思考的情况下执行的重要操作数量而进步。"——阿尔弗雷德·诺斯·怀特黑德，数学家和哲学家

2、三个组件：Anthropic如何虚拟化Agent

这里的操作系统类比是精确的，不是装饰性的。Unix将硬件虚拟化为稳定的抽象——read()调用在1970年代的磁带和现代SSD上工作相同。Claude托管Agent将Agent组件虚拟化为与实现无关的接口。

2.1 从单体到解耦

该平台由三个独立可交换的组件组成。会话——一个仅追加的事件日志，存在于挽具和沙箱之外的Agent持久内存。挽具——一个无状态的调用循环，将Claude连接到工具并将工具调用路由到适当的基础设施。沙箱——一个一次性使用的隔离代码执行环境。每个组件都可以在不破坏其他组件的情况下替换。

从单体到解耦的演变是痛苦的。Anthropic的第一个实现将所有组件放在单个容器中——会话、挽具和沙箱。结果是经典的基础设施"宠物"——一台需要手动护理的命名服务器。当容器死亡时，会话丢失。挽具错误、事件流中的数据包丢失或容器离线——从外部看都是一样的。

解决方案：挽具离开容器。不是直接文件访问，沙箱像任何其他工具一样被调用：execute(name, input) → string。容器变成了"牲畜"——一个可处置的资源而不是需要护理的宠物。

如果失败，挽具将错误捕获为工具调用错误。新容器通过provision({resources})出现。如果挽具失败——新容器通过wake(sessionId)启动，获取事件日志，并从最后一个事件恢复。

2.2 元挽具，不是挽具

Anthropic测量了结果： p50 TTFT（第一个token的时间）下降了约60%，p95下降了超过90%。不需要沙箱的会话不需要为其启动付费。

在我看来，关键区别更微妙。Anthropic没有构建特定的挽具—— 他们为挽具构建了一个挽具。元挽具是一组稳定的接口，而不是具体的实现。

特定的挽具编码关于模型约束的假设。编码模型变化而生存的接口的元挽具。它与分布式系统中相同的原则，应用于AI Agent。

三个独立可交换的组件——会话在脑（挽具）和手（沙箱）故障中生存。

三个组件分离。一个关键问题仍然存在——当会话运行数小时，如何管理模型看到的内容。

"我们看到的世界是我们准备让自己看到的世界。"——威廉·詹姆斯，心理学家和哲学家

3、上下文管理：模型看到的比你告诉它的更重要

上下文工程——管理模型在任何给定时刻"看到"的内容——是生产Agent最困难的方面，因为它是无形的。没有人看到上下文退化，直到Agent开始做出奇怪的决策。这不是提示工程，不是RAG——这是对模型整个上下文的系统管理。

3.1 上下文腐烂和上下文焦虑

上下文腐烂——精度随着上下文窗口填充而下降——比官方限制建议的开始得早得多。Agent在128K-200K token时退化，远在模型限制之前。Transformer架构需要n个token的n²注意对——token越多，注意能力越拉得越紧。实际效果：一个在5轮后写出完美TypeScript的Agent在25轮��忽视指令并切换到Python，因为原始的"仅使用TypeScript"命令被推到了上下文中间，模型关注最少。

最初，我们认为上下文腐烂是一个模型限制——原来是挽具设计问题。上下文焦虑——Cognition AI在Devin为Claude Sonnet 4.5重建时发现的异常行为——确认了诊断。模型因为感觉接近上下文限制而匆忙完成任务。

Anthropic在工程博客上描述这种模式，指出这些假设——比如为特定模型添加的上下文重置——随着每次新发布而老化。为Sonnet 4.5解决问题的相同重置成为Opus 4.5的负担。这是元挽具优于特定挽具的关键论点。

3.2 会话不是上下文窗口

会话不是上下文窗口。这个区别是根本的。会话是一个外部的持久事件日志——发生的事情的完整历史。上下文窗口是一个短暂的视图，挽具从该历史构建。getEvents()接口让挽具选择事件流的位置片段，并在将它们传递给Claude之前进行转换。

挽具成为上下文工程师——决定模型现在应该看到完整历史中的什么。三种技术解决长视野上下文问题：

• 压缩——总结旧事件，原始内容保存在会话日志中
• 结构化笔记——Agent定期将笔记写到上下文窗口外的文件，以便以后检索
• 子Agent架构——专门的子Agent处理具有干净上下文窗口的专注任务，返回压缩摘要

最后一种技术与单个Agent相比提高结果超过90%。

如果你的Agent在30分钟后开始做奇怪的决策——可能不是幻觉。这是上下文腐烂。像监控服务器内存一样监控上下文窗口使用。

理解架构和上下文。现在关键问题是：何时使用托管平台，何时自己构建。

"最重要的决定不是关于做什么，而是关于不做什么。"——彼得·德鲁克，现代管理之父

4、决策的五个维度

"平台vs框架vs自制"架构决策不会简化为单一维度。这就像选择租公寓、建房子和买地——每个选项在不同情况下都有意义。五个对比维度提供具体标准而不是笼统的话。

5.1 状态模型和隔离

维度1：状态模型。Claude托管Agent使用仅追加的会话日志——一个外部的持久事件日志。LangGraph使用带检查点的类型化状态图，在每个超级步骤后检查点到数据库。CrewAI提供带有从执行历史重放的@persist状态。

Temporal提供具有完整历史和确定性重放的事件源。AWS Bedrock AgentCore使用托管状态，每会话一个microVM。

维度2：隔离。托管Agent提供内置沙箱——每个会话一个容器，凭证在保险库中。LangGraph和CrewAI不提供原生隔离——你必须自己构建。Temporal需要带有外部平台的容器。Bedrock AgentCore为每个会话提供专用的microVM。

5.2 恢复和锁定

维度3：故障恢复。托管Agent中的wake(sessionId)自动从事件日志恢复Agent。LangGraph提供从最后一个检查点恢复，跳过成功的节点。CrewAI有有限的恢复。

Temporal保证持久执行——工作流在服务器故障、重启和网络中断中生存。一家企业报告99.999%的正常运行时间。

维度4：锁定。托管Agent仅适用于Claude模型和Anthropic基础设施。LangGraph、CrewAI和Temporal是开源的——零模型锁定。Bedrock AgentCore与框架无关和多模型，但绑定到AWS生态系统。

5.3 成本和何时选择什么

维度5：成本。托管Agent每会话小时0.08美元加上标准token费率——以毫秒计量的会话小时定价。LangGraph、CreamAI和Temporal需要你自己的基础设施——软件是免费的，但托管、维护和工程时间不是。Bedrock AgentCore按秒vCPU+GB小时计费。

没有单一的正确答案。当速度到市场和可靠性是优先事项时，托管Agent获胜——Rakuten在不到一周内部署了专门的Agent，Sentry从数月缩短到数周。当你想完全控制决策图且不想要锁定时，LangGraph获胜。 当你有基础设施团队和监管要求时， Temporal+自定义挽具获胜——建立在Cadence（Uber，约2015）基础上，经过十多年持久执行生态系统的演进。

根据我的经验，最糟糕的决定是没有决定——从头构建而不意识到它是架构选择。68%的生产Agent最多执行10个步骤。大多数团队不需要长视野能力——他们需要短工作流的坚实基础设施。

表格帮助你选择。如果你选择托管平台——你必须面对每个架构师都知道的问题。

"自由不是没有约束——而是选择你接受的约束的能力。"——让-保罗·萨特，哲学家

6、黄金笼：选择托管平台时你放弃什么

Agent平台中的供应商锁定与传统云中的锁定不同。在云中，锁定是关于基础设施——计算、存储、网络。**在Agent平台中，锁定覆盖三层：**模型（仅Claude）、基础设施（Anthropic托管）、工具（集成）。

MCP——模型上下文协议——中和最难的一层。Agent模型和工具之间的开放通信协议，由Anthropic发起并转移到Linux基金会，已成为事实上的标准。OpenAI、Google、AWS、Azure——都采用了它。如果你的工具通过MCP通信，迁移成本降至交换编排器，而不是重写集成。这是一个结构性逃出口——内置于架构中的缓存机制，而不是之后附加的。

6.1 两层保留

两层锁定保留：模型（仅Claude）和状态（Anthropic生态系统中的会话）。实际上，两者都比工具层更容易迁移。开源替代品——包括LangChain深度Agent部署——在发布后不久出现，证实市场已经在构建替代品。

诚实的分析需要背景。70%的受监管企业每三个月重建一次他们的Agent堆栈。问题不是"是否迁移"——而是"何时"。每个架构师在选择平台之前应该问五个问题：

• 如果需要迁移，我能导出会话日志吗？
• 工具接口对其他提供商够标准吗？
• 我离开时审计数据会发生什么？
• 最坏情况的迁移成本是多少？
• 我的多模型策略与平台锁定兼容吗？

不要问"是否有锁定"——总是有。**问"最坏情况的迁移成本是多少"。**如果你使用MCP作为工具层，答案比没有它要好得多。

做出决定，评估锁定。平台不能做一切——这是你的挽具仍然需要做的。

"生命中唯一的常量是变化。"——赫拉克利特，古代哲学家

7、老化假设：为什么平台不消除挽具

"LLM把脚手架当早餐吃。"Nicolas Bustamante的短语精确描述了基本动态：模型越来越有能力处理以前需要硬编码挽具的逻辑。脚手架——补偿模型限制的代码——随着模型改进变得不必要。

上下文焦虑的故事完美地说明了这一点。解决了Sonnet 4.5问题的相同上下文重置成为Opus 4.5的负担。挽具编码假设。假设会老化。每次新模型发布都可能使部分挽具逻辑失效。

7.1 平台如操作系统，挽具如应用程序

托管平台接管基础设施——会话、恢复、隔离、扩展、安全。那是80%的Agent代码。**剩余的20%——领域逻辑——是最困难的部分。**工具验证、路由、领域特定的上下文工程、每次模型发布的迭代。矛盾的是，平台让你有时间专注于那20%，而不是与管道搏斗。

根据我的经验，团队犯的最大错误是将托管平台视为"现成的Agent"。平台是操作系统。你的挽具是应用程序。操作系统管理内存和磁盘，但应用程序必须知道如何处理它们。

将挽具设计为薄层——平台和领域逻辑之间的薄自适应层。不要为永久性优化——为变化优化。每季度检查哪些挽具假设已过期。这是我们与微服务看到的相同模式：混乱→框架→托管平台。Agent是新的微服务。

"瞄准无限，达到完美。瞄准完美，达到平庸。"——塞缪尔·约翰逊，作家和词典编纂者

8、关键要点

开头的80/20比例既是诊断也是处方。 80%的Agent代码是基础设施，不是智能——这是使用平台的论据，而不是更好的模型。这是你从本文中得到的：

• 每步95%可靠性×20步=36%成功机会。可靠性复合是乘法问题。在改进提示之前——修复基础设施。
• 三个组件——会话、挽具、沙箱——独立可交换。会话在脑和手故障中生存。如果你的Agent在容器失败时丢失状态——你是单体，不是生产架构。
• 上下文工程>提示工程。像服务器内存一样监控上下文窗口使用。会话不是上下文窗口——它是持久内存，挽具从中构建短暂视图。
• 决策表有五个维度，不是一个。打印它。下次你的团队辩论"什么框架"——重定向到"哪个维度是我们的优先事项"。
• MCP中和工具锁定。迁移成本降至交换编排器。在选择平台之前问五个迁移问题。
• 平台不消除挽具——它改变比例。将挽具设计为薄层并每季度重新审视。

8.1 一个警告

这仍在测试中。多小时会话可靠性的生产数据尚不存在。比较托管Agent与Bedrock AgentCore在相同任务上的独立基准测试也不存在。 将这个平台视为架构承诺，而不是成品。一个工程良好的承诺——但承诺。

原文链接：80% of Your Agent's Code Has Nothing to Do With Intelligence — Managed Agents

汇智网翻译整理，转载请标明出处