夜雨聆风全文约 6600 字，预计阅读 12 分钟。团队协作型 AI Coding 产品，表面上都在做 agent 协作，真正开始分化的地方，不在代码生成本身，而在任务、状态、交接和责任到底归谁管。本文从仓库流程、任务调度层和独立平台这几种正在浮现的做法切入，讲清楚这类产品为什么越做越不像同一种东西。
团队协作型 AI Coding 产品，现在真正难的是什么？
我越来越觉得，团队上 agent 最先踩的坑，往往不是模型能力不够。
模型差一点，无非多改几轮。
真正麻烦的是协作一乱，所有人都开始找日志、找上下文、找接手人。
任务在 Linear，执行在本地 worktree，日志在终端，结果在 PR，规则在仓库文档，交接说明在聊天记录。看上去每一段都在运转，真出了问题，所有人还是会问同一句话：
这是谁改的？这才是 agent 进团队以后最麻烦的现场。
单人用 agent，核心问题很简单，它能不能把活干出来。
团队用 agent，问题马上变了：
任务从哪里来？谁把它交给 agent？agent 在哪里跑？它改了哪些文件？失败以后谁接？PR 谁 review？这次经验怎么留给下次？所以我现在看团队协作型 AI Coding 产品，已经不太关心它还能不能再多起几个 agent。
我更关心另一件事：
它到底把团队的工作状态，放在了哪里？看了一圈 AICodingFlow、Symphony、Multica 这一类项目，我越来越觉得，它们看上去都在做协作，真正争的却是同一个位置：团队工作状态到底落在哪一层。
沿着这个标准看，眼下这类产品已经开始分化出几种很不一样的做法。
一、从仓库流程里长出来的协作流
第一种做法最朴素。
团队本来就在 GitHub 或 GitLab 里开 issue、建分支、提 PR、做 review、跑 CI，那就别再额外搭一个大前台了。直接把 agent 接进原来的研发流程，让它沿着现有轨道干活。
AICodingFlow 就很典型。
它不是在卖一套全新的协作平台，而是在把原来的仓库工作流重新接上 agent。
它在 README 里写得很清楚，本地开发流是这条：
issue -> branch/worktree -> commit -> push -> pr -> review -> mergeGitHub 协作流是这条：
issue -> triage/spec -> implement -> pr -> review -> comments -> merge你一看就懂，它没想改掉团队原来的工作台。
它做的事更像是把老流程重新串一遍。以前这些动作主要靠人手动接起来，现在 triage、spec、实现、review comment 响应，可以逐步交给 workflow 和 agent。
这条路的好处很直接，迁移成本低。
团队不用换任务系统，不用搬协作入口，也不用重新教育所有人怎么工作。issue 还是 issue，PR 还是 PR，review 还是 review，CI 还是 CI。原来的工程节奏不需要推翻，只需要把 agent 接上去。
这对什么团队最有吸引力？
就是那种 GitHub 已经用得很深的团队。
有 issue 模板，有 PR 规范，有 Actions，有 CODEOWNERS，有稳定 review 习惯。这类团队缺的往往不是新平台，而是一套让 agent 顺着现有工程轨道往前跑的方法。
所以这种方案最打动人的地方，不是未来感，而是省事。
但它的边界也很清楚。
仓库很适合放结果。
PR、CI、review comment、commit diff，这些都很适合待在 GitHub 里。
可仓库不天然适合当总控台。
跨仓库任务、跨项目优先级、agent 当前状态、运行时日志、失败恢复、任务接力，这些东西如果全靠 GitHub 页面去承载，很快就会有点挤。
GitHub 很擅长存证据。
它不一定擅长指挥现场。
所以这一类产品主要是在回答一个问题：
怎么让 agent 沿着现有仓库流程干活？这个问题它回答得不错。
但另一个问题，它没有彻底解决：
一个团队同时放出去很多 agent 之后，谁来统筹这一堆现场？二、任务系统后面的调度层
第二种做法，比前一类又往前走了一步。
它盯上的已经不只是仓库，而是任务系统本身。
因为很多团队真正的工作入口，压根不在 GitHub issue 里。
它在 Linear、飞书项目、Jira、Notion，或者别的任务系统里。
产品、运营、测试、工程，大家看的都是同一块任务板。你让他们为了用 agent，再去 GitHub 里重写一遍任务，这件事通常走不远。
这类产品大致是这个思路：
任务继续待在原来的任务系统里。后面加一个中心服务。由它负责读取任务、创建隔离工作区、拉起 agent、追踪运行状态，让结果最终回到工程流程。Symphony 就是这个方向里很典型的项目。
Symphony 的 spec 说得非常直白：它是一个长期运行的自动化服务，会持续从 issue tracker 里读取工作，为每个 issue 创建隔离 workspace，再在里面跑 coding agent session。当前 spec 版本里，对接的是 Linear。
这几个点放在一起看，它的角色就很清楚了：
它不是一次性脚本，而是长期运行的服务。 它不是让多个任务挤在一个目录里乱跑，而是按 issue 隔离 workspace。 它把团队规则放回仓库里的 WORKFLOW.md。它强调日志、状态和并发运行时的可观测性。
这就意味着，Symphony 关心的重点，已经不是“怎么让 AI 写一段代码”。
它更像在处理另一件很土、但也很团队化的事：
怎么让一批任务稳定地交给 agent 执行，而且别互相撞车。这条路为什么会冒出来？
因为现实里，任务系统会记账，但不会干活。
仓库会收结果，但不会调度现场。
中间天然缺一层东西。
这层东西不负责替你写需求，也不负责替你 review 代码。它负责的是把任务从“板子上的一张卡片”，变成“一个真的在跑的执行单元”。
我更愿意把它理解成任务系统后面的一层调度层。
产品经理继续在任务系统里写需求。
负责人继续看任务状态。
agent 在隔离 workspace 里干活。
代码结果回到 PR 或 diff。
而中间那堆以前最容易乱掉的东西，比如调度、重试、停止条件、日志、并发、恢复，全交给中心服务兜着。
这种做法比 GitHub 那一派更贴近真实团队分工。
但它的代价也很直接。
中心服务一旦起来，它自己就会变成一套要维护的工程。
数据库、轮询、Webhook、权限、环境准备、CLI 版本、失败恢复、观测面板，这些都不是一句“接个 agent”就能带过去的。
如果团队只是想偶尔让 agent 改两个小 issue，这套东西会显得过重。
可一旦团队真的准备把 agent 放进日常派单流里，这层调度又几乎是躲不开的。
因为任务多起来以后，你最怕的不是 agent 不会写。
你最怕的是：
它到底有没有在跑？跑到哪了？卡在什么地方？现在该谁接？说到底，它在回答另一个问题：
怎么让任务系统里的工作，稳定地变成 agent 的执行现场？三、把 agent 当成团队成员的平台
第三种做法最彻底。
前两类都还有点借现成系统办公的意思。
GitHub / GitLab 派，是借仓库体系。
任务调度派，是借现有任务系统。
这一类不一样。它更像在说：
既然 agent 要长期进团队，那就别再东拼西凑了。直接给它们做一套工作台。Multica 就很像这个方向上的代表。
Multica 的 README 里有一句话，基本把路数说透了：
它要把 coding agents 变成 real teammates。
这已经不只是“给某个 CLI 套一层壳”了。
更像是让 agent 在团队协作系统里真有一个位置。
在这种平台里，agent 不是一段临时跑起来的命令。
它更像团队里的一个正式对象。
它有身份，有 runtime，有任务，有进度，有 blocker，有评论，有技能积累，甚至还能组成 squad。
以前项目管理工具里的 assignee，默认是人。
在这类平台里，assignee 可以直接是 agent。
以前 comment 大多是人写的。
现在 agent 也会出现在任务流里汇报“我做到哪了”“我卡住了”“我准备下一步干什么”。
以前 runtime 是个后台概念。
到了这里，runtime 本身也变成平台要直接管理的对象。
Multica 这种做法比较完整，也最容易让人把它想成“AI 团队该有的样子”。
它把很多原来散落在各处的对象都摆到了台面上：
任务分给谁 agent 跑在哪个 runtime 上 它用哪个 CLI 当前状态是什么 日志在哪里 blocker 是什么 哪些经验可以沉淀成 reusable skill
这类平台一旦做顺了，它就不只是一个 AI Coding 工具。
它更像 AI 时代的新协作底座。
但它也最容易撞到团队现有习惯。
因为一个团队原本已经有 GitHub、Linear、Slack、CI、权限系统、内部规范。现在再来一个完整平台，所有人第一反应都会是：
那到底谁才是主系统？如果任务还在 Linear，独立平台就得把接入做得非常深。
如果任务搬进独立平台，它就得承接一部分原来项目管理工具的工作。
这两条都不轻。
它的优势和麻烦，其实是绑在一起的。
东西做得越全，迁移成本通常也越高。看起来越像未来，越考验团队愿不愿意真的搬过去。
换句话说，这一类产品在回答的是：
如果 agent 不是工具，而是团队资源，那我们要不要专门给它们建一套组织结构？它们真正争的，不是代码生成，是团队工作状态到底落在哪一层
把这三类产品放在一起看，会发现一个很有意思的地方。
它们都在做 AI Coding 协作。
但真要往深了看，争的是同一件事：
团队的工作状态，最后到底归谁管？GitHub / GitLab 派的答案是：
归仓库流程管。issue、PR、CI、review comment 就是中心。任务调度派的答案是：
任务留在任务系统里，执行状态交给中心服务管。独立平台派的答案是：
干脆重建一个新中心，把人、agent、任务、runtime、skill 都收进去。这不是简单的产品形态不同。
更像三种治理选择。
谁来定义任务入口。
谁来存状态。
谁来安排交接。
谁来决定团队以后和 agent 一起工作的主场。
所以我现在看这类产品，已经不太爱问“谁的模型更强”“谁一次能并发多少个 agent”了。
这些当然重要。
但那是上半场的问题。
下半场更现实的问题是：
谁能少制造混乱？谁能让团队少找日志？谁能让一个任务从派发到交付，都有人看得见、接得住、说得清？判断这类产品，别先看 demo，先问五个土问题
真要判断一个团队协作型 AI Coding 产品值不值得看，我建议先别急着看演示视频。
先问五个很土的问题。
第一，任务从哪里来？
它是读 GitHub issue，读 Linear，读飞书项目，还是自己提供一套任务系统？这件事决定了团队要不要迁移主入口。
第二，agent 在哪里跑？
本地 worktree、隔离 workspace、云端 VM、daemon 挂载的机器，它们背后对应的是完全不同的权限、成本和事故范围。
第三，过程谁看得见？
只看到最后一个 PR 远远不够。团队至少得知道它跑了哪些命令、卡在哪里、什么时候该停、失败以后怎么接手。
第四，结果怎么回到正式工程流程？
它最后交回来的是 diff、PR、comment、walkthrough，还是只在平台里写个“完成”？如果结果回不到 review 和 CI，团队就很难真的把它纳入日常开发。
第五，经验怎么留给下次？
如果每次任务的规则、踩坑、命令、上下文都散在聊天记录里，那 agent 用久了也只是高级临时工。能不能把经验写回规则、workflow、skill 和团队共享记忆，这决定了它是不是越用越顺。
这五个问题，比“它支持多少个 agent”更重要。
支持十个 agent 不稀奇。
十个 agent 同时跑，团队还知道谁在干什么，这才稀奇。
我的判断
团队协作型 AI Coding 产品，接下来不会只往“更强的代码生成”走。
代码生成当然还会进步。
但最后拉开差距的，大概不在谁更会补全代码，而在谁更会管理这几件看起来很土的事：
任务归属。运行隔离。过程可见。结果可审。经验可复用。AICodingFlow 这一类，更像把 agent 接进现有仓库流程。
Symphony 这一类，是在任务系统和执行现场之间加一层调度。
Multica 这一类，则是试着把 agent 直接放进一套新的协作平台里。
它们都叫“团队协作型 AI Coding 产品”。
但最后都绕不开同一个问题：
团队到底愿意在哪里，和 AI 一起上班？以前 AI Coding 工具争的是“谁更会写代码”。
现在团队协作层争的，更像是谁能少制造混乱。
这个变化不花哨。
但它比“再多起三个 agent”更接近真实工作。
因为对团队来说，更让人头疼的，往往不是 agent 写不出代码。
而是它写完以后，没人知道怎么接。
资料来源
Terry-Mao/AICodingFlow openai/symphony Symphony Service Specification OpenAI：An open-source spec for Codex orchestration: Symphony multica-ai/multica
