企业官网建设流程全解析

最近在啃 openclaw 仓库里的 Multi-Agent Content Factory 用例，前后花了一周多，把官方英文文档翻成了中文笔记，也顺手把代码跑了一遍。这个用例解决的是内容生产环节最经典的问题：选题、调研、初稿、审校、分发这一整套流程，能不能交给一群各司其职的 Agent 去互相协作完成。我用下来最大的感受是，它不是一个堆 Prompt 的脚本集合，而是一套带有明确分工、状态管理、质量门禁和人工介入节点的完整流水线。这篇文章把我在翻译和实操过程中沉淀下来的东西做个梳理，适合正在研究多智能体编排、想给团队搭一套内容自动化管线，或者单纯对 Agent 协作机制感兴趣的朋友。

1. 用例定位：先搞清楚这个 Multi-Agent Content Factory 到底在做什么

1.1 官方文档里的一句话定义

原版文档里，Multi-Agent Content Factory 被定义成“一个通过多个专用智能体协作，把用户提供的主题自动加工成可发布内容的工作流”。这个定义非常收敛，它没有说要替代整个编辑部，而是强调“基于一个主题”和“可发布内容”。我对照源码之后才真正理解，这句话其实限制了整个系统的边界：输入是一个主题或一句话想法，输出是一篇结构完整的文章，中间所有环节都可以由不同的 Agent 接管。

为什么这个定义很重要？因为它决定了架构的基本形态。如果输入变成“持续追踪某个行业新闻并每日自动更新”，那系统需要长周期记忆、定时触发、增量生成；但这里的输入是单次主题，所以所有 Agent 只需要围绕一个上下文工作，任务状态也可以简单地在会话内维护。翻译时我特意查了原文用词，写的是 single-pass pipeline，不是 multi-turn conversation。这个措辞差异很关键，它暗示设计者在刻意避免无限对话带来的状态失控问题。如果你在搭自己的系统，第一件事也是定义好输入的边界：是单次任务，还是持续任务。边界定义错了，后面的编排逻辑全都会跟着错。

1.2 它对标的是传统内容生产流程

传统内容生产通常是这样：主编定选题，记者查资料，写手出初稿，编辑改稿，SEO 专员调关键词，最后再有人负责发布。每个环节都需要人，而且环节之间靠文档、群消息、会议来同步。Multi-Agent Content Factory 想做的事情，就是把这五六个角色抽象成 Agent，用一套消息机制替代会议，用共享的“内容草稿”替代文档流转。

实际操作中，这个用例并没有把每个环节做成独立的微服务，而是用单进程内多个 Agent 实例来模拟团队。它关注的是“角色边界 + 工具调用 + 质量门禁”，而不是大规模分布式部署。如果你在玩 openclaw，会看到它的编排层支持把不同 Agent 挂在同一张工作流图上，共用一份上下文存储。这种设计带来的直接好处是部署成本低、调试直观、适合小团队，代价是并发能力有限，所有 Agent 争抢同一个进程的计算资源。对于内容生产这种以分钟为单位的任务来说，并发劣势完全可以接受。

1.3 适合谁参考

翻译完整个用例，我觉得它最值得参考的对象有三类：

• 正在尝试用多智能体做内容自动化的开发者和内容运营，想找一个不是玩具级别的参考实现；
• 研究 Agent 协作机制，尤其是任务分配、状态共享、约定校验的人；
• 已经跑过单 Agent 写稿，但发现输出不稳定、无法控制质量，想引入多角色协作机制的人。

不适合谁？如果你的需求非常简单——比如只想要一个“输入标题直接生成文章”的脚本，那这个用例反而显得重。多智能体架构的价值在复杂任务、多步骤交互、需要多轮校验的场景中才能体现出来。单 Agent 能解决的问题，用五个 Agent 去解决只会增加延迟和成本。我见过不少团队把系统拆得过于复杂，本质上是拿多智能体的概念包装单次调用，最后除了让排查问题变得困难，没有带来任何收益。

