AI-Agent-Book第一章思考题

1. 如果只能增加一项能力：模型、上下文、还是工具？

我通常会优先选更多、更可靠的工具。

原因是：更强模型主要提升"想得更好"，更丰富上下文提升"知道得更多"，而工具直接扩展了 Agent 能做什么。一个不会查数据库、不会执行操作的强模型，本质上仍然只是顾问；接入检索、代码执行、业务 API 后，它才真正具备闭环能力。

但选择取决于当前系统的瓶颈：

• 如果 Agent 经常"知道该做什么，但做不了"，优先加工具。
• 如果工具已经齐全，但经常选错工具、规划错误、理解复杂要求失败，优先换更强模型。
• 如果错误主要源于"不知道用户历史、业务规则、前序状态"，优先增加上下文/记忆能力。

所以更准确的原则不是"哪个最好"，而是：

增加系统当前最稀缺的能力，而不是继续增强已经足够强的维度。

还要注意，"更多上下文"和"更多工具"本身并不一定更好。工具太多会扩大搜索空间，上下文太长会产生噪声，因此真正重要的是有效工具暴露 和有效上下文管理。

---

2. 如何打破 ReAct 完整历史导致的二次方成本？

核心思路是：不要把完整轨迹当成唯一状态表示，而要把轨迹压缩成"状态"。

假设每一轮新增 (k) 个 token，第 (i) 次调用都发送前面约 (ik) 个 token，那么总输入量大致是：

k(1+2+\\cdots+n)=O(n\^2)

可以通过几种机制将它接近 (O(n))。

第一种是滚动摘要。把较早的 Thought、Action、Observation 压缩为结构化摘要，只保留近期若干轮原文。例如保留：

• 当前目标
• 已完成事项
• 关键事实
• 已尝试且失败的方法
• 当前约束
• 下一步计划

这样历史不是无限增长，而是"固定长度状态 + 最近窗口"。

第二种是外部记忆。完整轨迹存到数据库或向量库中，每轮只检索与当前决策相关的部分。模型看到的不是"所有历史"，而是：

\\text{Current State} + \\text{Relevant Memories}

第三种是结构化状态机。不要把"状态"隐含在自然语言聊天记录里，而是显式维护 JSON、数据库记录或黑板，例如：

goal
known_facts
completed_tasks
pending_tasks
failed_attempts
constraints
artifacts

第四种是分层上下文：短期上下文保留原始细节，中期历史做摘要，长期历史按需检索。

不过"压缩但不丢关键信息"本身就是难点。最危险的是摘要把一个失败条件删掉，Agent 过几轮又重复同一个错误。因此通常需要规定一类不可压缩信息，例如：

• 用户明确约束
• 已发生的不可逆操作
• 工具返回的关键 ID
• 失败尝试及失败原因
• 权限和安全状态

所以真正要打破的不是"历史"，而是历史 = 状态这一假设。

---

3. "模型即 Agent"与 Harness 越来越重要，为什么不矛盾？

两者作用在不同层次。

"模型即 Agent"意味着模型越来越能自主完成：

理解目标 → 规划 → 选工具 → 根据结果调整 → 再行动

于是以前框架里大量硬编码的 Planner、Router、ReAct parser 等逻辑，可以被模型吸收。

但自主性越强，系统边界越重要。

因为 Harness 负责的不是替模型"思考"，而是决定：

• 模型能看到什么；
• 能调用什么；
• 每个工具权限是什么；
• 调用失败怎么办；
• 哪些操作需要审批；
• 状态怎样保存；
• 什么时候停止；
• 怎么监控、审计和恢复。

可以类比操作系统：程序越强，并不意味着操作系统越不重要。恰恰因为程序能力强，权限隔离、资源管理和故障恢复更重要。

未来 Agent 框架的价值可能从"替模型编排思考步骤"，转向五类基础设施：

1. Context engineering：动态构造最合适的上下文。
2. Tool infrastructure：工具发现、描述、权限、调用、重试。
3. State / memory：长期状态、任务状态和检查点。
4. Safety / governance：审批、风险控制、审计。
5. Observability / evaluation：追踪轨迹、成本、失败模式和质量。

所以未来好的框架可能"看起来更薄"，但底层工程反而更重。

---

4. 除了工具结果缺失，还有哪些无限循环？如何检测？

生产环境里的循环远比"没有 Observation"复杂。

常见情况包括：

工具持续失败。

调用 API → timeout → retry → timeout → retry......

参数修复循环。

参数非法 → 修改参数 → 仍非法 → 再修改......

两个工具互相触发。

