企业官网建设流程全解析

之前我在个人博客里零零散散写过一些多智能体协作的尝试，但真正把整套流程按“代理机构”的方式固定下来，还是从这个叫“agency-agents”的项目开始的。它做的事情说起来并不复杂：把一个项目从“客户一句话”到“成品交付”之间的所有环节，拆成若干个由AI智能体承担的岗位，让每个岗位按自己的职责处理信息、产出内容、提出意见，再由一个统一的流程引擎把它们串起来。你可以把它当成一家没有工位的微型代理公司，里面各角色各干各的活，但协作结果最终会汇集到一组可以对外交付的文档。

我做这个项目的直接动机，是长期处理外包单时发现自己的时间大量浪费在重复沟通和修改上。客户提的需求经常只有三四句话，但背后涉及的受众分析、竞品调研、核心卖点提炼、文案调性拿捏，每一轮都要反复来回。这些事情并不是没有规律，只是每次都要人肉重复一遍。我开始思考：如果让一个需求分析师类型的智能体先把客户的话翻译成结构化任务书，再让策划、文案、设计顾问、审核员这些不同角色的agent依次处理，最后再经过人工抽检，是不是就能把单次交付的准备时间从两小时压到半小时以内？这个想法就是“agency-agents”的起点。

这篇文章我会把项目的设计逻辑、角色定义、实际跑通的过程、遇到的主要问题以及我觉得值得继续做的方向全部展开。如果你是做服务外包的，或者对多智能体协作感兴趣，这里面的很多东西可以直接抄作业。

1. 整体设计思路：为什么一家“代理机构”需要一群agent

1.1 传统工作流程里的隐性成本在哪里

在正式写代码之前，我花了一周时间做流程拆解。我把自己过去一年多接过的项目类型全部列出来，发现大部分需求可以归类为：品牌宣传文案、活动策划方案、社媒内容日历、简单视觉方向建议。这些项目的共同点是都需要几个固定的能力：理解客户原始表达、补全背景信息、把信息组织成结构化的任务、在任务里拆解出多个产出方向、逐个方向写出可执行的文案、最后检查有没有偏离需求。

如果靠人力来做，每一步都需要沟通和确认，尤其是需求理解和产出方向这两环，占掉了几乎一半时间。而这两环恰恰又是最容易被规则化、模板化的：客户说“我们想做一个年轻向的产品介绍页”，其实背后就意味着受众画像、语气风格、文案结构、视觉偏好等一组默认参数。人工做的时候是凭经验快速脑补，所以我希望agent也能做到这一点。

1.2 把“外包协作”转译为“智能体协作”

我更关键的一步，是把现实中代理机构的协作模式翻译成技术架构。现实中有项目经理、策划、文案、美术指导、校对，每个角色只负责自己那部分，信息通过文档和会议传递。这个模式天然就适合用多智能体来模拟。

在多智能体系统里，每个agent可以有自己的系统提示词、自己的记忆区域、自己的输出协议。我让“需求分析师”只负责把原始需求转化成一个标准化的JSON任务书；“策略策划”只阅读任务书并输出方向建议；“文案执行”只接收策略并产出多个版本内容；“视觉顾问”只负责给出风格和版式建议；“质检员”则按规则逐项核对交付物。这样每个agent的输入输出都相当干净，测试和排错也容易。

注意，刚开始我犯过一个错：想设计一个“万能agent”来干所有事情。结果它总是把需求理解、文案、审核混在一起，输出类型不可控，后期根本无法追责。后来才彻底改成角色隔离的模式。

1.3 项目的能力边界

我需要提前说明“agency-agents”不做什么。第一，它不做真实的图像生成，视觉顾问只给方向和参考描述，不直接产出图片；第二，它不替你做客户沟通，所有agent的产出最后仍需人来看过、再转发给客户；第三，它不自动对接付款、合同这类业务流程，只关注从需求到内容交付这一段。

