0:00 / --:--
Chain of Thought · 10 月 14 日
Tom Hacohen 认为，智能体首先放大 webhook 的实现差异和文档维护负担，其次因本地运行、临时订阅而需要可续取事件的轮询端点，而标准化验证、技能文件测试和拒绝复杂度叠加是应对之道。
当 AI 智能体（Agent）成为事件的接收者和集成代码的编写者，传统 webhook 的断线重试、订阅范围与开发者文档问题会被放大；Svix 的答案是让事件可续取、让验证有标准，同时保持系统简单。
这集还没有学习卡。生成后会保存在这一集，下次直接打开。
Latent Space· 2026-10-28为什么 AI 智能体喜欢 SupabaseWhy Agents Love Supabase内容相近
a16z Show· 2026-10-21AI 智能体缺失的基础设施：文档｜Reducto 的 Adit AbrahamThe Missing Infrastructure for AI Agents: Documents | Reducto’s Adit Abraham内容相近
No Priors· 2026-10-23与 Cloudflare CTO Dane Knecht 谈智能体网络的安全民主化Democratizing Security for the Agentic Web with Cloudflare CTO Dane KnechtChain of Thought
What Breaks When Agents Become the Customer | Svix CEO Tom Hacohen
YouTube
音频
Webhook 让服务在事件发生时，主动向另一端发送通知。它看似只是一次 HTTP 请求，实际投入生产后却涉及签名验证、失败重试、事件顺序、投递状态，以及接收方是否始终在线。Svix 将这套能力作为基础设施提供给其他公司。
本集的变化在于“客户”不再只是常驻云端的服务。智能体可能运行在会合盖的笔记本电脑上，也可能临时为某项任务订阅事件；它还可能自行阅读文档、编写集成代码。Tom 因此从 webhook 的老问题出发，讨论哪些约定仍然适用，哪些必须重新设计。
这集最有价值的区分，是“智能体增加了集成数量”与“智能体改变了集成的接收方式”并非同一件事。前者使 webhook 原有的实现分歧、签名方案和维护负担进一步累积；后者则直接撞上推送模型的前提：接收端要有稳定、可访问的地址。笔记本合盖后，本地转发隧道随之断开，提供方只能重试；重新上线时，过期事件可能集中涌来。Tom 提出的轮询端点并不是否定 webhook，而是让间歇在线的接收者按上次位置续取事件。
他对标准的态度同样务实。Standard Webhooks 首先试图缩小签名与验证的实现差异，而不是一次规定事件系统的所有行为；未来功能也应跟随真实需求。与此同时，智能体能适应变化中的工具接口，令 SDK 不再必然是集成的入口，但自动重试等经过打磨的行为并不会因此自动出现。面向智能体的技能文件可以承担“解决方案工程师”式的引导，却也会过时，需要测试和维护。
贯穿全场的是 Tom 对复杂度的警惕：代码生成更便宜，不等于系统更容易理解。Svix 新公布的 Poke 规范试图为跨服务订阅和长耗时异步任务提供更简单的事件接口；它仍处早期，能否成为通用做法尚待实践。节目因而不是宣告 webhook 已失效，而是在问：当使用者变得更动态、更大量、更不常在线，旧基础设施如何保住可靠性而不叠出又一层补丁。
💬 他们说了什么：Tom 认为，REST、JSON 和 HTTP 已让今天的集成比各家自定义 TCP 协议的年代容易得多；但连接越容易建立，连接的总量也越大。他借用杰文斯悖论解释这种反差：接入 10 个系统与接入 1000 个系统，遇到的特殊实现不是同一量级。他甚至认为，现实中几乎找不到两个完全相同的 webhook 实现。
💡 为什么重要：基础设施的难点不一定来自单次请求，而是海量接收方带来的差异。减少允许的实现方式，可能比继续优化某一个实现更能降低整个生态的集成成本。
⚡ 争议点：“集成越容易、总工作越多”是有解释力的判断，但本集没有提供集成数量或维护成本的系统数据；它也不能说明每家公司都会遇到相同的规模问题。
💬 Tom 在此前的端到端加密同步产品 EteSync 中不断收到 webhook 需求，却发现认真构建和维护这项功能会占用过多资源。后来，一位朋友只想“发出 webhook，不用操心背后的事”，并表示愿意付费；另一个潜在用户也提出同样需求。产品在 Hacker News 发布后，同时收到了“这不值得做”和“我们正需要它”的反馈。面对 webhook 是否是糟糕基础原语的质疑，Tom 借 JSON 说明“较差但好用”的技术为何会普及：它未必优雅，却足以让大量人完成工作。
💡 Svix 的创业判断不是 webhook 技术多先进，而是大量团队都需要它、却不愿各自经营一套可靠投递系统。Tom 将 webhook 比作固定街边镜子的胶带：不完美，但能用。
⚡ “够用”不等于无需改进。兼容性让 JSON 等通用格式难以迭代，webhook 也可能因沿用已久而留下安全与维护负担；指出它有商业价值，并未回答所有替代方案的取舍。
💬 Tom 提出事件与主动调用 API 的关键差别：API 调用方可以选择版本或请求内容，而事件通常由发送方决定何时发送、发送什么。事件还可能在当前会话之外异步产生；接收方不知道它何时抵达，也可能收到上一次会话遗留的事件。若接收方是运行在笔记本或其他短暂环境中的智能体，传统接收方式便更不合适。
💡 智能体处理事件，不只是“给模型一个 webhook 地址”。设计者还须回答事件属于哪个任务或会话、订阅应持续多久，以及智能体暂时不在线时由谁保管事件。
⚡ 发送方主导是常见 webhook 的特征，不代表所有事件系统都缺乏过滤、版本或订阅控制。Tom 描述的是当前集成中的主要摩擦，而非异步事件不可解决的固有缺陷。
💬 本地智能体常借助 ngrok、Cloudflare Tunnel 等工具，把云端请求转发到笔记本。合盖后，本地服务和转发通道可能断开；提供方持续重试，最终仍可能投递失败。Tom 举例说，用户重新开盖时可能迎来 12 小时前事件的集中重试。Svix 约在 3 年前推出轮询端点：接收方保存上次取到的位置，恢复运行后从那里继续拉取遗漏事件；面向 Hermes 和 OpenClaw 的集成则采用了类似的适配方式。
💡 对间歇在线的接收者，“能从断点继续”比“始终能接收推送”更符合实际。由智能体主动通过出站 HTTPS 获取事件，也避免了为每台本地设备长期维持可访问的入站地址。
⚡ 轮询改善断线体验，不会自动解决重复事件、保留期限、顺序和消费进度持久化等问题；它还可能引入轮询频率与延迟之间的权衡。
💬 Tom 区分两类集成：大型平台之间预先配置的固定连接，可能仍按旧方式工作；智能体临时接入更多服务时，则需要自行决定订阅哪些事件、订阅多长时间，以及回调对应哪个会话。主持人进一步提出“互联网长尾”问题：学校等机构未必很快提供面向智能体的 API，浏览器操作仍会重要。Tom 回应称，技术前沿企业的经济活动更可能经由 API 与 webhook；他也回忆自己曾解析一家运动课程网站，再把内容转换成 JSON 供自制应用使用。
💡 不能把“智能体使用互联网”误写为“所有网站马上都会提供 API”。结构化接口、浏览器操作及针对旧网站的适配，很可能长期并存。
⚡ Tom 关于“大部分智能体经济价值将经由 API 与 webhook”的判断是预测，不是节目中得到量化验证的结论；旧网站能被技术性解析，也不等于其数据可以稳定或合规地被使用。
💬 Tom 说，Svix 推动 Standard Webhooks，首先是因为各家 webhook 的差异给接收工具 SvixIngest 带来持续集成成本。统一约定后，Kong、ngrok 这类工具才更容易提供通用的 webhook 验证能力。标准也给 Svix 带来直接好处：过去销售沟通中，有大量时间花在解释客户自创签名方案的安全问题上；现在可以引用共同规范和已发布的多语言库。他特别澄清，节目提及的 OpenAI 并非当时的 Svix 客户。
💡 标准的作用不只是方便发送方，也让接收端与中间工具有机会复用验证逻辑。它降低的是整个连接链条的差异成本。
⚡ 采用同一标准不等于所有 webhook 行为一致，也不意味着使用相关规范的公司购买了 Svix 产品。签名验证之外，重试、事件语义与运行保障仍须分别评估。
💬 Standard Webhooks 设有委员会，Tom 表示重要讨论尽量公开进行，外部贡献者也可以通过 GitHub 参与文档、网站与兼容库建设。路线选择上，他主张观察已经出现的需求并“快速跟随”，而非先在会议室里设计一套包罗万象的规范。他举 MCP 拟加入 webhook 支持为例：相关讨论提出一种用于确认接收方知晓密钥的挑战响应检查；Tom 认为并非所有 webhook 都需要它，但标准可能因实际需求而扩展。
💡 这种治理方式为新需求留下入口，也避免过早把尚未验证的设计固定下来。对建设集成的团队而言，公开讨论比单纯等待版本号更能透露可能发生的变化。
⚡ 节目谈到的 MCP 支持和规范扩展属于当时的讨论或计划，不宜视为已经正式发布的功能；“快速跟随”也要面对不同使用场景提出相冲突要求时的取舍。
💬 Tom 认为，智能体比人更能适应变化中的 API 或工具定义，因此原先很难改变的接口或许可以更快迭代。他由此提出一个试探性问题：智能体能自行拼装集成代码，SDK 是否仍是必需品？他的限定很明确——人类仍从 SDK 获益；Svix SDK 中的自动重试等行为，也未必会被智能体自行实现，更未必实现得兼容。MCP 则展示了较动态、不依赖传统 SDK 的另一种集成路径。
💡 接口设计的重心可能从“为人提供固定语言封装”，部分转向“让智能体理解能力、约束和正确行为”。但生成调用代码，与获得经过测试的可靠性机制，是两回事。
⚡ “SDK 不再是阻碍”不等于“应该删除 SDK”。当认证、重试或错误处理有细微约束时，缺少成熟库可能把复杂度转移给每一个智能体生成的实现。
💬 Svix 为智能体提供技能文件，但 Tom 坦言它们曾经过时，团队不得不修复。他希望加强评测：让智能体持续尝试集成任务，观察修改后是否更容易成功。内容分工上，API 参考文档定义接口，人类文档解释用法；技能文件则引用两者，并补充条件式指导，例如先询问用户要走哪条集成路径，再检查现有代码是否匹配。
💡 技能文件不只是把文档换个格式，而可以把解决方案工程师的判断流程写给智能体。不过，流程一旦与产品行为脱节，就可能持续指导智能体犯错。
⚡ 让智能体反复试用能够发现部分故障，却不能替代明确的真实来源、版本管理和人工审查。节目也没有提出一套已经解决“技能过时”的完整方法。
💬 Tom 担忧，智能体大量产出代码后，团队可能依靠另一些智能体审查、修补文档和监控错误，最终在补丁上叠补丁，而不是退一步简化设计。他引用朋友的类比：过去有人因为离岸开发成本较低而增加人手、增加代码，如今也可能因为生成成本低而增加产量。但他不确定结果会完全相同，因为智能体的可扩展规模更大。主持人则分享了用定期检查来减少文档与代码漂移的实践。
💡 交付速度、代码量与系统可理解性是不同指标。若每个新增检查器只是在维护更多复杂度，技术债仍可能增长；Tom 主张即使采用智能体式开发，也应主动追求更少、更清晰的代码。
⚡ 智能体同样能承担重构与清理工作，技术债是否净增长并无定论。节目提供的是值得警惕的机制和个人经验，而不是对所有“软件工厂”的实证结论。
💬 Svix 新公布的 Poke 旨在让智能体更容易跨服务订阅事件，并触发、接收异步工作的结果。Tom 对比了可能在 10 或 100 毫秒量级返回的普通 API 与需要 4 小时才能得到结果的委派任务：后者需要更合适的事件交接方式。他强调 Poke 非常早期，产品尚未完整成形，先公开规范是为了在仍可调整时收集反馈；其思路来自 AgentMail 集成、轮询端点与 Standard Webhooks 等既有工作。谈到当前客户价值，他举 Clerk、Resend 等例子，强调让客户把精力留给自身产品，而不必反复维护 webhook 基础设施。
💡 Poke 所瞄准的不是“把 webhook 改个名字”，而是长期、异步、可临时订阅的任务如何跨服务交接。Tom 希望在使用模式尚未固化时，先让正确做法足够简单。
⚡ Poke 的采用范围和最终接口形态还无法从本集确认；客户节省时间、无需再操心 webhook 等效果主要来自嘉宾陈述。由于 Svix 赞助本集，产品成效尤其适合结合独立案例核实。
“She just wanted to send webhooks and not have to think about it.” 她只想把 webhook 发出去，不必再为背后的机制操心。——Tom，谈 Svix 的起点
“Maybe webhooks are duct tape.” 也许 webhook 就像胶带。——Tom，谈不完美但实用的基础原语
“Maybe we don't need SDKs anymore. No idea.” 也许我们不再需要 SDK 了——我也不知道。——Tom，强调这仍是开放问题
“Even with agentic flows, you can aspire to have simplicity.” 即便采用智能体式工作流，仍可以追求简单。——Tom，谈代码生成与复杂度
本文时间戳依据所给英文转写标注；关于产品状态、客户效果及未来计划的表述，按访谈内容归属于发言者。
