企业官网建设流程全解析

最近在折腾 openclaw 的多智能体编排，把“内容工厂”这个用例的翻译笔记整理了一遍。说白了，就是用一套多智能体系统，把从选题、写作、配图到发布的整个内容生产流程拆成流水线，让不同的智能体各管一段，协同产出一篇篇完整可用的内容。我实际跑通了几条流水线之后，最大的感触是：这个场景比想象中更适合多智能体入场，而且它的设计思路一旦吃透，套用到别的自动化场景里也基本是通的。

这套东西适合谁？一类是内容团队的运营或技术负责人，想用更低成本拉升产量；另一类是已经在用大模型 API 写内容但觉得单次生成质量不稳、需要反复人工改稿的人。如果你只是偶尔写一篇文章、不想搭流程，那没必要上多智能体，单次调用模型就够了。但只要你的内容量到了每天 10 篇以上，或者内容要分栏目、分风格、分渠道去维护，那“工厂化”和这里面的编排思路就非常值得参考。

1. 内容工厂的整体设计与思路拆解

1.1 为什么内容生产需要“工厂化”

内容生产的重复性很高，而且不同环节的目标其实互相冲突。写初稿的时候，要求发散、丰富、快；审校的时候，要求收敛、准确、挑毛病。这两个目标如果塞给同一个模型、同一个 Prompt，结果通常很尴尬——要么初稿太拘谨，要么审校太宽松。

为什么要用多智能体？因为可以把“发散”和“收敛”拆开，用不同的角色、不同的模型参数去对应不同的环节。

我在搭建这套内容工厂时，主要是基于 openclaw 的工作流引擎来串联智能体。openclaw 本身负责托管智能体实例、维护消息队列、把每个智能体的输入输出衔接起来。每个智能体有独立的身份定义、上下文窗口以及模型配置，互不干扰，同时通过事件总线交换任务和产物。

多智能体的意义不是“多个模型一起生成同一篇文章”，而是把一个复杂任务纵向切分成多个阶段，每个阶段由专门的智能体负责。就像真实编辑部里，主编定方向、记者写初稿、编辑改稿、质检员查错。每个岗位有自己的标准和背景知识，通过明确的交接物协作，而不是大家一起写一行字。

对比单智能体方案，多智能体的核心优势有两个：一是质量稳定，因为每个环节的评判标准被锁在了 Prompt 和流程里，而不是靠一次生成“碰运气”；二是可扩展，想加一个风格检查智能体，不需要重写整个流程，只需要在编排器里加一个节点。

1.2 多智能体架构的选型思路

选 openclaw 这套架构，我主要考虑了三层：任务类型、智能体间的关系、以及异常处理的复杂度。

先说任务类型。内容工厂的任务是典型的分段流水线式任务，上游产出是下游的输入。这种任务非常适合用“管道模式”编排，而不是“黑板模式”或“辩论模式”。前者更可控，后者适合开放探索型任务，但对内容产量和稳定交付来说太不可控。

再说智能体间的关系。我一开始尝试过让所有智能体共享同一个上下文池，结果发现根本没法控制。一个智能体改了一轮内容，另一个智能体的上下文就跟着变了，互相污染。后来才把上下文彻底隔离，智能体之间只通过标准化的消息结构传东西。这个经验后面还会细说。

openclaw 的编排方式是基于事件驱动的工作流。我定义好一个 DAG（有向无环图），每个节点是一个智能体，节点之间通过事件触发。一个智能体完成输出后，发布一个事件，编排器收到事件后，根据路由规则把数据交给下一个节点。

这套设计的核心是“解耦”。每个智能体不直接调用下一个智能体，而是把自己的产物放进消息池里，由编排器决定下一步。好处是，我可以随时替换任意一个节点——比如把某个栏目的审校智能体换成更严格一点的版本——而不影响上游智能体。

1.3 用例翻译笔记在整个项目中的角色

这个标题里的“用例翻译笔记”，我理解为一手实践记录：读 openclaw 官方用例文档的时候，把晦涩的配置逻辑用实际项目的语言重新阐述一遍，翻译成“我自己的话”。这很关键，因为 openclaw 的文档更偏重框架能力说明，不会告诉你某个配置在实际内容生产里到底会触发什么问题。

我在整理 Multi-Agent Content Factory 这个用例时，发现它的参考实现里用的是一组非常典型的角色分工，但在配置细节上有很多坑。比如角色的 system prompt 不能只用一句话定义，openclaw 在实例化智能体的时候会加载整套工具清单，如果 prompt 里声明的能力跟实际挂载的工具不匹配，智能体就会出现“纸上谈兵”的现象——嘴上说要调用某工具，实际根本没挂载。这种细节，光看官方文档很难意识到，只有自己配一遍、跑一遍，才会在失败日志里看到教训。

