企业官网建设流程全解析

去年年初我接了一个内部的自动化运营项目，围绕一个叫“agency-agents”的多智能体协作方向，把好几个不同专长的AI Agent组织成一个“虚拟项目组”，让它们像一支小团队一样去处理内容生产、数据整理、质量审核这些繁琐活。跑了几个月，从最初的手忙脚乱，到后来稳定出活，踩坑不少，收获更多。这篇笔记我就把这个项目的设计思路、核心架构、实操细节和常见问题完整梳理一遍。如果你正打算用多个大模型Agent协作处理复杂业务，又被角色划分、上下文管理、任务路由这些问题卡住，那这篇内容应该能让你少走些弯路。

1. 项目定位：多个Agent比一个Agent强在哪儿

先说痛点。单个Agent就像那种“全能但只有三小时专注力”的实习生，你让它写方案，它能写得像模像样，但一旦遇到需要查资料、交叉比对、多重审核的任务，它很快就开始跑偏，甚至自己脑补数据。原因不复杂：大模型本质上是单线程能力体，上下文窗口有限、注意力会随着对话长度衰减、任务环节一多，早期信息就被挤没了。而“agency-agents”这套思路的出发点很简单：与其逼一个Agent干所有事，不如养一支各有所长的Agent小队，让它们像公司组织架构一样分工、汇报、复核。它解决的不是“单个模型能力”的问题，而是“单点能力如何变成团队能力”的放大问题。

1.1 单Agent的瓶颈：会聊天，不一定能干活

我之前做过一次很典型的对比实验。让同一个模型分别用“单Agent直出”和“多Agent协作”两种方式去写一份市场调研简报，任务里有三个动作：收集数据、分析趋势、输出结论。

单Agent模式下，模型在一轮长对话里把这几个动作全做了，结果前两步表现尚可，第三步就开始糊弄——它在开头引用了某个市场数据，到结论部分又用了另一个口径的数据，前后明显打架。问题不是模型不够聪明，而是它没有一个“复核节点”，也没人逼它把上下文里的关键信息单独拎出来保存。说白了，大模型在长链条任务里缺乏“工作记忆巩固”的机制，聊着聊着就把自己说过的话给忘了。

多Agent模式下，我把任务拆成三段：数据收集Agent只负责找数据，分析Agent只负责看数据提结论，审核Agent负责检查前后一致性和逻辑漏洞。结果很不一样，因为每个环节都被限制在相对独立的上下文里，后一个环节拿到的输入是前一个环节的结构化输出，而不是一整段杂乱的对话历史。这套模式，本质上就是给模型补上了“分工”和“复核”两个单点缺失的能力。

1.2 多智能体协作的基本模型：角色、任务路由与共识

了解了痛点，再来看“agency-agents”是怎么组织起来的。它核心就三层：

• 角色层（Role Layer）：定义不同的Agent身份，比如决策者、执行者、质检者，每个角色有明确的职责边界。
• 任务层（Task Layer）：把复杂任务拆解成可执行的子任务，并标注依赖关系，谁先做、谁后做、谁可以并行。
• 共识层（Consensus Layer）：执行者和质检者之间进行多轮交互，不断收敛，直到给出一个让各方都满意的最终结果。

这套模型用生活里的比喻来说，就像一个小公司的项目流程：需求方提需求，项目经理把需求拆成任务，执行人员分别认领，最后还要有QA角色来验收。单Agent模式相当于一个人既当项目经理又当程序员还当测试员，遇到小需求没问题，项目一复杂，必然出纰漏。多Agent协作的本质就是把这三个角色分开，让专业的人做专业的事，同时通过流程上的制约关系来保证质量。

1.3 适合与不适合的场景

这套模式最适合的是那些流程相对明确、但执行过程里存在大量重复性、文本性、判断性工作的场景，比如研究报告生成、代码评审、客服工单分类、内容合规审查。在这些场景里，“流程可以结构化”这件事本身就是最大的优势。

不太适合的情况也有：纯粹的创意发散类任务（比如写首诗、做头脑风暴），多Agent反而会显得笨重；需要极低延迟实时响应的任务（比如在线客服对话），多Agent的消息传递和决策链路会拖慢响应速度。对使用者来说，技术开发者和技术经理是最直接的受众，但业务人员也可以借助低代码工具借用这套思路，不一定非要自己写代码。

2. 核心架构设计：为什么这套协作能跑通不散架

多Agent系统最大的风险不是“Agent不够聪明”，而是“Agent太多太乱”。如果把多个Agent丢进一个没有结构的群聊里，它们会开始互相干扰、争夺话语权、甚至陷入无休止的内部辩论。所以“agency-agents”在设计时，核心原则是“结构化协作”，而不是“群聊式协作”。整个系统围绕四个大模块搭建：调度中心、角色注册表、任务总线、上下文仓库。

