Agent 不是 API 路由:Trigger.dev 把聊天循环搬进耐久任务1×0:007:040:08开场0:44事件播报1:36技术拆解4:07工程意义5:43落地建议6:31收尾0:08主播先说明今天的覆盖范围。过去二十四小时里,我没有找到足够支撑单主题深挖的一手 Agent 工程更新,所以本期把窗口放大到近一周。选中的事件是 Trigger.dev 在七月二日发布 v4.5.0,并宣布它的 AI Agents 平台进入 GA。0:26主播这件事听起来像一个 SDK 更新,但对 Loop Engineering 更有意思的地方在这里:Trigger.dev 明确把聊天 Agent 从一次 API 请求,改成一个按 chatId 绑定的长任务。对工程团队来说,Agent 循环第一次有了更像后台工作流的运行骨架。0:44主播据 Trigger.dev 的 v4.5.0 release note,这次稳定下来的核心包括 chat.agent、Sessions 和 AI Prompts。chat.agent 可以把 Vercel AI SDK 的聊天补全跑成耐久任务;一段对话对应一个长生命周期 task,客户端刷新、断线、重新部署、空闲超时,甚至运行崩溃后,都可以从上一个 chunk 继续接上。1:12主播release note 还给了几个关键点:每个 turn 会在 dashboard 里形成 span;Sessions 是底层的双向流通道;AI Prompts 可以在部署时自动版本化,也能在 dashboard 里覆盖提示词或模型;人类审批、停止生成、运行中 steering、上下文注入,都放进同一套聊天循环里。1:36主播Trigger.dev 的 AI Agents 文档说得更直白:AI chat 不是一个 request,而是一个 session。这个定义很重要。很多团队现在的聊天 Agent 仍然挂在 HTTP route 后面,前端发消息,后端开一个流,模型开始输出。只要页面刷新、服务重启、部署切版本,开发者就要自己补状态、补断点、补重连。2:00主播Trigger.dev 的做法是把循环的身份放在 Session 上,而不是放在某一次 run 上。Sessions 文档里说,一个 Session 可以跨过多个 run;run 只是做活的执行实体,Session 才是客户端持续读写的对象。输入流接用户消息,输出流回传文本、reasoning、tool call 和自定义数据。run 挂了,下一条输入可以唤起新的 run,流继续沿着同一个会话往前走。2:27主播这会改变 Agent 可靠性的分工。过去我们常把恢复能力写在业务代码里,比如自己存 messages,自己记 cursor,自己处理 SSE 的 last event id。现在平台把这些能力变成运行时职责:空闲时挂起释放计算,下一条输入再唤醒;部署升级时换到新版本;客户端只面对同一个 chatId,不需要知道底下换过几次 worker。2:54主播再看 human-in-the-loop。Trigger.dev 的文档描述了一个很实用的模式:当模型调用一个没有 execute 函数的工具时,streamText 会带着 pending tool call 结束这一轮。前端渲染问题和选项,用户回答后,下一轮把结果合并回同一条 assistant message。等待期间 run 会 suspend,人的思考时间不计入 maxDuration,也不占着计算。3:19主播这不是 UX 小功能,它是 Agent 安全边界的一部分。需要确认退款、批准写操作、选择执行方案时,Agent 不应该假装自己可以一路跑完。它要能停下,留下一个可恢复的暂停点,把人的回答接回原来的消息链,再继续完成任务。审批如果只靠聊天文本约定,迟早会漏;审批如果是运行时状态,才有机会被审计。3:44主播AI Prompts 也是同一个思路。Prompts 文档说,模板写在代码里,部署时自动版本化;运行时可以解析到具体版本、模型和配置;每次 generation 能关联回 prompt 版本,并看到 token、成本和延迟。对团队来说,这相当于把提示词从一段散落在代码里的字符串,变成可追踪的配置对象。4:07主播把这些点放在一起看,Trigger.dev 这次更新真正处理的是 Agent 循环的生命周期。第一层是对话生命周期:消息不是一次请求的附属品,而是一个可以跨运行边界延续的会话。第二层是执行生命周期:任务可以暂停、恢复、重启、升级。第三层是治理生命周期:提示词、工具调用、审批和成本都能回到 trace 或版本记录里。4:34主播这对产品团队有一个直接提醒:如果你的 Agent 会连续工作几十秒、几分钟,或者需要用户中途确认,它就不再适合只挂在一个普通接口后面。接口可以启动循环,但不能代表循环本身。循环需要身份、状态、超时策略、恢复点、审计线索和人为介入的协议。4:56主播当然,Trigger.dev 不是在替你判断 Agent 该不该调用某个工具,也不会自动解决提示词质量。它提供的是运行骨架。骨架搭起来以后,团队仍然要设计工具权限、状态校验、失败重试和成本上限。换句话说,它把一部分样板活拿走了,但没有替工程团队做架构判断。5:19主播我更在意的是它把几个常被拆开的东西放到一起:流式输出、长任务、审批、prompt 版本、span 观测。很多 Agent 项目失败,不是因为模型不会回答,而是因为这些东西分别落在前端、后端、队列、数据库和日志系统里。出了问题以后,没人能还原当时到底走了哪条路径。5:43主播如果你的团队已经在做聊天型 Agent,可以先问四个问题。第一,一段对话的稳定身份在哪里,是浏览器连接、数据库行,还是一个可恢复的 Session。第二,模型中途需要人确认时,暂停点有没有被结构化记录。第三,提示词改动能不能追到具体版本和成本。第四,客户端断线或部署重启后,流能不能从安全位置继续。6:08主播如果四个答案里有两个还不清楚,就别急着加更多工具。先把循环收束成一个可运行、可恢复、可观察的单元。Trigger.dev v4.5.0 给了一个参考答案:聊天循环可以长在任务系统里,Session 负责身份,run 负责执行,prompt 和 span 负责把变化留下来。6:31主播今天可以带走的判断是:Agent 工程正在从「让模型多做一步」转向「让每一步都有运行语义」。一个会暂停、会恢复、会留下 trace 的 Agent,不一定更聪明,但更容易被团队接进生产系统。下次评估一个 Agent 平台时,不妨先看它怎么处理中断、审批和版本,而不是先看它包了多少模型。