A 说信息不足 → 调 B
B 说需要 A 的结果 → 调 A

反复搜索。

Agent 不确信答案，于是不断换关键词搜索，但信息增益已经接近零。

规划震荡。

方案 A → 怀疑 A → 改 B → 怀疑 B → 又回 A

状态没有真正变化。

虽然每轮文本不同，但环境状态、任务进度都没变化。

检测机制不能只靠 max_steps=20。更好的方法是多层组合：

• 硬限制：最大步骤、最大 token、最大时间、最大费用。
• 重复动作检测：相同工具 + 相同/近似参数连续出现。
• 状态进展检测：连续 N 步没有新增事实、没有完成子任务、环境状态不变。
• 语义循环检测：检测最近几轮计划是否高度相似。
• 失败预算：同一工具或同一错误类型最多重试 N 次。
• 信息增益检测：连续搜索没有产生新信息时停止。
• 计划版本计数：A→B→A→B 等震荡超过阈值时中止。

终止之后也不应简单输出 "failed"。应该进入专门的恢复策略：

我已经尝试了 X 和 Y；两者均因 Z 失败。目前缺少 A，因此继续自动执行预计不会取得进展。需要人工提供 A / 授权 B / 稍后重试。

这比单纯"达到最大步数"更可解释。

---

5. 用感知、行动、策略分析一个 AI 产品

以 ChatGPT 类通用助手为例。

感知。

输入来源已经不仅是文本，还可以包括图片、文件、网页内容、工具结果以及一定程度上的用户历史。它的感知空间很宽，因此可以处理大量开放问题。

弱点在于"知道什么信息值得进入当前上下文"仍然很难。如果把所有历史都放进去，会产生噪声；如果筛选过度，又可能遗漏关键约束。

行动。

动作可以包含生成文字、调用搜索、运行代码、操作外部服务等，因此是比较开放的动作空间。

好处是泛化能力强，问题是工具越多，错误工具选择和高风险操作也会增加。

策略。

很多任务不再依赖固定 workflow，而由模型动态决定是否检索、是否调用工具、如何分解步骤。因此策略具有较高自主性。

整体架构是合理的，因为通用助手面对的任务空间几乎无法预先枚举。

如果由我设计，会重点提升三个地方。

一是加入更加明确的任务状态层。复杂任务不应该完全依赖聊天历史，而应维护：

目标
约束
已完成
待完成
关键决策
产生的文件

二是做更强的动态工具选择。不要每轮把几十个工具全部暴露给模型，而是先根据任务筛选工具子集。

三是加入显式进度判断。系统应该能够判断"我是在解决问题，还是只是在继续生成动作"。

---

6. 航班订票客服：工作流还是自主 Agent？

我会采用混合架构。

航班订票涉及真实资金、库存和不可逆交易，因此关键交易链路适合工作流：

查询航班
↓
选择航班
↓
确认乘客
↓
确认价格
↓
支付
↓
出票

这些步骤必须确定、可审计，而且在最终购买前需要明确确认。

但用户的输入本身非常开放：

"我周五晚上从东京走，最好周日下午回来，不想太早起，如果大阪比京都方便也可以。"

这种需求非常适合 Agent 来理解、规划和调用搜索工具。

因此可以设计为：

自然语言需求
      ↓
自主 Agent
理解需求、查询、比较、解释
      ↓
形成明确候选方案
      ↓
确定性 Workflow
身份 → 价格确认 → 支付 → 出票

甚至售后也可以采用类似结构：

Agent 判断用户意图
       ↓
改签 / 退票 / 行李 / 延误
       ↓
进入对应受控工作流

原则是：

探索阶段开放，承诺阶段收敛。

越接近真实资金、法律责任或不可逆操作，系统越应该从 Agent 模式切换到确定性 workflow。

---

7. 如何设计动态工具风险评估？

风险不能只定义在"工具级"，而应该定义在：

Risk=f(tool, parameters, context, user, environment)

例如：

delete_file("/tmp/test.txt")

可能是低风险，而：

delete_file("/etc/passwd")

显然是高风险。

可以设计多层风险评分。

首先是工具基础风险：

search_web = 1
send_email = 3
delete_file = 4
transfer_money = 5

然后加入参数风险：