2.1 “虚拟公司”模式：调度中心与角色注册表

调度中心是整个系统的总指挥，负责把用户的原始目标拆解为行动计划，再把各个步骤分发到对应的Agent。它的工作方式有点像项目经理：收到需求后，先判断需要哪些角色参与，再规划执行的先后顺序，最后跟踪每个子任务的完成情况。

角色注册表则是一个“人员花名册”，记录每个Agent的姓名、职责、擅长领域、输入输出格式、可调用的工具列表。这玩意太重要了。很多失败的多Agent项目，问题出在系统根本不清楚“每个Agent到底负责什么”，结果三个Agent同时尝试完成同一个任务，输出里充满了重复和冲突。注册表的好处就是把每个角色的边界先画好，调度中心才知道该把任务发给谁。

用配置化方式管理注册表还有一个额外的好处：调优非常方便。想换某个环节的模型，只要改配置项就行，不用改代码。我在项目后期对执行Agent的模型做了一次升级，整个过程只花了几分钟，这都得益于注册表的解耦设计。

2.2 任务拓扑与依赖关系：怎么拆才不会乱

有了角色，下一步就是任务拆解。这一步最容易犯的错是“简单切分”——把一个任务切成三份，然后让三个Agent同时开工，完事再拼起来。听起来高效，实际运行会发现整体效果很差，因为子任务之间往往存在依赖关系。

我采用的方案是任务拓扑图。以“写一份新能源行业分析报告”为例，任务可以拆成四步：数据收集和框架设计互相独立，可以并行执行；等这两步完成后，才能进入正文撰写阶段；正文完成后，才能进入质量复核阶段。调度中心只需要维护这样一张依赖图，然后根据它来排定执行顺序。用工程管理的术语来说，这相当于给Agent团队引入了“关键路径法”——先算出哪条链路的耗时可能最长，然后把优质的模型或更充裕的上下文预算分配给这条链路上的Agent，确保整体不卡壳。

2.3 上下文共享：黑板、便签与记忆仓库

多Agent系统比单Agent麻烦得多的一件事，就是信息同步。试想一下，数据收集Agent辛苦查到的资料，如果不同步给写稿的Agent，那写稿Agent只能凭空发挥，产出的东西必然质量堪忧。

我的解决方案是引入“黑板（Blackboard）”结构。所有Agent都可以读取黑板上的公共信息，但只有特定角色才能往特定的区域写入内容。比如数据收集Agent只能写“数据区”，框架设计Agent只能写“架构区”，内容生产Agent只能写“稿件区”，互相之间不能越界写入，避免信息污染。同时，每一步Agent的输出都会被压缩、去重、结构化，再存入记忆仓库，供后续阶段调用。

为什么用黑板而不是直接让Agent之间对话？因为对话是“无结构”的，所有消息混杂在一起，后续Agent要花大量精力去分辨哪些信息有用；而黑板是“有结构”的，每个区域有自己的格式和主题，Agent读取时能快速定位自己需要的内容。这一点，在上下文窗口紧张的场景下尤为重要。

3. 实操演示：从零搭一个最小可用的Agent团队

说了这么多概念，直接上一套最小可复现的方案。我会用Python写一个轻量级的多Agent调度器，定义一个需求解析Agent、一个内容生产Agent、一个质量审核Agent，让它们协作完成“生成一份新能源行业科普文章大纲”的任务。这套代码不依赖任何特定框架，理解原理后可以迁移到任何平台上。

3.1 环境准备与基础设计

先准备环境，需要Python 3.10以上，以及一个支持对话补全接口的大模型服务。这里我用一个抽象的接口来接入模型，只要它能输入文本输出文本就行，具体是哪家服务并不影响逻辑。

首先是Agent的基类设计。核心是一个run方法，接收上下文输入，返回结构化输出：

# agent_base.py class BaseAgent: def __init__(self, name, role, system_prompt): self.name = name self.role = role self.system_prompt = system_prompt self.memory = [] def run(self, task_input, shared_context): # 拼接系统提示词、共享上下文和当前任务输入 messages = [ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": f"共享上下文：{shared_context}\n\n当前任务：{task_input}"} ] response = self._call_model(messages) self.memory.append(response) return response def _call_model(self, messages): # 调用大模型服务，这里用通用接口占位 # 实际使用时替换为对应的SDK调用代码 return chat_completion(messages)

再定义三个角色的提示词：