2. 系统拆解：内容工厂里的 Agent 分工与协作模型

2.1 角色划分：五个核心 Agent

这个用例里一共注册了五个 Agent，原文档把它们叫作 Researcher、Writer、Editor、SEO Optimizer、Publisher。我翻译时没直译成“研究员、作者、编辑、SEO、发布者”，而是按国内内容团队的习惯改成了“选题调研、初稿撰写、编辑审校、SEO 优化、发布执行”。这五个角色各有自己的系统提示词和工具集。

角色之间不是平等的，原文档里有一个很微妙的设置：Editor 对 Writer 有“要求修改”的权限，Writer 收到之后必须重新生成；SEO Optimizer 没有直接改写权，只能把建议写到共享上下文中，由 Editor 决定是否采纳。这个设计很符合内容行业的真实权力结构，也避免多个 Agent 同时修改同一份草稿造成冲突。翻译笔记里我特别标注了这一点：不要让所有 Agent 都拥有对最终成稿的写权限，“建议权”和“改写权”分开，是维持系统稳定性的关键。

2.2 任务编排：从串行到并行

第一个版本的工作流完全串行，流程是：调研 -> 写作 -> 审校 -> SEO -> 发布。跑通之后发现效率低，尤其是调研阶段经常要等待外部 API 返回，而写作 Agent 其实可以先根据大纲写一个版本，等资料回来再补充。后来在 openclaw 的图上把调研拆成了两个并行的分支：一个查数据，一个查案例，两个结果都写回共享上下文，Writer 等到两个分支都结束才开始写作。

openclaw 的编排模型里，节点之间通过边上的 condition 来控制依赖关系。在配置文件中能看到每个 Agent 的完成条件：比如调研 Agent 要收集到至少三条外部来源或者执行了三次工具调用才算完成，否则会触发重试。这个机制本质上是用有向图把内容生产流程变成可执行的 DAG。翻译文档时我看到一张 ASCII 流程图，原图上把“人工确认”标成了一个特殊的 gate 节点，我后来在源码里确认它就是一个暂停点——执行到这一步会停下，等外部输入。

并行编排带来一个需要小心的点：多个分支同时写共享上下文时，如果字段命名不规范，很容易出现写覆盖。openclaw 给每个 Agent 分配独立的 namespace 来缓解这个问题，但前提是你配置得对。我在实操时见过有人把两个分支 Agent 配成同一个 namespace，结果后完成的分支直接覆盖了先完成分支的数据，这在我后面的章节会详细说。

2.3 共享状态与消息传递的设计

这个用例没有用复杂的消息总线，而是基于一个全局 context store 来做协作。每个 Agent 可以读取 context 里任意字段，但只允许写入自己的命名空间。例如 Writer 的草稿存在 draft.writer_v1，Editor 的批注存在 review.editor_v1，发布阶段读取 review.approved 字段，如果为空就直接终止任务并上报状态。

我当时觉得这种设计比队列消息更稳定，原因是写内容类任务天然依赖“大家都看同一份草稿”，而不是“事件你发我收”。用消息队列实现议程模式很容易出现不同 Agent 手里的草稿版本不一致的问题。共享上下文虽然并发粒度粗，但对这个场景来说，简单可靠比性能更重要。翻译的时候我还注意了一个细节：openclaw 的 context store 每次写入都是 append-only，不直接修改原值，而是生成新版本。这样一旦出现异常，很容易回溯到某个节点的输出。

3. 关键设计细节：翻译笔记里最值得记的 5 个点

3.1 提示词模板的写法

这个用例里的提示词模板不是一长段 prompt，而是分成了 system、context、instruction、output_format 四部分。system 定义角色和纪律，context 从全局上下文中格式化填充，instruction 是当前步骤的目标，output_format 规定了 JSON 字段。举例说，Writer 的 output_format 要求返回 title、sections、references、draft_text 四个字段，Editor 返回 verdict、comments、suggestion 三个字段。这种结构化输出让下游节点能准确地拿到自己需要的部分，也方便后面做校验。

