AWS Well-Architected Framework 遇上 Agent 非确定性：调用图假设失效后怎么办

AWS Well-Architected Framework 遇上 Agent 非确定性：调用图假设失效后怎么办

传统 Well-Architected Framework 依赖预先绘制完整调用图进行风险评估，而 Agentic AI 的执行路径无法在请求到达前确定，导致原有设计审查节奏失灵。这一根源性变化正迫使云架构实践重新思考观测性和控制手段。

过去十多年，AWS Well-Architected Framework（WAF）一直是云上系统设计审查的核心工具。它提供客观、可量化的检查清单，帮助架构师在可靠性、安全性、成本优化、性能效率、可持续性和运营卓越六个支柱下发现风险、填补空白。审查过程高度结构化：先画出明确的调用图（call graph），再逐层对照 WAF 最佳实践，明确哪些地方存在歧义、哪些可以接受风险。这种方法在微服务、分布式系统时代非常有效，因为服务间的调用关系在设计阶段就能基本确定。

但 Agentic AI 打破了这个前提。Agent 不是按固定流程执行的代码，它会根据上下文、工具输出、甚至中间推理结果动态决定下一步动作。同一输入可能触发完全不同的工具调用序列，执行路径在请求到达前无法完整绘制。这直接导致 WAF 审查中“先画调用图、再评估风险”的核心节奏失效。所有新增的歧义，几乎都源于这个根源假设的崩塌。

传统 WAF 如何依赖调用图完成风险闭环

WAF 的效力建立在“可预测执行路径”这一隐含前提上。在设计审查会议中，架构师首先需要提供完整的调用图：从入口 API 到各个微服务、数据库、缓存、外部依赖的完整链路。审查者对照 Reliability Pillar 中的“故障隔离”“自动恢复”等问题项，检查每个节点是否有单点、是否有重试机制、熔断器是否正确配置。

这种做法在过去十年被证明高效。Amazon 零售业务、AWS 内部系统以及大量客户落地项目，都通过反复迭代 WAF 审查把系统风险控制在可接受范围内。调用图让歧义变得可见：哪个服务调用超时会影响全局 SLO，哪个依赖的权限策略存在越权风险，都能被提前指出并整改。

可观测性工具也围绕调用图展开。AWS X-Ray、CloudWatch 等产品以 trace 为核心，把一次请求的完整调用链路可视化。开发者可以轻松定位延迟瓶颈、错误传播路径。监控告警规则也是基于已知的调用关系设定：某个 Lambda 调用 DynamoDB 失败率超过 1% 就触发警报。这种“已知路径 + 指标阈值”的模式，构成了过去云原生系统的稳定基石。

然而，当系统核心组件换成 Agent 后，调用图不再是静态的。Agent 可能调用工具 A 后根据结果决定是否调用工具 B，也可能直接进入人工介入流程，甚至自主生成新的子 Agent。一次请求的 trace 每次都不一样，传统的基于固定路径的审查和监控立刻失去抓手。

Agent 非确定性从根本上改变架构审查前提

Agentic AI 的核心特征是自主规划和工具使用。它不再是“输入→固定函数→输出”的映射，而是一个可以多次思考、多次调用外部工具、甚至修改自身计划的循环过程。这种特性直接冲击 WAF 的六个支柱。

在可靠性方面，传统“预测并预防所有失败模式”变得困难。因为你无法提前列出 Agent 所有可能的执行分支，故障模式也就无法穷尽。安全性审查同样面临挑战：Agent 可能自主决定调用哪些 API，权限边界难以静态定义。成本优化支柱也受影响——一次 Agent 调用可能触发几十次 LLM 推理和工具调用，费用波动远超传统微服务。

更关键的是，WAF 审查的节奏被打乱。过去审查会议可以围绕一张调用图展开讨论，现在架构师只能提供“可能的工具集合”和“决策逻辑描述”，却无法给出确定性的路径图。审查者只能依赖更模糊的描述判断风险，这让“客观评估、明确指导”的 WAF 优势大幅削弱。

国内云厂商的客户也已遇到类似问题。阿里云上的多个智能客服项目引入 Agent 后，发现原有 SLO 承诺难以维持，因为单次会话的 token 消耗和外部 API 调用次数波动极大。腾讯云的金融风控场景中，Agent 自主调用多个数据源的路径不可预测，导致审计日志难以完全覆盖所有合规路径。

可观测性工具必须从“路径追踪”转向“意图与轨迹记录”

传统可观测性三支柱（日志、指标、trace）高度依赖已知调用关系。当路径不可预测时，trace 仍然有价值，但其意义从“验证固定路径”转变为“记录实际发生的行为轨迹”。