• 需求解析Agent：“你是项目负责人，你的任务是将用户的目标拆解为可执行的子任务清单，输出JSON数组，格式为[{'step': 1, 'task': '描述', 'requires': []}]。你不要执行具体内容，只做规划。”
• 内容生产Agent：“你是内容撰稿人，根据给定的任务清单撰写内容，必须输出结构清晰的Markdown文本，不要超范围发挥，不要编造事实。”
• 质量审核Agent：“你是质检员，检查内容是否完整、逻辑是否通顺、格式是否符合要求，输出修改意见。如果内容没有问题，输出[PASS]。”

3.2 调度器：怎么把三个角色串起来

调度器是整个系统的核心，它负责串联三个Agent，并控制协作循环：

# scheduler.py class AgentScheduler: def __init__(self): self.agents = {} self.shared_context = {} def register_agent(self, agent): self.agents[agent.role] = agent def run_pipeline(self, user_task): # 第一步：需求解析 planner = self.agents["planner"] task_plan = planner.run(user_task, self.shared_context) # 第二步：执行 writer = self.agents["writer"] draft = writer.run(f"请按照任务清单执行：{task_plan}", self.shared_context) # 第三步：审核，最多循环3次 reviewer = self.agents["reviewer"] max_rounds = 3 for i in range(max_rounds): review_result = reviewer.run(draft, self.shared_context) if "[PASS]" in review_result: print("审核通过，流程结束") return draft else: print(f"第{i+1}轮审核未通过，按意见修改") draft = writer.run(f"请根据审核意见修改：{review_result}", self.shared_context) # 超过最大轮次，直接返回当前版本 return draft

这个调度器做了几件很重要的事：一是限制了审校循环的最大轮数，防止系统陷入无休止地挑刺-修改的循环；二是每一步都通过共享上下文传递关键信息，而不是把完整对话历史直接塞给下一个Agent；三是通过register_agent把角色注册和业务逻辑解耦。

3.3 跑一个具体例子：观察协作过程

我实际跑了一次，用户输入是“写一篇介绍新能源电池技术路线的科普文章大纲”。运行日志大致如下：

1. 需求解析Agent输出：

[ {"step": 1, "task": "列出三种主流电池技术路线名称", "requires": []}, {"step": 2, "task": "解释每种路线的原理和优缺点", "requires": [1]}, {"step": 3, "task": "对比三种路线的适用场景", "requires": [1, 2]}, {"step": 4, "task": "撰写科普文章大纲", "requires": [2, 3]} ]

2. 内容生产Agent输出：一份带三级目录的Markdown大纲，包含引言、技术路线介绍、对比分析、结论展望几个部分。

3. 质量审核Agent输出：给出两条修改意见，“‘固态电池’部分缺少最新进展信息，建议补充”；“‘适用场景’对比表格式不够直观，建议改为表格”。

4. 内容生产Agent根据意见修改后，复核通过。

整个流程跑下来大约两分钟，产出的是一个质量不错的结构化大纲。这个过程中最关键的一点是：每个Agent只专注于自己的那一步，不需要看前面所有步骤的原始聊天记录，上下文干净，模型输出自然更稳定。

3.4 模型参数调优与成本控制

实操中还有一个必须面对的问题：成本。多Agent系统天然比单Agent调用更贵，如果不做控制，一次复杂任务的Token消耗可能是单Agent的十倍甚至更多。

我最常用的小技巧是“摘要笔记机制”。每个Agent完成输出后，调度器先让一个轻量级压缩Agent（或直接用相同模型加一个“提炼摘要”的提示词）把输出浓缩为几条要点，然后再传给下一个Agent。这样可以显著减少下游Agent需要阅读的Token量。实测下来，某些场景下Token消耗能降低40%-60%，效果非常明显。

模型参数也有讲究。内容生产Agent这类需要稳定输出的角色，temperature建议设置在0.2-0.4之间，保证输出风格稳定；而质量审核Agent可以稍微调高一点，比如0.7-0.8，让它在找问题的时候更有发散性，不容易漏掉异常情况。并发策略上，前期调试阶段并行数不要开太高，先用1-2个Agent跑通流程，稳定后再逐步增加，否则出问题时排查成本会直线上升。

4. 常见问题排查与效果调优实录

多Agent系统的调试比单Agent难得多，因为问题可能出在任何一个环节，也可能是多个环节之间的交互出了毛病。我把实际运行中遇到最频繁的几类问题整理出来，方便排查。

4.1 问题速查表

4.2 上下文漂移问题与“需求不变式”

多Agent系统最常见的隐性bug，是任务执行到中后期，Agent开始“自由发挥”，产出内容偏离用户最初的意图。比如用户本来要的是“面向投资者的简洁摘要”，结果执行Agent在后期写出来一堆技术术语堆砌的冗长描述。

排查后我发现，问题出在上下文传递过程中：原始用户需求被淹没在中间环节的大量中间信息里，后面收到任务的Agent根本不知道自己为什么要做这件事。解决办法很简单，我给每个Agent的系统提示词里都加了一行“铁律”开头：