所以这篇笔记本质上就是把“官方用例”翻译成“可落地的工程实践”，把文档里一笔带过的地方全部展开，把容易踩坑的地方标记出来。

2. 核心智能体角色分解与协作逻辑

2.1 主编智能体：任务拆解与选题判断

主编智能体是整个流水线的第一环。它的职责不是自己写内容，而是接收一个宽泛的需求描述，把它拆成具体的“内容订单”。比如需求进来是“本周要 5 篇关于 AI 编程工具的文章，面向初级开发者”，主编智能体需要做的事是：

• 把 5 篇拆成具体的选题，并为每个选题设定目标读者、核心观点、参考素材范围、字数区间。
• 给每个选题打上栏目标签、风格标签、优先级。
• 把拆好的订单结构化成 JSON，发布到消息池。

这个环节里最关键的配置是模型选择与温度参数。我给主编智能体用的是偏低温度的模型（temperature 0.3 左右），因为它做的是结构化拆解，需要稳健，不需要发散。温度太高，方案就会飘，给出的选题清单里经常出现用户根本不关心的方向。

还有一个细节：主编智能体必须同时具备“读输入需求和写结构化订单”的能力。但注意，它不需要具备“写正文”的能力。我见过很多人在配置角色时，习惯性给每个智能体都赋予全量能力，结果就是每个智能体都想抢着写正文，流程反而乱。正确的做法是给主编智能体挂上读取输入文件的工具和输出 JSON 的工具，不挂文章生成长文本的能力，用工具边界约束它的行为范围。

2.2 内容生产智能体：初稿生成与多风格适配

生产智能体是流水线里最重的执行单元。我通常按栏目或内容风格配置多个生产智能体，比如一个面向技术教程风格、一个面向行业资讯风格、一个面向轻松吐槽风格。每个智能体共用一套写作流程，但 system prompt 里的风格约束完全不同。

生产智能体接收到主编订单后，要做的事包括：搜索内部素材库（挂载检索工具）、根据大纲写出初稿、在输出前做一次自检（章节是否齐全、是否存在明显重复内容）。它输出的是一个带 Markdown 结构的正文草稿，同时附带自己的写作日志和内容置信度评分。

这个环节最容易翻车的是“多步骤任务在一轮内完成”。openclaw 的智能体默认是单轮生成，如果让它一口气经历“检索素材、写大纲、写正文、自检”四步，它会在某个步骤后直接把输出截断。我在配置时把生产智能体的工作拆成两个子任务：先输出大纲，等大纲被审核通过后再输出正文。这里用了 openclaw 的“人工审批节点”，实际上是把人和机器混合编排进流程，而不是完全无人化。

2.3 审校智能体：质量门禁与修正建议

审校智能体是整个流水线里的质量闸门。它不直接改文章，而是返回“修改建议列表”。这里有个很容易犯的错误：让审校智能体直接输出修改后的全文。那样做会把审校智能体变成第二个写作智能体，而且一旦它改写能力不足，质量反而更不稳定。

让审校智能体输出结构化建议有几个好处：一是便于人工复核，二是便于生产智能体增量修改，三是每次审校结果都能沉淀为质量数据。我给审校智能体定义了一个输出 schema，包含问题类型（结构、事实、语法、风格）、问题定位（章节号/段落号）、严重程度、修改建议。生产智能体拿到这份建议后，再针对性地修补原文。

审校智能体的温度设置更低，我设的是 0.1 左右。同时它的系统提示里写明了评判标准和权限边界，比如“只评估事实准确性和逻辑连贯性，不负责重写”。

审校环节通常要跑两轮，一轮是事实与结构审校，一轮是风格与错别字审校。如果你把两轮合并到一个智能体里，它会因为上下文里塞的东西太多而顾此失彼，前半段还在挑事实错误，后半段就变成纠错别字了。拆成两个审校节点后，专业度和稳定性都明显提升。

2.4 路由编排器：状态机与消息流转

路由编排器是“工厂”里最重要的基础设施。它不做内容判断，只做状态流转。我基于 openclaw 的事件路由功能，定义了这条状态链：

draft -> review_fact -> review_style -> revision -> publish_check -> done

每个状态对应一个智能体节点。编排器把上一个节点的输出打包为用户消息，发送给下一个节点，并把节点返回的结果写入一个共享状态库。状态库用简单的 JSON 文档存储，每条记录对应一篇内容产品，记录它的当前状态、流转历史和各方产物。

为什么这么做？因为多智能体项目里最怕的是“智能体之间互相传话传不清楚”。如果让生产智能体直接给审校智能体发消息，两边一旦对消息格式理解不一致，整个流程就会卡住。编排器做中转，保证了中间消息格式的统一。

