我如何用 Agent Teams 管理 AI Demo 构建流程

为什么我开始搭建 Agent Teams

最开始用 AI Coding Agent 时，我把所有事情都交给一个 Agent：理解需求、写代码、改 bug、调样式。结果经常是，它在一个长任务的后半段开始跑偏，要么改了不该改的文件，要么把之前能跑的功能改坏了。

后来我发现，问题不在于 Agent 能力不够，而在于我没有给它足够的结构。单个 Agent 在长上下文中容易丢失边界，尤其是在任务涉及多个文件、多个步骤的时候。

所以我开始尝试搭建一套 Agent Teams 工作流，把项目启动、需求澄清、执行、验收、回滚和交接拆成多个角色与步骤。

我对 Agent Teams 的基本理解

对我来说，Agent Teams 更像一套任务分工和审查机制。方向判断先单独拎出来：做什么、不做什么、边界在哪里；具体改动再交给执行 Agent；最后由验收环节检查偏差，比如 build 是否通过、页面是否正常、有没有意外修改。

这三个角色可以由不同的模型承担，也可以由同一个模型在不同阶段承担。我现在更在意的是，把不同类型的思考分开处理。

我现在采用的角色分工

判断模型更像产品负责人，处理方向、边界和优先级。这个角色通常是我自己，偶尔会用 Claude 或 GPT 帮我梳理思路，但最终判断还是我来做。它要回答的问题很具体：这件事值不值得做，边界在哪里，什么必须有，什么可以先放下。

执行 Agent 只在指令明确之后动手改文件。Claude Code、Codex、Antigravity 都可以承担这个角色，但前提是边界写清楚：只改指定文件，只做指定任务，不顺手动其他东西。Gemini 3.5 Flash 曾经在优化主页内容时改坏 About、导航和 UI，这次之后我对“文件边界”这件事更敏感了。

验收环节还是我自己来做。build 是否通过、页面是否正常、有没有意外修改、是否符合预期，这些不能完全交给 Agent。Agent 可以帮我跑命令，但页面语气对不对、UI 是否失控、逻辑是否绕远了，最后还是要人判断。

当上下文过长时，我会写一份简短的交接文档，记录项目结构、当前状态、下一步要做什么、哪些文件不能动。Antigravity 额度中断后切到 Codex 接手，就是靠这种交接文档把任务继续下去的。

一个小型 AI Demo 的工作流

以我最近做的几个 AI Demo 为例，流程大致是这样的。先想清楚问题：这个 Demo 要解决什么？给谁用？输入输出各是什么？边界在哪里？比如”做一个需求澄清工具”，就要先拆清楚：输入是客户的一句话需求，输出是结构化 Brief + 澄清问题，边界是不处理复杂多轮对话。不需要写完整 PRD，但在给 Agent 写指令之前，这些得自己想清楚。

技术选型和项目结构确定之后，把哪些文件可以改、哪些不能改，提前写明白，再交给执行 Agent。每完成一轮执行，跑 npm run build，确认没有编译错误。本地验收通过后，部署到 Preview 环境，再检查一遍：页面能打开、功能能用、没有明显问题。

验收通过后 commit，记录当前状态。如果要交接给下一个 Agent，再补一份简短交接文档，说明项目结构、当前状态、下一步要做什么、哪些文件不能动。这样换一个 Agent 接手时，不需要从头猜上下文。

我踩过的坑

最常见的问题是上下文太长。有一次我把整个项目的历史、需求、技术栈全塞进一个 prompt，结果 Agent 输出的内容前言不搭后语。现在我会把上下文拆成多轮对话，每轮只聚焦一个具体问题。

还有一种问题是没审计就开始改。有一次 Agent 基于它”以为”的代码结构去修改，结果改错了文件。现在我会先让它读一遍相关文件，确认理解现状，再让它动手。

回滚点也很重要。有一次 Agent 执行完之后，我发现结果不满意，但之前没有 commit，git status 显示一堆改动，分不清哪些是 Agent 改的。现在每次重要修改后，我会先本地 build，通过后再 commit，给自己留一个干净的回滚点。

Mock 和真实 API 的差异也踩过。企业模糊需求澄清 Agent 接入真实 API 后，我发现底部 Mock 示例文案和真实输出格式不一致，需要同步修正。这个问题提醒我：Mock 可以帮助早期搭结构，但验收时要尽早看真实输出。

我现在采用的原则

每轮只做一个小目标，执行前先让 Agent 读一遍相关文件，每次执行完先 build 再 commit。重要节点要有回滚点，每完成一个可验收的功能就 commit 一次。出了问题先判断是 Agent 的执行问题，还是配置或环境问题，再决定怎么修，避免在一个已经混乱的状态上继续叠改动。

这套方法的局限

方向对不对还是需要人来判断，这一点目前没有办法绕开。有一次 Agent 实现了一个功能，build 通过了，功能也能用，但 UI 很丑——这类判断 Agent 做不了。即使用了「每轮只做一个小目标」，上下文有时还是会累积很长，需要主动清空，重新开始。交接文档和指令模板目前还比较随意，每次都要重新组织语言，这是后续需要继续沉淀的地方。

这套方法目前还是阶段性的实践记录。随着后续项目经验积累，我会继续调整角色边界、交接模板和验收方式。