AWS 发布 AgentCore 环境智能体参考实现
来源AWS Machine Learning查看原文
速览
- 环境智能体把触发机制从用户提示词换成系统事件，适合文档处理、监控告警、定时分析等场景。
- 人工介入被设计成单一工具加统一响应信封，平台层只有一条代码路径。
- autoExecute 开关决定自动执行还是先人工复核，是控制风险的关键配置。
- 事件经 S3 通知、Signal Processor、SQS、Job Execution Lambda 到 AgentCore Runtime 的完整链路。
- 智能体容器基于 LangChain 的 create_agent 构建，工具由 config.yaml 配置驱动，开关工具无需改代码。
- 示例明确区分「平台自带」与「用户自建」：平台做管道，业务智能体需自行编写。
- 文章给出了 webhook 信号处理器的示例代码，说明新增信号类型的三步契约。
- 生产部署建议包括 IAM 最小权限、DynamoDB 与 S3 静态加密、CloudFront 与 API Gateway 强制 HTTPS。
- 作者指出实时聊天、简单请求响应 API、纯确定性工作流不适合用环境智能体。
AWS 在其机器学习博客上发布了一篇技术文章，介绍如何用 Amazon Bedrock AgentCore 构建「环境智能体」（ambient agents）。这类智能体不再等待用户打开聊天窗口输入提示词，而是监听事件流（如 Amazon S3 文件上传、定时任务），自动创建任务并执行，在需要澄清、审批或复核时通过单一的 ask_human 工具暂停并请求人工介入，人工回复后从断点继续。文章给出了完整的参考实现：事件经 Amazon S3 通知触发 Signal Processor Lambda，匹配 DynamoDB 中的信号定义后创建任务，经 Amazon SQS 队列由 Job Execution Lambda 调用 AgentCore Runtime 上的容器化 LangChain 智能体，状态与对话历史存于 DynamoDB，React 前端通过 API Gateway 轮询展示。信号上的 autoExecute 开关决定任务是自动执行还是先等人工确认。示例默认使用 Anthropic Claude Sonnet 4.5 模型，附带 calculator、ask_human、list_s3_files、read_s3_file 四个工具，整套平台以单个 AWS CDK 栈部署。
关键事实
- 环境智能体由事件触发而非用户提示词触发，可并行处理多个事件，但并非完全自主，会在需要时暂停等待人工输入。
- 参考实现中，信号上的 autoExecute 标志是唯一开关：false（默认）时任务以 idle 状态等待人工执行，true 时直接入队自动运行。
- 智能体通过单一 ask_human 工具请求人工输入，返回规范响应信封，status 为 completed、interrupted 或 error，对应字段为 result、question 或 error。
- ask_human 工具不抛异常，而是返回哨兵字符串 __HUMAN_INPUT_REQUIRED__::，由编排器在图执行结束后检测并转换为 interrupted 响应。
- 示例默认模型为 us.anthropic.claude-sonnet-4-5-20250929-v1:0，区域 us-east-1，max_iterations 设为 10。
- 对话存储表设置 30 天 TTL，对话消息通过 UpdateItem + list_append 原子追加，避免并发写入互相覆盖。
本站视角
这篇文章对国内做 Agent 落地的团队有直接参考价值，但价值点和 AWS 的营销口径不完全一致。首先，它把「人在回路」从概念变成了可复制的工程契约：一个 ask_human 工具加一个三状态响应信封（completed / interrupted / error），平台层只有一条代码路径。这个设计对国内做企业级 Agent 的团队尤其值得抄——很多团队卡在「智能体要不要全自动」这个二选一上，而 AWS 的答案是把它降级成一个配置项 autoExecute，默认 false 先人工复核，跑顺了再打开。这比在架构层面做两套流程务实得多。其次，它明确了平台与业务的边界：AWS 提供信号接入、SQS 任务管道、DynamoDB 状态、React 界面和 AgentCore 托管，业务方只需要写一个符合契约的容器化智能体，大约 50 行适配代码。这对用 API 的中小团队是个提醒——真正的工作量在业务智能体和工具实现上，不在管道上。第三，需要指出的是，这篇文章本质是 AWS 的开发者布道内容，配套的是 GitHub 上的 aws-samples 仓库，目的是引导用户使用 Bedrock AgentCore、SQS、DynamoDB 这一整套 AWS 服务。文章没有给出任何性能数据、成本对比或与竞品的横向评测，所谓「时间从小时级降到秒级」是定性描述而非实测结果，读者不应把它当作基准。另外，示例默认绑定 Anthropic Claude Sonnet 4.5 和 us-east-1 区域，国内团队如果不在该区域部署，模型可用性和延迟都需要重新评估。我们认为，这套模式最值得国内团队借鉴的是它的「契约思维」：把智能体与平台之间的接口收敛到极少的几个约定上，从而让事件源、工具、模型都可以独立替换。至于是否要照搬 AWS 这套服务组合，取决于团队已有的云基础设施——如果已经在用阿里云或腾讯云，事件通知、消息队列、状态存储都有对应组件，这套架构模式完全可以平移，不必为了参考实现而迁移云厂商。
背景与影响
环境智能体（ambient agents）这一概念近期由 LangChain 等团队提出，核心是把智能体从「对话驱动」转向「事件驱动」：智能体监听事件流并对其采取行动，可同时处理多个事件，但保留人工介入环节。AWS 这篇文章的定位是把这一范式落到自家基础设施上。AWS 用户本身已经大量使用 Amazon S3 事件通知、Amazon EventBridge、AWS Lambda 触发器和 DynamoDB 流等事件驱动组件，缺的是把这些事件源接到能推理、能行动、能在必要时找人的智能体上。文章指出，AWS Step Functions 这类全自动管道能编排流程但无法处理歧义或主动提问，聊天型智能体有推理能力却需要有人先开口，环境智能体补的是中间这段。Amazon Bedrock AgentCore 是 AWS 面向智能体规模化构建与运行的平台，AgentCore Runtime 提供基于容器的托管执行环境，支持长时运行任务和会话隔离。这意味着 AWS 正在把「事件驱动 + 人在回路」这套模式产品化，用参考实现而非成品的形式提供给开发者。需要注意的是，文章明确说明这是一个参考实现而非开箱即用的产品，自带的智能体只用于验证管道，不能直接解决业务问题。
本文由 AI 辅助整理自公开信源，事实部分以原文为准；「本站视角」一节为编辑部判断，欢迎指正。版权归原作者所有，如有异议请联系我们。