AWS发布基于Bedrock AgentCore的事件驱动ambient agent参考实现
文档落入S3后自动生成任务，AgentCore Runtime承载容器化智能体，遇需人工确认时通过单一ask_human工具暂停，人在Jobs页面用同一个响应信封回复。
AI解读：这套方案解决的是"文件来了没人及时处理"的问题：上传到S3的文件会触发信号，平台自动为匹配的智能体创建任务，智能体分析后给出结论，必要时才停下来等人确认。AWS博客给出了完整的服务端无服务器参考实现，不是概念介绍。
关键开关是信号上的autoExecute。默认false时任务以idle状态落到Jobs页面等人点击运行；设为true则直接进入工作队列立即执行，只有智能体自己调用ask_human才会打扰人。这意味着团队可以先跑"人工过一遍"的模式，确认稳定后再放开自动执行。
真正做工程的人需要留意：人机交互被压缩成一个工具加一个响应信封，status只有completed、interrupted、error三种，对应result、question、error。平台层只有一条代码路径，所以Notify、Question、Review、Error这些交互形态是提示词写法差异，不是运行时的不同模式。
AWS机器学习博客发布了一篇技术文章，介绍如何在Amazon Bedrock AgentCore上构建ambient agent（环境智能体）：这类智能体由事件流触发，而不是等用户在聊天框里输入提示词。文章作者为Juan Albarran。
文章给出的定义是：ambient agent响应事件流，需要时通过单一的ask_human工具暂停并向人询问，人类回答后从原处继续。文中将一个事件到智能体的完整链路概括为：Event → Signal → Agent → [可选人工交互] → Action。
文章用文档处理场景做说明：文件落到Amazon S3存储桶后，几秒内Jobs页面就会出现一个待运行的任务（如果配置为自动执行则已经在运行），智能体分析文件、呈现发现，并在采取下一步前请求批准。文中把这一模式表述为"事件本身就是提示词"。
文章同时给出了适用边界：完全自动化的流水线（如AWS Step Functions）可以编排工作流，但无法推理模糊情况或提出澄清问题；基于聊天的智能体可以推理，但需要有人先发起对话。ambient agent被定位为填补两者之间的空白。
依据来源摘要，本文只覆盖该博客文章的已发布内容，未验证参考实现的运行效果。
信号（signal）如何把S3事件映射成智能体任务
ambient signal是一份配置，把事件源映射到某个智能体；事件发生时平台自动为该智能体创建任务。参考实现开箱支持两类信号源，其余为扩展点。
信号在DynamoDB中存储，字段包括signalId、userId、agentId、signalName、signalType、enabled、autoExecute、bucketName，以及包含bucketName、prefix、suffix的configuration，另有triggerCount、lastTriggered、createdAt。
autoExecute是决定行为的关键开关：为false（默认）时任务以idle状态进入Jobs页面，等待人工审阅并运行；为true时信号处理器直接把任务入队，智能体立即运行，只有智能体自身调用ask_human才会引入人工。文章称后者为完全自主流程。
配置上有一个细节：DynamoDB GSI的分区键不能嵌套在map属性内，因此signal_management在每次写入时把configuration.bucketName镜像到顶层bucketName，让bucketName-signalId-index这个GSI能在每次S3事件中匹配到对应信号。
S3存储桶的通知配置由signal_management Lambda在创建或更新信号时动态安装，因此为新的前缀新增信号不需要重新部署。前缀和后缀过滤被下推到存储桶的通知配置，信号处理器只会被可能匹配的事件调用。
参考实现自带的两类信号源是：S3文件上传（在指定存储桶和前缀收到文件时触发）和定时事件（由携带jobType: "scheduled" 的任务驱动，而非Signals页面上的信号）。API webhook和数据库变更（DynamoDB Streams或Amazon RDS事件）被列为扩展点，需要自行编写新的处理Lambda函数和Signals页面上对应的表单字段。
ask_human工具与响应信封
该示例中智能体通过单一ask_human工具与人交互，并返回一个规范化响应信封。信封中status取值之一为completed、interrupted或error，对应字段分别是result、question或error。平台另外在每次响应中传递session_id和job_id以便关联后续轮次；文章说明这两个是关联元数据，不属于智能体必须实现的核心契约。
当智能体返回interrupted时，平台将任务置为interrupted状态并把requiresAction标志设为true。参考用的React前端会在Jobs页面的Interrupted标签以每行一个警告标识来呈现这些任务，因此不需要额外的审阅队列来轮询。同一个Jobs视图展示待答问题、待批准动作、最终结果和失败任务。
文章列举了该机制支持的人机交互提示模式：Notify轮次只报告结果；Question轮次请求澄清；Review轮次提出动作并等待APPROVE / REJECT / MODIFY；Error轮次把失败记录在任务上，由用户决定是否重试。文章明确这些是智能体如何写问题的约定，不是独立的运行时模式；平台层面只有一条代码路径和一个信封。
架构与组件
端到端流程为：Amazon S3发出s3:ObjectCreated通知，Signal Processor Lambda接收并对ambient-signals表上的GSI查询匹配信号，为每个匹配项创建任务记录；API层或调度器把任务入队到Amazon SQS；同一个Job Execution Lambda通过绑定的SQS事件源消费队列、在Amazon Bedrock AgentCore Runtime上调用智能体，并把结果及人工输入请求写回DynamoDB；由S3经CloudFront提供的React前端轮询一个小型API Gateway和Lambda层获取更新，让用户回应待处理交互。
管道由三个Lambda函数承担从入口到智能体的流转：Signal Processor匹配事件与信号定义并创建任务；Job Execution在一个函数中包含两条入口路径，即负责入队的API处理器和消费消息并以任务上下文调用AgentCore Runtime的SQS工作进程；Scheduler按一分钟的cron触发，把到期的定时任务入队到同一个SQS队列。
Amazon SQS用于把API Gateway请求与智能体调用解耦，job-execution队列存放待处理工作，死信队列（DLQ）捕获在配置重试次数后仍无法处理的消息。
Amazon Bedrock AgentCore Runtime在隔离容器中运行智能体代码，支持长时间运行的工作负载。文章称AgentCore Runtime支持的会话时长足以覆盖信号到人机交互的完整流程；参考实现把每个智能体轮次限制在Lambda的 15 分钟超时以内，文章认为实际中有足够余量。
Amazon DynamoDB存储智能体注册表、任务记录、ambient信号定义、聊天线程、对话历史和Powertools幂等记录。对话消息通过UpdateItem + list_append原子追加，避免并发写入互相覆盖。
API Gateway之后有五个管理层的Lambda函数暴露前端使用的REST API：agent_management、job_management、signal_management、chat_management、conversation_management，另有一个chat_execution工作Lambda由chat_management异步调用，使聊天API调用立即返回。React前端通过S3和CloudFront提供Agent Management UI。
文章附带的Signal Processor核心处理逻辑示例：遍历event["Records"]，取出bucket和key，对每个find_matching_signals(bucket, key) 的结果调用create_agent_job(signal, {"bucket": bucket, "key": key})。实际代码位于backend/functions/multi_agent/signal_processor.py，另外使用AWS Lambda Powertools做结构化日志和幂等，查询signals表上的bucketName-signalId-index GSI，应用每个信号上配置的前缀和后缀校验，并写入一条signal_triggered任务行。
智能体在AgentCore Runtime上的打包与配置
示例的智能体目录结构为：agent.py作为入口，config.yaml存放配置，requirements.txt列出依赖，core/下含agent_core.py（主智能体逻辑）、tool_factory.py（配置驱动的工具创建）、execution_control.py（会话状态与循环检测），tools/下含calculator.py、human_input.py、s3_reader.py（导出list_s3_files和read_s3_file）。
config.yaml定义智能体行为、工具和系统提示词。示例默认使用Amazon Bedrock上的Anthropic Claude Sonnet 4.5，模型ID为us.anthropic.claude-sonnet-4-5-20250929-v1:0，区域为us-east-1；文章称该模型适合该人机交互工作流依赖的多步工具调用和长上下文推理。切换到Claude Haiku、Amazon Nova或其他Bedrock上支持工具调用的模型只需改model_id一行，模型在各区域的可用性不同。
max_iterations: 10 让图在停止前有大约十次模型到工具往返的余量；编排器会将该值翻倍以计算LangGraph的递归上限，因为每次往返要经过两个图节点。文章称这覆盖了示例中S3、calculator和ask_human工具所需的多步工具使用。配置文件还包含一个execution: 块（循环检测器、熔断器、会话缓存阈值），文中为简洁省略，完整内容见agent/config.example.yaml。
前置条件
部署参考实现前需要准备下列条件（文中明确列出）：
一个具备创建IAM角色、Lambda函数、DynamoDB表、S3存储桶、Amazon SQS队列、Amazon API Gateway API、Amazon CloudFront分发、Amazon Cognito用户池、Amazon ECR仓库和Bedrock AgentCore运行时权限的AWS账户；文章称沙盒账户上的管理员权限是合适的起点。
已配置好该账户凭证、默认AWS区域为us-east-1的AWS CLI（示例默认值按该区域接线）。
已在账户和区域中完成bootstrap的AWS CDK v2（cdk bootstrap）。
本地已安装并运行的Docker；部署过程中会构建智能体容器并推送到Amazon ECR。
后端Lambda函数和智能体构建需要Python 3.11或更高版本，React前端需要Node.js 18或更高版本。
目标区域中可访问Amazon Bedrock的Anthropic Claude Sonnet 4.5模型；此前未使用过Bedrock的用户需按"Manage access to Amazon Bedrock FMs"启用该模型。模型在各AWS区域的可用性不同，需查阅Bedrock文档确认目标区域当前支持的模型列表。文章称之后切换模型只需改一行配置。