人机协同Agent的“回复”闭环：安全异步回传的架构思考

构建需要人类做决策的Agent系统时，请求侧往往不是最难的部分——一个带工作量证明（PoW）的 llms.txt 端点就能挡住大部分垃圾请求。真正棘手的是回复侧：客户端是无状态的，不可能挂起等待三个小时的 200 OK。一位开发者在 Reddit 上提出的这个问题，戳中了 human-in-the-loop（HITL）架构中最容易被低估的环节。

无状态客户端与长时等待的根本矛盾

传统 HTTP 请求-响应模型假设调用方会在原地等待结果返回。但人类决策的时间尺度是分钟到小时级别，远超 HTTP 连接的生命周期。客户端可能是一个 CLI 工具、一个 CI 流水线步骤，或者一个已经结束运行的 Agent 实例。它们发出请求后就“消失”了，既没有持久的内存空间，也没有持续的网络连接来接收回复。

这就产生了一个架构上的空档：请求发出后，回复该送到哪里？由谁暂存？如何保证只有合法的请求方能取回？原帖作者尝试用零知识中继（channels/namespaces）搭建了一个“邮箱”，但他自己也承认这套方案“感觉过于复杂”。

无状态客户端指每次请求都携带完整上下文、不依赖本地会话存储的客户端形态。在 HITL 架构中，无状态性带来两个直接后果：一是客户端无法在内存中保留“我发起过某个请求”的记录，必须在请求时把标识（token、请求 ID）外化到可持久化的介质中；二是客户端重启或迁移后，必须能凭该标识重新定位到对应的决策结果。因此，回复闭环的设计前提是：请求与回复之间必须存在一个可外部引用、可跨会话恢复的关联键，而不能依赖进程内的回调或闭包。这也是后文所有方案都围绕“令牌”展开的根本原因。

常见方案的权衡取舍

围绕这个回复闭环，业界其实已经沉淀出几类思路，各有代价。

轮询与长轮询：简单但浪费

最直接的做法是让客户端携带一个 token 定期轮询状态端点。实现成本低，但频繁空轮询带来无效负载；长轮询（long polling）能减少空转，却仍受限于连接超时和代理层的中断。对于“三小时后才有回复”的场景，轮询窗口的设定本身就是个难题。

Webhook 回调：需要可寻址的接收方

把回复 POST 到客户端预先注册的回调地址，是事件驱动系统的标准做法。问题在于，很多 Agent 客户端根本没有公网可达的端点，尤其是在本地开发或受限网络环境中。此外，回调地址本身需要鉴权，否则会成为新的攻击面。

可寻址性（addressability） 指接收方拥有一个稳定、可从公网解析并建立连接的端点。Webhook 方案成立的前提是接收方具备可寻址性，但 Agent 客户端常常运行在 NAT 之后、本地回环地址或临时容器中，不具备公网入站能力。此外，回调地址还需防范 SSRF（服务端请求伪造）：攻击者可能注册指向内网地址的回调 URL，诱导中继服务向其发起请求。成熟实现通常要求回调地址经过归属验证（如发送 challenge 并校验响应），并对目标 IP 段做白名单限制。这些约束使得 Webhook 在开放环境中并非“即插即用”的方案。

邮箱式中继：安全但复杂

这正是原帖作者的方案——用一个中继服务充当即时消息式的“信箱”，按 channel/namespace 隔离，客户端凭凭证取回。它的安全性最好，但引入了额外的状态管理和信任假设：中继服务本身必须被信任，命名空间的访问控制、消息过期、防重放都需要仔细设计。作者感到“过度复杂”并非没有道理。

签名令牌 + 拉取：折中路线

另一种思路是让请求方生成一对密钥或一个签名令牌，回复方（人类决策者）用该令牌对决策结果签名，结果写入一个可公开但不可篡改的存储（如内容寻址存储），客户端凭私钥或令牌拉取并验证。这样中继只需保证可用性，不需要成为可信第三方。安全边界从“信任中继”转移到“验证签名”，复杂度有所下降。

内容寻址存储（content-addressed storage） 以内容哈希作为寻址键，同一内容永远对应同一地址。其安全意义在于：存储层无法在不改变地址的前提下篡改内容，客户端凭哈希即可验证完整性，从而把“信任存储方”降级为“信任哈希函数”。配合数字签名，回复方可对决策结果签名，客户端用公钥验证来源真实性，实现不可否认性。这种组合将安全边界从“信任中继服务”转移到“验证密码学证据”，中继只需保证可用性与抗审查，无需被完全信任，是降低信任假设的常用工程手段。

安全性不能只靠传输层

无论选择哪种回传机制，有几个安全属性必须显式满足：回复的真实性（确实来自被授权的人类决策者）、完整性（传输中未被篡改）、以及没错性（决策者可被追溯）。单纯依赖 HTTPS 只能保证传输通道安全，无法回答“这个回复是否合法”的问题。

原帖中 PoW 门控解决了请求侧的滥用问题，但回复侧面临的是另一类威胁：伪造回复、重放旧回复、以及未授权方读取敏感决策内容。这也是为什么作者最终走向了带命名空间隔离的中继——他需要的是访问控制，而不仅仅是加密传输。

一个务实的架构建议

综合来看，对于大多数 HITL 场景，分层设计比单一机制更现实：请求侧用 PoW 或速率限制挡住滥用；回复侧用短期有效的签名令牌绑定请求与决策，配合一个轻量的、只负责暂存和转发的存储层；客户端在恢复运行时凭令牌拉取并验证签名。中继不需要理解业务语义，也不需要长期保存明文，从而把信任假设降到最低。

原帖作者的困惑很有代表性：HITL 系统的难点不在“问”，而在“答”如何安全地回到一个可能早已不在原地的提问者手中。这个问题的答案，取决于你愿意把信任放在哪一层——是信任一个复杂的中继，还是信任一套可验证的签名机制。