最简单的 Agent Loop 包含哪些步骤？Message 有哪些类型？

先这样答

最简单的 Agent Loop 包含组装上下文、调用模型、执行工具并回填、判断终止这四个步骤。交互过程中的 Message 按业内通用标准分为 system、user、assistant 和 tool 四种类型。

Agent Loop 靠不断追加消息运转。系统先将全局指令、可用工具定义与历史对话组装为上下文发给模型。模型会输出普通文本或发起工具调用请求。若模型决定调用工具，框架会拦截请求并执行，将结果作为新消息回填到上下文中。随后程序判断模型是否给出最终回答，或是否触发步数上限、用户中断、死循环检测等终止条件。若未终止，包含新消息的上下文会发给模型进入下一轮循环。

上下文中传递的 Message 列表严格遵循角色设定。system 承载全局指令与人设，user 代表用户输入。assistant 是模型回复，含文本与工具调用请求，tool 专门存放工具执行结果。在工程上，assistant 的调用请求与 tool 的结果必须通过唯一标识符对齐，消息顺序错乱或 tool 结果缺失是多数框架报错的根源。若上下文超限，需按消息粒度裁剪，优先丢弃中间轮次，但必须保留 system 消息与近期对话。

Agent 的核心逻辑就是通过这四类消息的有序追加来驱动四步循环，实际工程中重点要做好死循环拦截与消息序列对齐。

面试官会怎么追问

• 「如果模型一直调工具，或者在两个工具之间反复横跳，怎么打断？」 答法是在循环中设置最大步数上限，达到阈值强制终止。同时在工程上引入重复检测机制，若发现模型连续多次使用相同参数调用同一工具，直接触发预警并向模型注入提示，要求其给出最终回答。
• 「随着循环次数增加，上下文超出模型窗口限制了怎么处理？」 答法是按照消息粒度进行滑动窗口裁剪，不能截断单条消息的中间内容。裁剪时必须保留 system 消息以维持人设和工具定义，同时保留最近几轮的对话消息，优先丢弃较早的中间轮次。
• 「为什么调用工具后，再次请求模型经常会报错？」 答法多数是因为 assistant 的工具调用请求和后续回填的 tool 消息没有正确对齐。框架要求这两条消息必须包含相同的唯一标识符，若 tool 消息缺失或标识符不匹配，模型就无法识别执行结果，从而导致上下文校验失败报错。

回答的坑

把工具执行结果作为 user 消息传给模型是早期不规范的做法，正确方向是使用专用的 tool 消息类型并与调用请求的标识符严格对齐。

只描述模型推理和工具执行交替却不提终止条件是常见失误，正确方向是必须说明步数上限和死循环检测，这是保障程序不失控的底线。