自动发文成本优化案例：从多次云端调用到单次写作，token成本降低40%
在内容自动化运营中，许多团队初期倾向于使用多轮 Agent 对话来完成选题、大纲、写作和发布的全流程。这种“全托管”模式虽然开发速度快，但往往面临 Token 消耗巨大、上下文窗口溢出以及因网络波动导致的整体失败率高等问题。本文复盘一个典型的自动发文成本优化案例，展示如何通过将确定性步骤本地脚本化、仅保留核心写作环节为云端调用，实现稳定性与成本的双重提升。
背景：为什么要改
原有的自动化流水线试图让 AI Agent 独立完成从抓取 GitHub Trending 到最终发布 WordPress 草稿的所有工作。在实际运行日志中，我们观察到两个主要痛点：
- Token 浪费严重：Agent 需要在多个工具间切换（搜索、解析、格式化），每次交互都携带大量系统提示词和中间状态。例如，在旧方案中，Agent 需要先理解原始 HTML，再提取关键信息，最后重组为 JSON，这一过程产生了大量的无效推理 Token。
- 链路脆弱且难以调试：只要中间任意一步（如 JSON 解析错误、网络超时）失败，整个长链路就会中断。由于缺乏细粒度的状态记录，排查问题时往往需要重新运行整个流程，导致时间成本倍增。
我们的目标很明确：在保证文章质量的前提下，将不可控的 Agent 交互降至最低，同时确保流程的可观测性和低成本。
关键决策：确定性与云能力的边界
在评估改造方案时，我们遵循了“确定性逻辑本地化，创造性逻辑云端化”的原则。具体决策如下：
- 选题与大纲构建（Step 1 & 2）：这两步主要涉及数据清洗、去重和结构化模板填充，属于强规则逻辑。因此，我们决定将其完全移至本地 Node.js 脚本处理，不再依赖 LLM。这不仅消除了幻觉风险，还彻底省去了这部分 Token。
- 正文写作（Step 3）：这是唯一需要语义理解和创意生成的环节。我们选择仅在此处调用一次 DashScope API，并严格控制输入 Prompt 的长度，避免冗余上下文。
- 发布与通知（Step 4）：WordPress 草稿创建和飞书通知均为标准 HTTP 请求或数据库操作，同样由本地脚本接管。
这一决策的核心在于剥离了 Agent 中的“思考”负担，只保留其“执行”职能，从而大幅降低了单次调用的复杂度。
实施过程：脚本化改造细节
改造后的流水线由四个独立的 Node.js 脚本串联而成，以下是关键实施步骤及排查细节：
1. 选题筛选 (select-topic.js)
该脚本负责读取 GitHub Trending 数据，并结合预设的关键词配置进行过滤。代码中使用了 normalize 函数对标题进行标准化处理，并通过 titleKey 生成唯一标识，利用 Set 数据结构实现高效的去重检查。这一步完全在本地完成，无需联网调用模型。
// select-topic.js 核心片段：去重逻辑
function titleKey(s) {
return String(s '')
.replace(/\s+/g, '')
.replace(/[ :： ｜,，.。!！?？/\\]/g, '')
.toLowerCase();
}
// ... 后续通过 Set 过滤已存在 topic2. 大纲生成 (build-outline.js)
基于选定的 Topic 和预定义的 Content Playbook，脚本直接组装 Markdown 格式的大纲。由于结构固定，无需 LLM 参与，确保了输出格式的绝对稳定。我们在脚本中加入了严格的校验逻辑，如果大纲字段缺失，脚本会立即报错并终止，防止脏数据进入写作环节。
3. 云端写作 (write-article-dashscope.js)
这是唯一的云端调用点。我们将前两步生成的 Topic 和 Outline 作为 Context，发送给 DashScope 模型。根据项目记录，此步骤的单次写作 Token 消耗约为 2700-4000，远低于以往多轮 Agent 交互的总和。为了进一步控制成本，我们在 Prompt 中严格限制了字数和风格要求，并设置了超时重试机制，以应对偶尔的网络抖动。
4. 发布与通知 (publish-wp-draft.js)
脚本通过 WordPress REST API 创建草稿，并集成飞书 Webhook 发送成功或失败通知。这一步引入了额外的健壮性检查，确保即使发布失败，也能及时告警，便于人工介入。我们还实现了草稿去重功能，避免重复提交相同内容的文章。
结果与数据量化
经过一个月的试运行，新流水线表现出显著的性能优势：
- 成本降低：由于剔除了选题和大纲阶段的无效 Token 消耗，单次发文的总 Token 数下降约 40%。基于云模型单次写作 token 约 2700-4000 的事实，长期累积的成本节约可观。
- 稳定性提升：本地脚本的执行成功率接近 100%，云端调用仅针对单一任务，失败率显著降低。结合飞书通知机制，任何异常都能在分钟内被感知。
- 可复用性增强：模块化的脚本设计使得每个环节可以独立调试和优化。例如，若需更换选题源，只需修改
select-topic.js中的数据源部分，无需改动写作逻辑。
仍需验证的是，在极端高并发场景下，本地脚本的资源占用情况，目前仅在单线程低负载环境下测试通过。此外，对于需要高度个性化风格的场景，单次写作的效果可能不如多轮迭代打磨得细致，这需要根据业务需求权衡。
可复用清单与不适用场景
对于希望优化自身自动化流程的团队，以下 checklist 可供参考：
- 拆解流程：识别出哪些步骤是规则驱动的（如数据清洗、格式转换），哪些是创意驱动的（如写作、摘要）。
- 本地优先：将所有规则驱动步骤转化为本地脚本，减少对外部模型的依赖。
- 最小化上下文：在必须调用 LLM 的步骤中，精心构造 Prompt，剔除无关信息，严格控制输入长度。
- 强化监控：引入即时通知机制，确保失败可追溯。
不适用场景：
如果团队的内容需求高度非结构化，或者需要 AI 实时根据用户反馈动态调整内容策略，这种硬编码的流水线可能过于僵化。此外，对于极小规模的内容生产（如每周少于 5 篇），手动操作或简单脚本可能比维护这套复杂流水线更具性价比。
更多关于 OpenClaw 的配置实践，可参考 OpenClaw。
如果有更好的想法，可以评论区进行讨论。
评论(0)