企业官网建设流程全解析

最近接了个有点特殊的活儿：需要让AI自动完成一整套案头工作——先做某行业的竞品调研，再提炼市场洞察，然后生成一套短视频运营策略，最后还要产出几版可用的内容初稿。单靠一个大模型接口去硬跑，效果一言难尽，要么前半段还行后半段开始瞎编，要么调研结果和策略结论完全对不上。折腾了一圈之后，我把这套流程拆成了多个各司其职的Agent，模仿“代理机构”里不同岗位协同运转的方式，组了一套多Agent协作系统。项目代号就叫Agency Agents。

这套思路本质上就是把AI从“一个超级实习生”变成“一整支线上代理团队”。每个Agent只负责一个环节、只掌握自己需要的工具和信息，通过结构化的中间产物互相传递成果，最后拼装出完整的交付物。实测下来，整体质量比单Agent硬扛提升了不止一个档次，而且每个环节都可审计、可干预、可单独调优。这篇文章就把这套系统的设计思路、角色拆解、实操过程和踩坑实录完整写出来，给正在做多Agent协作或者想用AI跑复杂工作流的同学一个可复现的参考。

1. 为什么要拼一支AI代理团队

先说清楚一个问题：单纯把复杂任务扔给一个大模型，为什么不靠谱。

1.1 单Agent硬扛复杂任务的三个死穴

第一个死穴是上下文冲突。一个长链条任务里，前置信息（比如调研数据）和后续任务（比如写策略方案）往往需要不同的语气、格式和关注重点。你让同一个模型既要“严谨客观地引用数据”，又要“天马行空地提创意”，这两个指令糅在同一个系统提示词里，模型很容易精神分裂。我试过把调研和创作塞给同一个Agent，结果调研部分写得很飘、创作部分又过于保守，两头都不讨好。

第二个死穴是工具负担。复杂任务通常需要检索、计算、读写文件、调外部API这些能力。如果所有工具都挂在一个Agent身上，意味着每次请求都要把所有工具的定义和参数说明塞进上下文，token消耗巨大，而且模型在频繁的工具选择中非常容易出错，经常该调用计算器的时候跑去搜网页，或者干脆自己瞎编一个数字。

第三个死穴是异常定位困难。单Agent跑一个二十步的任务，一旦中间某一步的结果不对，你很难判断到底是哪一步出了问题、是prompt的问题还是工具返回的问题。如果是多Agent协作，每个Agent的输出就是独立产物，哪一步质量不行直接单独重跑，排查成本低得多。

1.2 把Agent当人看：外包机构式协作模型

我长期做内容项目，对这种场景太熟了：一个需求进来，项目经理拆任务，研究员收集资料，策略分析师定方向，文案执行产出，最后还要有质检员审一遍。每个人各管一段，用文档交接，谁都不需要掌握全流程的细节。

如果把这个协作模型平移到Agent体系里，就形成了agency-agents的核心框架。每个Agent扮演一个“岗位”，它有明确的职责描述、知道自己该读什么信息、产出什么格式的结果、交接给哪个下游。整个系统不再是一个全能的“超级实习生”，而是一个各司其职的“线上代理机构”。

这带来的直接好处是：单个Agent的prompt可以写得极其聚焦，上下文压力小，工具数量少而精准，模型能达到的上限更高。同时，流程中任何一个环节都可以插入人的审查，就像真实工作中总监要review下属的方案一样。

1.3 先定规矩再谈智能：契约式流程编排

多Agent协作有两种主流路线：一种是无中心的自由协商，Agent们像聊天一样你一句我一句把任务讨论完，灵活但不可控；另一种是契约式的流水线编排，任务被严格拆成几个阶段，每个阶段有明确的输入、输出和验收标准，Agent之间的交接靠结构化的数据包完成。

我的建议是，第一版方案一定要选择契约式流水线。原因很简单：自由协商一定会带来token成本的不可控和结果的不可复现性，Debug的时候想复现一个问题都难。契约式流水线虽然看起来“没那么智能”，但它可观测、可回滚、可优化。你完全可以在跑通流水线之后，在某个环节内引入多Agent讨论机制，把“局部智能”和“全局可控”结合起来。

