一个让工程师夜不能寐的问题

2026年4月13日，一篇标题为《Claude is getting worse, according to Claude》的报道出现在 The Register 上。报道的核心荒诞之处在于：用户们用 Claude 自身来测试 Claude 的性能退化，而 Claude 给出了自我确认的答案。与此同时，Fortune 的报道显示，Anthropic 正面临大规模用户反弹浪潮——性能问题、响应质量下降、透明度不足，这些投诉在企业客户群体中尤为集中。(来源: The Register, 2026-04-13; Fortune, 2026-04-14)

这不是一家公司的公关危机。这是整个 Agent 架构范式在生产压力下暴露的结构性裂缝。

企业 AI Agent 的可靠性问题，在过去18个月里已经从工程师的私下抱怨演变为一个可量化的商业风险。Nava——一家专注于防止 AI 金融 Agent 失控的初创公司——在2026年4月完成了830万美元种子轮融资，其融资叙事的核心命题就是：现有 Agent 架构在企业金融场景中存在根本性的可靠性缺陷，需要独立的护栏层来防止代价高昂的错误。(来源: Fortune, 2026-04-14)

这个融资事件本身就是一个信号。当市场开始为「防止 AI Agent 出错」这件事单独付费，说明问题的严重程度已经超越了可以用 prompt engineering 修补的范畴。

本文要论证的核心命题是：企业 Agent 在生产环境中的高失败率，根源不在于模型能力不足，而在于「脑」与「手」的耦合架构——决策层与执行层混合在同一个不可控单元中，导致错误传播路径无法被截断。Anthropic 近期围绕 Claude 的多 Agent 托管能力和 AWS AgentCore 的 Agent Registry 所构建的基础设施方向，正在尝试系统性地解决这个问题。理解这个架构分离的逻辑，是理解下一代企业 AI 基础设施竞争格局的关键。

重要说明：本文对「脑手分离」架构的技术细节分析，部分基于 Anthropic 已公开的多 Agent 编排文档和 AWS AgentCore 的官方功能描述，部分基于作者对分布式系统架构原理的推演。文中会明确标注哪些是官方公布的设计，哪些是作者的架构推断，以便读者自行判断。

第一层：现有 Agent 架构为什么在企业生产环境中失败

1.1 失败的解剖学

要理解为什么 Agent 在生产环境中失败，需要先理解「生产环境」与「演示环境」之间的本质差异。

在演示环境中，Agent 的任务路径是预设的，工具调用序列是经过调试的，失败案例已经被人工过滤。一个能在演示中完美完成「查询数据库-生成报告-发送邮件」三步任务的 Agent，在生产环境中面对的是：数据库连接超时、邮件服务 API 限流、用户意图表述模糊、工具返回格式不一致、并发请求导致状态冲突等数十个变量同时存在的混沌状态。

企业生产环境的核心特征是：不确定性是常态，而非异常。

关于 Agent 在生产环境中的实际失败率，目前缺乏公开的、经过严格方法论验证的行业级统计数据。但多个间接信号指向问题的严重性：Gartner 在2025年的 Hype Cycle 中将 Autonomous AI Agents 置于「期望膨胀峰值」阶段，暗示实际部署效果与市场预期之间存在显著落差；Deloitte 2025年的企业 AI 调查报告显示，超过65%的企业 AI 项目未能从试点阶段推进到全面生产部署，其中「可靠性和可控性不足」是排名前三的阻碍因素。(来源: Gartner, 2025; Deloitte, 2025) 虽然这些数据并非专门针对 Agent 架构，但它们描绘了企业 AI 生产化面临的系统性挑战。

现有主流 Agent 架构——无论是基于 ReAct 框架的单体 Agent，还是 AutoGPT 式的自循环 Agent——都存在一个共同的结构性问题：推理层（脑）和执行层（手）高度耦合。

具体表现为：

