上一版 pSEO 系统中，我们用 OpenClaw 管理多个 Specialist Agent，让它们依次完成关键词研究、竞品分析、写作、审核、内链、图片、结构化落盘和发布。

这套方案证明了多 Agent 可以完成一条长内容链路，但运行一段时间后，问题也越来越集中：任务偶尔停在中间，需要 Cron 发送消息唤醒；Workflow Agent 的上下文会随着关键词和阶段不断增长；同一个流程既要理解内容，又要判断状态、安排重试和调度下游；为了推进一个确定性的步骤，也可能产生一次模型调用。

重构前，一次任务的执行成功率约为 60%，生成一篇文章的模型成本约 30 美元，完整执行平均需要 40 分钟。更麻烦的是，这些数字并不稳定：随着 Workflow Agent 的上下文持续增长，任务会越来越慢，失败率也会继续升高。

切换到 Workflow + OpenCode 节点 Agent 后，执行成功率提升到 95%，单篇文章成本降到 5 美元以下，平均执行时间缩短到 20 分钟。我们不是通过更换一个更强的模型获得这些结果，而是把流程控制从 Agent 的上下文中移回了代码。

这些问题表面上分别属于稳定性、上下文和成本，根因却是同一个：

我们让 Agent 承担了工作流引擎的职责。

Agent 擅长理解语义、分析页面和生成内容，但状态流转、依赖判断、超时、重试、并发和发布，本质上都是确定性问题。用概率模型管理确定性流程，会给状态和调度引入不必要的不确定性。

因此，我们重新设计了整条链路：用代码 Workflow 作为唯一控制面，只在需要语义能力的节点调用 OpenCode Agent。 OpenCode 负责加载节点 Agent 的指令、模型和工具，并以独立 session 执行单个节点，但不负责决定整条流程如何推进。

新的结构不再存在一个负责全流程推理的 Workflow Agent。Workflow 知道下一步应该运行什么，Agent 只需要完成当前节点。

1. 旧方案的问题，不是再加一层 Prompt 就能解决

OpenClaw 方案中，Workflow Agent 需要持续处理三类信息：

• 任务信息：当前关键词、pillar、cluster、slug 和目标环境。
• 内容信息：Ahrefs 数据、竞品原文、文章正文、审核报告和内链候选。
• 控制信息：当前阶段、前置依赖、失败原因、重试次数和下一步动作。

这三类信息的生命周期并不相同。内容信息只应该存在于某个具体节点，任务状态需要跨节点持久化，流程规则则应该长期固定。把它们都放进一个 Agent 会话后，上下文会持续膨胀，边界也会越来越模糊。

例如，一个关键词完成研究和竞品分析后，Workflow Agent 已经读入大量页面；进入写作阶段时，它还要继续保留之前的调度记录；审核退回后，又会叠加审核报告、返修指令和新一轮正文。处理多个关键词时，如果会话没有彻底隔离，上一轮任务还可能干扰下一轮判断。

更麻烦的是，Agent 的一次“执行成功”不等于阶段真的成功。它可能已经生成正文，却忘记更新状态；也可能更新了状态，但文件写到了错误目录；还可能说任务已经完成，而必需产物并不存在。为了修复这些问题，我们会继续给 Prompt 增加路径规则、状态规则和检查规则，最终却只是让 Workflow Agent 的职责更重。

这不是模型能力不足，而是职责分配错误。

2. 新架构：Workflow 管流程，Agent 做节点

重构后的核心结构如下：

这张图最重要的变化不是节点名称，而是箭头由谁控制。

在旧方案中，箭头存在于 Workflow Agent 的 Prompt 和上下文中。Agent 读取状态后，自行决定调用哪个 Specialist、是否重试、是否继续。新方案中，箭头直接写在 Workflow 的 DAG 和依赖规则里。只有当前置节点满足条件，调度器才会把任务放入下一个节点。

每一个关键词在逻辑上都有一份独立的 DAG 状态。Workflow 负责：