我在实践里把编排器的消息格式固定为三层结构：任务元信息（任务 ID、频道、优先级）、内容主体（当前版本全文）、流转历史（哪些节点处理过、每轮的产物和状态）。第一版我忘记加入流转历史，结果一旦文章被多次打回，新节点根本不知道它之前经历过什么，导致反复犯同类问题。加上了历史之后，审校智能体能够看到上一轮已经提过哪些建议，避免重复提。

3. 基于 openclaw 的完整实操：从配置到跑通

3.1 配置文件结构与环境准备

openclaw 的部署不复杂，核心是配置一个 agent registry 和一个 workflow definition。我在服务器上用的是 Docker Compose 方式，里面跑着 openclaw 服务端、一个 PostgreSQL 用于保存状态、以及一个 Redis 做事件消息的临时队列。

目录结构大致像这样：

project/ agents/ editor.yaml writer_tech.yaml writer_news.yaml reviewer_fact.yaml reviewer_style.yaml publisher.yaml workflows/ content_factory.yaml prompts/ editor_prompt.txt writer_prompt_base.txt ... outputs/ tasks/ articles/

每个 agent 的 YAML 文件里，核心字段是 name、model、prompt_file、tool_ids、temperature。我强烈建议在 agent 定义里显式声明 model 和 temperature，而不是用全局默认值。

内容工厂的 workflow 定义文件是整个项目的核心，它描述了节点的连接关系、事件触发条件和数据映射。我配置时最关注的是on_event字段，它决定一个节点完成后，下一个节点什么时候被触发。配置要点是：每个节点完成后必须发布一个明确的事件名，事件名用“任务类型+阶段”来命名，比如task.review_completed，不要用含糊的task.completed，否则路由条件会写得很痛苦。

3.2 配置智能体 Prompt 的几条经验

给内容工厂里每个智能体写 Prompt，是投入产出比最高的工作。我总结了几条经验，每条都是踩过坑之后换来的：

第一，角色定位要写“决策边界”，而不只是写“技能”。比如审校智能体的 prompt 里如果只有“你是资深编辑”，它就会觉得自己有权重写全文。我在 prompt 里明确写：“你只输出修改建议，不输出修改后全文。你无权改变文章结构，只能提出结构调整建议。”

第二，输出格式用 XML 或 JSON 模板固定。我建议每个智能体的 prompt 尾部都附一个输出模板示例，让模型照着结构填。内容工厂这种场景对格式稳定性要求极高，因为下游节点要靠解析格式来取字段，格式一乱，整个管道就断了。

第三，在 prompt 里加入“负面约束”。就是明确告诉模型不要做什么。比如生产智能体 prompt 里加一句“不要使用‘首先、其次、最后’这类模板化过渡词”，比加十句正面描述都管用。

3.3 定义消息与解析规则

openclaw 允许在智能体节点之间自定义消息解析器。因为生产智能体输出的是 Markdown 正文，而审校智能体需要的是结构化建议，二者格式完全不同。我写了两个解析器：

• markdown_parser：把生产智能体输出的 Markdown 正文按标题层级拆成“章节块”，每个块带标题和正文内容。这样审校智能体可以按章节定位问题。
• json_review_parser：把审校智能体的建议 JSON 解析成问题列表，再合并同章节的同类型问题。

为什么不用大模型直接解析？因为文本解析这件事是确定性操作，用代码做 100% 可靠，用 LLM 解析会有概率出错。多智能体流水线里的每一步不确定性会被放大，所以尽量把边界上的解析工作交给确定性代码，让大模型专注在生成和判断上。这个思路贯穿整个项目，是流水线能稳定跑起来的基础。

另一个细节是“消息清洗”。生产智能体输出的正文可能会携带它自己的思考过程，比如“好，我现在开始写大纲了”这种话。我在 markdown_parser 里把这些杂质剔除掉，只保留真正的正文内容，避免审校智能体把模型自言自语当成正文去审校。

3.4 执行一次完整的内容生产任务

我以一条实际跑过的流水线为例：需求是“写一篇面向新手的 openclaw 工作流入门指南，1000 字左右”。

首先我向主编智能体提交需求。它把这篇拆成了 3 个阶段：选题确认、正文写作、审校修订，并生成了一份带大纲的订单。我在工作台里确认了订单，相当于做了一个人工审批节点。

订单确认后，生产智能体收到任务。它先从素材库检索到 3 篇文章参考，再按大纲生成正文。这个过程在控制台里能实时看到任务状态变化。第一版初稿花了大约 40 秒，输出的结构完整，但有两个地方事实引用不够准确。

接着审校智能体介入。事实审校节点返回了 2 条建议，风格审校节点返回了 1 条关于标题冗长的建议。生产智能体收到建议后自动修订，生成了第二版。这版基本可以直接用，我花了很少时间微调后发布。

