以前：人盯着每一个窗口
开会话、贴需求、看卡没卡，再切到下一个。
人负责催进度注意力成瓶颈AI 会写代码了，
谁来给它派活儿？
Symphony 就像施工队的调度员：看工单、分工位、盯进度，把成果交给人验收。
它不是一个更聪明的模型，而是组织编程智能体工作的开源规范与参考实现。
现在：人管理要完成的事
把目标写到看板，调度层安排智能体持续执行。
按工单分配按容量并行三个核心零件
📋
工单：要做什么
Linear 看板承载目标、状态与依赖。调度器持续读取，挑出当前符合条件的任务。
不是所有打开的任务都会立刻启动，还要看阻塞、状态和并发限制。
🧰
工位：在哪里做
每个任务有自己的工作区，Codex 在里面读代码、修改、运行检查，避免不同任务挤在同一个目录。
独立目录不等于强安全沙箱；权限仍要配置。
📜
工作手册：怎样算做好
WORKFLOW.md 保存配置和提示词：如何执行、验证、交接，团队随代码一起版本管理。
SPEC.md 是“怎么造调度员”；WORKFLOW.md 是“这个团队怎么干活”。
点几下，看调度员怎么排活儿
假设只开两个工位。任务 B 必须等 A 完成，任务 C 与它们无关。
简化教学模型：失败重试、依赖和人工验收在这里按固定步骤演示；真实行为由规范、实现和团队工作流决定。不会启动真实智能体。
成果不是一句“我完成了”
① 明确目标
写需求与验收条件
写需求与验收条件
② 智能体执行
编码、调查、运行测试
编码、调查、运行测试
③ 提交证据
PR、CI 结果、演示等
PR、CI 结果、演示等
④ 人做判断
接受、打回或继续探索
接受、打回或继续探索
Symphony 核心负责调度，不包办所有事情。改工单状态、贴 PR 链接、处理评审等，通常由智能体借助工具和工作流完成。一次成功运行，也可能只到“待人工评审”，并不等于代码已合并。
这篇文章真正想说的三件事
🧠
瓶颈从代码变成注意力
AI 能并行干活，人却不擅长不断切换上下文。把会话管理交出去，工程师才能盯住少数真正难的问题。
模糊、需要强判断的任务，仍可能更适合人与 Codex 直接交互。
🔌
用正式接口，不盯终端
Codex App Server 让程序通过结构化接口管理线程与执行过程。参考实现用 Elixir 组织并发任务。
规范不绑定语言，可以据此构建适合自己环境的版本。
🧱
先修好施工现场
清楚的文档、自动测试、工具与验收标准，决定了智能体能否靠谱执行。调度器不能替你补齐全部工程基础。
文章展示的 CI 跟进与演示视频等能力，依赖相应工具和工作流。
两个边界，别被标题带跑
📈 “PR 变多”不等于“人人生产力翻倍”
OpenAI 报告：部分内部团队在最初三周，合入主分支的 PR 数量达到原来的六倍。这是特定团队的观察，不是普遍效果保证，也不等于质量、业务价值同步增长。
🚧 这是参考实现，不是托管成品
官方将其定位为面向可信环境测试的工程预览，并表示不计划把 Symphony 作为独立产品持续维护。部署前仍要处理认证、权限、资源预算、沙箱和评审策略。
记住这一张小纸条
Codex 是干活的人；Symphony 是调度员；Linear 是工单墙；测试和评审是验收关。
真正的升级：不是让一个 AI 多聊几句，而是让一批任务可以有秩序地持续推进。