2. 角色拆解和核心机制解析

这套系统的设计核心不是代码本身，而是角色和协作机制。代码谁都会写，但角色定义不清晰、交接协议不统一，系统跑起来就是一锅粥。

2.1 五类角色的职责与边界

我最终沉淀下来的一套基础角色配置是五类，覆盖了绝大多数“案头类”任务：

这里最关键的一步是给每个角色写清楚“角色卡片”，包括：

• 角色名称和一句话定位。
• 必须遵守的行为规范，例如“调研员只输出事实，不输出观点”。
• 输入规范：它在上游拿到的数据结构长什么样。
• 输出规范：它产出的中间产物格式，字段怎么定义。
• 退出条件：什么时候可以判定自己完成了任务。
• 边界与禁忌：例如“撰稿人不得自行修改调研数据，遇到疑问提交问题清单”。

我一开始没写边界与禁忌，结果出现过调研员自己下结论、撰稿人顺手改数据的情况。写清楚边界之后，系统的“职业感”立刻出来了。

2.2 工具绑定与权限隔离

每个Agent不应该拥有全套工具。比如调研员需要搜索引擎和爬虫，分析师需要数据计算工具，撰稿人需要文档工具，质检员需要文本对比和风格检查工具。工具全绑定的后果是模型选择困难、攻击面大、上下文膨胀。我在系统里给每个角色配了一个工具白名单，只有角色卡片里声明了“可调用工具X”的Agent才能调用它。

实践中有个细节：尽量给工具设置“一级准入限制”，比如把内部知识库或外部API的权限与角色绑定，通过工具函数名做前缀匹配。这样就算模型出现幻觉或者被恶意提示词注入，也只能在允许的工具范围内操作，不会把整个后台泄露出去。

2.3 中间产物标准化：Agent之间说话要有格式

多Agent系统最容易翻车的地方是Agent之间的“沟通”。如果你允许Agent用自然语言自由交流，听起来很灵活，但实际上传递的信息会在一次次转述中变形、遗漏。我采用的方案是：所有Agent之间必须通过结构化数据包通信。

一个典型的中间产物数据包大概长这样：

from dataclasses import dataclass, field from typing import List, Optional @dataclass class ResearchNote: """调研笔记的标准化结构""" topic: str # 调研主题 source_url: str # 信息来源 source_reliability: float # 信源可信度 0-1 key_points: List[str] # 关键事实点 quotes: Optional[str] = None # 可引用的原文片段 confidence: float = 0.8 # 模型对该信息的置信度 tags: List[str] = field(default_factory=list) # 标签便于下游检索 @dataclass class StrategyPoint: """策略要点的标准化结构""" insight: str # 核心洞察 evidence: List[str] # 支撑证据（引用ResearchNote.topic） recommendation: str # 可执行的建议 priority: int # 优先级 1-5 risks: List[str] = field(default_factory=list) # 风险点

要求每个Agent的输出都符合对应的dataclass结构，下游Agent直接读取字段，而不是去“理解”一段自然语言。这套“结构化中间产物”机制是整个系统稳定运转的基石，强烈建议不要省掉。

2.4 上下文管理：别让Agent背着全量历史跑

在一开始的版本里，我天真地把所有Agent的历史对话都拼进下一个Agent的上下文。结果跑了几个任务之后，token开销疯涨，而且每个Agent都带着一堆无关紧要的早期讨论开始干活，注意力被严重稀释。

后来我改成“增量传递+关键信息摘要”机制：每个Agent只接收上游的数据包字段，以及一个由Planner统一生成的任务快照（包含需求原文、当前环节目标、相关历史结论摘要）。需要完整历史记录时，再按需去存储里检索。这就像真实工作里，文案不需要看原始访谈录音，只需要看研究员的整理笔记和策略分析师的brief。

