智能体工作何时需要循环、子智能体和共享日志

OpenAI 应用 AI 工程团队的 Raj 说，随着模型进步，智能体设计也在变化。他与开发者体验工程师 Eric 回顾了从单一循环到长期运行和多智能体协作的演变。

Raj 回忆起让早期 ChatGPT 编写 FizzBuzz，再自己把代码复制到编辑器中运行。下一步变化是让模型通过工具执行自己的推理结果。

在图像分析例子中，模型可以放大图片、检查细节并决定下一步。Raj 将行动、反馈和规划的过程称为智能体循环。

Codex 通过计算机访问扩展了这一思路。模型与外围运行框架共同设计：框架提供工具和反馈，训练则帮助模型使用它们。

运行框架管理指令、工具、执行和上下文。Raj 说，Codex 倾向于使用少量通用工具，例如 shell、文件系统和计算机操作，让模型自行判断如何处理任务。

Responses API 将上下文和工具定义传给模型；运行框架在沙箱中执行请求的工具，并把结果加入对话。框架设计和模型训练相互影响。

长任务会让指令、文件、工具调用和结果填满上下文窗口。压缩机制浓缩历史，让智能体保留有用信息并继续工作。

Raj 说，Codex 训练模型理解压缩，并从压缩后的状态继续。这让工作可以跨越多个上下文窗口和压缩事件。

早期模型可能取得进展却在完成任务前停止，因此用户会反复发送继续指令。外层循环和 Ralph 式循环将重复尝试自动化，并通过文件在运行之间传递状态。

Codex 后来加入保存在对话上下文之外的目标。运行框架跟踪目标，可以在一轮结束后继续，也可以在遇到真正阻碍时停止。

Raj 说，后续训练把更多持续工作能力加入模型本身：模型可以识别有用步骤并检查工作，无须反复收到继续提示。更好的协调能力又让并行工作成为可能。

Eric 建议大多数任务先从一个智能体、明确任务和结果检查方式开始。只有任务确有需要时才增加智能体，因为额外智能体会消耗令牌，却不一定提高速度或质量。

彼此独立的审查或并行调查可能适合委派。每个子智能体有自己的工作上下文，但复杂结构也可能增加协调工作而没有带来价值。

Eric 介绍了按需调整工作强度：主模型可以在遇到难题时向更强的模型求助，并将简单辅助工作交给较小的智能体。他提醒，这并不保证成本更低。

在移植一款旧游戏时，他让一个智能体捕获正在运行的原作，另一个在 Blender 中解包并可视化场景。由于输出格式会影响捕获方法，两者需要交换发现。

他区分了用户可见的聊天与子智能体：一个协调聊天可以管理其他聊天，而每个聊天又可以使用自己的子智能体。用户可以打开并调整单独的聊天。

对于长期游戏项目，不同聊天可以负责美术、编程和测试。Eric 提醒，复杂的审批层级可能拖慢智能体，形成他所说的中层管理成本。

频繁的用户调整可能让原始目标在多次压缩后逐渐偏离。Eric 建议维护精简工作日志，记录目标、当前工作、负责人和决定，而不是记录每一次失败测试。

他提醒，最佳实践有时效性。随后 Raj 讨论了更大规模协调智能体的挑战。

Raj 说，OpenAI 的一项数学工作使用了 1 万个智能体、270 万条消息和约 1300 亿输出令牌。他介绍了不同团队围绕共同目标探索不同方法，并跨团队交流发现。

各团队探索假设、挑战前提并运行实验。工作揭示出有希望的新问题后，系统创建新团队或调整现有团队方向，但总体目标保持不变。

Raj 报告称，内部模型参与取得了数学成果，并认为更强的模型可能支持更有雄心的工作。他鼓励开发者重新尝试早期模型无法完成的问题。