用户原始需求（永远不要偏离）：{user_original_request}

这在代码里是写死在模板里的，任何中间的摘要、压缩过程都不会动这行。相当于给整个团队立了一个“军令状”，所有人干活前都要先看一眼最终目标。加了这行之后，跑偏率肉眼可见地下降。

4.3 循环爆炸与Token失控

另一种高发问题，是质检Agent“过于尽职”。有一次跑代码生成任务，质检Agent给执行Agent提了十几条修改意见，执行Agent改完一轮，质检Agent又发现新的问题，再退回，一来一回跑了七八轮，预算烧掉了大半。

最后我给系统加了个硬性约束：任何环节的协商循环最多跑3轮，第3轮结束时如果还没通过质检，调度器直接选择“人工接管”或“强制采用最近一次版本”。实际效果证明，大多数情况下第3轮的产出已经足够好——因为反复修改本身存在边际递减效应，过了某个点，改动反而会破坏原有的结构完整性。

4.4 质量评估：怎么判断协作效果是否变好了

多Agent系统不是搭完就完事，必须有一套质量评估机制，否则你根本不知道改动是变好了还是变坏了。我的做法是建立一个小的“评分集”：收集20个典型任务，每次改完系统，都让它在这些任务上跑一遍，然后对产出做人工打分，主要看准确性、完整度、格式合规性和交付时效四个维度。

这个方法比较原始，但非常有效。有次我调整了一个Agent的提示词，表面上看单次产出变好了，但一跑评分集，发现其他几个任务的质量反而下降了。如果没有这套评分集，这个回归问题很难被发现。所以，任何多Agent系统在上线前，都应该先建立属于自己的回归评测集。

5. 场景扩展与落地心得

“agency-agents”这套架构虽然是在内部项目里打磨出来的，但它的适用范围非常宽。稍微改一下角色配置，就能迁移到不少业务场景里。

5.1 真实场景举例：客服工单自动化

我在另一个小场景里试过这套思路，用来处理客服工单。流程是这样的：

• 分类Agent先判断工单属于哪种类型（产品咨询、退换货、技术故障等）；
• 话术Agent根据分类结果和业务知识库生成回复草稿；
• 情绪Agent再分析客户原文的情绪倾向，如果检测到高风险情绪，标记为“需人工优先处理”；
• 最终所有工单统一送人工审核，审核通过才发送给客户。

这个场景的好处是每个环节都能选择最适合的模型：分类任务用轻量级模型就够，话术生成需要中档模型，情绪分析则用一个擅长语义判断的模型。多Agent的灵活性在这里体现得很直接，你不用拿一个“万能模型”去处理所有请求，而是按需选型，成本优化空间大。

5.2 架构演进方向

我目前的实现里，角色还是静态配置的——哪种任务需要哪些角色，是提前写死的。更进一步的玩法，是让系统根据任务复杂度动态生成新角色：先由“规划Agent”分析任务特征，然后自动定义角色的职责、提示词、工具权限，生成一个临时的Agent团队。这个方向目前也比较火，业内叫“自动团队生成”或者“动态多智能体”。

但从个人经验来看，动态团队目前还不太适合直接用到关键业务上，因为角色自动生成的随机性很大，可控性不高。更好的路径是先跑通静态团队，把协作流程、上下文管理这些基本功练扎实，再逐步引入动态化。一上来就追求全自动，大概率会被各种不可控的行为搞到崩溃。

5.3 给搭车者的几条实操建议

• 先做人机混合：不要一上来就追求“全自动”，先让Agent产出初稿，人类做最终审核。这样既能保证质量，也能在初期快速积累反馈数据，用来优化提示词。
• 别给Agent太多自由：自由是高熵的，Agent的自由度过高，产出的不确定性就越大。尽量用严格的任务模板和输出格式约束它们。
• 监控要前置：为系统加入日志查看器和Token计量器，记录每个Agent的调用情况、Token消耗和执行时长。否则一旦出了问题，你连问题出在哪都不知道。

最后说点个人感受。我到现在还记得第一次把一个真实业务全部交给“agency-agents”跑通时的场景，数据收集、对比、审核、生成、再审核，全流程自动完成，产出的报告比我预期的完整得多。但说句掏心窝的话，多Agent不是酷炫的概念，而是一套严谨的工程体系。你想真正用好它，得先接受一个事实：调试一个Agent团队，比调试一个Agent难十倍。这也是为什么我建议所有想尝试的人，都从最小三Agent协作开始——需求解析、执行、审核，先把这三个角色跑顺，再去追求更大规模的编排。这个小起点，能帮你把架构里的每个细节都吃透，后面的路会好走很多。