翻译笔记里我特意标了一段：原文档强调“每个 Agent 的 system prompt 里必须写清楚它的输入输出契约，而不是把流程指令写在 system prompt 里”。这个原则太重要了。很多失败的多智能体项目，问题就出在把流程控制逻辑塞进提示词，比如“你先调用搜索工具，然后等 30 秒，再调用写作模型”，这种命令式写法一旦工具延迟就会崩。正确做法是把流程交给编排层，提示词只负责角色行为和输出规范。

3.2 工具注册与外部 API 对接

openclaw 对工具的定义是一个函数 + 描述 + 参数 schema。Multi-Agent Content Factory 里注册了六个工具：search_web、fetch_url、db_lookup、text_generate、spellcheck、publish_article。工具和 Agent 之间是显式绑定的，Agent 配置里 declaration 字段下面有个 tools 数组，只有白名单里的工具才会暴露给模型。

我一开始以为工具调用都是通过 JSON function call 完成的，后来翻了源码才发现这里的 text_generate 其实是一个内部路由，它根据传入的 model 参数决定调用本地模型还是远程 API。这个抽象层的意义在于，Agent 自己不用关心模型地址和密钥，统一从配置文件里读。实际操作中，我如果要加一个“查重”功能，只需要新写一个 dedup 函数，注册到同一个 executor，然后在 Editor 的 tools 数组里加上去就行。整个过程不需要改动工作流图的定义，插件化程度很高。

3.3 质量门禁（Review Gate）机制

这个用例里最有参考价值的是 review gate。它不是简单地把 Editor 的评语拼到草稿后面，而是规定了一个可编程的判断逻辑：Editor 结束后，系统检查 review.editor_v1.verdict 字段是否为 approved，同时检查 editor_revision 是否小于等于 2。如果连续修改两次仍未通过，工作流直接进入失败分支，把草稿和所有评语打包成报告发给维护人员。

这个“最多修订两次”的阈值看似随意，其实背后有成本考量。每次修订都要调一次写作模型，多智能体系统的总成本约等于各 Agent 调用成本之和。三次失败后继续迭代，边际收益通常已经很低，不如尽早断臂止损。我后来在配置里把阈值给成了一个可选参数 max_revisions，用户可以在初始化时动态设置，这样既保留默认值，又不会把逻辑写死。这算是我在翻译笔记上做的一个小扩展，开放给团队后，大家可以根据不同内容类型调整修订次数上线。

3.4 人类介入（Human-in-the-loop）节点

自动化程度再高，有些环节还是需要人点头。这个用例在“发布”之前设置了一个 human approval 节点，默认是 auto-approve 模式，但可以改成 manual。原文档里给的场景是：内容面向外部用户时，建议开启人工确认；如果只是生成内部草稿，可以跳过。

我在本地跑的时候开了 manual 模式，发现 openclaw 对这种情况的处理是直接把工作流挂起，然后命令行终端弹出确认提示，等待输入 y/n。用久了之后我有点担心这个模式在服务端部署时会卡住，后来看到配置里还有一个 timeout 参数，超过指定秒数会自动按“不通过”处理。这种兜底机制很有必要，避免一个人工节点阻塞整个流水线。顺便说一句，在服务端长时间跑任务时，我会把 human approval 节点设计成从外部接口接收信号，而不是依赖终端输入，否则一旦进程转成后台守护，这个节点就永远等不到回应。

3.5 可观测性与日志追踪

多智能体系统排障最大的难点是“黑盒”。一个任务失败，说不清是哪个 Agent 的提示词问题，还是上游数据问题，又或者是外部 API 超时。openclaw 的 Telemetry 模块会把每次 Agent 执行的输入输出摘要、token 消耗、工具调用耗时记录成带 trace_id 的日志。

