从40分钟到5分钟：我把生产日报做成了一套能自己”复盘”的 AI 流水线

先说结果：我们组每天的生产日报，从原来手搓 40 分钟，到现在一套定时流水线 5 分钟跑完，我只需要扫一眼确认发出。

2026 年了，AI 写个日报早就不是新鲜事。真正想分享的，是这件事逼我把一套本该属于数据工程的工程纪律，用在一个看起来很小的需求上——而且生成那段，我没用”调一下 prompt”的玩法，而是按现在主流的 agent 思路搭的。正是这些，决定了它是能跑一年的东西，还是跑三天就崩的玩具。

一、痛点：重复劳动里藏着最贵的成本

日报要汇总：良率、产能、异常工单、关键设备状态。原来我的流程是——从三个系统导出、粘到 Excel 做透视表、手写”今日整体平稳，B 线良率波动”的总结、排版发出去。

熟练工也要 40 分钟，且每天下班前最易被打断，一个电话回来就忘了算到哪。算笔账：22 个工作日 × 40 分钟 ≈ 15 小时/月，一年近 180 小时，全耗在复制粘贴上。

二、技术选型：没上 Airflow，也没用 n8n 的 Agent Builder，但借了两家的脑子

2026 年摆在面前的选项其实很明确：要么上 Airflow 3 那套工业标准，要么用 n8n 的 AI Agent Builder 拖一个。我都认真评估过：

• Airflow：DAG-as-code、可移植、能上 CI/CD，是正经数据工程做法；但对一个每日单次、单链路的小批量任务，光部署 scheduler + worker + 元数据库就是过度设计，维护成本会吃掉省下的时间。
• n8n AI Agent：今年它 LangChain 节点、MCP、human-in-the-loop 都挺成熟，拖很快；但工作流是绑定它运行时的 JSON，可移植性差，而且我想把取数和校验写进单测，可视化画布反而不如代码好测。

我的判断：用轻量栈（Python + 定时任务 + 小编排脚本），但把 Airflow 的工程纪律和 n8n 的 agent 思路都借过来。这点后面是关键。

最终架构（简化）：

定时触发(cron)
  └─ 1. Extract   从3个系统拉数 → 落原始层(raw)，按日期分区
  └─ 2. Transform 清洗/对齐口径 → 计算指标(df)，结构化
  └─ 3. Generate  Agent(草稿) → 校验Tool(拿数字对账) → 不一致打回重写
  └─ 4. Validate  质量门禁(行数/空值/越界) → 不过则告警人工
  └─ 5. Render & Push  渲染模板 → 群机器人推送 + 存共享盘

三、两个真正难的点（也是体现功力的地方）

难点 1：三个系统的”良率”不是同一个良率

最坑的不是拉数，是口径对不齐。三个系统的”良率”定义略有差异，直接算会 silently 出错。做法：

• 数据契约（data contract）：和 data 组对齐，把每个指标的计算口径、主键、来源写成文档，代码严格按契约实现；
• 幂等设计：所有写入按”日期分区”落盘，重跑某天只覆盖当天分区、绝不追加。我专门验证过——清空某天分区重跑两次，行数和产物 key 必须完全一致。这是后面”敢放心交给定时任务”的底气。

难点 2：让 Agent 写总结，但给它套上”不能撒谎”的硬约束

2026 年我再也不会让模型”自由发挥”了。生成那段我用的是一个很轻的多智能体 + 工具调用结构，而不是单轮 prompt：

• 草稿 Agent：只负责”把结构化指标说成人话”，且被要求返回结构化 JSON（各段落文本），不让它自己算数；
• 校验 Tool（关键）：这是我自己写的一个工具，被 Agent 调用——它拿着第一步算出的真值，去逐条核对叙述里出现的每个关键数字，不一致就返回错误。Agent 拿到错误会自我打回重写，最多循环 N 次仍对不上就整条日报拦截、推告警给我。

等于把”可信”从”靠模型自觉”变成了”靠工具强制”。这个边界划分，比选哪个模型重要得多——模型只管表达，计算与真相永远在代码侧。

顺带一提，我也在想要不要把三个系统的接口用 MCP 暴露成工具让 Agent 直接取数。但评估后否决了：取数逻辑一旦进 agent 运行时，就难做单测和幂等控制了。所以取数老老实实在代码里，Agent 只在”表达层”发挥作用。这也是 2026 年做 agent 很常见的一个教训——不是所有环节都该 agent 化。

四、可靠性：让它”跑一年”而不是”跑三天”

• 重试 + 退避：拉数失败自动重试 3 次、指数退避，网络抖动不再半夜叫人；
• 质量门禁：行数为 0、关键字段空、数字越界 → fail 并推私信告警；
• 可观测：每步打日志（抽了多少行、落了哪个分区、校验过没过），出问题 30 秒定位；
• 告警分层：只在三种情况叫我——取数失败、质量门禁不过、推送失败；其余记日志不刷屏；
• runbook：取数失败先看源系统、质量门禁不过先核对口径再清空重跑。把踩过的坑变成”照着做就行”。

五、结果和一点反思

现在每天 5 分钟出日报，稳定跑了大半年没出过数字错误。省下的不是 40 分钟，是下班前那段最易被中断、也最易出错的焦虑时间。

回头看，最值钱的不是”我用了 AI”，而是几个判断：

• 不盲目上重武器：单日小批量，轻量栈 + 工程纪律就够了；agent 和 Airflow 都是好东西，但用错场景就是债；
• Agent 也要划边界：表达交给 agent，计算和真相留在代码 + 工具校验，责任分离才不出事故；
• 幂等和可重跑是自动化的前提——不能安全重跑的流程，就不该交给定时任务。

如果你也在被某种日复一日的重复报表折磨，欢迎找我聊。我这套”轻量栈 + 数据工程纪律 + 受约束的 Agent”的思路，能套到很多类似活儿上。