openai/symphony（28k★）：把项目工作变成隔离的自治实施运行——工程师管理工程而非监督代理。本篇读它的 SPEC.md（语言无关规格书）与它身后的 harness engineering 方法论。
一句话定位
从「监督代理」到「管理工作」的范式转换：Symphony 是一个长驻服务——盯议题看板→为每个议题开隔离工作区→派编码代理进去干→代理交付工作证明（CI 状态、PR review、复杂度分析、走查视频）→人验收落地。工程师的注意力从过程（盯 agent）上移到结果（验收工作）。
SPEC 哲学（最独特的一件）
整个系统写成一份 RFC 2119 风格的语言无关规格书（MUST/SHOULD/MAY），官方推荐两种用法：
- 自己造一个：把 SPEC.md 喂给你喜欢的编码代理，用你选的语言实现——「规格即产品」
- 用官方的 Elixir 参考实现
用代理时代的工具交付代理时代的产品——分发方式本身就是方法论的演示。
架构四支柱（从 SPEC 提炼）
- 议题驱动：固定节奏轮询 issue tracker（Linear 等），有界并发派工——工作从看板来，不从对话来
- 逐议题隔离工作区：agent 命令只在自己的工作区目录里跑——爆炸半径按问题隔离
- 策略在库（WORKFLOW.md）：agent 的提示与运行时设置随代码版本化——工作流是代码仓库的一部分
- 可观测与恢复：结构化日志、指数退避重试、tracker/文件系统驱动的重启恢复——长跑服务的运维是第一公民
外加一条关键边界：Symphony 是调度器与读取器，票据写入（状态迁移、评论、PR 链接）由代理经配置凭证执行；成功运行可以终于「Human Review」态而非必须 Done——人的验收位嵌在状态机里。
方法论精华
1. harness engineering（挽具工程）：Symphony 的前置概念——先给你的代码库装「挽具」（测试、CI、可验证验收），agent 才能拉得动；没有挽具的马是装饰。这是「可验证性决定上限」的工程组织版。
2. 工作证明（proof of work）：代理交付的不是「说做完了」而是 CI 状态+review 反馈+复杂度分析+走查视频——自治的代价是举证义务的升级。
3. WORKFLOW.md 随库版本化：agent 行为策略与代码同库同版本——代理配置漂移是事故源，版本化是解药（与法务 playbook 治理同一思想）。
4. 验收态在状态机里：成功≠Done，可以终于 Human Review——把人的位置设计进流程，而不是事后补。
编者按
Symphony 是「AI 工程组织学」的当下最高样本：它不问「agent 能干什么」，只问「什么工作形态可以被验收」。对照 launch-your-agent（单代理孵化）与 oncall-kit（单循环值守）——三个样本合成一条演化线：对话→单循环→看板驱动的常驻编排。