错误传播不可截断。当 Agent 在第3步做出了一个基于错误前提的推理，这个错误会被携带进第4步、第5步的工具调用中。在一个10步的任务链中，第3步的推理错误可能在第8步才以「数据写入错误」的形式显现，此时回溯和修复的成本已经远超重新执行整个任务。

状态管理是个黑盒。传统 Agent 架构中，任务状态通常存储在模型的上下文窗口（context window）中。这意味着状态是不透明的、难以外部监控的、且受到 context 长度限制的。一个需要处理500个步骤的企业工作流，在 context 窗口耗尽时会发生什么？答案通常是：静默失败，或者产生幻觉式的「假完成」。

工具调用缺乏权限隔离。在单体 Agent 架构中，负责「思考下一步做什么」的组件与负责「实际执行操作」的组件共享相同的权限上下文。这意味着一旦推理层被注入攻击（prompt injection）或产生幻觉，执行层没有独立的防护机制来拦截危险操作。

可观测性严重不足。企业运维团队需要回答的问题是：「这个 Agent 在过去24小时内做了什么，为什么做，哪些步骤失败了，失败原因是什么？」在耦合架构中，这些问题几乎无法被系统性地回答，因为推理过程和执行过程混合在同一个不透明的推理链中。

1.2 金融场景：失败代价的量化

Nava 的融资案例提供了一个具体的行业视角。这家公司的产品定位是为 AI 金融 Agent 提供「护栏」——本质上是在现有 Agent 架构之外，额外构建一个独立的决策审查层。(来源: Fortune, 2026-04-14)

金融场景的特殊性在于：错误的代价是直接的、可量化的、且通常不可逆的。一个 Agent 错误地执行了一笔转账，或者在错误的时机触发了一个交易，损失是实实在在的美元数字。Forrester 在其关于 Agentic Payments 的分析中指出，B2C 商业场景中的 Agent 支付正处于早期阶段，核心挑战之一是信任与控制机制的缺失。(来源: Forrester, 2026-04) 需要指出的是，Forrester 讨论的 Agentic Payments 侧重于消费者支付场景中的 Agent 代理行为，与 Nava 所关注的金融交易 Agent 失控问题并非完全相同的领域——但两者共同指向了一个更广泛的命题：当 AI Agent 触及资金流动，信任和控制机制的缺失会被急剧放大。

这解释了为什么 Nava 能在这个时间节点以830万美元完成种子轮：投资者和企业客户都意识到，现有 Agent 架构在高风险场景中的可靠性不足以支撑真实的业务部署。

但 Nava 的解法——在现有架构外叠加护栏层——本质上是一种补丁式修复。它没有解决根本的架构问题，只是在已经发生错误之后提供了一个拦截层。这就像在一辆刹车系统设计有缺陷的汽车外面加装一个紧急停车装置：有用，但不优雅，且增加了系统复杂度。

1.3 可靠性危机的信号密度

The Register 的报道揭示了一个更深层的问题：Claude 的性能波动不仅影响了普通用户，也波及了依赖 Claude API 构建产品的企业开发者。(来源: The Register, 2026-04-13) 对于一个将 AI Agent 嵌入核心业务流程的企业来说，底层模型的性能不稳定是一个系统性风险——因为在耦合架构中，模型性能的任何波动都会直接传导到业务结果。

Fortune 的报道进一步指出，用户反弹的一个重要原因是「透明度不足」——当 Claude 的性能出现问题时，用户和企业客户很难获得关于问题原因、影响范围和修复时间线的清晰信息。(来源: Fortune, 2026-04-14) 这个透明度问题，在技术层面的根源恰恰是可观测性的缺失：当「脑」和「手」耦合在一起时，很难精确定位问题出在推理层还是执行层。

第二层：托管分离架构的技术逻辑

2.1 「脑」与「手」分离的核心原理

