Bohdan Triapitsyn
bb45164ae8
Arm the target button in the composer and the next prompt becomes a goal: the server keeps the session working toward it (idle tick -> small-model audit -> continuation) until the objective is verifiably complete, blocked, or out of budget — even with the UI closed. Server (packages/web/server/lib/session-goal): - event-driven loop on the global SSE hub; goal state lives in session.metadata.openchamber.goal (merge-safe patches, stale-write guard by goal id), so it survives restarts and syncs to every client for free - the small-model audit (objective + last assistant turn only, language pinned to the objective) is the sole termination authority; blocked needs 3 consecutive verdicts, audit outages tolerate one unaudited continuation then stop the goal as resumable-blocked - hard stops: optional token budget, auto-continuation cap (Resume grants a fresh allowance), turn errors; user abort pauses the goal instead of blocking it, and resuming over an aborted tail nudges immediately - token accounting as a snapshot of the latest turn (input + cache.read + output), goal-relative via a creation baseline and segmented across compactions; a compaction summary skips the audit and continues - continuations reuse the session's own provider/model/agent/variant UI: - three-mode target button (arm / disarm / manage dialog), informational goal strip with inline pause/resume and an Evaluating indicator, sidebar state glyph, objective length counter (2000-char server clamp), read-only completed goals - goal entry points: composer (sessions and drafts), start-new-session- from-answer dialog, plan implement dialog (plan content becomes the objective), scheduled tasks (Run as goal + budget) - Settings -> Chat -> Goal: feature toggle + default token budget with three-layer parity (web server, client persistence, VS Code bridge); VS Code renders goal state but hides the entry points (the loop runs in the web server only) Notifications: per-turn "ready" notifications are suppressed while a goal is active; settling sends one final notification (desktop, web-push, APNs generic titles with the session name as body) honoring the completion toggle. Error/question/permission notifications are untouched. Docs: user guide (session-goals) in all 9 locales + sidebar entry, scheduled-tasks cross-reference, server module DOCUMENTATION.md.
36 lines
1.5 KiB
Plaintext
36 lines
1.5 KiB
Plaintext
---
|
|
title: 计划任务
|
|
description: 按计划自动运行提示词。
|
|
---
|
|
|
|
# 计划任务
|
|
|
|
计划任务会按计划为你运行提示词 — 例如每日的“总结昨天的变更”或每周的清理。任务运行时，OpenChamber 会开启一个新会话并自行发送提示词。从会话侧边栏顶部的按钮打开调度器。
|
|
|
|
## 创建任务
|
|
|
|
1. 从会话侧边栏打开计划任务对话框。
|
|
2. 添加一个任务并给它一个名称。
|
|
3. 选择它何时运行：
|
|
- **daily** — 每天在一个或多个时间点
|
|
- **weekly** — 在选定的工作日和时间点
|
|
- **once** — 单个日期和时间
|
|
4. 设置它要做什么：要发送的提示词，以及要使用的提供商、模型和智能体。提示词可以是斜杠命令，比如 `/review`。
|
|
5. 保存，并确保该任务已启用。
|
|
|
|
你可以用 **run now** 立即运行任何任务，以检查它是否按预期工作。
|
|
|
|
勾选**作为目标运行**，运行就会把提示词推进到完成，而不是在一次回复后停下 — 参见[会话目标](/session-goals/)。
|
|
|
|
## 成功的样子
|
|
|
|
运行之后，任务会显示它上次运行的时间、是否成功，以及指向它所创建会话的链接。如果某次运行失败，错误也会显示在那里。
|
|
|
|
## 请记住
|
|
|
|
任务只在 OpenChamber 服务器运行时触发。如果你关闭它，计划任务的运行会被暂停，直到服务器重新启动。
|
|
|
|
## 相关内容
|
|
|
|
- [命令与代码片段](/zh-cn/commands-snippets/) — 复用斜杠命令作为提示词
|