大家一定要关注 Symphony，迈向 AI Agent 军团的里程碑

OpenAI 两个月前悄悄把一个叫 Symphony 的项目放上了 GitHub，上周才正式发文宣布。

官宣到现在七天，stars 从 0 涨到 19k，forks 1.6k。

但如果你只看数字，会错过它真正的意义。

OpenAI 在 README 里写了一句非常反常的话——

我们不打算把 Symphony 当作产品来维护。这是一个参考实现。请你们 fork 它、改它、自己重建。

这句话很容易被读成"这个项目没人管，别浪费时间"。

但读懂的人会立刻反应过来——

Symphony 不是产品。它是 spec。

而 AI Agent 走到今天,最缺的就是 spec。

单兵不是军团

回看 AI Agent 这两三年的演进,分得很清楚——

Agent 1.0:单兵。ChatGPT 一问一答,一条 prompt 一个 response。

Agent 2.0:班排。Claude Code 的 subagents、Cursor 的 agent mode。一个主 Agent 调几个子 Agent,结果汇总。

Agent 3.0:军团。一个人指挥 10 个、50 个、100 个 Agent,各自独立作战,并行推进多条战线。

班排和军团的差距不是数量。

是组织。

3 个人不需要军规,靠喊就行。30 个人靠口头协调还能勉强。300 个人没有军规——就是一群乱兵。

Agent 也一样。3 个 subagent,主 Agent 自己调度。30 个 Agent,还能靠人盯。300 个 Agent 没有 spec,是一团混乱。

Symphony 解决的,正是从班排到军团这一跳的核心问题。

Agent 三代演进

拆开 Symphony,里面装了什么

SPEC.md 是一份非常工程师的文档。没有营销话术、没有"赋能未来"、没有 vision。

通篇就讲五件事。

一、调度器是唯一真理之源

Symphony 把整个系统切成五个角色:

• Workflow Loader(读配置)
• Orchestrator(调度器)
• Workspace Manager(工作区管理)
• Agent Runner(Agent 启动器)
• Issue Tracker Client(问题源对接)

只有 Orchestrator 有权决定调度、重试、停止、释放。

这一条很关键。

班排级编排不需要它——主 Agent 自己拍板就行。但军团级里,每个 Agent 都会觉得自己最重要、自己的状态最对——必须有一个军令状机制。

Symphony 让 Orchestrator 当军令状。其它模块只能听调度。

二、不要数据库

整套设计里没有持久化数据库。

状态恢复怎么做?

无状态恢复——通过 tracker 和文件系统驱动重启恢复,而非持久数据库。

这一条看着平平无奇,背后是一个非常有洞见的判断——

Issue tracker 已经是真理之源。再加一个数据库,等于引入第二真理之源。

两个真理之源之间出现不一致是必然的。

Symphony 直接砍掉。所有状态从 Linear(或任意 tracker)重建。重启 = 重新 fetch + 重新计算。

这是 Unix 哲学的味道——不要存它能算出来的东西。

三、Workspace 是边界

Agent 命令仅在专属工作空间路径内执行。 工作空间路径必须在工作空间根目录内。 工作空间密钥仅包含 [A-Za-z0-9._-](其他替换为 _)。 

三句话,把 Agent 的安全模型钉死。

10 个 Agent 同时跑,没有这三句话,就是 10 个 root 进程在你的服务器上自由发挥。

更关键的是生命周期 hook——

hooks:after_create:"git clone ... && npm install"before_run:"npm update"after_run:"npm run cleanup"before_remove:"rm -rf node_modules"

进任务、出任务、报销、清场——全部可挂钩。

这是给企业 Ops 团队留的接口。没有这个接口,Agent 进不了生产环境。

四、并发是一等公民

agent:max_concurrent_agents:10max_concurrent_agents_by_state:"In Progress":5"Todo":3

全局并发上限 + 按状态分配槽位。

带状态的并发控制是军团级编排的硬需求。30 个 Agent 同时去抢"In Progress"槽位,没有按状态分配就是 thundering herd。

这种细节 v1 通常不会有,要 production 翻车几次才补。Symphony 直接在 v1 给齐。

五、提示词进 git

Workflow 配置和 Agent 提示词都写在 WORKFLOW.md 里。