Anthropic 在其官方文档中描述了 Claude 的多 Agent 编排能力：一个主 Agent（orchestrator）可以创建和管理多个子 Agent（sub-agents），每个子 Agent 拥有独立的工具集、系统提示和权限范围。主 Agent 负责任务分解和结果整合，子 Agent 负责在各自受限的范围内执行具体操作。(来源: Anthropic Docs, Multi-agent systems)

基于这个官方描述的多 Agent 编排框架，我们可以提炼出一个更广泛的架构原理——编排层与执行层的分离：

编排层（Orchestration Layer / 「脑」）：负责任务理解、计划生成、步骤分解、结果评估和错误恢复决策。这一层的核心是 Claude 主 Agent，其职责是「思考」——决定做什么、以什么顺序做、如果出错了怎么调整。

执行层（Execution Layer / 「手」）：负责实际的工具调用、API 交互、数据读写和外部系统集成。这一层的核心是受托管的子 Agent 和工具集合，其职责是「执行」——按照编排层的指令，在各自受限的权限范围内与外部世界交互。

以下是作者基于分布式系统架构原理的推断：这两层之间的分离，如果要在企业生产环境中真正发挥可靠性价值，需要通过明确的接口协议、独立的权限模型和独立的可观测性管道来实现更接近物理隔离的效果。Anthropic 官方文档目前描述的是子 Agent 拥有独立的工具集和系统提示，但关于接口协议的标准化程度、权限模型的隔离深度，官方尚未提供完整的技术规格。

这个设计的关键洞察是：大多数 Agent 失败不是因为模型「不够聪明」，而是因为推理错误和执行错误被混淆在一起，导致无法精确诊断和修复。

2.2 AWS AgentCore：基础设施层的配套

2026年4月，AWS 宣布 AgentCore 中的 Agent Registry 功能进入 Preview 阶段。(来源: AWS, 2026-04) Agent Registry 的核心功能是集中化的 Agent 发现和治理（centralized agent discovery and governance）。

根据 AWS 官方公告，Agent Registry 提供的功能包括：

Agent 身份管理：每个 Agent 都有明确的身份标识、能力描述和元数据。这为多 Agent 系统中「谁在做什么」的可追溯性提供了基础。

能力发现：编排层可以动态发现可用的 Agent 及其能力，而不需要硬编码工具集合。这提高了系统的灵活性和可扩展性。

治理和审计：企业可以集中管理 Agent 的访问控制策略，并获得跨所有 Agent 的统一审计日志。

需要明确的是：AWS AgentCore 的 Agent Registry 是一个通用的 Agent 治理基础设施，适用于在 Amazon Bedrock 上运行的各类 Agent，并非专门为 Claude 的多 Agent 架构设计。但考虑到 Anthropic 与 AWS 的深度合作关系——Amazon Bedrock 是 Claude 模型的主要云端部署平台之一——两者的技术整合使得 Claude 的多 Agent 编排能够在企业级基础设施上获得原生的治理支持。作者推断：随着 Agent Registry 的成熟，它将成为 Claude 多 Agent 系统在企业部署中的关键配套组件，尽管目前两者的集成深度尚未被官方详细披露。

2.3 错误隔离：分离架构的可靠性机制

分离架构对可靠性的最核心贡献是错误隔离。以下分析基于分布式系统的通用架构原理，结合 Anthropic 多 Agent 文档中子 Agent 拥有独立工具集和权限范围的设计特征进行推演。

在耦合架构中，一个推理错误会直接触发一个执行操作，然后执行结果又成为下一次推理的输入，形成一个错误放大的正反馈循环。

在分离架构中，编排层和执行层之间存在一个明确的任务委派接口。编排层生成的是任务意图——「我需要查询用户ID为12345的账户余额」，执行层（子 Agent）将这个意图转化为具体的 API 调用。这个转化过程可以被独立审查和过滤。