这个用例的日志里，每条记录都带 agent_name 和 step_order，可以很容易地还原出完整调用链。我当时排查一个“Writer 生成的标题和内容不一致”的问题，就是靠日志发现 Researcher 返回的资料里有两条过期信息，Writer 把其中一条当成了事实写进正文，而 Editor 没有做事实核查。这类问题如果不看 trace，单纯调提示词会浪费时间。现在的做法是，每跑完一个任务，我都会把 trace_id 记进结果对象里，后续一旦有用户反馈内容有问题，可以直接定位到是哪一轮哪一步产生的。

4. 实操：本地跑通 openclaw 的 Multi-Agent Content Factory

4.1 环境准备与安装

我用的环境是 Python 3.11 加 pip，openclaw 当前需要 3.10 以上版本。安装直接 pip install openclaw，然后把仓库里的 examples/content_factory 目录拉下来。如果你访问外网不便，把依赖包预先下载到本地离线包也行，但建议直接用官方依赖清单装，省得之后缺包。

需要特别注意的是模型配置。这个用例默认走远程 API，但我在配置里把 LLM 指向了本地服务，只需要改 config.yaml 里 model_provider 字段和 base_url。另外它需要一个向量库来做 db_lookup 工具的检索，我直接用轻量级嵌入式数据库加简单的 TF-IDF 方案顶替，跑出来的效果也够用。对于想快速上手的同学，不建议一开始就上大型向量数据库，先跑通流程再说。很多项目卡在第一步不是因为代码复杂，而是因为环境依赖和外部服务太多。

4.2 配置文件解析

打开 content_factory/config.yaml，核心结构大致是这样，我摘了一段精简版：

workflow: name: content_factory entry: research agents: researcher: model: local-model system_prompt: prompts/researcher.md tools: [search_web, fetch_url, db_lookup] namespace: research writer: model: local-model system_prompt: prompts/writer.md tools: [text_generate] namespace: draft editor: model: local-model system_prompt: prompts/editor.md tools: [spellcheck, db_lookup] namespace: review edges: - from: researcher to: writer condition: research.sources_count >= 3 - from: writer to: editor condition: draft.draft_text != null - from: editor to: writer condition: review.verdict == 'revision' - from: editor to: seo_optimizer condition: review.verdict == 'approved' gate: human_approval: true timeout: 600

翻译笔记中我最初被 condition 的表达绕了一下，后来才明白这里每个条件都读取的是共享上下文中的字段。比如 research.sources_count 不是变量，而是 Researcher 写完上下文后自动更新的一个计数。openclaw 的上下文更新是幂等的，每次 Agent 完成任务后会根据 return_schema 更新 namespace 里的字段，所以条件判断不会读到脏数据。这个机制需要你在定义 Agent 的 return_schema 时就想清楚，哪些字段会被下游节点引用。

4.3 启动一次内容生产任务

启动命令很简单：

python -m openclaw run ./content_factory/config.yaml --input "为什么多智能体协作比单模型更可控"

运行之后，终端会先输出当前工作流图的节点列表，然后进入执行阶段。我实际跑通的一次流程耗时是：调研 48 秒，包含三次网页搜索；写作 22 秒；编辑 15 秒；SEO 优化 8 秒；人工确认 5 秒。总计 98 秒。因为是最基础的串行模式，所以总耗时就是各节点相加；如果开了并行调研分支，调研时间可以缩短到 30 秒左右。

我第一次没跑通，卡在调研节点上。原配置里 search_web 工具默认只返回 5 条结果，但我输入的主题比较冷门，搜索返回只有 2 条，condition 要求 research.sources_count >= 3，于是工作流在边线上反复重试。后来我把条件改成了 sources_count >= 2，或者把搜索返回参数从 5 改成 10，问题就解决了。这种边界条件，翻译文档的时候只字不提，只有跑起来才发现。建议初次复现的人给自己留半小时专门处理这种阈值问题。