YAML frontmatter 配参数,Markdown 写提示词。

文件进 git,pull request 改提示词,CI 跑回归。

这是把 prompt engineering 做成 ops-as-code 的标准动作。

班排级编排里你可能在终端里调 prompt 调一下午。军团级里——

提示词必须可版本化、可 review、可回滚。

否则 100 个 Agent 一起出 bug,你不知道是谁动了哪一句话。

Symphony 五模块架构

五件事合起来看

随便挑一件单看,都不算革命。

调度器、无状态、workspace 沙箱、并发控制、提示词版本化——每一件都是已经解决了 10 年的工程问题。

但这五件事第一次被打包写成一份 Agent 编排 spec。

之前每个团队都在重新造一遍——

• 没有调度器,让主 Agent 兜着 → 主 Agent 上下文爆炸
• 没有无状态设计,加个 Redis 当中间层 → 半年后 Redis 和 Linear 状态不一致
• 没有 workspace 沙箱 → Agent 跑啊跑,把 ~/.bashrc 改了
• 没有并发控制 → 10 个 Agent 抢同一条 Issue,撞 race condition
• 没有提示词版本化 → 改了一句 prompt,全军出现回归,无法定位

这五个坑每一个都需要一支团队踩半年才能填好。

Symphony 把这五个坑的填法写成规范。

而且——OpenAI 自己用 Codex 写出了 TypeScript / Python / Rust / Elixir 四种实现。

意思是:这份 spec 已经被验证可以用任意语言落地。

为什么大家会低估它

Symphony 看上去太"无聊"了——

• 没有炫酷 UI
• 没有 demo video(除了一段 Linear 看板演示)
• 没有 Agent 之间斗智斗勇的桥段
• 没有"我们用 AI 写了 AI"的奇观
• README 第一段就劝你别等 OpenAI 维护

这五件事每一件都让 Symphony 在话题度上跑不赢市面上随便一个 LangGraph 教程。

但 Linux 第一版也没有 demo video。

POSIX spec 也不会上头条。

真正的基础设施都是无聊的。

它无聊,是因为它把所有"刺激的"决策都关进了"一定要这么做"的笼子里。

这是 Agent 工程的 POSIX 时刻

POSIX 不是操作系统。POSIX 是一份 spec——所有 Unix-like 系统按这份 spec 开发,所以才能跨系统写可移植代码。

容器没走出"每家自己一套"的混沌期,直到 OCI(Open Container Initiative)那份 spec 出来。

Kubernetes 的爆发也不是因为它最早,是它把声明式 API + Pod spec 写成了规范。

每一次工程范式跃迁的关键节点都不是产品,而是 spec。

Agent 编排领域到目前为止——LangChain、LangGraph、AutoGen、CrewAI、Devin、Multica——每家各搞各的。

每个都在重新发明调度器、重新发明状态机、重新发明 workspace、重新发明并发模型。

迁移成本极高,几乎没有可移植性。

直到 Symphony。

它给出第一份别人能照着抄的 spec。

照着抄写出来的实现,相互之间结构相似、概念可类比、迁移成本可控。

这是从"百花齐放"到"军规统一"的拐点。

也是 Agent 工程从手工艺迈向工业化的里程碑。

建议立即着手做

不要等 Multica、不要等 LangGraph 4.0、不要等 OpenAI 出企业版——这条路 OpenAI 自己都说不走了。

值得做的三件事——

一、读 SPEC.md。两个小时能看完。看完之后,你团队里谁在做 Agent 编排,让他也读一遍。这是 Agent 工程师的新基准读物。

二、用 SPEC.md 当镜子照你现有的实现。有调度器吗?是无状态的吗?有 workspace 隔离吗?提示词进 git 了吗?每一项"没有",都是将来要还的债。

三、试着用任意语言落地一份。这是验证团队是否真的理解 Agent 编排的最好办法。能跑通一份 Symphony 实现,约等于通过 Agent 工程师的入门考试。

结尾

10 年后回头看 2026,Agent 这个领域真正会被记住的,不是哪个 GPT 版本、哪个 Claude 版本、哪段 demo 视频。

是哪一份 spec 第一次把军团级编排从"经验"写成了"规范"。