AI 执行服务怎么搭：任务调度中枢拆解

📖 摘要：在「Dify 编排发起 + 外部 Agent 真执行」的链路里，中间有一个我们自研的轻量服务——约 160 行、零第三方依赖。它不执行任何业务动作，却是整套 AI 应用交付链路里最不能少的一环：任务秒级受理、状态全程跟踪、失败绝不悬空、高危默认拒绝。本文拆开这个「调度中枢」：为什么中间必须有一层、它的五个职责各自怎么实测、以及 160 行的秘密——职责收敛。适合正在评估「让 AI 执行真实任务」架构的交付方。

一、场景：被问得最多的问题

做 AI 真执行演示和交付时，有一个问题被问得最多，几乎每次都会被提出来：

「你们写的那个执行服务，到底是干嘛的？160 行，能干什么？」

问的人往往刚看完架构图——图上有三个框：Dify 流程、执行服务、Agent。前两个框好懂：Dify 是编排平台，Agent 是能干活的执行体。中间那个框最可疑：一个自研的、160 行的、零依赖的小服务——夹在两边中间，看起来像是可有可无的胶水。

这篇文章正面回答这个问题。先说结论：执行服务不执行任何业务动作——它不干活。它管的是「活怎么被派出去、干到哪一步、干完怎么交代、出事了怎么收场」。 用组织打比方，它是执行层的调度室：管理层（Dify 审批流程）批完单子投进来，调度室收单、盯进度、安排汇报——工人（Agent）负责真干活。

二、为什么中间必须有一层

先回答「为什么不让 Dify 直接调 Agent，中间非要加个服务」。三个结构性的原因，不是偏好：

1. 同步与异步的断层。 Dify 的 HTTP 节点是同步世界——发请求、等返回。Agent 真执行是另一套时间尺度——简单任务 8 到 15 秒，深度任务一分钟起。让用户的表单流程同步等一两分钟，体验和稳定性都不可接受。实测最早的同步通道就是这样：简单问答能回来，任务一拉长就挂。

2. 任务状态需要一个「活着的地方」。 任务跑到一半——执行中、等结果、已失败——发起它的那次流程早就结束了。任务现在什么状态、走到哪一步、结果在哪，必须有一个服务持续持有。否则就是「发出去就忘了」——这在真实交付里是要命的事。

3. 闸门需要一个咽喉位置。 安全闸门（高危任务拦截）要拦在任务执行的必经点上——Dify 的投递只有一条路进来，闸门挂在路上才拦得住。直连模式下没有这个位置，Agent 就变成了「裸奔的执行体」。

三、它做什么：五个职责，逐个拆

执行服务的全部职责收敛成五个：投递接收、任务状态机、转交执行、双态回写、兜底与闸门。逐个说：

① 投递接收——秒回，流程不阻塞。 Dify 流程把任务包投过来，执行服务立即回一个「任务已受理 + 任务 ID」，流程当场结束，用户不用等。实测：表单提交到受理返回 0.6 秒。

② 任务状态机——盯全程。 每个任务从受理开始就进入状态跟踪：submitted（已受理）→ running（执行中）→ completed（已完成）或 failed（已失败）。执行服务轮询 Agent 的执行状态，任何时刻问它「这个任务到哪一步了」，它都答得出来。

③ 转交执行——派活。 把任务描述提交给 Agent 执行（异步提交，202 即返执行 ID），失败自动重试（实测配置 3 次、间隔 10 秒），覆盖网关瞬断这类窗口。

④ 双态回写——交代。 任务到终态后，无论成功失败，都回调 Dify 的收口流程。这一点是交付可信度的底线：失败信号必须回到确定性流程，否则任务就会无声悬空——表单显示「已提交」，实际永远没人知道结果。

⑤ 兜底与闸门——收场与放行。 兜底：执行超时先停掉孤儿执行（释放执行侧资源）再走失败回调，不允许任务悬空。闸门：任务投递先过高危模式库（删除/格式化/清库/关机重启类），命中默认拒绝——Agent 零接触；要放行必须显式授权。实测双向验证过：默认提交破坏性任务返回拦截，带授权标记后放行真执行。

四、一单任务的一生

把五职责串起来看一遍，比逐个记更直观。一单「发布前巡检」任务从提交到结果送达的完整旅程：

这条链路上，执行服务出现在每一个「不能断」的位置：受理（不能让流程阻塞）、盯执行（不能不知道进度）、收结果（不能让结果丢）、回写（不能让失败悬空）。任务 ID 贯穿全程——发起流程的单号、执行服务的任务 ID、Agent 的执行 ID、收口流程的记录——任何一环出问题，顺着 ID 链就能定位到具体环节。

五、它不做什么：160 行的秘密

160 行能扛住上面这些事，秘密不在代码技巧，在职责收敛——它明确不做什么：