3. 实操：从一个真实任务看全流程运转

理论说了不少，直接看一个我们跑通的实际场景。任务需求是：“给某本地生活品牌的短视频账号做一套月度运营策略，包含竞品分析、内容方向和三条选题脚本初稿。”项目代号模拟项目X，整个流程跑下来大概耗时十分钟，中间经历了两轮人工干预。

3.1 第一步：Planner拆解需求

Planner拿到需求后要做几件事：识别任务类型（这是一个“策略方案+内容产出”复合型任务），拆解成调研、分析、创作、质检四个阶段，并明确每阶段的验收标准。Planner输出的任务清单是一个JSON结构：

{ "task_id": "sim-proj-x-march", "overall_goal": "产出某本地生活品牌短视频月度运营策略", "stages": [ { "stage_name": "research", "agent_role": "researcher", "input_requirements": ["目标品类", "主要竞品账号列表"], "output_schema": "ResearchNoteList", "acceptance_criteria": ["每个竞品至少3条信息", "来源必须标注", "可信度低于0.6的信息需单独列明"] }, { "stage_name": "analysis", "agent_role": "analyst", "input_requirements": ["ResearchNoteList"], "output_schema": "StrategyPointList", "acceptance_criteria": ["策略点必须引用调研证据", "至少包含5个可落地的洞察"] }, { "stage_name": "writing", "agent_role": "writer", "input_requirements": ["StrategyPointList"], "output_schema": "DraftScriptList", "acceptance_criteria": ["每个脚本包含开场钩子、核心内容、行动号召", "风格与品牌调性一致"] }, { "stage_name": "review", "agent_role": "editor", "input_requirements": ["DraftScriptList", "StrategyPointList", "ResearchNoteList"], "output_schema": "ReviewReport", "acceptance_criteria": ["核查事实与数据来源一致性", "标注风格问题和修改建议"] } ] }

任务清单本身就是一种“执行契约”，后续每个Agent都是参照它来理解和动手的。如果项目目标变化，直接在任务清单上改字段，系统能很快重新对齐。

3.2 第二步：调研员的筛选与去重逻辑

调研员是全流程里最容易出幺蛾子的角色，因为搜到的信息质量参差不齐。我在调研员的指令里明确要求：优先采用高可信度信源，比如官方发布、行业头部媒体、一手访谈；凡是来自论坛、贴吧和低权威自媒体的信息，必须单列到“待核验”列表，并附上可信度评分。同时，调研员要对重复信息做去重合并，避免下游被同一信息反复轰炸。

这一轮模拟项目X的调研共收集了12个来源，其中7条进入正式笔记，5条进入待核验列表。我看了一眼待核验列表，基本都是某些账号自己发布的“爆款方法论”，没有数据支撑，可信度评分都偏低，便让调研员直接丢弃，不进入下游环节。

这里有一个值得注意的细节：一定要让调研员输出原始来源链接，而不是转述性的“某平台上的一个说法”。转述信息一旦离开来源，后续的事实核查就要多花几倍时间。

3.3 第三步：分析师的提炼与交叉验证

分析师拿到的不是原始调研笔记，而是经过整理的结构化ResearchNote列表。它要做的事情是：把信息按主题归类，寻找不同信源之间的交叉印证关系，排除单点孤证，最终生成策略要点。

在模拟项目X中，分析师输出了一条关键洞察：某竞品的爆款内容普遍采用“本地商户真实探店”视角，且发布时间集中在周末上午。这条洞察同时引用了三条不同来源的调研笔记，结论可信度较高。但分析师也标记了一个风险点：样本量有限，关于发布时间的结论可能只适用于当前季节，建议在策略执行阶段做A/B验证。

这一步的实操心得是：分析师一定要输出“证据链”，也就是每条洞察后面明确写出支撑它的证据来源ID。这能大幅降低后续编辑部的核查工作量，也让整个策略方案的论证链条更加透明。如果分析师的洞察没有证据支持，我一般会直接打回重写，因为经验表明孤证型洞察在真实场景中大概率站不住脚。