这个边界设定很重要，因为如果你期望一个agent系统包揽所有事，很容易在无关环节浪费精力。把边界划清楚后，项目的目标就非常聚焦：把从“原始需求”到“可交付内容”之间的处理流程尽可能自动化，同时保留人工抽检和修改的入口。我觉得这是很多个人开发者容易忽略的一点：不是所有环节都值得自动化，先把高频、重复、低决策成本的部分自动化，收益最大。

2. 核心角色与信息流设计

2.1 五个agent岗位和它们的职责协议

我把团队里的角色固定为五个：需求分析师、策略策划、文案执行、视觉顾问、质检员，另外还有一个“流程控制器”负责调度，但流程控制器不算内容角色。

每个角色的职责用系统提示词约束得非常具体。比如需求分析师的唯一输出就是一张结构化的需求卡片，包含项目类型、目标受众、核心关键词、必须包含的卖点、字数范围、语气风格、参考案例链接，这些字段用JSON格式固化下来。视觉顾问的输出则是一段结构化的视觉建议，包括主色建议、字体方向、构图参考、或参考文献格式的推荐，而不会去写文案。

每个agent都有各自的“工作守则”，比如文案执行必须提供三个版本：一个偏理性功能型、一个偏感性故事型、一个偏极简直接型。这三个版本不许合并，再在这三版基础上生成一个推荐组合方案。质检员的协议里有一条硬规则：如果发现文案里没有出现需求卡片中标记的“必含卖点”，直接返回给文案执行重新写，而不是自己动手修改。

2.2 信息流的四个关键节点

整个系统里的信息流其实不复杂，但执行顺序和边界必须明确。我设置了四个关键节点：需求解析、策略锚定、内容产出、质量验证。

在需求解析节点，流程控制器把客户原始消息直接交给需求分析师，拿到结构化的需求卡片后进入下一环。策略锚定阶段由策略策划读取需求卡片，输出三条方向策略，每条方向包括目标解读、内容重心、情绪基调。内容产出阶段由文案执行读取需求卡片和策略锚定结果，分别按不同策略生成文案。质量验证阶段由质检员逐项核对需求卡片字段，给出通过或不通过的结论，以及需要修改的具体位置。

这四个节点之间没有回头路，但允许循环。如果质检不过，需求卡片和当前文案会一并传回文案执行那里进行修改，修改后再次进入质检，最多循环两次。超过两次就自动通知人工介入。这个有限循环的设计防止了agent之间无限踢皮球。

2.3 为什么不用单个大模型来包办

可能有人会问，把这些角色提示词合到一个prompt里，让大模型一次输出完整方案不就行了吗？我试过，效果确实有，但有一个致命问题：一次输出时，模型内部容易“偷懒”。比如需求分析不足就直接开始写文案，或者文案写得天花乱坠却忽略了原始需求里的限制条件。把流程拆成多agent后，每一环的上下文都相对简单，模型不需要在同一个长上下文里来回切换角色，输出的稳定性反而高很多。

另外一个很重要的点是可追溯性。当单轮输出模式出问题时，你很难判断到底是需求理解坏了还是文案生成坏了。但在多agent模式下，我可以直接查看需求分析师抽出来的JSON卡片，一眼就能判断是上游错了还是下游执行偏了。这种可追溯性对于工程调优来说是决定性的。

3. 工程化实操：从零搭起一套可复用的agent协作系统

3.1 基础框架选择与安装

在技术选型上，我没有选择自己从零写调度逻辑，而是基于一个开源的轻量级agent编排框架来做的，具体名称在这里不展开，但你可以在代码托管平台上搜“多智能体工作流编排”相关关键词找到同类项目。选择这个框架的原因有两点：一是它已经实现了多agent之间的消息路由和上下文隔离；二是它有可插拔的存储层，可以方便地记录每个agent的输入输出轨迹。