4.4 观察 Agent 协作过程

openclaw 有一个简单的控制台面板，按回车可以逐条刷新执行日志。在面板里能实时看到当前正在执行的 Agent、它正在使用的工具、以及已经写入上下文的字段。我在实际运行时开了两个终端，一个跑任务，一个 tail 日志文件，这样可以对照观察。

一次比较典型的调用过程是：Researcher 首先调用 search_web，返回结果写入 research.raw_results；随后 fetch_url 提取页面正文，写入 research.notes；然后 db_lookup 查内部库，写入 research.internal_refs。当所有工具执行完毕，它把 research.sources_count 更新为实际来源数量。Writer 读取这些字段后，开始调用 text_generate 生成章节；中途如果 Editor 判定需要修订，Writer 会重新执行 text_generate，但不重新查资料。这个“不重查资料”的策略很聪明，避免每次修订都重复外部调用，既省钱又减延迟。如果你自己设计类似的流水线，一定要把“哪些动作允许重跑、哪些不允许”明确写出来。

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

5.1 Agent 互相踩踏，输出覆盖

最早跑的时候，我发现 Writer 生成的草稿偶尔会被 Editor 的输出覆盖。查了半天，发现是两个 Agent 的 namespace 写错了。Writer 被配置成 namespace: draft，但编辑器实例因为复制粘贴漏改，也用了 namespace: draft，导致 Editor 写入的 verdict 字段把 Writer 的 draft_text 覆盖了。这类问题的本质是“共享上下文命名空间设计不合理”。

解决办法是在每个 Agent 的 namespace 后面加版本后缀，比如 draft.writer_v1、review.editor_v1，并且约定每个 Agent 只允许写自己前缀下的字段。openclaw 里没有强约束，所以这必须靠人工规范。我还在配置里加了一个启动校验脚本，扫描所有 agent 的 namespace，发现重复就报错退出。这个改动很小，但能省下后续大量排障时间。

5.2 内容质量不稳定

这是最容易让人对多智能体失去信心的一个问题。同一篇主题，有时生成的内容逻辑通顺，有时明显跑偏。复盘发现跑偏的情况大多集中在调研资料不充分的时候。Writer 在资料不足时，倾向于从自己的预训练记忆里补充事实，而这些事实没有经过查证，自然容易出错。

我的处理策略分两层：第一，在 Writer 的 system prompt 里加了一条铁律——如果 research.notes 提供的资料不足以支撑某个论点，必须返回 insufficient_material 标记，而不是自行编造；第二，在 Writer 的输出 schema 里增加引用来源校验，如果输出里没有足够多的来源标记，就拒绝入库并触发一次补充调研。经过这两层处理，内容质量明显稳定下来。这个思路也适合你自己搭的任何 Agent 系统：给 Agent 一个“说不知道”的安全出口，而不是逼它硬编。

5.3 API 超时导致任务卡死

默认的 HTTP 超时是 30 秒，但内容生成模型有时响应超过 60 秒，于是节点报错，任务直接失败。我一开始在 workflow 外层套了重试机制，发现每次都是重新从 entry 开始，浪费了前面节点的成本。后来翻了源码，发现 openclaw 的重试粒度可以按节点配置，在 agents 定义里加 retry_times: 3 和 retry_interval: 10，它只在当前节点重试，不回溯到工作流起点。

这个细节很值得记下来。多智能体的重试不是越粗越好，粒度越细成本越低。如果是外部 API 偶发超时，节点级重试就够了；如果是模型本身经常性超时，就需要考虑换更小的模型或者调低 max_tokens。我后来还把重试间隔做成了指数退避，第一次 10 秒，第二次 20 秒，第三次 40 秒，避免节点集中重试时把外部 API 打爆。

5.4 上下文过长被截断

