企业官网建设流程全解析

先说结论：如果把大模型当成一个“什么都会一点，但什么都不精”的全能选手，那agency-agents这个项目要解决的，就是把这一个全能选手拆成一堆“单科专精”的专家，然后让专家们像真实公司一样分工协作。我最近用这套思路做了一个模拟项目X，把内容产出、竞品分析、数据整理、初稿润色这些原本需要三个人干的活，压缩成了一条全自动流水线。这篇文章把整个设计思路、实操细节、踩过的坑都整理出来，包含可直接抄走的角色定义模板、任务交接机制和上下文管理方案。

1. 项目整体设计思路与角色拆解

1.1 为什么需要“Agent团队”而不是一个超级Agent

很多人刚开始接触智能体的时候，都有同一个疑问：既然大模型上下文窗口越来越大，能力也越来越强，为什么还要搞出多个Agent来协作？直接在提示词里把所有要求写清楚，让模型一个人多角色扮演不就行了？

我用自己的实际经历回答这个问题：单Agent模式在任务比较简单的时候确实够用，比如写一封邮件、总结一篇文章，效果都还不错。但一旦任务变成“从竞品文档里提取卖点，结合用户评论生成一份推广文案，再根据几个不同平台的格式要求输出三个版本”，单Agent就开始顾此失彼。原因在于，大模型在长对话里很容易发生“角色漂移”——刚开始还是文案专家，写了几轮之后就开始越界去处理数据问题，或者忘记自己最开始被指定的专业视角。更麻烦的是，一个人在又当运动员又当裁判的情况下，缺乏客观的校验机制，错误会在最终输出里沉淀下来。

多Agent设计的核心价值不是“用更多模型token”，而是把复杂任务拆小，让每个Agent只处理自己最擅长的部分，同时用“上下游交接”的方式自然形成质量关卡。我用一个生活化的类比：真正的内容团队从来不是让一个人从头跟到尾，而是策划、撰稿、校对、排版各司其职。每一环都在前一轮结果上做加法或修正，最终交付物质量远高于一个人单干。

1.2 角色岗位的设定原则与边界划分

设计Agent团队的第一步，也是最关键的一步，是定义清楚“团队里都有谁”。在agency-agents这个项目里，我最早踩的坑就是角色设得太多太细，结果光是Agent之间的沟通开销就把收益吃掉了。后来我总结出一个非常实用的原则：一个Agent只对一种产出负责，且该产出有明确的“完成标准”。

以我这次实现的模拟项目X为例，最终保留了五个角色：

这个岗位设计背后有几条很重要的边界原则。第一，上游为下游服务，下游对上游负责。策略分析师不用关心最终文字的段落在某个平台上会不会被折叠，发布运营也不用替主笔作者重写整篇内容，每个人只关心自己这层要交付什么。第二，允许角色之间有信息差。意思是说，研究员看到的是资料和数据，不需要了解用户的完整需求背景；而主笔作者拿到的已经是经过整理的资料包，也不需要知道研究员是从哪几个网站找到的。这种信息隔离虽然看起来“浪费”了一些上下文窗口，但能最大程度避免无关信息干扰当前角色的判断。

1.3 任务链与“人类介入点”的设计

多Agent系统如果做成完全自动的黑盒，实操中会非常危险——你不知道哪一环出了问题，也不知道中间结果长什么样。所以在最初的架构设计里，我就定了一个铁律：每个Agent完成自己的交付物之后，必须暂停并输出一个结构化的“交接单”，而不是直接传给下一个Agent继续跑。这样设计有双重好处：程序上可以随时挂起供人工检查，逻辑上则强制每个Agent给出“我做了什么、我的结论是什么、我有什么不确定的点”。

这个设计后来被证明是整套系统里最值当的投入。因为我测试过程中发现，某个细分领域的研究资料里混入了几条明显的营销软文，研究员Agent没识别出来，直接当成了事实数据写进资料包。如果在全自动链路里，主笔作者会毫无防备地把这些错误信息写进初稿，最后审校再放松一点，垃圾内容就发出去了。而有了中间交接点，我只花了十秒钟扫了一眼研究员输出的来源清单，就发现问题并及时拦截了。

2. 核心机制：上下文、记忆与协作协议

2.1 Agent间直接通信与任务看板的取舍

