夜雨聆风
01 从会话切到任务
OpenAI 最近发布了一篇博客，介绍了一个叫 Symphony 的内部工具。
它指向 AI 编程的一个新变化：
未来，你可能不再打开一个聊天窗口，手动指挥 agent 写代码。
而是会维护一个任务面板。
agent 自己领任务，自己执行，失败了自己恢复。
你只负责三件事：
定义任务。
设置边界。
检查结果。
OpenAI 之前的做法，是让工程师同时开几个 Codex 会话。
02 人的注意力成了瓶颈
表面上，是 agent 在并行写代码。实际上，是人在来回切上下文。
要盯进度、要判断，失败了，还要手动重试。
他们发现，一个人同时管理 3 到 5 个 Codex 会话，基本就到极限了。
再多，生产力反而会下降。人的注意力成了瓶颈。
Symphony 要解决的，就是这个卡点：
把 AI 编程从“人盯着聊天窗口”，变成“系统调度任务队列”。
Symphony 的核心变化，就是把工作单元换掉。
03 工作单元变成 issue 和 ticket
它不再把一次会话或者一个窗口当作工作单元。
它把 issue、task、ticket 当作工作单元。
会话是过程。
任务才是软件开发真正围绕的对象。
所以 Symphony 关心的是：
任务系统里有哪些工作？
哪些任务可以开始？
哪些任务被阻塞？
每个任务应该由哪个 agent 接住？
人应该在哪个节点 review？
OpenAI 用 Linear 来承载这个任务面板。
04 任务队列如何自动跑起来
你可以把 Linear 理解成工程团队的任务看板。人先在 Linear 里创建任务。
写清楚要改什么，怎么验收。
然后 Symphony 在后台轮询这个看板。
发现有任务能做，它就自动拉起一个 agent。
这个 agent 拿到任务描述。
进入自己的独立 workspace。
开始改代码、跑测试、产出结果。
如果中途失败，Symphony 会自动重启和重试。
等任务完成，结果再进入人类 review。
这就是从聊天窗口到任务队列。
人不再一个窗口一个窗口地催。
任务放到看板上。
系统自己派发。
agent 自己执行。
失败自己恢复。
最后把结果送到你面前。
这里有三个机制，支撑这个变化。
05 轮询、隔离、重试
第一个机制，是轮询。系统持续扫描任务板。
哪些任务处在活跃状态。
哪些任务没有被阻塞。
哪些任务还没有 agent 在跑。
一旦发现可以执行，就启动 agent。
这个机制解决的是“谁来触发”的问题。
在聊天模式里，触发者永远是人。
你不打开窗口。
AI 就不会开始。
在任务队列里，任务状态本身就是触发器。
第二个机制，是隔离。
每个任务一个独立 workspace。
它解决的是并行的基本前提。
多个 agent 同时改东西，最怕互相污染。
A 任务改到 B 任务的文件。
B 任务带乱 A 任务的上下文。
最后得到的并行，会变成一团难以复盘的混乱。
隔离 workspace 的意义，就是让每个任务有边界。
边界清楚，才谈得上并行。
第三个机制，是自动恢复。
agent 会失败。
会卡住。
会超时。
如果每次失败都要人回来处理。
系统还是没有摆脱人工监督。
Symphony 的做法，是失败后自动重试。
间隔逐步拉长。
从 10 秒，到 20 秒，到 40 秒。
最后封顶到 5 分钟。
这个机制解决的是“谁来兜底”的问题。
很多失败，不值得立刻打断人。
很多临时问题，系统自己重试就能恢复。
轮询、隔离、重试。
这三件事合在一起。
才让 AI 编程从对话，变成守护进程。
对话模式里，AI 在等你。
守护进程模式里，系统一直在跑。
人的角色从司机，变成调度员。
司机要一直握着方向盘。
调度员不需要坐进每一辆车。
这种方式带来五个直接好处。
06 五个直接变化
第一，工作单元变大了。到了 Symphony 里，任务可以先变成计划。
agent 先分析代码库、Slack 或 Notion。
产出实现方案。
人确认之后，agent 再把方案拆成任务树。
任务之间的依赖也会写清楚。
比如 React 升级，要等 Vite 迁移完成。
那系统就先跑 Vite。
再跑 React。
并行不能一起乱跑。
系统要知道什么能同时做，什么必须等。
第二，探索成本明显下降。
过去你想试一个重构方向。
要开窗口、交代背景、看着它跑、中途处理问题。
现在你可以把探索写成一张任务卡。
让 agent 去分析、尝试、产出结果。
结果不对，扔掉就行。成本很低。
OpenAI 原文说得很直接。
agent 做错了，也会留下有用信息。
代价接近于零。
这改变了行为模式。
过去不值得尝试的事，现在可以先跑一轮看看。
第三，发起工作的人变多了。
产品经理和设计师，也可以直接把功能请求写进 Symphony。
他们不需要 checkout 仓库。
不需要管理 Codex 会话。
描述功能，然后拿回一个 review packet。
里面甚至有功能 walkthrough，展示功能在真实产品里跑起来的样子。
AI 编程开始离开单个工程师的聊天窗口。
它开始进入团队的任务系统。
第四，最后一公里被接管了。
在大 monorepo 里，landing 一个 PR 是很慢的。
要看 CI、要 rebase、要解冲突、要重试 flaky checks。
Symphony 自动处理这些。
等任务到了 Merging 状态。
团队就更有把握。
这个变更能进 main。
中间不需要人一直盯着。
第五，工作随时随地可以推进。
因为 Symphony 跑在 devbox 上，不睡觉。
你从任何地方往任务板里加一张卡，agent 就会接住。
OpenAI 提到一个细节。
团队里有个工程师，在小木屋里。
用手机上的 Linear app，推进了三个重大变更。
还有一点值得单独说。
07 它也会发现新任务
agent 在实现或 review 时，经常发现当前任务之外的改进机会。
性能问题、重构方向、更好的架构。
它会自己新建 issue，人之后再判断要不要排期。
所以任务队列不只是执行清单。
它开始变成一个会自我生长的工作系统。
但边界也在这里。
08 边界在哪里
Symphony 适合接住大量常规实现。适合边界清楚的任务。
适合能被测试和 review 验收的任务。
它不适合所有问题。
模糊问题。
强判断问题。
需要专业经验的问题。
这些仍然适合人与 agent频繁交互。
Symphony 没有把工程师赶出开发过程。
它把工程师从低层监督里解放出来。
让人少盯小任务，多处理真正困难的问题。
09 问题从写代码变成拆任务
AI 编程的工作单元，正在从会话变成任务。
会话需要人在场。
任务不需要。
Symphony 用轮询、隔离、重试三个机制，让任务自己跑起来。
跑起来之后，工作单元可以变大，探索可以变便宜，发起工作的人可以变多，最后一公里可以被接管。
这不只是某个工具的进步。
更是 AI 编程从交互走向调度的一次结构变化。
对我们每个人来说，问题也在变。
从"怎么让 AI 写出更好的代码"。
变成"怎么把工作拆成 AI 能接住的任务"。