3.4 第四步：撰稿人的创作约束

撰稿人看起来是最“自由”的角色，但实际上创作类Agent的约束最多。我在角色卡片里给撰稿人定了三条硬性约束：

第一，所有事实性表述必须与分析师提供的策略要点保持严格一致，不许自行补充数据，更不许改数据；第二，脚本结构要遵循固定的框架（钩子、冲突或情绪点、内容价值、行动引导），框架内可以发挥创意，框架外不能自由发挥；第三，用词风格要匹配品牌调性词表，禁止出现调性词表之外的夸张用语，比如“最便宜”“百分百有效”这类。

三条约束其实都来自真实踩坑。之前有一次撰稿人自作主张在策略方案里加了一条“根据市场调研，用户的平均接受度是95%”，结果上查原始调研数据根本没有出处，导致整份方案被客户打回来返工。从那时起，创作类Agent输出里凡是涉及数字和断言的地方，我都在指令里要求它要么引用证据ID、要么明确标注“此为建议性假设”。

最终撰稿人产出了三条选题脚本初稿，其中两条是直接命中策略洞察的，一条是尝试突破的新视角。整体结构完整，事实性表述都正确引用了证据ID，只有一处情绪表达略为夸张，被质检环节拦了下来。

3.5 第五步：质检员的价值远超预期

质检员是整条流水线里最容易被视为“多余”的角色，但实际上它的价值非常高。它主要做三件事：逐条核对事实和数据来源，检查内容风格是否与品牌调性一致，判断内容是否有效落实了策略要点。

在模拟项目X的交付中，质检员抓出了两个问题。一个是致命伤：某条脚本中的“探店视频平均完播率提升30%”这个说法，在调研数据里根本没有直接支撑，疑似撰稿人根据行业经验做了外推，质检员要求必须删除或补充证据。另一个是风格问题：脚本的开头钩子用了“家人们”这种过于网感的表达，与品牌偏沉稳的调性不符合，质检员给出了平替文案。这两个问题如果不拦截，内容直接交付，又得重做。

质检员不仅要列问题，还要给修改建议，而不是简单地“打回重跑”。如果只是打回，下游撰稿人不一定理解哪里错了；给出具体建议，返工的效率和准确率都明显提升。从这之后，我把“修改建议”写进了质检员角色的输出规范。

3.6 参数选择与模型分工

不同角色我用了不同的模型配置和参数策略。调研员对检索准确率要求高，温度设最低档，基本不发挥创造性，重点是忠实整理；分析师希望它能在信息中找到隐藏关联，温度适中，允许一定的跳跃性推测，但必须在输出中标记推测项；撰稿人需要内容新鲜感和语言表现力，温度偏高，同时打开“长文本生成”相关的增强参数；质检员需要严格的判别能力，温度设置很低，输出风格偏“挑毛病”，要求每次输出都要附带违规片段和修改建议。

参数方面有一个容易被忽略的坑：上下文窗口并不是越大越好。窗口大了，模型确实能记住更多内容，但也更容易在庞杂信息中迷失重点，响应延迟和成本也会明显增加。我实测下来，对于调研和质检这类聚焦型任务，4k到8k的上下文窗口足够；反而是需要长文本连贯性的创作任务，可以给到16k以上。如果你不做这些区分，一股脑给所有Agent开大窗口，实际效果反而是负向的。

4. 常见问题与排查技巧实录

这套系统上线后不是一帆风顺的，前前后后修了不少问题。下面把几个最容易遇到的坑和排障思路整理出来。

4.1 问题一：Agent之间陷入死循环

现象是调研员和分析师反复交换意见，互相补充信息，任务执行了几十轮还没有输出最终结论。定位方法是在调度层给每个Agent的执行次数设置预算上限，比如某个阶段最多执行3轮，超过后强制终止并转入人工review。同时，在契约里明确“每个Agent的退出条件”，比如调研员完成一次完整的检索循环后必须输出成果，不允许“补充调研”式的无限自我延伸。

