传统的 pSEO（Programmatic SEO），通常是围绕大规模长尾关键词设计页面模板，再将结构化数据填入模板，批量生成城市页、目录页、对比页、集成页等搜索落地页。它的核心并不是“批量写文章”，而是用程序化方式降低页面生产成本，扩大搜索需求的覆盖范围。

生成式 AI 的发展，为 pSEO 提供了新的实现路径。过去依赖固定模板和结构化字段完成的页面，如今可以加入关键词研究、竞品分析、内容写作、质量审核和内链推荐等 AI 能力。pSEO 因此不再局限于数据与模板的简单组合，而是可以生产结构更灵活、信息密度更高的内容。

2026 年初，OpenClaw 快速走红。相比一次性完成任务的普通 AI 对话工具，它更接近一个 Agent Harness：能够管理上下文与持久化记忆、调用工具、编排多阶段任务，并通过运行记录和外部反馈持续调整执行策略。

这让我们产生了一个想法：能否基于 OpenClaw 搭建一套完整的 pSEO 内容生产体系，让 AI 不只是生成单篇文章，而是参与从关键词研究到发布、监测和迭代的全过程？更进一步，能否把审核结果、搜索表现和人工修改沉淀为可复用的数据与规则，让这套系统在持续运行中越写越好？

真正开始实践后，我们很快发现，最难的部分并不是生成文章，而是如何把研究、写作、审核、内链、图片、结构化数据、发布和反馈稳定地串联起来。

因此，我们没有把 OpenClaw 只当成一个写作助手，而是把它作为 pSEO 的 Agent 运行时，围绕它搭建了一条从关键词到发布的完整流水线。

这篇文章不讨论“AI 能不能写 SEO 内容”，而是复盘我们如何拆解这套系统、为什么采用多 Agent 架构，以及真正运行后遇到了哪些工程问题。

1. 先明确边界：pSEO 不替代人工 Blog

在设计系统之前，我们先划清了人工内容与程序化内容的边界。

高流量、高转化、高品牌价值的关键词，仍然适合人工写作，或者由 AI 生成初稿后进行深度精修。竞品对比、行业解决方案、购买决策和核心教程直接影响用户信任，不能简单追求产量。

pSEO 更适合承接另一类需求：搜索意图明确、结构相对稳定、数量庞大的中长尾关键词。例如问题型、解释型、教程型和导航型搜索。它们的单页流量不一定高，但组合起来能够扩大搜索入口、补全主题覆盖，并通过内链把用户导向高价值页面。

所以我们的目标不是“用 AI 替代编辑”，而是建立一条分工明确的内容链路：

人工 Blog 负责深度、信任、品牌和转化，pSEO 负责规模、覆盖、长尾和分发。

这个边界也决定了后面的系统设计。我们需要的不是一个万能写作 Agent，而是一套能把标准化工作稳定执行、把高风险环节留给规则和人工控制的生产流程。

2. 为什么没有做成一个超级 Agent

最直接的方案，是给一个 Agent 一份很长的 Prompt：先查关键词，再分析竞品，然后写文章、加内链、生成图片，最后发布。

这种方式演示起来很顺，但一进入持续生产就会暴露问题：

• 上下文越来越长，竞品原文、写作规则和发布协议互相挤占窗口。
• 某一步失败后很难局部重试，通常只能从头再来。
• 研究、写作和审核由同一个上下文完成，审核很容易变成自我确认。
• Agent 权限过大，写作者同时拥有发布权限，安全边界不清晰。
• 中间过程不可观察，出了问题很难判断是数据、模型还是发布环节导致的。

我们最终采用了**“主控编排 + Specialist 执行”**的两层架构。

主控 Agent 不亲自写文章，只负责接收任务、判断当前阶段、调度对应的 Specialist、验收产物并推进状态。Specialist 则各自只负责一个明确阶段，例如研究、竞品分析、写作或发布。

拆分之后，每个 Agent 的上下文更小，输入输出更明确，失败也可以在局部恢复。更重要的是，系统第一次拥有了真正的阶段边界。

3. 整体架构

