亚马逊AWS官方博客

从应用到 Agent：开发范式正在发生什么变化？

摘要：AI Agent 正在将软件从执行预定义逻辑的应用，转变为基于目标进行动态决策与行动的系统。这一变化为开发者带来更强能力的同时，也引入了新的工程挑战。 本文从开发者视角出发，解析 Agent 与传统应用在执行模型与系统结构上的差异，并结合云原生实践，探讨在生产环境中构建可扩展、可控的 Agent 系统时需要关注的关键问题，包括隔离、状态管理与成本控制。

一、引言

在过去几十年里，软件工程经历了多次架构演进：从单体到微服务，从同步调用到事件驱动。但有一件事始终没有改变：系统的执行路径由开发者定义，由软件负责执行。随着以 OpenClaw 为代表的 AI Agent 系统出现，这一前提正在发生变化：软件不再只是执行逻辑，而开始参与“如何执行”的决策。

二、从函数执行到 Agent Loop：控制权的转移

传统应用的核心是一条清晰的执行路径。用户输入触发函数调用，系统按照预先设计的逻辑返回结果。即使在复杂系统中，这种路径也仍然由代码显式定义。

Agent 系统则不同。它围绕一个持续运行的决策循环展开：理解目标、进行推理、调用工具、观察结果，并基于新的上下文继续决策。这种循环使得系统不再依赖固定流程，而是根据环境动态选择下一步行动。

[图1]

这意味着一个关键变化：控制流从“代码驱动”转向“模型驱动”。

三、Agent 的本质是一个系统

从架构角度来看，Agent 不应被理解为一个模型能力的延伸，而更像一个由多个层次构成的系统。

[图2]

模型负责推理与生成能力，工具层负责连接外部世界，例如数据库、API 或文件系统，而真正驱动系统行为的，是位于其上的编排能力。编排层决定系统在每一个时刻应该采取什么行动，并在不确定环境中不断调整路径。与此同时，状态与记忆为整个系统提供上下文，使得行为能够在多轮执行中保持连续。

这种结构带来的变化在于，问题的核心不再是模型能力是否足够，而是系统是否具备可控性。一旦 Agent 能够调用工具、执行代码并访问数据，它就已经成为一个真正的“执行主体”，而不仅仅是一个生成文本的组件。

3.1 从单 Agent 到多 Agent：复杂性的自然演进

在简单场景中，一个 Agent 已经可以完成任务。但当问题进入真实业务环境，复杂性很快出现。

例如一个看似简单的问题：“ROI 下降，是用户行为问题还是产品问题？”。在实际系统中，这往往意味着需要同时理解数据湖中的行为数据、数据仓库中的业务指标，以及文档中的业务定义。单一 Agent 很难在一个上下文中同时处理这些信息。

当任务复杂度提升时，系统会自然演进为多个 Agent 的协作结构。不同 Agent 负责不同领域的能力，通过分工降低单点推理的不确定性。在这种模式下，系统更像一个团队，而不是一个程序。任务被拆解、分发，再由不同角色完成并最终汇总。系统能力来自结构，而不是单一模型的增强。

[图3]

当然，这种结构也带来了新的问题。调度复杂性、通信开销以及状态一致性都成为必须面对的工程挑战。因此，多 Agent 系统的关键并不在于增加数量，而在于设计清晰的职责边界、上下文边界以及失败处理机制。

3.2 数据 Agent：理解能力才是核心瓶颈

当 Agent 进入数据场景时，问题进一步放大。

现实中的数据系统高度异构。用户行为数据可能存储在数据湖中，业务指标存在于数据仓库，而业务规则散落在文档或知识库中。用户的问题通常是跨域的，但系统中的数据却是分散的。

在这种情况下，真正的瓶颈不再是查询能力，而是语义理解能力。系统需要知道用户所说的“ROI”对应哪个字段，“region”来自哪张表，以及这些数据之间如何关联。

从Agent架构角度看，这类问题本质上是用户意图、工具调用以及外部数据结构时间的编排问题。在工程实践中，这通常通过引入语义层（Semantic Layer）来解决。系统先通过语义匹配找到候选数据对象，再通过结构关系推理出正确的关联路径。

[图4：Data Agent 需要通过 Semantic Layer 连接业务语言与数据结构]

在这一过程中，Agent 不再只是生成 SQL，而是在构建对数据系统的理解。

3.3 Memory：从上下文到长期能力

Memory 是 Agent 系统中另一个关键但常被低估的部分。

在简单实现中，Memory 只是对话上下文的拼接，但在生产环境中，这远远不够。系统需要能够从对话中提取信息，判断哪些是长期有效的知识，哪些只是临时上下文，并对这些信息进行分类、存储、召回以及更新。

