两周前，安特罗皮克公司（Anthropic）旗下“克劳德代码”（Claude Code）负责人鲍里斯·切尔尼（Boris Cherny）在台上说了一番话，改变了我对构建基础设施的看法：
“我不再直接向克劳德（Claude）发送提示词了。我运行着循环程序。是它们在向克劳德发送提示词。”
随后，彼得·斯坦伯格（Peter Steinberger）发布了一篇帖子，为这一概念命了名：循环工程。这个想法很简单，但影响巨大。你不再编写提示词，而是开始设计为你向智能体发送提示词的系统。智能体进入一个循环——推理、行动、观察、重复——直到达成目标或耗尽预算才会停止。
这立刻让我产生了一个疑问：如果智能体将在循环中自主运行，那么当“行动”步骤涉及资金时会发生什么？
我运营着 Spraay——一个支持 x402 协议的支付网关，在 16 条区块链上拥有 170 多个端点。智能体已经通过模型上下文协议（MCP）服务器调用我们的批量支付、托管和工资发放端点。但这些调用都是“发后不管”式的。智能体发送请求，收到响应，除非进行轮询，否则无法知道付款何时实际结算。轮询会消耗令牌。消耗的令牌意味着成本。而在循环中，这种成本会在每个周期中累积。
因此，我们将该网关改造为原生支持循环。以下是其含义以及我们的构建方式。
核心问题：循环需要回调，而非轮询
一个采用循环工程设计的智能体在执行批量工资发放时，流程如下：
1. 观察：“需要支付 10 名员工的工资”
2. 推理：“我应该通过 Spraay 批量处理这些支付”
3. 行动：POST /api/v1/payroll/execute
4. 观察：???（智能体如何知道支付已结算？）
5. 推理：???（我应该重试？继续下一步？还是出错了？）
如果没有回调机制，第 4 步就会变成主循环内部的一个轮询循环。智能体会每隔几秒就猛烈请求 GET /status，在等待期间不断消耗推理令牌。对于单笔支付来说，这是一种浪费。而对于运行连续操作的智能体——如处理发票、释放托管里程碑款项、执行每周工资发放——这种做法是不可持续的。
解决方案：让智能体在任何请求中传递一个 callback_url（回调网址）。当操作完成时，网关会向该网址发送一个经过签名的负载数据。智能体的循环接收到事件，进行处理，并决定下一步行动。无需轮询，不浪费令牌。
实现方案：三个层级
第一层：Webhook 基础设施
核心系统是一个由 Supabase 支持的事件队列，配有一个后台分发工作器。当智能体在请求正文中包含 callback_url 时，网关会：
- 生成每个事件专用的哈希消息认证码（HMAC）签名密钥
- 将 Webhook 事件存入
webhook_events表中排队 - 返回正常响应以及一个包含
webhook_id和webhook_secret的webhook对象 - 后台工作器轮询待处理事件并进行投递
以下是智能体在包含 callback_url 时看到的内容：
