🐦 第1章 智能体概述
📄 一句话概括

大模型只会一件事:给定前文,预测下一个词。 就这一件事,让它天然缺三样:不知道新事、动不了手、记不住刚才。 Agent 补的正是这三样——检索补知识、工具补手脚、循环补多步。 这一节用六个任务画出这条分工线,再看教材列的七个行业为什么都落在同一边。

📝 本章和前面几章的关系

前两节讲了「什么值得做」和「由什么构成」,这一节讲「里面那个模型到底贡献了什么」。 讲清楚这一点,后面看到「接入 DeepSeek 大模型」这一步就不会以为换个模型能解决所有问题。 也是给第 5 章的知识库、第 6 章的提示词埋伏笔:那两章解决的正是模型缺的头两样。

一、大模型只会一件事

给它一段前文,它算出下一个词最可能是什么,再把那个词接上去,重复。整段回答就是这么长出来的。 这一件事很强,强到看起来像会推理、会总结、会翻译。但它带来的三个局限,任何提示词技巧都改不掉。 第一,它不知道今天的事。 训练数据有个截止日期,之后发生的一概不知。 你问它明天的天气,它只能按季节编。

第二,它动不了手。 它能写出「已为您取消订单」这句话,但订单还在。 文字和动作之间隔着一次接口调用。 第三,它记不住刚才。 每次调用都是从头看一遍你给的这段文本。所谓「记住」,是把历史又贴了一遍。

二、Agent 补的三样

补第一条,叫检索。回答之前先去资料里捞一段相关的,塞进前文。第 5 章整章讲这个,名字叫 RAG。 补第二条,叫工具。 把「取消订单」变成一个真能调的接口,模型输出一个调用请求,外面执行,再把结果告诉它。 第 3 章讲插件,就是这件事的产品化。 补第三条,叫循环。一次说不完就分几次说,每次带上前面的结果。 第 4 章的工作流和第 1 章的循环是同一个东西的两种形态:一个由模型决定下一步,一个由图纸决定。

三样补完,大模型还是那个大模型,权重一个都没变。变的是它周围多了查、做、再来的通道。

三、六个任务,一条线就分开了

演示里六个任务按三个维度打分:要不要外部数据、要不要多步、有没有副作用。 只有两个是「模型就够」:把这段话译成英文、给这篇新闻起三个标题。 共同点是输入全在手上,结果不用核——翻错了你一眼能看出来,标题起得不好换个就是。 要外部数据的四件,都得给工具。 天气、求表里的和、查订单、发群消息。不给工具,模型只能编。 这是全书最贵的一条经验,也是新手项目翻车的第一原因。

「查订单」还多一个多步:先问单号、再查库、再组织话术。一步说不完。 「定时发群」多一个有副作用:它会真的把消息发出去,发错了收不回来。 这一条决定了它必须有「先给人看一眼」的环节。

四、七个行业,落在同一边

教材列的场景是:新媒体运营、教育、短视频、家装、智能客服、办公、市场宣传、旅游。 看着杂,其实全落在「要外部数据 + 要出成品」这一边,没有一个落在「模型就够」那边。 它们的共同结构是:输入很杂(一张图、一条链接、一段口述),中间要查资料(产品库、素材库、 知识库),最后要交一个成品(文案、海报、视频、答复)。

这个结构正好是工作流的形状:三个环节,每个环节换一种能力。所以这本书九章案例全是工作流,不是巧合。 反过来,如果某个场景的输入很干净、结论不用核,那它根本不需要做成产品——打开对话框问一句就完了。

五、分工一句话

模型负责「怎么说」,Agent 负责「说什么之前先干什么」。 这两件事的优化手段完全不同。前者的手段是提示词、示例、格式约束; 后者的手段是节点、工具、检索、分支。 新手常犯的错是拿前者的手段去解后者的病:模型答不出公司政策,就去改提示词,改二十遍还是编。 正解是给它一个知识库。

所以看一个项目好不好,先看它把问题归到了哪一边。归错了,越努力越远。

六、动手 Demo:六个任务,三个维度

六个常见任务,逐条标三件事:要不要外部数据、要不要多步、有没有副作用。 标完用一条规则推结论,再看结论跟直觉对不对得上。

TASKS = [
    ('把这段话译成英文',       0, 0, 0),
    ('查明天宜昌的天气',       1, 0, 0),
    ('把这张表第三列求和',     1, 0, 0),
    ('给这篇新闻起三个标题',   0, 0, 0),
    ('客户问订单到哪了,回答他', 1, 1, 0),
    ('每天八点把这周数据发群里', 1, 1, 1),
]

