第1章
1. 如果你只能给一个 Agent 系统增加一项能力——更强的模型、更丰富的上下文还是更多的工具——你会选哪个？在什么条件下你的选择会改变？
通常情况，选择更强的模型总是能带来更大的收益，因为更强的模型拥有更长的上下文窗口，组织混乱信息的能力更强，也可以通过 coding 的元能力自己创造工具；因此更换更强的模型实际就是同时拥有了更多的上下文和更多的工具。
但是更强的模型通常更贵，因此如果证明，通过增加更多工具，或者提供更丰富的上下文，当前模型的智力已经足以处理问题，那么出于性价比的考虑，应选择其他的提升方法。以订票 Agent 为例，由于工作场景有限，与其更换更强模型，指望模型自己 handle 意外情况，不如接入知识库，通过外部预设场景与应对方式来达到相同的效果。
2. ReAct 循环中，累计缓存读取量随轮数近似二次方增长。如何降低这种增长？
KV-Cache 的增长，可以通过上下文压缩、提炼记忆等方式解决。上下文压缩是现在普遍使用的方法；被动压缩包括，当接近上下文窗口长度限制时，触发上下文压缩以避免上下文溢出；主动压缩则是模型自主判断合适的压缩时机触发压缩，优化上下文长度，缓解缓存读取压力。
上下文压缩解决的是短期上下文的问题，而记忆是解决长期信息存储。通过选择性遗忘和提炼，可以将大量的噪声信息压缩为少量真正有用的信息并存储下来，从而避免将缓存和注意力浪费在无用信息上。
3. “模型即 Agent” 范式意味着模型在工具调用决策上越来越自主。但本章论证了 Harness 工程的重要性反而在增加。这两个趋势如何共存？Agent 框架未来的核心价值体现在哪些方面？
个人认为，模型能力的增强必定会吸收 Harness 的一部分功能，例如随着模型对于工具使用的理解加强，Harness 层的对工具使用的配置就被吸收了；但是模型能力越强，越泛化，反而越证明 Harness 的必要性。
首先是需要 Harness 的安全限制、错误判断与处理，来防止模型做出破坏性操作；而且随着模型能力增强，模型做出破坏性操作的可能性反而在增加（参考 OpenAI 攻击 Hugging Face 事件），因此 Harness 的安全边界愈发重要。
其次，对于垂直场景，模型需要 Harness 补齐领域知识和能力，并且在费用和性能之间达成平衡。例如 Harness 可以给模型配置记忆、RAG 和行业专用工具，这样模型即使可以通过搜索、coding 等元能力实现相似的功能，但在费用和易用性等方面也没有优势。
4. 引言指出”好的设计原则应该穿越模型的迭代周期”，但实现这些原则的具体工程手段可能会随模型能力进步而过时。试举一个这样的 Agent 工程手段，并说明理由。
最明显的例子是，为了能更好地利用模型输出，在很多场景下会要求模型输出标准的 JSON 格式文件。此前，需要开发者在处理模型输出时添加很多 parser 或者规则检测，来从模型的文本输出中提炼并组装标准格式的输出；然而随着模型训练时内置的工具使用能力和输出标准化能力，现在只需要简单的提示词，就能让模型输出标准格式的信息，不再需要 post-processing。
第2章
1. DeepSeek R1 曾要求剥离全部历史思考，而 DeepSeek V4 反转为强制回传全部 reasoning_content——对比这两种相反的策略，各有什么利弊？这个反转说明了什么？
剥离全部历史思考可以控制上下文长度，而回传全部思考内容，可以让模型在多轮对话中，能理解此前作出的工具调用或输出的原因，并且顺着此前的思考链进行推理，提升理解和推理能力。这种反转说明，上下文窗口长度目前不是性能瓶颈，模型开始更加追求理解和推理的智力。
2. 上下文感知压缩实验中，从约 148K 个字符压缩到约 2,000 个字符，这种极端的压缩是否存在”不可逆信息损失”的风险？如何解决？
这是一种有损压缩，必然是存在”不可逆信息损失”的。解决方法可以分为两种。
首先是建立多层次的记忆系统。不同层次的记忆设置不同压缩率，可以逐级保留不同压缩率的信息，例如最底层的冷数据，可以保留完整的 trace。模型在工作时，可以通过多个记忆层次的交叉校准，来避免因为极高压缩率导致的信息损失。
其次是面向不同的任务场景，建立不同的上下文感知压缩方式。例如客服场景，压缩时应强调客户诉求、服务进度等信息；针对不同场景设置不同关注信息，可以避免关键信息被丢弃。
3. 本章提出”上下文学习本质上是检索而非推理”。如果这个论断成立，当前所有基于”把更多信息塞进上下文”的优化方向都需要重新审视。你认为应该如何突破这一局限？
突破方法在于利用 Agent 的创造和调用工具的能力。对于 Agent 来说，理想的工作方式是，模型负责意图识别、工具调用判断等更上层的工作，由模型调用或创造的程序工具则负责数据计算等更下层的工作。这种工作方式可以充分利用模型处理不同场景的灵活性，和程序进行数据计算推理的确定性。因此模型不应该直接处理上下文中的所有信息，而更应该关注用户想要如何处理这些信息，有哪些可用的工具可以用来处理信息。
4. Skills 的渐进式披露只在 Agent 判断需要时才加载完整内容。但这个判断本身依赖模型的能力——如果模型不知道自己不知道什么，就无法正确触发 Skill 的加载。这个”元认知”问题如何解决？
首先是在 Skill 的 brief 中写明适用和不适用的情况，方便模型只读简介就能知道是否应该去加载更详细的内容。其次是在模型的系统提示词中加上强制扫描 skill 目录下所有 skill 的要求，防止模型偷懒不使用 skill。最后是针对垂直领域的 Agent，可以绑定特定的 skill 要求模型基于规则而不是自己的推理，对 skill 进行调用。
5. 本章强调动态信息（如系统时间戳、工具列表顺序）的变化会破坏 KV Cache 前缀命中。在一个拥有大量工具且工具集频繁变动的生产系统中，你会如何设计上下文布局来最大化缓存命中率？
通过两种方式。在上下文布局方面，遵循静态内容放前面、动态内容放后面的原则，将频繁变动的工具列表内容附在上下文最后，例如作为 Agent 状态栏的一部分，避免干扰已命中的缓存。第二种方法是在上下文中只暴露相对固定的工具分类，当模型决定调用某一类型的工具时，再通过 list 工具分类的方式获取具体可用的工具类型，由于工具分类固定，因此也不会影响缓存命中。
第3章
1. Rich Sutton 的”苦涩的教训”认为通用方法（搜索和学习）最终会胜过手工设计的特征。本章构建的整个知识系统（分块策略、索引结构、检索管道）是否本身就是一种”手工设计”？如果模型能力足够强，这些设计是否会被简单的”全量输入”所替代？/ 随着模型能力的提升，你认为领域知识库还重要吗？未来强大的基座模型是否有可能包含领域知识库中所有的信息，从而不再需要领域知识库？
这两个问题可以一起回答。在 AI 变成全知全能之神之前，我认为 LLM 通过海量语料学习到的是人类知识的平均水平，因此对于任何领域、任何专家来说，都需要领域知识库来让 AI 在特定领域达到比平均水平更高的能力。同时，也需要人类专家在特定领域对 AI 进行一定的监督与校准。与之相对的，当在一个人类能力不如 AI 的领域，就应该完全交与 AI 进行搜索和学习，而不是用条条框框干扰甚至误导 AI 的判断。
2. 请为一个 Markdown 用户记忆库同时设计增量更新与定期整理流程。如果 Reviewer 与 Proposer 使用同一模型，且只能看到 Proposer 挑选的对话片段，系统仍可能合入哪些错误？请从模型独立性、证据覆盖和工具权限三方面说明你的改进。
增量更新包括多层次总结用户对话，从保存完整的轨迹作为最终事实校验的依据，到提取高层次信息并更新到专用的短期记忆存储文件。定期整理流程由定时器自动触发，会通过比较高层次记忆文件的 diff 进行进一步的提炼与抽象，根据 Agent 的设计目的，沉淀为系统提示词或角色提示词等，同时将有用的信息更新到长期记忆文件；然后将短期记忆文件移动到备份数据库，准备进行下一周期的增量更新。
为了避免 Reviewer 和 Proposer 使用同一模型导致的前后矛盾、时间混淆等错误，从模型独立性角度，需要给 Proposer 和 Reviewer 设计针对性的角色提示词，让他们关注不同的角度，避免陷入趋同的判断模式；从证据覆盖角度，要求 Proposer 提议时总是附带原文作为证据，方便验证；从工具权限角度，赋予 Reviewer 查询原始轨迹的权限，以验证 Proposer 的证据是否符合事实，以及发现可能的错误。
第4章
1. 本章提出了”执行-验证-反馈”闭环（如写代码后自动运行 linter）。这种”操作后立即自动验证”的模式还可以应用到哪些工具场景？是否存在某些操作，其验证本身的成本或风险超过了操作本身，导致这种模式不可行？
像代码这种操作后可以立即验证的本身就是少数，因此成为了 AI 最先突破的应用场景。生活中大部分的场景反而因为验证成本高昂而不适合目前的 AI 进入。例如 AI4S 中，如果 AI 只提出无理假设，而无法进行实际的物理实验，则无法进入闭环；或者如支付场景中，AI 无法实际发起支付，再进行验证，而必须保证执行的绝对正确。因此目前个人经验是，AI 的瓶颈在于验证，如果能解决快速验证 AI 产出的问题，那么就可以让 AI 的飞轮转起来提高效率，否则还需要引入人类进入验证环节，拖慢整体的效率。
2. 本章提出了”工具爆炸”问题——Agent 面对数千个工具时选择精度下降。除了主动工具发现，还有哪些方案？可以参考人类专家在面对大量可用工具时的策略。
方法是设计面向特定领域的工具集，由 AI 进行多步判断，先判断需要处理的问题的领域，然后在领域工具集中判断最适合的具体工具。
第5章
1. 代码生成 Agent 在处理日志解析时，能自动跟随格式演化。但如果格式变化是一个 bug 而非预期改动，Agent 的适应性反而掩盖了问题。Agent 应该如何区分”需要适应的变化”和”需要报告的异常”？
需要人类对于格式变化方式有预期，并将预期的变化方向或可能的变化形式告诉 AI。这样当 AI 发现预期之外的变化形式时，即使可以自适应地处理，也会在最终的处理报告中体现出来，方便及时发现问题。
2. Agent 自举——能创造 Agent 的 Agent——实现了”智能的自我繁殖”。但每次自举都可能引入新的偏差或错误，这种错误会在代际间累积吗？如何防止 Agent 自举的退化？
和生物进化、代码库积累一样，错误是会不断累积的。解决方法是及时保留最佳版本（best build），当评估出现明显的某项性能退化时，可以以 best build 为蓝本，cherry pick 优秀 feature，形成一个全新的分支，作为之后迭代的起点。
3. Artifact 模式让 Agent 生成 SQL 或前端代码，由数据库和浏览器直接执行，绕过 LLM 处理大量数据。与传统的”Agent 直接给出答案”相比，这种”Agent 生成代码、系统执行代码”的分工有什么优劣？
优势是减轻幻觉，提高确定性，并且节省 token，可复用；劣势是无法以自然语言形式给出结论，部分分析工作仍需要人类执行。总体来看优势大于劣势。
4. Simon Willison 提出了 Agent 的”致命三要素”（访问私有数据、暴露于不受信任内容、具备外部通信能力），本章在此基础上增加了第四个——持久记忆。在一个需要同时处理这四种要素的生产环境中，你会如何设计安全策略？
把 Agent 当成实习生进行管理。具体措施如下：
- 访问私有信息：最小权限管理，并且只读，没有写权限。如需 merge，需要人类（作为 mentor）进行签字放行；
- 暴露于不受信任内容 / 具备外部通信能力：配置网络白名单，处理外部信息时放在 sandbox 中执行，向外部发送消息时需要 mentor 签字放行；
- 持久记忆：设置明确的记忆有效时间。