Symphony
把项目工作转化为隔离、自主的实现运行，让团队从监督编码代理升级为管理任务本身。
源代码（SPEC.md、elixir 实现）未在证据中提供，无法核实最小权限、用户确认、回滚等安全机制；仅工作流显示 actions 按版本锁定、权限声明收敛（contents: read），故相关项记 1 而非 0。许可证文件完整，来源归属（Apache-2.0 全文）可得满分。
核心实现与 SPEC 不在提供文件内，自一致性、依赖可用性、失败信息只能依据 README 断言与 smoke 测试脚本（预期退出码 1 并输出 preview 提示）记 1。
README 明确限定适用场景（已采用 harness engineering 的受信任环境）并给出 WARNING，边界声明尚可记 2；但触发精度与环境适配细节依赖未提供的 elixir/README.md，记 1。
仓库结构清晰、许可证完整（3）、发布工作流强制 tag 与 mix.exs 版本一致并生成 sha256（记 2）；无 CHANGELOG、FAQ，安装说明仅是指向未提供文件的链接（记 1）。
README 清楚陈述产品价值（从监督 agent 转向管理工作）记 2；但输出可用性、成本收益缺乏可审查的实现与证据，记 1。
README 关键主张（演示视频、CI 证明、安全合并 PR）无法在静态文件中追溯验证，记 1；对'工程预览'性质的诚实声明与事实推断区分良好，记 2。
- 核心规范与实现源码未随证据提供，安全机制（权限、确认、回滚）均无法静态核实，请勿据此直接部署。
- README 自述为'低知名度工程预览，仅限受信任环境测试'，代理会自主生成 PR 并合并，务必在隔离环境与受控仓库上验证。
- 测试 docker-compose 将 Codex 认证文件挂载进容器，复用该模式时注意凭据暴露面。
- 评估所依据的文件子集不完整，本结论置信度低，应以完整仓库复核后再决策。
这个 Agent 能做什么，适合哪些场景？
Symphony 是 OpenAI 在 GitHub 上开源（Apache-2.0 许可）的工程系统，核心理念是让团队管理待完成的工作，而不是逐个监督编码代理。它会监控任务来源（演示中是 Linear 看板），为每个任务生成独立的代理运行，代理完成任务后提交 PR 并提供工作证明：CI 状态、PR 审查反馈、复杂度分析和演示视频。任务被接受后，代理会安全地合入 PR。仓库提供两条采用路径：一份开放规格 SPEC.md，可以用任意编程语言自行实现；以及一个基于 Elixir 的实验性参考实现，附有环境搭建文档。仓库明确警告这是一个面向可信环境测试的低调工程预览版。
Symphony 监控 Linear 看板上的任务，为每个任务启动隔离的自主代理运行（演示中由 Codex 驱动）。代理完成实现后产出可审计的工作证明——CI 状态、PR 审查反馈、复杂度分析和走查视频——并在人类接受后安全落地 PR。仓库提供 SPEC.md 规格文档，说明如何按规格自行实现；elixir/README.md 则给出 Elixir 参考实现的安装与运行步骤，也支持把安装说明直接交给编码代理代为执行。
- 使用 Linear 管理需求的团队，希望看板任务被自动领取并由代理完成实现，而非人工排队处理
- 已实践'harness engineering'（脚手架工程）的工程团队，想把编码代理的使用从逐个监督推进到工作流级别的管理
- 愿意按 SPEC.md 用自选语言自建实现、以完全掌控运行边界的平台或基础设施团队
- 希望快速试用参考实现的 Elixir 团队，可用 elixir/README.md 中的步骤搭建环境
- 需要代理输出可审计工作证明（CI、审查反馈、复杂度分析）后再决定是否合入 PR 的严谨团队
这个 Agent 有哪些优点和局限？
- 规格开放：SPEC.md 允许团队用任意编程语言自行实现，不锁定特定运行时或实现栈
- 输出可审计：代理必须提供 CI 状态、PR 审查反馈、复杂度分析和走查视频等工作证明，而非仅交付代码
- 任务隔离与安全落地：每个任务是独立的自主运行，PR 只有在被人类接受后才合入，保留人工把关
- 提供可运行的 Elixir 参考实现，且支持让编码代理自动完成环境搭建，降低试用门槛
- 官方明确标注为'低调工程预览'，面向可信环境测试，不建议直接用于生产关键流程
- 在采用'harness engineering'的代码库中效果最佳，未做脚手架工程改造的仓库可能需要先补基础设施
- 核心演示依赖 Codex 与 Linear 等外部服务，采用前需评估这些供应商依赖和相应成本
- 源材料未提供基准数据、失败案例处理或安全边界的详细文档，代理行为的可靠性缺乏可查证据
如何安装或部署这个 Agent？
源材料未给出一条统一命令即可完成的安装流程，需二选一：
方案一（自行实现）：让任意编码代理按规格实现 Symphony：
> Implement Symphony according to the following spec:
> https://github.com/openai/symphony/blob/main/SPEC.md方案二（Elixir 参考实现）：克隆仓库后按 https://github.com/openai/symphony/blob/main/elixir/README.md 中的环境搭建与运行说明操作；也可以把该说明直接交给编码代理代为安装：
> Set up Symphony for my repository based on
> https://github.com/openai/symphony/blob/main/elixir/README.md缺失信息：Elixir 参考实现的具体版本要求、依赖命令和环境变量在源材料中未展开，需查阅 elixir/README.md。
如何使用这个 Agent？
搭建完成后，Symphony 会持续监控已配置的任务源（演示中为 Linear 看板）。工作流为：任务出现在看板 → Symphony 生成隔离的代理运行 → 代理实现并提交 PR，附 CI 状态、审查反馈、复杂度分析与走查视频作为工作证明 → 工程师在更高层面审查并接受或拒绝 → 接受后代理安全合入 PR。全程无需逐个监督编码代理。注意：这是工程预览版，仓库明确建议仅在可信环境中测试。
这个 Agent 与同类方案有什么区别？
README 将 Symphony 定位为 OpenAI 'harness engineering' 方法论的下一步——从'管理编码代理'（直接监督 Codex 等工具）推进到'管理待完成的工作'。它是这一转变的载体，源材料中未提及其他具名竞争产品。