企业官网建设流程全解析

去年下半年，我们团队做了一个在旁人看来有点“冒险”的决定：把一条完整的软件研发流水线——从需求拆解、方案设计、编码实现到测试验收——全部交给一组 AI Agent 去协作完成。这套系统内部代号叫 Agency Agents，定位是多智能体协作系统。项目启动前，周围不少人都在观望：这到底是想用 AI 替掉程序员，还是搞一个只能演示的玩具？半年跑下来，我的答案很明确：它既没有替掉任何人，也不只是一个玩具，它真正重构的是研发团队里最值钱的东西——信息流转方式。这篇文章不打算讲太多学院派概念，而是把这个项目从架构设计、核心模块实现到生产落地踩坑的完整过程拆开，把每个关键决策的“为什么”也一并说清楚，给正在规划多智能体系统的团队一份可以直接参考的实操记录。

1. 为什么要重构开发团队：先看清协作里的隐性损耗

1.1 传统研发流程里最贵的是“等待”

先说一个很扎心的事实：大多数研发团队真正的瓶颈不是写代码的速度，而是信息在不同角色之间传递时产生的损耗和等待。一个需求从产品经理手里到最终上线，中间要经过需求评审、技术方案、编码、联调、测试、验收，每个环节都在等人、等确认、等反馈。我见过最典型的情况是，开发同学把代码写完了，才发现产品经理口述的需求和文档里写的是两回事，于是整个迭代返工。这种问题不是某个人的能力问题，而是流程本身的串行协作模式决定了信息必然失真。

所以当我第一次接触多智能体的思路时，脑子里第一个反应不是“AI 能写多少代码”，而是：如果每个角色都有一个训练有素的 Agent 来承担，那信息的交接是不是可以变成结构化的、可追溯的、甚至可并行的？这就是 Agency Agents 项目的起点。核心关键词是“协作”：不是做一个全能的超级 Agent，而是让多个专职 Agent 像真实团队一样分工配合，每个人负责自己擅长的环节，用统一的协议来交接成果。

1.2 多智能体协作改变了什么

多智能体系统本质上是在模仿人类团队的工作方式。所谓 Agent，我理解它不只是“会聊天的机器人”，而是拥有目标、能调用工具、能产出具体成果的工作单元。一个 Agent 负责写代码，另一个负责审查代码，还有一个负责跑测试并反馈结果——这个过程和真实团队的分工没有本质区别，区别在于它们之间的协作是基于明确定义的接口和协议，而不是靠人的记忆和默契。

落到实践里，这种模式带来三个非常明显的变化。第一是并行化：如果需求拆解足够细，多个开发 Agent 可以同时处理互不依赖的子任务，不再需要像以前那样排队等一个人把所有模块写完。第二是可审计性：Agent 之间每一次消息传递、每一次工具调用、每一次决策输出都会留痕，出了问题可以回放整个推理过程，这在传统协作里几乎不可能。第三是可量化的质量门禁：测试 Agent、评审 Agent 可以像 CI 里的检查项一样被强制执行，任何一环不过就返工，而不是靠“人情”放过。

1.3 不是所有团队都适合“重构”

说实话，我也见过不少团队拿着多智能体框架硬套传统流程，结果项目还没落地就被 token 成本烧垮了。这里我想给一个比较清醒的判断：如果你的需求高度模糊、业务逻辑极其复杂且强依赖线下沟通，现阶段不建议强行上多智能体；如果你的需求可以被拆成明确的模块，流程里有大量重复性的分析、编码、检查工作，那么多智能体协作系统的收益会非常大。Agency Agents 一开始就选了一个合适的切入点：把那些规则清晰的研发子流程——比如单模块开发、接口联调、自动化测试——交给 Agent 协作完成，人为干预只保留在需求确认和最终验收两个关键节点。

2. Agency Agents 的总体架构：把每一层拆开看

2.1 四层架构：接入、编排、能力、数据

整个系统在设计上严格遵循分层思想，我没有选择把逻辑全塞进一个超大循环里，因为多智能体系统最大的风险就是“失控”，而分层是控制复杂度的第一步。从上到下大致是四层：

