用 Bedrock 和 Lambda 自动部署应用

许多企业都有大量始终未能开发的内部工具。某个团队可能需要一个运费计算器、一份简单的受理表单，或一个基于电子表格的小型仪表板，但每一个工具都需要开发人员、一个待办事项排期，以及一套部署流水线。这些工具太小，不足以获得优先处理；数量又太多，无法忽视。

PDI Technologies 服务于便利零售和石油批发行业，通过安全连接企业的数据与运营，帮助全球各地的企业提升效率和盈利能力。PDI 拥有 40 年的行业经验，员工约 4,000 人，服务覆盖 200 多个国家和地区的 20 多万个客户地点。PDI 意识到，传统部署流水线正在阻碍非技术团队交付他们所需的工具。

为弥合这一差距，PDI Technologies 构建了 PDI Brew。非技术员工只需用自然语言描述自己想要的工具，几秒钟内就能获得一个配置完备、支持多租户、受单点登录（SSO）保护并运行在 AWS 上的 Web 应用程序。无需 Git、终端或 DevOps 知识。需要工具的人，就是交付工具的人。由于每个应用都继承同一个平台，因此都可以按需启用受治理的 AI 能力（聊天、摘要和分类），这些能力由 Amazon Bedrock 提供支持。在此过程中，应用创建者完全不需要接触模型端点或 API 密钥。

在本文中，我们将介绍 PDI Technologies 如何围绕一种智能体式配置模式构建 PDI Brew。规划智能体使用 AI 助手（例如 Claude、ChatGPT 或 Claude Code）中的技能，将用户意图捕获为结构化清单；也可以在 AWS 信任边界内通过调用 Amazon Bedrock 模型来完成这一过程。随后，运行在 AWS Lambda 上的配置智能体会分解该清单、对工作负载进行分类、选择工具，并在一次请求中编排所有下游 AWS 资源的创建。接下来，我们还会展示同一平台如何将应用内 AI 作为一个受治理、遵循最小权限原则的 Amazon Bedrock 网关对外提供。我们将介绍系统架构、安全模型、Lambda 中的长时间运行配置步骤、AI 护栏与预算设计，以及该系统大规模运行时的成本构成。

为了理解这一架构，熟悉以下 AWS 服务会很有帮助：AWS Lambda、Amazon API Gateway、Amazon DynamoDB、Amazon Simple Storage Service（Amazon S3）、Amazon CloudFront 和 Amazon Bedrock。如果了解 Microsoft Entra ID（原 Azure AD）和 MSAL.js，也将有助于理解身份验证相关章节。如果你计划在自己的环境中实现类似模式，请确认已安装并配置 AWS Command Line Interface（AWS CLI），并且所使用的凭证拥有创建 AWS Identity and Access Management（IAM）角色和策略所需的足够权限。

内部工具面临的挑战

传统的内部工具交付方式，会将一个简单的业务需求与完整的软件交付生命周期绑定在一起。即使只是一个单页面计算器，也要承担代码仓库、构建流水线、身份验证集成、托管方案、TLS 证书、DNS、日志记录和持续维护等成本。最终，大量小型工具会永久积压在队列中，优先级始终低于能够创造收入的功能。

我们希望构建一个具备以下四项特性的系统：

意图输入，应用输出。需求方描述所需工具，平台负责配置并部署，无需移交给工程团队。

默认安全且受治理。每个应用都会继承企业 SSO、限定范围的 IAM 权限、HTTPS 和集中式可观测性，不存在“不安全”的路径。

无服务器且可缩容至零。数百个小型应用在空闲时的成本必须接近于零，并且不需要修补共享服务器，也不需要规划容量。

AI 并非毫无限制。应用可以使用生成式 AI，但只能通过带有护栏、配额和完整审计记录的受控路径访问，绝不能嵌入自己的模型密钥。

“智能体式”并不意味着“每个决策都必须在请求路径中调用大语言模型”。我们将智能体定义为一种能够接收目标、分解目标、选择工具并采取行动以实现目标的系统。PDI Brew 将该定义的两部分拆分为两个信任特征截然不同的智能体。

