用 Issue 驱动开发：当瓶颈从 Agent 转向人

一个被忽视的事实

OpenAI 两周前开源了 Symphony，大多数报道把焦点放在那个夸张的数字上：某些团队的 landed PR 数量在三周内增长了 500%。

但比数字更值得品味的，是触发这个项目的那段叙述。

OpenAI 的工程师们发现，他们手里的 Codex 已经足够能干——能干到一个工程师可以同时开 3 到 5 个会话让它并行干活。但他们也发现，超过这个数字之后，人会先崩溃。在不同 session 之间来回切换、看输出、做引导、再切回去,上下文切换成本会迅速吞掉所有效率收益。

换句话说：瓶颈不在 agent,在人。

这个观察并不新鲜——它其实就是软件工程里被讨论了几十年的"管理跨度"问题,只不过这次被管理的对象从工程师变成了 agent。但它指向的解决思路,对我们今天怎么构建 AI 协作流程,有非常具体的启示。

范式转变：从 session 管理到 work 管理

人脑能稳定监督的并发任务数,大概就在个位数。这是个生理上限,不会因为 agent 更强而提升。

那么思路只剩两种:

1. 让 agent 更不需要被监督(提升模型能力)
2. 让人不再去监督 session(改变协作架构)

Symphony 选了第二条。

它的核心动作只有一个:把 issue tracker 当作 agent 的控制平面。每一张 open 的 ticket 自动获得一个独立的 agent workspace,agent 持续运行,直到产出 PR、被人 review、合并。人不再"管 session",只"管 work"——什么是值得做的、什么做完了、什么需要再讨论。

这个动作看似简单,但带来的变化是结构性的:

• 人的角色变了:从 prompter / supervisor,变成 PR reviewer 和 issue 作者
• agent 的目标也变了:不再是"回答提问",而是"说服一个人 merge 你的代码"
• 协作的最小单位变了:不是一次对话,而是一张被推进到完成状态的 ticket

三个解耦：issue ≠ session ≠ PR

如果你仔细看 Symphony 的 spec,会发现一个有意思的设计:它刻意把 issue、session 和 PR 解耦了。

• 一个 issue 可以产生多个 PR(跨多个 repo 的改动)
• 一个 issue 也可以不产生任何 PR(纯调研、分析、踩坑报告也算完成)
• 一次失败的 session 不等于这个 issue 失败——orchestrator 会按指数退避重试,重新拉起一个 agent

这个解耦看起来是工程细节,但它实际上重新定义了"工作"。

在传统流程里,一个工程师写一个 PR,PR 是工作的容器。但当 agent 来执行时,ticket 才是工作的容器,PR 只是它的一种产物形式。你可以让 agent 去"调查一下为什么这个测试偶尔挂"——产出可能是一份分析文档,可能是几个候选 PR,也可能是"我搞不定,需要人介入"——这都是合法的完成状态。

这个观念的迁移很重要。它意味着 ticket 可以承载比一个 PR 大得多的工作单位,而 agent 的工作不再被"必须产出代码"这件事绑架。

那个被刻意忽略的前提

但请注意一件事:Symphony 的 README 里有一句话,几乎所有报道都没强调:

Symphony works best in codebases that have adopted harness engineering.

翻译过来就是:你的 CI 必须值得信任。

为什么?因为当人不再监工 session 时,"验收"就完全交给自动化测试和 review 流程了。如果你的 CI 能在有回归的代码上打绿勾,Symphony 只会愉快地把回归 merge 进来。如果你的 issue 描述模糊到 agent 必须反复澄清,那"自动化"也就无从谈起。

换句话说,Symphony 不是一个能直接套到任何团队上的工具,它是一个对工程基础设施有要求的协作模式。在能跑起来之前,你需要:

1. 可信的测试套件——CI 通过 ≈ 代码可以合并
2. 干净的 issue——ticket 描述足够清楚,agent 不需要回头问人
3. 明确的边界——哪些类型的工作适合扔给 agent,哪些必须人主导