作者推断：在理想的分离架构实现中，执行层还可以实现幂等性保证（idempotency guarantee）——同一个意图被执行多次，结果应该是一致的。这使得错误恢复变得可操作：当执行失败时，系统可以安全地重试，而不需要担心副作用的叠加。对于金融场景来说，这个特性的价值尤为突出。一个「转账1000美元」的意图，即使因为网络超时被重试了3次，也应该只产生1次转账，而不是3次。在耦合架构中实现这个保证需要大量的特殊处理；在分离架构中，它可以在执行层统一实现。需要强调的是，幂等性保证是一个需要在执行层显式工程化实现的特性，分离架构提供了实现它的结构性条件，但并不自动保证它的存在。

2.4 权限模型的重构

分离架构的另一个关键优势是最小权限原则的可实施性。

Anthropic 的多 Agent 文档明确指出，子 Agent 可以被配置为仅访问特定的工具集，且拥有独立于主 Agent 的系统提示来约束其行为范围。(来源: Anthropic Docs, Multi-agent systems) 这为权限隔离提供了基础。

在耦合架构中，负责推理的模型和负责执行的工具共享相同的运行时上下文，这使得细粒度的权限控制非常困难。如果模型有权读取数据库，它通常也有权写入数据库——因为区分读写权限需要在每次工具调用时进行上下文感知的权限判断，而这个判断本身又依赖于模型的推理，形成了循环依赖。

在分离架构中，子 Agent 的工具集和权限边界由系统设计者在部署时独立配置。作者推断：这意味着在理想实现中——

  • 一个被 prompt injection 攻击的编排层，其影响范围受限于子 Agent 预设的工具集边界，无法调用未被授权的工具
  • 企业安全团队可以独立审查和调整子 Agent 的权限策略，而不需要修改主 Agent 的 prompt 或行为
  • 不同的业务场景可以配置不同权限集的子 Agent，而共享同一个编排层模型

当然，这种权限隔离的有效性取决于实现细节——例如，主 Agent 是否能动态修改子 Agent 的工具集？子 Agent 之间是否存在权限泄露的可能？这些问题在 Anthropic 当前的公开文档中尚未被完整回答。

2.5 可观测性的系统性改善

Project Glasswing 是 Anthropic 在 AI 安全基础设施领域的一个重要举措，其官方描述聚焦于为 AI 时代的关键软件提供安全保障。(来源: Anthropic, 2026-04) 需要指出的是，Glasswing 的官方页面描述的是通用的 AI 安全基础设施愿景，并未明确提及与 Claude 多 Agent 编排的具体技术集成。但从战略方向上看，Glasswing 对 AI 系统安全性和可审计性的关注，与多 Agent 分离架构对可观测性的需求存在天然的互补性。

以下是基于架构原理的分析：分离架构天然支持更好的可观测性，因为：

推理链和执行链可以独立记录。编排层的每一个推理步骤、每一个计划决策，都可以被独立捕获和存储，而不需要从混合的执行日志中反向推断。

失败定位精确化。当一个任务失败时，系统可以明确区分：是编排层的推理产生了错误的任务委派（模型问题），还是执行层在执行正确任务时遇到了障碍（基础设施问题）？这两类问题的修复路径完全不同。

业务指标与技术指标分离。企业运维团队关心的是「这个任务完成了吗，对业务有什么影响」；工程团队关心的是「哪个组件失败了，为什么失败」。分离架构使得这两个层次的监控可以独立构建。

第三层：大多数人没有看到的东西

3.1 这不只是一个架构选择，而是一个商业模式重构

大多数关于多 Agent 编排的讨论停留在技术架构层面：分离好还是耦合好，可靠性如何提升，安全性如何增强。但这个架构选择背后有一个更深层的商业逻辑，很少被明确讨论。

托管分离架构将 Anthropic 从「模型提供商」转变为「Agent 基础设施提供商」。

这个转变的商业含义是巨大的：

在「模型提供商」模式下，Anthropic 的收入来自 API 调用，竞争维度是模型性能和价格。这是一个相对标准化的商品市场，竞争对手包括 OpenAI、Google DeepMind、Meta 等。

