《智能体设计模式》第 1 章思考题解答

来源:bojieli.github.io/ai-agent-book · 第 1 章 整理日期:2026-08-11

本章核心素材:感知(眼睛)/ 行动(手脚)/ 策略(大脑)三维分析框架;上下文五要素(系统提示词、工具定义、用户消息、模型回复、工具执行结果);实验 1-1 消融实验;护栏三层(输入/执行/输出);工作流 vs 自主 Agent;人工干预机制。

题 1(★):只能给 Agent 系统加一项能力——更强的模型、更丰富的上下文,还是更多的工具?

默认选择:更丰富的上下文。

本章消融实验的核心洞察是:“上下文决定了 Agent 能看到什么,而 Agent 只能基于它看到的信息做决策。“上下文是模型能力与现实世界之间的接口——模型再强,看不到关键事实就只能瞎猜;工具再多,没有上下文告诉模型"何时该用、用完结果如何”,反而扩大选择难度、降低工具选择准确率。且上下文工程通常是三者中最便宜、迭代最快的杠杆。

选择会改变的条件(用失败归因诊断):

• 信息都看到了但决策错误(推理断裂、多步逻辑崩盘)→ 瓶颈在模型,选更强的模型;
• 策略正确但缺少事实(不知道库存、看不到报错)→ 选上下文;
• 知道该做什么但没有手段(没有写文件权限、无法访问外部系统)→ 工具是硬约束,选工具;
• 任务本身感知受限时(如操控 GUI 却拿不到截图/DOM),优先补感知模态——本质也是上下文。

一句话:先诊断瓶颈在哪一环,再投资哪一环;无诊断信息时,投上下文的期望收益最高。

题 2(★★★):ReAct 循环中累计缓存读取量随轮数近似二次方增长,如何降低?

增长来源: 第 t 轮调用模型时,上下文 ≈ 静态前缀 + 前 t−1 轮轨迹,长度约为 L₀ + t·Δ(每轮新增的思考+工具调用+结果近似常数 Δ)。T 轮累计读取量为 Σ(L₀ + t·Δ) ≈ L₀·T + Δ·T²/2,即 O(T²)。即使有 prompt caching,重复读取的前缀只是降价,总量仍是二次方。根本出路是给每轮上下文长度封顶——单轮上下文压到常数上限 M 后,累计量变为 O(T·M),线性。

具体手段:

1. 滚动摘要/历史压缩:轨迹超过阈值后,把较早轮次压缩成摘要(保留关键决策、事实、错误),替换原始消息。这是把 O(t) 变回有界的核心手段。
2. 工具结果瘦身:工具结果(整个网页、整个文件)往往是最大的块。截断、只保留与当前子目标相关的片段,或把大结果存到外部、上下文里只留引用和摘要。
3. 子 Agent 分解:长任务拆成子任务,每个子 Agent 用全新的小上下文执行,只向父 Agent 返回结论摘要。一条 O(T²) 大轨迹变成多条 O(tᵢ²) 小轨迹(Σtᵢ=T),平方和远小于和的平方。
4. 滑动窗口 + 状态外置:用任务清单/进度文件等紧凑结构保存状态,每轮只注入"当前状态 + 当前步骤”,而非全部历史。
5. 分层规划:规划者维护紧凑的全局状态,执行者只拿当前步骤的上下文。

权衡: 压缩会丢信息,丢错信息会导致重复劳动甚至循环,摘要要优先保留事实、决策和失败教训;同时保持静态前缀(系统提示+工具定义)完全稳定,让缓存命中率最大化——不降低增长,但降低单价。

题 3(★★):“模型即 Agent” 与 Harness 工程日益重要,两个趋势如何共存?Agent 框架未来的核心价值?

两者不矛盾,因为 Harness 的职能发生了迁移:

• 早期框架要"教"模型当 Agent(手写 ReAct 模板、解析文本里的动作),这部分被模型内化了——模型经强化学习训练后原生就会规划、调用工具、自我修正。框架不再微管理"怎么思考"。
• 但模型越自主,单次决策的"爆炸半径"越大,而模型本身是概率性的、无状态的、无法自我担保合规。Harness 的重心转向本章定义:上下文管理 + 工具接口 + 约束 + 验证 + 纠正。类比:发动机越强,底盘、刹车和道路规则越重要。

共存方式(模型负责决策,Harness 负责决策之外的系统工程):

1. 上下文工程:决定模型每轮看到什么;
2. 状态与持久化:模型不跨会话记状态,记忆、断点续跑、任务恢复在框架层;
3. 安全与治理:护栏、沙箱、权限、审批流——编码的是业务策略,不是对模型能力的补偿,不会随模型变强而过时;
4. 可靠性:重试、错误恢复、超时熔断、可观测性;
5. 人机协作接口:何时、以何种方式把控制权交给人。

