OpenAI
Wesley Pasfield 在 2026 年 5 月的笔记本里搭了一条闭环：真实轨迹、人工和模型反馈、Promptfoo 评测、HALO 排序，再交给 Codex 改支架。评论先过，再考虑自动合并。
来源：Wesley Pasfield（OpenAI），2026 年 5 月 12 日，Cookbook《Build an Agent Improvement Loop with Traces, Evals, and Codex》。
这篇笔记本做的是一条改进飞轮，而不是再演示一次怎么把 Agent 跑起来。顺序是：从真实轨迹开始，加上人工反馈和模型反馈，把反馈变成可以重跑的评测，再用这些证据提出下一批支架改动，交给 Codex 去实现。
这里的支架（harness）是模型外面的整份合同：指令、工具、路由、输出要求和校验。飞轮要保住的是每次运行学到的东西。轨迹说明发生了什么，反馈说明什么重要，评测把这些期望变成可重复的检查，Codex 则对得到的改动集动手。
例子里具体有什么
示范 Agent 用 OpenAI Agents SDK，扮演一名财务分析师，为一家虚构公司做收购尽调。它阅读财务导出、客户数据、合同、安全笔记、董事会材料和管理层叙述，用引用和可复核的产物回答尽调问题。笔记本里对五次运行留下轨迹。
闭环结束时应有六样东西：这个分析师及其五次带轨迹的运行；同一批轨迹上的人工反馈和模型生成的反馈；自动生成的 Promptfoo 评测套件；对当前行为的一道 Promptfoo 校验门；一次用 HALO 对轨迹、反馈和评测结果做的优化；一份给开发者的 Codex 交接说明，让它去实现建议的支架改动。
往下传的是一个文件：产物目录里的 codex_handoff.md。里面有 HALO 的诊断、排好序的建议、背后的证据，以及 Codex 做下一次支架更新需要的实现说明。
自动化到哪一步由人定
开发者可以只用这条环路提出一份待审的改动集，也可以接到自动开拉取请求、合并和部署的流程上。作者建议的起点是审阅式环路：系统提出改动，开发者在合并前看 diff。评测门越被信任，同一份交接才适合更深的自动化。无论哪一种，核心都一样：轨迹加上人工和模型反馈，变成具体的支架改动，而不是散落的评论。
和停在轨迹或评测的例子相比，这份笔记本把轨迹、审阅判断、生成的评测、优化和实现交接放进同一条可运行的环路。运行依赖当时的模型输出，不是事先录好的假轨迹。依赖包括 Python 侧的 openai、openai-agents、halo-engine，以及用 npx 跑的 Promptfoo。
原文：https://developers.openai.com/cookbook/examples/agents_sdk/agent_improvement_loop
觉得有用，转给同事
微信扫码
用微信扫一扫，在手机上打开后即可转发。