AIWatch.

把"Agent 工程"从经验直觉提升为可复用的设计语言：触发、停止、工件、适用场景——四个变量一旦确定，循环的形态就确定了。

# 核心升级：从"提示"到"循环"的范式转换

· 传统用法中，人主导每一轮（turn）：发提示 → agent 执行 → 人检查 → 再发提示。这就是默认的 agentic loop。 · "设计循环"的本质，是把触发、停止、所用工件、适用场景这四个维度显式化，从而让 agent 能在更少人工干预下完成更复杂、更长跨度的工作。判断的关键不是"任务难不难"，而是哪一段工作可以交付出去。

# 四种循环类型：一张可操作的选型表

1. Turn-based（回合制循环） · 你交付的是：检查这一步 · 触发：用户提示 · 停止：agent 自行判断任务完成，或认为需要更多上下文 · 主要工件：SKILL.md（把人工验证步骤编码进去） · 适用场景：短期、一次性、不属于周期流程的任务

这是默认的 agentic loop。你发提示、agent 执行、你检查、再发提示。改进空间在于用 SKILL.md 把"你脑子里的验收标准"显式化，让 agent 能自检更多环节，从而压缩每一轮的回合数。

2. Goal-based（/goal） · 你交付的是：停止条件 · 触发：实时手动提示 · 停止：目标达成，或达到预设轮数上限 · 主要工件：/goal + 评估模型 · 适用场景：有可验证退出标准的任务

当单轮不够、需要 agent 迭代时使用。关键是把"完成长什么样"写死——每轮 agent 想停时，由评估模型核对你的条件，不达标就送回去继续。确定性指标效果最好（通过多少测试、分数超过某阈值），因为评估模型只需比对，无需自行裁量"够不够好"。

3. Time-based（/loop、/schedule） · 你交付的是：触发时机 · 停止：你取消它，或工作自然完成（PR 合并、队列清空） · 主要工件：/loop（本地，关机即停）、/schedule（上云） · 适用场景：周期性工作，或与外部系统交互

适用于"任务不变、只有输入在变"的场景（如每天总结 Slack），或需要定期探查外部状态再反应的场景（如 PR 等待 review、CI 可能失败）。工程经验上，优先事件驱动而非纯时间驱动——设更长间隔、或基于状态变化触发，能同时省 token 与避免抖动。

4. Proactive（主动式循环） · 你交付的是：提示本身 · 触发：事件或计划，无人实时参与 · 停止：每个子任务达目标即退出；routine 本身持续运行直到关闭 · 主要工件：上述全部 + 动态工作流（research preview）+ auto mode · 适用场景：持续流入的标准化工作——bug 报告、issue triage、依赖升级、批量迁移

这是最复杂、可组合性最强的形态。文章给出的范例拼装方式：/schedule 定时巡查 → /goal 定义"完成"标准 + SKILL 编码验证方法 → 动态工作流并行探索多方案并对抗式审查 → auto mode 免授权全程执行。

成本控制的关键是模型分级路由：routine 跑在小而快的模型上，判断性决策才调最强模型。循环本身不省钱，分层 + 明确边界才省钱。

四种类型并非互斥，而是可组合的积木。 最复杂的形式（Proactive）就是把 /schedule、/goal、动态工作流、auto mode 拼装起来：定时巡查 → 定义"完成"标准 → 多 agent 并行探索方案 → 对抗式审查 → 全程无需授权。

# 关键工程实践（容易被忽略的部分）

1. 自验证是循环质量的支点。 文章反复强调：不要把"编辑成功"当成"工作完成"。把人工评审步骤编码成 SKILL.md，并尽量量化检查（测试通过数、Lighthouse 分数、Core Web Vitals、控制台零错误）。可量化的退出标准，让 agent 能自我判断、减少早停。

2. /goal 的有效性取决于"完成"的可确定性。 文章明确指出：确定性指标（通过多少测试、超过某分数阈值）效果最好。因为每轮结束时由评估模型检查条件是否满足——模糊目标会让评估模型无所适从，导致要么早停、要么空转。

3. 时间循环应"事件驱动"优先于"时间驱动"。 文章在 managed usage 中点名：设更长间隔，或基于事件反应而非定时轮询。/loop 跑在本地机器，关机即停；上云用 /schedule。这是工程经验而非理论——频繁轮询既烧 token，又易造成状态抖动。

4. 模型分级路由。 Proactive 循环建议：routine 路由到更小更快的模型，判断性决策才用最强模型。这与"循环节省成本"的直觉相悖——循环本身不省钱，模型分层 + 明确边界才省钱。

# 系统设计：质量与成本的两条护栏

质量护栏（四条递进）： · 保持代码库整洁——agent 跟随既有模式与约定； · 给 agent 自验证能力——用 SKILL 编码"好"的标准； · 文档易达——框架/库文档保持最新最佳实践； · 用第二个 agent 做代码审查——新鲜上下文的审查者不受主 agent 推理路径的"确认偏误"影响。

更进一步的工程纪律：单次结果不达标时，不要只修这一个问题，而应把它编码进系统，让未来所有迭代都受益。 这是把循环当作"可演进的系统"而非"一次性的脚本"来对待。

成本护栏（五条）： · 选对工件与模型——简单任务不需要多 agent 或循环； · 明确成功/停止标准——具体到"什么样算完成"； · 大规模运行前先试点——动态工作流可产生数百 agent； · 确定性工作用脚本——例如表单填写脚本，比 agent 反复推导代码便宜得多； · 不要比必要更频繁地运行 routine；

用 /usage、/goal（无参）、/workflows 审查 token 消耗分布，可随时停止 agent。

# 落地起点：一句话的方法论

审视你已在做的工作，找出你自身是瓶颈的那一项，问自己能交付哪一片段：能写出验证检查吗？目标够清晰吗？工作是否按计划流入？

这条建议的精妙之处在于它反向定义了循环的适用边界： · 写不出量化验证 → 不要用 goal-based； · 目标说不清"完成长什么样" → 不该自动化； · 工作不按计划流入 → 不该用 time-based； · 都不是 → 老老实实用 turn-based，别过度工程化。

对团队而言，最有价值的可执行项是：先写 SKILL.md 把人工验证步骤沉淀下来——它是所有更高阶循环（goal / time / proactive）的共享底座。没有可靠的自验证，任何循环都只是"更快地产生次品"。