企业官网建设流程全解析

1. SEO内容团队的产能瓶颈，到底卡在哪一步

如果你在SEO内容团队待过，大概率经历过这样的循环：关键词表拉出来几百个长尾词，选题会开完，写手排期排到两个月后，结果三个月过去，真正上线并收录的文章不到三成。不是团队不努力，而是单点人工流程天然存在吞吐上限——选题靠人翻竞品、写作靠人憋灵感、审核靠人逐句抠、发布靠人复制粘贴，每个环节都在等上一个人交棒。

OpenClaw 这类多 Agent 协同框架能做什么？简单说，它把「一篇文章从关键词到发布」拆成若干可独立执行的角色，让选题 Agent、写作 Agent、审核 Agent、发布 Agent 各管一段，中间用任务编排文件串起来，再通过 CC Switch 把模型调用统一收敛到 TaoToken 的 Key 上。适合谁？适合已经有稳定关键词库、每周要出 20 篇以上 SEO 文章、但人力卡在 5 到 8 篇的团队。我试过把一条 30 个长尾词的流水线跑通，从触发到产出可发布草稿，全程不需要人工介入，只有最后一道事实核查留了人工确认。

这篇文章交付三样东西：可复制的 Agent 角色配置骨架、任务编排文件、以及 CC Switch 接入 TaoToken 统一 Key 的 settings.json 示例。你照着改参数就能在本地跑通，最后我会给验证请求和常见报错排查。

2. 前置准备：TaoToken 统一 Key 与 CC Switch 接入

多 Agent 流水线最怕什么？每个 Agent 各配一套模型 Key，写作 Agent 用一家、审核 Agent 用另一家，月底对账对到崩溃，某个 Key 限流了还得逐个排查。TaoToken 在这里的作用是提供一个统一的 API 入口，你申请一个 Key，所有 Agent 的模型调用都走它，计费和限流集中管理。

先拿到 Key。打开 TaoToken 控制台，在 API Keys 页面创建一个新 Key，复制出来。注意这个 Key 只显示一次，建议直接写进环境变量而不是硬编码在配置文件里。

export TAOTOKEN_API_KEY="sk-你的key"

CC Switch 是一个模型配置切换工具，它的核心配置文件是 settings.json。你要做的是把默认的模型供应商指向 TaoToken 的 API 地址，这样 OpenClaw 里所有 Agent 调用模型时都会走这个统一入口。下面是一个最小可用的 settings.json 骨架：

{ "providers": { "taotoken": { "baseUrl": "https://taotoken.net/api", "apiKey": "${TAOTOKEN_API_KEY}", "models": { "writer": "claude-sonnet-4-20250514", "reviewer": "claude-sonnet-4-20250514", "planner": "claude-sonnet-4-20250514" } } }, "defaultProvider": "taotoken" }

这里有个细节：baseUrl填的是https://taotoken.net/api，不要加多余的路径后缀。apiKey用${TAOTOKEN_API_KEY}引用环境变量，CC Switch 启动时会自动读取。models字段里我给写作、审核、规划三个角色都配了同一个模型，实际跑的时候你可以按需换成更便宜的模型做选题、更强的模型做审核，TaoToken 支持在同一个 Key 下切换不同模型。

配置写完后，用一条 curl 验证 Key 是否生效：

curl -X POST https://taotoken.net/api/v1/messages \ -H "Content-Type: application/json" \ -H "x-api-key: ${TAOTOKEN_API_KEY}" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-sonnet-4-20250514", "max_tokens": 64, "messages": [{"role": "user", "content": "回复 OK"}] }'

返回里出现content字段且文本为 OK，说明 Key 和网络都通了。这一步不通，后面所有 Agent 都跑不起来，所以先卡在这里验证。

3. OpenClaw 多 Agent 角色配置骨架

OpenClaw 的 Agent 定义通常放在一个 agents 目录下，每个 Agent 一个 YAML 或 JSON 文件。我按 SEO 文章流水线拆了四个核心角色：选题 Agent、写作 Agent、审核 Agent、发布 Agent。下面给出每个角色的配置骨架，你直接复制改参数。

3.1 选题 Agent：从关键词表到文章大纲

选题 Agent 的职责是读取关键词列表，结合竞品标题和搜索意图，输出一份带 H2/H3 结构的大纲。它的输入是关键词和目标字数，输出是结构化 JSON。

name: topic-planner model: planner system: | 你是一个SEO选题规划师。给定一个关键词和搜索意图，输出一份文章大纲。 要求： 1. 标题包含关键词，长度不超过30字 2. 至少4个H2，每个H2下2到3个H3 3. 输出严格JSON，字段为 title, h2_list, target_words input: keyword: "{{keyword}}" intent: "{{intent}}" target_words: 2500 output_format: json