在「Agent 基础设施提供商」模式下，Anthropic 的价值主张变成了：「我们不只是提供一个聪明的模型，我们提供一套完整的、企业级的 Agent 运行环境，包括编排、执行、监控、治理和安全」。这个价值主张的竞争维度更加复合，切换成本更高，且与企业的核心业务流程深度绑定。

AWS AgentCore 和 Agent Registry 的推出，以及 Amazon Bedrock 对 Claude 模型的原生支持，实际上是在帮助 Anthropic 构建这个基础设施层的护城河。(来源: AWS, 2026-04) 对于企业客户来说，当他们的 Agent 工作流深度集成了 AWS AgentCore 的治理机制和 Claude 的多 Agent 编排能力，迁移到其他平台的成本会显著提升。

3.2 Claude Mythos 与分离架构的战略关联

2026年4月，Amazon Bedrock 宣布 Claude Mythos 进入 Gated Research Preview 阶段。(来源: AWS, 2026-04) 与此同时，Anthropic 联合创始人确认公司已就 Mythos 向 Trump 政府进行了简报。(来源: TechCrunch, 2026-04-14)

Claude Mythos 代表了 Anthropic 在模型能力上的新一代突破，但它与分离架构的关系不是简单的「更好的脑」替换「旧的脑」。

关键洞察在于：更强大的模型在耦合架构中可能带来更高的风险，而不是更高的安全性。

一个能力更强的模型意味着：更复杂的推理链、更多的工具调用、更长的执行序列、更大的操作范围。如果这个更强大的模型仍然在耦合架构中运行，它的每一个推理错误都会被放大为更大规模的执行错误。

这就是为什么分离架构必须先于或同步于 Mythos 级别的模型能力部署：能力的扩张必须与控制框架的完善同步进行，否则可靠性问题会随着模型能力的提升而指数级恶化。

Anthropic 向 Trump 政府简报 Mythos，部分原因可能正是为了展示这个「能力-控制」同步框架的完整性。在政策层面，一个能力极强但控制框架完善的 AI 系统，比一个能力中等但控制框架薄弱的系统更容易获得监管信任。

3.3 自动化对齐研究：「脑」的长期演化方向

Anthropic 的 Automated Alignment Researchers 研究项目——使用大型语言模型来辅助对齐研究——揭示了一个更长远的战略意图。(来源: Anthropic Research, 2026-04)

这个研究方向的核心命题是：如果 AI 模型可以参与自身的对齐研究，那么对齐过程可以被显著加速。

以下是一个前瞻性推测，而非基于当前技术现实的描述：如果这个研究方向取得突破，未来的编排层模型可能越来越接近「能够理解自身行为边界」的系统。在多 Agent 架构中，这意味着编排层在生成任务委派时就能进行某种程度的自我审查——「这个任务委派是否超出了我应该执行的范围？」——而不需要完全依赖执行层的外部护栏。

但必须承认，当前的技术距离这一愿景仍有显著差距。现有的对齐技术（包括 RLHF、Constitutional AI 等）主要在训练阶段发挥作用，而非在推理时的实时自我审查。从「AI 辅助对齐研究」到「编排层实时自我审查」之间，存在多个尚未解决的技术跳跃。

这个推测的价值在于：它暗示了分离架构不是一个静态的设计，而是一个动态演化的框架。随着编排层模型的对齐能力提升，「脑」的自主决策范围可以逐渐扩大；同时，执行层的护栏机制可以相应调整，而不需要重新设计整个系统。

3.4 性能退化问题的架构解读

回到文章开头的 Claude 性能退化事件。The Register 和 Fortune 的报道都指向了一个现象：Claude 的性能波动影响了大量用户，但 Anthropic 在解释和沟通上的透明度不足。(来源: The Register, 2026-04-13; Fortune, 2026-04-14)

