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 不是一口吃掉整份工作,而是先稳稳接住最适合自动化的部分。