在很多关于大模型应用的讨论中，人们很容易陷入一个误区：
只要写好了 Prompt，再加上几个工具调用，一个“智能体（Agent）”似乎就完成了。
但在实际工程中，这种理解往往会很快失效。
一个真正可用的 Agent 系统，决定性因素并不是 Prompt，而是它背后的执行循环（query loop）。
一、Prompt vs Query Loop：定义 vs 执行
我们可以把一个 Agent 拆成两层：
1. Prompt：定义“它应该是什么”
Prompt 更像是一份岗位说明书，规定了：
- 你是谁（角色）
- 你的目标是什么（任务）
- 你可以使用哪些工具
- 你的行为边界和风格
它决定的是：
👉理想状态下，模型应该表现成什么样
2. Query Loop：决定“它实际上怎么运行”
Query Loop 是系统真正的“执行内核”，类似操作系统的主循环，负责：
- 接收当前输入
- 读取历史状态
- 判断是否调用工具
- 处理工具返回结果
- 决定是否继续下一轮
- 出错时恢复
- 上下文过长时压缩
- 资源不足时降级
它决定的是：
👉模型在真实环境中，能不能把任务一步步做完
👉核心结论：
Prompt 决定“你该怎么做”，
Query Loop 决定“你能不能真的做成”。
二、为什么 Agent ≠ 单次 API 调用
传统调用方式是：输入 → 模型 → 输出
但 Agent 的真实执行模式是：
用户任务
↓
模型分析
↓
调用工具
↓
工具返回结果
↓
继续推理
↓
再调用工具
↓
……
直到任务完成
这本质上是一个：
多轮闭环执行系统（multi-step loop）
因此：
- 单次 API 调用 = 一次“回答”
- Query Loop = 一个“持续推进任务的过程”
三、Agent 的本质：带状态的多轮执行系统
在实际实现中，系统会维护一个跨轮状态（state），例如：
- messages（历史对话）
- toolUseContext（工具上下文）
- turnCount（轮数）
- pendingToolUseSummary（待处理工具信息）
- recovery 状态
- context 压缩标记等
这意味着：
Agent 不是“每轮重新开始”，而是在继承过去状态的基础上继续执行
一个直观例子
任务：分析代码 → 修复 bug → 输出总结
执行过程可能是：
- 读取任务
- 查看代码（工具调用）
- 发现 bug（记录状态）
- 修改代码
- 测试失败
- 再修复
- 测试通过
- 输出总结
如果没有状态：
👉 每一轮都会“失忆”，任务无法推进
四、Harness 思维：把模型“管起来”
这里可以引入一个非常关键的概念：
Harness（执行框架）
它的核心思想是：
不是让模型自由发挥，而是把模型纳入一个受控的执行系统中
这个系统的目标不是：
❌ “让模型更会说”
而是：
✅让模型在复杂任务中稳定完成事情
五、一个成熟 Agent 必须解决的四个问题
1. 预算控制（Budget Awareness）
资源是有限的，包括：
- token
- 上下文长度
- 工具调用次数
- 推理轮数
- 成本（钱）
如果没有预算控制，会出现：
- 无限循环调用工具
- 上下文爆炸
- 成本失控
👉 本质：系统必须知道“什么时候该收手”
2. 错误恢复（Recovery）
现实系统一定会出错，比如：
- 输出被截断
- 工具调用失败
- 返回格式错误
- 上下文超限
成熟 Agent 应该具备：
- 重试
- 修正
- 降级
- 补偿执行
👉 本质：不能因为一次失败就崩掉
3. 上下文自救（Context Management）
多轮执行会导致上下文膨胀：
- 历史对话
- 工具调用记录
- 中间推理过程
问题：
- 超出窗口限制
- 注意力稀释，性能下降
解决方法包括：
- message clipping（裁剪）
- history snip（历史抽取）
- microcompact（轻压缩）
- context collapse（摘要折叠）
- autocompact（自动触发）
👉 本质：保留“关键记忆”，丢弃“冗余细节”
4. 工具失败后的推进能力
工具是最不稳定的环节：
- API 失败
- 文件不存在
- 权限问题
- 返回空数据
弱 Agent：
“调用失败了，结束。”
强 Agent：
- 分析失败原因
- 换方法重试
- 缩小问题范围
- 跳过非关键步骤
- 输出部分结果
👉 本质：即使工具失败，也要继续推进任务
六、为什么很多“Agent”其实不算 Agent
很多系统只是：
- 一个 Prompt
- 几个工具
- 一个简单循环
但缺少：
- 状态管理
- 预算控制
- 错误恢复
- 上下文治理
- 失败推进能力
结果就是：
- 时好时坏
- 多轮后崩溃
- 工具失败就卡死
- 成本不可控
👉 所以作者的核心判断是：
没有这些结构，所谓的 Agent，只是一个“不稳定的执行器”。
七、Query Loop 在做什么（工程本质）
一个成熟的 Query Loop，每一轮都会做：
- 上下文治理（裁剪 / 压缩）
- 资源检查（预算是否充足）
- 调用模型
- 判断是否调用工具
- 执行工具
- 处理结果
- 异常恢复
- 决定是否继续
换句话说：
它不是在“调用模型”，而是在“调度一个任务执行过程”
八、总结（一句话版本）
Prompt 决定了 Agent “看起来像什么”，
而 Query Loop 决定了它“能不能真正把事情做完”。
一个真正成熟的 Agent 系统，本质是一个具备：
- 状态管理
- 预算控制
- 错误恢复
- 上下文压缩
- 工具失败容错
的任务执行系统，而不仅仅是一个“会调用工具的模型”。
