自主 Agent 的人类确认收件箱（HITL 通道）

自主 AI agent 在执行多步骤任务时经常需要人来拍板（“这个文件我分析完了，可以执行删除/发送吗？”），但现有 agent 框架没有统一的反向通信通道：agent 无法在任务中途“主动找人说一句话”。信号 2 的作者直言“没有这样一个开放的 inbox/channel，AI agent 无法在授权任务中主动与人发起对话”，只能自己造轮子（AI Beacon）；信号 3 显示开发者要在 AWS 上从零拼 Lambda、DynamoDB、Step Functions 才能实现一个“ask for approval before taking the next step”的 ambient agent。痛点集中在开发者侧：集成成本高、跨平台无通用方案、agent 跨步骤保持对话状态困难（AI Beacon 目前仍在测试“agent 能否保留 token 并跨步骤继续对话”）。

构建 tool-using 自主 agent 的开发者（个人开发者、agent 创业团队、平台工程师）。规模定性判断：随着 ambient agent / event-driven agent 兴起（信号 3 显示 AWS 已专门为此推出 AgentCore），这个开发者群体在快速扩大，但目前付费意愿未经验证，更像早期技术尝鲜人群。

• Agent 收件箱 API：一个开放的 JSON API，任何 agent 框架在任务执行中途可调用，向“操作员”发起会话（提问、请求批准、汇报发现）。
• 私与会话 token：agent 拿到一次性 conversation token，在多步骤长任务中保持同一对话上下文，跨轮次不丢状态——这正是 AI Beacon 正在验证的核心机制。
• 人类操作界面：轻量 Web 界面（或邮件/IM 转发），人看到 agent 的请求后一条回复即可批准、拒绝或给补充指令。
• 框架无关集成：提供 LangChain/AgentCore/自研 agent 的接入示例，AI 在其中的角色是被集成的“请求方”，产品本身是通信与状态层，不依赖具体模型。
• 事件驱动模式：参考 Bedrock AgentCore 的思路，以事件作为 prompt 触发 agent，响应走标准 envelope，便于审计。

三条信号都指向同一时间窗口：Bedrock AgentCore 在 2026-10 刚推出 event-driven ambient agent 与内置 HITL tool（“The event itself is the prompt”），说明大平台刚开始定义这个交互范式但方案重且绑定 AWS；同周开源社区出现 AI Beacon 这类轻量实验，说明框架外开发者正缺一个通用、可移植的 agent↔人通信层。范式刚成型、独立方案尚未出现，是切入的时机——但也意味着窗口可能很快被平台关闭。

第一版只做三件事：做——(1) JSON API：agent 在执行任务时可主动向收件箱发起会话；(2) 会话 token 机制：agent 在多步骤任务中持 token 保持同一会话上下文；(3) 简单 operator Web 界面：人类查看、回复、批准/拒绝 agent 的请求。不做——不做 agent 本身的编排或执行（不替代 LangGraph/AgentCore Runtime），不做厂商绑定的完整 HITL 工作流（如审批链、审计合规），不做多 agent 群聊（另一方向，暂不混入），不做企业 SSO/权限体系。

• 平台内置化：AWS Bedrock AgentCore 已把 HITL 作为单一内置 tool 提供，Anthropic/OpenAI 的 agent 产品也可能原生加入“agent 主动请求人类输入”，独立中间件窗口期可能很短。
• 需求真实性存疑：三条信号全部是 capability/launch 型，无用户吐槽或付费意愿，可能只是玩具项目氛围而非真实刚需。
• 技术不确定性：agent 跨步骤保持 token 与会话状态本身就是未验证难题（AI Beacon 作者仍在实验）。
• 安全与滥用：开放 inbox API 若被恶意 agent 用于垃圾消息或钓鱼式请求，需认真设计鉴权与限流。