多Agent协作最常见的两种模式，一种是Agent之间直接对话，把对方当成队友，你来我往多轮交流；另一种是大家都在一个共享“任务看板”上读写消息，自己不直接说话，只更新自己负责的那部分内容。我在agency-agents里特意选了后者，或者说以后者为主、前者为辅。

直接对话模式的优点是灵活，Agent可以边做边问，但同时缺点非常明显：第一，多轮对话消耗的token数量成倍增长，成本不可控；第二，Agent之间聊着聊着就容易“跑偏成社交场面话”而非有效协作，你要花很多算力才能把它们拉回正题。共享任务看板则更接近真实公司里的“文档协作”逻辑——每个人写自己的部分，下游自己来取。这个模式更稳健，也更容易调试，因为你可以在任意时刻把看板内容完整打印出来，检查每个环节都发生了什么。

我在具体工程实现上做了一个非常轻量的消息队列：用一个JSON文件充当看板，每个Agent启动时读取看板上的任务状态，完成后把自己的产出写入“deliverables”字段，并更新任务状态。没有引入消息总线或者持久化数据库，因为对这个量级的个人项目来说，文件和字典结构已经足够。如果未来要做并发或者横向扩展，再考虑上正式的队列中间件。

2.2 每个Agent的“私密记忆”与“共享记忆”

用多Agent协作的时候，一个绕不开的问题是Agent之间有没有记忆，记忆是共享的还是私有的。你当然可以粗暴地把对话历史全部传给每个Agent，但那样子上下文很快就会被撑爆，而且大量冗余信息反而会稀释模型对关键指令的注意力。

我采用的是“轻量级共享记忆 + 深度私有记忆”的双层结构。所谓共享记忆，是一个只包含任务目标、已完成的交接单摘要、当前进度状态的全局变量。每个Agent启动时先读取这个共享区块，理解自己处在整个流水线的什么位置，但不需要看到其他Agent全部的历史贡献。所谓私有记忆，就是每个Agent自己在自己的对话上下文里保留本轮全部工作记录。比如研究员会记住自己查过哪些资料、筛选过哪些信息源、为什么排除某些内容，但这些细节不会传给下游。

这么做背后的逻辑是：下游需要的是“结论”而不是“过程”。主笔作者拿到的是“资料包包含A、B、C三个事实，来源标注完整”，他不需要知道研究员是先搜了关键词一还是关键词二。信息针对性越强，模型生成时的注意力就越集中，输出质量就越稳定。这是在几次“主笔输出被冗长检索日志带偏”之后总结出来的教训。

2.3 角色切换时的格式协议与交接规范

多Agent系统里最不值得踩但最多人踩的坑，就是交接格式不统一。第一个Agent输出一段散文式总结，第二个Agent想要结构化数据还得自己再解析一遍，费时费力还容易出错。我在项目早期就定下了“强制结构化交接”的规矩，宁可每个环节多花几个token，也要保证交接内容字段清晰、类型明确。

我设计的交接单包含统一格式：

{ "agent": "研究员", "status": "completed", "deliverable_type": "research_pack", "summary": "一句话总结核心发现", "deliverable": { "key_facts": ["事实1，含来源", "事实2，含来源"], "risk_notes": ["信息不确定处，需要主笔注意"], "source_count": 12 } }

这个字段结构其实是一种“软约束”，我用提示词要求模型必须按这个JSON格式输出，同时在代码侧做了简易的解析校验，解析失败就直接重试。强制结构化带来的收益非常直接：主笔作者读交接单的时候，模型不需要在长文本里“寻找重点”，而是直接根据字段名定位到需要的内容，生成初稿的准确率显著提升。后来我又把提示词里的交接单格式改成几次迭代版本，加了“deliverable_type”字段来区分不同类型产出，便于程序根据产出类型走不同的后续分支处理。

3. 实操过程：从零搭建一个最小可用Agent团队

3.1 技术选型与成本预算

agency-agents这个项目在技术选型上没有做太多高大上的决策，核心思路就是“用最普通的工具，快速把链路跑通”。我使用的是Python作为主语言，因为生态最完善，处理JSON和调用大模型接口都方便。模型层面选择的是当前市面上两家主流商用大模型API，一个偏重推理深度，一个偏重写作自然度，分别用在不同环节。

具体的分配策略是：