规划智能体负责捕获意图。它与用户对话，帮助用户完善需求，生成应用前端，并且最关键的是输出结构化部署清单：一份描述用户意图的 JSON，其中包括应用名称、类型、数据模式和访问控制设置。规划逻辑被封装为 Vibe App Builder 技能，可在员工已经使用的任意 AI 助手中运行。让规划器运行在助手内，可以让用户在自己已经打开的工具中获得丰富的对话体验，同时缩小 AWS 侧的暴露面。

配置智能体是一个 AWS Lambda 函数。它接收清单，并作为一个确定性、可审计、能够使用工具的编排器执行操作。它会验证请求、对工作负载进行分类，并选择相应的配置路径。随后，它将 AWS 和 Microsoft Graph API 作为工具进行调用，通过异步自调用处理长时间运行的步骤，最终返回一个可访问的 URL。我们有意将配置逻辑放在 Lambda 中，而不是放在聊天会话中：配置工作负载正是那种每个决策都必须有日志记录、可复现且不能出现幻觉的场景。

可插拔的规划器：自带 AI 助手

意图可以来自任何地方，因此规划器被设计成一个可插拔层，提供两条可互换的路径。通过单个环境变量 PLANNER_MODE 即可选择启用哪一条路径，而且两条路径都会输出完全相同的部署清单，因此所有下游流程都无需改变。

路径 A——任意 AI 助手中的 Vibe Skill。Vibe App Builder 技能（下文简称 Vibe Skill）封装了规划逻辑，可在员工已经使用的任意 AI 助手中运行。助手与用户对话、生成前端并生成清单。规划器运行在 AWS 之外，因此用户可以在自己已经打开的工具中获得丰富的对话体验。

路径 B——AWS 信任边界内的 Amazon Bedrock。对于 Teams、Web 表单或 IDE 等渠道，请求会被发送到 Amazon Bedrock。一次 Bedrock 模型调用（InvokeModel）充当规划器：它对工作负载进行分类，输出相同的清单，并可以在资源配置前验证或修复数据模式。该路径完全在 AWS 内部运行，因此每个决策都会记录在 AWS CloudTrail 中，并与模型调用 ID 关联，同时不会有任何意图数据离开 AWS 边界。这对于具有严格数据驻留要求的团队非常重要。

一份契约，一个配置智能体。由于两个规划器都会输出相同的清单 JSON，因此无论采用哪条路径，Lambda 上的配置智能体和整套应用级运行时都完全相同。增加 Bedrock 路径只是一次增量变更，而不是重写。此外，PLANNER_MODE 可以按组织、工作区或用户固定设置，因此一家企业可以强制使用 Bedrock 路径，而另一家企业则可以保留 AI 助手内的使用体验。这也为后续演进留下了一条清晰的路径：未来可以将 Bedrock 调用替换为功能更丰富的托管式智能体运行时，而无需改动路径 A 或配置智能体。

下图展示了端到端架构。整个架构分为三层：可插拔的意图与规划层、统一的智能体式配置运行时，以及每个应用独立的运行时；同时由共享的边缘服务、身份服务和可观测性服务提供支持。

下面的演练将跟踪一个请求如何依次经过各个层：

在意图与规划层，员工使用自然语言描述所需工具。根据 PLANNER_MODE，规划器可以是运行在其 AI 助手中的 Vibe Skill（路径 A），也可以是位于 Slack 或 Teams 等渠道背后的 Amazon Bedrock 调用（路径 B）。无论采用哪种方式，规划器都会以 JSON 格式输出相同的部署清单。

该清单通过 HTTPS 发送到 Amazon API Gateway 上的 POST /deploy，并使用 Entra ID 持有者令牌（MSAL.js）进行身份验证。由于两条规划器路径最终汇聚到同一个端点，并遵循同一份契约，因此从这里开始的所有流程都完全相同。