实操心法：多Agent系统里的很多“死循环”不是bug，是任务定义不清晰的必然结果。上游的验收标准写得太含糊，或者中间产物格式没定死，下游就会陷入怎么改都不对、于是不断返工的状态。先看循环发生在哪两个角色之间，再返回去检查上游的验收标准是否可度量，问题通常立刻明了。

4.2 问题二：错误信息在流水线中被放大

调研员收集了一条错误数据，分析师基于它给出了一条看起来很合理的洞察，撰稿人再把这条洞察包装成一个铿锵有力的结论，整个链条下来，错误信息已经从“可疑”变成了“可信”。这个问题在多Agent系统里非常危险，因为每一步的处理都会让信息变得更精炼、更权威，错误也被同步放大。

解决思路是双路并行：在关键环节设置事实核查点，比如分析师输出中的每条洞察必须引用ResearchNote的证据ID，质检员职责里必须包含“源数据比对”这一项；同时，每个数据包都带上置信度字段，低于阈值的结论会在下游自动被打标“待核验”，撰稿人看到这个标签时就不得把它写进最终交付物，只能作为内部参考。

4.3 问题三：上下文爆炸与信息遗忘

任务链太长时，早期调研的信息会在后续环节中逐渐失真，甚至被后续Agent遗忘。我前面提到的“增量传递+关键信息摘要”机制就是专门处理这个问题的。实际操作上，Planner会在任务推进过程中定期生成一个“全局记忆摘要”，把已经确认的结论和关键数据汇总成几百字的结构化文本，随任务清单一起往下传。后续Agent不需要读全量历史，只看摘要和自身上游的数据包。

这个思路和人类协作完全一致——项目总监不会把每天所有邮件都转发给新加入的同事，而只会给一份简报加上相关附件。这样可以有效控制token开支，还能显著提升信息传递的准确率。

4.4 问题四：角色漂移，Agent开始干别人的活儿

有时候角色定义不够严格，Agent会自动“越权”。比如调研员在笔记里直接写了“建议采用A策略”，分析师在洞察里开始组织语言写文案，这些都是角色漂移的表现。角色漂移的危害在于：职责边界模糊后，中间产物的结构会悄悄变样，导致下游解析失败，或者信息形态不符合预期。

我一般通过三个手段来治理：一是在角色卡片里明确“禁止”事项，调研员不得输出建议、撰稿人不得修改数据；二是在每个Agent输出环节做一个格式校验，不符合数据包结构的一律拦截，报错提示为“输出异常”；三是给每个Agent加一个阶段自评环节，输出前先对照自己的角色卡片检查一遍。自评环节看似额外消耗一步，但它能有效减少因角色漂移导致的下游返工，总体成本反而是降低的。

4.5 常见问题速查表

5. 几点收尾心得

项目跑到现在，最大的体会就是：多Agent系统的瓶颈往往不在模型能力，而在协作治理。

第一个心得是别一上来就追求“全自主”。把流程先做成可控的流水线，每个环节都有人工插手的接口，跑顺了再逐步放开自主度。业务流程先规范，再到Agent流程，这个顺序不能反。与其花大量时间调一套“Agent自由协商”的机制，不如先把中间产物的标准定清楚，收益立竿见影。

第二个心得是Agent的指令设计比模型选择更影响最终效果。一个任务让最强的模型但prompt混乱地去跑，效果大概率不如一个普通模型配上一张清晰的角色卡片。角色卡片的价值就是让模型知道自己在什么位置、该拿什么、该给什么，以及什么绝对不能碰。

第三个心得是这套模式远不限于内容生产。只要任务可以拆成“收集信息、形成策略、执行产出、质量校验”这几个环节，不管是活动策划、行业研究、程序化文案投放还是运营策略，agency-agents这套架子都能套用。后续我打算在系统里新增一个反馈环：让质检员发现的错误能回溯到对应环节，驱动角色卡片的自动修正，把一次性项目迭代成一台能自我进化的线上代理机构。