智能体,还是写死的流程?
这一章讲三件事: 「路线由代码挑」的那条路具体长什么样;它有哪几种固定形状; 以及在什么情况下你应该选它而不是选智能体。
它在全书链条里的位置: 第 01 章给了判定标准,这一章走到标准的另一边去看一眼。 看清楚了你才会明白:接下来九章要教的那套东西,只在「路线事先不知道」的时候才划算。
1. 同一个输入,两条路:先走写死的那条
这一节把一个具体输入放上台,走完第一条路。
书里举的例子是:做一个应用,输入一段代码,输出它翻译成另一种语言的版本1。 我们把它坐实成一个具体输入。
下面走查里的行数和分支结果,是我们为演示编的,不是真实数值。 书里那两张流程图都写着「Figure coming soon」(图稍后补上)2,所以这条走查是我们照文字重建的。
输入: 一段 40 行的 Python 代码,用户要它变成 Go。
| 第几步 | 谁在做 | 手里拿到什么 |
|---|---|---|
| 1 | 模型 | 收到那 40 行代码,被问「这是什么语言」,答:Python |
| 2 | 代码 | 一行判断:上一步答出语言了吗?→ 答出来了,往下走 |
| 3 | 代码 | 再一行判断:Python 转 Go,我手头有现成的转换程序吗?→ 没有 |
| 4 | 模型 | 被第二次叫来:「把这 40 行翻成 Go」,交回 52 行 Go 代码(比原来多 12 行) |
| 5 | 代码 | 把这 52 行交给用户,结束 |
看清楚第 2 步和第 3 步:那两个判断是两行普通的 if,不是模型做的。
如果第 1 步没答出语言(比如那段代码只有几行注释),第 2 步那行 if
会直接走另一条岔路:给用户返回一条失败消息,整件事到此为止——
连问都不会再问模型一句1。
这条路上,模型总共只被叫了两次,而且每一次叫它干什么、叫完之后往哪走, 全都是写代码的人事先排好的。
2. 这条路有名字,而且有固定形状
这一节回答:上面那条路是随手写的 if-else,还是有讲究的东西?
它有讲究。
把一件事拆成固定的几步、按固定的顺序走完,这条流水线叫工作流—— 这个词在软件行业里早就有,不是 AI 带来的。
而上面这条流水线的特别之处在于:它的某几步是叫模型去干的。 书里给这一整类系统一个名字——智能体式工作流: 由代码(而不是模型)决定逻辑走哪条路,但仍然会叫模型来干其中一部分活的系统3。
顺便把一个词说清楚,后面 每一章都会用到:提示词(你发给模型的那段话)—— 第 1 步里那句「这是什么语言」就是一条提示词。
有了这个词,上面那条流水线的正式名字就好说了:它叫提示词链—— 一件事需要一次或多次调用模型,再加上一条代码路径来决定接下来走哪一步4。 「链」指的就是第 1 步的输出被第 4 步接着用的那个串联关系。
这不是学名的堆砌。 知道它叫提示词链,你才能在别人的系统图上认出它, 也才能知道下一节那四种形状和它是同一层的东西。
3. 同一个输入,换智能体走一遍
这一节走完第二条路,并指出两条路真正的分叉点。
书里的智能体版做法是:把「检测语言」和「翻译」这些工具交给模型, 然后只对它说一句「看看输入是什么语言,再挑合适的工具去翻」5。
同样,下面这几步里的具体内容是我们为演示编的。
输入:同样那 40 行 Python。
| 第几圈 | 模型写下什么 | 塞回去的是什么 |
|---|---|---|
| 0 | (还没开始)手里先拿到一张工具清单:detect_language、translate_with_parser | — |
| 1 | detect_language(code=…) | Python |
| 2 | 它把清单又看了一遍,没有能把 Python 翻成 Go 的工具 | — |
| 3 | 不调工具了,自己动笔翻 | 交出 52 行 Go 代码 |
分叉点在哪儿?对比着看第 1 节的表:
| 写死的流程 | 智能体 | |
|---|---|---|
| 「答出语言了吗」这个判断 | 第 2 步,一行 if | 不存在——模型看到 Python 就自己往下走了 |
| 「有没有现成的转换程序」这个判断 | 第 3 步,一行 if | 不存在——模型自己去清单里找了一遍 |
| 找不到工具怎么办 | 事先写好:调模型翻 | 模型自己决定:它选择自己动笔5 |
| 循环 | 没有循环,一条直线走到底 | 有循环 |
注意最后一行,它最容易被误读: 差别不是「有没有循环」。
你完全可以写一个带 while 的写死流程,它照样不是智能体。
真正的差别是:那张路线图被整个撤掉了。 写死的版本里,「先检测、再判断、再翻译」这个顺序是一张图,画在代码里; 智能体版本里没有这张图,只有一堆摊开的工具和一句话。
4. 另外四种写死法,各治什么病
这一节只给一张表,不展开。 理由很实在:这四种形状在这本书里只出现在这一段, 后面九章一次都不再提——它们是外围概念,记住名字和用途就够了6。
| 名字 | 它治什么病 |
|---|---|
| 提示词链(上面那条) | 一件事要分几步做,每步的结果决定下一步走哪儿 |
| 并行化 | 同一件事要几个角度同时看,几次调用一起发出去,结果再合并 |
| 路由 | 先让模型把输入分个类,再按类别派给不同的处理路线 |
| 编排者—工人 | 一个模型把大活拆成小块、分给几个模型去做,最后再由一个模型把结果拼起来 |
| 评估者—优化者 | 一个模型写答案,另一个模型打分;不合格就带着意见退回去重写 |
这五种全都不属于智能体——因为「拆成几块」「派给谁」「转几次为止」这些决定, 都写在代码里,不是模型当场挑的。
5. 怎么选:换来什么、失去什么
这一节给出选择标准,它比前面所有内容都实用。
写死的流程换来的那样东西,书里点名了:确定性—— 同样的输入,每次都走同样的路、得到同样形状的结果3。
这不是个小好处。一条写死的路你可以:
- 测:每条岔路都能单独写测试,跑一遍就知道对不对;
- 算钱:模型被叫几次是固定的,账单可以事先估出来;
- 查:出了问题,能指着说「是第 3 步那行判断错了」。
智能体把这三样全都换掉了。它换来的是:你事先不知道路线的时候,它也能走。
三样东西各值多少:回到第 1、3 节那两条路
光说「能测、能算钱、能查」太抽象。回到本章那个翻译需求,把账摆出来。
下面这张表里「下次可能几次」这类估计是我们为演示编的,不是实测数值。 唯一确定的是两条路这一次各叫了几次模型——那是第 1、3 节数出来的。
| 写死的流程(第 1 节) | 智能体(第 3 节) | |
|---|---|---|
| 模型被叫几次 | 固定 2 次(检测语言 1 次 + 翻译 1 次) | 不固定:这次是 2 次,下次可能 1 次,也可能 5 次 |
| 你能不能事先报价 | 能:2 次 × 单价 | 不能,只能给一个区间 |
| 一次跑多久 | 波动小 | 波动大:多转两圈就多等几秒 |
| 有一条岔路错了,你怎么找 | 指着第 2 步那行 if 说「就是它」 | 要把模型每一圈写下的话都翻出来读 |
| 加一种新语言 | 改代码、重新测那条岔路 | 通常不用改代码——把新工具摆上去就行 |
看最后两行,那才是真正的取舍: 写死的流程把「查错成本」压到最低, 代价是每加一个情况都要动代码;智能体反过来——加情况几乎不要钱,查错要人命。
所以真正该问的不是「哪个更先进」,而是「你这个系统未来一年会不会一直往里加情况」。 一年加两次,写死;一周加两次,再考虑放开。
选择标准
这条路,你事先知不知道? 知道 → 写死。不知道 → 交给模型。
「知不知道」怎么判?三个具体问题,有一个答不上来才轮到智能体:
- 步骤能不能列完? 你能不能在纸上把所有分支画完、且不留「其他情况」这一格?
- 顺序会不会变? 会不会有输入需要先做第 3 步、再回头做第 1 步?
- 要不要中途长出新步骤? 会不会出现「查完发现还得再查一样别的」这种事?
三个都能干脆答上来,就写死。 前面那个工单流水线三个都答得上来, 所以它一行智能体代码都不需要。
这解释了一个常常让人意 外的事实:真正跑在线上的系统里,写死的流程反而更多。 因为绝大多数业务需求,路线是知道的—— 「收到工单 → 分类 → 查知识库 → 生成回复 → 拿不准就转人工」这条路, 你闭着眼都能画出来,没有任何理由让模型每次现想一遍。
Anthropic 那篇被本书引为定义来源的文章,给的建议也是同一个方向: 先用最简单的做法,评测之后仍然不够,再上多步的智能体系统7。
6. 我们的判断:这条分界线在工程上没那么干净
判断(我们的,不是书里的): 书里把两者讲成互斥的两类, 但真实系统通常是混的——外层写死,内层放开。 上面那条工单流水线里,「查知识库」那一步完全可以是一个小智能体: 它自己决定查几次、换几个关键词。外层的五步顺序照样是写死的。 所以「这个系统是不是智能体」往往不是一个能回答的问题, 该问的是「哪一层是写死的、哪一层放开了」。 如果错,会错在: 如果某个系统里模型能改写外层顺序本身(比如它能决定跳过分类那一步), 那这个「外层写死」的说法就不成立,整个系统要按智能体来对待—— 包括按智能体的方式做安全审查。判据是:模型的输出能不能改变下一步是 哪一步。
7. 可带走的
- 同一个需求有两种做法:路线由代码写死(模型只干其中一小段),或者路线交给模型;
- 写死的那类叫智能体式工作流——由代码决定走哪条路,但仍然会叫模型干活;
- 最常见的形状叫提示词链:调一次或多次模型,中间用代码判断走哪一步;
- 分叉点不在「有没有循环」,在于那张路线图存不存在;
- 五种常见形状:提示词链、并行化、路由、编排者—工人、评估者—优化者——全都不是智能体;
- 写死换来的是确定性:能测、能估账、出问题能指到具体某一步;
- 选择标准只有一条:这条路你事先知不知道;知道就写死;
- 「知不知道」拆成三问:步骤能不能列完、顺序会不会变、要不要中途长出新步骤;
- 真正的取舍在最后两行账上:写死把查错成本压到最低,代价是加情况要动代码;智能体反过来;
- 线上跑的多半是写死的,因为多数业务的路线本来就是知道的;
- 真实系统通常是混的:外层写死、内层放开——该问的是「哪一层放开了」。
8. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 代码翻译那个例子、失败分支 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:24(搜「turns it into its equivalent in another language」) |
| 智能体式工作流的定义、确定性 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:24(搜「This is distinct from an agentic workflow」) |
| 提示词链的定义 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:24(搜「This is prompt chaining」) |
| 另外四种形状 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:24(搜「orchestrator-worker」) · :24(搜「evaluator-optimizer」) |
| 写死流程那张图的文字描述 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:26(搜「The figure below shows the prompt chaining workflow」) |
| 智能体版的做法 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:30(搜「By contrast, an agentic approach」) |
| 两者的根本差别 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:34(搜「The chief difference to remember」) |
| 图全部缺失 | Chapter 1. Agentic AI and MCP | text/04-ch01-chapter-1-agentic-ai-and-mcp.txt:28(搜「Figure coming soon」) |