用七层可组合架构推进企业智能体落地

Agent 能回答问题，不代表它能扛住生产流量。AWS 这篇文章讨论的，就是从演示到上线之间缺失的工程基础：权限怎么管、工具怎么分、错误怎么查、质量怎么持续验证。

作者给出一套基于 Amazon Bedrock AgentCore 的七层参考架构，核心主张是先划清职责、稳定接口，再选择具体产品。它值得程序员读的地方，是把 Agent 上线需要补的工程工作列得比较完整；但文中没有并发、成本或准确率的对照数据，不能把架构建议当成效果承诺。

七层架构解决的是重复造轮子

原型通常只需证明模型能完成任务。真正上线后，团队还要面对数千个并发请求、费用压力、安全审查，以及模型在真实输入下的表现波动。作者认为，项目卡在这里，往往不只是模型能力的问题，而是每个团队都在重新搭路由、权限、监控和评估。

这套框架把职责拆成七层：数据与知识、模型与推理、编排、安全与护栏、应用、可观测性，以及 Agent 运维。七层是职责划分，不必理解成请求依次穿过的七个服务。

数据层负责接收查询，返回相关上下文，覆盖检索、嵌入和结构化、非结构化数据访问。参考组件包括 Amazon Bedrock Knowledge Base、Vector Engine for Amazon OpenSearch Serverless、Amazon S3 Vectors 和 Amazon DynamoDB。

推理层则把模型选择从业务代码中移出去。简单任务可以用更小、更快的模型，复杂推理再选择能力更强的模型，但选择依据应该是有代表性的业务数据评估。LiteLLM 这类代理提供统一的请求和响应接口，让更换模型时少改应用逻辑。

这里真正需要稳定的是接口约定。例如，调用方需要知道数据层会返回什么、权限检查在哪发生、一次请求怎样关联到追踪记录。底下用什么产品，可以逐步替换。

可插拔的前提是接口稳定，不是组件数量足够多。

作者强调，这些 AWS 服务属于参考实现的选择，并非七层架构的强制依赖。团队可以沿用已有的推理、安全和监控设施。不过，文章没有展开接口字段、错误语义和兼容策略，距离可直接复用的接口规范还有一段距离。

多 Agent 的价值，是把工具和权限一起收窄

作者没有主张所有任务都上多 Agent。简单任务交给单个 Agent 从头完成；复杂、跨领域的工作，再由主管 Agent 分派给专门的 Agent。

原因不难理解：一个 Agent 同时背着大量工具、指令和上下文，会增加上下文负担与延迟，还可能选错工具、越过原定职责。拆分以后，每个专门 Agent 的能力、工具范围、测试和扩容都能单独处理。

零售客服参考实现把这个思路落到了退款场景。主管 Agent 收到请求后，调用 Order agent 和 Refund agent。前者从 Amazon DynamoDB 查询购买、配送信息；后者从知识库检索按会员等级划分的退款政策，再结合送达日期、当前日期和会员等级计算资格。

但职责拆开还不够。主管 Agent 不应硬编码所有下属，作者建议通过集中式 Agent 注册表记录工具、技能和负责人，再使用 MCP（Model Context Protocol）和 A2A（Agent to Agent）等标准协议发现、调用。

参考选型包括用 Strands Agents 构建专门 Agent，用 Amazon Bedrock AgentCore harness 承担编排，配合 AWS Agent Registry 和 Amazon Bedrock AgentCore Gateway 完成集中发现与路由。

安全边界也要跟着拆。每个 Agent 只能调用获准工具，权限不能靠提示词约束。零售案例里的调用都经过 AgentCore Gateway，在工具执行前由 Policy in AgentCore 做细粒度访问控制。

此外，作者要求默认不信任外部内容，对用户、其他 Agent 和自动化流程发来的请求都做认证；使用临时、限定范围的凭证，避免长期密钥；对请求与响应中的 PHI（个人健康信息）和 PII（个人身份信息）进行脱敏。

