LLMStart|持续课程 · 不追玄学
模块 5 · 5.1
进阶级70 分钟样板课精修版

5.1Agent 基础

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

Agent 到底是什么,为什么它不是“会聊天的模型”这么简单?

学习目标

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

  • 区分 Chatbot、Workflow 和 Agent。
  • 解释 Agent 的基本组成:目标、模型、工具、状态、反馈和控制边界。
  • 判断哪些任务适合 Agent,哪些任务更适合普通对话或固定流程。
  • 理解 Agent 为什么容易失败。
  • 设计一个带人工确认节点的最小 Agent 工作流。

开场场景

用户说:

请帮我安排下周和 Alex 的会议。

如果是普通 Chatbot,它可能帮你写一封邮件:

Hi Alex,我们下周找个时间聊聊……

但如果是一个真正能完成任务的 Agent,它可能需要:

  1. 查看你的日历。
  2. 找出空闲时间。
  3. 询问 Alex 的时间。
  4. 等待对方回复。
  5. 创建日历事件。
  6. 发送会议邀请。
  7. 在发送前让你确认。

这已经不是“回答问题”,而是“围绕目标执行一串动作”。

Agent 的难点也在这里:它不只是会说话,它会做事。会做事,就会带来权限、状态、错误和责任。

先给直觉

可以先用三句话区分:

Chatbot:你问一句,它答一句。
Workflow:系统按预设流程一步步执行。
Agent:围绕目标,动态决定下一步,并调用工具行动。

再换成人话:

  • Chatbot 更像问答助手。
  • Workflow 更像流程表。
  • Agent 更像有工具、有任务、有边界的助理。

很多产品把普通聊天框叫 Agent,其实只是换了个名字。名字不重要,关键看它是否能基于目标、状态和工具持续行动。

Agent 的最小结构

一个最小 Agent 通常包含:

目标
  ↓
模型
  ↓
计划
  ↓
工具调用
  ↓
观察结果
  ↓
更新状态
  ↓
继续 / 停止 / 请求确认

如果没有工具,它通常只是 Chatbot。

如果没有状态,它很难做长任务。

如果没有控制边界,它可能做出高风险动作。

如果没有反馈,它可能在错误基础上继续执行。

最小 Agent 工作流图:目标、计划、调用工具、观察结果、更新状态、人工确认的循环

图:最小 Agent 是一个带状态、带确认、带日志的行动循环,高风险动作前必须暂停请人确认。

Agent 的基本组成

1. 目标

Agent 必须知道要完成什么。

目标可以是:

  • 查找资料并总结。
  • 生成一份报告。
  • 安排会议。
  • 处理客户工单。
  • 修复代码中的一个 bug。

目标越模糊,Agent 越容易跑偏。

差目标:

帮我处理一下这个项目。

好目标:

请检查这个课程目录,找出缺失的模块 README,并补齐每个 README 的学习目标和单元结构。

好目标通常包含:

  • 要完成的结果。
  • 输入材料。
  • 允许的动作。
  • 不允许的动作。
  • 验收标准。

2. 模型

模型负责理解任务、规划步骤、生成工具调用参数、解释结果。

不同 Agent 对模型能力要求不同:

  • 简单任务可能用较便宜模型。
  • 复杂规划需要更强推理能力。
  • 高风险任务需要更严格评估和人工确认。

模型不是 Agent 的全部。

只接一个强模型,不等于就有了可靠 Agent。

3. 工具

Agent 要行动,通常需要工具。

工具可以是:

  • 搜索网页。
  • 查询数据库。
  • 读取文件。
  • 写入文档。
  • 发送邮件。
  • 创建日历事件。
  • 执行代码。
  • 调用第三方 API。

工具让模型从“会说”走向“能做”。

但工具也带来风险:它可能读错、写错、发错、删错。

4. 状态

状态记录 Agent 当前任务进度。

比如:

  • 已经完成哪些步骤。
  • 当前拿到了哪些资料。
  • 哪些工具调用成功或失败。
  • 用户确认了什么。
  • 下一步计划是什么。

没有状态,Agent 很容易重复劳动、忘记上下文,或者在长任务中迷路。

5. 反馈

Agent 需要观察行动结果。