delete /tmp/*        +0
delete project/*     +1
delete system/*      +4
recursive=true       +2
wildcard=*           +2

再加入上下文风险：

• 是否生产环境；
• 是否影响多人；
• 是否可恢复；
• 是否首次执行；
• 是否来自未经信任的网页指令。

最后形成策略：

Risk 0-2 → 自动执行
Risk 3   → 执行但记录
Risk 4   → 请求确认
Risk 5   → 禁止或要求更高权限审批

还应采用预执行和实际执行分离：

prepare_delete()
→ 返回影响范围
→ risk evaluator
→ approval
→ execute_delete()

这比让模型直接调 delete_file() 安全很多。

关键思想是：

工具没有固定风险，真正有风险的是"某个主体，在某个环境下，以某组参数执行某个动作"。

---

8. 什么时候受限动作空间优于开放动作空间？

当任务的目标不是"创造性"，而是稳定性、可预测性和可验证性时。

比如银行客服：

请选择：查询余额 / 挂失 / 转账 / 修改信息。

如果让模型自由创造动作：

"我觉得可以先帮你冻结部分资金，然后联系另一家银行......"

风险就很大。

受限动作空间尤其适合：

• 金融交易；
• 医疗流程；
• 权限管理；
• 工业控制；
• 游戏 NPC 的规则动作；
• 企业审批；
• 客服工单；
• 数据库修改；
• 合规要求严格的任务。

它有几个非常强的优势。

第一，可验证。系统可以枚举所有可能动作。

第二，更容易做权限控制。

第三，测试空间有限。

第四，可以用 classifier 或 constrained decoding 保证输出合法。

第五，减少 prompt injection 能够转化成真实危害的机会。

因此一个常见设计是：

自由语言理解 + 受限动作执行。

例如模型可以自由理解用户：

"我卡丢了，刚才还有一笔不是我刷的。"

但最终动作只能从：

LOCK_CARD
REPORT_FRAUD
CHECK_TRANSACTION
TRANSFER_TO_HUMAN

中选择。

很多生产级 Agent 最终可能都会采用这种"开放推理、受限执行"的结构。

---

9. 用户不在线、响应慢或指令模糊时怎么办？

首先要区分两类情况：

可以安全继续的动作 和需要用户授权才能继续的动作。

如果 Agent 遇到模糊信息，但下一步是低风险、可逆的，例如继续搜索航班，则可以根据合理默认值推进，同时记录假设：

暂按经济舱搜索，不执行购买。

如果下一步涉及支付、发送消息、删除数据等高风险行为，就应该进入暂停状态，而不是替用户猜。

一个好的人工移交机制至少需要保存：

当前目标
已完成步骤
当前阻塞
需要用户回答的问题
推荐选项
恢复执行所需状态

这样用户几个小时后回来，不需要重新开始。

对于模糊指令，可以采用"最小授权原则"：

能做 80% 的准备工作，但最后 20% 需要明确授权时，就先把 80% 做完。

例如用户说：

"帮我订一张去上海的机票。"

Agent 可以先：

• 查航班；
• 排序；
• 找出三个候选；
• 计算价格；

但不应该自行支付。

如果用户长期不响应，则任务应该进入诸如：

WAITING_FOR_USER

而不是继续循环。

所以"优雅移交"本质上不是问一句：

"需要人工吗？"

而是设计一套可暂停、可恢复、可解释的任务状态机。

---

10. 哪个当前 Agent 原则可能随模型进步而过时？

我认为可能逐渐过时的一条原则是：

复杂任务必须显式拆成多个固定 Agent / 固定 Planner-Executor 模块。

目前很多系统使用：

Planner Agent
↓
Research Agent
↓
Coding Agent
↓
Reviewer Agent

这种设计的一个重要原因，是单次模型调用能力有限：上下文有限、长程规划差、专业能力不稳定，因此需要人为拆分角色。

但随着模型变强，一个模型可能在单一上下文中自行完成：

规划 → 搜索 → 编码 → 检查 → 修改

此时为了"Multi-Agent 而 Multi-Agent"反而会产生：

• 更多 token 消耗；
• 更多通信开销；
• 上下文损失；
• Agent 间误解；
• 调度复杂度；
• 更难调试。

因此未来的原则可能从：

"复杂任务应该拆成多个 Agent"

变成：

"只有当任务存在真正的并行性、权限隔离、上下文隔离或专业化收益时，才拆成多个 Agent。"

不过有些原则大概率会长期存在，例如：

• 最小权限；
• 高风险操作确认；
• 可观测性；
• 状态持久化；
• 失败可恢复；
• 对外部结果进行验证。

因为这些原则解决的不是"模型不够聪明"，而是任何自主系统都存在的不确定性和风险。

从这个角度看，可以用一个标准判断某条 Agent 原则是否"穿越模型周期"：

如果它解决的是"模型能力不足"，它可能随着模型升级而消失；

如果它解决的是"现实世界的风险、权限、成本和不可逆性"，它大概率会长期存在。