启动、反思、收尾：Agent 工作流的原生生命周期

英文版：Start, Reflect, Finalize: The Native Lifecycle of an Agent Workflow

绝大多数 AI 协作还停留在最原始的阶段：用户交代任务，模型开始“思考”，双方都祈祷关键上下文没在对话里丢失。

问个一次性问题，这样凑合还行。真要跑严肃的工作流，这套玩法就行不通了。

Agent 驱动的项目绝非一句提示词那么简单。它更像一套微型操作系统，包含法则、角色、工具、记忆、归档、凭证规则、对外输出规范以及交接文档。如果 Agent 冷启动后不经 briefing 就直接发表意见，那跟没看材料就进场指点江山的顾问没两样；如果干完活直接消失，无异于拔电源关机，而不是正常执行 shutdown 流程。

《Workflow Design Bible》的第三层核心，并非什么生产 tricks，而是一套完整的生命周期协议。

在我自己的工作流里，有四个技能撑起了这套原生生命周期：

这四者构成了 Agent 驱动型公司的原生启停闭环。

为什么工作流需要“开机仪式”

AI 工作流最危险的时刻，往往不是报错失败，而是模型自信满满输出的第一段话。

模型在代码仓库里醒来，扫到几个文件，拼凑起零碎的上下文记忆，便开始规划。计划听起来头头是道，甚至大方向也没错。但“大方向没错”正是工作流失控的开端。

也许 NEXT_SESSION.md 明确写着下一步是发布独立博客，模型却以为还要继续做视频渲染；也许 AGENTS.md 里角色分工早已调整，模型脑子里还是旧的协作模式；也许某个工具昨天刚升级，Agent 却因为历史记录里躺着旧命令，顺手就用了过时的写法。

这就是正经项目必须配备 /start-session 的原因。

它的目的很简单：在 Agent 产生任何观点之前，先让它把“公司”加载进来。

它会依次读取项目路由器和启动文档：CONSTITUTION.md、IDENTITY.md、SOUL.md、WORKFLOW.md、ROLES.md、MEMORY.md，尤其是 NEXT_SESSION.md。它会检查报告，如果有只读的 doctor 脚本，也会跑一遍。最后给负责人一份精简的 briefing：我是谁、这是什么项目、公司当前状态、阻塞项是什么、第一步具体该做什么。

听起来平淡无奇，但这其实是整个系统里最关键的设计决策之一。

没有启动协议，上下文只是传言；有了启动协议，上下文才成为基础设施。

先读文档，再动脑子

这并非让 Agent 走形式地念文件，而是要扭转默认的认知的顺序。

错误的顺序是：凭记忆思考、猜测项目状态、找文件验证猜测、然后开工。

正确的顺序是：加载项目法则、加载交接文档、将交接内容与实际现状比对、最后再决定做什么。

之所以要这么较真，是因为 AI 天生被优化为“续写”。它急于提供帮助，急于产出下一个有用的动作。这种冲动在执行阶段是优势，在启动阶段却是隐患。启动时的首要任务不是创造，而是定位。

优秀的人类团队深谙此道。飞行员不会凭记忆编造起飞检查单，外科医生不会走进手术室现猜病人身份，靠谱的工程师也不会靠着模糊的分支名直接部署上线。

Agent 世界的等价操作就是 /start-session：读指定文档、尊重交接内容，然后才开始干活。

为什么工作流需要“软关机”

如果说 /start-session 是干净启动，/finalize 就是软关机。

很多 AI 任务即便成功了，收尾也很糟糕。代码补上了，文章发布了，图片生成了，bug 修好了。然后会话一关，工作中最有价值的部分就蒸发了：那些摩擦与教训。

到底哪里卡住了？哪个命令用着别扭？哪条指令缺失了？哪一步被迫重复了？哪条凭证规则差点惹祸？哪个公开验证环节拦住了虚假的成功？工作流里还有哪部分依赖模型记住脆弱的操作序列？

执行任务时，Agent 专注于完工，这没错。但完工之后，它应该切换模式，变成工作流本身的维护者。

这正是 /finalize 的职责。

它会复盘刚发生的真实会话：bug、绕路、重复劳动、文档缺失、函数不稳定、工具报错、凭证风险、敏感信息泄露隐患。然后抛出工作流设计中最核心的问题：

这次会话教会了我们什么，能确保下次不用再交同样的学费？

如果答案是小而安全的改动，/finalize 不该只写计划，而应立即动手：更新相关文档、调整技能、优化命令、补上遗漏的备注，并按项目规则提交。如果改动较大或有风险，则记录根因并请求批准。

这便是“完成任务”与“组织学习”的区别。

收尾不是写状态报告

对 /finalize 最常见的误解，就是把它当成总结汇报。

“今天完成了 X、Y、Z，一切顺利。”

这远远不够。

总结只记录发生了什么，收尾要改善下一次会发生什么。

这个技能刻意偏向根因分析。如果模型被迫把同一个命令跑了三遍，问题不在于“第三次用的什么命令”，而在于为什么前两次会失败。是文档过时了？CLI 报错信息太含糊？预期文件路径根本没写？命令用错了 Python 环境？还是本该固化在代码里的决策，依然飘在模型的脑子里？

所以我称之为软关机。正常关闭电脑时，系统会刷写待写入数据、关闭打开的句柄，让磁盘处于可恢复状态。/finalize 对工作会话做的也是同样的事。

它把隐性经验刷写到显性知识中。

深层审计：self-reflection

/finalize 盯着刚结束的会话，/self-reflection 则审视整体架构。