第一层是模型接入层。这一层负责屏蔽不同大模型服务的差异，把各家推理接口统一封装成一个标准调用入口，同时处理限流、重试、并发控制和模型路由。为什么要单独做一层？因为实测下来，不同模型在不同任务上的表现差异很大：有的模型适合做代码生成，有的模型在长文本理解上更稳。我们把“用哪个模型”做成可配置的策略，而不是写死在代码里，这样后续模型升级只需要改配置。

第二层是编排层，这是整个系统的核心。它负责维护一张任务图，记录当前有哪些子任务、各自的依赖关系、状态是待执行还是已完成，以及接下来应该由哪个 Agent 接手。编排层还控制着整个协作过程的终止条件，防止 Agent 之间无限“踢皮球”。我把编排看成整个系统的“项目经理”，它自己不写代码、不分析需求，但所有工作的推进节奏都由它把控。

第三层是能力层，或者说工具层。Agent 本身只是“大脑”，真正干活靠的是工具：代码仓库读写、命令行执行、测试框架调用、文档检索等等。每个工具都需要显式注册、声明参数格式，并且有独立的权限控制。这一层我们踩过不少坑，后面在落地章节里细说。

第四层是数据层，负责持久化记忆和运行日志。短期记忆存在工作上下文里，长期记忆落到向量数据库和结构化存储中，每次协作的完整轨迹都会落库，用于复盘和后续评估。

2.2 角色模型：让每个 Agent 只专注一件事

Agency Agents 采用了角色分离的设计，而不是让一个 Agent 包办所有事。为什么这么设计？核心原因是上下文窗口是有限的，一个 Agent 的注意力就是它的上下文，塞得越多，越容易偏。把研发流程拆成几个专职角色，每个角色的上下文里只放它需要的信息，效果会稳定很多。

我们定义的初始角色有五个：需求分析 Agent，负责把原始需求整理成结构化的需求描述、验收标准；架构设计 Agent，负责拆模块、定接口，输出技术方案；开发 Agent，负责按方案实现代码和单元测试；测试 Agent，负责生成测试用例并执行，把失败结果反馈回去；评审 Agent，扮演质量门禁的角色，检查代码规范、覆盖率、潜在缺陷，不通过就打回。

这套角色模型参考的是真实研发团队的最小配置。你会发现它并不是越多越好，五个角色能覆盖一条完整的单模块交付链路，再多就会引入不必要的通信成本。每个 Agent 都有自己的“岗位说明书”——也就是系统提示词里写清楚的目标、输入格式、输出格式、行为约束。这听起来简单，实际是决定系统行为稳定性的最关键因素之一。

2.3 通信与消息机制：黑板模式与任务图

Agent 之间怎么通信，是设计早期争论最多的问题。最后我们选了一种接近“黑板模式”加“共享任务图”的混合方案。所谓黑板模式，就是所有 Agent 不直接私聊，而是把阶段性成果写到一块共享区域，需要的人自己去读取。这样做的好处是弱耦合：A 角色产出的文档放在黑板上，B 角色只需要按约定格式取用，不需要知道 A 是怎么生成的。

任务图则是编排层给所有 Agent 的“作战地图”。每个节点是一个子任务，边上标注依赖关系。Agent 完成任务后，会更新节点状态并写入产出物地址。这样做的直观好处是：任何一个环节失败，都能立刻定位到具体节点和数据，排障效率比看聊天记录高得多。如果你只用消息队列让 Agent 你一句我一句地对话，很快就会被无主题的闲聊淹没，这是我们反复验证过的教训。

3. 核心模块的工程实现：从抽象到代码

3.1 Agent 的统一抽象与注册机制

所有 Agent 在代码层面都遵循同一个抽象接口，这也是实现多角色统一调度的基础。我倾向于把 Agent 定义成一个配置驱动的组件，而不是为每个角色单独写一套调用逻辑。核心字段包括：角色名、系统提示词、可用工具列表、使用的模型策略、以及输出协议。这样新增一个角色，本质上是新增一份配置，不会改动编排层代码。