• 解析节点依赖。
• 维护 pending、running、done 和 failed 状态。
• 控制并发数量。
• 记录每次 attempt 的开始和结束时间。
• 在超时或进程异常后执行重试。
• 校验节点返回值和落盘产物。
• 从已有状态恢复，而不是重新跑完整流程。
• 汇总日志、耗时和模型成本。

OpenCode Agent 负责：

• 理解竞品页面并提炼内容机会。
• 设计文章结构和生成正文。
• 完成需要语义判断的质量审核。
• 在不破坏阅读体验的前提下插入内链。
• 根据主题生成符合视觉规范的图片。

换句话说，Workflow 决定“何时做、由谁做、失败后怎么办”，Agent 只决定“这个内容任务应该怎么完成”。

3. 不是所有节点都需要 Agent

重构时，我们先重新审视了每个阶段：它究竟需要语义推理，还是只需要稳定执行一组明确规则？

最终，节点被分成两类。

迁移后的判断标准很直接：凡是可以通过固定输入、规则和退出码描述的工作，都不再调用 Agent；只有必须理解语义或生成内容的节点才保留 Agent。 对于审核和内链这类混合任务，Agent 负责主观判断，脚本负责可以确定性验证的边界。

3.1 确定性节点

关键词初始化、Ahrefs 数据获取、SERP 页面抓取、JSON 组装、文件上传、URL 回填和 pSEO library rebuild，都不需要模型参与。

以 Research 节点为例，它接收 keyword、country、SERP 数量和抓取配置，完成以下工作：

1. 优先读取已有缓存，没有缓存时调用 Ahrefs。
2. 保留原始 JSON，并渲染一份后续 Agent 更容易读取的 Markdown。
3. 从 SERP 数据中提取目标 URL。
4. 抓取竞品页面并记录成功与失败列表。
5. 输出统一的结果 JSON，包括文件路径、数量和风险信息。

这些步骤都可以由确定性规则完整表达。脚本能提供稳定的输入、明确的退出码和可重复执行的结果，也不会因为 Prompt 理解偏差把文件写到错误位置。

JSON 节点同样如此。它等待内链正文和封面图两个上游节点完成，然后检查 seo-metadata.md、linked-article-content.md 和 cover_image.json 是否存在，使用严格输入模式组装正式 article.json。发布节点再根据目标环境上传文件，成功后回填 BOE URL 并触发 pSEO library rebuild；上传失败则保留失败结果，交给 Workflow 决定是否重试。

把这些阶段从 Agent 中移出后，我们不仅减少了模型调用，也把大量不可预测行为变成了普通程序错误。程序错误可以通过退出码、日志和测试定位，不需要重新猜测 Agent 当时为什么没有继续执行。

3.2 Agent 节点

竞品分析、写作、主观审核、内链语义选择和图片生成仍然适合由 Agent 完成，因为这些任务依赖语义理解或创作能力。

但 Agent 的调用粒度发生了变化：一个关键词、一个节点、一次独立调用。

例如 Writer Agent 只接收：

• 当前关键词及必要的分类信息。
• ahrefs-data.md。
• competitor-page-analysis.md。
• 写作规范和输出协议。
• 首次写作或定向返修模式。

它不需要知道整个批次有多少关键词，不需要知道图片是否完成，也不负责决定文章何时发布。完成后，它只返回当前节点的结构化结果，并写出 seo-metadata.md、article-outline.md 和 article-content.md。

这使 Agent 的 Prompt 更短，权限更小，失败影响范围也更有限。即使某个 Writer Agent 异常，也只会影响一个关键词的 write 节点，不会拖住一个长期运行的 Workflow Agent 会话。

4. 用产物协议连接节点，而不是用对话传递记忆

多 Agent 系统很容易把“协作”做成多个 Agent 相互发送消息。我们的新方案反过来：节点之间没有必须继承的对话，只共享经过约束的文件产物。

每个关键词拥有独立目录：

cache/{slug}/
├── ahrefs-data-raw.json
├── ahrefs-data.md
├── competitor-pages/
├── competitor-page-analysis.md
├── seo-metadata.md
├── article-outline.md
├── article-content.md
├── quality-check-report.md
├── linked-article-content.md
├── cover_image.webp
├── cover_image.json
└── result-{stage}.json