从架构角度解读这个问题，有一个很少被讨论的维度：在耦合架构中，模型性能的波动和基础设施问题的影响是混合在一起的，很难被精确区分和独立诊断。

当用户报告「Claude 变慢了」或「Claude 的回答质量下降了」，这可能是：

  • 模型本身的推理质量变化（可能是训练更新的副作用）
  • 计算资源压力导致的推理截断（Fortune 报道中提到了 compute crunch 的可能性）
  • 工具调用层的延迟增加
  • 上下文管理的效率下降

在耦合架构中，这4种原因产生的用户体验症状是相似的，但修复路径完全不同。Anthropic 的「透明度不足」，部分原因可能正是因为在现有架构下，精确定位问题根源本身就是一个高难度的工程问题。

分离架构在这个问题上的价值是：它使得性能问题的诊断成为一个可系统化的工程问题，而不是一个依赖专家经验的艺术问题。

第四层：对立视角与我的判断

4.1 反对意见：复杂性的代价

分离架构并不是没有代价的。有几个严肃的反对意见值得正视：

复杂性增加。将单体 Agent 拆分为编排层和执行层，意味着系统中多了一个接口、多了一个部署单元、多了一套监控管道。对于中小型企业来说，这个复杂性增加可能超过了可靠性收益。一个5人工程团队，可能更愿意接受偶发的 Agent 失败，也不愿意维护一套复杂的分离架构。

延迟增加。编排层和执行层之间的通信引入了额外的网络延迟。对于需要实时响应的场景（如客服 Agent），这个延迟可能是不可接受的。Anthropic 的多 Agent 文档中也提到了子 Agent 创建和通信的开销问题。

接口设计的难度。编排层与执行层之间的任务委派接口设计本身是一个非平凡的工程问题。如果接口设计不当，分离架构可能比耦合架构更脆弱——因为接口本身成为了一个新的故障点。

过度工程化的风险。对于很多企业 Agent 用例，任务复杂度根本不需要分离架构。一个「每天早上8点生成销售报告并发送邮件」的 Agent，用简单的耦合架构完全可以可靠运行。

4.2 反对意见：「分离」可能是一个营销叙事而非技术必然

一个更尖锐的反对意见是：Anthropic 推动多 Agent 分离架构，部分动机可能是商业性的而非纯技术性的。通过让企业客户采用更复杂的多 Agent 架构，Anthropic 可以增加 API 调用量（每个子 Agent 都是独立的 API 调用）、提高切换成本、并在基础设施层建立更深的绑定。

这个批评并非没有道理。微服务架构在软件工程领域的历史提供了一个前车之鉴：2010年代中期，微服务被广泛推崇为单体架构的替代方案，但到了2020年代，越来越多的工程团队开始反思过度微服务化带来的运维复杂性，「monolith first」的声音重新出现。Agent 架构领域可能正在经历类似的周期。

4.3 我的判断：分离架构在高风险场景中是必要的，但不是通用解

综合以上分析，我的判断是：

分离架构不是 Agent 架构的通用最优解，但它是企业高风险场景中的必要条件。

以下是作者构建的风险矩阵框架（基于分布式系统设计原则和企业 IT 治理实践的综合考量，非行业标准分类）：

场景维度 适合耦合架构 适合分离架构
操作可逆性 高（可撤销） 低（不可逆）
错误代价 低（用户体验影响） 高（财务/法律影响）
任务复杂度 低（<10步） 高（>50步）
并发规模 低（单用户） 高（企业级）
监管要求 无 有（金融、医疗、法律）

金融 Agent（Nava 的目标市场）、医疗 Agent、法律合规 Agent——这些场景的特征是操作不可逆、错误代价高、有监管要求。在这些场景中，分离架构不是一个「更好的选择」，而是一个「没有替代方案的必要条件」。

Nava 的830万美元种子轮融资，本质上是市场对「Agent 可靠性在金融场景中是刚需」这个命题的资本投票。(来源: Fortune, 2026-04-14)