API Gateway 调用 Deploy Lambda（配置智能体）。它会验证 Entra JWT（租户和过期时间），强制要求请求中包含访问控制模式，并以原子方式检查应用注册表中的 slug 所有权。

智能体对工作负载进行分类，包括静态应用（计算器或图表）和全栈应用（需要数据持久化），然后选择匹配的配置路径。

对于静态应用，智能体会将 HTML 包装在 Entra 身份验证外壳中，上传到 Amazon S3，使 Amazon CloudFront 缓存失效，并在 Amazon DynamoDB 中注册该应用。

对于全栈应用，该智能体还会为每个应用预置一张独立的 DynamoDB 表、一个具有受限 AWS IAM 角色的独立 AWS Lambda 函数，以及一个独立的 API Gateway。然后，它会将新的 API URL 注入前端，再进行打包和上传。

耗时较长的步骤（例如创建 Microsoft 365 组）通过异步自调用来处理：智能体将自身的第二个副本作为后台任务调用，使用户的请求能够快速返回。

最终用户通过 CloudFront 使用 HTTPS 访问上线后的应用，其中 CloudFront Function 会将 <slug>.domain 路由到 S3 中对应的应用。每个应用都受到 Entra 单点登录保护，并且可以在 Amazon CloudWatch 中进行观测。

预置智能体的工作原理

预置智能体执行两项核心功能：对工作负载进行分类，以及编排耗时较长的预置步骤。

工具选择与工作负载分类

Deploy Lambda 将 AWS SDK for JavaScript v3 和 Microsoft Graph API 作为自己的工具集。它根据清单决定调用哪些工具以及调用顺序。静态应用只会涉及 S3、CloudFront 和 DynamoDB 注册表。全栈应用还会使用 DynamoDB 和 API Gateway；对于声明了特定能力的应用，还会使用 Lambda 和 IAM。访问控制则会调用 Microsoft Graph，以创建和管理应用的 M365 组。分类过程是确定性的，并且会完整记录日志：相同的清单始终会生成相同的计划。

Lambda 内的长时间运行任务

有些预置步骤所需的时间超出了用户愿意等待同步请求的时长，其中最典型的是创建 M365 组之后的目录传播。智能体不会一直保持请求处于打开状态，而是使用异步自调用：它以 Event 调用类型对自身执行 lambda:InvokeFunction，立即返回应用的在线 URL，并由后台副本完成这些缓慢的工作。这相当于无服务器环境中的智能体“后台任务”模式，并且能够从容地在 Lambda 执行时限内完成。

每应用运行时：双层计算模型

并非每个应用都需要独立的计算资源。大多数全栈应用只是对自身 DynamoDB 表执行简单的创建、读取、更新和删除（CRUD）操作，因此它们运行在平台统一管理的共享 CRUD Lambda 上。该 Lambda 前端使用带预置并发的加权别名。这样，多个应用可以共用一条保持预热并经过审计的代码路径，同时获得自动金丝雀回滚保护。

只有当应用清单声明了封闭允许列表中的某项能力时，例如发送电子邮件、调用特定的外部 HTTPS 域名，或从指定数据源读取数据，该应用才会升级为使用独立的每应用 Lambda，并配备专用且权限受限的 IAM 角色。这种升级需要经过管理员审批。审批过程以提交代码的静态分析以及最终 IAM 角色的漂移检测为依据。默认路径是共享且低成本的；特权路径则按应用隔离、遵循最小权限原则，并受到审批控制。

已部署的应用越来越需要 AI 功能：汇总记录、对录入表单进行分类，或者基于应用数据回答问题。最直接的做法是让每个应用都嵌入模型供应商的 SDK 和 API 密钥，但这会导致凭证四处分散、中央治理失效，并且无法控制支出。PDI Brew 采取了相反的方式：AI 是通过统一端点访问的平台能力，而不是由每个应用自行维护的一项集成。

每次调用模型前后，都会执行三项控制。首先，强制性的 Amazon Bedrock Guardrail 会在每次调用中处理个人身份信息（PII）脱敏、内容过滤和提示词注入防御。应用无法关闭这项功能。