Markdown 适合人和 Agent 阅读，JSON 适合 Workflow 验收。两者承担不同职责。

以 quality_check 节点为例，审核 Agent 可以在 quality-check-report.md 中详细解释标题、结构、事实、表达和 SEO 问题；result-quality_check.json 只提供 Workflow 真正需要的字段，例如：

{
  "status": "completed",
  "slug": "example-keyword",
  "stage": "quality_check",
  "outputs": {
    "pass_decision": "repair_needed",
    "quality_check_report": "cache/example-keyword/quality-check-report.md"
  },
  "next_step_recommendation": "repair",
  "risks": ["P0: missing required evidence"]
}

Workflow 不需要理解整份审核报告，只需要读取 outputs.pass_decision。如果结果是 repair_needed，它记录本次审核 attempt，再把当前关键词的 write 和 quality_check 节点重新放回 pending，下一次直接以 repair 模式调用 Writer Agent，并在修订后重新审核；如果结果是 pass，才开放 internal_linked 和 image 节点。

这样做有三个直接收益：

• 节点可以独立重跑，不依赖之前的会话历史。
• 任意结果都能回溯到输入文件和输出文件。
• 替换模型或 Agent 实现时，只需要保持产物协议不变。

对话是临时计算过程，产物才是工作流中的长期事实。

5. 状态机取代“发消息问它做到哪了”

旧方案遇到任务停滞时，会通过 Cron 向 Workflow Agent 发送一条“检查当前状态并继续执行”的消息。它有时有效，因为新消息会触发 Agent 重新读取上下文和文件；但它无法回答几个关键问题：Agent 是仍在执行、正在等待外部服务，还是已经停止？再次唤醒会不会重复执行？应该从哪个节点恢复？

新方案不再通过消息猜测任务状态，而是为每个关键词的每个节点保存显式状态：

pending -> running -> done
                   -> pending  // 未超过重试次数
                   -> failed   // 重试耗尽

我们为每次执行定义了一条 attempt 记录，包括 startedAt、endedAt、节点名称、关键词 slug、Agent session、退出状态和结果路径。调度器只允许满足依赖的 pending 节点进入运行池。

如果进程中断，Workflow 重启后会读取状态文件：

• done 节点直接跳过。
• pending 节点重新进入候选队列。
• 超时的 running 节点结束当前 attempt，并按重试规则处理。
• 已达到最大重试次数的节点保持 failed，避免无限消耗资源。

状态更新也不再由 Agent 主动完成。Agent 可以返回内容和结果，但 Workflow 的节点 validator 只有在三项检查全部通过后才会执行 markDone：进程正常退出、结果满足 schema、必需产物真实存在。

这一区别很重要。Agent 说“完成了”只是一个返回值，Workflow 验收通过才是阶段完成。

6. 上下文优化不再依赖“记得清空会话”

上下文问题在新架构中不再是运行技巧，而是由调用边界直接解决。

每个 Agent 节点只读取当前任务所需的最小输入。竞品分析节点不需要文章正文；Writer 不需要发布日志；图片节点不需要 Ahrefs 的完整原始 JSON；发布节点甚至不需要 Agent。

同一个关键词进入返修时，也不必把整个 Workflow 历史重新塞给 Writer。它只需要当前正文、审核报告和必要的 metadata。跨阶段信息通过文件传递，跨任务信息通过结构化状态传递，Agent 会话不承担持久化职责。

因此，上下文隔离自然形成了三层：

• 批次级：只保存关键词列表、DAG 状态和全局配置。
• 关键词级：保存该文章的研究、正文和图片等共享产物。
• 节点级：只在一次 Agent 调用中加载完成当前任务所需的信息。

一个关键词不会继承另一个关键词的会话，一个节点也不会无条件继承上一个节点的全部内容。上下文从“不断追加的聊天记录”变成了“按节点装载的输入资源”。