但对于大量的长尾 Agent 用例——内容生成、数据分析、代码辅助——耦合架构仍然是性价比更高的选择。正确的产品策略应该是：分离架构作为企业级高风险场景的默认选项，耦合架构作为开发者和中低风险场景的默认选项，两者共存而不是相互替代。

4.4 竞争格局分析

从竞争角度看，Anthropic 的多 Agent 编排 + AWS AgentCore 组合面临来自多个方向的竞争压力。这里重点分析 OpenAI 的架构路径差异：

OpenAI 的 Responses API 和 Agents SDK：OpenAI 在2025年推出了 Agents SDK（开源），提供了 Agent 编排、工具调用和 handoff（Agent 间任务移交）等能力。与 Anthropic 的多 Agent 架构相比，OpenAI 的方案更强调开发者友好性和灵活性——Agents SDK 是开源的，开发者可以自由定制编排逻辑。但在企业治理层面，OpenAI 目前缺乏类似 AWS AgentCore Agent Registry 的集中化治理基础设施。这意味着 OpenAI 的方案在开发者市场可能更具吸引力，但在需要严格治理和审计的企业场景中，Anthropic + AWS 的组合可能具有结构性优势。(来源: OpenAI, 2025)

Google 的 Vertex AI Agent Builder 和 Agent Development Kit (ADK)：Google 在2025年推出了 ADK，同样支持多 Agent 编排和工具集成。Google 的差异化在于其云基础设施的规模优势和 Gemini 模型的多模态能力。但 Google 在 AI 安全叙事上的积累不如 Anthropic 深厚，这在政府和监管敏感场景中可能是一个劣势。

垂直场景的专业玩家：Nava 这类专注于特定场景（金融）的 Agent 可靠性解决方案，可能在其垂直市场比通用平台更具竞争力，因为它们可以针对特定行业的合规要求和风险模式进行深度优化。

Anthropic 的差异化优势在于：Constitutional AI 和对齐研究的积累，使其在「可信赖的 Agent 基础设施」这个定位上有更强的叙事基础。特别是在政府和监管敏感场景中，Anthropic 向 Trump 政府简报 Mythos 的动作，表明公司正在主动构建政策层面的信任资产。(来源: TechCrunch, 2026-04-14)

第五层：预判——这意味着什么

5.1 企业 AI 采购标准的重构

在未来12-18个月内，企业 AI 采购决策中「可靠性架构」将从加分项变为必要条件。

这个转变的驱动力是：随着企业 Agent 从「辅助工具」演变为「核心业务流程的执行者」，IT 和法律部门会对 Agent 的可审计性、可控性和故障隔离能力提出越来越严格的要求。

能够提供清晰的编排-执行分离架构文档、完整的审计日志、细粒度权限控制的 Agent 平台，将在企业采购竞争中获得系统性优势。Anthropic + AWS 的组合在这个维度上的准备程度，目前看来优于大多数竞争对手。

5.2 Agent 可靠性市场的形成

Nava 的融资案例预示着一个新的市场类别正在形成：Agent 可靠性和治理工具。

这个市场的形成逻辑类似于早期云计算时代的安全和监控工具市场：当企业开始大规模部署云服务时，独立的云安全和云监控工具市场随之兴起（如 Datadog 2010年成立、Palo Alto Networks 向云安全转型），因为云服务商自身提供的原生工具无法满足企业的差异化需求。

同样的模式将在 Agent 场景中重演。无论 Anthropic 的多 Agent 架构多么完善，总会有企业需要跨平台的 Agent 治理工具、特定行业的合规验证工具、或者比平台原生工具更细粒度的可观测性解决方案。

这意味着 Nava 并不是一个孤立的案例，而是一个新兴市场类别的早期信号。未来12-18个月内，类似的垂直场景 Agent 可靠性解决方案（医疗、法律、HR）可能会陆续出现。

5.3 对开发者和企业的实践建议

对于正在构建 Agent 的开发者：