这里model: planner对应 settings.json 里配的模型别名。{{keyword}}是编排文件传入的变量。输出强制 JSON 是为了让下游写作 Agent 能直接解析，不用再做自然语言抽取。

3.2 写作 Agent：按大纲逐段生成

写作 Agent 接收大纲 JSON，按 H2 分段生成正文。关键点是它不能一次性生成全文，否则容易跑偏和超长。我的做法是让编排文件按 H2 循环调用写作 Agent，每次只写一个章节。

name: section-writer model: writer system: | 你是一个SEO文章写手。根据给定的大纲章节和关键词，写出该章节正文。 要求： 1. 每个H3下至少150字，段落4到6行 2. 关键词自然出现，不堆砌 3. 不用emoji，不用"综上所述"这类套话 4. 输出纯Markdown，不要加代码块包裹 input: section_title: "{{section_title}}" sub_points: "{{sub_points}}" keyword: "{{keyword}}" context: "{{previous_summary}}" output_format: markdown

context字段传入前文摘要，保证章节之间不重复、不矛盾。这个摘要是编排文件在每段写完后自动生成的，不需要人工干预。

3.3 审核 Agent：事实核查与SEO检查

审核 Agent 做两件事：一是检查关键词密度和标题标签，二是对文中出现的数据、年份、专有名词做事实核查。它输出一个审核报告，包含 pass 或 revise 以及具体修改意见。

name: content-reviewer model: reviewer system: | 你是一个SEO内容审核员。检查给定文章的三个维度： 1. 关键词是否出现在标题、首段、至少两个H2中 2. 是否存在事实性错误或无法验证的数据 3. 是否有AI套话（如"随着...的发展"、"综上所述"） 输出JSON：{"result": "pass|revise", "issues": [...], "keyword_density": 0.0} input: article: "{{article}}" keyword: "{{keyword}}" output_format: json

如果result是 revise，编排文件会把 issues 回传给写作 Agent 重写对应段落，最多重试两次。两次不过就标记为人工介入，不阻塞整条流水线。

3.4 发布 Agent：格式化并写入 CMS

发布 Agent 负责把审核通过的文章转成目标 CMS 的格式，生成 slug、meta description、内链建议，然后调用发布接口。这一步我建议先输出到本地文件，确认无误后再接真实 CMS。

name: publisher model: writer system: | 将文章转换为发布格式，输出JSON： {"title": "", "slug": "", "meta_description": "", "content_md": "", "internal_links": []} slug用关键词的英文短横线形式，meta_description不超过155字符。 input: article: "{{article}}" keyword: "{{keyword}}" output_format: json

4. 任务编排文件：把四个 Agent 串成流水线

Agent 定义好了，接下来是编排。OpenClaw 的编排文件一般是一个 pipeline.yaml，描述任务顺序、变量传递和条件分支。下面是我跑通的最小版本：

name: seo-article-pipeline trigger: type: keyword_list source: "./keywords.csv" steps: - id: plan agent: topic-planner input: keyword: "{{item.keyword}}" intent: "{{item.intent}}" output: outline - id: write agent: section-writer loop: "{{outline.h2_list}}" input: section_title: "{{loop_item.title}}" sub_points: "{{loop_item.h3_list}}" keyword: "{{item.keyword}}" context: "{{steps.write.previous_summary}}" output: sections - id: assemble type: merge input: "{{steps.write.sections}}" output: draft - id: review agent: content-reviewer input: article: "{{steps.assemble.draft}}" keyword: "{{item.keyword}}" output: review_result on_revise: target: write max_retry: 2 - id: publish agent: publisher input: article: "{{steps.assemble.draft}}" keyword: "{{item.keyword}}" output: "./output/{{item.keyword}}.json"

几个关键点解释一下。trigger从 keywords.csv 读取关键词列表，每行一个关键词和意图。loop让写作 Agent 按 H2 循环，previous_summary是自动累积的前文摘要。on_revise定义了审核不通过时的回退逻辑，最多重试两次。publish的输出路径用关键词命名，方便你批量检查。

跑这条流水线的命令：

openclaw run pipeline.yaml --config ./settings.json --concurrency 3

--concurrency 3表示同时处理 3 个关键词，这个值取决于你的 TaoToken Key 的并发限额，建议先从 1 开始，确认稳定后再往上加。

5. 本地跑通与效果验证

