让你的智能体在有人回复的那一刻就行动

提问之后的等待

向人提问只是工作的一半。对方过几分钟或几小时才会回复，而那时智能体通常已经去忙别的了。以前它只有三种办法获知回复：循环轮询，架一个能唤醒它的 Webhook 服务器，或者停下来等用户回来问一句“他们回复了吗？”。聊天应用里的大多数智能体用的是最后一种，任务也就卡在这里。

MCP 推送：让回复主动找到智能体

你的智能体创建的每个请求同时也是一个 MCP 资源 runitby://requests/{requestId}，createRequest 的结果里附有指向它的链接。采用 2026-07-28 协议的客户端用 subscriptions/listen 订阅它。有人回复或状态变化时，Run it by 会发送 notifications/resources/updated；智能体读取这个资源（返回内容与 getStatus 相同），然后继续完成任务。

→ subscriptions/listen
  { "resourceSubscriptions": ["runitby://requests/req_8fK2…"] }

← notifications/resources/updated
  { "uri": "runitby://requests/req_8fK2…" }

→ resources/read
  { "uri": "runitby://requests/req_8fK2…" }   // status, verdict and every answer so far

你这边什么都不用运行：不用托管端点，不用校验密钥，也不用调轮询间隔。智能体提完问题就去做别的事，等对方回复后再接着干活。

示例：自己办完的一笔退款

一个客服智能体需要三位经理中的两位批准一笔 $1,200 的退款。它创建审批时设置了 sendEmail: true，所以每位经理都会通过邮件收到自己的链接，然后它订阅这个请求：

{
  "mode": "approval",
  "title": "Refund #4821",
  "requester": "Ava (the Acme refunds agent)",
  "audience": { "kind": "named", "recipients": [{ "name": "John Smith", "email": "john@acme.com" }, { "name": "Martin Carpenter", "email": "martin@acme.com" }, { "name": "Emily Lee", "email": "emily@acme.com" }] },
  "approval": { "reason": "Refund order #4821, $1,200", "policy": "majority", "verify": "email" },
  "sendEmail": true
}

1. 10:14。John 批准。智能体收到通知，读取请求（3 人中已有 1 人批准），继续等待。
2. 10:21。Emily 批准。审批结果为 "approved"；智能体在同一次会话里办理退款并告知客户。
3. Martin 不需要再回复了：审批规则已经满足，他的链接也不再接受回复。

如果经理们拒绝了，或者请求过期了，审批结果会如实说明，智能体也会就此停手。没有回复绝不会变成同意。

推送、Webhook、等待还是邮件？

• MCP 推送：适用于持续运行、需要自行做出反应的 MCP 客户端智能体。
• Webhook：适用于由你的后端掌控工作流的情况，每条回复都是一个带签名的 POST，服务器宕机时会重试数小时。
• 带 wait 的 getStatus：适用于对话还开着、回复很快的情况，它最多挂起 25 秒，有人一回复就立即返回。
• notifyEmail：适用于也需要让人知道，或者等对方回复时会话可能早已结束的情况。

它们可以随意组合：给智能体用推送，给它的主人发一封邮件，是不错的搭配。

须知

• 推送属于 Builder 和 Pro 套餐，每个账号同一时间在 Builder 上可打开一个订阅，在 Pro 上最多可打开三个。
• 需要采用 2026-07-28 协议的 MCP 客户端。这个资源本身在所有套餐上都可以读取。
• 在 Free 和 Builder 套餐上，subscriptions/listen 会返回一个错误，其中列出其他获知回复的方式，智能体可以直接切换，不用猜。