LLMStart|持续课程 · 不追玄学
模块 5 · 5.4
进阶级75 分钟

5.4真实自动化案例

本课只解决一个主问题:本单元只解决一个主问题:

Agent 在真实工作里到底怎么用,哪些地方必须谨慎设计?

学习目标

学完本单元后,学习者应该能够:

  • 分析真实自动化任务是否适合 Agent。
  • 为研究助手、内容生产助手、数据分析助手和客服助手设计工作流。
  • 识别每类 Agent 的工具、状态、确认节点和失败风险。
  • 将 Agent 设计从“想象很强”落到可执行流程。
  • 建立自动化项目的最小可用版本思维。

先给直觉

真实 Agent 项目不是一句:

帮我自动完成这个任务。

而是一套明确的结构:

任务目标
  ↓
输入资料
  ↓
可用工具
  ↓
工作步骤
  ↓
中间检查
  ↓
人工确认
  ↓
输出结果
  ↓
日志和复盘

本节用四个案例说明:Agent 如何从概念进入工作流。

案例 1:研究助手

场景

用户想研究一个主题,例如:

请帮我研究 RAG 系统的常见失败模式,并整理成课程提纲。

适合 Agent 吗

适合,但要控制范围。

原因:

  • 任务可以拆成多个步骤。
  • 需要搜索、阅读、整理和总结。
  • 中间结果可以检查。
  • 最终输出需要人工判断。

工作流

  1. 明确研究问题。
  2. 拆解子主题。
  3. 搜索或读取资料。
  4. 提取关键观点。
  5. 聚类观点。
  6. 标注来源和不确定点。
  7. 生成提纲。
  8. 等待人工确认。
  9. 生成正式草稿。

工具

  • 网页搜索。
  • 文档读取。
  • PDF 解析。
  • 笔记写入。
  • 事实核查队列。

状态

  • 待明确问题。
  • 已拆解子主题。
  • 已收集资料。
  • 已提取观点。
  • 待人工确认。
  • 已生成提纲。

确认节点

  • 研究范围确认。
  • 资料来源确认。
  • 提纲确认。

失败风险

  • 搜到低质量资料。
  • 过度依赖单一来源。
  • 把观点当事实。
  • 引用不存在或不支持结论。
  • 主题扩散。

最小可用版本

第一版不自动写完整报告。

只做:

  • 资料收集。
  • 观点提取。
  • 来源标注。
  • 提纲生成。

正式文章由人确认后再写。

案例 2:内容生产助手

场景

把课程单元转成公众号文章。

例如:

请把“Prompt Injection”这节课转成一篇公众号文章。

适合 Agent 吗

适合,但发布前必须人工审核。

工作流

  1. 读取课程单元。
  2. 提取核心问题。
  3. 判断目标读者。
  4. 生成文章主线。
  5. 生成标题候选。
  6. 生成文章大纲。
  7. 生成人话解释、案例和误区。
  8. 标注事实核查点。
  9. 生成初稿。
  10. 按风格检查表自检。
  11. 等待人工审稿。

工具

  • 文件读取。
  • 课程索引查询。
  • 公众号模板读取。
  • 草稿写入。
  • 风格检查。
  • 事实核查队列写入。

状态

  • 待读取课程。
  • 已提取主线。
  • 已生成大纲。
  • 已生成初稿。
  • 待事实核查。
  • 待人工审稿。

确认节点

  • 主线确认。
  • 标题确认。
  • 发布前确认。

失败风险

  • 标题夸张。
  • 技术解释过度简化。
  • 事实没核查。
  • 文章像课程讲义硬搬。
  • 风格不一致。

最小可用版本

只生成:

  • 文章主线。
  • 标题候选。
  • 大纲。
  • 事实核查清单。

先不自动生成全文。

案例 3:数据分析助手

场景

用户上传一份课程反馈表,希望分析学习者最常见的问题。

适合 Agent 吗

适合,但需要严格数据边界。

工作流

  1. 读取数据文件。
  2. 检查字段和样本。
  3. 做数据质量检查。
  4. 汇总关键指标。
  5. 聚类开放反馈。
  6. 生成图表建议。
  7. 输出发现和局限。
  8. 等待人工确认后生成报告。

工具

  • 表格读取。
  • 数据清洗。
  • 统计计算。
  • 图表生成。
  • 报告写入。

状态

  • 已读取文件。
  • 已完成质量检查。
  • 已完成统计。
  • 已完成反馈聚类。
  • 待人工确认。
  • 已生成报告。