写长文时，调研资料 + 草稿 + 编辑意见加在一起，很容易超过模型上下文窗口。openclaw 默认策略是截断最早的记录，但这样会丢失调研资料的上下文。我后来改成按重要程度排序，保留草稿和最新的编辑意见，把原始 search 返回结果移到 summary buffer 中。

一个实用的技巧：在配置里设置 context_strategy: selective，然后给每个字段打上 retention 优先级。草稿和评审意见设 high，原始资料设 medium，日志设 low。这样即便超窗，也不会丢核心信息。实测生成一篇 3000 字左右的文章，上下文占用在可接受范围内，调整后没有出现过截断导致的逻辑断裂。

5.5 问题排查速查表

这张表我直接贴在了项目文档开头，团队里有人遇到问题先查表，能少打扰很多人。如果你的多智能体项目也经常出问题，建议尽早积累自己的问题速查表，排查效率会高很多。

6. 翻译笔记之外的几点心得

6.1 多智能体不是万能药

翻完整个用例并跑通之后，我对多智能体的态度变得更加务实。它最适合那些天然存在角色分工、需要多轮校验、且每一个环节都能定义明确输入输出契约的任务。内容生产恰好符合这些特征，所以 Multi-Agent Content Factory 显得合理。但如果你要处理的任务本身非常开放，比如“帮我聊聊天”，强行拆成多个 Agent 只会徒增延迟和错误传播路径。

我在笔记最后写了一句批注：一个 Agent 能完成的事情，永远不要拆成两个 Agent。多智能体的价值是让每个角色专注自己的局部目标，并通过机制保证局部最优能收敛到全局可接受，而不是简单地把一个复杂提示词拆成几个简单提示词。拆分的依据应该是角色边界，而不是为了数量上的好看。

6.2 提示词工程仍是杠杆率最高的一环

整个用例跑下来，生成质量影响最大的始终是提示词边界，而不是模型参数。同一套五个 Agent，把 Writer 的 system prompt 从“你是一个文案”改成“你是一个需要严格基于 research.notes 写作，禁止补充未经验证信息的中文编辑”，输出质量差了一个量级。openclaw 本身没有魔法，它只是把流程托底做得更规范，让提示词的效果能稳定发挥。

所以我的建议是，别急着加更多 Agent 或者换更强模型，先把每个角色的 system prompt 和行为约束打磨清楚。多智能体系统的整体表现，很大程度上取决于最弱的那个环节；而最弱环节往往不是模型能力，是 Agent 对自身职责和边界的理解不够。

6.3 后续可以这样扩展

我目前正在尝试在 content_factory 基础上加一个历史素材库：把每次生成的草稿、编辑意见、最终发布版本都存回数据库，之后让 Researcher 可以检索历史内容，避免重复产出相似文章。另外还打算加一个分发环节，让发布执行 Agent 自动把文章推送到多个内容平台。openclaw 的工具注册机制让这些扩展变得比较简单，基本就是写一个新函数、挂到对应 Agent 的工具列表里。

如果你也想在这个用例上做扩展，建议优先做两件事：一是把“人工确认”节点改造成可配置的外部服务接口，方便和已有的审批流对接；二是增加一个质量抽样评估节点，不定期对最终发布的内容做自动复盘。这两项都不算特别复杂，但对真实业务落地帮助非常大。

最后说句实话，这个用例的翻译笔记我整理了两周，比单纯跑代码学到的东西多得多。很多设计细节只有当你试图用中文把别人的思路重新讲清楚的时候才会真正注意到，比如 namespace 的版本管理、condition 的取值边界、gate 的超时兜底。如果你们也在研究多智能体编排，我建议不要只看文档或者只跑 demo，试着把官方用例的架构图手动画一遍，再用自己的话把每个节点的输入输出契约写出来。这个过程本身就是在建立你对自己系统的设计直觉。多智能体系统的坑很多，但每踩一个，后面都会少踩十个。