"如果你需要，我可以继续xxxx"——我相信看到这句话会莫名烦躁的不止我一个人。
不是因为模型偷懒，恰恰相反，它很多时候已经做完了 70% 的判断：知道下一步应该查资料、建任务、跑测试、写 draft、或者停下来找人确认。但最后它还是把球踢回来，问一句"要不要继续"。
结果人变成了 cron。每隔一会儿看一眼，回复"继续""可以""跑一下""发我看看"。
这不叫 human-in-the-loop，这叫 human-as-cron。
真正有用的 human-in-the-loop，不是让人每一步都点头。人应该卡在少数真正需要判断的位置：方向选择、公开发布、资金操作、credential、生产环境、客户承诺。其他能按规则推进的步骤，就应该自己推进。
所以我现在越来越觉得，个人 AI 用户，甚至是一人公司最缺的不是再多一个聊天窗口，而是一套 Agent Routine Harness。
Agentic AI 的演进路线
过去大家聊 Prompt Engineering，重点是"怎么问"。后来聊 Context Engineering，重点变成"模型应该看到什么"。再往后，大家开始讲 Agent Harness：工具权限、文件系统、终端、browser、memory、skills、review gate。
发展的路线其实很清楚：大家发现 AI 的问题，不只是模型聪不聪明，而是它在什么环境里工作。
- Prompt 解决启动问题
- Context 解决现场信息问题
- Memory / KB / Skills 解决下次别从零开始、别重复犯错的问题
- Harness 解决工具、权限、验证、状态、边界的问题
这些都对。但如果你真的高频使用 AI，会发现还有一层没有被讲清楚：同一类工作反复发生时，它到底应该怎么被稳定处理？
这就是 Routine 的位置。
Routine 不是替代 prompt，也不是替代 memory。它是把 prompt、context、memory、tools、verification、review gate 组合成一个可重复运行的工作单元，一个强化的 harness 结构。
换句话说：Memory 减少重复犯错。Routine 减少重复调度。这两个不是一回事。
Routine 不是"让 AI 记住"，而是定义同类工作怎么跑
很多 AI 使用问题，表面看是"它忘了"。忘了你的偏好，忘了项目规则，忘了上次踩过的坑，忘了某个文件不能改，忘了公开文章不能暴露内部项目名。
这时候 memory、KB、skills 都很有用。它们让 agent 下次少问一点，少猜一点，少犯同样的错。
但还有另一类问题，不是"忘了"能解释的。看到一个链接，想让 AI 研究、写入知识库、再变成初稿。CI 挂了，想让 AI 先判断是不是 flaky，再决定修还是 block。客户发来 booking / support / ops 类消息，想让 AI 先整理事实、查状态、生成 reply draft，但不要乱承诺。
这些事情不是"记住一个偏好"就能解决的。它们本质上是反复发生的工作流。如果每次都靠你重新 prompt，一边解释背景，一边提醒风险，一边催它继续，那其实没有 routine。只是人肉调度一个很聪明的实习生。
Routine 的目标是：当同类事情再次发生时，系统知道从哪里开始、按什么顺序推进、用什么检查结果、把状态写回哪里、遇到什么情况必须停。
我现在会把一个 routine 写成这几个部分：
trigger: 什么事件触发，来自 Telegram / GitHub / email / cron / 手动
route: 归到哪个账号、topic、workspace、assignee
context: 必须加载哪些 KB、历史记录、repo 规则、客户状态
contract: outcome、acceptance criteria、边界、必须找人的情况
tools: 能用哪些工具，哪些动作永远不能自动做
verification: tests / lint / schema / grep / screenshot / content-lint
state: 结果写回哪里，Kanban comment / Google Doc / KB / issue
recovery: check 失败怎么建 fix task，缺上下文什么时候 block
这看起来像工程流程，其实对个人用户更有用。因为个人和一人公司没有 PM、QA、ops、客服、工程经理给你兜底。AI 一旦开始多线程干活，最先爆掉的不是模型能力，而是你的注意力。
Routine 不是为了把人拿掉。是为了别让人做低信息量确认。
三个实用 Routine 示例
Routine 1：Link → KB → Draft
触发是固定 topic 收到 URL。Router 先判断这是内容研究。Research agent 的第一步不是写文章，而是拿 source。原帖、thread、引用链接、图片、视频、repo README，能抓多少抓多少。拿不到就标 source incomplete。
第二步是写 KB。关键 claim 要分层：source 里明确说的、你推出来的、没验证的。
第三步才是 draft。Writer 只基于 KB 生成角度和正文。写完跑 content-lint，再 grep 内部编辑残留。最后创建 Google Doc，block as review-required。
人的位置很清楚。你不需要每一步回复"继续"。你只在 source 不完整要不要继续写、以及 draft 能不能发布这两个 gate 上做判断。
Routine 2：CI 失败 → 修复 / 阻塞
触发是 GitHub check failed。Agent 拉 PR diff、失败 job log、repo 里的 AGENTS.md / CLAUDE.md、测试命令和最近一次相关修改。然后先判断失败类型：test、lint、typecheck、build、external service、flaky。
如果是 flaky，先 retry 一次或者标记 flaky，不改代码。如果是 external service 或 credential 问题，comment 说明证据，然后 block。如果是明确代码 bug，就在 worktree 里修。
最重要的是 review gate。配置、auth、billing、deploy、schema migration 这些文件，一律不能自动 merge。
Routine 3：客户运营 / 预订处理
触发是 booking 邮件或表单进来。Agent 先抽取结构化信息：客户是谁、要什么、时间窗口、地点、数量、是否付款、是否有冲突、缺什么信息。
然后查内部状态。查不到就标 unknown，不要补脑。接着生成两样东西：一个内部 ops summary，一个对客户的 reply draft。
Reply draft 给客户看，但只能承诺已经被系统确认的东西。涉及 refund、damage、late fee、特殊承诺，一律 review-required。
判断一个任务要不要变成 routine
我现在会看三个条件：
- 它是不是反复出现。同一类事情出现第三次，而且每次你都要重新解释背景，那就值得写下来。
- 它能不能验证。能跑测试、lint、content-lint、schema、grep、截图、日志检查，或者至少能用 checklist 验收，就适合让 agent 多做一点。
- 它失败后能不能回流。失败不是一句"抱歉我没做好"，而是能变成 fix task、block reason、缺失字段、待人工确认项。
反过来，高风险资金操作、法律承诺、复杂客户承诺、无法验证的开放式战略判断，不适合一开始就 routine 化。
下一阶段
Prompt library 解决"这次怎么问"。Memory / skill library 解决"下次别忘什么"。Routine library 解决"每次 X 发生，系统怎么稳定处理"。
真正拉开差距的，不是谁收藏了更多 prompt，而是谁把自己的重复工作拆成了可运行的 routine。
如果你的 agent 每做完一步都问"如果你需要，我可以继续"，那它还是聊天助手。如果它能按 contract 自己推进、验证、写回状态，只有碰到真正的 gate 才找你，那它才开始像一个 worker。
否则你以为自己在用 AI Agent，实际只是给 LLM 当人肉闹钟。