复杂任务AI处理实践：淘宝工程师的实战手记

本文分享了作者探索AI辅助处理"复杂重复性工作"的实践经验。文章总结了一套可复用的方法论——如何将人工操作抽象为"感知-决策-执行"的 AI 闭环，并通过工单处理、数据治理、基线运维等真实案例，展示从"工具助手"到"智能体"的三种自动化模式。

引言：为什么我们需要“AI协作者”？

• 时不时在非工作时间收到告警，只为处理一条非自身原因的上游问题；
• 收到工单后要翻五六个平台查日志、看配置、逐层排查，且一年要处理数百条工单；
• 上游改了个字段，你得手动排查几百个下游任务是否受影响；
• 想治理一张表，需要翻遍本表与所有上下游的代码和元数据才能下结论；

核心理念：输入明确、逻辑清晰、动作固定的“重复性工作”，都可以尝试交给AI完成。

不仅包括“批量打标”这种显性重复，也包括“数据治理”“工单排查”“夜间值班”这种看似灵活但套路固定的隐性重复工作。

核心思想：把人类的操作

抽象成 AI 的“眼”、“手”和“脑”

• AI 如何感知上下文？ → 构建“眼睛”
• AI 如何执行动作？ → 构建“手”
• AI 如何闭环操作？ → 构建“脑”

[AI大脑] ←(Prompt/Workflow)→ [工具集]   ↑                       ↗       ↘(决策与规划)           (读取类工具)   (操作类工具)                   (如查代码/读工单) (如发任务/评论/发布)

一句话总结：把平时“打开网页查看信息”的动作，变成AI可调用的“工具”。

• ODPS治理？→ 用 Workflow：查各项信息 → 查血缘→ 读各层代码 → 判断是否可治理 → 下线or冷备or治理；
• 处理工单？→ 用 Agent：先理解问题类型 → 决定查日志还是看配置 → 综合判断 → 直接回复 or 流转。

最终目标：构建一个“感知 → 决策 → 执行 → 反馈”的完整闭环，让AI自己跑完一整件事。

💡 最简单方法： 把你的提示词交给 AI 润色一遍

• 明确输入格式和范围 — 告诉 AI "你会看到什么"
• 清晰定义判断标准 — 可量化、可验证（如"字段被用于 JOIN"而非"字段很重要"）
• 规定结构化输出格式 — JSON / 表格 / Markdown
• 提供正反例示范 — 什么是对的，什么是错的
• 设置边界条件处理规则 — 遇到不确定情况怎么办

• 有不确定性 → 直接返回 而非冒险执行
• ✅ 策略按最保守的来 宁可少治理，不可误删除
• ✅ 设置安全阈值 如"仅当高置信度时自动执行"

{  "是否可缩短生命周期": " ",  "是否可下线": " ",  "原因": "",  "分步骤结论": [    "任务优先级",    "下游最长依赖时长",    "上游可恢复性"  ],  "工具原始结果": { "下游节点列表": [...], "节点元信息": {...} },  ............}

• 可验证性 — 人类可追溯 AI 的每一步推理；
• 可信任性 — 即使 AI 出错，也能快速定位问题，同时也可以根据原始数据和中间结果人工快速得出结论；
• 可优化性 — 通过分析过程改进 Prompt 和工具。

• 增加观测节点 — 在关键步骤后插入"结果确认"环节；
• 增加验证节点 — 在结果后添加验证环节；
• 重要内容人工验证 — 高风险操作和重要节点、必须人工确认；
• 多次执行取一致 — 对不确定结果，可人工复核。

AI自动化的不同方案

• AI 对一批代码等内容，做一些梳理、分类、打标或质量检查
• AI 批量从文档中提取关键信息，整理成结构化知识
• 批量任务创建：读取模板 → 自动生成 → 提交发布

• 快速见效：已有工具的情况下，几分钟就能搭建

适用判断：如果你的工作是"需要看大量信息，但只需要简单判断"，就适合用工具助手。