主控 Agent 负责接收关键词任务并将其分派给 Workflow Agent，不直接参与文章生产。Workflow Agent 负责维护单篇文章的执行状态，依次调用八个阶段 Agent，并处理验收、返修、重试和结果回传。OpenClaw Cron 按固定时间间隔向 Workflow Agent 发送检查与继续执行消息，用于唤醒可能停滞的长流程任务。

4. 一篇文章如何经过八个阶段

目前主流程可以概括为八个阶段。

4.1 关键词研究与原始数据准备

pseo-research-agent 负责读取 Ahrefs 关键词与 SERP 数据，将原始 JSON 转成便于后续 Agent 阅读的 Markdown，并根据 SERP URL 抓取竞品页面。

这一阶段只负责采集，不急着下结论。它会保留原始数据，同时产出 ahrefs-data.md 和 competitor-pages/*.md。保留原始层很重要，因为后续发现判断错误时，我们能够回到证据，而不是只能依赖某次模型摘要。

4.2 竞品页面分析

pseo-competitor-analysis-agent 逐页分析竞品覆盖了什么、遗漏了什么、采用了哪些标题，以及原文中有哪些可以验证的证据和 FAQ。

我们给这个阶段设定了**“证据优先”**的原则：结论必须来自抓取到的页面，引用长度受限，不能为了让分析显得完整而补造内容。

这样做的目的不是模仿竞品，而是建立一张内容地图：搜索结果已经满足了哪些需求，我们还能增加什么信息，文章结构应该避开什么同质化表达。

4.3 SEO 写作

pseo-writer-agent 读取关键词数据和竞品分析，一次生成三类产物：

• seo-metadata.md：标题、摘要等 SEO 元数据。
• article-outline.md：文章结构和各章节目标。
• article-content.md：完整英文正文。

写作规则不仅包含字数和结构，还包含事实纪律、禁用表达和固定骨架。这里的关键不是把 Prompt 写得越长越好，而是把可重复检查的要求变成显式产物，让后面的审核 Agent 有东西可验。

4.4 独立质量复核与定向返修

pseo-review-agent 不参与写作，只根据 rubric 检查文章，并输出 quality-check-report.md。

审核结果只有两个有效状态：pass 或 repair_needed。如果出现 P0 问题，流程会退回 writer 的 repair 模式。返修阶段不会整篇重写，而是根据审核反馈定向修改正文，然后再次进入审核。

这个回路是整条流水线里最重要的设计之一。没有审核回退机制的 AI 内容生产，只是批量生成；具备明确验收标准和局部返修能力后，它才开始接近工程系统。

4.5 站内链接插入

文章通过内容审核后，pseo-internal-linked-agent 才开始插入内链。

它只能从本地内链库和上游提供的候选库中选择 URL，不能凭模型记忆编造链接；同一 URL 最多出现一次，H2 标题中禁止插入链接。最终生成独立的 linked-article-content.md，不直接覆盖原始正文。

把内链从写作中拆出来有两个好处：一是链接策略可以独立迭代，二是我们可以清楚地区分“内容质量问题”和“链接处理问题”。

4.6 封面图生成与上传

pseo-image-agent 根据关键词和固定视觉模板生成 4:3 封面图，校验文件大小后上传到 TOS，并把最终地址写入 cover_image.json。

图片被设计成一个独立阶段，而不是 writer 的附属能力。这样既能限制图片 Agent 的输入范围，也方便单独重试生成或上传。

4.7 结构化落盘

前面的产物最终由 pseo-json-manage-agent 汇总为固定 schema 的 article.json。

它会检查必需输入、组装 metadata、正文和封面信息，并计算阅读时长。正式产物按照 pillar、cluster 和 slug 分层保存。这个阶段相当于内容生产与发布系统之间的契约层：上游可以持续调整 Agent，下游只需要消费稳定的 JSON。

4.8 环境发布

pseo-publish-agent 负责把 article.json 上传到 TOS/Hera，并刷新 CDN 缓存。系统默认发布到 BOE，进入 online 必须二次确认；上传失败时回滚状态，避免任务显示成功但线上没有内容。

此外，我们还保留了一个非主线的人审 Agent。它只负责把中间产物和最终文章原样写入飞书文档，不改写内容，方便在需要时引入人工审核。

5. 多 Agent 系统的两个关键设计

5.1 Agent 之间不传对话，只传产物

多 Agent 系统最容易掉进的坑，是把“协作”理解成 Agent 之间不断聊天。对话看起来灵活，但难以复现，也很难验证。

我们的核心做法是建立共享产物层。每次运行都有独立目录，中间结果通过文件传递：原始关键词数据、竞品页面、分析报告、正文、审核报告、内链版本、封面信息和发布结果都可以被单独检查。

这带来了几个直接收益：

• 可恢复：失败后可以从现有产物继续，不必重复昂贵的抓取和生成。
• 可观察：看到目录中的文件，就能判断流程推进到哪一步。
• 可审计：文章中的结论可以追溯到竞品原文和研究数据。
• 可替换：更换某个 Specialist 时，只要保持输入输出契约，下游不用重写。
• 可测试：每个阶段都可以使用固定输入进行独立验收。

换句话说，OpenClaw 负责运行 Agent，而文件协议让这些 Agent 组成了一套系统。

5.2 不同阶段使用不同的 Agent 和模型

多 Agent 架构的另一个价值，是不必让所有阶段共享同一个模型。不同任务对模型能力、响应速度和调用成本的要求并不相同，如果全程使用能力最强、价格最高的模型，不仅成本难以控制，也未必能获得更好的整体效果。

我们的做法是根据阶段特征选择 Agent 和底层模型。例如，写作阶段直接决定文章的结构、表达和信息密度，因此使用更擅长长文写作、但调用成本也更高的 Gemini 3 Pro；页面抓取与初步处理数量大、调用频繁，更关注推理效率和单位成本，因此使用价格较低且擅长推理的 DeepSeek V4 Pro。

这种分配方式把模型选择从全局配置变成阶段配置。后续更换模型时，只需调整对应的 Specialist，不必改动整条工作流。模型升级、成本优化和效果对比也可以在单个阶段内独立进行。

6. 真正运行后，我们发现了哪些问题

架构拆分并不等于系统已经稳定。实际运行暴露的问题，反而帮助我们看清下一阶段该优化什么。

6.1 上下文溢出

上下文溢出并不只发生在竞品分析阶段。竞品分析需要逐页读取大量 Markdown，页面一多，单个阶段的输入就可能超过上下文限制。与此同时，Workflow Agent 还要编排从研究到发布的完整长流程，持续接收各阶段的状态、结果和错误信息，本身也会积累大量上下文。

更严重的问题出现在批量任务中。我们最初让同一个 Workflow Agent 连续处理多个关键词，新关键词开始执行时没有清空上一轮上下文。随着任务不断推进，前面关键词的研究结果、执行日志和异常记录会持续留在会话中，不仅占用窗口，还可能干扰当前关键词的判断。

**正确的隔离粒度应该是一个关键词对应一次全新的 Workflow Agent 会话。**主控 Agent 每次分派关键词时，都启动一个上下文为空的 Workflow Agent；任务需要继承的状态通过文件和结构化产物传递，而不是保留在历史对话中。单个阶段内部则继续通过分批处理、单页摘要缓存、输入截断规则和 token 预算控制长输入。

**上下文必须被视为有生命周期和容量限制的运行资源，而不是可以无限追加的任务记录。**会话负责当前关键词的推理，文件负责跨阶段和跨任务的持久化，二者需要明确分工。

6.2 Agent 对文件路径的理解不稳定

实际运行中，路径规则本身是统一的，但 Agent 对规则的理解并不总是稳定。即使 Prompt 已经明确指定输入和输出目录，Agent 偶尔仍会自行推断路径，把文件写入相邻目录、旧的运行目录或它认为更合理的位置。文件虽然生成成功，Workflow Agent 却无法在约定位置找到它，最终仍会把阶段判断为失败。

继续增加路径说明并不能从根本上解决这个问题。路径拼接、目录创建、文件命名和产物校验都属于确定性操作，不应该交给模型临场判断。

更可靠的做法是为各阶段提供统一脚本，将路径规则封装在程序中。Agent 只需要调用指定脚本并填写关键词、运行 ID、产物类型等必要参数，不再直接计算或选择文件路径。脚本负责把文件写入正确位置，并返回标准化的产物信息供 Workflow Agent 验收。

这也是我们逐渐形成的一条原则：**Agent 负责理解任务和生成内容，脚本负责执行可以被确定性描述的操作。**减少模型需要自行判断的细节，比反复强化 Prompt 更能提升流水线的稳定性。

6.3 状态记录不够严格，也缺少统一监控

目前各阶段虽然会输出 JSON 状态，但结构约束还不够严格，部分字段、状态值和错误信息仍由 Agent 自行理解和记录。同一种执行结果可能被写成不同格式，Agent 也可能遗漏状态更新，导致 Workflow Agent 难以稳定判断阶段是否完成、是否需要重试，以及应该从哪里恢复。

**执行状态不应该依赖 Agent 的主动性。**每个阶段都需要使用严格的 JSON Schema、固定状态枚举和标准错误码，并由统一脚本负责写入和校验。Agent 只提交必要参数和产物，脚本根据执行结果更新状态，避免让模型直接维护流程控制数据。

另一个缺口是缺少统一的 Dashboard。现在排查任务主要依赖运行目录、日志和产物文件，无法快速看到有哪些关键词正在执行、停在哪个阶段、重试了多少次、最终是否发布成功。

后续需要建立一套能够同时监控执行过程和分析执行结果的 Dashboard。它不仅要展示任务状态、阶段耗时、错误类型和重试次数，还要汇总文章产量、审核通过率、发布结果等指标。这样我们才能从单次任务排障进一步走向整条内容流水线的运行分析和持续优化。

6.4 Prompt 规则缺少程序化校验

例如证据引用长度、FAQ 必须来自原文、H2 不能包含内链等要求，目前部分仍依赖 Prompt 约束。模型遵守规则的概率可以很高，但生产系统不能只依赖概率。

凡是可以确定性判断的规则，都应该下沉到脚本或 schema 校验。让模型负责语义，让程序负责边界，是更可靠的分工。

6.5 用 Cron 消息唤醒停滞任务

长流程运行时，Workflow Agent 偶尔会停在某个阶段，没有报错，也没有继续执行。针对这种情况，我们使用了 OpenClaw 的 Cron 机制：按照固定时间间隔，向 Workflow Agent 发送一条检查当前状态并继续执行的消息。

当 Workflow Agent 卡住时，新消息会触发新一轮处理。它会重新读取当前上下文和已有产物，大概率能够识别尚未完成的阶段，并继续向后推进。这套机制实现简单，对偶发的任务停滞有明显效果。

不过，**Cron 本质上只是定时唤醒，而不是严格的任务恢复机制。**它无法准确判断 Agent 是仍在正常执行、等待外部服务，还是已经真正停止，也不能保证每次唤醒都能从正确阶段继续。后续仍需要把阶段状态、最近活动时间和重试次数记录为结构化数据，让 Cron 根据明确状态决定是否恢复任务，而不是仅依赖一条定时消息推动 Agent 继续运行。

7. 总结

传统 pSEO 通过模板和结构化数据扩大页面规模，生成式 AI 则让研究、分析和长文写作也可以进入程序化流程。但 AI 带来的不只有内容能力，还有上下文溢出、执行不稳定、状态不确定和成本不可控等新的工程问题。

我们的核心做法不是打造一个能力更强的超级 Agent，而是**限制每个 Agent 的职责，用 Workflow 编排阶段，用共享产物连接阶段，用脚本约束确定性操作，再用审核和返修守住质量边界。**OpenClaw 在其中承担的是 Agent Harness 和运行时的角色，而不是单纯的写作工具。

这套系统仍然处在持续完善中。一个关键词一个全新 Workflow 会话、统一脚本处理文件、严格的状态 Schema，以及能够监控执行过程和分析结果的 Dashboard，都是接下来需要补齐的能力。Cron 可以暂时唤醒停滞任务，但最终仍需要由明确的状态和恢复机制保证流程可靠运行。

**pSEO 的长期价值不在于让 AI 无限生成页面，而在于建立一条能够吸收审核结果、运行问题和搜索反馈，并持续改进的内容生产闭环。**模型会变化，Agent 也可以替换，真正能够积累下来的，是流程、规则、产物协议和反馈数据。