@dataclass class AgentConfig: role: str # 角色名：developer / tester / reviewer system_prompt: str # 岗位说明书 tools: list[str] # 允许使用的工具列表 model_policy: str # 模型路由策略：按任务类型选择 output_schema: dict # 输出协议：定义产出物结构 max_iterations: int = 10 # 单角色最大尝试次数

这个抽象用得非常顺手。接新模型、加新角色、调提示词，全是配置变更，不涉及核心代码改动。给团队的启发是：多智能体系统首先是工程问题，配置化是让系统活下来的关键，不要一上来就写死逻辑。

3.2 工具接入与权限控制的“翻车”经验

工具层是整个系统里最像“现实世界”的地方。Agent 说得再好听，真正调用命令行把代码跑起来的那一下才会暴露问题。我们早期给开发 Agent 开放了 shell 执行权限，结果它在一次测试任务中直接把临时环境的依赖全局升级了，导致后面的任务全部失败。这次事故之后，我给工具层加了三道防线：

第一，所有工具必须显式声明参数 schema，Agent 只能生成参数，不能自由拼接命令。第二，所有工具分成只读和写两类，写操作必须经过编排层确认，并且统一在沙箱环境里执行。第三，所有执行结果都会回传给 Agent，但它看不到完整的环境状态，避免它基于错误假设做下一步决策。这些限制看似束缚了 Agent，实际上大大提升了稳定性。

这里我想补充一个观点：工具不是越多越好。每个工具都意味着更大的选择空间，也就意味着更高的出错概率。我们上线初期只保留了六个核心工具：代码读取、代码搜索、命令行执行、测试执行、文档写入、需求黑板上读。够用且可控，这是工具选型的基本原则。

3.3 任务分解与编排引擎：从需求到任务图

任务分解是多智能体系统的真正难点。它决定了一个复杂需求能不能被并行处理，也决定了每个 Agent 的上下文是否干净。我们采用的做法是“两级分解”：先由需求分析 Agent 把原始需求拆成用户故事级别的任务项，再由架构设计 Agent 为每个任务项标注依赖关系和技术约束，最终生成一张任务图。

任务图是 DAG 结构，每个节点包含任务描述、产出物定义、验收标准、指定角色。这里有个很关键的细节：验收标准必须在任务进入执行队列之前就定义清楚，否则开发 Agent 做完以后，测试 Agent 和评审 Agent 会陷入“什么算完成”的无限争论。先定义标准，再干活，这条规则在人和 Agent 之间同样适用。任务图生成之后，编排层会做一次拓扑排序，把可以并行的节点标记成同一批，按批次调度给不同角色的 Agent。

3.4 记忆与上下文管理：别让 Agent“记太多”

记忆设计是我最想强调的部分。很多人做多智能体系统，恨不得把整个项目历史都塞给每个 Agent，结果上下文一长，模型就“犯迷糊”，前后矛盾。我们的原则是“按需投喂”：每个 Agent 只拿到它执行当前任务所需要的最小上下文集合，包括任务描述、相关代码片段、接口定义、以及黑板上指定路径的文档内容，而不是整个对话历史。

长期记忆则交给数据层。协作完成之后，关键结论、代码结构、接口约定会被结构化后写入长期记忆库。下一次类似任务需要时，通过向量检索把相关的“历史经验”带回来。这个设计让系统有一点“团队成长”的意思，同一个 Agent 在跑了半年之后，处理相似任务的第一次成功率明显更高。但我要提醒一句：长期记忆的写入必须经过筛选，不是所有对话都值得记住，垃圾进垃圾出，检索质量很快会被污染。

4. 从零到一：具体落地一套多智能体系统的完整过程

4.1 基础设施准备：四样东西先备齐

在写任何业务逻辑之前，先把基础设施想清楚，能省掉后期一大半的返工。我们落地时准备的底料就四样：大模型推理服务、向量数据库、一个任务队列、还有代码仓库的读写权限。模型服务我们同时接入了云端接口和私有化部署，原因很实际——敏感代码不能出内网，而日常需求用云端能力更快。向量数据库用来放长期记忆和检索索引，可选的开源方案就够用，不需要上太重的架构。