• 数据治理：查表信息及代码 → 看血缘关系 → 读上下游代码 → 查上下游信息 → 评估 → 给出治理方案 → 输出治理建议JSON
• 定期巡检任务：每天自动检查系统状态 → 发现异常 → 分类处理 → 发送报警
• 特定场景工单排查：读取工单内容和已有进度 → 查询日志 → 确认问题 → 逐层排查 → 定位原因 → 回复

• 流程复杂：可能包含10-50个步骤,有循环、条件判断

• 多工具协同：需要调用多种不同平台的不同工具（查询、分析、操作）
• 全自动执行：设置好后可以无人值守

适用判断：如果你的工作是"步骤很多，但每次都按相同顺序做"，就适合用workflow。

• 工单自动运维：理解用户问题 → 自主选择排查方向 → 调用相关工具 → 分析根因 → 给出解决方案 → 自动回复或流转
• 基线运维：监控多条基线 → 发现异常→ 持续监测直到决策时间点 → 自主决策处理→ 执行操作 → 通知相关人员

• 高度灵活：不依赖固定流程，每次的处理路径可能完全不同
• 自主决策：AI 自己判断"接下来应该查什么、做什么"
• 接近人类：像资深工程师一样思考和行动

• 需要更强的大模型能力（推理、规划、多轮对话）；
• 需要精细的 Prompt 设计，避免 AI 陷入无效循环；
• 工具与子Agent应尽量精简，避免系统过于复杂难以收敛；
• 当前RAG召回机制不够智能，需要设计好的知识库来应对。

适用判断：如果你的工作是"每次情况都不同,需要根据实际问题灵活应对",就需要用智能Agent。不过目前Agent在复杂任务上的效果有限，作者即使拆分多层子agent后，也只实现了10步以内的轻量推理。

哪些场景适合AI自动化?

只要每天有“不得不做但不想做”的事情，就可以试着问一句：

这件事能不能让AI先帮我做90%？剩下10%我来兜底。

结语：AI 不是来抢饭碗的

而是帮我们做更有价值的事

不是所有工作都值得交给 AI，但所有低价值的工作都应该被 AI 替代。

概览及案例实现细节

• 工具接入 + 一定代码基础 + 提示词
• 对工程能力要求不高

• 案例一：代码影响分析（简单 Workflow）

[AI Workflow]  ├─ 步骤1：输入所有任务列表  ├─ 步骤2：循环每个任务（Python或workflow循环）  │   ├─ 调用“眼睛”类工具：读取SQL代码+读取file代码（适应file拼SQL类任务）  │   ├─ AI 分析中间结果：代码中是否包含该字段？是否用于 JOIN 操作?是否转换数据类型?  │   ├─ AI 判断最终结论：是否有影响  │   └─ 记录结论  └─ 步骤3：生成json结果  ↓输出：json2Excel （任务名 | 是否受影响 | 是否包含此字段 ｜ 是否用此字段JOIN ｜ 是否转换数据类型）

• 知识提取：批量从文档/工单/代码/缺陷中抽取结构化知识，向量化构建知识库、自动更新
• 批量任务创建：如搭建一条数据深度备份链路,批量创建并发布备份任务
• 日志解读：批量从日志中解析出血缘关系

核心价值：将原本需要人工逐个处理的工作,变成批量自动化分析

• 案例二：自动存储治理（复杂 Workflow）

典型流程（20+ 节点）：1. 接收待治理表名2. 【眼】查询表元信息（生命周期、大小、优先级等）3. 【眼】获取全链路血缘（上游来源 + 下游消费）4. 【眼】遍历所有下游任务，查看 SQL 代码5. 【AI 分析】判断对该表的实际依赖范围6. 【眼】检查上游数据恢复能力（冷备策略、重跑成本）7. 【AI 决策】综合评估重要性 & 使用8. 【AI 输出】生成治理建议：下线 / 缩短生命周期 / 深度冷存备份9. 【手】自动执行治理操作 或 给出json格式的结论

• 流程固定： 每个步骤的先后顺序、判断逻辑都是确定的；
• 多工具协同： 需要调用十几个不同的工具（读代码、读元数据、读血缘、执行操作等）；
• 决策复杂： 需要综合多维度信息做出治理决策。