整条流水线一次跑完大约 8 分钟，其中大部分时间消耗在审校环节的模型调用上。如果纯粹用单次生成再人工改稿，通常至少需要半小时。对批量内容需求来说，这个效率差异是决定性的。

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

4.1 智能体上下文污染问题

最让我头疼的问题，是智能体之间上下文互相污染。表现是：生产智能体在处理第二篇文章时，会突然引用第一篇文章里的内容；或者审校智能体把上一轮的审校建议带到新一轮里。

排查之后发现，问题出在我给智能体实例设置的上下文保留策略上。openclaw 默认会为同一个智能体实例保留多轮对话上下文，以便多轮交互。但内容工厂的场景里，智能体每次接手的是一篇新文章，不应该记得上一篇文章的内容。

解决办法是：在每个“消息循环”结束后主动清空智能体的上下文，或者按任务 ID 隔离上下文。openclaw 支持按对话 ID 作上下文隔离，我把任务 ID 映射成对话 ID，确保每篇文章对应一个隔离上下文。

这里有一个工程上的取舍：上下文隔离会让智能体失去“长期记忆”，但对内容工厂来说，长期记忆本身就不该放在智能体上下文里，而应该放到外部状态库里。记忆靠外部存储，上下文只负责当前任务，这个边界划清之后，很多问题都消失了。

4.2 输出格式漂移

多智能体流水线跑久了，难免出现某一轮智能体输出的格式不符合解析器预期。最典型的是审校智能体的建议 JSON 里，某条建议缺少严重程度字段，或者生产智能体的正文里标题层级乱掉。

我的处理方案是三层兜底：

第一层在 prompt 层，尽量把输出模板写详细，减少漂移概率。第二层在解析器层，做容错解析。比如 JSON 解析失败时，进入“宽松模式”，只取数组部分，缺失字段补默认值。第三层在编排层，如果连续解析失败三次，就把这条任务转入“人工处理队列”，而不是让它无限重试。

这个三层兜底里，第二层和第三层至关重要。一开始我只做了第一层，结果有一次审校节点连续七篇内容输出格式异常，整个队列全部卡死。加上容错解析和人工兜底后，流程的稳定性大幅提升。

4.3 成本与速率控制

多智能体流水线的成本比单次调用高得多。一篇文章可能需要调用 6 到 10 次模型接口，因为反复生成、审校、修订都会产生调用。

我控制的策略有三个：一是控制审校轮数上限，默认最多两轮，如果两轮审校后还有重大问题，就转人工处理而不是无限自动修订；二是用不同档位的模型，生产智能体用能力较强的模型，审校智能体在跑纯风格检查时用相对便宜的模型，只有事实审校用高能力模型；三是加缓存规则，同一篇内容重复审校时，直接复用之前的审校结果，避免重复计费。

这里想让跑内容工厂的人注意：成本不是靠省调用次数降下来的，而是靠把模型档位和任务难度匹配降下来的。让最强的模型干最难的活，让便宜模型干机械活，整体成本能下降 30% 到 40%。

4.4 故障恢复与重试

最后一个踩坑点是任务失败后的恢复机制。openclaw 的默认行为是节点失败后记录错误状态，但不会自动恢复。在内容工厂场景里，一个节点失败会导致整个批次的文章全部卡住。

我加了一个简单的死信队列机制：任务在某节点失败后，进入死信队列。每天晚上跑一个恢复脚本，把死信队列里的任务根据失败原因分类处理——资源超时的自动重试；格式解析失败的重置到上一步重新处理；连续失败超过阈值的任务标记为“需人工介入”。

加了这个机制后，流水线基本能做到无人值守。但前提是每个节点的幂等性要做好，即同一任务在同一节点重复执行，结果是一致的。openclaw 的事件系统支持消息去重，我用任务 ID + 节点名作为去重键，防止重试时产生重复产物。

结尾：一点个人体会

这套多智能体内容工厂跑下来，我最大的体会是：多智能体真正解决的问题不是“让 AI 更聪明”，而是“让 AI 的分工更清晰”。内容生产是个天然适合分工的领域，选题、初稿、审校、发布，每一步的目标完全不同，强行用一个模型包办所有，能力再强也会顾此失彼。

后来我又把这个模式迁移到别的场景，比如自动化测试报告生成、产品需求文档分解，基本思路完全复用。核心永远是先把流程拆到足够细的节点，再为每个节点配一个高度专注的智能体，最后用事件路由把节点串起来。

如果你刚接触 openclaw，我的建议是先别急着堆智能体数量，用三个节点跑通一条最小内容流水线：主编拆单、生产初稿、审校把关。把这一条线跑稳、跑熟了，再往里面加角色、加分支、加人工审批节点，你会发现整个系统像搭积木一样，越搭越顺。