这也让 token 使用更容易控制。我们可以为每类节点设置独立模型、输入预算和超时：竞品分析选择推理成本更低的模型，长文写作使用更擅长结构和表达的模型，确定性节点保持零模型调用。每次启动节点时，Workflow 会同时持久化 slug、node、attemptId 和 sessionId，因此模型成本可以直接归属到一次具体执行，而不是只得到整条流程的总账。

7. 审核返修成为 DAG 中的一条明确回边

内容系统中最容易失控的部分，是 Writer 和 Reviewer 之间的返修。

如果返修只存在于 Prompt 中，Reviewer 说“需要修改”后，谁负责重新调用 Writer、最多修改几次、修改后从哪里继续，都要由 Agent 临场决定。新方案把它直接写成 DAG 的一条回边：

write -> quality_check -> pass -> internal_linked
              |
              └-> repair_needed -> write(repair)

quality_check 节点内部先运行确定性脚本，检查 metadata 格式、关键词位置、标题层级、链接规则等客观项，再由审核 Agent 判断信息完整性、表达质量和事实风险。任何 P0 问题都会生成结构化的 repair_needed。

Workflow 收到结果后，重置当前关键词的 write 和 quality_check 节点，并保留之前的 attempt 记录。Writer 在 repair 模式下根据审核报告定向修改，而不是重新生成整篇文章；修改完成后，quality_check 再执行一次。达到最大循环次数后仍未通过，任务进入 failed，不会因为 Agent 想“再试一次”而无限循环。

审核因此不再是一次建议，而是一个有入口、有出口、有上限的流程节点。

8. DAG 让真正可并行的工作同时发生

旧流程通常按阶段整批推进：所有关键词研究完成后再统一分析，分析完成后再统一写作。某个慢任务可能让同一批中的其他任务一起等待。

Workflow 按 ready node 调度单个关键词。关键词 A 完成 analysis 后，可以立即进入 write，不必等待关键词 B 的竞品页面抓取结束。并发池释放一个位置后，调度器马上补入下一个 ready 节点，而不是等待整批任务全部完成。

同一关键词内部也不必完全串行。审核通过后，封面图和内链处理可以同时执行；JSON 节点只需要等待 internal_linked 和 image 两个分支汇合：

这种并行不是让 Agent 自己决定“顺便再做一件事”，而是由 DAG 明确声明依赖。调度器可以准确知道哪些节点已 ready、哪些节点正在占用模型配额、哪些节点仍在等待上游产物。

9. 改造后的实际效果

架构改造完成后，我们对同一条 pSEO 生产链路重新统计了三个核心指标：

执行成功率提升了 35 个百分点，平均耗时缩短了一半，单篇成本下降超过 83%。但比单次数据更重要的是，新的执行曲线不再随着任务推进持续恶化。

旧架构中的 Workflow Agent 既要记住之前发生了什么，又要继续决定下一步做什么。研究数据、竞品页面、生成正文、审核反馈、调用记录和错误信息不断进入同一个上下文。运行时间越长，上下文越大，单次推理越慢，模型也越容易遗漏状态或做出错误的阶段判断。一个关键词发生返修，还会进一步放大后续调用的输入规模。

新架构把这种累积效应切断了。代码 Workflow 保存长期状态，节点 Agent 每次只加载当前关键词、当前节点所需的输入。已完成阶段通过结果 JSON 和文件产物交接，不需要在后续会话中重复携带。失败重试也只重跑当前节点，不再重新消耗上游研究、写作或图片节点的成本。

成本下降同样不是单纯来自使用更便宜的模型，而是减少了三类无效调用：

• 不再让模型判断确定性的状态流转和路径操作。
• 不再为了唤醒停滞的 Workflow Agent 反复发送上下文消息。
• 不再因为局部失败而重跑整条内容链路。

Dashboard 最终记录每个关键词、节点和 attempt 的状态、耗时、重试次数与模型成本。成功率、成本和执行时间因此不再是任务结束后的粗略估算，而是可以定位到具体节点的运行数据。

10. 稳定性来自减少不确定性，而不是增加监控消息