Amazon Bedrock Guardrails、Amazon Bedrock AgentCore Identity，以及 AWS 的安全与治理控制承担不同防线。重大决策还应留下可发现篡改的审计记录，高影响操作经过人工审批，异常行为由熔断机制中止。

这部分最实用的提醒是：Agent 能提出一个工具调用，不等于它有权执行。

上线后的重点，是持续知道它有没有做对

应用层被要求保持轻薄，主要负责展示会话、把请求交给编排层，同时设计好供其他 AI Agent 使用的外部接口。对前端团队来说，这有助于独立调整交互，不必把退款政策、工具调度等业务规则塞进聊天组件。

作者还提出在应用入口放一个决策模型：用一次调用判断请求是否在服务范围内、是否需要人工、是否紧急，返回概率，再由代码按阈值处理。只有确实需要时，才启动完整的 Agent 流程。

这是一条值得评估的成本控制思路，但文章没有给出概率校准方法、阈值或误判数据。尤其是人工升级和紧急请求，不能只因模型返回了一个分数就认为判断可靠。

进入后端以后，仅有日志和接口成功率也不够。一次调用没有报错，仍可能查错订单、套错政策。作者要求从第一天就建立端到端追踪，同时记录每次请求的费用、token 用量、首 token 时间、安全情况，以及延迟、错误率和支出。

参考工具是 Amazon CloudWatch、OpenTelemetry 和 Amazon CloudWatch Omni。零售案例希望通过这些记录定位错误发生在哪一层、哪个决策点，而不是只看到最终答案不对。

运维层再把观测接到持续评估上：为每个生产会话评估依据充分性、准确性和安全性，并建立回归门禁，阻止质量下降的版本发布。参考选型包括 Amazon Bedrock AgentCore Evaluations 和 Amazon Bedrock AgentCore optimization。

上线时通过测试，只能证明当时的版本通过了测试。

模型、工具和知识库都可能变化，评估也必须跟着运行。不过，文章没有说明逐会话评分的成本、时效，以及评分结果如何校验，这些仍需团队自己设计。

我的判断

这套架构最有价值的地方，是把权限、观测和持续评估列为起步条件。相比先做一个大 Agent、上线后再补控制，它更容易明确问题由谁负责，也更适合多个业务团队共用基础设施。

但「七层」不是七套平台的采购清单。对于工具少、流程固定的应用，单 Agent 加明确的程序流程，可能已经足够。注册表、主管调度和多个专门 Agent 会引入更多调用、状态传递与排障工作，文章没有证明这种复杂度在什么规模下开始划算。

退款案例也留下一个问题：原文说 Refund agent 负责计算资格，却没说日期和规则判断究竟由模型推理，还是由确定性代码执行。如果规则可以明确编码，我更倾向于让工具完成计算，让模型负责理解请求和解释结果；这是站内建议，不是作者展示过的对照结论。

可插拔同样有边界。统一调用入口可以减少改动，但不同模型的工具调用行为、错误形式和输出表现仍可能不同。换供应商之后，需要重新评估，不能因为接口兼容就省掉验证。

因此，我会把它视为一份覆盖较完整的生产设计参考。原文提供了可运行的零售实现，却没有给出吞吐、延迟、成本或质量收益数据；关于拆分后更可控、更易维护的判断，仍主要是工程经验。作者也明确说，示例不能替代生产安全加固、测试和审查。

能拿来做什么

• 如果你在做前端聊天入口，把界面状态和展示逻辑留在应用层，把政策判断、工具授权和业务流程放到后端。入口分类模型可以试，但先用真实请求检查误分情况，再决定阈值。
• 如果你用 Node 搭建 Agent 服务，先为检索、模型调用和工具执行约定输入、输出与错误格式，并统一传递追踪标识。这样替换某个组件时，才有条件控制改动范围。
• 如果业务涉及退款或其他高影响操作，在工具执行前落实身份认证、细粒度授权和必要的人工审批，并检查日志、记忆中是否残留敏感信息。
• 每次更换模型、提示词、工具或知识库，都重跑代表性业务样本，同时比较答案质量、费用和延迟。再用生产追踪中的失败会话补充回归集，让后续发布有可核验的依据。