Ambient Agent 的生产架构：事件就是提示，但不能直接等于命令
2026 年 10 月 1 日，AWS 发布用 Amazon Bedrock AgentCore 构建 Ambient Agent 的架构：Agent 不等用户打开聊天窗口，而是由 S3、定时任务、数据库变化或系统告警触发；运行中可通过统一 ask_human 工具暂停，收到规范响应后继续。参考实现使用 AgentCore Runtime、DynamoDB 与 Lambda，并指出单次 Agent turn 受 Lambda 15 分钟上限约束。
这类“环境代理”把 Agent 从交互式助手变成后台参与者。最大的变化是事件本身成为 prompt，但事件是外部输入，不一定可信、完整或只出现一次。若直接把事件文本交给高权限模型执行，消息队列就等同远程命令入口。
事件负责唤醒，策略决定能做什么，持久状态保证它可以安全地停下来。
入口先做真实性与幂等
每个事件应验证签名、来源、租户、schema 和时间窗口，并生成稳定幂等键。对象存储通知和消息系统通常提供至少一次投递，重复事件是正常现象。平台要记录“已接收、处理中、等待、完成、失败”状态，重复到达时返回当前运行，而不是新建任务。
事件只传资源引用和最小上下文，Agent 再按权限读取详细数据。不要把整份不可信文档作为系统指令拼接；内容进入模型时明确标注为数据，并隔离其中可能存在的提示注入。
长任务要分 turn，而不是撑住进程
单次计算有 15 分钟上限并不是缺陷，而是提醒架构将任务拆成可检查点步骤。每个 turn 读取状态、执行有限动作、写入结果并决定下一状态。等待人工、第三方回调或冷却窗口时释放计算资源。
状态机必须记录副作用。若发送通知后进程崩溃，恢复时先检查幂等记录，不能再发一次。对于无法天然幂等的外部系统，使用业务唯一键、查询确认或补偿流程。
ask_human 应是正式协议
统一人工工具比每个场景临时发消息可靠，但请求不能只是一段自由文本。规范 envelope 应包含 run ID、问题类型、上下文摘要、可选动作、风险、截止时间与回复 schema。回复必须验证来自有权限的人，并绑定原运行。
审批超时需要明确策略：暂停、自动拒绝、升级值班人或执行低风险默认项。绝不能让模型自行解释“没有回复就是同意”。人类修改建议时，系统还要区分批准、拒绝和提供新信息，避免把评论误当授权。
生产系统必须有背压和死信
突发事件可能同时唤醒大量 Agent，形成模型、工具和下游 SaaS 的级联压力。队列应按租户和优先级限流，运行时设置并发、成本与动作预算。连续失败或 schema 不兼容的事件进入死信队列，保留原始事件和失败阶段供人工重放。
上线验收至少覆盖重复投递、乱序事件、审批超时、运行时崩溃、权限在等待期间被撤销和下游限流。Ambient Agent 的价值是持续响应环境，而不是持续占用资源；它的可信度来自每次唤醒都可验证、每次暂停都可恢复、每个动作都可追踪。