Reactiv用AgentCore把电商App更新做成定时任务，配置时间降80%
AWS博客披露：Reactiv基于Amazon Bedrock AgentCore搭建三智能体系统，商家用自然语言设定每周更新计划，系统自动生成配置，但上线前仍需商家审批。
AI解读：Reactiv的客户是Shopify商家，这些商家的原生App转化率是网页访客的2到4倍，但首页过时或错过促销窗口都会直接损失收入。问题是每周手动换选品、调版块、做素材、按时发布，多数商家没这个精力。Reactiv做的AI Scheduler就是把这套动作交给智能体按计划自动执行。
具体做法是商家用自然语言描述需求，比如“每周一上午9点用热销品刷新首页”，系统生成一条Amazon EventBridge定时规则；触发后由Supervisor、Analytics、Builder三个智能体分工，查询数据、生成新配置，最终结果存入DynamoDB等待商家审批。官方明确写了：没有商家明确批准，任何改动不会上线。
对商家来说，直接影响是配置时间从17小时降到3小时，发布后的改动从按天算变成按分钟算；对Reactiv来说，三人团队用10周做出三智能体系统，此前单智能体版本花了15周。省下的还有约100个OpenAPI规范文件被Strands SDK的装饰器替代，以及每年近6000美元的算力成本。
更值得注意的是多租户隔离和记忆。每个商家的执行环境、记忆和状态跑在独立的Firecracker microVM里，记忆按商家隔离，不会串数据。互动式编辑智能体和定时智能体后来统一到同一套框架和记忆上，商家在后台聊天时留下的偏好，会直接被下一次定时任务使用。
限制同样清楚：这套系统的能力边界是Reactiv预定义的设计属性和版块类型，目前正在把颜色、字体、间距等做成MCP服务器，让智能体在受控的设计语言内修改，而不是自由生成布局。
这些数字来自Reactiv内部测量，AWS博客转述，没有第三方验证。工具数量、节省成本和提速比例可以看作这家公司的自报成绩，不是行业普遍水平。对做类似多智能体产品的团队，可参考的是它的架构取舍：托管运行时、持久记忆、原生MCP和按租户隔离，而不是照搬80%这个结果。
Reactiv为Shopify商家提供原生iOS和Android App搭建服务。AWS机器学习博客称，这类App的购物者转化率是网页访客的2到4倍，但商家普遍没时间每周手动更新首页、换选品、做素材。Reactiv用Amazon Bedrock AgentCore搭了一套AI Scheduler，让商家用自然语言设置定时更新，系统自动生成新配置。
Reactiv公布的内部数据显示，商家配置时间减少80%：原本17小时的手动工作现在3小时完成，发布后的改动用分钟而不是天计算；三人团队用10周交付三智能体系统，此前单智能体版本用了15周，到生产环境的速度快33%。
商家说一句话，EventBridge定时触发三个智能体
AI Scheduler的入口是Reactiv后台的聊天框或表单。商家输入类似“每周一上午9点用热销品刷新首页”的指令，选择频率和时间，系统生成一条Amazon EventBridge cron规则作为计划记录。
触发后，Lambda函数先校验商家账号、获取并发锁、拉取当前App配置，再把商家提示词、现有配置和会话元数据一起传给AgentCore runtime。runtime内部运行一个Strands多智能体图：Supervisor Agent分类意图并路由到纯分析、纯构建或先分析后构建的流程；Analytics Agent通过text-to-SQL查询Amazon Redshift中的商家表现数据；Builder Agent据此生成更新后的App配置。
Builder Agent会调用50多个工具，包括通过Config MCP做配置变更、通过Lambda查询数据、用Shopify Storefront SDK查商品、用图像生成SDK创建素材。Config MCP托管在AgentCore上，对每一次配置变更按Reactiv的App schema校验。博客原文的说法是，MCP同时充当参考和护栏，Builder Agent无法产出不合法的配置。生成的配置存入Amazon DynamoDB等待商家审核。
- 调度：Amazon EventBridge cron规则，按商家设定的频率触发
- 执行：AWS Lambda做任务执行器，校验账号、锁并发、拉取当前配置
- 智能体：Supervisor做意图路由，Analytics查Redshift数据，Builder生成配置
- 校验：Config MCP托管在AgentCore runtime，按App schema校验每次变更
- 结果：存入DynamoDB，商家审批后才上线
AgentCore提供托管运行时、长期记忆和按商家隔离
Reactiv在迁移前有四类需求：多智能体编排、跨会话持久记忆、原生MCP支持和按商家隔离数据。他们最终用了AgentCore的三项能力。
AgentCore runtime把智能体跑在Firecracker microVM里，这是AWS Lambda同款隔离技术。Reactiv把Strands智能体图打包成Docker镜像，推到Amazon ECR，再部署到AgentCore。定时触发时智能体启动，跑完关闭，不需要Amazon ECS集群、扩缩容策略或常驻算力。Reactiv高级AI开发者Adam Gibicar在博客中说：“我们不管理容器、编排器或扩缩容策略。把智能体代码打包成Docker镜像，部署到AgentCore，剩下的它处理。”
记忆方面，AgentCore提供跨会话的长期记忆。Reactiv用了三种策略：会话摘要器把每次任务的动作压缩成后续运行可用的上下文；偏好学习器记录商家长期批准或拒绝的布局；语义事实提取器存储商家店铺知识，比如商品类目、热销品和品牌规范。记忆按商家划分，不需要自建向量数据库或检索管道。
隔离方面，每个商家的执行上下文、记忆和智能体状态都跑在独立的Firecracker microVM里，商家A的偏好和商家B的会话互不可见，租户路由和隔离由AgentCore在基础设施层处理。
- AgentCore runtime：托管智能体执行，按需启停，无闲置算力
- AgentCore memory：跨会话长期记忆，按商家隔离，三种记忆策略
- AgentCore Identity：处理服务间认证，替掉此前自建的Cognito认证层和JSON-RPC握手代码
- Config MCP：作为有状态服务器托管在AgentCore runtime上，会话开始时初始化商家当前App配置
互动和定时两套智能体合并，记忆双向共享
上线调度器后，Reactiv有两套互不相通的智能体系统：互动式后台智能体基于自定义UI适配器，定时智能体基于Strands加AgentCore，二者不共享记忆、工具和基础设施。
他们后来把互动智能体迁移到Amazon Bedrock AgentCore上的AG-UI协议，使后台智能体和调度器共用同一套Strands框架、AgentCore托管的MCP服务器和AgentCore记忆实例。结果是双向记忆共享：后台会话中学到的偏好和事实会进入下一次定时任务，定时任务积累的信息也会反过来影响后台交互。按博客描述，商家越常用前台智能体，定时任务就越贴合偏好。
其他内部测量数据还包括：用Strands SDK的@tool装饰器取代约100个OpenAPI规范文件；迁移后仅算力一项每年节省近6000美元；定时任务执行时间从超过10分钟降到约5分钟，原因是AgentCore runtime的原生流式输出替代了此前四步轮询链。
- 合并前：互动智能体和定时智能体不共享记忆、工具和基础设施
- 合并后：共用Strands框架、MCP服务器、记忆实例和UI协议
- 任务执行时间从10分钟以上降至约5分钟
- 算力成本每年节省近6000美元
下一步是把设计系统做成MCP，仍有限制
Reactiv接下来会把现有设计属性——颜色、字体、间距、组件变体——做成新的MCP服务器，托管在AgentCore上，供调度器、互动构建器以及未来的外部集成共用。商家可以说“让App符合我的品牌”，智能体在受控的设计词汇内改，而不是无约束生成。
这套设计系统还会用于重做入驻体验：新商家提供品牌名和网站后，智能体能分析其现有网页，基于真实设计属性和组件生成App的起点，而不是从零搭布局。更远期的计划是让商家用自然语言请求全新的布局版块，智能体生成经过校验的JSON表示，App用Reactiv的设计系统组件实时渲染。
需要说明的是，这篇AWS博客中的效果数据均为Reactiv内部测量，由AWS转述，没有第三方验证。50多个工具、80%配置时间下降、33%到生产提速和每年近6000美元节省属于公司自报成绩，不代表行业普遍水平。另外，文章没有披露智能体生成配置的准确率、商家拒绝率或出错时的回滚机制。
- 设计属性将作为新MCP服务器托管在AgentCore，先服务调度器和互动构建器
- 未来支持自然语言生成新布局版块，用设计系统组件渲染
- 效果数字来自Reactiv内部测量，由AWS博客转述，无第三方验证
- 未披露智能体生成配置的准确率、拒绝率和回滚机制