这些事情本来就是工程团队应该投入的,只是在"人主导"的世界里你可以靠 review 来补救;在"agent 主导"的世界里,它们成了硬门槛。

这也解释了为什么 OpenAI 内部的 500% 增长不太可能在大多数团队复现——他们已经在 harness engineering 上投入了相当多的功夫,Symphony 只是把这些投入兑现成了协作效率。前置投资没做够的团队,装上 Symphony 之后只会更快地暴露问题,而不是更快地交付价值。

对小团队的启示:不需要 Symphony,但需要这个范式

Symphony 本身是一个参考实现(OpenAI 自己也说不打算长期维护),它要求接入 Codex App Server、跑 Elixir 服务、连 Linear——对小团队来说接入成本不低。

但它揭示的协作范式可以独立于具体工具被采用:

• 把 issue tracker 当成 agent 的 todo list——不一定要自动调度,但至少把"agent 可以接的活"明确标出来,贴个 agent-ready 标签也行
• 每个任务有独立 workspace——可以是 git worktree,可以是 sandbox 容器,重点是 agent 之间不互相污染状态
• PR 是验收物,不是工作单位——一张 ticket 完成的标志不是开了 PR,而是 ticket 被关掉
• 失败可重试,不需要 carry session 上下文——agent 应该能从 issue 本身重建上下文,而不是依赖一段对话历史

这些原则中的任何一条单独落地,对团队的协作效率都有可观的提升。你不需要立刻自动化所有事情,但需要开始用这种眼光重新看你的开发流程。

一个非常具体的起步动作:挑一个你团队下周的 ticket,试着把它写到"丢给一个不熟悉项目的实习生也能独立完成"的程度。你会立刻发现你们平时的 ticket 漏掉了多少隐含上下文。这些隐含上下文,就是 agent 协作的真正障碍。

一个更大的转变:spec-first

OpenAI 这次发布还有一个被低估的细节:他们把 SPEC.md 而不是代码当成了主要交付物。

OpenAI 工程师 Zach Brock 在 X 上的原话是 "software as a spec"——你可以把 SPEC.md 喂给任何 coding agent,让它用你喜欢的语言、风格、栈实现一遍。Elixir 的参考实现只是其中一个版本,OpenAI 内部还做了 TS、Go、Rust、Java、Python 五个并行 port 来压测这份 spec。

这暗示了一种新的开源协作方式:规范优先于实现。当任何一个团队都能用自己的 agent 把 spec 物化成代码时,"代码本身"就不再是稀缺品,清晰的规范才是。

这一点跟 issue 驱动开发其实是同一件事的两面:

• 对内部协作:清晰的 issue 让 agent 可以自主执行
• 对开源协作:清晰的 spec 让 agent 可以重新实现

两者背后的共同假设是:只要描述足够清楚,执行可以被自动化。

结语:issue 驱动开发,不是一个工具问题

我们花了二十年时间训练工程师们写好 issue。Jira、Linear、GitHub Issues 之所以重要,本质上不是因为它们好看,而是因为清晰的工作描述是协作的基础。

只不过过去这种清晰度的受益者是"另一个工程师"——他可能不读你的 issue,也可能边读边骂你写得太烂,但他至少有能力自己脑补缺失的上下文,或者走过来当面问你。

到了 agent 协作的时代,这种容错没有了。Agent 不会因为你是同事就给你面子,它就按你写的去做,然后开一个 PR 等你 review。

所以 issue 驱动开发的真正含义是:

把你想让别人(人或 agent)完成的工作,描述清楚到能被独立执行的程度。

工具是次要的。Symphony 也好,自己用 git worktree 加几个 shell 脚本拼一套也好,甚至完全不自动化、只是改变写 ticket 的习惯也好——核心问题是你的团队能不能把工作切成清晰的、能被独立完成的单位。

如果能,agent 会帮你把这个能力放大十倍。

如果不能,再强的 agent 也救不了你。