当每个人都有了 Agent，团队该怎样一起工作？
在当下，写代码、查问题、跑测试，越来越多工作可以直接交给 Qoder 推进，交付的速度和质量也在不断提升。每一个独立个体的效率都得到了提升，但是组织的效率却没有显著提升。
为了解决这些难题，Qoder 协作能力全面升级，正式发布项目 Projects 和讨论 Discussion 功能。项目功能用于组织需要多人协作的研发工作，讨论功能支持邀请同事和专业 Agent，共同讨论需求、评审技术方案或分析缺陷。
人人都是超级个体，组织如何协作
说一个在团队里比较常见的协作方式。大家围绕一项需求，在群聊或线下会议中形成一套完整方案。讨论结束后，每个人回到自己的工作环境，从整体方案中取出与自己有关的部分，整理成上下文和提示词，再交给自己的 Agent。
每次从讨论进入执行，人都要在群聊、会议、终端和 Agent 会话之间来回切换。刚才确认了什么，哪些内容需要交给 Agent，都要由参与者自己记住和整理。注意力也在一次次切换中被拆开。
讨论形成的方案随后进入不同的 Agent 会话。每个人整理给 Agent 的内容都带着自己的理解。有人更关注需求目标，有人首先看到实现风险。同一句结论经过不同的人转述，可能已经变成了几个略有差异的任务。人的理解偏差再叠加模型输出的不确定性，主任务的分支很快就可能偏离原来的方案。
Agent 完成以后，代码变更、测试结果或 PR 链接又留在不同的会话和终端里。团队想继续推进，往往要先把这些产物重新收集起来，再解释它们分别做了什么。
任务本身还会持续变化。推进过程中出现的新情况可能改变原有方案，交给 Agent 的信息也要随之更新。人就这样变成人肉 API，在多个 Agent 之间来回搬运信息。Agent 与组织的协同效率并没有提升。
协作方式变化：人不再做智能体的搬运工
Qoder负责人丁宇在云栖大会发布现场
今天，我们在 Qoder 中推出「项目」，用于组织内需要多人协作的研发工作，例如开发新功能、修复缺陷或进行技术改造。你可以将工作拆分为 Issue，设置优先级和状态，在看板中跟踪进度。需要评审方案或确认问题时，可以从 Issue 发起讨论，邀请同事和 Agent 一起参与。
- 团队可以在项目 Projects 中用 Issue 记录任务目标、负责人和当前状态。讨论从 Issue 开始，逐渐明确需求，确认后的信息连同任务交给 Agent。
- 「讨论」功能则支持邀请同事和专业 Agent 共同讨论需求、评审技术方案或分析缺陷。你可以在讨论中添加上下文、回复具体问题，也可以通过@ 请 Agent 分析材料或比较方案。例如，评审技术方案时，可以邀请后端同事介绍现有实现、测试同事补充异常场景，再请 Agent 比较不同方案。
- 讨论过程中，团队可以把已经确认的要求和决定标记为“关键信息”。Agent 得到更多内容的同时，也知道哪些信息仍然有效，可以作为接下来执行的依据。
- 讨论结束后，记录选定的方案、待解决的问题和后续负责人。代码变更、测试结果或 PR 链接随后回到任务，相关成员直接检查和验收。
角色依然有各自的专业分工，共同的信息却不需要掌握在某一个人手里。研发可以看到需求为什么这样定，产品也能及时了解实现中的限制。每个人依据同一份任务上下文继续判断，等待某个人居中转述的情况也会减少。
这意味着，我们不再需要反复解释“刚才讨论到哪里”“这个文件是什么”“另一个 Agent 做了什么”。协作不再围绕工具切换，而是围绕任务本身展开。
让不同任务拥有合适的执行方式
准确的任务上下文进入执行以后，还需要合适的 Agent 来完成工作。
用户可以根据需要自定义 Agent，为不同任务配置相应的能力和工作方式。那些反复使用的设置可以保留下来，用户不必每次重新交代。复杂的任务还可以交给 Agent Team。Leader 负责拆解任务，多个成员 Agent 分别处理其中的部分，也可以从不同方向探索和验证，随后再汇总结果，等待人类判断。
一个更强的团队，需要让每个人和各自的 Agent 始终围绕同一项工作继续协作。
这也是 Qoder 想向前推进的一步。让团队从各自使用 Agent，走向人与 Agent 共同推进一项工作。
项目、讨论、自定义智能体和智能体团队功能目前处于 beta 阶段，企业（Teams 和 Enterprise）订阅用户可以优先体验，并逐步对外开放。
