04 - 会话循环

从一轮对话到多轮会话

对话循环解决了人机交互的基本结构，行动循环扩展了单次交互中的自主能力。但两者都隐含一个假设：所有问题可以在一轮对话中得到解决。

这个假设在实践中很快失效。原因有二：

• 第一，模型能力的衰减。 随着上下文窗口的填充，模型的推理质量会逐渐下降。早期的对话细节被淹没在大量的 Token 中，模型开始遗忘关键信息、重复已完成的步骤、在细枝末节上纠缠。
• 第二，推理成本的膨胀。 注意力机制的复杂度与序列长度呈平方关系。当对话历史从 1K Token 增长到 32K Token，单次推理的开销不再是 32 倍，而是接近 1000 倍。这是一个不可持续的成本曲线。

因此，复杂任务必须被拆解到多个对话中完成。每个对话承载一个子目标，多个对话串联起来推动整体目标的实现。这就是会话循环（Session Loop）：

Session 1: 需求分析 → 设计草案
    ↓
Session 2: 细化设计 → 模块划分
    ↓
Session 3: 编码实现 → 单元测试
    ↓
Session 4: 集成测试 → 修复缺陷
    ↓
...

无限游戏

有些任务甚至没有明确的终点。一个开源项目的维护、一个在线服务的运营、一个知识库的积累——这些都是无限游戏（Infinite Games）。

在无限游戏中，Agent 不是被调用一次就完成任务，而是长期驻留，持续响应外部事件：

• 新的 Issue 被提交
• 安全漏洞被披露
• 依赖库发布新版本
• 用户提出功能需求

每一个事件都可能触发一个新的 Session，Session 的结果又会影响后续的响应策略。Agent 在这种循环中积累经验、建立上下文、形成对项目的深层理解。

这与单次调用的 ChatBot 有本质区别。无限游戏需要状态跨越 Session 持久化，需要学习机制，需要对历史的回顾与反思。

任务特性决定设计

如果说对话循环和行动循环的结构相对标准，会话循环则呈现出高度碎片化的面貌。不同的任务类型催生了截然不同的设计模式：

• 批处理型任务：一次性处理大量输入，追求吞吐量和资源效率。Session 之间无依赖，可水平扩展。
• 流水线型任务：Session 按固定顺序执行，前一个 Session 的输出是后一个的输入。需要严格的版本控制和状态传递机制。
• 探索型任务：目标模糊，需要在 Session 中逐步澄清。Session 可能被中断、回溯、重新开始。需要分支管理和回滚能力。
• 协作型任务：多个 Agent 参与同一个 Session，或跨 Session 接力。需要明确的权限边界和冲突解决机制。

社区中甚至存在根本性的分歧：一派强调 Session 的确定性——给定相同的输入，应该产生相同的输出；另一派接受 Session 的开放性——Agent 应该能够从历史中学习，对相同输入做出不同响应。这两种立场指向完全不同的工程实现。

隐藏的复杂性

会话循环的复杂性往往被低估。它不只是在多个对话间串行执行，而是在每个 Session 的开始和结束处承载着大量边界工作：

Session 初始化：

• 更新 API 凭证，确保调用权限未过期
• 加载系统提示词，注入当前 Session 的角色定义
• 读取用户级配置（~/.config/agent/...）和项目级配置（./.agents/...）
• 扫描可用工具列表，建立工具名称到实现的映射
• 恢复上一 Session 的上下文状态，继续未完成的任务

Session 收尾：

• 更新执行日志，记录本次 Session 的轨迹
• 发送遥测数据，用于性能监控和异常检测
• 通过邮件或 IM 通知用户任务完成或需要介入
• 生成检查点，保存中间产物供后续 Session 恢复
• 清理临时资源——数据库连接、文件句柄、子进程

在云端部署的 Agent 中，收尾工作还可能涉及：

• 释放计算实例，停止计费
• 归档日志到对象存储
• 触发下游工作流

这些工作不在模型的控制之下，却是生产环境中 Agent 可靠运行的基础。

工程可靠性的基石

对话循环和行动循环的改进往往是普适的。一个更高效的注意力机制、一个更聪明的工具调用策略，一旦被验证，就会迅速被主流框架吸收，成为行业标准。这些改进加速了 Token 的销售，但难以构成竞争壁垒。

会话循环则是另一回事。它深深嵌入在特定的工作流程、组织规范、合规要求之中。一个为医疗诊断设计的 Session 管理机制，与为金融交易设计的机制，可能截然不同——不是因为技术原理不同，而是因为约束条件不同。

在会话循环层面的优化，往往是企业建立差异化能力的关键。

这包括：

• 与内部 IAM 系统集成的凭证管理
• 符合审计要求的日志和追踪
• 针对特定业务场景的 Session 切分策略
• 跨 Session 的知识沉淀和复用机制

这些不是框架可以替你做决定的事情。它们需要你对业务有深入理解，在可靠性、成本、用户体验之间做出权衡。

从三层到整体

回顾这三层循环：

| 层级 | 边界 | 核心问题 | | ---- | ----------------------- | ------------------------ | | 对话 | User ↔ Assistant | 控制权如何交替？ | | 行动 | Assistant ↔ Environment | 如何调用工具、处理结果？ | | 会话 | Session ↔ Session | 如何拆解目标、沉淀状态？ |

对话循环定义了交互的基本节拍，行动循环扩展了单次交互的能力边界，会话循环则将 Agent 的寿命从一轮对话延长到完整任务乃至无限游戏。

当你设计一个 Agent 系统时，不妨从会话循环开始思考：这个任务需要多少个 Session？Session 之间如何传递状态？哪些工作应该在 Session 开始和结束时完成？

这些问题的答案，将决定你的 Agent 是在玩具级别徘徊，还是能够在生产环境中可靠运行。