配置写完了，怎么确认整条流水线真的在工作？我分三步验证。

第一步，单 Agent 验证。先只跑选题 Agent，确认它能从关键词生成合法 JSON 大纲：

openclaw run pipeline.yaml --step plan --limit 1 --dry-run

--dry-run会打印每个步骤的输入输出但不实际调用发布接口。如果大纲 JSON 解析失败，多半是模型输出里混了 Markdown 代码块标记，在 system prompt 里加一句「不要用代码块包裹 JSON」即可。

第二步，全链路小批量验证。取 3 个关键词跑完整流程：

openclaw run pipeline.yaml --limit 3 --concurrency 1

跑完后检查./output/目录，每个关键词应该对应一个 JSON 文件，里面包含 title、slug、meta_description 和 content_md。打开 content_md 看三件事：关键词是否出现在标题和首段、H2 数量是否达标、有没有明显的 AI 套话。如果审核 Agent 的 pass 率低于 70%，说明写作 Agent 的 system prompt 需要收紧，比如把「不用套话」改成具体的禁用词列表。

第三步，效果对比。把自动生成的文章和人工写的文章各取 10 篇，对比三个指标：关键词密度、平均段落字数、H2 覆盖率。我实测下来，自动生成的文章在结构一致性上明显更稳，但深度案例的丰富度不如资深写手。所以我的建议是：自动流水线负责铺量长尾词，人工写手集中精力做 3 到 5 篇支柱内容，两者用内链串起来。

如果你在验证阶段想快速试不同模型对写作质量的影响，可以直接在 TaoToken 的模型对话页面里粘贴同一段 prompt 对比输出，不用改配置文件就能切换模型。确认哪个模型适合你的内容风格后，再写回 settings.json。

6. 本篇常见报错排查

跑流水线时最容易撞上的几个报错，我按出现频率排一下。

报错一：401 Unauthorized。九成是 Key 没读到。检查TAOTOKEN_API_KEY环境变量是否在当前 shell 生效，echo $TAOTOKEN_API_KEY看有没有输出。如果用的是 CC Switch 的${TAOTOKEN_API_KEY}引用，确认 CC Switch 启动时继承了环境变量，而不是在另一个终端里 export 的。

报错二：JSON 解析失败。模型输出里带了 ```json 代码块标记，或者末尾多了解释性文字。在对应 Agent 的 system prompt 里加「只输出 JSON，不要任何额外文字和代码块标记」，同时在编排文件里加一个output_parser: strict_json字段做兜底。

报错三：审核 Agent 无限重试。如果写作 Agent 每次重写都触发同样的 issues，说明 issues 描述太模糊。把审核 Agent 的输出要求改成「每条 issue 必须包含具体段落位置和修改建议」，写作 Agent 才能针对性修改。另外max_retry一定要设上限，我设的是 2。

报错四：并发跑的时候部分关键词超时。这是 TaoToken Key 的并发限额到了。把--concurrency降到 1 或 2，或者在编排文件里给每个步骤加retry_on_timeout: 1。如果长期需要高并发，去 TaoToken 控制台看当前套餐的限额，按需调整。

报错五：发布 Agent 生成的 slug 重复。两个关键词的中文转英文后撞了。在发布 Agent 的 system prompt 里加一句「slug 末尾追加 4 位随机字符」，或者在编排文件里加一个去重步骤。

排障的核心思路是：先确认 Key 和网络通，再确认单个 Agent 输出格式对，最后才查编排逻辑。大部分问题出在前两步，不用一上来就怀疑流水线设计。

7. 下一步：把流水线接到你的实际工作流

跑通本地验证后，你可以做三件事让它真正产生价值。第一，把发布 Agent 的输出从本地文件改成调用你 CMS 的 API，WordPress 有 REST API，Hexo 和 Hugo 可以直接写 Markdown 文件到 source 目录。第二，把关键词来源从静态 CSV 改成从你的关键词工具导出，或者接一个定时任务每周拉一次新词。第三，给审核 Agent 加一个人工确认的 webhook，高价值文章在发布前推送到飞书或钉钉，人工点确认后才发。

如果你还没开始配，先去 TaoToken 控制台把 Key 建好，然后照着第 2 节的 settings.json 把 CC Switch 接上。接入文档里有不同语言 SDK 的调用示例，Python 和 Node 都有，你按自己 OpenClaw 的运行环境选。长期跑编码和 Agent 流水线的话，Coding Plan 的额度比按量计费更划算，适合每周稳定产出几十篇的团队。模型对话页面可以随时用来对比不同模型在你内容场景下的表现，不用改配置就能试。