其次，一个包含 12 个计数器的原子化预算机制会实施支出限制。在发起任何 Bedrock 调用之前，系统会通过单次 DynamoDB TransactWriteItems 在四个范围内预留支出额度，分别是全局、应用、用户和应用-用户；每个范围又包含三个时间窗口，分别是每日、每周和每月。如果十二个计数器中的任意一个超出限制，请求都会被立即中断，并返回 429 Too Many Requests，同时通过结构化响应体指出触发了哪项限制。这样，无论失控成本来自缺陷、循环还是滥用，它都会成为一个有界且可观测的事件，而不是一张意外账单。管理员可以为应用所有者授予更高的应用级预算，但所有者不能提高全局和每用户的上限。

第三，双层终止开关确保管理员的禁用操作始终优先于所有者的启用操作，同时还可以通过一个平台级全局标志禁用所有位置的 AI。因此，平台团队始终保有一个独立于任何应用的硬停止开关。

每次调用都会接受审计，包括 UPN、应用、模型、Token 数量、预估成本和护栏结果，因此从端到端来看，每一笔支出和每一次使用都可以归属到具体的应用和用户。

安全性与最小权限

由于该智能体负责预置基础设施，其安全模型是整个设计中最重要的部分。以下几项原则构成了该模型的基础。

IAM 层的纵深防御。预置智能体拥有创建资源所需的广泛权限，但它创建的每应用 Lambda 函数会继承一个独立且权限受限的角色，该角色只能访问名称以 pdi-brew-{env}-app- 为前缀的 DynamoDB 表。智能体绝不会向已部署应用授予超出其实际需求的权限，因此某个租户代码中的缺陷无法读取其他租户的数据。

每条路径都进行身份验证。已部署应用不存在未经身份验证即可访问的路由。部署 API 会在预置资源之前验证 Entra JWT，每个生成的应用也会被封装在 MSAL.js 身份验证外壳中，并在每次访问时通过 Microsoft Graph 检查 Microsoft 365 组成员资格。

关于身份提供商的说明：此架构使用 Microsoft Entra ID 和 MSAL.js 进行身份验证，而不是 Amazon Cognito。这是一项经过慎重考虑的设计选择，源于 PDI Technologies 现有的企业 SSO 要求。PDI 的员工已经通过 Microsoft Entra ID 进行身份验证。直接与其既有身份提供商集成，既减少了最终用户的操作阻力，也符合现有安全策略。对于没有既定身份提供商偏好的组织，Amazon Cognito 是一种替代方案，它可以与 AWS 服务原生集成，并支持类似的联合登录流程。

AI 在设计上遵循最小权限原则。AI Lambda 角色授予的 bedrock:InvokeModel 和 InvokeModelWithResponseStream 权限，会按资源限定到允许列表中的模型 ARN，而不是 *；账户内没有其他资源可以调用 Bedrock。其他 Lambda 函数不具备 Bedrock 权限，只能通过网关以 HTTPS 方式访问 AI，并在那里接受护栏和预算控制。

其他控制措施进一步加强了所有已部署应用的安全态势。Amazon S3 会完全阻止公共访问，只有 CloudFront 能够通过 Origin Access Control 读取对象。CloudFront 会强制重定向至 HTTPS，并实施 HSTS 和严格的 Content-Security-Policy。API Gateway 会对部署端点实施速率限制：持续每秒 50 个请求，突发上限为 100 个请求。Amazon S3 版本控制和 DynamoDB 时间点恢复可防止数据丢失，prevent-destroy 生命周期规则则会保护注册表和存储桶。

无服务器原生多租户

每个已部署应用都是一个租户。该架构为每个租户提供独立的子域名（由 CloudFront Function 路由）、适用情况下独立的 DynamoDB 表，以及仅能访问其自身数据的 Lambda 角色。租户之间不存在共享计算资源，也没有“吵闹邻居”风险；由于每个组件都是无服务器的，因此各租户在空闲时都可以独立缩容至零。部署第一百个应用时，增加的成本几乎为零，直到有人真正使用它。

