企业官网建设流程全解析

我花了两周时间，把一个需要四个人并行开发的内部项目，硬生生塞给了一组 AI Agent。说出来你可能不信，最后跑通的产出质量，比我团队里两位中级开发交出来的第一版都要干净。

这个想法不是拍脑袋冒出来的。当时我手里压着两个并行需求，团队能写代码的人已经连续加班到晚上十点。我把主流的 AI 编码辅助工具挨个试了一圈，发现它们最大的问题不是写不出代码，而是永远在单打独斗：你给一个模糊需求，它就猜一个实现方式；你让它改接口，它不会主动去同步调用方；更没有人做需求澄清和代码审查。这让我意识到，把开发工作交给 AI，关键不在于单个 Agent 有多聪明，而在于能不能把一套开发流程拆成多个角色，让它们像真实团队一样协作。于是就有了这套 Agency Agents 多智能体协作系统的原型。

这套东西的定位很明确：不是给个人用的补全工具，而是一个能承接完整需求、独立跑完"需求分析—技术设计—编码—测试—审查"全流程的轻量级"虚拟开发团队"。如果你也在纠结怎么把手头的编码工作流改造成多智能体协作模式，或者被 Agent 之间互相抢活、上下文混乱的问题折腾得头大，这篇文章值得你花十五分钟看完。

1. 为什么好好的团队，会想着交给一堆 Agent

1.1 从"帮你写代码"到"替你拆任务"

大部分人对 AI 编程的认知还停留在"对话式补全"：打开编辑器，写一段注释，让 AI 填出函数体。这种模式有两个天花板。

第一是上下文窗口不够用。单个 Agent 的注意力是有限的，你让它负责整个项目，它会在前 2000 行代码里表现优秀，到了第 5000 行就开始自相矛盾，忘了前面的模块接口长什么样。第二是责任边界模糊。真实团队里，写接口的人和改调用方的人可能是两个角色，但在单 Agent 模式下，它既当产品经理又当测试，角色冲突导致它经常在"实现需求"和"怀疑需求"之间内耗。

多智能体协作解决的就是这两件事。通过把项目拆成若干独立角色，每个 Agent 只维护自己负责的上下文片段，控制上下文长度；同时把"分析需求"和"写代码"分成两个 Agent，让需求变更不至于直接冲击编码过程。用一句大白话讲：单 Agent 是一个人干所有活儿，多智能体是一群人各管一摊活儿。

1.2 多智能体协作的适用边界

我必须先泼一盆冷水：不是所有项目都适合上多智能体。我这套系统跑得顺，前提是项目形态非常适合它。

适合的场景有三个共同特征。第一，需求边界相对清晰，可以拆成独立任务，比如内部后台系统、报表工具、定时任务脚本；第二，交付物以代码和文档为主，不需要和外部硬件或者真人反复交互；第三，团队对代码风格和接口规范有明确约定，这样不同 Agent 产出的代码才能拼得起来。

不适合的场景也很清楚：涉及强交互的 UI 原型评审、需要线下资源协调的项目、需求三天两头大改方向的探索型业务，这几种情况别硬上。Agent 处理需求变更的能力比真人差远了，你让它重写一个模块，它大概率会把另一个模块的代码也顺手带偏。

提示：上多智能体之前，先把你要做的项目拆成一张任务清单。如果这张清单超过三成任务需要互相等待，那说明项目依赖关系太强，不太适合当前阶段的多智能体协作。

2. 系统架构：我把"团队"拆成了哪几层

2.1 整体拓扑与角色分工

我的系统没有用复杂分布式架构，就是一层很朴素的调度中心加六类执行单元。调度中心负责拆任务、分派、收集结果；执行单元是六个不同角色的 Agent，每个角色有独立的提示词和工具权限。

• 产品 Agent：接收原始需求，输出功能列表、验收标准和优先级
• 架构 Agent：把功能映射到模块，定义接口、数据结构和跨模块调用关系
• 后端 Agent：按照架构设计实现服务端逻辑
• 前端 Agent：基于后端接口实现调用方和页面逻辑
• 测试 Agent：根据验收标准生成测试用例，并实际执行
• 审查 Agent：检查代码规范、安全风险和设计一致性