如果你的 Agent 涉及金融交易、数据写入、外部 API 调用等不可逆操作，现在就应该开始按照分离架构设计，即使当前规模还不需要完整的多 Agent 基础设施。关键是在代码层面保持推理逻辑和执行逻辑的清晰分离，这会大大降低未来迁移到托管架构的成本。

对于正在评估 Agent 平台的企业 IT 决策者：

在评估 Agent 平台时，可观测性和权限隔离应该是与模型性能同等重要的评估维度。要求供应商提供具体的「如何诊断 Agent 失败」的演示，而不只是「Agent 能完成什么任务」的演示。同时关注平台是否提供集中化的 Agent 治理能力（如 AWS AgentCore Agent Registry 所提供的功能）。

对于关注这个领域的投资者：

Agent 可靠性和治理工具是一个值得关注的新兴市场类别。Nava 的融资时间点表明市场已经开始为这个需求付费。关注那些在特定垂直行业（金融、医疗、法律）构建 Agent 护栏和合规验证工具的初创公司。

结论：架构是命运

Claude 性能退化引发的用户反弹、Nava 的830万美元融资、AWS AgentCore Agent Registry 的发布、Claude Mythos 的出现——这些看似分散的事件，在「脑-手分离」这个架构框架下获得了统一的解释。

企业 Agent 在生产环境中的可靠性问题，不是一个可以用更好的 prompt 或更聪明的模型解决的问题。它是一个架构问题：当决策层和执行层耦合在一起，错误传播无法被截断，可观测性无法被系统化，权限隔离无法被实施，可靠性就永远是一个依赖运气的属性，而不是一个可工程化的保证。

Anthropic 通过多 Agent 托管架构尝试的，是将可靠性从一个「希望如此」的期望，变成一个「设计如此」的保证。这个转变的成功与否，将在很大程度上决定 Anthropic 能否在企业 AI 基础设施市场占据核心位置，而不只是作为一个「聪明的模型」供应商在日益商品化的 API 市场中竞争。

但我们也必须保持清醒：分离架构不是银弹。它在高风险、高复杂度的企业场景中是必要条件，但对于大量的中低风险 Agent 用例，耦合架构仍然是更务实的选择。真正的赢家不是那些押注单一架构范式的公司，而是那些能够根据场景风险特征灵活提供不同架构选项的平台。

架构选择，在技术领域从来都不只是技术选择。它是关于谁控制价值链的哪个环节、谁的切换成本最高、谁最终能够收取基础设施溢价的商业命运选择。Anthropic 正在用多 Agent 分离架构押注：可靠性基础设施，将是下一个 AI 商业竞争的主战场。

参考资料

  1. Claude is getting worse, according to Claude — The Register, 2026-04-13

  2. Anthropic is facing a wave of user backlash over Claude performance issues — Fortune, 2026-04-14

  3. Nava raises $8.3 million in seed funding to keep AI financial agents from going off the rails — Fortune, 2026-04-14

  4. AWS Agent Registry for centralized agent discovery and governance is now available in Preview — AWS, 2026-04

  5. Anthropic co-founder confirms the company briefed the Trump administration on Mythos — TechCrunch, 2026-04-14

  6. Amazon Bedrock now offers Claude Mythos Preview — AWS, 2026-04

  7. Project Glasswing: Securing critical software for the AI era — Anthropic, 2026-04

  8. Automated Alignment Researchers: Using large language models for alignment research — Anthropic Research, 2026-04

  9. Agentic Payments In B2C Commerce: Where We Are Now — Forrester, 2026-04

  10. Multi-agent systems — Anthropic Documentation — Anthropic Docs

  11. Gartner Hype Cycle for Artificial Intelligence, 2025 — 来源: Gartner, 2025

  12. Deloitte State of AI in the Enterprise Survey, 2025 — 来源: Deloitte, 2025

  13. OpenAI Agents SDK — OpenAI, 2025