一次运行六周的编程智能体实践及其监督方式

两位 OpenAI 工程师介绍长期运行的编程智能体：一人负责工程效率，另一人负责开发者体验。他们先展示构建交互式 3D 场景的实验。

开发者体验工程师让 Codex 和 Astra 根据七张参考照片构建可探索的 Ferrari 模型和网站。他与智能体协作了几天，并说它还制作了黏土和线框视图。

随后，他要求制作 Nürburgring 赛道的飞行浏览动画。他说 Codex 调查了长 21 公里的赛道，使用子智能体检查几何形状和规划渲染，并在内存问题和过热中断后从已保存帧继续。

负责工程效率的讲者将其与早先详细的执行计划对比。他说，使用较新模型时，他更愿意说明结果、权衡和成功检查方式，让智能体自己选择步骤。

他的团队维护持续集成系统，自动测试代码变更。不稳定测试可能一次失败、下次通过，排查原因很费时，而新的失败还会不断出现。

他让一个智能体监控并修复这些失败。他说，智能体运行了六周，直到同事开始运行类似智能体；最初的提示词约 200 字，规定了代码库、沟通方式和 CI 资源规则。

起初，一个聊天负责调查和修复问题，但难题会占用它处理新问题的时间。四天后，他让主聊天收集失败、组织工作和沟通，把具体调查委派出去。

他报告称，运行期间智能体每周创建超过 100 个拉取请求，累计提交超过 1000 次、发送 600 多条 Slack 消息，并合并了自己的 213 项修复。在其他情况下，它发现同事已有类似修复，便优先处理对方的工作。

他说，这次运行调用工具近 50 万次，使用超过 5800 个子智能体会话。其中 6.7 万多次调用是等待，反映了测试和 CI 作业所需的时间。

一个困难案例涉及 GPU 测试中间歇出现的浮点错误。子智能体关联日志、锁定特定节点，并在数天内学会在该节点反复运行测试。

智能体联系负责该系统的研究人员，询问原因是否可能是未记录的优化或硬件故障。当它不确定删除失败测试是否合适时，有时会在人工审查前让另一个智能体质疑拟议修改。

开发者体验讲者建议每个目标使用一个聊天，并提供具体目标及可供智能体检查工作的测试。他建议在 AGENTS.md 中记录项目规则和限制。

精简工作日志可以记录已尝试的内容和剩余事项，让中断后的恢复更容易。上下文压缩则把相关信息带过长时间的对话。

远程环境让工作无需笔记本电脑持续运行也能继续。讲者介绍了连接远程机器或使用 Codex Cloud，并在之后恢复环境。

插件可以让智能体从 GitHub、Linear 等来源获取相关背景，包括已有问题、拉取请求和讨论。这有助于它了解相关工作，而不是盲目重复。

大型工作可以按独立部分拆分为子聊天，例如分别处理 3D 模型和网站。独立 worktree 为并行工作提供不同的代码检出，用户可以打开并调整各个聊天。

讲者介绍了用于提问的侧边聊天，以及针对难题使用更多推理和子智能体的模式。他们区分了适合并行聊天的独立工作和单个困难调查。

当工作依赖审查等外部事件时，定时心跳可以回到同一聊天并根据新反馈行动。单独的定时任务则可以用于生成周期性摘要。

负责工程效率的讲者按价格估算，原先六周运行的成本约为每小时 32 美元，并说换用后来的模型可将估算降至 16 美元。他指出，代码审查和 CI 资源等也是额外因素。

他建议从重复工作入手，为智能体提供测试和完成标准，明确何时升级给人处理，并设置支出或 CI 并发限制。