流程先于智能 — 二途序

问题从哪里来

这一周做了很多和自动化有关的事：博客自动生成、GitHub API 发布文档、OpenHuman 记忆模块、RSS 分析、ArchPilot 课程生成，还有 Waaao Agent 的分层架构。

表面看方向不一样。一个是写博客，一个是发文档，一个是记忆系统，一个是多 Agent 协作。

但它们背后卡住的是同一个问题：怎么让 AI 从一次性问答，变成可以持续工作的系统。

如果只是让模型回答问题，它通常能给个不错的结果。

但任务一变长，问题就出现：它不知道先读哪些上下文，不知道哪些内容能写进公开文档，不知道什么时候该停止，也不知道结果算不算完成。

所以真正要解决的不是」模型够不够聪明」，而是」任务有没有流程」。

真正卡住的是边界

自动化系统最容易失控的地方，是边界不清。

比如博客自动发布，不能只说」根据日志写篇博客」。它至少要知道：

输入在哪里。
周记放哪里。
博客保存到哪个目录。
frontmatter 怎么写。
日期用哪一天。
哪些文件可以提交。
最后怎么验证。

Agent 系统也是一样。一个全能助手同时负责理解需求、拆任务、执行、验收、记忆更新，很快变成一团混乱。看起来什么都能做，实际每一步都不好检查。

更稳的做法是把职责拆开：

flowchart LR
    A[入口 Agent<br/>接收意图] --> B[Universal Agent<br/>理解上下文/拆解/计划]
    B --> C[专家 Agent<br/>独立子任务]
    C --> D[复盘<br/>判断是否达标]
    D --> E[记忆模块<br/>沉淀长期信息]

这样拆不是为了让架构复杂，而是让每一步都有输入、输出和验收标准。

我最后怎么处理

我把这类任务统一看成一条流程，而不是一段提示词。

一个可执行的流程大概是：

RESEARCH -> PRD -> TECH -> PLAN -> EXECUTE -> TEST(E2E)

这条链路的价值在于，每一步只回答自己的问题：

RESEARCH 负责事实和上下文。
PRD 负责目标。
TECH 负责方案。
PLAN 负责拆解。
EXECUTE 负责落地。
TEST 负责证明结果。

博客生成也可以套同样的逻辑：

先读每日志，不急着写。
再整理每天的任务、方案、效果和思考。
然后生成周记，找出本周主线。
最后只围绕一个点写博客。
发布前检查 frontmatter、日期、标签、保存目录和 git 状态。

这比」写一篇博客」麻烦一点，但结果更稳定。它把模型容易遗漏的部分变成了明确步骤。

这件事留下的经验

Agent 的能力，不只体现在输出文本上，更体现在能不能按约束完成一件事。

约束包括流程，也包括安全边界。

这周的原始日志里出现过 token、API Key、SSH 信息。它们可以用于当时调试，但不应进入周记、博客或仓库。自动化越强，越要提前定义什么能写、什么必须脱敏。

还有适配边界。DMXAPI 图像模型可能返回 base64，也可能返回 URL；不同 LLM 渠道有不同参数；不同开源项目文档完整度也不同。系统不能假装差异不存在，要把差异收进适配层和验证流程里。

最后留下的判断是：流程不是 Agent 的负担，而是 Agent 的骨架。没有流程，模型只能临场发挥；有了流程，模型才有机会稳定完成长期任务。