任务队列这里值得多说两句。多 Agent 协作是典型的异步场景，开发 Agent 在跑一个编译任务的时候，测试 Agent 可能正在等依赖。我们直接用了一个轻量队列来解耦，每个任务节点的状态变更都通过队列通知编排层。如果一开始就坚持同步调用，系统会被最慢的那个 Agent 卡住，整体吞吐量非常难看。做架构的人一定要记住：多智能体本质上是分布式系统，异步是默认姿势。

4.2 最小闭环：先让两个 Agent 跑通再看效果

我们遇到的第一个诱惑是做全功能版本，五六个 Agent 一起上。还好忍住了。真正让项目“立住”的，是一个只有两个 Agent 的最小闭环：需求分析 Agent 和开发 Agent。需求分析 Agent 负责把一条简单的功能需求转成结构化任务描述，开发 Agent 根据描述生成代码并提交。整个链路跑通之后，再加测试 Agent、评审 Agent，每一步都验证增量价值。

这个最小闭环的价值再怎么强调都不过分。它验证了三个最关键的前提：模型能理解结构化输出协议、工具调用链路是通的、编排层能正确调度。这三个前提任何一个不成立，后面加多少 Agent 都是白搭。我建议所有准备做多智能体系统的团队，第一周的目标就一个：两个 Agent 协作完成一个你能看得见结果的真实任务，不是 Hello World，而是一个真实的小功能。

4.3 关键参数与调优：几个直接影响质量的旋钮

当最小闭环跑通之后，真正考验工程能力的是参数调优。这里挑几个我们花了最多时间调整的参数讲讲。

第一个是单 Agent 的最大迭代次数。默认值给低了，Agent 经常还没做完就放弃；给高了，遇到棘手问题会陷入长时间自循环。我们最后给开发 Agent 设成 15 次，给评审 Agent 设成 5 次，因为评审只需要做判断，不需要反复试探。

第二个是温度参数。代码生成类任务我们把温度压到 0.2 甚至更低，保证输出稳定；需求分析和方案设计这类偏发散的任务用 0.7 左右，给模型一点创造性空间。一个系统里不同角色用不同温度，这是很快见效的小技巧。

第三个是超时控制。Agent 调工具是有真实耗时的，命令执行可能几十秒，模型推理可能十几秒。我们把每个工具调用都加了超时和重试策略，超时后记录日志并让编排层重新调度，而不是干等。这部分直接影响系统在弱网环境下的可用性，很值得提前设计。

4.4 成本与收益评估：账要算清楚

多智能体系统的成本是绕不开的话题。我们做过一次统计：完成一个中等复杂度的模块开发，从需求分析到测试完成，平均消耗的 token 大约是直接让单个 Agent 写代码的三倍。听上去吓人，但如果结合返工率来看就合理了：多角色协作让首次交付通过率提高了不少，整体算下来单位通过需求所花费的总成本反而持平，而交付周期明显缩短。

控制成本我们做了三件事。第一是模型分级路由：简单任务走便宜的小模型，复杂任务才用强模型，实测能省三成以上成本。第二是缓存：重复的代码检索、相似需求分析结果都做语义缓存，效果显著。第三是上下文瘦身：前面讲的按需投喂不仅是质量手段，也是省钱手段，少一个 token 就少一分钱。算账不用等到上线后，原型阶段就要记录 token 用量和成功率的比值，这个指标决定你能不能长期跑下去。

5. 踩坑实录：常见问题与排查技巧整理

5.1 Agent 之间“踢皮球”：死循环与收敛控制

多智能体系统最常见的翻车方式，是两个 Agent 因为对“完成”的理解不一致，反复互相打回。我们有次测试 Agent 说测试失败，开发 Agent 说代码没问题，两个人来回推了七轮，token 烧了一堆还没结果。这个问题的根源不完全是模型笨，而是缺少明确的收敛信号。

