智能体运行身份解析，一次基金比较背后的三次Run与三次ModelTurn

当用户在一个聊天窗口中要求智能体比较两只基金、追问费用差异、再生成对比表格时，表面上是连贯的三次提问，系统内部却可能触发三次独立的‘运行’（Run），而每一次Run内部又包含多个‘模型回合’（Model Turn）。这种看似冗余的结构设计，并非工程过度抽象，而是为应对真实场景中目标延续性、执行不确定性与状态恢复需求所必需的底层机制。

以Open ETF Agent v0.28.0的公开实现为例，该系统将一次用户会话（Conversation C1）映射为一个长期目标（Task T1：理解基金A与B的差异），但实际执行被拆解为三个独立运行单元：R1（基础比较）、R2（费用补充分析）、R3（结果结构化输出）。这三者共享同一对话上下文，却各自拥有明确的起止边界——R1结束时报告已生成，R2启动时可读取R1结果，但R1本身无需持续驻留内存。这种设计避免了将整个对话强绑定于单一执行进程，提升了系统的可扩展性与容错能力。

图1清晰展示了该逻辑：用户未切换窗口，但系统识别出三次独立完成的Run。关键前提在于“追问发生在上一轮结束之后”——即R1明确返回“比较报告已完成”，用户才发起新请求。若用户在R1执行中途插入问题（如“准备持有多久？”），则该补充信息会被纳入当前Run的中间状态，而非开启新Run。这说明，“继续”的语义高度依赖于执行阶段的判定标准：是等待用户输入的暂停，还是逻辑闭环后的终止。

进一步聚焦R1内部，其并非单次模型调用即可完成。系统将R1分解为三个模型回合（M1、M2、M3）：

• M1：模型接收初始问题与可用工具列表，提议读取基金A、B的公开资料（X1、X2）；
• M2：在X1、X2结果返回后，模型发现B的费用数据缺失出处，遂提议补读费用公告原文（X3）；
• M3：X3结果到位后，模型整合全部信息，生成最终比较结论。

每个Model Turn对应一次确定输入下的逻辑决策输出，无论输出是回答还是工具调用提议。值得注意的是，工具提议（如X1/X2/X3）、实际执行（系统调用API获取文档）、结果保存（本地缓存或数据库写入）与后续输入组装（将新观察注入下一轮Prompt），属于四个不同事件流。它们必须被独立追踪，否则将导致状态混淆——例如，若X3请求失败后系统直接重发X3而未保留前次失败记录，用户无法追溯为何某部分数据始终缺失。

图2呈现了这一过程：三次模型回合驱动三次工具动作，形成“观察→决策→执行→再观察”的闭环。其中M2的触发条件是M1输出的结果暴露了信息缺口，而非预设流程。这揭示了智能体运行的核心特征：动态适应性。系统不预设完整步骤链，而是根据每轮反馈实时调整下一步策略。

更复杂的场景出现在请求失败与重试环节。假设M2提出的X3请求因网络超时失败，系统面临两种选择：一是新建一个身份（如R1’）重新执行整个R1，二是保留原R1上下文，在M2基础上重试X3。前者看似简洁，实则埋下隐患：若用户后续询问“上次查到的费用数据为什么没用？”，系统无法关联到R1中已发生的失败尝试；后者虽需维护更多状态，却能确保所有操作痕迹可追溯。

图3对此作出明确区分：在M2阶段，系统记录“A2.1 本次请求失败，尚未取得有效输出”；满足重试条件后进入A2.2，获得本轮输出，但前次失败记录仍被保留。整个示例共3个模型回合、4次请求（X1、X2、X3失败、X3成功），印证了“结果未知时，不能靠新建身份掩盖重放风险”的设计原则。

需要强调的是，Session、Worker与Schedule并非垂直分层架构，而是分别承担状态管理、执行调度与时间触发职能的协作模块。Session负责维持对话上下文与任务目标的映射；Worker是实际执行Run的计算单元；Schedule则处理延迟执行、周期任务等时间敏感操作。三者可复用、可组合，不必强制解耦为独立服务。工程师应优先厘清“继续”的范围——是延续目标、恢复执行，还是重新发起？再据此决定状态保留粒度与恢复机制。

当前主流框架如OpenAI Agents SDK，已明确区分“单次Run内的代理循环”与“同一会话中后续Run的启动”。这意味着开发者无需将Session、Run、Turn视为统一标准模型，而应依据产品需求灵活建模：面向长周期研究的产品需显式管理Task对象；面向即时问答的轻量应用则可省略Task层，仅用Conversation+Run即可。

在工程实践中，常见误区是将教学图示直接当作数据模型照搬。例如，误以为每个Run必须绑定唯一Worker进程，或认为Model Turn必须严格按顺序编号。实际上，R2可复用R1的Worker资源，M3也可在M1未完全结束时提前预加载部分数据——只要保证逻辑因果不颠倒、状态变更可回溯即可。

随着智能体从单轮问答走向多步骤推理，运行身份的精细化管理正成为系统可靠性的关键。它不仅影响错误排查效率，更关系到用户对结果可信度的判断。当智能体说“已整理成一页对比表”，用户隐含期待的是：该表基于完整、可验证的数据链生成。若背后存在未披露的重试或跳过步骤，即使结果正确，也会削弱系统透明性。

未来，随着Agent工作流标准化推进（如W3C正在讨论的Agent Communication Protocol），运行身份的语义定义有望收敛。但在现阶段，工程师仍需回归具体业务场景，沿着“用户目标—模型决策—系统动作—结果沉淀”链条逐层拆解，才能构建出既健壮又可解释的智能体执行体系。

值得补充的是，此类设计挑战在金融、医疗等高可靠性领域尤为突出。例如，基金比较中若遗漏某份关键公告的时效性校验, 即使最终表格格式完美, 也可能引发合规风险。因此，将“失败记录保留”“请求留痕”作为默认行为，而非可选配置，应成为行业共识。

智能体的“继续”不是简单的流程接续，而是多维度状态的协同演进。理解Run与Model Turn的边界，本质是在人机协作中划清责任归属：哪部分由模型判断，哪部分由系统保障，哪部分需用户确认。唯有如此，才能让智能体真正成为可信赖的协作者，而非黑箱执行器。