这两者不能混为一谈。

会话级问题可能是“Agent 忘了更新 NEXT_SESSION.md”；架构级问题则是“工作流缺乏可靠的生命周期闭环，交接漂移在所难免”。

/self-reflection 是针对《Workflow Design Bible》项目的定期架构审计。它会评估这家“公司”的设计是否依然合理：

• CEO 是在做编排决策，还是在干体力活？
• 角色与能力边界是否清晰？
• 扇出点是否有文档支撑并真正被使用？
• 四层体系是否完好：路由器、命名文档、技能与角色、工具？
• AGENTS.md 是否依然精简，还是沦为了杂物抽屉？
• 全局技能与项目本地技能是否彻底分离？
• 生命周期是否真的能闭环？
• 是否有 doctor 脚本校验文档声明与现实的一致性？
• 身份、记忆、灵魂文档是实用还是臃肿？
• 凭证和敏感信息是否彻底隔离在提示词、日志和提交记录之外？

产出不是补丁，而是“精炼与升级”计划。该技能会刻意暂停，在修改前请求批准。

这种克制至关重要。架构变更牵一发而动全身，提案必须附带证据、根因、影响文件、风险评估和验证方案。模型可以发现改进机会，但方向必须由负责人拍板。

窄层审计：self-reflection-cli

我工作流里最常问的一个问题非常直白：

模型还在实时执行的哪些事，本该变成一条命令？

这就是 /self-reflection-cli 的活。

它不是哲学层面的泛泛审计，而是“下沉”审计。它专门寻找那些重复、确定性高、即兴执行易出错或涉及敏感信息的任务。一个步骤触发的信号越多，就越该尽快下沉为稳定的函数、脚本、CLI 或 MCP 封装。

这类例子随处可见：

• 跨时区计算发布窗口；
• 将 Ghost 封面图归一化为 1280×720 且限制大小；
• 检查公开页面是否包含预期的标题和图片；
• 将最终博客源文件归档到规范目录；
• 将内容写入 SQLite 和 ChromaDB；
• 校验构建目录是否包含所有必需图片；
• 检查工作流文档里声明的角色或技能是否已废弃。

这些事不该依赖 Agent 当下的细心程度。它们应该是具备输入输出、支持 dry-run、保证幂等、错误分类清晰的命令。

/self-reflection-cli 守住了合理的分工边界：

• Codex 负责判断轻重缓急、权衡取舍、寻找高杠杆改进点；
• 代码负责以完全一致的方式执行机械步骤。

工作流越老越便宜、越老越安全的秘诀就在于此：智能不断向下迁移。

生命周期闭环

这四个技能构成了一个循环：

/start-session
  -> 加载公司状态
  -> 执行工作
  -> /finalize
       -> 沉淀会话经验
       -> 修复小缺陷
  -> /self-reflection
       -> 审计架构
  -> /self-reflection-cli
       -> 将可重复执行下沉为工具
  -> 下一次 /start-session 从更完善的公司状态启动

并非每次会话都需要跑全套审计，但严肃的工作流必须随时能调用这个闭环。

日常工作至少要做到干净启动、干净收尾。高强度会话必须执行 finalize。反复出现的摩擦应触发 self-reflection。每周配额重置前，如果高端模型预算还有剩余，与其继续跑机械任务，不如花在架构优化和任务下沉上。

这才是昂贵智能的更好用法。

幻觉不只是事实错误

人们谈论幻觉时，通常指内容层面：模型编造了来源、日期、论断或引语。

在工作流里，幻觉还会以“操作自信”的形式出现。

模型可能凭空捏造项目当前状态，假设某文件存在，记住一条过时的命令，因为 API 调用看似成功就宣称公开页面已更新，或者因为上次这么做就“知道”下一步该干嘛。

解药不是告诫模型“仔细点”。小心不是架构。

真正的解药是让工作流的现实变得可加载、可校验、可闭环：

• 从命名文档加载项目状态；
• 传递文件路径而非粘贴内容载荷；
• 对外部变更先 dry-run 再正式执行；
• 发布后校验公开页面的真实状态；
• 归档最终源文件；
• 完工后写入记忆；
• 执行会话收尾；
• 定期审计哪些任务该固化为代码。

这才是工作流对模型本性的补偿机制。模型很聪明，但它不是数据库，不是调度器，不是凭证保险库，不是发布管理器，也不是文件系统清单。让它做判断，让系统负责记忆。

成熟的工作流会主动学习

Agent 工作流的真正价值，不在于能完成一次任务。人类早就能做到这一点。

真正的价值在于，系统能在每次任务后进化。

成熟的工作流应该能感知自身的痛点。它要把反复出现的痛点转化为工具，把模糊的决策转化为成文的策略，把对外输出的失误转化为验证关卡，把缺失的交接转化为生命周期规则，把有用的发现沉淀为记忆，再把稳定的记忆固化为文档或代码。

这就是启停技能如此重要的原因。它们赋予了工作流新陈代谢的能力。

/start-session 让公司以本来面目醒来。

/finalize 让公司消化刚发生的一切。

/self-reflection 让公司重构自身结构。

/self-reflection-cli 让公司将劳动从脆弱的智能迁移到稳定的机器中。

这便是 Agent 驱动工作流的原生生命周期：从真相启动，凭判断工作，以学习收尾，并定期重构这台工作的机器。

一旦这个闭环运转起来，工作流就不再是一串精巧的提示词。

它变成了一家懂得如何自我进化的公司。

《Workflow Design Bible》基于 MIT 协议开源：github.com/preangelleo/workflow-design-bible。