亚马逊AWS官方博客

从本地到数千门店：FastAgent 与 Amazon Bedrock AgentCore 的企业级 Agent 实践

摘要：本地 Agent 已经能够承载指令、技能和工具。进入企业生产环境后，团队还需要解决云端运行、渠道接入、会话状态、任务调度、身份权限和可观测性。在 Amazon Bedrock AgentCore 团队的技术指导、架构建议和兼容性支持下，FastAgent 完成了面向 AgentCore Runtime 的部署集成，并验证了 Slack、飞书、定时任务、状态恢复和运行日志等关键路径。本文介绍这次项目的场景、架构、实施过程和阶段成果。

一、从本地运行走向企业服务

Coding Agent 正在显著降低 Agent 的开发门槛。开发者可以通过普通目录管理 Persona、Agent Skills、TypeScript Tools 和项目上下文，并在本地快速完成业务验证。

企业服务对运行环境提出了更完整的要求。Agent 需要响应 API 和业务事件，进入 Slack、飞书等员工日常入口，按照计划自动执行任务，并在版本更新后延续会话和渠道状态。身份权限、运行隔离、日志和资源治理也需要进入统一架构。

A 集团的前线 Agent 场景体现了这种需求。该集团拥有约 4,000 家门店，希望为每家门店配置专属店长 Agent。总部策略、门店数据、历史经验和现场反馈需要持续汇集，每个门店又要保留独立的身份、权限、记忆和任务上下文。这个场景推动我们寻找一条具备企业级承载能力的云端路径。

为什么迁移到 AgentCore Runtime

在评估自建方案（自行搭建并维护容器编排、扩缩容和多租户隔离）与托管 Runtime 之后，我们选择迁移到 Amazon Bedrock AgentCore Runtime。核心原因是它直接解决了前线 Agent 规模化落地中最棘手的四个问题：

  • 每用户（每租户）隔离：4,000 家门店各自需要独立的身份、权限、记忆和会话上下文。AgentCore Runtime 按会话提供 MicroVM 级别的运行隔离，“每门店一个专属 Agent”天然获得租户间的强隔离边界，团队无需自行设计和维护复杂的多租户隔离层。
  • 成本优化：Runtime 按会话、按实际调用计费，闲置期间不占用常驻算力。无需为 4,000 家门店长期预留 4,000 个常驻进程或容器——这也是单店每月模型与云资源增量成本能够控制在约 100 元的关键。
  • 免运维基础设施：无需自建和维护 Kubernetes、容器编排、节点扩缩容、系统补丁和高可用方案。底层运行环境由托管服务负责，团队得以专注于 Agent 的业务逻辑、技能和工具，而非基础设施。
  • 支持大规模并发：Runtime 按调用自动弹性扩缩，可从容承载数千家门店的并发调用与高峰时段的突发流量，无需提前进行容量规划或手动扩容。

正是这四点让我们判断：相比自建，AgentCore Runtime 能以更低的运维负担和更优的成本结构，支撑前线 Agent 从数十家试点门店扩展到 4,000 家门店的规模。

二、项目目标

我们围绕五个目标开展集成：

  1. 保留本地 Agent 的定义、Skills、Tools 和业务上下文。
  2. 通过 Amazon Bedrock AgentCore Runtime 承载 Agent 的云端运行。
  3. 连接 Slack、飞书等工作入口，并通过 Channel Adapter 扩展企业微信、钉钉等企业渠道。
  4. 支持 Webhook、定时任务、状态恢复和持续运维。
  5. 形成可检查、可部署、可复现的开源示例。

FastAgent 的中心接口保持为：

invoke(scope, prompt) => AsyncIterable<AgentEvent>

Channel 将外部事件转换为调用，AgentCore Runtime 提供云端运行环境，企业系统继续提供数据、知识和业务工具。

三、总体架构

图 1：FastAgent 与 Amazon Bedrock AgentCore 总体架构