这个角色划分不是拍脑袋定的，我参考了自己团队的真实岗位设置。关键原则是：每个角色的职责不能重叠。比如架构 Agent 只画接口，不写实现；后端 Agent 只负责实现，不改需求描述。职责一旦重叠，多个 Agent 就会对同一件事产生不同判断，最后产出的模块互相打架。

2.2 通信模式：共享黑板而不是微信群

多智能体系统最核心的设计决策不是用什么模型，而是 Agent 之间怎么通信。我见过很多方案用"消息满天飞"模式，每个 Agent 之间直接发消息，像一个热闹的微信群。这种模式在三个 Agent 时听起来很美，但 Agent 数量到五个以上就会失控：消息延迟、上下文重复、多个 Agent 同时抢改一个文件。

我采用的是共享黑板模式。所有 Agent 不直接对话，而是把产出写到一块共享工作区里，调度中心负责维护黑板上的内容版本。比如产品 Agent 写完需求文档，黑板上的需求文档就更新；后端 Agent 开始编码前，去黑板上读最新的接口定义，而不是靠消息告诉你"接口改过了"。

这对应到项目里就是一个共享文件目录加一份状态索引。每个 Agent 有权限读写自己的产物目录，但读取他人产物时只能读取，不能修改。这个权限设计非常重要，它是防止 Agent 之间互相覆盖劳动成果的关键。

2.3 任务编排：串行推进 + 反馈回路

任务不能一口气全发出去。产品分析、架构设计、后端编码、前端编码、测试这些阶段有严格的先后依赖。我采用了一个带反馈回路的串行流水线。

调度中心把流程定义成一个有向无环图：产品完成才能开始架构，架构完成才能分配前后端任务，前后端完成后测试才能开始。这避免了多个 Agent 抢在依赖未完成的情况下盲目开工。

但光串行会有一个致命问题：如果测试发现后端接口和前端调用不一致，整个流程就卡死了。所以我加了反馈回路。测试 Agent 发现的缺陷，不会直接打回给开发，而是先回到架构 Agent 做原因分类：是设计问题还是实现问题。这样避免两个开发 Agent 因为同一个缺陷互相推诿，循环重试。

我实测下来，单个项目的平均执行链路是 6 个阶段，其中平均会触发 1.8 次反馈回路。也就是说，完全一次通过的项目是少数，多数项目都要经历一轮来自测试或者审查 Agent 的返工。这不是缺陷，反而是多智能体协作的价值所在——它用额外的计算成本换来了质量的自我修正。

3. 核心环节实现：代码层面怎么落地

3.1 Agent 的基础抽象

说完了架构思路，直接上核心代码。我这里的 Agent 不复杂，核心就是一个带角色属性、工具权限、输出产物路径的执行函数。它内部还是调用大模型，但多了两层约束：角色提示词和产物校验。

from dataclasses import dataclass, field from enum import Enum from typing import Optional class AgentRole(Enum): PRODUCT = "product" ARCHITECT = "architect" BACKEND = "backend" FRONTEND = "frontend" QA = "qa" REVIEWER = "reviewer" @dataclass class Task: task_id: str role: AgentRole description: str input_paths: list output_paths: list status: str = "pending" # pending/running/success/failed result: Optional[str] = None retry_count: int = 0 @dataclass class Agent: role: AgentRole system_prompt: str allowed_tools: list model: str max_retries: int = 3 def execute(self, task: Task) -> Task: context = self._collect_context(task.input_paths) prompt = self._build_prompt(task.description, context) result = self._call_model(prompt, self.system_prompt) task.result = result task.status = "success" return task

这里有两个细节值得说。第一，每个 Agent 都有独立的system_prompt，这是角色行为约束的核心。第二，_collect_context只读取input_paths指定的文件，读取范围被严格控制，避免 Agent 看到不该看的内容而产生偏见。

3.2 角色提示词的设计

角色提示词是我踩坑最多的地方。一开始我写得又长又绕，结果产品 Agent 开始写代码，后端 Agent 开始谈需求。后来我总结出一套三段式提示词结构：

• 角色定位：用一句话说明你是谁、为谁服务、对接谁
• 工作方式：说明你输入什么、输出什么格式、遵循什么约束
• 避坑约束：明确列出你不该做的事情

以架构 Agent 为例：

