Dify调用AI Agent做执行前的审批产品系统Vibe Coding

面向企业 IT 运维与技术交付团队：发布前巡检（查服务状态、磁盘水位、版本核对）这类任务活不重，但必须有人做。长期困在"AI 只能给建议、动手还是人"的断档里——知识问答再准也碰不到真实系统，问它"这台服务器现在磁盘水位多少"，它读不到真实状态，答不了。

这个应用把「审批 → 执行 → 收口」做成完整闭环：AI 不只给方案，而是真的在目标服务器上把活干完，而且每一步都有审批、有留痕、可对账。

主流程分四段：

一、工单受理——录入工单号、服务器角色、紧急程度、任务描述；

二、任务包组装——把工单拼装成结构化任务包，包含任务目标、环境线索、边界约束（如"数据必须来自真实命令输出，禁止编造""涉及删除、格式化、重启等危险操作先停下请求授权"）；

三、人工审批——关键动作必须人工确认才放行，审批不通过则直接驳回留痕；

四、真执行投递——调用外部执行桥，在目标服务器上真实执行任务并回写结果。

配套的「AI 执行结果收口」流程按执行状态分流：成功端自动组装可对账结果报告，失败端输出兜底指引，避免"执行了但结果没人收"的悬空状态。

我独立负责流程设计、节点编排与执行桥实现。四个技术要点：

1. 用确定性工作流承载审批与留痕——人工审批节点把"要不要执行"的判断权留给人，AI 只负责执行；
2. 执行通道放在编排之外——外部 Agent 在真实服务器上拆任务、跑命令、看结果，由一个执行服务承接断点（约百行），而非让平台内模型假装执行；
3. 约束前置——安全边界写进任务包（禁止编造输出、危险操作先请求授权），把风险拦在执行之前；
4. 结果收口——用条件分支做成功/失败双路兜底，执行完必须有明确结论。

实测对照（同一道发布前巡检题、同款模型）：带执行通道的版本约 10 秒完成真实巡检、数据可与系统逐项对账；无执行通道的版本如实拒绝——"我没有访问服务器的通道"。结论：AI 会不会真干活的差距不在模型智商，在执行通道。