我推荐一个比较稳妥的起步组合：后端用Python写，编排框架用支持异步任务的，模型接口统一走OpenAI兼容协议。这样即使你后续想换不同模型服务商，也只需要改一个环境变量。我自己当时是接了一个支持较长上下文的商业模型接口，同时在本地部署了一个较小的开源模型作为“快速预览”用，这样可以控制成本。

3.2 配置文件的写法与角色注册

框架安装好之后，最关键的一步是定义一个agents配置目录。我建议把所有角色定义放在一个yaml文件里，而不是散布在代码中。这个yaml文件的每条记录包含三部分：role（角色名）、system_prompt（系统提示词）、input_schema（输入结构说明）和output_schema（输出结构说明）。比如需求分析师的output_schema会定义所有字段的类型和必填项，质量控制器的output_schema则包含一个布尔类型的pass字段和一个字符串类型的reason字段。

这里贴一个简化版配置示例：

agents: - role: requirement_analyst system_prompt: | 你是一位资深的需求分析师。 你只把用户提供的原始需求整理成结构化需求卡片。 不要给出任何解决方案，也不要写文案。 如果原始需求信息不足，请在卡片中标记unknown字段。 input_schema: raw_text: string source_urls: list[string] output_schema: project_type: string target_audience: string key_points: list[string] mandatory_selling_points: list[string] word_count_range: [int, int] tone: string unknown_requirements: list[string]

另一个需要特别配置的部分是角色之间的转发规则。在框架里，每个agent都有一个“next”字段，标明自己处理完后把结果传给哪个agent。比如需求分析师的next是strategy_planner，strategy_planner的next是copywriter，copywriter的next是quality_inspector。这个next规则不是写死在代码里的，而是放在配置里，方便后续随时修改流程顺序。

3.3 工作流引擎中状态流转的实现

框架本身提供了任务状态机的支持，但我觉得默认状态不足以支撑业务情况，所以做了一个简单的扩展。我为每个任务维护了当前阶段、输入内容、输出内容、重试次数、所有阶段的日志。

流程控制器的核心逻辑其实只有几十行伪代码，大致如下：

def run_workflow(task_id, raw_input): stage = "requirement_analysis" result = {} context = {"raw_input": raw_input} while stage != "done": agent = get_agent(stage) response = agent.execute(context) context[stage + "_output"] = response stage = next_stage(stage, response) return context

当然，实际代码里我还加入了每次调用前的数据校验和调用后的输出schema校验。这一步非常重要，因为模型偶尔会多输出字段或者漏字段，如果不校验，后面所有环节都会读到一个坏的上下文。我建议每个人都在agent调用后加一个简单的校验函数，使用JSON schema库或自己写字段检查都行。

3.4 如何保证上下文不串味

多agent系统最怕的就是上下文污染：前一个agent的错误判断或者跑题内容被后一个agent当作“事实”。为了防止串味，我做了两个处理。

第一，每个agent的输入是固定的、显式命名的字段，而不是前一环的完整输出。比如文案执行拿到的不是需求分析师的原始回复，而是经过清洗后的需求卡片JSON。第二，我在每个角色的系统提示词末尾都会加一句“你只应使用输入字段中的内容，所有输出必须严格遵循当前角色职责，不得引用你在其他角色中的猜测或假设。”这句话看着简单，但实际测试中能显著降低跑题概率。

我还额外做了一个“关键信息锁”：需求卡片中的mandatory_selling_points字段在完整流程中不可被任何其他agent修改。框架会在每两个agent交接时检查这个字段是否仍存在且内容未被改动。这个锁让质检员有了一个固定的核对基准，否则一个写文案的agent很容易在过程中“顺手优化”掉客户一开始强调的卖点，导致交付结果大走样。

4. 实战复盘：从需求到方案完整走一遍

4.1 输入一个典型的模糊需求

