5.1Agent 基础
本课只解决一个主问题:本单元只解决一个主问题:Agent 到底是什么,为什么它不是“会聊天的模型”这么简单?
学习目标
学完本单元后,学习者应该能够:
- 区分 Chatbot、Workflow 和 Agent。
- 解释 Agent 的基本组成:目标、模型、工具、状态、反馈和控制边界。
- 判断哪些任务适合 Agent,哪些任务更适合普通对话或固定流程。
- 理解 Agent 为什么容易失败。
- 设计一个带人工确认节点的最小 Agent 工作流。
开场场景
用户说:
请帮我安排下周和 Alex 的会议。
如果是普通 Chatbot,它可能帮你写一封邮件:
Hi Alex,我们下周找个时间聊聊……
但如果是一个真正能完成任务的 Agent,它可能需要:
- 查看你的日历。
- 找出空闲时间。
- 询问 Alex 的时间。
- 等待对方回复。
- 创建日历事件。
- 发送会议邀请。
- 在发送前让你确认。
这已经不是“回答问题”,而是“围绕目标执行一串动作”。
Agent 的难点也在这里:它不只是会说话,它会做事。会做事,就会带来权限、状态、错误和责任。
先给直觉
可以先用三句话区分:
Chatbot:你问一句,它答一句。
Workflow:系统按预设流程一步步执行。
Agent:围绕目标,动态决定下一步,并调用工具行动。
再换成人话:
- Chatbot 更像问答助手。
- Workflow 更像流程表。
- Agent 更像有工具、有任务、有边界的助理。
很多产品把普通聊天框叫 Agent,其实只是换了个名字。名字不重要,关键看它是否能基于目标、状态和工具持续行动。
Agent 的最小结构
一个最小 Agent 通常包含:
目标
↓
模型
↓
计划
↓
工具调用
↓
观察结果
↓
更新状态
↓
继续 / 停止 / 请求确认
如果没有工具,它通常只是 Chatbot。
如果没有状态,它很难做长任务。
如果没有控制边界,它可能做出高风险动作。
如果没有反馈,它可能在错误基础上继续执行。
图:最小 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 偏动态规划与行动。很多任务用 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 可能这样工作:
- 拆解问题:检索失败、重排失败、生成失败、评估失败。
- 搜索资料或读取指定文档。
- 提取关键观点。
- 对观点做聚类。
- 生成课程提纲。
- 标注需要人工核查的来源。
- 等待用户确认后生成正式讲义。
注意最后一步:正式讲义前需要确认事实来源。
研究任务里,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,把目标、工具、状态、确认节点和评估放进一个小项目。
检查题(自测)
- Chatbot、Workflow、Agent 的核心区别是什么?
- 一个 Agent 通常需要哪些组成部分?
- 为什么高风险动作前需要人类确认?
- 为什么强模型不等于可靠 Agent?
- 什么情况下 Workflow 比 Agent 更合适?
参考答案
- Chatbot 主要回答问题;Workflow 按固定流程执行;Agent 围绕目标动态规划、调用工具、观察结果并继续行动。
- 通常包括目标、模型、工具、状态、反馈和控制边界。有些系统还会加入计划器、记忆、评估器和人工确认节点。
- 因为高风险动作会产生真实后果,例如发送邮件、删除文件、发布内容、花钱或处理敏感数据。确认节点能把错误拦在行动前。
- 因为 Agent 的可靠性还取决于工具 schema、权限、状态管理、错误处理、日志、评估和人工确认。模型只是其中一部分。
- 当流程稳定、规则明确、结果可预测、需要审计时,Workflow 往往更合适。
Takeaway
Agent 的核心不是“模型会聊天”,而是模型能围绕目标规划、调用工具、观察结果并继续行动。真正的难点在工具、状态、反馈、权限和评估。能回答是一步,能可靠做事是另一座山。