例如:

  • 搜索结果是否相关。
  • 文件是否写入成功。
  • API 是否返回错误。
  • 测试是否通过。
  • 用户是否批准下一步。

Agent 不是只会下命令,还要看结果并调整计划。

6. 控制边界

控制边界决定 Agent 能做什么、不能做什么、什么时候必须停下来问人。

例如:

  • 可以读取文件,但不能删除文件。
  • 可以起草邮件,但发送前必须确认。
  • 可以查询客户资料,但不能导出敏感信息。
  • 可以修改代码,但不能直接部署生产。

没有边界的 Agent,不是先进,是吓人。

Chatbot、Workflow、Agent 的区别

类型 核心特点 适合场景 风险
Chatbot 对话问答 解释、总结、轻量创作 输出不稳定、缺少行动能力
Workflow 固定流程 审批、批处理、稳定业务流程 灵活性低
Agent 动态规划和行动 研究、自动化、多步骤任务 难评估、容易跑偏、权限风险

很多产品其实不需要 Agent,用 Workflow 更合适。

如果流程清楚、规则稳定、结果可预测,硬上 Agent 反而增加复杂度。技术不是越自由越好,太自由有时只是把麻烦外包给未来的你。

Chatbot、Workflow、Agent 三种形态的对比

图:Chatbot 偏对话、Workflow 偏固定流程、Agent 偏动态规划与行动。很多任务用 Workflow 就够,不必上 Agent。

什么时候用 Chatbot

适合 Chatbot 的情况:

  • 用户主要想问问题。
  • 输出不需要调用外部工具。
  • 不需要持续执行多步骤。
  • 错误成本较低。
  • 用户会自己判断和复制结果。

例子:

  • 概念解释。
  • 文章润色。
  • 简短问答。
  • 课程答疑。
  • 头脑风暴。

什么时候用 Workflow

适合 Workflow 的情况:

  • 流程固定。
  • 条件明确。
  • 每一步规则稳定。
  • 不需要模型自由规划。
  • 需要可审计和可预测。

例子:

  • 表单审批。
  • 固定数据清洗。
  • 课程发布检查。
  • 每日固定报表。
  • 规则明确的通知流程。

Workflow 不酷,但稳定。稳定在真实产品里很值钱。

什么时候用 Agent

比较适合 Agent 的任务通常有这些特征:

  • 目标明确。
  • 可以拆成多个步骤。
  • 每步结果可以观察。
  • 需要根据中间结果调整。
  • 工具权限可控。
  • 失败成本可接受或有人工确认。

例子:

  • 资料研究助手。
  • 代码库探索助手。
  • 数据分析助手。
  • 内容生产流程助手。
  • 客服工单预处理。
  • 个人知识库整理。

Agent 不适合什么任务

不适合的场景:

  • 目标非常模糊。
  • 任务结果难以验证。
  • 错误成本很高。
  • 权限边界不清。
  • 数据来源不可靠。
  • 需要复杂人际判断。

例如:

  • 自动做重大财务决策。
  • 自动发送法律意见。
  • 自动处理敏感人事决定。
  • 没有审核地对外发布公司声明。

这些场景可以用 AI 辅助,但不应该让 Agent 无人监管地执行。

Agent 为什么容易失败

1. 目标理解错误

用户目标模糊,Agent 只能猜。

2. 计划不可靠

模型生成的计划可能漏步骤、顺序错误或过于乐观。

3. 工具调用错误

参数填错、接口失败、权限不足、返回结果理解错,都可能让任务失败。

4. 状态管理混乱

长任务里,Agent 可能忘记已完成的事情,或者重复执行。

5. 反馈不足

如果系统不检查工具结果,Agent 可能在错误基础上继续行动。

6. 缺少人工确认

高风险动作如果没有确认节点,错误会从“说错”升级为“做错”。

Agent 失败定位表

失败表现 可能原因 检查方向
一开始就跑偏 目标模糊 任务说明、验收标准
计划不合理 模型规划弱、约束少 计划审核、步骤模板
工具调用失败 参数错、权限不足、接口异常 工具 schema、错误处理
重复执行 状态记录不足 状态机、任务日志
做了危险动作 权限边界不清 人工确认、工具权限
输出无法复查 缺少日志和来源 记录工具调用和中间结果
成本失控 循环调用或重试过多 限流、预算、停止条件