未来框架核心价值:“补偿模型缺陷"的工程贬值,“表达产品与业务要求"的工程升值。具体包括:上下文管理基础设施、工具生态与标准化(如 MCP)、护栏与审计层、多 Agent 编排、评测与监控、记忆系统。

题 4(★★):除工具结果缺失外,生产中还有哪些情况导致 Agent 无限循环?检测和终止机制?

其他常见成因:

1. 错误信息不含修复线索:工具反复报错但没说明哪个参数错,模型原样重试同一调用;
2. 无副作用的"成功”:工具返回成功但环境没变化(点击没生效、条件永不满足),Agent 反复检查同一条件;
3. 策略振荡:A 失败→换 B,B 失败→换回 A;或两个子 Agent 互相委派;
4. 目标不可满足:验收标准永远过不了(如"找最便宜的"没有终止条件,或 LLM 评审员过度苛刻一直打回);
5. 上下文溢出失忆:历史被截断后,Agent 忘了自己试过什么,从头再来——表现为宏观循环;
6. 环境侧:分页/滚动永不结束、页面被外部持续修改、环境内容里的提示注入指示它重复动作;
7. 协议问题:模型已给出最终答案,但框架识别不了完成信号,继续追问。

检测与终止机制(分层设计):

• 硬熔断(兜底,必须有):最大轮数、最大 token/预算、墙钟超时——任何一条触发即强制终止;
• 循环检测:对最近 N 步的工具调用(名称+归一化参数)做哈希,重复 k 次即判定;滑动窗口检测 A→B→A 型振荡;对连续动作做语义相似度比较,抓"换汤不换药"的重试;
• 进度看门狗:要求维护显式任务清单/状态,连续 K 步状态无推进即判定停滞;
• 分级响应阶梯:检测到循环 → 注入提示(“你已重复调用 X,请换策略”)→ 强制重规划或换模型 → 暂停并移交人工 → 终止并汇报部分结果;
• 工具层:区分瞬时错误与永久错误,瞬时错误指数退避重试且设上限;
• 事后:结构化记录完整轨迹,离线回放分析定位循环模式,沉淀进评测集。

终止要"优雅”:保存状态、总结已完成部分、说明卡点——直接衔接人工接管(题 9)。

题 5(★):用感知/行动/策略三维度分析一个日常 AI 产品

以 Claude Code(编码 Agent) 为例(与本章表格中 Cursor 同类):

架构合理性: 开放式动作空间与编码任务的开放性匹配(每个 bug 都不同,预定义流程覆盖不了);“编辑后必须验证"的闭环符合"基于环境反馈持续交互"的核心定义;人工确认门对应护栏设计。

薄弱点与改进空间:

1. 长会话上下文增长——正是题 2 的二次方问题,可更激进地做滚动摘要和状态外置;
2. 验证依赖测试质量——没有测试的代码改动难以自证,可引入更强的自动验证(UI 改动自动截图比对、运行时行为观测);
3. 跨会话记忆——目前靠记忆文件,可结构化为"项目事实库”(约定、踩过的坑);
4. 默认隔离——高风险命令默认进沙箱执行,把护栏从"询问"前移到"隔离";
5. 大仓库定位——超大 monorepo 中搜索成本高,可维护代码地图/索引作为常驻上下文。

题 6(★★):航班订票客服系统选工作流还是自主 Agent?能否混合?

答案:混合——工作流为骨架,自主 Agent 处理模糊边缘。

依据本章:工作流可控、可审计、成本低但缺灵活性;自主 Agent 灵活但成本高、误差随步骤复合。订票业务的特征:

• 主干高度结构化:查票→选航班→填乘机人→支付→出票,路径固定、涉及真金白银和实名制合规,必须走工作流——可测试、可审计、出错可追责;
• 输入端天然模糊:“帮我订下周三去上海最便宜的,别太早”——意图理解、槽位填充、澄清追问需要 LLM 的灵活理解;
• 异常长尾是开放问题:航班取消后的改签、恶劣天气批量退改、多程联运、特殊旅客——预定义流程写不全,适合受限的自主 Agent(只给航班领域工具,退款超过阈值必须人工审批)。

架构: 意图路由 → 进入对应工作流;工作流内用 LLM 做自然语言抽取与澄清;遇到未覆盖状态 → 升级到受限 Agent → 仍无法解决 → 移交人工客服。工作流保住 90% 主路径的确定性,Agent 吃掉 10% 长尾,风险和成本都最小。

题 7(★★★):工具大多低风险、特定参数组合变高风险,如何设计动态风险评估?

核心思想:**风险不是工具的属性,而是 (工具, 参数, 环境状态) 三元组在调用时刻的属性。**静态的工具级评级只是先验,必须在每次调用时用真实参数重新计算。设计四层:

1. 参数级规则(快、确定):对实参做模式匹配——受保护路径的黑名单/白名单(/etc、/System、*.pem、生产库连接串)、敏感操作的参数特征。delete_file 命中受保护路径即升级。
2. 语义分类器(补规则的盲区):用小模型/分类器评估这次具体调用的含义:影响半径多大?可逆吗?目标是生产资源吗?规则抓不住的新颖参数组合靠它兜底。
3. 环境感知(同一调用,风险不同):查目标真实状态——这个文件在 git 里有版本(可恢复)吗?有备份吗?当前是开发沙箱还是生产环境?从 CMDB/元数据拿资源关键性等级。删一个有备份的临时文件是低风险,删同路径下唯一生产配置是高风险。
4. 统计基线:与该工具历史调用分布对比,显著异常的参数组合自动升级复核。

评级输出映射到分级动作: 低→直接执行;中→执行但先做可逆化(软删除/回收站代替硬删、自动快照);高→人工确认后执行;极高→直接拒绝。设计上优先让高风险操作变可逆:dry-run 预览受影响对象、事务化批量操作、删除先进回收站。最后用审计日志回流,持续校准评级函数。

题 8(★★):受限的动作空间在什么场景下反而优于开放式?

1. 高风险低容错领域(支付、医疗、工业控制):受限空间可穷举测试、可形式化验证、可审计,开放式的行为空间无法做覆盖性保证;
2. 意图收敛的窄任务(查订单、改签、FAQ):预定义选项就能覆盖,受限模式更可靠、更便宜、延迟更低;
3. 需要确定性保证与合规审计的场景:每个分支可解释、可追溯,监管友好;
4. 高并发消费级产品:Agent 循环慢且贵,受限流程能满足 QPS 和延迟要求;
5. 用户侧需要结构化:表单/向导式选项降低表达歧义,比开放式输入更省认知负担;
6. 底层模型能力有限:小模型驾驭不了开放动作空间,约束选项直接降低错误率;
7. 安全性:受限动作空间天然限制提示注入的爆炸半径——即使被注入,能调用的工具也就那几个。

**规律:任务的开放性越低、风险越高、对确定性和延迟的要求越高,受限空间越优。**成熟系统常是"受限骨架 + 开放兜底":主路径走预定义选项,覆盖不了时落入受限 Agent。

题 9(★★):需要人工干预,但用户不在线/响应慢/指令模糊,Agent 怎么办?

先减少问的必要性: 决策依据应有优先级阶梯——明确指令 > 用户历史偏好/记忆 > 领域惯例 > 保守默认。多数决策根本不必问。

移交时做对格式: 异步友好的移交物 = 状态摘要 + 已完成项 + 卡点 + 带推荐项的选项列表(而不是开放式问题)+ 等待时限。

用户不在线时,按可逆性区分对待(核心原则):

• 可逆/低风险决策:按保守默认执行,继续推进,同时记录并告知(“我按 X 处理了,你可以随时改”)——不要为等用户而空转;
• 不可逆/高风险决策:绝不猜测。把任务停泊在安全状态,通知用户,等待;可支持事前预授权(“金额小于 100 元直接办”)消化可预期的等待;
• 超时升级:超过时限换渠道提醒,仍无响应则按预设策略升级给代理人或终止并留报告。

用户指令模糊时: 不把模糊当作同意,尤其对高风险操作;用"具体二选一 + 各自后果"重新提问;对低风险路径可声明式推进(“我将按 X 理解执行,除非你反对”)。全程留审计日志。

一句话:自主性以可逆性为界——可逆的先做后报,不可逆的宁停勿猜。

题 10(★★★):举一个会随模型能力进步而过时的 Agent 工程手段

例子:手写的 ReAct 提示词脚手架 + 正则解析工具调用。

早期框架靠 few-shot 模板强制模型输出 Thought: / Action: / Observation: 文本,再用正则把动作从自由文本里解析出来,解析失败就重试。这个手段正在过时,原因是:它补偿的是模型缺陷——当年模型不会规范地发起工具调用,只能靠提示词硬掰。而现在的模型经过强化学习后训练,原生输出结构化的 tool_calls(本章上下文五要素中,模型回复就包含 reasoning + content + tool_calls 三段),格式错误率趋近于零,API 层还有结构化输出/受限解码兜底。继续套文本模板反而有害:约束了模型被训练出的行为方式,浪费 token,还引入不必要的解析故障点。

但穿越周期的原则还在:“推理与行动交替进行、用环境反馈修正下一步”——ReAct 的思想本身没过时,过时的只是用提示词模板实现它的方式。

同类例子:从自由文本解析 JSON 的兜底解析器(被原生结构化输出取代)、为补推理能力做多路采样投票(随模型推理变强而边际收益递减)。

**判别规律:凡是"补偿模型能力缺陷"的工程手段,都会随缺陷被修复而过时;凡是"编码业务策略与系统要求"的手段(护栏、审计、状态管理、人机移交),则穿越模型迭代周期存续。**架构上应当把两者分层隔离,让过时的那一层可以整层替换。

附:全题结论速览