• 不做业务：不判断任务内容是否合理、不做业务规则——那是发起流程和人的事。
• 不做编排：不掺和多流程、多分支——那是 Dify 的事。
• 不扛全部安全：安全是三层分工，它只管第一环。

安全三层具体说：闸门（执行服务——管「这个任务批不批」，高危默认拒+授权放行）在它身上；系统权限（管「批了执行体能碰哪」——最小权限账号+命令白名单，OS 层强制，想越也越不了）在部署层；审计（管「有没有越界」——任务 ID 贯穿+收口留痕+实际命令与声明比对）在记录层。它只是守门人，不是整个安全体系。

同样，结果兜底也不是它一个扛：它负责把失败送回确定性流程（收口），收口流程负责把失败加工成人工兜底指引（任务 ID、原因、处置选项）。「送回」和「出指引」是两层。

这层克制是刻意的：服务越小，越好维护、越好审计、坏了越容易十分钟看穿。执行服务只做平台做不了的事（异步调度、状态持有、咽喉闸门）——平台能做的（编排、审批、结果加工）一律留给平台。这是「能平台化就不自研」原则在组件层面的一次执行。

六、实测验证：它不是「设计上应该有用」，是测过

其中「失败不悬空」是验收标准级的验证：验收这套链路的判据不是「正常路径跑通了」，而是「任何故障都能回到确定性流程并生成人工兜底指引」——三类故障注入全覆盖才算过。

七、边界与下一步

如实交代当前形态的边界与演进方向：

• 任务台账当前是内存态——服务重启会丢历史记录。生产化第一步是落盘（任务记录持久化），实测链路不受影响。
• 鉴权与多租户隔离——当前是单调用方实验形态；生产部署需加鉴权（调用方认证），多流程共用时做租户隔离。
• 高危授权从关键词升级为显式声明——关键词模式会误伤正常业务描述（任务里提一句「覆盖部署」可能被拦），生产形态改成任务包显式声明高危动作 + 审批授权置位（这两层实测已跑通）。
• 任务级失败判定在收口端——Agent 执行遇到错误时常以「如实汇报错误」完成（不编造是本分），执行终态不携带「目标是否达成」——所以收口流程要补结果语义体检，识别结果里的失败信号。执行服务管「执行终态」，收口端管「目标是否达成」，两段分工。
• 执行服务与收口流程的分工：执行服务是调度中枢（收单/盯进度/兜底/闸门——外部组件），收口流程是执行结果回到 Dify 正式体系的接驳点（可审计、可接下游：知识库/工单/报表）——不是同一个东西，也不是谁替代谁。

常见问题

执行服务和收口流程（Dify 的第二个流程）是什么分工？

执行服务是调度中枢：收单、盯进度、双态回写、兜底、闸门——它不加工结果，只负责把任务管到终态并把结果送回确定性体系。收口流程是 Dify 里的第二个独立流程（发起流程投递完就办结、无法续跑，执行完成后必须重新进入一次 Dify）：它承接执行服务回调的结果，做质检（识别失败信号）、出正式报告或人工兜底指引、留档可审计——执行结果从这里回到 Dify 生态，未来可接知识库/工单/报表等下游。一句话：执行服务管「调度到终态」，收口流程管「结果进入正式体系」。

160 行的服务怎么保证可靠？是不是太简单了？

可靠性不靠代码量大，靠职责收敛和验收纪律。它只做五件事（投递/状态机/回写/兜底/闸门），不做业务不做编排——逻辑面窄，出问题十分钟能看穿。可靠性由三层验证兜底：正常路径端到端实测、三类故障注入（停执行体/中断/超时）全覆盖、安全闸门双向验证（拦截+授权放行）——验收判据是「任何故障都能回到确定性流程」，不是「正常路径跑通了」。生产化演进（台账落盘/鉴权/多租户）见正文第七节。

这个执行服务会被平台内建能力取代吗？

平台（Dify 这类编排平台）正在往 Agent 平台演进，审批、工具调用等能力会逐步内建——执行服务里「断点/审批承接」类职能确实存在被平台吸收的可能。但它有两块不在平台演进路线内：一是状态持有与异步调度（跨流程生命周期的任务跟踪，平台内工作流 run 是一次性的，天然需要外部调度层）；二是咽喉闸门的位置（独立于平台的放行控制点——不混进编排平台，安全边界才清晰）。所以更准确的判断是：平台吸收的是「重复造的部分」，执行服务留下的是「平台结构上给不了的部分」。这也是为什么它值得单独写一篇——它是这套架构里「平台替代不了的那 160 行」。

相关文章：给 AI 接上一双真干活的手——Agent 工作流里的人工审批怎么编排（AI 真执行形态总览）｜AI 自动化工作流从零搭：断点续跑式编排指南（动手搭建指南）

本文基于 Dify 1.17.0 社区版 + Hermes Agent v0.21.0 实测。AI 参与创作声明：本文由 AI 辅助写作，内容基于作者真实实测记录。