Agent 已经能写代码、跑测试、出方案。但真正推进一项工作，往往还需要团队成员共同讨论、判断和确认。个人与 Agent 的协作越来越顺畅，团队的协作方式却未必跟得上。

人在一个群里讨论，Agent 分散在不同环境里

今天的团队协作通常是这样的：大家先在 IM 群里沟通，或者在会议室里讨论方案；达成一致后，再各自回到桌面端、终端或云端工具，把讨论结论交给自己手边的 Agent 去执行。

于是出现一个别扭的错位——人在同一个群里讨论，Agent 却分散在不同的执行环境里。 任务负责人要把意见整理一遍，再重新告诉 Agent：哪些已经确认、哪些需要修改、哪些还不能动。执行中冒出新问题，又得把结果带回团队，重新讨论、重新转述。注意力被反复切换打断，上下文被拆散在会议纪要、聊天记录和各人与 Agent 的对话里；Agent 生成的方案、代码和测试报告，也需要人一份份收集起来，带回团队检查和确认。

注意力分散、上下文分散、产物碎片化。 Agent 承担了执行，人却仍然是连接团队讨论与 Agent 执行的那个"搬运工"。而这个问题的根子，不在"负责人记得够不够全、转述得够不够细"。只要讨论和执行身处两个地方，搬运就无法避免。

让讨论直接发生在工作的地方

在 Qoder 的日常研发里，我们也在摸索同一件事：当越来越多工作交给 Agent，团队讨论和 Agent 执行该怎么衔接？

我们的尝试很直接：让讨论直接发生在工作的地方。 推进任务的人可以在任务上拉上相关同事，一起补充背景、确认约束、处理分歧；讨论中形成的决定留在任务上，成为后续执行的依据，而不是等散会之后，再由一个人把信息重新组织一遍。

从人在群聊和工具之间转述，到讨论、执行与确认围绕同一个任务展开。这让我们逐渐明确：团队需要的不是更勤快的负责人，而是一个共同的工作空间——让讨论与任务保持关联，让已经确认的信息能够直接接续到执行。

项目与讨论，就是把这套协作实践产品化的结果。

具体来说，这套协作方式把一项工作收拢为连续的过程：任务有共同的落点，讨论沉淀为执行依据，执行结果再回到任务。

团队共同的工作，有了一处落点

项目是人与 Agent 围绕代码工程协作的团队空间。人和 Agent 都以项目成员的身份参与工作，要做的事由 Issue（任务）承载，记录任务描述、指派、状态以及关联的讨论。谁在推进、进展如何、还有哪些问题待确认，都能围绕同一个任务看到。

讨论留在任务上，共识成为执行依据

讨论可以从 Issue 发起，也可以围绕自由话题展开。成员邀请相关同事进来，补充信息、讨论方案、确认取舍；讨论结论可以回写到关联的 Issue。

讨论过程中，成员可以把关键对话标记为关键信息——已经确认的要求、约束和决定就此沉淀下来，作为接下来的执行依据，而不是淹没在聊天记录里。

从委派到验收，执行都围绕任务展开

• 派出去的不只是一个执行者

委派出去的 Agent 本身也需要更得力。你可以按需自定义 Agent，为不同任务配置相应的能力和工作方式；复杂的任务还可以交给自己的Agent Teams：Leader 负责拆解任务，多个成员 Agent 分别处理其中的一部分，也可以从不同方向探索和验证，随后再汇总结果，等待人类判断。

• 结果回到任务，调整沿着同一条线

团队达成一致后，成员可以直接在讨论中委派 Agent 执行。任务、讨论与执行产物始终保持关联，后续验收和调整无需另起一条沟通线。

如何把这套协作方式用进日常开发

一系列需要多人协作的工作，可以从创建一个项目开始。团队围绕共同目标创建项目，邀请持续参与的成员加入，在其中共享代码库、需求文档和 Issue 列表等公共信息。

提出需求。 项目成员将日常需求或工作创建为 Issue，简要写清目标和初步方案；未来也将支持从其他需求系统导入。

拉起协作。 当一个 Issue 需要多人参与时，负责该项工作的成员——例如 Feature Owner 或产品经理——从 Issue 发起讨论，邀请产品、设计、研发和测试等相关同事加入。

形成共识。 参与者在讨论中对齐方案，确认需求范围、实现方案和验收标准，并将关键结论标记为「关键信息」。这时，任务所需的上下文不再散落在 IM 群、文档和会议纪要里。

推进执行。 达成一致后，开发在讨论中 @ 自己的 Agent 或 Agent Team。Agent 基于 Issue、讨论内容和「关键信息」理解任务并执行。

验收与调整。 代码变更、测试结果或 PR 链接返回同一讨论，由参与者检查和验收。确认后的产物与「关键信息」会写回 Issue，方便后续追溯和复用；如需调整，也在这里确认新的要求，再让 Agent 继续推进。

人可以把注意力放在判断和确认上，而不是在同事与 Agent 之间反复搬运信息。