Agent 里的 Webhook 是什么先说一句话定义:Webhook 是一种反向 API——不是你主动去问对方有事没有而是对方一有事就主动打电话给你。先理解普通 API 和 Webhook 的区别假设你想知道我的订单发货了没。普通 API(轮询):你每隔几秒就问一次服务器发货了吗?发货了吗?发货了吗?“。绝大多数时候答案是还没”白问了,浪费资源。Webhook(回调):你提前告诉服务器等发货了,打这个电话号码通知我。然后你就该干嘛干嘛。一旦真发货了,服务器主动往你留的那个地址一个 URL发一条 HTTP 请求把消息推给你。所以 Webhook 本质就是:你提供一个 URL别人在特定事件发生时主动往这个 URL 发数据。在 Agent 场景里Webhook 通常扮演两个角色角色一:外部世界叫醒Agent 的入口Agent 很多时候不是一直在跑而是事件驱动的——有事才动。Webhook 就是那个触发开关。举几个例子:GitHub 上有人提了个新 Issue → GitHub 往你的 Agent Webhook URL 发一条消息 → Agent 被唤醒,自动分析这个 Issue、打标签、甚至尝试修复。用户在 Slack 里 了机器人 → Slack 通过 Webhook 把消息推给 Agent → Agent 开始处理并回复。监控系统发现服务器报警 → Webhook 触发 → Agent 自动开始排查。外部事件发生 │ ▼ 外部系统 ──HTTP POST──► 你的 Agent 的 Webhook URL │ ▼ Agent 被唤醒,开始干活角色二:Agent 干完活后通知外部世界反过来也一样。有些任务耗时很长比如跑一个大分析你不可能让调用方一直挂着等。这时:调用方发起任务时顺便留一个 Webhook URL。Agent 慢慢跑跑完了。Agent 主动往那个 URL 发一条任务完成结果在这里。这就避免了调用方傻等或反复轮询。一个具体的数据长什么样外部系统触发 Agent 的 Webhook,发过去的一般是一段 JSON,大概长这样:POSThttps://my-agent.com/webhook Content-Type:application/json{event:issue.created,repository:my-project,issue:{number:42,title:登录页面在 Safari 上崩溃,body:点击登录按钮后白屏……}}Agent 这边收到后,解析event知道发生了什么再根据内容决定接下来调用哪些工具去处理。一个非常重要的安全提醒Webhook 是一个对公网暴露的入口——任何知道这个 URL 的人都能往里面发请求。如果不加保护等于给你的 Agent 开了一扇没锁的门:别人可以伪造事件骗 Agent 去执行操作。结合我们前面聊的提示注入攻击者可以在 Webhook 的内容里比如那个 Issue 的body字段夹带恶意指令。所以 Webhook 接收端通常要做两件事:验签:发送方用一个共享密钥对内容签名,你这边校验签名,确认这条消息确实来自可信来源不是伪造的。把内容当不可信数据处理:Webhook 送来的所有文本(标题、正文等)都是外部输入,不能直接当成给 Agent 的可信指令。这正好呼应我们之前讲 Sidecar 时那个逻辑——外部内容里夹带的话术不能被当真。和前面 Sidecar 的联系Sidecar 机制给 AI Agent 挂一个并行的安全边车可以串起来看:Webhook是外部事件进Agent 的入口。进来的内容是不可信的可能藏着攻击。Agent 处理时决定执行工具调用。Sidecar在工具真正执行前做门控拦住危险操作。一个管怎么进来一个管进来之后想乱动手时怎么拦住正好是一前一后两道关。后记2026年8月10日于上海在claude opus 4.8辅助下完成。