你是一名系统架构师，负责把产品需求转化为可实施的技术设计方案。 输入：需求文档（来自产品 Agent） 输出：接口定义文档、数据模型定义、模块划分文档、技术选型结论 约束： - 只设计接口，不写业务实现 - 接口定义必须包含每个参数的名称、类型、取值范围 - 技术选型只允许从既定技术栈里选择 - 如果产品需求存在歧义，在文档中标注"待确认"，不要自作主张

这段提示词看着简单，但"只设计接口，不写业务实现"这句话省了我不计其数的返工。并且，要在每个角色提示词里加一句"如果你发现上游输入有问题，暂停并提交问题说明，而不是继续执行"。这是防止幻觉扩散的第二道防线。

3.3 上下文与状态管理

多智能体系统最常见的故障不是模型答错，而是上下文越滚越大，最后 Agent 只盯着最近对话，忘了项目背景。我用了两级记忆机制。

第一级是项目级记忆，存在共享目录的PROJECT.md里，记录项目目标、技术栈、模块树、历史决策。所有 Agent 在执行前都会读这个文件，但不写入。第二级是任务级记忆，每个 Agent 只保留自己这次任务相关的上下文，执行完毕就释放。

任务级记忆使用了摘要压缩策略：当单次任务的上下文超过模型窗口的 70% 时，就把早期内容压缩成摘要，作为前缀保留。这样能稳定地把单任务上下文控制在 4000 token 内，整个项目六七个 Agent 跑完，不会出现上下文互相污染。

3.4 质量闭环：审查、重试与失败降级

质量保障不能只靠一个测试 Agent。我在流水线末端加了一个独立的审查 Agent，它的任务是检查后端和前端产出的代码是否满足架构 Agent 定义的接口规范，以及是否存在明显安全问题。

审查 Agent 的输出是两类问题的列表：阻断问题和建议问题。阻断问题丢回对应开发 Agent 重试，建议问题写入项目日志但不影响上线。这个机制看起来很简陋，但它带来了一个关键收益：重试不是无限的。每个任务设置了最大重试 3 次，超过次数就触发失败降级，由调度中心输出一个"未完成任务报告"，人工介入。

4. 实操全过程：用模拟项目跑通整个系统

4.1 环境与依赖

整套系统跑在 Python 3.11 上，依赖极少。核心就用了一个异步 HTTP 客户端、文件操作库和一个 YAML 配置解析器。没有引入额外的 Agent 编排框架，这是刻意为之。我想先验证多智能体协作的核心逻辑，不想被框架限制。

模型方面，我统一调用一个成熟大模型的接口，通过配置文件切换角色对应的模型版本。实际跑下来，产品分析、架构设计这类推理任务用稍大一点的模型效果更好；前后端编码用普通模型就够；测试 Agent 倒是意外地吃模型能力，因为它要同时理解需求和代码两边的语义。

4.2 搭建共享工作区与协调器

共享工作区就是一个目录，我在里面建了五个子目录，对应五类产物。调度协调器是一个不到 300 行的 Python 脚本，作用是把任务队列按依赖关系排序、逐个分派、收集结果。

import asyncio from pathlib import Path class Scheduler: def __init__(self, agents, workdir: str): self.agents = agents self.workdir = Path(workdir) self.task_queue = [] def build_plan(self, raw_requirement: str): # 根据项目模板生成任务依赖图 pass async def run(self): for task in self.task_queue: agent = self.agents[task.role] task = agent.execute(task) if task.status == "failed" and task.retry_count < agent.max_retries: self.task_queue.append(task) # 重新排队 return self.generate_report()

关键点是任务重排队逻辑。失败的任务不是原地重试，而是丢回队列末尾，这样避免同一个失败任务卡住后面所有任务。

4.3 一次完整执行记录

我挑一个有代表性的模拟项目来展示执行过程。需求是"为内部项目管理系统增加报表导出功能，支持按日期范围导出 CSV 文件，并发送到配置的邮箱"。

第一阶段，产品 Agent 输出了功能清单：新增导出页面、按日期筛选、生成 CSV、异步发送邮件、导出历史记录。验收标准有 7 条，其中一条是"CSV 必须支持 UTF-8 编码，兼容 Excel 打开"。

