用 Claude Code 写过代码的应该都有这种感受：Agent 跑起来之后，根本不敢走开。
生怕它卡在某个地方原地打转，改了一堆不该改的文件，本来想用来提效，反而变成了全程陪跑。
说白了，现在大部分 AI Coding 工具的使用模式都是一样的：我们提问题，它给答案，我们审结果，发现不对再改。绕来绕去，还是离不开人盯着。
为了解决这个痛点，OpenAI 最近在 GitHub 上开源了一个新项目，狂揽 12000+ Star，在开发者圈里引发了不小的讨论。
这就是Symphony，一个让 AI agent 自己领任务、自己跑、自己交卷的编码自动化框架。
要理解它在做什么，先看一下 AI coding 工具这几年的演进路径。
最早是代码补全，Copilot 那个阶段，写下一行，AI 帮我们补完。后来是对话写代码，Claude Code 这类工具，我们描述需求，AI 来改文件。
Symphony 代表的是第三个阶段，项目级自主编排：issue 进去，验证过的 PR 出来，中间的过程 AI 自己搞定。
用项目自己的描述来说，这是从管理 coding agent 到管理工作本身的转变。
它的核心运行逻辑其实不复杂。
Symphony 会持续监听 Linear 看板，一旦某个 issue 被标记为「ready for agent」，就自动领取这个任务，为它创建一个独立的工作区，然后拉起一个 Codex agent 去实现。
整个过程完全不需要人工介入。
agent 完成工作后，不是直接提 PR 了事，而是要先提交一套交卷凭证：CI 通过状态、代码 review 反馈、改动复杂度分析、还有一段 walkthrough 视频。
这套机制在项目里有个专属名字，叫proof of work。审核通过，PR 才会被安全合并。
另一个设计细节值得单独说一下：WORKFLOW.md。
这是一个放在 repo 里的配置文件，定义了 Symphony 在这个项目上的所有行为规则，包括监听哪个看板、并发跑几个 agent、任务超时时间，以及传给 agent 的 prompt 模板。
不同项目、不同团队，agent 的行为规范各不相同，全靠这一个文件来控制。改完推上去，下一个 polling 周期立刻生效，不用重启服务。
也就是说，团队对 agent 的行为守则，和代码一起被版本化管理，随时可以审计、回滚。
这个设计思路，OpenAI 内部称之为harness engineering，专门为 AI agent 设计约束和反馈环路，让它能可靠地产出结果。有点像当年 DevOps 的出现，是一套新的工程规范正在成形的信号。
技术选型上，Symphony 用Elixir来写，这个选择一开始挺出人意料的。
但仔细想想确实合理：Elixir 底层的 Erlang/OTP，当初就是为大量独立任务并发容错设计的，每个任务跑在独立进程里，一个挂了不影响其他的，整个系统照常运转。这套模型几乎是为 agent orchestration 量身定制的，比 Python 系的框架稳得多。
当然，局限性也要说清楚。
目前 issue tracker 只支持 Linear，不过 GitHub Issues 和 Jira 的适配已经在路上了，这是阶段性限制。agent 运行时目前只对接 OpenAI Codex，想接入其他 agent 需要自己实现对应协议。
另外还有一个前置要求：代码库本身得先做好「harness engineering」，测试要能本地独立运行、文档要机器可读、架构要模块化。这些条件加在一起，决定了它目前更适合架构相对规范的团队去探索试用，还不到直接上生产的阶段。
上手方式有两种，都挺有意思。
一种是直接用官方提供的 Elixir 实现，照着 README 走就行。另一种更有趣，项目提供了完整的 SPEC.md 规范文档，可以直接把它扔给任意 coding agent，让它用我们熟悉的语言从头实现一套 Symphony 出来。
用 AI 来实现一个用来管理 AI 的系统，某种程度上也算是对这套理念最好的验证了。
回头想想开头那个场景：盯着 agent 跑，生怕它跑偏。Symphony 想解决的，正是这种不安全感。把规则写进 WORKFLOW.md，把验收标准交给 proof of work，让 agent 在一个有约束的环境里自主完成工作。
能不能真正做到放手不管，还要看实际落地的效果。但这个方向，值得持续关注。
GitHub 项目地址：https://github.com/openai/symphony
今天的分享到此结束，感谢大家抽空阅读，我们下期再见，Respect！