为了验证系统，我准备了一条过去经常遇到的客户需求：“我们想做一个线上推广用的产品介绍长图，主要面向二十多岁刚工作的人群，突出产品省时省力，最好有一种轻松的氛围，文案不用太长，但要有记忆点。”

这条需求信息量其实很少：没有账户名称、没有具体产品、没有投放渠道，甚至没有说清楚“长图”是给视觉设计师用的画面描述脚本，还是给文案用的排版文案。如果按照旧方式，我需要先追问五个问题才能开始。现在我把这条需求放进“agency-agents”，看它如何自动处理。

4.2 各环节的实际输出观察

需求分析师拿到这条消息后，按协议生成了一张需求卡片。它抽取出的project_type是“social_media_image_script”，target_audience是“23-29岁初入职场人群”，key_points标记了“省时省力、轻松氛围、短文案、记忆点”。对缺失的账户和产品名，它没有瞎编，而是放到了unknown_requirements里，并在后续传给策略策划时明确提示“账户信息和产品名称缺失，策略中不输出具体品牌名”。

这一步输出质量让我很满意，因为如果换成单agent直接写文案，它很可能会自动编一个品牌名，或者顺着“省时省力”就开始写“一键搞定的神器”这种陈词滥调。现在的结构化过程天然逼迫它承认未知。

策略策划拿到需求卡片后，输出了三条方向策略。第一条是“效率提升型”：突出下班时间解放，用具体时间数据对比制造痛点；第二条是“轻松生活型”：用白描场景展示早晨从容的状态；第三条是“反套路型”：用一句自嘲的短句点出产品不可替代的价值，视觉上可以采用手写字体。每条方向都配了执行要点和情绪基调。

接下来文案执行分别按三条策略各写了两个版本，其中方向二的一条输出是：

“早上比闹钟晚起二十分钟，还能悠闲喝完一杯咖啡——这份从容，是它给的。”

这句话并不复杂，但我看到时还是有点惊喜，因为它直接呼应了“二十多岁刚工作”的生活场景，而不是生硬的“高效”、“便携”等形容词堆叠。视觉顾问则基于这张长图的场景给出了主色建议（暖白色配合低饱和橙色）、字体方向（正文用非衬线体，标题可用手写感字体）、构图建议（上半部分文字区，下半部分生活场景插画）。

质检员最后逐项核对了需求卡片。它发现整个交付内容缺少“记忆点”的显式解释，于是返回给了文案执行。文案执行收到修改意见后，在版本二里增加了一句“一句话总结：它能替你把那些琐碎的小事，悄悄打包带走。”重新提交后，质检员才给出了pass。

4.3 从输入到交付的耗时和成本统计

我记录了一下这次完整运行的耗时：模型调用一共11次，从输入到最终质检完成，用了大概90秒。由于大部分调用集中在文案和审核环节，成本约为直接让模型写五版文案再人工整合的六成。最值得对比的地方是人工参与时间：我只需要在质检通过后快速看一遍产出，确认没有语法问题和明显品牌风险，总共花了大约四分钟。而以前同样类型的基础策划，我至少要花四十分钟以上。

当然，这个效率提升的前提是需求中的未知信息会被显式标记出来。如果unknown_requirements太多，流程会直接停在一个需要人工补充信息的节点，而不是继续硬跑。这也是我在流程控制器里特意加的一个分支：如果unknown_requirements字段数量大于等于3，自动进入“需人工确认”状态，不再流转。

5. 常见问题与调优经验

5.1 最常见的五个协作卡死问题