• 降低存储xxPB，整个数据产品的存储减少50%；
• 借助AI轻松扫描了几乎所有的表及任务，治理了大量的表和任务；
• 精准：在今年的数据治理中，AI处理了数千张表的治理决策，人工复核了10%高优先级的样本，未发现误删数据的情况，不过发现ai策略过度保守的情况存在。

• 拆解清晰 — 将复杂任务拆解为原子化步骤、并且合理串联起来；
• 工具齐全 — 确保每个步骤都有对应的工具支持；
• Prompt 精准 — 每个决策节点的判断标准必须明确。

• 案例三：AI工单运维、引入 Hierarchical Agent——应对复杂与不确定性

图5:经过精简优化后的工单处理的workflow

Master Agent - 决策层【大脑】├── 子Agent A：日志提取分析【眼】│   ├── 孙Agent A1：获取日志并解析SQL│   ├── 工具A2：读取日志平台2日志│   └── 工具A3：读取日志平台3日志│├── 子Agent B：数据排查【手】│   ├── 孙Agent B1：检查各类关系│   ├── 工具B2：查询xx绑定情况│   └── 工具B3：查询xx历史├── 子Agent C：工单系统【手+眼】│   ├── 孙Agent C1：查看工单+初步判断│   ├── 工具C2：评论工单│   └── 工具C3：流转/关闭工单│├── 子Agent D：链路逐层排查workflow、知识库检索Agent、代码分析Agent等│   └── ...(其他专项分析能力)│└── 定时播报Agent：定时播报各项内容    └── ...(监控与通知)

1. 接收工单内容2. 理解问题类型和背景3. 规划排查路径4. 调度相关子Agent执行分析5. 汇总各Agent的分析结果6. 判断问题根因7. 生成解决方案8. 回复工单 或 转人工

• ✅ 灵活性强：可根据实际问题动态调整路径；
• ✅ 可扩展性好：新增问题类型只需增加对应 Specialist Agent；
• ✅ 贴近人类思维：先理解 → 再选择工具 → 最终综合判断。

• 需要更强的模型能力(推理、规划、工具选择)；
• 需要更精细的Prompt设计(避免Agent陷入无效循环)；
• 子Agent要做到足够的通用，适应所有场景；
• 需要足够的精简,尽可能合并工具和子Agent,避免过于复杂而难以规划闭环；
• RAG召回不够智能、需要特殊处理知识（添加索引）。

• 原有 50 节点 Workflow 基本实现对一些工单的基本闭环处理、其他的工单也可以完成部分前置排查工作；
• 现有通用答疑Agent为一线运营小二提供了问题排查能力，帮助他们更好的回答用户问题，前置拦截工单。 

• 新增 Agent 架构虽理论上更通用，但它更通用的同时，也更"笨"了；
• 当前仅支持直接问答与轻量级链路规划排查；
• 实际体验反而不如旧版 Workflow，正在持续优化中。

不是所有场景都需要 Agent，对于流程固定的场景，Workflow 可能是更优解。Agent 更适合"问题空间大、需要深度推理"的复杂场景。且目前ai的智能程度对复杂agent的支持也不算很好。

• 案例四：AI自动基线运维（开发中）

• 上游依赖众多：整个数据产品依赖数百个上游，为保障用户及时看到离线数据，SLA 要求xx点前产出
• 告警频繁： 虽然每个上游出问题的概率都很低，但架不住上游太多，基线告警频繁
• 人工运维压力大：这个时候就需要人工去推动上游产出，人工运维压力大

AI[监控期]├─ 多个定时任务持续监测各上游产出状态├─ 触发告警后自动推动上游处理（短信 + 外呼）├─ 若临近决策时间点仍未恢复 → AI自动解除依赖├─ 同步发送钉钉通知，提醒运营布防│[恢复期]├─ 上游产出后 → 自动生成回补任务├─ 回补触点数据 → 恢复能力├─ 次日回补其他报告数据，确保数据0丢失

简单来说：过去靠“人催+拍板舍弃”，现在由AI全程接管—— “监控 → 决策 → 解耦 → 恢复”全自动闭环。

• 解放人力：基本告别基线运维工作
• 自动回补、避免数据丢失，改善用户体验