[图 1：FastAgent 与 Amazon Bedrock AgentCore 总体架构]

Amazon Bedrock AgentCore Runtime 提供面向 Agent 的云端运行能力和会话隔离。AWS Identity and Access Management 管理资源访问边界，Amazon ECR 保存 Linux ARM64 容器镜像，AWS CloudFormation 统一管理 Runtime、AWS Lambda 和 Amazon EventBridge Scheduler 等资源，Amazon CloudWatch 承载运行日志。

FastAgent 在 Runtime 内加载 Agent 定义，处理流式调用、渠道事件、会话和任务。两层通过 AgentCore Runtime 的 HTTP 协议连接，企业可以在同一云端架构中运行已有 Agent。

关于 FastAgent

本次项目中的 FastAgent 正是承接这一步的开源框架（MIT 许可）。它的核心理念是“一个目录就是一个 Agent”：开发者在编码代理中已经打磨好的 AGENTS.md 指令、skills/ 技能和 tools/ 中的 TypeScript 工具，全部以文件形式保留——不引入新的 DSL，也无需框架级重写。FastAgent 不是又一个 Agent 编写规范，而是补齐了「从本地 Agent 目录到线上服务」这关键一跳：它围绕一个精简的 invoke 服务契约，为已有的 Agent 定义提供运行时与各类适配器。

具体而言，FastAgent 提供三类能力：多渠道接入（把同一个 Agent 服务为 GitHub PR 审查、Telegram、飞书 / Lark、Slack、HTTP/SSE 端点或自定义 Channel，内置签名校验、流式回复与群聊感知）；模型与工具中立（支持 OpenAI、Anthropic、Google 等任意模型提供方，工具从 tools/ 目录按文件名自动发现并用 Zod 校验，技能按需加载）；以及随处部署（目录即部署单元，无需应用构建步骤，fastagent deploy docker|fly|railway|agentcore 可直接生成容器与目标平台配置）。其中 agentcore 目标正是本项目的落地路径——它为 Amazon Bedrock AgentCore 生成单栈 CloudFormation 拓扑（Webhook 经由转发 Lambda、定时任务经由 EventBridge）。FastAgent 强调「嵌入而非接管」：不提供需要迁入的平台或控制台，你的鉴权、数据库、路由和基础设施始终归你所有。

四、五项关键集成

1. 适配 AgentCore Runtime

FastAgent 按照 AgentCore Runtime HTTP 协议提供 /invocations 和 /ping，生成 Linux ARM64 容器，并将镜像推送到 Amazon ECR。部署模板使用 AWS CloudFormation 描述运行时、身份权限、入口和任务资源，方便团队审核和持续维护。

2. 连接 Slack、飞书和企业渠道

AgentCore Runtime 通过 InvokeAgentRuntime 接收调用。面向 Slack、飞书等 Webhook 场景，架构使用 AWS Lambda Function URL 提供公共 HTTPS 入口。转发函数保留原始请求方法、路径、请求头和请求体，再调用固定的 Runtime 入口会话。FastAgent Channel 在容器内继续完成签名校验、事件解析、会话选择和消息回复。

这一机制已经覆盖 Slack 和飞书验证场景。企业微信、钉钉等入口可以沿用相同的 Channel Adapter 机制完成扩展。

3. 让定时任务适应按需运行

本地常驻进程可以维护 Cron 时钟，AgentCore Runtime 按会话提供计算环境。部署过程中，FastAgent 将可转换的静态计划映射为 Amazon EventBridge Scheduler 资源。计划到达触发时间后，EventBridge 调用入口函数，再由 Runtime 启动对应 Agent 任务。

Agent 主动创建的后续唤醒任务也可以映射为一次性 EventBridge 计划，使延迟检查、定期汇总和主动提醒获得云端触发能力。

4. 保存跨版本状态