确认节点

  • 数据字段确认。
  • 是否可以处理敏感字段。
  • 报告发布前确认。

失败风险

  • 数据泄露。
  • 样本太小却下结论。
  • 图表误导。
  • 忽略缺失值。
  • 把相关性说成因果。

最小可用版本

只做:

  • 字段识别。
  • 缺失值检查。
  • 基础统计。
  • 反馈主题聚类。

不自动给重大产品决策建议。

案例 4:客服工单助手

场景

客服每天处理大量工单,希望 AI 帮忙预处理。

适合 Agent 吗

适合部分环节。

不建议第一版让 Agent 自动回复客户。

工作流

  1. 读取工单。
  2. 判断问题类型。
  3. 检索知识库。
  4. 生成建议回复。
  5. 标注置信度和依据。
  6. 客服确认或修改。
  7. 记录最终回复。
  8. 收集失败案例。

工具

  • 工单系统查询。
  • 知识库检索。
  • 用户历史记录查询。
  • 回复草稿生成。
  • 工单标签写入。

状态

  • 待分类。
  • 已检索资料。
  • 已生成草稿。
  • 待客服确认。
  • 已发送或已退回。

确认节点

  • 客户回复发送前确认。
  • 涉及退款、投诉、法律风险时升级人工。

失败风险

  • 查错客户。
  • 引用过期政策。
  • 错误承诺补偿。
  • 回复语气不合适。
  • 泄露其他客户信息。

最小可用版本

只做:

  • 工单分类。
  • 推荐知识库条目。
  • 生成回复草稿。

发送动作由客服完成。

横向设计原则

1. 先做助手,不做全自动

第一版 Agent 应该帮助人完成任务,而不是完全替代人。

2. 先做低风险步骤

优先自动化:

  • 分类。
  • 总结。
  • 检索。
  • 草稿。
  • 检查。

谨慎自动化:

  • 发送。
  • 删除。
  • 付款。
  • 发布。
  • 修改生产数据。

3. 每一步都要可观察

用户应该知道 Agent 做了什么。

4. 失败案例要回流

每次失败都应该进入评估集或改进清单。

5. 工具权限要小

每个工具只给完成任务所需的权限。

自动化适配判断表

问题 是 否
任务目标是否清楚? 可继续 先澄清
是否能拆成步骤? 可继续 不适合 Agent
每步结果能否检查? 可继续 风险高
是否需要外部工具? 设计工具权限 可简化为 Chatbot
错误成本是否可控? 可试点 需要人工主导
是否有确认节点? 更安全 先补设计

常见误区

误区 1:Agent 应该一开始就全自动

第一版全自动通常风险太高。先做人类助手更稳。

误区 2:自动化越多,价值越大

错误的自动化会放大风险。真正的价值来自减少可靠流程里的负担。

误区 3:只要模型够强,就不用流程设计

强模型仍然需要工具、状态、确认和日志。

误区 4:失败案例是坏事

失败案例是改进材料。没有记录才是坏事。

误区 5:所有团队都需要同一种 Agent

不同团队的资料、权限、风险和工作习惯不同,Agent 也应该不同。

动手练习

选择一个你自己的工作任务,设计一个 Agent 最小可用版本。

填写:

项目 内容
任务名称
用户目标
输入资料
工作流步骤
所需工具
状态列表
人工确认节点
失败风险
第一版不做什么
检查题(自测)
  1. 为什么第一版 Agent 更适合做助手,而不是全自动执行者?
  2. 研究助手、内容助手、数据分析助手、客服助手的风险有什么不同?
  3. 设计 Agent 最小可用版本时,为什么要明确“不做什么”?
参考答案
  1. 助手模式保留人工确认与监督,失败影响可控,还能积累真实数据验证价值;全自动执行一出错就不可逆,第一版风险太高。
  2. 研究助手风险在引用与误导;内容助手在版权与事实;数据分析助手在隐私与错误结论;客服助手在承诺与责任。风险来源不同,防护重点也不同。
  3. 明确"不做什么"能控制范围、降低风险,也让评估边界清楚:先把少数任务做好,再谈扩展。

Takeaway

真实 Agent 项目的关键不是让模型显得自主,而是把任务拆成可控步骤,给它合适工具,记录状态,设置确认节点,并持续收集失败案例。好的 Agent 不是一口吃掉整份工作,而是先稳稳接住最适合自动化的部分。