第二阶段，架构 Agent 定义了接口：/api/v1/reports/export，参数是start_date、end_date、email，响应里带一个task_id用于异步查询导出状态。它特意标注了"待确认"项，要求产品确认超过 10 万条数据时的导出策略。

第三阶段到第五阶段，前后端编码和测试执行了约 40 分钟（含调用等待时间）。测试 Agent 生成了 6 条测试用例，其中一条 CSV 的 UTF-8 编码测试第一次跑失败了。原因是后端 Agent 写了标准的文件输出，但没有加 BOM 头。这个缺陷被打回后端，第二次修复通过。

最后审查 Agent 发现了一个阻断问题：CSV 字段拼接时没有处理单元格内包含逗号的转义场景。这个虽然有争议（因为当前需求里字段列表固定不含逗号），但审查 Agent 按规则把它标记为阻断，后端重试后加了双引号包裹逻辑。整个流程到此结束，耗时约 70 分钟，产出代码大约 600 行，前后端各 300 行。

4.4 成本估算与参数调整

跑完这套流程，最直观的成本是大模型 API 调用费。我按一次完整项目做了统计：

总计约 13 万 token 左右。如果模型单价较高，一次完整项目约几元成本，相比真人写 600 行代码的成本，算下来还是相当划算的。

参数调整上，最有用的一个旋钮是"测试 Agent 的严格程度"。我把测试 Agent 的提示词里加了一句"如果你认为需求描述存在明显遗漏，必须在测试用例中体现为未通过项"，整个系统的输出质量立刻上了一个台阶。因为测试 Agent 松弛的话，下游审查 Agent 再严也只是捡漏。

5. 踩坑实录：多智能体的十个常见问题

5.1 高频问题速查表

跑了两周，我整理了出现频率最高的问题，做成一张速查表：

5.2 最值得警惕的三个隐形坑

第一是幻觉扩散。单个 Agent 偶尔会编造一个不存在的接口名称，这不算严重，因为人类也会犯。但可怕的是，后端 Agent 编造了一个接口getExportStatus，前端 Agent 读黑板时发现这个"事实"存在，就会顺着去调用。系统内部因此形成了高度一致的"共识错误"。最后是审查 Agent 对照架构文档才揪出来的。所以架构 Agent 的定义文档必须被设为最高权威，其他 Agent 的产物都要和它对拍。

第二是无反馈的"死循环式完稿"。如果审查 Agent 一次性列出了 10 个阻断问题，后端 Agent 会进行一次大规模重写，但重写后往往会引入新的非阻断问题，导致又来一轮审查。解决方法是限制定量修改：每次重试只允许修复审查列出的问题，不允许顺手重构其他代码。这个约束在提示词里写了三遍，不然一定会出乱子。

第三是测试通过率和真实上线质量的错位。测试 Agent 写的测试用例，往往是基于它自己生成的种子数据，这些种子数据过于干净，导致测试通过率虚高。我给测试 Agent 加了一个"混乱数据注入"工具，让它至少在测试数据里加入 20% 的空值、重复值、边界值。这套改进之后，测试环节发现问题的数量增加了大概一倍。

注意：多智能体系统的测试，比单 Agent 更需要关注"数据的多样性"。干净数据下的绿色测试，往往只是给交付一个虚假的安全感。

6. 从这套系统里，我悟到的三件事

第一，多智能体的价值不在于让每个 Agent 变强，而在于让它们互相校对、互相兜底。单一模型再聪明，也躲不过上下文遗忘；但架构文档锚定 + 测试返工 + 审查拦截的三个环节，可以把质量波动死死按在可控范围内。

第二，系统调试的重心应该放在协作协议上，而不是单个 Agent 的提示词上。我花在调度、黑板、任务依赖上的时间，远多于调某个角色的提示词。角色提示词写得再完美，协作协议不通畅，产出依然是一堆拼不起来的碎片。

第三，多智能体的落地，本质上是把团队的隐形流程显性化。你平时怎么开需求评审会、怎么做接口联调、怎么设测试通过标准，这些规则如果说不清楚，Agent 更不可能执行到位。所以下一步我会把这套系统往实时交互的方向扩展，让产品 Agent 在需求不明确时可以直接向使用者提问，而不是只能写一个"待确认"了事。这里面还有不少坑要踩，等跑通了再回来分享。