二途序

流程先于智能

问题从哪里来

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

表面看这些方向不一样。一个是写博客，一个是发文档，一个是记忆系统，一个是多 Agent 协作。但它们背后卡住的是同一个问题：怎么让 AI 从一次性问答，变成可以持续工作的系统。

如果只是让模型回答问题，它通常能给出一个看起来不错的结果。但一旦任务变长，问题就会出现：它不知道先读哪些上下文，不知道哪些内容能写进公开文档，不知道什么时候该停止，也不知道结果算不算完成。

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

真正卡住的是边界

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

比如博客自动发布，不能只说「根据日志写篇博客」。它至少要知道输入在哪里、周记放哪里、博客保存到哪个目录、frontmatter 怎么写、日期用哪一天、哪些文件可以提交、最后怎么验证。

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

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

  • 入口 Agent 负责接收用户意图。
  • Universal Agent 负责理解上下文、拆解任务、制定计划。
  • 专家 Agent 负责独立子任务。
  • 复盘环节负责判断结果是否达标。
  • 记忆模块负责沉淀长期信息。

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

我最后怎么处理

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

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

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 的骨架。没有流程，模型只能临场发挥；有了流程，模型才有机会稳定地完成长期任务。