从本地到数千门店：FastAgent 与 Amazon Bedrock AgentCore 的企业级 Agent 实践
内容提要
FastAgent 与 Amazon Bedrock AgentCore 集成，将本地 Agent 迁移至云端，为 A 集团约 4000 家门店提供专属店长 Agent。AgentCore Runtime 支持按会话隔离、按需计费、免运维和弹性并发，单店月成本约 100 元。项目完成 Runtime 部署、Slack/飞书接入、EventBridge 定时任务、S3 跨版本状态恢复及 CloudWatch 日志观测。试点门店执行率超 80%，销售额提升 30%–50%。
延伸解读
为什么选择托管 Runtime 而非自建
文章明确对比了自建容器编排与 AgentCore Runtime 的差异。对于 4000 家门店的规模，自建意味着要维护多租户隔离、扩缩容和常驻算力；而 Runtime 按会话提供 MicroVM 级隔离，并按实际调用计费，闲置不占算力。这使单店每月模型与云资源增量成本能控制在约 100 元，同时免去 Kubernetes 等基础设施运维。这一选择的核心逻辑是：用托管服务换取更低的运维负担和更优的成本结构。
状态恢复的边界与补充方案
文章指出 AgentCore Runtime 的托管 Session Storage 在 14 天无调用或版本更新后会重置。这意味着仅靠内置存储无法满足跨版本、长周期的状态延续需求。FastAgent 因此增加 S3 状态快照，在首次可信调用时恢复会话、渠道去重记录和待处理任务。这一设计提醒读者：托管服务的默认能力有明确边界，企业需根据业务连续性要求评估是否补充外部持久化层。
试点数据的解读口径
文章报告试点门店执行率超 80%、部分门店长尾商品销售提升 20%–30%、单店销售额提升 30%–50%。但原文同时强调，这些是早期验证信号，最终结果以双方确认的样本、周期、指标口径和归因报告为准。读者在参考这些数字时，应注意其阶段性和归因局限性，不宜直接外推为规模化后的确定收益。
渠道接入的扩展方式
Slack 和飞书通过 Lambda Function URL 接收 Webhook，转发函数保留原始请求信息后调用 Runtime 固定入口，容器内再完成签名校验和消息回复。文章说明企业微信、钉钉等渠道可沿用相同的 Channel Adapter 机制扩展。这表明该架构的渠道层是解耦的，新增入口主要涉及适配器开发，而非改动 Agent 核心逻辑，有利于企业按自身办公生态逐步接入。
Q&A
FastAgent 和 Amazon Bedrock AgentCore 是怎么配合工作的？
FastAgent 负责保留本地 Agent 的定义、Skills、Tools 和业务上下文，并通过精简的 invoke 服务契约提供运行时与适配器；Amazon Bedrock AgentCore Runtime 提供云端运行环境、会话隔离和弹性扩缩。两者通过 AgentCore Runtime 的 HTTP 协议连接，FastAgent 在 Runtime 内加载 Agent 定义，处理流式调用、渠道事件、会话和任务。
为什么 A 集团要把门店 Agent 从本地迁移到 AgentCore Runtime？
核心原因是 AgentCore Runtime 解决了四个规模化难题：按会话提供 MicroVM 级运行隔离，满足 4000 家门店各自独立的身份、权限、记忆和会话上下文；按会话和实际调用计费，闲置不占常驻算力，使单店每月模型与云资源增量成本控制在约 100 元；免运维基础设施，团队无需自建 Kubernetes 和扩缩容；按调用自动弹性扩缩，支撑数千门店的并发与突发流量。
FastAgent 如何把 Slack、飞书等渠道的消息接入到云端 Agent？
架构使用 AWS Lambda Function URL 提供公共 HTTPS 入口，转发函数保留原始请求方法、路径、请求头和请求体，再调用固定的 Runtime 入口会话。FastAgent Channel 在容器内完成签名校验、事件解析、会话选择和消息回复。该机制已覆盖 Slack 和飞书验证场景，企业微信、钉钉等可沿用相同的 Channel Adapter 机制扩展。
AgentCore Runtime 的会话状态在版本更新后会丢失吗？FastAgent 怎么解决？
根据 AWS 官方文档，MicroVM Runtime 的 Session Storage 在 14 天没有调用或 Runtime 版本更新后会重置。FastAgent 为共享 Webhook 和定时入口增加了 Amazon S3 状态快照，新运行环境在首次可信调用时恢复会话、渠道去重记录、待处理任务和唤醒计划，工作完成后再更新快照。状态桶按凭据存储的安全等级管理，并启用访问限制和版本控制。
FastAgent 在 AgentCore 上如何实现定时任务和主动唤醒？
FastAgent 将可转换的静态计划映射为 Amazon EventBridge Scheduler 资源。计划到达触发时间后，EventBridge 调用入口函数，再由 Runtime 启动对应 Agent 任务。Agent 主动创建的后续唤醒任务也可以映射为一次性 EventBridge 计划，使延迟检查、定期汇总和主动提醒获得云端触发能力。
这个项目在试点门店取得了哪些业务效果？成本如何？
早期试点覆盖数十家不同类型和层级的门店，每位试点店长通过飞书获得专属 Agent，按日、周、月接收商品、陈列、补货和经营行动建议。试点阶段店长建议执行率超过 80%，部分门店长尾商品销售提升 20% 至 30%，试点期间单店销售额提升 30% 至 50%，单店每月模型与云资源增量成本约 100 元。这些为早期验证信号，最终结果以双方确认的样本、周期、指标口径和归因报告为准。
FastAgent 部署到 AgentCore 的流程和可观测性是怎么做的？
部署流程依次完成环境检查、镜像构建、Amazon ECR 推送、AWS CloudFormation 更新、状态检查和入口验证，可通过 fastagent deploy agentcore 生成可审查的部署文件，并通过 --run 驱动部署。Runtime 应用日志与 Lambda 入口日志分别进入 Amazon CloudWatch，运维人员可以快速判断问题发生在外部事件、入口转发、Runtime 启动、模型调用或渠道回复环节。