整套流水线跑一个完整任务，费用大概是单次直接调用的4到6倍。这个数字听起来不低，但要注意，它替代的是三个人各自几小时的劳动。从单位成本来看，性价比依然很高。如果想压缩成本，最有效的方式就是减少重试次数、缩短中间过程中的无效对话轮次，这个后面在优化部分细说。

3.2 框架选择与核心代码结构

Agent编排我尝试过几种方案，最终没有依赖现成的重量级编排框架，而是写了一套非常薄的中控脚本。不是说那些框架不好，而是这个项目的关键逻辑在提示词设计和交接协议上，编排层只需要几十行代码就能搞定，引入重框架反而徒增学习成本和版本升级风险。

核心的中控逻辑核心很简单：

def run_pipeline(task_description): # 策略分析 strategy = run_agent("strategy_analyzer", task_description) # 深度研究 research_pack = run_agent("deep_researcher", strategy) # 主笔写作 draft = run_agent("lead_writer", research_pack) # 专业审校 final = run_agent("professional_editor", draft) # 发布运营 platform_versions = run_agent("publisher", final) return platform_versions def run_agent(agent_name, input_data): prompt = build_prompt(agent_name, input_data) response = call_llm(prompt) parsed = parse_response(response) # 校验失败则重试，最多3次 for attempt in range(3): if validate(parsed): break parsed = parse_response(call_llm(prompt + "注意：请严格按JSON格式输出")) return parsed

这段代码骨架的关键在于build_prompt函数，它会把每个Agent的系统提示词、当前输入数据、期望输出格式三层内容拼装起来。提示词质量直接决定整个项目成败，这个下面会专门讲。另外validate函数也别小看，它简单检查JSON字段是否存在、关键字段是否非空，这层防御避免了很多“看起来成功了实际没人干活”的假进度。

3.3 一个可以直接抄走的提示词模板

多Agent系统里提示词设计和单Agent应用有很大区别。核心差异在于，你不仅要告诉模型“你是谁、你要干什么”，还要告诉它“你的上游是谁、你从哪拿输入、你的输出给谁、对方期望什么格式”。我在反复调优之后，形成了一个固定模板：

你是一个[角色名]，负责[职责描述]。 上游交付物内容如下： [输入数据] 你的工作流程： 1. 先理解上游交付的核心结论 2. 基于你的专业视角进行处理 3. 输出结构化结果 输出格式要求（严格遵守）： [JSON格式描述] 质量红线： - 不要编造上游未提供的事实 - 遇到信息不足时，在risk_notes字段中说明 - 只输出JSON，不要任何多余解释

这套模板里有三个值得注意的设计点。第一是“先理解上游交付的核心结论”这个步骤，它引导模型不急着输出，而是先消化输入，减少“鸡同鸭讲”的概率。第二是“质量红线”部分，尤其是“不要编造上游未提供的事实”，在重视准确性的任务里作用是决定性的。第三是“只输出JSON，不要任何多余解释”，这是为了程序解析的稳定，避免模型情绪化地给你来一段“好的，根据你的要求，我已经完成了分析…”之类的废话。

3.4 完整流水线的运行记录

为了让你更直观地知道这套系统跑起来是什么样，我放一段实际运行的中间过程记录（脱敏后）。当时输入的任务是“为一款面向独立开发者的效率工具写一份详细的产品介绍，包含核心卖点和场景示例”。

策略分析师先跑了一轮，输出要点是“目标读者为独立开发者，强调节省时间、上手成本低、和现有工作流融合”，策略中场报告里还附了一个三段式内容骨架：痛点场景、解决方案、实操案例。随后深度研究员开始检索，检索聚焦在独立开发者的常用工具链、效率痛点讨论帖、同类产品对比评测三个方向。研究员标记了其中两个数据点置信度低，提醒主笔作者谨慎引用。主笔作者拿到资料包后，用了大约生成1200个单词的篇幅产出了初稿。我粗读了一遍，结构清晰，但是节奏偏慢，开头铺垫过长。

在这里我做了人工介入，给审校Agent加了一条额外指令“压缩开头内容，让核心价值主张出现的更早”。审校Agent在润色时把第一段删了一半，同时在第三部分补充了一个更具体的应用场景案例。最终发布运营按照博客平台和短内容平台两种场景分别适配，博客版本保留了完整结构和代码示例，短内容平台版本则提炼成五个要点加一句引导语。整个过程耗时约两分半钟，坐等出稿的体验确实很爽。

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

4.1 Agent任务执行陷入周期性循环

