读懂一轮 Agent 与继续执行

新提示与继续不同

agentLoop 接受 prompts 并加到上下文；agentLoopContinue 不增加新消息。后者的 77–83 行只检查两件事：列表为空时抛错，最后一条消息 role 为 assistant 时抛错。注释还要求 convertToLlm 后末尾为 user 或 toolResult，这个条件没有在入口完整验证。因此练习里的 assertCanContinue 只是复现局部检查，不能被当成所有供应商的消息合法性验证器。

export function assertCanContinue(messages: { role: string }[]): void {
  // 实现原函数中的两项前置检查
}

循环为何会再次请求模型

runLoop 的外层处理任务结束后到来的 follow-up，内层处理工具调用和 steering 消息。prepareNextTurn 可在后续回合安装新的快照。响应包含工具调用时，运行时执行工具，将每个 toolResult 同时写入 currentContext.messages 和 newMessages，再判断继续或停止。若输出因为 length 截断，源码走失败工具结果路径，避免执行参数可能不完整的调用。

用确定性轨迹验证理解

源码只读不意味着你不用动手。先给自己的最小循环一个假模型：第一次输出工具调用，第二次输出最终答案；假工具返回固定观察。检查第二次请求确实看到工具结果，且停止后不再调用模型。再用空消息、末尾 assistant、末尾 user、末尾 toolResult 验证局部检查。四项测试通过只证明这四个分支，不证明完整 Agent、外部权限或供应商兼容。

执行耗时与取消要分别记录

1.1 的工具结果和 tool_execution_end 新增 durationMs，表示 execute() 实际耗时，使用单调时钟并排除 hooks；没有执行的调用不带这个字段。缺少 durationMs 不能擅自记成零，也不能用界面等待时间替代。集成还要检查会话的最终事件，分开成功、取消与错误，才能让轨迹解释任务如何结束。

最终停止不一定是完成

AgentSettledEvent 表示这次运行已彻底稳定，不会自动重试、压缩或排队继续；1.1 增加 aborted，供集成识别用户取消。aborted:true 不能被计作成功交付；aborted:false 也不代替你的业务验收。用假事件测试完成和取消两个分支，不需要调用真实模型。