我们的解法是双管齐下。第一，所有角色必须按输出协议产生结构化结果，并且在结果里显式声明当前状态是“完成”“需要补充信息”还是“阻塞”，不允许输出模棱两可的文本。第二，编排层设置全局轮次上限，达到上限就强制进入人工评审通道，不无限耗下去。后来我们又加了一条：同一对 Agent 之间来回打回累计超过三次，自动升级给评审 Agent 介入。这套机制上线后，死循环问题基本绝迹。

5.2 上下文污染：Agents 越聊越偏

上下文污染是另一个高频问题。现象是：一个任务刚开始很正常，跑了几个来回之后，Agent 开始讨论上一个任务的内容，甚至把无关代码片段当作当前任务的参考。原因也很简单——我们把共享黑板里的历史信息没有做好隔离，Agent 在取产出物时把“附近”的内容也带回来了。

排查办法是给每个任务节点做上下文隔离：任务图上的每个节点，允许访问的文档、代码路径、历史消息都是白名单制，不在白名单里的内容直接不可见。这个改动做起来不复杂，但需要严格维护白名单字段。我建议在系统设计阶段就把“上下文作用域”想清楚，而不是等出问题再去补救。

5.3 工具调用失败：Agent 的错误恢复能力不足

工具调用失败是每天都可能遇到的事。我们遇到的典型场景是：测试 Agent 去执行一条命令，环境恰好没有安装依赖，它报错了。按理说它应该安装依赖再跑，但早期版本里它会直接把这个错误当成最终结论返回，导致整个任务被判失败。这说明模型在“工具失败—自我修复—重新尝试”这个循环上的能力，比起写代码本身要弱得多。

后来我们加了两层保障。第一层在工具层：常见错误，比如依赖缺失、文件不存在，由工具执行器自动做标准修复（自动安装缺的东西、创建缺失目录），并重试一次。第二层在 Agent 提示词：明确告诉它，工具调用失败不代表任务失败，先分析错误原因再决定下一步，最多重试三次。同时我们把每次失败的错误信息截断到合理长度，防止巨型错误日志污染上下文。这套组合拳下来，工具失败导致的无效终止少了大概六成。

5.4 质量评估与回归：怎么知道系统没变笨

多智能体系统最大的一个隐患是“不可预测的退化”：你升级了模型提示词，或者换了底座模型，对整个系统的行为影响可能是全局的、非线性的。如果不建立回归体系，你会很难判断一次改动到底是变好了还是变坏了。

我们建立了一套最小评估集：挑出二十个历史真实任务，涵盖开发、测试、评审各类场景，每次改动后跑一遍，统计通过率、返工轮次、耗用 token 三个核心指标。评估结果不一定完全自动判定，关键节点用人工抽检。这套回归不重，但极其救命——有一次我们调整了模型路由策略，整体成本降了，结果代码通过率从百分之八十掉到六成，如果没有回归集，这个问题可能要等到生产事故才被发现。下面是几个高频问题速查：

6. 我的几点体会与后续扩展方向

踩过这么多坑之后，我最深的体会是：多智能体系统真正难的，从来不是让单个 Agent 变聪明，而是让一群 Agent 保持稳定和可控。它更像是在建一个组织，而不是在写一个算法。组织结构、岗位职责、协作协议、熔断机制，这些工程层面的东西，决定了系统是能长期跑下去，还是只停留在 Demo 阶段。我也越来越觉得，落地的关键不是追求“全自动”，而是找到人和 Agent 的最佳分工点：Agent 负责重复性高、规则明确的工作，人负责判断和兜底。

最后分享一个小技巧：如果你们团队也想尝试，不要一开始就追求“替代真实团队”，而是选一条最简单的真实研发子流程，比如“单模块开发到自测通过”，用两个 Agent 把它跑起来。在这个闭环里把任务分解、工具调用、上下文隔离和终止条件都磨顺，再逐步扩展角色。这个内容我觉得后续可以继续深入的方向还有两个：一个是把长期记忆从“被动检索”升级成“主动沉淀经验规则”，让系统真正学会举一反三；另一个是把评估集扩大成自动化闭环，让每次变更都自动跑回归并给出质量报告。多智能体协作这块明显还在高速演进期，想把系统做好，唯一的路径就是自己下场踩一遍坑。