第一章 AI Agent 入门
1. (★★) 如果你只能给一个 Agent 系统增加一项能力——更强的模型、更丰富的上下文、还是更多的工具——你会选哪个？在什么条件下你的选择会改变？
对应“大脑/眼睛/手脚”公式，先找短板：通常优先补上下文，即补充观察空间（observation space）。若任务超出模型推理能力，换更强模型。若动作空间不足（例如无法访问公司内部系统），加工具。判断依据是分析失败轨迹，定位瓶颈在感知、决策还是行动。
2. (★★★) ReAct 循环中，累计缓存读取量随轮数近似二次方增长。如何降低这种增长？
第 i 轮读取的缓存前缀长度约与 i 成正比，累计读取量为 1 + 2 + ... + n = O(n²)；这里二次增长的是累计缓存读取费用，而非轨迹长度或 KV Cache 占用。可在达到 token 阈值时批量压缩早期轨迹，只保留结论与关键状态，并把大块中间结果外置后按需检索，或用子 Agent 隔离。不能每轮压缩，否则既可能损害 Agent 性能，也会引入额外的压缩调用和缓存重建开销。
3. (★★) “模型即 Agent” 范式意味着模型在工具调用决策上越来越自主。但本章论证了 Harness 工程的重要性反而在增加。这两个趋势如何共存？Agent 框架未来的核心价值体现在哪些方面？
马与缰绳隐喻：模型越强、自主空间越大，出错影响面越大，越需约束、验证、纠正。框架价值从“编排 LLM 调用”转向 Harness 五要素中的保障层：权限分类、熔断器、错误恢复、上下文压缩、工具生态。
4. (★★) 消融实验中 “工具结果反馈” 的缺失导致 Agent 陷入无限循环。在生产环境中，除了工具结果缺失，还有哪些情况可能导致 Agent 无限循环？你会设计怎样的检测和终止机制？
其他诱因：工具反复报同一错误、模型因幻觉调用不存在的工具、上下文压缩导致关键状态丢失、思考过程被剥离导致模型 API 报错、任务本身无解。机制：设定最大迭代次数等停止条件；检测重复调用（相同工具+参数指纹）；超过失败阈值后升级为人工干预。
5. (★) 本章用感知、行动、策略三个维度分析了五个 Agent 产品。请选择一个你日常使用的 AI 产品，用这三个维度进行分析，并思考它的架构设计是否合理。如果由你来设计这个 AI 产品，有哪些改进空间？
开放题。要点：仿照章中表格，写出眼睛（能看到什么信息源）、手脚（动作空间是否开放式、能否内部思考）、策略（Agent 执行循环的模式）。
6. (★★) 如果你要设计一个专门处理航班订票的客服系统，你会选择工作流模式还是自主 Agent 模式？有没有可能在同一个系统中混合使用两种模式？
主体采用工作流：身份核实→搜索→付款→预订四个节点，保证“付款前不能预订”等合规顺序，且把提示注入攻击面限制在单个节点内。开放性环节（理解需求、改签、航班取消后的替代方案推荐）切换为自主 Agent。高风险操作（大额付款、退款）需加人工确认。
7. (★★★) 护栏部分提到了工具风险评级。如果一个工具在大多数情况下是低风险的，但在特定参数组合下变为高风险（如 delete_file 删除普通文件 vs 删除系统文件），你会如何设计动态风险评估？
评级对象从“工具”细化到“工具+参数”：调用时根据可逆性、权限和影响面计算风险。采用基于规则的确定性检查（路径黑白名单、正则），而非模型判断。验证时应只检查结构化数据，防止提示注入操纵判断结果。
8. (★★) 本章的 Agent 产品表格中，所有 Agent 的动作空间都是 “开放式” 的。一个受限的动作空间（比如只能从预定义选项中选择）在什么场景下反而优于开放式？
高合规、高风险、错误不可逆场景：如退款、付款，受限选项即“约束”，天然防呆，从设计上让错误无法发生。
9. (★★) 人工干预机制要求 Agent 能 “优雅地移交控制”。但在实践中，用户可能不在线、响应很慢、或者给出模糊的指令。此时 Agent 应该怎么办？
Fail-safe：高风险操作在未获确认时暂停，而非默认执行；先完成可逆的低风险部分，将高风险部分记录在文档中，便于人类决策和 Agent 恢复；使用异步沟通工具（消息、邮件）通知用户并设置超时策略；指令模糊时先澄清意图。
10. (★★★) 引言指出 “好的设计原则应该穿越模型的迭代周期”，但实现这些原则的具体工程手段可能会随模型能力进步而过时。试举一个这样的 Agent 工程手段，并说明理由。
示例一：通过约束采样强制工具调用符合严格格式。这是在模型容易输出非法 JSON、遗漏参数时采用的可靠性补丁；随着模型的格式遵循能力提高，其收益可能逐渐降低，但高风险场景仍应保留确定性的格式校验。
示例二：为弥补模型无法持续吸收新知识而引入外部知识库。如果模型未来具备可靠的持续学习能力，一部分知识维护可能从模型外部迁移到参数中。不过，外部知识库在实时更新、精确检索、权限控制和来源追溯方面仍有独立价值，因此更可能缩小适用范围，而非完全消失。
示例三：要求所有能力都必须通过模型 API 的标准工具调用接口暴露，禁止自定义调用形式。Skills 已经展示了另一条路径：用文本描述能力及操作方法，再让模型通过通用命令行工具执行；从模型视角看，这相当于在通用执行器之上理解并遵循一种自定义的文本调用协议。随着模型理解任意接口的能力增强，“必须使用标准工具调用格式”不再适合作为普遍原则。标准格式对于互操作、结构化校验以及能力较弱的模型仍然有用，但它应是基于场景的工程选择。
示例四：要求提示词与全部工具定义必须预先放在上下文开头。这种做法源于早期模型的指令遵循能力有限，提示或工具定义离开熟悉的固定位置后，模型往往难以正确识别和执行。Skills 会在运行过程中按需把提示词加载到上下文中间；动态工具发现也会在找到新工具后，把工具定义追加到已有轨迹之后。随着模型的指令遵循能力增强，以及针对这类动态加载方式进行专门的后训练，提示词和工具定义不再必须固定在上下文开头。