vs-code-agents

场景：当你用 AI 写代码，却发现它越改越乱

用过 GitHub Copilot 的开发者，大多有过这样的经历：给它一个模糊的需求，它哗哗写了几百行；你提了几个修改意见，它又哗哗改了一堆；反复几次之后，代码质量稀烂，bug 成堆，你甚至忘了最初的需求是什么——这个 AI 成了一个"超级打字机"，却不是一个靠谱的开发搭档。 问题的根源在于：单个 AI 模型试图同时扮演多个角色——需求分析师、架构师、编码员、测试员、运维工程师——每切换一次上下文，它就丢失一截记忆，每次"一心多用"，质量就下滑一次。 Flowbaby Agent Team（项目原名 vs-code-agents）想解决的就是这个问题：不是让一个 AI 变强，而是让一群各有专长的 AI 互相配合，各司其职，互相监督。就像一家软件公司里，产品经理做规划、架构师定方案、安全工程师审计、程序员写代码、测试工程师验证——每个人只专注自己那一块，handoff（交接）时有文档可查，质量门禁（Quality Gate）卡住有问题的交付物。 这个项目由 groupzer0 团队开发，是他们 Flowbaby（一个 VS Code 持久记忆扩展）的参考实现——也就是说，这套多智能体协作模式，本身就是他们做 Flowbaby 时摸索出来的最佳实践。 想象你是一家建筑公司的老板。你接到一个盖房子的项目，流程是这样的：先由总规划师（Roadmap）确定要盖什么样的楼、预算多少；再由规划师（Planner）拆解成施工步骤——但规划师只管"要做什么"和"为什么这么做"，绝对不能写代码；随后分析师（Analyst）去研究地质条件和周边环境，架构师（Architect）设计结构方案，批评者（Critic）专门挑刺找漏洞，安全工程师（Security）审计合规风险；等所有评审都通过了，实施工程师（Implementer）才开始编程；写完后代码审查员（Code Reviewer）复查质量，QA 工程师写测试用例，UAT（用户验收测试）确认业务价值，DevOps 负责打包发布——每一步都要前一步的产出作为输入。 这套流程叫"文档驱动工作流"（Document-First Workflow）。每个 agent 的产出都是一份 Markdown 文档，存在 agent-output/ 目录下：planning/ 放需求文档，architecture/ 放设计决策记录（ADR），critiques/ 放评审意见，security/ 放安全报告……下一位 agent 要接手时，先读前一位留下的文档。这样即使隔了几天再回来，也能通过文档追溯当时的想法。 11 个专业 Agent 协同分工：Roadmap（战略规划）、Planner（需求分解）、Analyst（技术调研）、Architect（架构设计）、Critic（方案批评）、Security（安全审计）、Implementer（代码实现）、Code Reviewer（代码质量审查）、QA（测试策略）、UAT（业务价值验收）、DevOps（发布运维）、Retrospective（复盘改进）和 ProcessImprovement（流程优化）。每个 agent 只被允许使用自己角色范围内的工具。 例如，Planner agent 只能做计划，不能写代码；Security agent 只能审计发现问题，不能自己修复；Implementer 必须严格按计划执行，不能自己改需求。这种"权限约束"设计，从根本上避免了角色越位和质量滑坡。 一个典型的端到端工作流大约是：Roadmap → Planner → （Analyst + Architect + Critic + Security 并行评审） → Implementer → Code Reviewer → QA → UAT → DevOps → Retrospective → ProcessImprovement。评审阶段并行执行可以大幅缩短周期，而关键节点（Critic、Security、Code Reviewer）的否决权则保证了质量不会在流水线中逐级衰减。 Flowbaby Agent Team 与 VS Code 原生的 Copilot Chat 深度集成。安装 Flowbaby 扩展后，在 VS Code 侧边栏的 Chat 面板里，从下拉菜单选择对应的 agent，然后输入需求。agent 会通过 Flowbaby 的记忆系统（flowbabyRetrieveMemory、flowbabyStoreSummary）读取跨会话的上下文，在工作区目录下生成 agent-output/ 目录，将每一步产出作为文档保存。 如果没有安装 Flowbaby 扩展，agents 仍然可以工作，但失去了跨会话记忆——每次新建会话，agent 就忘了上次讨论了什么。对于短期任务影响不大，但涉及多日迭代的项目，有记忆和无记忆的体验差距明显。 上手几乎零门槛。不需要懂 Docker，不需要配置环境变量，只要把 vs-code-agents/ 目录下的 .agent.md 文件复制到项目根目录的 .github/agents/ 或 VS Code 用户配置目录下，重启 VS Code，就能在 Chat 面板里看到所有 agent 可供选择。但需要注意：项目依赖 GitHub Copilot 订阅（Copilot Free 或 Copilot Pro），纯免费用户无法使用。 这套模式目前仍处于快速迭代期。VS Code 本身在 2025-2026 年大幅强化了 multi-agent 能力（背景 agent、云端 agent、跨会话管理），Flowbaby Agent Team 也在同步演进。核心风险在于：agent 之间的 handoff 依赖文档质量，如果某个 agent 输出了模糊或错误的文档，后续所有 agent 都会被误导。此外，当 agent 数量多、评审流程长时，单个需求的完成时间可能比纯手工开发更长——这是一套"以时间换质量"的方案，更适合对质量要求高的正式项目，而非追求快速原型验证的场景。 Flowbaby Agent Team 代表了 AI 辅助开发的一个重要方向：不是让一个"万能 AI"包打天下，而是用多智能体分工+质量门禁+文档驱动，构建可追溯、有保障的 AI 开发流水线。随着 VS Code 和 GitHub Copilot 对 multi-agent 工作流的支持越来越成熟，这类框架有望成为中大型 AI 开发项目的标准工程实践。

图1：Flowbaby Agent Team 多智能体协作体系 多智能体分工对比单一大模型的本质优势在于"专业分工+质量门禁"：Critic agent 专门负责在 Planner 输出计划后挑刺，安全 agent 负责审计代码漏洞，而不是让一个通用模型"顺便"处理这些工作。这种机制让 AI 开发流水线具备了类似传统软件工程的质量保障体系，却不需要额外的人力投入。 从 GitHub Stars 增长曲线看，该项目在 2025-2026 年 VS Code 大规模引入 multi-agent 功能后获得显著关注。代表了一个趋势：随着 AI 编码工具普及，团队开始关注如何将 AI 的"速度优势"与工程化的"质量保障"结合——这正是 Flowbaby Agent Team 试图填补的空白。