跑多Agent系统最让人崩溃的问题就是“同一个环节反复重试却始终得不到合格的输出”。我遇到过一个非常典型的场景：主笔作者生成初稿后，审校Agent每次都以“内容与上游资料包中的某个数据不一致”为由打回重写，而主笔重新生成后审校依然不满意，陷入死循环。

排查过程让我确认问题出在交接协议不明确上：审校Agent对“事实核查”的理解过于苛刻，连表述角度差异都算作事实冲突。解决办法是在审校Agent的系统提示词里加了一条边界约束：“只对硬事实错误（时间、数据、名称、引用含义）提出修改，表达层面的润色建议集中放在意见清单的最后一部分，不阻塞主笔的交付。”加完这条之后循环频率降了九成。这个问题的根源不完全是模型能力，更多是角色边界在提示词层面没有划清楚。

4.2 上下文窗口被中间产物“白白吃掉”

我曾经天真地让每个Agent都接收全量任务信息，觉得信息越多越安全。结果任务跑到第三个Agent的时候，上下文用量已经过半，后面的环节开始频繁出现“遗漏要求”的症状。后来我优化了参数，变成只传递当前必要的交接单和相关字段，上下文占用立刻降了七成。而且更妙的是，模型输出质量反而提升了，因为注意力更集中了。

这里有一个量化经验可以分享：如果任务的原始描述有800个token，你把它原封不动传个四五个Agent，光重复传递就烧掉几千个token。而用交接单结构，每个环节只需要传递关键结论和结构化数据，总量可以压缩到远低于原始描述的规模。省下来的上下文空间应该留给真正干活时需要的思考，而不是浪费在重复阅读背景信息上。

4.3 多Agent输出风格不一致的根源与对策

如果你发现流水线串联起来之后，最终交付物读起来“像两个人拼出来的”，大概率问题不在生成阶段，而在交接信息里缺少风格规范。我一开始也遇到过这个问题，主笔写得很放飞，审校又改得很保守，成品风格割裂。

解决方案是让更上游的Agent就输出“风格指令”，而不是让最终环节才开始约定风格。我在策略分析师的交付物里增加了一个字段叫“style_guide”，内容是“语气要求、句式偏好、禁用词清单、术语表”。下游每个Agent的提示词里都强制引用这些内容，最终成品的风格一致性显著提升。这个调整的另一个附带好处是，如果你要批量生成系列内容，只要在策略分析环节提供一套固定风格指令，就能在整个生产周期里保持统一调性。

4.4 一个速查表：最常见的五个问题

最后整理一个速查表，覆盖我在调试这个项目时遇到的高频问题和对应解法：

5. 从项目中沉淀下来的几点实践经验

做了几次完整的多Agent流水线之后，我对这类系统的理解比最初设想要深很多。第一个体会是，多Agent系统的设计核心始终是“信息架构”而不是“模型能力”。很多人以为换个更强的模型就能解决一切问题，但实际上，把什么信息在什么环节用什么结构传给谁，才是决定系统上限的钥匙。同样的模型组合，交接方式不同，效果可以差出好几倍。

第二个体会是，人工介入点不是偷懒，而是系统质量的稳定器。我最初也追求过全自动零人工，后来发现，在关键决策节点上留一个“快速看一眼”的机会，反而让整个系统的可维护性大幅提升。这些介入点就像质检工位，不需要每次都动手改东西，但它们的“存在本身”就足以防止错误一路畅通地流到终点。

第三个体会非常务实：这类系统的调试思路，和传统程序很不一样。传统程序报错，是逻辑问题；而Agent系统出错，往往是因为提示词给模型的“发挥空间”太大或者太小。所以我在后续迭代中养成习惯，每次出问题先问自己“这个错误是不是因为边界没划清楚导致的”，而不是急着去改代码逻辑。

至于后续扩展方向，我觉得有两个方向很有潜力。一个方向是把现在的线性流水线改造成带分支的——比如某些任务根本不需要研究员参与，直接由主笔接手，缩短链路、节省成本。另一个方向是给Agent团队加入“外部反馈闭环”，让最终成品的读者数据回流到策略分析师，形成一个自我进化的体系。这两个方向都需要在前面这套基础架构上做增量改动，但核心的交接规范和角色定义原则是通用的。我后续如果继续迭代这个项目，会优先在这两个方向上做尝试。