为什么 Prompt 不等于 Agent：从 Query Loop 看智能体的真正核心

在很多关于大模型应用的讨论中人们很容易陷入一个误区只要写好了 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 系统本质是一个具备状态管理预算控制错误恢复上下文压缩工具失败容错的任务执行系统而不仅仅是一个“会调用工具的模型”。