在测试阶段，我遇到了不少“看起来像是死循环”的问题，后来总结出五个典型情况。第一，文案执行反复否定自己，每次都给完全不同的方向，导致质检永远不过。解决方法是给文案执行增加一个“创作纪律”：先在内部草稿区列出三个方向的大纲，再基于大纲写正文，不许中途重写整段逻辑。第二，需求分析师经常把“客户要求”和“自己的建议”混在一起，导致后续每个环节都被带偏。解决方法是在输出schema里增加一个“建议与需求分离”字段，把客户原话原样记录到original_statements里，规则建议放到另一栏。第三，视觉顾问和文案执行有时会互相“抄作业”：视觉顾问写了一段文案方向，文案执行又给了视觉建议。为了切断这种互相越界，我在工作流里强制规定它们之间不直接通信，所有信息都要通过策略锚定文档间接传递。

第四，质检员全凭模型主观判断，标准不稳定。我后来把质检规则做成了可配置的checklist，每个检查项单独打分，低于某个阈值就不过。例如“核心卖点是否在文案中直接出现”、“语气是否符合需求卡片的tone字段”、“字数是否落在指定范围内”，这三项是硬指标。第五，模型返回的JSON偶尔会非法，导致状态机崩溃。这个问题可以通过在每次调用后增加一个重试机制，当解析失败时把错误信息回传给同一agent并强制要求修正输出格式，而不是直接让整个流程失败。

5.2 成本控制：从Token浪费到精准调用

多agent系统的成本其实很容易失控。最开始我把每个agent的上下文都设成无限长，结果每次后续调用都要带上前面所有轮次的完整记录，一次任务跑下来能耗费几万个Token。后来我做了两个优化。

第一，给每个agent限定一个max_context_tokens，其中历史的“公共信息”只保留最近一次关键输出，而不是所有输出。具体来说，我的流程控制器维护了一个“摘要层”：每当一个环节结束后，会生成一份四到五句话的摘要，后续agent只读摘要和当前阶段的结构化输出，不读上一环的完整对白。

第二，针对文案生成这种高消耗环节，我引入了“先生成大纲，再扩写正文”的两步策略。文案执行首先只输出每个版本的要点和大纲，经策略锚定文档确认后，才针对被选中的大纲扩写完整文案。这个过程虽然增加了一次场景调用，但因为即使被否掉，其余大纲也不会扩充，整体Token消耗反而下降了近三成。

5.3 效果评估与后续扩展

我对这套系统的效果评估，不单看最终交付物过没过质检，还会记录几个维度：返工次数、未知需求数量、模型自我否定频率、平均单次任务成本。我给自己定了一个量化目标：三个月内把平均返工次数从1.8降到0.7以下，把单次简单需求的成本控制在普通模型直接生成方案的60%以下。

目前来看这两项已经基本达成。下一步我想做几个方向的扩展：一是增加一个“用户反馈学习层”，把每次人工修改的内容记录下来，定期生成一份修改流水线投喂给需求分析师的提示词，让它慢慢熟悉自己常漏掉的点；二是把多agent协作从“线性流水线”改成“多分支并行”，例如在策略锚定阶段同时让两个不同风格偏好设定的agent输出策略，最后由策略决策agent做选择。

最后再分享一个实用技巧

如果你也想尝试搭建类似的agent协作系统，我强烈建议不要把第一步的目标设得太宏大。先拿一个你手头最熟悉的业务场景，比如“写一次活动方案”或者“做一份演示文稿大纲”，定义好三个角色就够：需求整理、内容生成、质量检查。跑通一条极简流水线，后续再慢慢加角色，比如加一个“舆情分析”或者“竞争对手信息补充”。在这个过程中你会明显感受到，每个新的agent不是让系统变复杂，而是让每个环节的“人设”更清晰、更不会越界。

另一个从实际中得来的经验是：每次运行完，记得把关键日志导成文本文件存起来。这个习惯对排查问题帮助极大。当某个agent连续三次都给出了重复内容或者自我否定时，日志里的温度、概率值、提示词版本都会成为定位问题的重要线索。我自己的做法是把每一次运行的prompt、输出、校验结果都按日期存进一个单独的目录，丢不了，也方便回放。这个习惯让“调优”这个听起来很虚的词，变成了每天晚上都能做的具体事情。