duoduo-loop

Duoduo Loop

/loop 可将一句话请求转换为定期运行的后台任务。在任意前台 duoduo 聊天中输入 /loop <what you want done, in your own words>，例如飞书私信、stdio CLI 或编辑器（ACP）会话。Agent 会直接从你的描述中读取运行频率、引擎和交付要求，拟定执行计划，并在你确认后创建任务。循环任务会在各自的后台作业会话中运行；你的聊天仍是人与人之间的对话，并会收到任务结果消息。

确认流程

每个 /loop 都会先拟定计划：

你：/loop 每 20 分钟检查一次 staging 部署，一旦出问题就立刻告诉我 Agent：计划——在后台任务中每 20 分钟检查一次；仅在出现异常时通知你；任务 ID 为 staging-watch；说“停止 staging-watch”即可结束。确认？ 你：确认

计划始终会显示运行频率、引擎/模型、结果送达方式以及停止方法——同意前，请将其视为费用清单。如果要一步创建，请在请求中写明免确认： /loop 无需确认——每 20 分钟，……。

三种循环模式示例

1. 固定频率——每次执行相同的轻量任务（摘要、扫描、健康检查）。

/loop 每天早上 8 点给我发送 Hacker News 摘要

每次运行都会从头开始执行任务，并将结果发送给你。日历时间和时间间隔都适用（“每周一 9 点”“每 2 小时”）。时间间隔可以组合单位且不加空格（2h30m、1d6h4m；单位： s/m/h/d/w）。创建循环时，如果计划无效或无法执行，系统会拒绝创建，而不会先接受后悄无声息地始终不运行。

2. 自主安排节奏——短期任务，自行决定下一次检查时间。

/loop 监控 example/repo#123 的 CI，失败时重新运行，等它通过并合并后告诉我——自行安排节奏

循环会根据刚观察到的情况选择下一次唤醒时间——情况紧急时频繁检查，平静时降低频率——并在目标完成时自行结束，同时提交最终报告。

3. 长期追踪——持续数月的主题、大量阅读和不断积累的判断。

/loop 长期追踪 <topic> 的进展；只有出现真正重要的亮点时才每天提醒我，并把繁重的阅读交给后台助手

长期运行的协调器会在数周内持续积累判断，同时由短期助手负责大量资料的检索和阅读；Agent 会为你统筹这些分工、每轮质量检查和结果交付。你只需用通俗的话控制任务模式：多久接收一次消息、什么才算真正重要的亮点，以及把繁重工作交给助手。每轮结果要么完整交付，要么明确说明存在的缺口，而不会将其隐藏；追踪任务也可以无限期休眠后再次唤醒——见下文“暂停”。

用通俗的话选择引擎和模型

在请求中写明它们；系统会原样传递：

/loop 使用 codex 和 gpt-5.4-mini，每小时检查一次 <site> 是否正常运行

低成本模型适合高频检查；强模型则留给每日综合分析类循环。创建任何内容之前，计划都会复述你的选择。

管理正在运行的循环

所有管理操作都在聊天中完成，每个动词也都有对应的主机命令，可供你自行运行：

• 列出 — “显示我的循环” → 显示各循环的 ID、计划和上次结果。在主机上运行 duoduo job list；每个循环也对应 <runtime_dir>/var/jobs/active/ 下的一个 Markdown 文件。
• 查看 — “ 的状态是什么？” → 显示其计划、上次运行、上次结果和分配给它的任务。在主机上运行 duoduo job read <id>。
• 停止 — “停止 ” → duoduo job archive <id>。它会从计划中移除，文件会移到 <runtime_dir>/var/jobs/archive/，之后可以恢复。已经开始的运行会继续完成。
• 结束正在进行的运行 — duoduo job interrupt <id> -r "<reason>" 会要求当前运行停止。接下来如何处理取决于循环自身的类型：周期性循环会继续按计划运行，并在下一次运行时获知你提供的原因；尚未安排下一次检查的自适应循环则会就此结束，并向其负责人报告失败。要彻底停止循环，请使用 archive——这是两个不同的动词，而卡住的循环往往两者都需要。
• 暂停 / 唤醒（跟踪器） — 长期跟踪器只需在下次唤醒时间之后继续休眠即可暂停；在聊天中提及它（“继续跟踪那个 主题”），即可在保留记忆的情况下唤醒它。
• 调整频率 — “把 改成每天运行” → Agent 会就地修改循环的计划。对于长期跟踪器，提出此请求前请先了解代价：循环的对话与其计划绑定，因此更改频率会启动一个全新的对话，积累下来的判断则会留在旧会话中。
• 额外运行一次，保持频率不变 — 在主机上运行 duoduo job reschedule <id> "@in 30m"。这会额外安排一次运行，但不改变原计划：适合“今晚再检查一次”，不适合调整频率。

费用说明

间隔决定花费速度：每次触发都是真实的大模型运行。确认计划时，应考虑收紧频率并选择更便宜的模型。对于“持续监控直到完成”的需求，优先选择自适应类型——它会在需要采取行动时执行检查，并在完成后自行停止。

按场景排查问题

• “计划时间到了，却什么也没发生” — 先运行 duoduo daemon status；调度器运行在守护进程中，因此守护进程停止就意味着计划会静默失效。然后查看任务——运行 duoduo job read <id>，或询问 Agent“ 的状态是什么？”——上次结果和上次错误会说明最近一次触发时发生了什么。
• “它已经连续运行好几个小时了” — duoduo job read <id> 会显示一个已开始但从未完成的运行。使用 duoduo job interrupt <id> -r "<what went wrong>" 结束它；如果循环还安排了下一次运行，该次运行开始时就会知道为何被中断。系统会要求运行时停止，这会通知大模型及其工具，但不会通知该运行分离到后台的进程。
• “它给我发通知太频繁了” — 请求仅在有重要信号时通知：“将这个循环改为只在出现异常时提醒我。”通过计划创建的监控循环默认仅在有重要信号时通知；逐次报告则需要主动选择。
• “它失败了一次之后就没动静了” — 临时启动失败会自动重试；遇到实际错误的循环会告知你并停止。无论哪种情况，回复“重新启动它”，Agent 就会重新启用或重新创建循环。
• “它以前做过什么？” — 归档的循环仍可查看：询问“给我读一下 的归档记录”，或打开 <runtime_dir>/var/jobs/archive/ 下的文件。