def verdict(ext, multi, side):
    if side:  return 'Agent + 定时触发'
    if multi: return 'Agent(多步)'
    if ext:   return '模型 + 一个工具'
    return '模型就够'

实跑输出:

--------------------------------------------------------------------
六个任务:哪些非 Agent 不可
--------------------------------------------------------------------


  ① 六个任务逐个判:三个维度一画就清楚
  --------------------------------------------------------------------

| 任务 | 外部数据 | 多步 | 副作用 | 结论 |
|---|:---:|:---:|:---:|---|
| 把这段话译成英文 | — | — | — | 模型就够 |
| 查明天宜昌的天气 | 要 | — | — | 模型 + 一个工具 |
| 把这张表第三列求和 | 要 | — | — | 模型 + 一个工具 |
| 给这篇新闻起三个标题 | — | — | — | 模型就够 |
| 客户问订单到哪了,回答他 | 要 | 要 | — | Agent(多步) |
| 每天八点把这周数据发群里 | 要 | 要 | 要 | Agent + 定时触发 |

  六个里只有两个是「模型就够」:翻译、起标题。共同点是输入全在手上、结果不用核。
  要外部数据的四件,都得给工具——不给工具,模型只能编。这是全书最贵的一条经验。
  「查订单」多一个「多步」:先问单号、再查库、再组织话术,一步说不完。
  「定时发群」多一个「副作用」:它会真的把消息发出去,发错了收不回来。
  ! 三个维度里,只看「要不要外部数据」就能筛掉一半不该做 Agent 的活。

  ② 反过来:这三种别做 Agent
  --------------------------------------------------------------------

| 情形 | 例子 | 该用什么 |
|---|---|---|
| 答案唯一且能算 | 加减乘除、日期差 | 代码节点两行就完了,别让模型算 |
| 每次都一模一样 | 固定格式的报表 | 工作流比 Agent 稳,也便宜 |
| 错了没法发现 | 给领导的结论 | 连你自己都验不了,就不该让它自己跑 |

  这三条不是「Agent 做不到」,是「用了更贵、更慢、更容易错」。

①判据只有三个,但足以把六个任务分成四档。 注意「外部数据」这一列最值钱:它一票就能否掉一半不该做 Agent 的活。 ②两个「模型就够」的共同点值得多看一眼:输入全在手上,结果不用核。 翻译错了你读得出来,标题不好换个就行——这类活不要架子。 ③「查订单」这一行三个维度里中了两个。它难不在回答,在于先得知道问的是哪一单。 这就是多步的代价:每一多一步,就多一个出错的地方。 ④最后一行中了三个。副作用这一列一旦打勾,讨论的就不是「能不能做」,而是「怎么保证发错了能撤回」。 ⑤第二张表是反向清单。三条里最容易被忽略的是第三条:错了没法发现。这一条不是技术问题,是责任问题。

30 秒实验

  1. 给你自己的场景画这三列。如果「外部数据」打勾、「副作用」也打勾,先别做,先把撤回方案想出来。
  2. 找一句你最近改过五遍以上的提示词。 判断它治的是「说不清」还是「不知道」——如果是后者,改提示词没用。
  3. 列三个你行业里的活,看有几个落在「模型就够」这一档。它们不该做成产品。

常见误区

  1. 「接个大模型就什么都能答。」大模型不知道你公司的事,也不知道今天的事。这两样只能靠检索补。
  2. 「RAG 就是搜索。」搜索给你十条链接,RAG 给你一段能直接进提示词的文本,还带出处。 这一步的差别决定了模型会不会编。
  3. 「副作用可以后加开关。」开关是给「已经想清楚边界」的人用的。没想清楚,开关只会让你更敢放它跑。
自测三问(点开对答案) 1. 大模型天生缺哪三样? —— 不知道新事、动不了手、记不住刚才。分别靠检索、工具、循环来补。 2. 为什么「把这张表第三列求和」也算要外部数据? —— 因为数据在表里,不在模型的前文里。它得先读到那些数字,才能算——这就是工具。 3. 什么场景根本不值得做成产品? —— 输入干净、结论不用核、一次就能答完的。打开对话框问一句就够,做成产品只是多绕几层。

分工清楚了,最后一个现实问题是:不会写代码的人怎么入局,会写代码的人又能走到哪一步。 下一节把三条路摆出来,也给出一个三十行的最小骨架。

相关笔记