AWS 已经在 X-Ray 中开始支持更灵活的 trace 分析，能把 LLM 调用和工具调用作为独立 span 记录。未来方向是增加“意图层”观测：不仅记录 Agent 调用了哪个工具，还需记录它当时的目标、使用的 prompt 模板、以及决策依据。这相当于给 Agent 的每一步打上语义标签，让事后审查成为可能。

阿里云的链路追踪服务已开始集成对 Agent 框架的适配，能把 LangChain 或 AutoGen 的调用步骤展开为可视化流程。腾讯云的观测平台也在试点“Agent 行为日志”功能，把 Agent 的思考过程（thought）、行动（action）、观察（observation）三元组结构化存储，方便后续审计和调试。

但这些工具目前仍处于早期阶段。多数企业仍面临“看得见调用、看不懂意图”的困境。如何在不显著增加成本的前提下，完整记录 Agent 的决策链，仍是开放问题。

国内云厂商落地场景下的适应性调整方向

面对 Agent 非确定性，国内企业不能简单套用海外 WAF 模板，而需结合自身监管要求和业务特点进行本地化改造。

阿里云客户在电商推荐场景中，建议采用“混合 Agent 架构”：核心推荐逻辑仍使用确定性模型，只把需要实时调整的部分交给 Agent。这样调用图的大部分仍然可预测，WAF 审查仍能覆盖 70% 以上的路径。对无法预测的部分，则通过强化事中和事后观测来弥补：每一次 Agent 决策都必须落地完整日志，并与业务指标关联，实现“决策-结果”闭环追踪。

腾讯云金融客户则更关注合规。建议在 Agent 框架中嵌入“策略守卫”（guardrail），明确禁止 Agent 调用某些高风险工具，同时要求所有工具调用必须经过权限检查点。这些检查点成为新的固定路径，可继续使用传统 WAF 审查方法。对 Agent 自主部分，则建立单独的“Agent 支柱”审查清单，重点检查提示词工程质量、工具集合边界、回退机制是否完备。

华为云的部分政企客户走得更远。他们把 WAF 与企业内部控制框架结合，针对 Agent 系统额外增加“可解释性审查”和“人工介入比例”两项指标。如果一次业务流程中 Agent 自主决策比例超过 30%，则必须提供可解释报告，否则不予通过架构评审。这种做法把不可预测性控制在可接受范围内，同时保留了 WAF 原有的结构化优势。

新的架构范式：从静态审查转向动态治理

WAF 不会消失，但它的使用方式必须进化。未来审查可能分成两部分：对确定性组件继续使用经典调用图审查，对 Agent 组件则聚焦“治理边界”和“可观测能力”。

治理边界包括工具权限集、最大调用次数、必须遵守的安全策略等。这些边界本身是确定的，可以用 WAF 风格的问题项进行检查。可观测能力则需要新的技术栈：除了传统 trace，还需要语义日志、决策重放、异常模式自动聚类等能力。

AWS 自身也在内部试点这类混合审查方法。部分团队把 Agent 项目单独建立“Agent Well-Architected”检查清单，与经典 WAF 并行使用。国内云厂商同样可以借鉴这一思路，结合等保 2.0、数据安全法等本地合规要求，定制出适合中国企业的 Agent 架构审查框架。

这一转变并不轻松。它要求架构师同时掌握传统云架构和现代 AI 工程技能，也要求观测平台厂商加快产品迭代。但这是无法回避的方向——Agent 正在快速进入生产系统，如果继续用老方法审查，必然出现大量漏网风险或过度保守的设计。

企业当前可立即采取的四项具体行动

第一，梳理现有系统中的 Agent 使用范围，明确哪些组件已引入非确定性行为，为它们建立单独的观测流水线。

第二，升级日志方案，要求所有 Agent 框架必须输出结构化的 thought-action-observation 三元组，并与业务上下文关联存储。阿里云 SLS 和腾讯云 CLS 都已支持这类半结构化日志的高效查询。

第三，在架构审查会议中增加“执行路径不确定性评估”环节，强制架构师说明 Agent 可能的最坏调用次数、最高成本，以及对应的熔断和人工介入机制。

第四，与云厂商合作，试点新的可观测性功能。目前阿里云和腾讯云都愿意为重点客户提供 Agent 观测能力的早期访问资格，企业应主动争取，把自身需求反馈到产品路线图中。

这些行动无法完全恢复传统 WAF 的确定性，但能把风险控制在可管理范围内。Agent 带来的灵活性值得拥抱，前提是建立与之匹配的治理和观测能力。

云架构的最佳实践从来不是一成不变的。从单体到微服务，从虚拟机到容器，再到今天的 Agentic 系统，每次范式转移都要求我们更新工具箱。WAF 仍然是强大武器，只是它的瞄准镜需要重新校准，对准那些虽然不可预测、但仍可被观察、被约束、被持续改进的 Agent 行为。

（正文字数约 2150 字）

参考来源