工具、推理-行动循环与护栏 — 从「取信息」跨到「改世界」的那一步
这一章讲三件事: 「接上检索」和「接上工具」看着像同一件事,其实隔着一条很重的线; agent 每一步到底怎么决定下一步走哪儿(那是一个只有四个动作的循环); 以及当工具超时、返回垃圾、或者用户想让它干不该干的事时,该在哪几处设卡。
它在全书链条里的位置: 第 12 章说 agent 是「模型 + 三样东西」。 这一章把第二样(执行动作)和第三样(编排流程)讲透, 第 14 章讲工具多起来之后怎么管,第 15 章讲工具出错时该返回什么。
1. 顶层全景:同一句订票请求,这次走完一整圈
这一章继续用第 12 章那条主走查,但这次不再停在「它办不了」,而是走完:
「帮我找下周二从纽约到旧金山的航班,再订个联合广场附近的酒店。」
① 推理:「用户要机票和酒店两件事。**先办机票。**」
▼
② 行动:调订票接口
▼
③ 观察:拿回 3 个航班选项
▼
④ 推理:「他落地之后要住联合广场附近。**现在查酒店。**」
▼
⑤ 行动:调酒店接口
▼
⑥ 观察:拿回 5 家酒店
▼
⑦ 推理:「两边都齐了,整理成一条话给用户。」→ **最终答案**
─────────── 然后把这条链拆三次,每次拆掉一个部件 ───────────
拆一:**把工具整个拔掉**,问「巴黎现在天气怎么样」
→ 它答「巴黎现在晴,25°C」—— **它根本不知道,这是编的**
拆二:**让接口超时**
→ 有兜底就答「我这会儿查不到,请稍后再试」;没兜底它会编一个
拆三:**让接口返回 −273°C**
→ 输出校验按「地表温度合理范围 −90 到 60」把它判为无效数据丢掉
图说:①→⑦ 是这一章的骨架,三次拆解各对应一条工具可靠性策略。
航班数 3、酒店数 5 是为演示设的;−90 到 60 这个范围是书里的原数。
先把这一章第一句话就要立住的那条线画清楚。
2. 那条分水岭:取回来看,还是伸手去改
这一节回答一个第 05 章留下的问题,它是整个第二层的入口。
先看现象:两件事看着一样,后果差一个量级
第 05 章讲过:模型开口说「我要调 get_weather,参数是巴黎」,
我们的代码去执行,把结果塞回去让它接着写。 这一章讲的工具,动作看起来完全一样。
但请对比这两句:
| 它说要调什么 | 执行之后世界变了吗 |
|---|---|
search_flights(纽约→旧金山, 下周二) | 没变。 只是把已有的信息取了回来 |
book_flight(航班号 UA523, 乘客张三, 用尾号 4321 的卡付款) | 变了。 钱扣了、座位占了、确认信发出去了 |
书把这条线画得很直接:
检 索增强是被动地取信息; 而 agent 能主动执行会改变外部系统状态的工具。 取到航班选项(被动)之后,它能真的调接口把票订下来、通过邮件服务发确认信、更新用户的日历。 ——这些是单靠检索做不到的。这种「能行动」的能力,才是把一个信息检索系统变成真正 agent 的那一步。1
这句话请当成第二层的定义句。 它解释了第 12 章开头那句「赌注换了量级」: 被动取信息取错了,用户看到一个错答案;主动执行执行错了,钱已经出去了。
为什么这一条要单独讲:它决定你该在哪儿设卡
如果一个动作只是取信息,出错的代价是「答得不准」,补救办法是重新取一次。 如果一个动作会改变外面的世界,出错就没有「重来一次」这回事 ——票已经订了、信已经发了、记录已经删了。
所以后面三章那些看起来很啰嗦的东西——校验、兜底、护栏、审批、沙箱—— 全都是从这一条线长出来的。 线的这一边不需要它们,线的那一边缺一样都不行。
3. 工具是最有效的防幻觉手段之一,但它自己也会坏
这一节讲工具带来的收益和它带来的新问题,两件事要分开看。
收益:它把「猜」换成了「查」
第 02 章讲过幻觉为什么发生:模型在开口之前,没有任何一步去对照真实世界核对。 书在这里把这一点拆成三条它做不到的事2:
| 它做不到 | 后果 |
|---|---|
| 核对自己的回答 | 它拿训练时读过的东西作答,而那些东西可能过时或者本来就不全 |
| 拿到外部知识 | 没有实时数据,它只能靠那份冻住的快照 |
| 给出可核实的证据 | 回答里没有出处,用户无从验证 |
接上工具,这三条同时被治: 实时数据走接口(股价、天气)、 结构化信息走数据库(客户档案、订单历史)、要动手的事走外部系统(订机票、发邮件)3。
走查的「拆一」就是这个对照:
没有工具: 用户问「巴黎现在天气怎么样」
→ 它答「巴黎现在晴,25°C」
→ **这是幻觉。它不知道,但它答得很有把握**
有工具: 用户问同一句
→ 它说「我帮你查一下」→(调天气接口)
→ 它答「巴黎现在 20°C,多云」
图说:**同一个模型、同一个问题,差别只在中间那一步有没有真的去查。**
这两句回答是书里的原样。
书给的两项研究4:
- 一个装了自我评估机制的模型(也就是它会先掂量「 这题我到底知不知道」), 对 77.2% 的「它其实不知道的问题」正确地选择了去调接口查;
- 给写代码的模型接上实时的接口文档检索能提高表现, 而且对冷门接口提升最明显——那恰恰是它幻觉率最高的地方。
第二条尤其值得记: 它说明工具的收益不是均匀的。 模型越不熟的地方,工具帮得越多。
新问题:工具会超时、会限流、会返回垃圾
书的原话很直白:再好的工具也会因为超时、访问频率被限制、或者网络问题而失败。5
(「访问频率被限制」这件事有个常用说法: 服务方为了防止被打垮, 规定每分钟最多调多少次,超了就拒绝——这叫限流。)
所以接上工具不是终点,是新一轮问题的起点。 下一节讲三条对策。
4. 三条工具可靠性策略,一条都不能少
书把它们并列成三条,而它们各治一种不同的坏法6。
| 策略 | 它治的是什么 | 走查上的哪一次拆解 |
|---|---|---|
| ① 把回答锚在工具结果上 | 治「它明明能查却懒得查,自己编一个」 | 拆一 |
| ② 失败时兜底 | 治「工具挂了,它拿不到数据,于是编一个」 | 拆二 |
| ③ 校验工具输出 | 治「工具没挂,但返回的是垃圾,它照单全收」 | 拆三 |
① 锚定:凡是能查的,一律去查
做法本身很平常: 把接口和数据库接上,让 agent 遇到这类问题时走查询这条路, 而不是从自己那份冻住的快照里凑一个答案。
关键在于「一律」。 只要留了一条「查不到就自己发挥」的口子, 那条口子就会在最需要准确的时候被走。
② 兜底:优雅地失败,而不是编一个
这一条的措辞值得原样记住:
兜底逻辑保证 agent 优雅地失败,而不是编造一个答案。7
走查拆二的具体样子:
调天气接口 → 超时,什么也没拿到
▼
没有兜底: 它手里没有真数,但它还是要写出一段话来
→ 「巴黎现在晴,25°C」 ← **又编了一个**
▼
有兜底: 捕获这次失败,直接返回一句写死的话
→ 「我没能查到巴黎的天气,请稍后再试,或者换一个城市。」
图说:**关键不在「有没有报错」,在「拿不到数据的时候,它嘴里说出来的是什么」。**
上面那句兜底话取自书里的示例。
这条和第 12 章那条误差级联接得上: 一次工具失败如果被兜底接住, 它只影响这一步;如果被编造盖过去,它会带着一个假数据继续往下走十步。
③ 校验:工具返回的东西也要过一道
这是三条里最容易被跳过、也最有意思的一条。 工具没坏,接口正常返回, 但返回的内容不合理。
书给了一个具体到可以照抄的判据:
天气接口返回: temperature = -273
▼
校验: 地表温度的合理范围是 **−90 到 60 摄氏度**
▼
−273 不在这个区间里 → **判为无效数据,丢掉**
▼
agent 对用户说:「我拿到的天气数据无效。」
—— 而不是「巴黎现在 −273°C」
图说:−90 到 60 是书里给的原数(它对应地球有记录的极端低温和高温)。
**−273 这个具体的值是我们为演示挑的**——它正好是绝对零度附近,
是典型的「接口出故障时的占位值」。
书的校验函数还做了一件事:先确认返回的数据里有没有那个字段,再看值合不合理8。 这两步不能合并——字段根本不存在的时候去取值,程序会直接崩,而不是给你一个坏数。
判断(我们的,不是书里的): 这三条策略的真正共性是 「不许在信息缺失的地方让模型自由发挥」。 锚定堵的是「懒得查」,兜底堵的是「查不到」,校验堵的是「查到的是假的」 ——三个洞,同一种堵法:在它开口之前,把一个确定的东西塞给它。 如果错,会错在: 如果你的场景本来就要它发挥(写文案、出创意), 这套堵法会把它变得很死板。 判据是:问一句「这一步答错了,用户会不会当真」——会,就堵;不会,就放。
5. 它凭什么知道下一步该干什么
这一节讲第 12 章那三样东西里的第三样:编排。
先看现象:同一句话,可以走错好几种走法
主走查那句「找航班,再订联合广场附近的酒店」,书列了它必须做对的四件事9:
- 看出这里面有两个子任务(订机票、订酒店);
- 用订票工具按指定日期查航班;
- 用订酒店工具在联合广场找酒店;
- 把结果给用户看,用户点头之后才真正下单。
书说得很实在:没有一套决策机制,这四步里的任何一步都可能崩。 用错工具、看不出任务之间的先后依赖、 甚至顺序颠倒——先把酒店订了,航班却还没确认。
两条路:写死规则,还是让模型自己想
| 规则式 | 让模型自己推理 | |
|---|---|---|
| 怎么做 | 预先写好逻辑:句子里出现「flight」就调订票接口 | 把用户的话交给模型,让它判断需要哪几步、用哪些工具 |
| 好处 | 简单、透明,出了问题一眼看得出走的哪条分支 | 灵活,能处理没预料到的说法 |
| 命门 | 僵硬 | 要更强的模型、更多算力,而且必须仔细评测才敢信 |
书给的那个命门例子非常具体,值得记:
用户问「帮我找联合广场附近能带宠物的酒店」—— 一套纯规则的系统,如果没有人专门为「能带宠物」写过一条规则,就处理不了这个条件。10
这个例子的要害不是「规则不够多」,是规则的数量必须提前穷举。 用户能说出来的条件是无穷的,而你写规则的时间是有限的。
那个循环:推理 → 行动 → 观察 → 再推理
这是这一章的承重机制,后面每一章的 agent 都建在它上面。
先说清它解决的问题: 一个多步任务,能不能一次想清楚全部步骤再动手? 不能。 因为第 二步该干什么,取决于第一步查回来什么 ——航班查回来只有下午的班次,后面的酒店安排就得跟着变。
所以做法是:想一步、做一步、看结果、再想下一步。
推理(Reasoning) ── 想清楚下一步该干什么
▼
行动(Acting) ── 真的去做(调一个工具、取一份数据)
▼
观察(Observing) ── 看这一步的结果,把它并进下一轮的思考里
▼
↺ 重复,直到给出最终答案
图说:**四个动作里,「观察」是让它区别于「一次性规划」的那一个。**
没有观察,它就是在闭着眼睛按预定剧本走。
这套做法有名字:ReAct —— Reasoning(推理)+ Acting(行动)拼起来的, 你在任何一份 agent 框架的文档里都会撞见这个词11。
主走查第 ①–⑦ 步就是它跑一遍的样子(那七步是书里的原样,只有航班数和酒店数是我们为演示设的)。
多个答案都说得通的时候:同时铺开几条支线
书还给了一个变体。 当一个问题有好几个都合理的解法时,不必一条道走到黑。
书的例子:「怎么降低我们欧洲客户的运费?」12
支线 1: 换新的承运商
支线 2: 把仓库合并
支线 3: 谈批量折扣
→ 三条各自评估、各自推演结果 → 选最省钱的那一条
图说:这套「同时铺开几条再挑」的做法,第 04 章讲提示词时已经见过一次
(那里叫思维树,用来解 Game of 24)。**同一个东西,这里换到 agent 身上用。**
6. 检索 + 动作合在一起:那个只会引用馆藏的图书管理员
这一节把第 05 章那条线和这一章这条线合起来,书自己起了个名字。
书给的比方:传统的检索增强系统像一位极其博学、但只能引用馆内藏书的图书管理员。 它能告诉你埃菲尔铁塔多高、巴黎的春天多美, 但你问它「现在下不下雨」「明天塔顶的票还有没有」,它就哑了。13
这个比方到此为止。 说清楚的那件事是: 取回来的东西再全,也全是「已经存进去的」;而世界现在正在发生的事,不在库里。
做法是把两样并排挂上:一个工具去查向量库里的资料,一个工具去调实时接口。 关键的演示是: 当用户问「跟我讲讲埃菲尔铁塔,顺便说说巴黎现在的天气」时, agent 自己判断出这里面有两类不同的信息需求,分别选对工具,再把两份结果合成一条回答14。
这套「检索 + 动作」的组合,书叫它 Agentic RAG。 我们把它放在这里讲,是因为它本质上就是上一节那个循环 + 第 05 章那套检索 ——不是一种新架构,是两样已知东西的组合。
7. 护栏:拦住明说的容易,拦住换个说法的不容易
这一节讲这一章第二个承重词,而它最有价值的地方是书自己承认它不够用。
先看现象:同一个意图,换个词就溜过去了
假设你做的是一个旅行助手,你不希望它去聊加密货币投资。 最直接的做法:列一张词表,回答里出现「crypto」就拦下来。
书给的示例正是这样: 把要拦的内容分成三类——跑题的(加密货币、赌博、医疗、法律)、 敏感的(个人数据、财务、隐私)、不当的——然后逐词匹配15。
这套东西的名字叫护栏:一道设在模型和用户之间的检查, 把它的回答约束在它该干的事和安全的边界之内。
书自己给它打的补丁,是这一节最该带走的部分
虽然这个例子用的是简单的规则法,但关键词匹配在生产里很脆: 用户换个同义词或者换个说法就能轻松绕过去。 生产系统通常用「让另一个模型来判」的护栏,按语义而不是按词表来判断。16
为什么词表一定会漏,道理和上一节规则式决策的命门是同一条: 你要拦的是一个意图,而意图能被无穷多种说法表达。 你写的词表是有限的,而绕过它只需要找到一个你没写进去的说法。
「让另一个模型来判」这个做法在这本书里已经是第三次出现了: 第 09 章让模型给检索质量打分、第 04 章让模型交叉比对自己的多个答案、 这里让模型判 断一段回答安不安全。第 17 章还会有第四次(那里会讲它自己的毛病)。
另外两道:交叉核对,以及把步骤摊开给人看
书在同一节里还给了两样,它们和护栏不是一回事,但都是「不让它一个人说了算」17:
| 做法 | 具体怎么做 | 它治什么 |
|---|---|---|
| 交叉核对 | 拿两个互相独立的来源查同一件事,两边一致才算「已核实」,不一致就标出来让用户澄清或者转人工 | 单一来源本身就是错的 |
| 把中间推理步骤显示给用户 | 界面上直接写出「我要用天气工具查巴黎当前气温」 | 用户看不见它怎么想的,就无从判断它有没有走歪 |
交叉核对的例子是股价:两个接口都说 800,才回「已核实:特斯拉 800 美元」; 两边不一样,就直接把两个数都报出来说「发现不一致」。
第二样值得多说一句,因为它是产品设计而不是技术:
书说,用户看不到推理过程时会失去信任; 而把步骤摊开,用户就能在它走歪的时候当场纠正——这反过来提高了最终结果的正确率。18
书举的实例是一个把大模型和实时网页搜索结合起来的问答产品, 它把 agent 用了哪些来源、走了哪些步骤都显示在界面上。 书说:同时展示来源和推理步骤,已经成了现代 AI 界面的标配做法。
8. 它已经不是演示了:四个在跑的生产系统
这一节是书里最新的一块,而它的数字必须带着提醒读。
| 组织 | 做了什么 | 书给的数 |
|---|---|---|
| 一家大型医疗集团 | 一个「在旁边听着」的病历 agent:录下医患对话,自动生成临床病历 | 从 20 位医生的试点起步,原计划推给 400 位,因为需求太旺扩到 800 多位;职业倦怠率下降 21%;五分之三的医生说更愿意延长临床生涯;80% 的医生在问诊时终于是在看病人而不是在敲键盘 |
| 一家大型银行 | 450 多个 AI 用例的生态;一套内部助手服务 20 万员工;客服中心的问答 agent | 理财顾问的响应时间改善 95%;开发者生产力提升 10–20%;银行预测三到五年内每位顾问能多服务 50% 的客户 |
| 一家金融技术服务商 | 20 个专门做文档处理的 agent | 2024 年 11 月单月处理 5 万份文档;贷款文档的自动化率超过 90%,人只看 AI 标出来的少数边缘情况 |
| 一家服装零售商 | 个人购物助理 agent,管尺码、配送、退货这类常规问题 | 购物车放弃率和客服成本都显著下降(书没给具体数) |
行业整体的四个数19:超过一半的企业在用 AI 编程助手; 近三分之一的公司上了客服机器人;检索增强这套架构的采用率一年之内从 31% 涨到 51%; 而真正能自主规划、执行、调整的 agent 架构,占全部 AI 实施的 12%。
最后那个 12% 是这一整节里最该记住的数,因为它是唯一一个自带参照物的: 同一句话里,51% 的系统用了检索,只有 12% 用了真正的 agent。 换句话说,读到这里为止,这本书的第一层已经普及,第二层还只是少数。
判断(我们的,不是书里的): 这四个案例的数字都朝一个方向偏 ——它们全是成功案例,而且全部由当事组织自己发布。 「倦怠率下降 21%」这类数没有对照组(也就是另找一批条件相似、但没用这套系统的医生, 拿两边的数去比),也没有统计口径,「响应时间改善 95%」没说基线是多少。 它们能证明的只有一件事:这类系统确实在生产里跑着,不是演示。 能证明的到此为止,不要拿它们去论证「所以你也能提升 21%」。 如果错,会错在: 如果这些组织后来公布了带对照组的完整数据,这条批评就过严了。 判据是:看数字旁边有没有「和什么比」——一个都没有,就只当存在性证明读。
9. 作者的判断与证据
书里给了证据的:
| 说法 | 证据是什么 |
|---|---|
| 装了自我评估机制的模型对 77.2% 的未知问题选择了去查 | 一个具体的数,引自一项研究。但书没给这项研究的题目和年份,我们没能核到一手来源 |
| 接上实时接口文档能提升代码模型的表现,冷门接口尤甚 | 一条有方向的结论,但同样没有可核的出处 |
| 温度校验范围 −90 到 60 | 一个具体的判据,而且可以自己核(它对应地表有记录的极端温度) |
| 关键词护栏在生产里很脆 | 一条自我批评,书没给数据,但它给了机制:同义词和换个说法就能绕过 |
| 四个生产案例的各项数字 | 全部来自当事组织自己发布的材料,没有对照组 |
| 12% 的实施用了真正的 agent 架构 | 一个具体的比例,而且同句给了 51% 这个参照 |
作者的推测或没给证据的:
| 说法 | 它是什么 |
|---|---|
| 「工具集成是减少幻觉最有效的手段之一」 | 一句判断。 「最有效之一」没有任何比较基准 |
| 规则式 vs 模型推理的优劣对照 | 一张经验表,没有实测数据 |
| 「同时展示来源和推理步骤已成为现代界面的标配」 | 一句行业观察 |
| 「三到五年内每位顾问能多服务 50% 客户」 | 这是那家银行自己的预测,不是已发生的事实——书把它和已实现的数字排在同一段里,读的时候要分开 |
10. 边界与局限
-
三条工具策略只在单个工具上讲。 工具有十个、二十个的时候怎么管、模型凭什么知道有哪些工具 ——这一章一个字没提,第 14 章才讲;
-
工具失败之后该给模型返回什么,这一章只说了「兜底」。 而兜底返回的那句话该长什么样、 模型看到不同形状的错误会做出什么不同的下一步——第 15 章才是正经讲这件事的地方;
-
护栏只给了「关键词表很脆」这个诊断,没给药方。 书自己把药方推给了后面 (它写的是第 10 章,但那套多层安全系统实际在原书第 11 章,也就是我们的第 21 章 ——这是原书交叉引用没校对的又一处);
-
那个「让 AI 给 AI 打分再拿去改进模型」的做法只有一句话。 书在这里提了一下就推给后面, 完整的东西在我们的第 20 章;
-
没有讲权限:工具调用(也就是这一章从头讲到尾的那件事——模型开口说要调哪个工具、 我们的代码去执行)该不该被允许,书没碰。 一个能真的下单、能真的删记录的 agent, 凭什么被允许执行这些动作、谁批准、出事怎么回滚——这一章完全没碰。 第 15 章讲载具和沙箱时补上一部分,但「审批」这件事全书都讲得很浅;
-
循环什么时候停,书没讲。 推理 → 行动 → 观察一直转下去, 万一它一直调同一个工具却毫无进展呢? 书只在第 12 章那句 agent 定义里 提过一次「要有防死循环的控制」,这一章展开循环时反而没有回到这个问题。
11. 可带走的
全章那条走查,一行写完: 「找航班,再订联合广场附近的酒店」→ 推理「先办机票」→ 行动:调订票接口 → 观察:3 个航班 → 推理「再查酒店」→ 行动:调酒店接口 → 观察:5 家酒店 → 推理「整理给用户」→ 最终答案。 然后拆三次:拔掉工具问巴黎天气,它答「晴,25°C」(编的); 让接口超时,兜底让它说「查不到,请稍后再试」而不是编; 让接口返回 −273°C,校验按「−90 到 60」把它丢掉。
- 那条分水岭:检索是被动取信息,工具是主动改变外部系统的状态—— 真的下单、真的发信、真的改日历。这一步才把检索系统变成 agent;
- 线的两边设卡的必要性完全不同: 取错了可以重取,做错了没有「重来一次」;
- 工具治幻觉,治的是三件具体的事: 它没法核对自己、没法拿到外部知识、没法给出可核实的证据;
- 工具的收益不均匀:模型越不熟的地方,工具帮得越多(冷门接口提升最明显);
- 接上工具不是终点:工具会超时、会被限流、会返回垃圾;
- 三条策略各 治一种坏法: 锚定治「懒得查」、兜底治「查不到」、校验治「查到的是假的」;
- 兜底的标准是「优雅地失败,而不是编一个」——这句话是判据,不是口号;
- 校验要分两步:先确认字段在不在,再看值合不合理(温度必须在 −90 到 60 之间);
- 规则式决策的命门不是规则不够多,是条件必须提前穷举—— 「能带宠物」没写过就处理不了;
- agent 的骨架是一个四动作循环:推理 → 行动 → 观察 → 再推理,直到给出答案。 这套做法叫 ReAct;
- 循环里最关键的是「观察」——没有它,agent 就是闭着眼睛按预定剧本走;
- 护栏用词表做一定会漏,因为你拦的是意图,而意图有无穷多种说法;
- 交叉核对的判据是「两个独立来源都说同一个数才算已核实」,不一致就转人工;
- 把中间推理步骤显示给用户,不只是好看——它让用户能在它走歪时当场纠正。
12. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 被动检索 vs 主动动作那条分水岭 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:524(搜「tools used for retrieval and tools used for action」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:530(搜「into a true agent」) |
| 幻觉的三条成因(模型做不到的三件事) | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:496(搜「Hallucinations occur because」) |
| 工具能接的三类东西 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:507(搜「APIs for real-time data」) |
| 巴黎天气的前后对照 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:544(搜「sunny and 25」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:558(搜「20°C and cloudy」) |
| 77.2% 那项研究 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:562(搜「significantly improve factual accuracy」) |
| 锚定、兜底、校验三条 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:578(搜「ALWAYS ANCHOR RESPONSES」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:602(搜「IMPLEMENT FALLBACK LOGIC」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:621(搜「VALIDATE TOOL OUTPUTS」) |
| 温度合理范围 −90 到 60 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:630(搜「-90 <= temperature」) |
| 决策要做对的四件事 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:680(搜「the agent needs to」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:689(搜「booking a hotel before confirming」) |
| 规则式 vs 模型推理、能带宠物那个例子 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:697(搜「Rule-based systems rely on predefined logic」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:704(搜「pet-」) |
| 推理-行动-观察循环与那条订票走查 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:729(搜「Here is how ReAct works」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:742(搜「I should start with the」) |
| 同时铺开几条支线 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:764(搜「reduce shipping costs」) |
| 只能引用馆藏的图书管理员 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:772(搜「planning a trip to Paris」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:780(搜「knowledgeable librarians」) |
| 交叉核对 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1018(搜「Cross-referencing adds redundancy」) |
| 护栏与「关键词匹配在生产里很脆」 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1061(搜「blocked_categories」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1099(搜「keyword matching is brittle」) |
| 把推理步骤显示给用户 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1114(搜「lose trust in agents when reasoning is opaque」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1130(搜「both sources and reasoning steps」) |
| 四个生产案例 | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1159(搜「Burnout prevalence dropped」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1177(搜「response times improving by 95%」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1194(搜「processed 50,000 documents」) |
| 行业采用率与 12% | Chapter 6: Creating Effective AI Agents | text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1216(搜「from 31% to」) · text/09-ch06-chapter-6-creating-effective-ai-agents.txt:1218(搜「truly agentic」) |