AgentCore Runtime 的托管 Session Storage 可以在同一版本的停止和恢复之间保存会话文件。根据 AWS 官方文档，MicroVM Runtime 的 Session Storage 在 14 天没有调用或 Runtime 版本更新后会重置。

FastAgent 为共享 Webhook 和定时入口增加 Amazon S3 状态快照。新运行环境在首次可信调用时恢复会话、渠道去重记录、待处理任务和唤醒计划，工作完成后再更新快照。模型凭据可能随运行发生轮换，因此状态桶按照凭据存储的安全等级管理，并启用访问限制和版本控制。

5. 建立部署和运行观测

部署流程依次完成环境检查、镜像构建、Amazon ECR 推送、AWS CloudFormation 更新、状态检查和入口验证。Runtime 应用日志与 Lambda 入口日志分别进入 Amazon CloudWatch，运维人员可以快速判断问题发生在外部事件、入口转发、Runtime 启动、模型调用或渠道回复环节。

五、项目成果

本次项目形成了从本地 Agent 到 AgentCore 云端服务的完整路径，并在真实业务场景中得到验证。FastAgent 当前可以通过 fastagent deploy agentcore 生成可审查的部署文件，通过 fastagent deploy agentcore –run 驱动部署流程。下面从技术与业务两个维度总结阶段成果。

5.1 技术成果

在技术侧，本地 Agent 已完成向 AgentCore Runtime 的容器化部署，并通过了流式调用验证；Slack、飞书等 Webhook 渠道可以经由统一入口进入 Runtime。任务触发方面，静态计划与共享入口唤醒可以通过 Amazon EventBridge 执行，共享入口状态则可以借助 Amazon S3 快照跨 Runtime 版本恢复。运维可观测性方面，Runtime 与入口函数的日志能够分别查询和跟踪。此外，部署配置、容器与示例代码均以可检查的文件形式开放，具备可复现性。

5.2 业务成果

在业务侧，项目落地于第一章提到的 A 集团前线 Agent 场景。早期试点覆盖数十家不同类型和层级的门店，每位试点店长通过飞书获得专属 Agent，按日、周、月接收商品、陈列、补货和经营行动建议，并反馈现场执行情况。

试点阶段观察到，店长建议执行率超过 80%，部分门店的长尾商品销售提升 20% 至 30%，试点期间单店销售额提升 30% 至 50%，单店每月模型与云资源增量成本约 100 元。这些阶段数据用于展示早期验证信号，最终结果以双方确认的样本、周期、指标口径和归因报告为准。该场景也进一步明确了规模化前线 Agent 对独立会话、状态恢复、定时任务、渠道接入和运行观测的要求。

六、总结与下一步

Amazon Bedrock AgentCore 为 Agent 提供企业级云端运行基础。FastAgent 专注于连接本地 Agent 定义、AgentCore Runtime 和企业工作入口。在 AgentCore 团队的支持下，我们已经形成一条开放、可检查、可复现的集成路径。

下一步将继续完善示例仓库、企业渠道适配和规模化状态管理，并通过更多真实场景验证部署与运营方法。欢迎开发者和企业团队查看代码、运行示例、试用 Amazon Bedrock AgentCore，并向双方团队提交集成反馈。

相关资源

➡️ 下一步行动：

相关产品：

相关文章：

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

本篇作者

石洋

开源 Agent 开发框架 FastAgent 核心维护者，毕业于卡内基梅隆大学。在云计算、AI 基础设施、应用架构及大规模音视频系统领域拥有十余年设计与研发经验，并在大规模 AI应用与 Agent Harness 的架构设计和工程落地方面积累了丰富实践。目前专注于开源 AI Agent 开发框架和基础设施建设，致力于推动企业级 AI Agent 的高效开发、云端部署与规模化落地。

姬军翔

亚马逊云科技资深解决方案架构师，负责AI Agent相关的产品和技术咨询，超过10年的机器学习系统构建经验。

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

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