Event-Driven Loop1、引言2、Event-Driven Loop 到底解决什么问题3、Event-Driven Loop 核心原理3.1 Event Bus所有外部世界的门铃3.2 三个必须背下来的工程约束4、生产级实现FastAPI Durable Workflow LangGraph5、2026 年的关键改进点5.1 从HTTP 调一下到 Durable Execution5.2 幂等与 Outbox别让 Agent 重复发邮件5.3 Human-in-the-Loop高风险动作先等人点头6、适用场景与性能基准7、总结1、引言小屌丝鱼哥我那个 Agent 现在可猛了——写东西能自己改数字不对能自己审我用着贼顺手。小鱼那它一天能帮你干多少活小屌丝嗯……基本就我上班的时候我戳它一下它动一下。我下班关了浏览器它就跟死了一样。我让它盯着 GitHub 上那个 issue有人提就自动复现一下结果第二天我一看——昨晚三点有人提 issue它压根没理人家。小鱼废话你把它当博客客服养呢它又不会自己睁眼。你得让它被事情叫醒。小屌丝被事情叫醒啥意思小鱼就是 Event-Driven Loop。Webhook 来了、Cron 到点了、Slack 有人 你、Email 进了收件箱、GitHub 新建了一个 issue——这些外部世界的动静全部进到一个事件总线Agent 监听这些事件自己爬起来干活干完还能把结果写回数据库、回个 PR、发个通知。你不戳它它也在跑。小屌丝听着美好。但我上次自己写了个 FastAPI 接 webhookAgent 跑到一半服务重启了结果一封确认邮件给客户发了三遍……小鱼点头这就是为什么这一篇要讲三个工程约束——幂等、持久化、人审。不把这仨搞明白你的 Event-Driven Agent 不是自动员工是自动事故制造机。2、Event-Driven Loop 到底解决什么问题对应素材里的循环 3事件源谁在敲门 总线 Agent 动作写回真实世界 ───────────── ────────── ────────── ────────────── Webhook ┌──────────┐ Cron 定时任务 │ │ Slack 消息 ───▶ │ Event │ ───▶ Agent ──▶ 数据库 Email │ Bus │ (执行任务) 文档系统 GitHub issue/PR │ │ GitHub PR 监控告警 └──────────┘ 通知系统 ... 其他服务它跟前两层 Loop 的本质区别维度Agent LoopVerification LoopEvent-Driven Loop谁触发用户一句话生成完自动审外部世界任何事件Agent 是主动还是被动被动响应一次请求被动响应一次请求7×24 常驻事件来了自动起状态活多久一个请求内一个请求内跨小时、跨天、跨服务失败语义重跑就行重跑就行必须保证不重不漏、不重复写典型场景查天气写周报出稿前自审自动处理工单、监控告警、PR 机器人一句话总结Event-Driven Loop 事件总线 常驻 Agent 持久化执行 写回外部系统让 Agent 从你问它才答变成世界动它就动。3、Event-Driven Loop 核心原理3.1 Event Bus所有外部世界的门铃事件源在 2026 年基本就这几类WebhookGitHub、Stripe、Shopify、内部系统回调Cron / Scheduler每天早上 9 点拉昨日报表、每周一汇总周报IM 消息Slack / 飞书 / 企业微信群里被 Email收件箱来了新邮件分类并起草回复数据变更数据库 binlog、CDC、消息队列Kafka / Redis Stream。它们全部归一化成一个事件{event_id:evt_01J9X...,event_type:github.issue.opened,source:github,occurred_at:2026-09-27T15:02:11Z,payload:{repo:acme/web,issue_number:123,author:xxx},idempotency_key:github-issue-opened-123}Agent 订阅自己关心的event_type来了就起一次执行。注意idempotency_key这个字段下面会反复用。3.2 三个必须背下来的工程约束事件驱动跟你在 Jupyter 里跑一个 notebook 最大的不同是你不知道进程什么时候会死、消息会不会被投两次、写外部系统会不会写一半崩了。所以三件事必须从第一天就设计进去At-least-once 投递绝大多数消息系统保证至少投一次不保证只投一次。所以 Agent 对同一个事件可能被唤起两次必须自己幂等。Durable Execution持久化执行一个 Agent 任务可能要跑 5 分钟、30 分钟期间你发版重启、容器被杀任务得能从断点继续不能从头再来。副作用要可回滚 / 可重试Agent 要回 GitHub 评论、要发邮件、要写数据库——这些动作失败了要能重试但重试不能重复发。这三件事不解决Event-Driven Agent 上线第一天就会给你惊喜重复邮件、重复 PR、重复扣款。4、生产级实现FastAPI Durable Workflow LangGraph下面这套用一个轻量 durable workflow 引擎的思路2026 年主流选择是 Temporal、Inngest、Restate下面用伪代码风格写重点在结构# event_driven_loop.pyfromfastapiimportFastAPI,Request,HTTPExceptionfrompydanticimportBaseModelfromtypingimportAnyimporthashlib,hmac,json appFastAPI()# 一个最简单的已处理事件表生产里用 Redis/PostgresPROCESSED_EVENTS:set[str]set()classEvent(BaseModel):event_id:strevent_type:stridempotency_key:strpayload:dict[str,Any]# ---------- 1. Webhook 入口验签 幂等 ----------app.post(/hooks/github)asyncdefgithub_hook(req:Request):bodyawaitreq.body()sigreq.headers.get(X-Hub-Signature-256,)# 验签防伪造请求打进来ifnotverify_github_signature(body,sig):raiseHTTPException(status_code403)dataawaitreq.json()eventEvent(event_iddata[delivery],event_typefgithub.{data[action]},idempotency_keyfgithub-{data[action]}-{data[repository][id]}-{data[issue][number]},payloaddata,)# 幂等同一个 key 处理过就直接 ACK别再唤起一次 Agentifevent.idempotency_keyinPROCESSED_EVENTS:return{status:duplicate_ack}# 扔给 durable workflow 去跑Webhook 立刻返回别让 GitHub 等你enqueue_durable_workflow(handle_github_issue,event.model_dump())return{status:accepted}# ---------- 2. 真正的 Agent 工作流durable每一步都会被持久化 ----------asyncdefhandle_github_issue(event:dict):frommy_agentimportbuild_issue_agent# 第 1 篇那个 Agent Looprepoevent[payload][repository][full_name]numberevent[payload][issue][number]# 步骤 A拉 issue 正文 相关代码durable失败自动重试这一步issue_bodyawaitgithub_get_issue(repo,number)# 步骤 B跑 Agent Loop让它做初步复现 / 分类agentbuild_issue_agent()diagnosisawaitagent.ainvoke({issue_body:issue_body,repo:repo,})# 步骤 C高风险动作——自动改代码前先等人点头HITLifdiagnosis[should_open_pr]:awaitwait_for_human_approval(timeout24h,messagefAgent 建议给{repo}#{number}开个修复 PR是否批准,)# 步骤 D批准了再写 GitHub用幂等 key 防止重复 PRawaitgithub_create_pr(reporepo,titleffix:{diagnosis[title]},bodydiagnosis[pr_body],idempotency_keyfpr-{repo}-{number},)# 步骤 E不管改不改都回个评论告诉提 issue 的人我们看了awaitgithub_comment(reporepo,numbernumber,bodydiagnosis[initial_comment],idempotency_keyfcomment-{repo}-{number},)# ---------- 工具函数示意 ----------defverify_github_signature(body:bytes,sig:str)-bool:...defenqueue_durable_workflow(name:str,payload:dict):...asyncdefgithub_get_issue(repo:str,number:int):...asyncdefgithub_create_pr(**kw):...asyncdefgithub_comment(**kw):...asyncdefwait_for_human_approval(**kw):...关键设计点Webhook 入口只做验签 幂等 入队立刻返回真正的 Agent 跑在 durable worker 里每个外部写操作评论、开 PR都带idempotency_key重试不会重复写高风险动作改代码、开 PR中间插一个wait_for_human_approvaldurable workflow 会把状态挂起人在 Slack 上点个批准第二天回来它接着跑。5、2026 年的关键改进点5.1 从HTTP 调一下到 Durable Execution2024 年写 Event-Driven Agent典型姿势是 FastAPI Celery Redis。问题worker 挂了任务就丢了重启后不知道跑到哪一步要自己写一堆 checkpoint。2026 年的标准是Durable Execution 引擎Temporal / Inngest / Restate / 云厂商 Step Functions你写的就是普通的async def函数但每一步的返回值都被自动持久化进程挂了worker 重新起来后从最后一个完成的步骤继续长等待比如等 24 小时人审批不占任何进程状态存在引擎里自带重试、超时、超时报警、可视化 timeline。对 Agent 场景的好处是一个跑了 20 分钟的多步 Agent 任务你半夜发版重启它不会丢。这件事在 2024 年要自己写几百行才能做到。5.2 幂等与 Outbox别让 Agent 重复发邮件事件驱动最经典的事故就是客户凌晨收到三封一模一样的确认邮件。根因就一个消息系统 at-least-onceAgent 自己不幂等。工程上两个套路Idempotency Key每个外部副作用带一个业务主键比如comment-{repo}-{issue_number}写之前先查一遍有没有写过Transaction OutboxAgent 决定要发邮件这件事先把事件写进本地 outbox 表和业务事务一起提交再由独立进程投递。这样Agent 状态和外部副作用不会出现一个成功一个失败。一句话凡是 Agent 对真实世界的写操作都要假设它会被调用两次。5.3 Human-in-the-Loop高风险动作先等人点头Event-Driven Agent 最危险的不是不干活是自己把活干了——比如它自己判断这个 bug 必须紧急修复就直接 merge 了 PR、给客户发了退款邮件、在生产库删了一张表。2026 年的分层做法动作风险处理方式只读查数据、拉日志、写草稿全自动直接干低风险写回个 issue 评论、写文档自动干事后通知中风险写开 PR、发客户邮件自动起草等人点批准高风险写merge、退款、删数据、发钱必须人审拒绝自动执行Durable workflow 的wait_for_human_approval就是为这个设计的——任务挂起、状态持久化、审批通过后自动续跑。6、适用场景与性能基准场景推荐度说明GitHub / GitLab 机器人issue 分类、PR 初筛⭐⭐⭐⭐⭐天然事件源价值立刻可见工单 / 客服自动分诊⭐⭐⭐⭐⭐高频、低风险写、事件驱动定时报表 / 晨间摘要⭐⭐⭐⭐⭐Cron 是最简单的事件源监控告警自动诊断⭐⭐⭐⭐配合 Verification Loop 才敢自动处理自动下单 / 自动退款 / 自动发钱⭐⭐必须人审风险高毫秒级在线交易⭐事件队列 LLM 延迟扛不住一组 2026 年参考数字单事件端到端延迟从 webhook 到 Agent 产出5–30 秒单事件成本$0.02 – $0.10取决于 Agent 步数幂等重复率真实生产里消息重复投递比例约0.1%–1%必须处理Durable workflow 任务平均时长几十秒到几十分钟HITL 审批平均等待几小时靠异步挂起不占资源自动处理率成熟系统能做到70%–85%事件全自动闭环剩下转人工。7、总结Event-Driven Loop 把 Agent 从等你戳的聊天机器人变成7×24 盯着世界的数字员工。但它也是四层 Loop 里最容易出生产事故的一层——因为它真的在写真实世界。核心记忆点事件源千奇百怪归一化成一个 Event 结构再进总线At-least-once 是默认现实所有外部写操作都要幂等用 Durable Execution 引擎别自己写 checkpoint高风险动作必须 HITL全自动不是目标敢放手才是Webhook 入口要薄验签、幂等、入队剩下的交给 worker这套跑稳了你就拥有了一个不用睡觉的实习生——然后下一篇我们讲怎么让它自己把自己变得更聪明。我是小鱼CSDN 博客专家AIGC 技术MVP专家阿里云 专家博主51CTO博客专家企业认证金牌面试官多个名企认证特邀讲师等名企签约职场面试培训、职场规划师多个国内主流技术社区的认证专家博主多款主流产品(阿里云等)评测一等奖获得者关注小鱼学习【人工智能与大模型】最新最全的领域知识。