定位 Agent 问题时,不要只问“模型是不是不够强”。很多失败来自系统设计。

人类确认节点

Agent 设计里,一个非常重要的原则是:高风险动作前要让人确认。

需要确认的动作包括:

  • 发送邮件。
  • 删除或覆盖文件。
  • 花钱购买。
  • 发布公开内容。
  • 修改生产系统。
  • 向外部提交表单。
  • 处理敏感数据。

确认节点不是“降低自动化程度”,而是让系统更可靠。

一个好的确认节点应该告诉用户:

  • Agent 准备做什么。
  • 为什么要做。
  • 会影响哪些对象。
  • 是否可以撤销。
  • 用户有哪些选择。

案例:研究助手 Agent

任务:

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

一个 Agent 可能这样工作:

  1. 拆解问题:检索失败、重排失败、生成失败、评估失败。
  2. 搜索资料或读取指定文档。
  3. 提取关键观点。
  4. 对观点做聚类。
  5. 生成课程提纲。
  6. 标注需要人工核查的来源。
  7. 等待用户确认后生成正式讲义。

注意最后一步:正式讲义前需要确认事实来源。

研究任务里,Agent 可以帮你跑腿,但不能替你承担判断责任。

案例:课程内容生产 Agent

目标:

把一个课程主题整理成公众号文章初稿。

可控工作流:

主题输入
  ↓
确认目标读者
  ↓
生成文章大纲
  ↓
人工确认大纲
  ↓
生成初稿
  ↓
检查事实和术语
  ↓
人工审稿
  ↓
进入发布准备

这个系统可以用 Agent 辅助,但不应该自动发布。

因为对外发布涉及品牌、事实、版权和读者信任。

常见误区

误区 1:Agent 就是大模型加 Prompt

不是。Agent 通常还需要工具、状态、反馈和控制边界。

误区 2:Agent 越自主越好

不一定。越自主,越需要评估、权限和确认机制。

误区 3:所有自动化都应该做成 Agent

固定流程用 Workflow 往往更稳定、更便宜、更容易维护。

误区 4:模型强了,Agent 就自然可靠

强模型能改善规划和理解,但工具错误、权限风险、状态管理和评估问题仍然存在。

误区 5:只要加人工确认就安全

确认节点要提供足够信息。用户如果看不懂 Agent 要做什么,确认按钮只是心理安慰。

动手练习

选择一个你想自动化的任务,填写:

问题 你的答案
任务目标是什么?
用户输入是什么?
需要哪些工具?
需要记录哪些状态?
每一步结果如何验证?
哪些动作必须人工确认?
如果做错,最大风险是什么?
这个任务更适合 Chatbot、Workflow 还是 Agent?

与工作坊的关系

学完本节后,可以进入:

  • 20_workshops/03_agent_mini_project/README.md

这个工作坊会让学习者设计一个课程研究助手 Agent,把目标、工具、状态、确认节点和评估放进一个小项目。

检查题(自测)
  1. Chatbot、Workflow、Agent 的核心区别是什么?
  2. 一个 Agent 通常需要哪些组成部分?
  3. 为什么高风险动作前需要人类确认?
  4. 为什么强模型不等于可靠 Agent?
  5. 什么情况下 Workflow 比 Agent 更合适?
参考答案
  1. Chatbot 主要回答问题;Workflow 按固定流程执行;Agent 围绕目标动态规划、调用工具、观察结果并继续行动。
  2. 通常包括目标、模型、工具、状态、反馈和控制边界。有些系统还会加入计划器、记忆、评估器和人工确认节点。
  3. 因为高风险动作会产生真实后果,例如发送邮件、删除文件、发布内容、花钱或处理敏感数据。确认节点能把错误拦在行动前。
  4. 因为 Agent 的可靠性还取决于工具 schema、权限、状态管理、错误处理、日志、评估和人工确认。模型只是其中一部分。
  5. 当流程稳定、规则明确、结果可预测、需要审计时,Workflow 往往更合适。

Takeaway

Agent 的核心不是“模型会聊天”,而是模型能围绕目标规划、调用工具、观察结果并继续行动。真正的难点在工具、状态、反馈、权限和评估。能回答是一步,能可靠做事是另一座山。