预置智能体以及每个应用的 Lambda 函数都会将结构化 JSON 日志写入 Amazon CloudWatch。PDIBrew 命名空间中的自定义指标会跟踪部署、应用访问、身份验证失败、组和列表创建，以及预置延迟。管理面板使用 Amazon CloudWatch Logs Insights 查询每个应用的活动，Grafana 仪表板则展示整个平台的使用情况。预置调用会记录在 AWS CloudTrail 中；当 Bedrock 规划器（路径 B）启用时，每项规划决策也会以 InvokeModel 调用的形式记录在 CloudTrail 中，从而形成一条从用户意图到预置资源的端到端审计链路。

该技术栈中的每项服务都按使用量计费，没有固定成本，因此平台费用取决于实际使用情况，而不是已部署应用的数量。

在实践中，一个由 20 人组成、运行约 10 个应用的团队，每月成本大约为 5～15 美元。

自推出以来，PDI Brew 已扩展到为整个组织内的数百个应用提供服务，与传统的订阅制工具相比，节省了大量成本。尤其值得注意的是，部署工作不再局限于工程团队。如今，非开发人员也能独立创建和部署应用，并通过 Entra UPN 标签进行追踪，这表明 AI 驱动的工具已将应用创作能力扩展到传统开发团队之外。根据 PDI Technologies 的实践经验，以往需要数周才能完成的工作——包括反复流转工单、配置基础设施和执行构建流程——如今缩短到了几分钟，这一结果通过部署 Lambda 的时间戳进行衡量。其成本效益同样引人注目。该平台实现了显著的成本优化，应用在空闲状态下的单应用成本远低于传统订阅制工具。

在运营方面，该平台已经真正实现了自给自足。部署者可以通过 S3 版本控制托管机制，独立管理和回滚自己的应用，无须依赖其他团队进行持续维护。PDI 通过持续追踪 AppViews 来衡量应用的生命周期，从而区分能够长期使用的业务工具与一次性实验，并衡量其为组织带来的持久价值。

该平台还解锁了订阅制工具此前无法支持的使用场景。由于 PDI Brew 完全运行在 PDI 自有的云和身份边界内，因此能够承载受监管数据和敏感数据工作负载，满足数据不得离开组织边界的要求。AI 作为平台内置能力提供：Amazon Bedrock 中可用的 Amazon Nova 模型通过共享护栏和单应用 token 限额向应用开放，消除了通常会减缓企业 AI 应用进程的逐项目模型采购开销。

PDI Brew 表明，智能体式资源配置模式能够自然映射到 AWS 的无服务器基础组件上。一个可插拔的规划器（可以是任意助手中的 Vibe Skill，也可以是位于 AWS 信任边界内、面向 Slack 和 Teams 等渠道的 Amazon Bedrock）将自然语言意图转换为结构化清单。随后，运行在 AWS Lambda 上的资源配置 AI 智能体会将该清单转化为一个已完成全部资源配置、具备身份认证能力的多租户应用。该技术栈以 AWS Lambda、Amazon API Gateway、Amazon DynamoDB、Amazon S3 和 Amazon CloudFront 为构建模块，打造了一个产品化平台。使 Lambda 成为优秀 API 运行时的那些特性——无状态、可缩容至零、受 IAM 权限范围约束且具备可观测性——也使其成为资源配置 AI 智能体的优秀运行时，因为确定性和可审计性对于这类智能体至关重要。

许多积压了大量内部工具需求的组织都可以复用这些模式：通过单一的清单契约，将规划器与资源配置 AI 智能体解耦，使意图能够来自任意助手或渠道。确保资源配置过程具备确定性并遵循最小权限原则，同时利用无服务器架构处理多租户和缩容至零。若要开始在无服务器 AWS 上构建 AI 智能体，请参阅有关智能体式 AI 架构的 AWS Prescriptive Guidance、AWS Samples、Amazon Bedrock Developer Guide 以及 AWS AI/ML Blogs。