Memory 是 Agent 从“短期推理”走向“长期能力”的关键。当系统能够记住用户的偏好、业务规则以及历史成功路径时，其行为将逐渐稳定并具备连续性。

这也意味着，Memory 本质上从“上下文缓存”演变为“可治理的知识系统”。

四、从 Demo 到生产：真正的挑战才开始

在 Demo 阶段，Agent 系统往往已经能够完成令人印象深刻的任务。而一旦进入生产环境，问题会迅速暴露出来。

系统不再只是生成内容，而是开始执行真实操作，例如调用 API、访问数据，甚至修改外部系统状态。风险模型也随之改变。问题不再是“生成是否正确”，而是“系统是否可控”。

这一转变，使得基础设施和系统设计成为决定成败的关键。

在生产环境中，一个重要的设计原则是以 session 作为系统边界。每个用户或每个任务 session 都对应一个独立的执行环境，拥有自己的上下文、权限和运行状态。

在亚马逊云科技提供的云上，这种隔离可以通过轻量级虚拟化实现。例如基于 Firecracker 的 microVM 能够为每个 session 提供更强的虚拟化隔离边界，使每个session拥有独立的运行环境与文件系统视图，并在任务结束后快速销毁，从而降低多租户之间的相互影响。

[图5]

这种按需创建和销毁执行环境的方式，使得系统既具备强隔离能力，又能够实现弹性扩展。

一个典型的云上架构

[图6]

在实际部署中，一个生产级 Agent 系统通常会由多个云上服务组合而成，例如使用亚马逊科技提供的服务:Amazon Bedrock，Amazon S3等。

用户请求通常通过 Amazon API Gateway 接入系统，由 Amazon Lambda 作为轻量控制层，用于请求鉴权、session解析以及路由决策。实际的Agent执行运行在独立的运行时环境中，例如基于容器的平台（如Amazon EKS）或者虚拟机环（如Amazon EC2），以支持长时间任务与更强隔离。

Agent 的执行运行在隔离环境中，并通过 Amazon Bedrock 调用模型能力。在执行过程中产生的状态可以按类型拆分存储：

  • 长期文件与 workspace 数据通常存储在 Amazon S3
  • 会话状态与路由信息由 Amazon DynamoDB 管理
  • 需要语义检索或分析的 Memory、日志与 Trace 则进入 Amazon OpenSearch Service

这种模式与云原生的按需扩展理念一致，使 Agent 系统能够在负载波动和复杂任务场景下保持稳定与高效。

4.1 在无状态与有状态之间找到平衡

云原生系统强调无状态设计，而 Agent 系统天然依赖状态。这一矛盾的解决方式，是将计算与状态解耦。

执行环境保持无状态，以支持弹性扩展，而上下文、记忆以及业务状态被持久化存储。在需要时恢复状态，使系统行为在多次执行之间保持连续。

这种模式让 Agent 系统既具备云原生的弹性，又能够维持长期记忆能力。

4.2 成本与安全：系统设计的核心约束

在 Agent 系统中，成本结构与传统应用有所不同。模型调用（尤其是 token 消耗）往往成为主要的成本来源，因此系统通常需要通过多模型策略、调用剪裁以及缓存机制来优化整体成本结构。

安全问题同样需要通过系统设计来解决。身份认证、最小权限控制、运行时隔离以及存储隔离共同构成多层防护体系。一个重要原则是限制 Agent 能够执行的操作范围，而不是依赖模型本身的行为约束。

五、结论：构建“会行动的系统”

从应用走向 Agent，变化的不只是交互方式，而是系统设计的基本逻辑。

软件不再只是功能集合，而是围绕目标持续做出决策并执行行动的系统。系统能力不再来自单点逻辑，而来自结构化协作与清晰的边界设计。开发者的角色，也从实现功能转变为设计系统。

在这一过程中，云提供的不仅是计算资源，而是一整套支撑 Agent 系统的工程能力。从模型推理到执行隔离，从状态管理到调度与治理，这些能力共同构成了生产级 Agent 系统的基础。

我们不再只是构建软件，而是在构建可以行动的系统。

➡️ 下一步行动：

相关产品：

相关文章：

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

郑予彬

亚马逊云科技资深开发者布道师，专注于云原生、云安全技术研究和布道。20 年 ICT 行业和数字化转型实践积累，18 年的架构师经验，为金融、教育、制造以及世界 500 强企业客户提供数据中心建设，软件定义数据中心等解决方案的咨询及技术落地。

AWS 架构师中心：云端创新的引领者

探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用