OpenAI 开源 Symphony，最值得看的不是它用了 Elixir，也不是它现在能不能立刻替你管完整团队。真正值得看的，是它把问题换了一个层级：不要再盯着 coding agent 干活，要开始管理“工作本身”。
这句话听起来有点抽象，但落到团队里很现实。Agent 越多，人工盯每个会话越不现实。未来更合理的方式，是任务进队列，系统隔离运行，Agent 产出 PR、测试状态、复杂度分析、walkthrough，最后人类审结果。
热度：约 15k stars，OpenAI 的 engineering preview。
先理解定位：它不是又一个 IDE 插件
Symphony README 里写得很克制：这是低调的 engineering preview，适合 trusted environments。它展示的是一种工作模式：监控 Linear board，发现任务后启动隔离的 autonomous implementation run，Agent 完成任务并提供 proof of work。
这个定位很重要。它不是让你在编辑器里多一个聊天框，而是让团队从“和 Agent 对话”转向“给任务系统下发工作”。
跑之前先补 Harness Engineering
Symphony README 明确说，它更适合已经采用 harness engineering 的代码库。简单说，你的项目至少要有这些基础设施：
- 一条稳定的测试命令。
- 清楚的 lint/typecheck/format 规则。
- 可自动生成和验证 PR 的流程。
- 任务描述能映射到可验收改动。
- Agent 有隔离运行环境，不会污染主分支。
没有这些，Symphony 这类系统会变成“自动制造混乱”。
两种使用方式
第一种是照 SPEC 自己实现：
Implement Symphony according to the following spec:
https://github.com/openai/symphony/blob/main/SPEC.md这很有意思：OpenAI 直接鼓励你让自己喜欢的 coding agent 按 spec 在任意语言里实现 Symphony。换句话说，Symphony 首先是一份工作流规格，其次才是参考实现。
第二种是跑官方实验性 Elixir 实现：
Set up Symphony for my repository based on
https://github.com/openai/symphony/blob/main/elixir/README.md如果你不是 Elixir 用户，别急着纠结语言。先读 SPEC，看它怎样定义任务、运行、证明材料、评审和落地。
第一个适合交给 Symphony 的任务
别把“重写支付系统”这种任务扔进去。适合的第一批任务应该低风险、可验证、可回滚：
为用户设置页增加一个缺失的空状态提示。要求：有单元测试；不改变现有 API；PR 描述里包含截图或 walkthrough。或者：
修复某个 lint 规则导致的 CI 失败。要求：只改相关文件；提交前跑 typecheck 和测试；输出失败原因和修复依据。重点不是任务多酷，而是系统能不能产出可审的 proof of work。
对团队的提醒
Symphony 代表的趋势是：Agent 会从“个人提效工具”变成“工作队列执行者”。那管理层面的新问题也会出来：谁定义任务，谁批准运行，谁能合并 PR，失败怎么回滚，Agent 产出的证明材料是否可信。
这类系统真正成熟以后，工程负责人要管理的不是“哪个 Agent 更聪明”，而是“哪些任务值得自动化执行，执行结果怎样验收”。Symphony 现在还早，但方向很清楚：软件团队的控制面，正在从编辑器挪到任务系统。