从写代码，到管理多个智能体
在 AI Engineer Code Summit 的“与 Codex 协作的新方式”工作坊上，OpenAI 开发者体验工程师 Dominik Kundel 和 Charlie Guo 介绍了三条工作流：云端执行、语音调度，以及个人智能体 dots。
重点不只是让智能体完成单个编码任务，而是开发者如何在不同环境、多个任务之间完成委派、跟进和审查。对于在写好标智库关注 AI 开发工具的读者，这次讨论值得留意的是工作流如何组织，以及这些交互方式目前仍有哪些限制。
云端交接：复用环境，不等于自动衔接所有上下文
Codex 于 2025 年 5 月推出时，被定位为能够并行处理多个任务的云端软件工程智能体。不过，Kundel 表示，模型与运行框架经历了一段磨合，才逐渐形成更易用的体验。
工作坊介绍的新版 Codex Cloud 支持配置并发布一次环境，再让多个任务在该环境的独立实例中运行。用户可以选择允许访问的 GitHub 仓库；环境既可供个人使用，也可在公司内部共享。
需要区分的是：环境可复用，与本地任务能否顺畅交接到云端，是两个问题。 Kundel 表示，交接的一部分难点在于管理两种环境之间的上下文差异。他自己的做法之一，是直接要求本地 Codex 将工作交接给云端。
演示中，他重新打开了一个已有的云端任务，展示了仍附在任务中的 Appshot——一张本地 Mac 应用窗口的捕获画面。
按照他的描述，云端正在成为另一种后台执行位置，而不再是一套完全分离的工作流程。本地 Codex 可以发起云端任务，但这并不意味着所有上下文差异都已解决。
语音调度：不只是把提示词说出来
Kundel 使用一个虚构唱片公司的网站，演示了快速修改页面的过程，并介绍了自己通过语音口述需求、迭代界面的做法。
Guo 则提出了另一种思路：把语音当作工作流的控制层，而不只是键盘输入的替代品。
他关注的操作包括：
- 管理不同工作线程；
- 查看任务进展；
- 从电脑上的其他应用获取信息；
- 创建新的工作线程；
- 向不同智能体分派任务。
这里的区别在于，语音不仅用于描述“要改什么”，也用于安排“哪个任务由谁处理、现在进展如何”。
Kundel 还介绍了通过语音与个人智能体交流的习惯。按他的描述，他的 dot 能访问自己的开发机器、笔记本和云端环境，因此掌握了较多工作上下文，可以协助发起拉取请求（PR），供他随后审查。
这属于他个人配置下的使用经验，不代表所有用户默认拥有相同的访问能力。
个人智能体 dots：承接任务、补漏与跨场景协作
对于 dots，Guo 的评价并非一味肯定。他表示，即使是 Codex 重度用户，也可能觉得 dots 用起来有些别扭，因为这是一种新范式，擅长的事情与主 Codex 并不相同。
他总结了三类对自己有用的场景：
- 补漏提醒：标记可能被忽略的事项，充当一道检查保障。
- 任务委派入口：接收交办工作；他提到自己经常在 Slack 中这样使用。
- 跨工作场景协作：团队希望让 dots 出现在用户工作的更多位置。
Kundel 则表示，自己会从 dot 发起不少任务，而不是直接向 Codex 提示。原因是 dot 往往已经具备相关上下文，能够帮助管理任务并推进 PR。
这两位工程师的分享也提示了一个使用边界：dots 并不是简单换一个入口来调用主 Codex。它的交互方式和适用场景，需要用户重新摸索。
哪些地方仍需要磨合？
这次工作坊保留了几个明确的限制：
| 工作流 | 展示的能力或用法 | 仍需注意的边界 |
|---|---|---|
| 云端交接 | 复用已配置的环境，在独立实例中运行多个任务 | 本地与云端的上下文衔接仍需改进 |
| 语音调度 | 管理线程、查看进展、创建和分派任务 | 不宜把演示中的个人配置视为默认能力 |
| 个人智能体 dots | 接收任务、补漏提醒、利用已有上下文推进工作 | 新交互方式尚不完全直观，与主 Codex 的擅长领域不同 |
工作坊最后，Kundel 给出的建议包括：适当调低推理投入级别，以及主动向智能体寻求帮助。
这些工作流提供了更多任务组织手段，但尚未构成一套固定不变的最佳实践。 Kundel 的提醒是，不必过度依赖当前的操作习惯，因为产品和协作方式仍在持续变化。