Workflow + OpenCode 并不会让模型本身变得确定。竞品分析仍可能遗漏信息，Writer 仍可能写出不合格内容，图片生成也可能失败。新的架构解决的不是“让 Agent 永不出错”，而是把错误限制在一个可识别、可恢复的节点里。

它带来的稳定性主要来自五个变化：

1. 控制逻辑确定。 节点依赖、最大重试次数、并发和发布环境由代码决定。
2. 上下文隔离。 每个关键词、每个节点使用独立输入，不积累全流程历史。
3. 结果可验收。 进程退出、JSON schema 和文件产物必须同时满足要求。
4. 失败可局部恢复。 某个节点失败后只重跑该节点，不重复研究和其他昂贵步骤。
5. 成本可归因。 每次 Agent 调用都对应具体的关键词、节点和 attempt。

以前排查一个停滞任务时，我们需要查看会话、猜测 Agent 是否还会继续，再检查目录里缺了什么。现在只需要从状态中找到失败节点，查看它的输入、结果 JSON、日志和 Agent session。排障对象从一段长对话变成了一次明确的函数调用。

11. Agent 的权限也应该跟着节点缩小

当 Workflow Agent 负责全流程时，它通常同时拥有读写文件、启动子 Agent、调用外部服务和发布内容的权限。只要一次判断出现偏差，影响范围就可能跨越多个阶段。

节点化之后，权限可以按职责拆开：

• Analysis Agent 通过工具白名单和文件系统沙箱，只能读取研究数据并写分析报告。
• Writer Agent 首次写作时读取研究与分析产物；repair 模式额外读取现有正文、metadata 和审核报告，写权限只覆盖文章产物。
• Reviewer 读取正文、metadata 和审核规则，只能写审核报告与结构化结果。
• Internal Link Agent 只能读取正文和候选链接库，写入独立的内链版本。
• 发布脚本不经过内容 Agent，BOE 到 Online 之间设置独立的人工审批节点，审批结果也作为 DAG 状态持久化。

这不只是安全优化，也会提高执行稳定性。能力越少，Agent 需要判断的事情越少，产生意外副作用的空间也越小。

12. 最终留下来的不是某个 Agent，而是一套可替换的节点系统

重构之后，OpenCode 是 Agent 节点的运行环境，但它不再是工作流本身。未来更换某个模型、调整 Writer 规则，甚至替换整个竞品分析 Agent，都不会改变状态机和发布链路。

真正稳定的接口只有三部分：

• 节点输入。
• 节点输出 schema。
• 节点产物路径。

只要新 Agent 遵守这三个协议，Workflow 不需要知道它内部如何推理。相反，Research、JSON 和 Publish 这类确定性节点也可以持续替换实现，而不影响内容 Agent。

这让 pSEO 系统从“一组能够相互配合的 Agent”，变成了“一条允许 Agent 作为节点存在的内容生产基础设施”。

13. 总结

OpenClaw 方案帮助我们验证了多 Agent pSEO 的可行性，也让我们看清了长流程真正的难点：不是生成一篇文章，而是稳定地管理状态、依赖、上下文、重试、成本和发布边界。

当 Workflow Agent 同时承担内容理解和流程控制时，这些问题会相互放大。上下文越长，判断越不稳定；为了恢复不稳定任务，需要更多消息和模型调用；调用越多，成本和状态又越难追踪。

Workflow + OpenCode 的重构，本质上是重新划分确定性与不确定性的边界：

代码负责确定流程，Agent 负责处理语义；状态通过机器协议流转，内容通过文件产物流转。

这样做并没有消除 Agent 的不确定性，而是让这种不确定性只存在于它真正有价值的地方。一个 Agent 可以失败，但不能让整条流程失去状态；一次写作可以返修，但不能无限循环；一个节点可以更换模型，但不能改变下游协议。

pSEO 内容工厂要长期运行，最终依赖的不会是某个更强的 Workflow Agent，而是一套能够准确调度节点、隔离上下文、验收产物并从失败处恢复的工作流。Agent 是其中最有创造力的执行单元，但 Workflow 才是让它们稳定协作的基础。