跳转至

想让 Agent 在你睡觉时继续干活？先给它排好夜班

Ch04.640 想让 Agent 在你睡觉时继续干活？先给它排好夜班

📊 Level ⭐⭐ | 5.3KB | entities/agent-nightshift-cron-task-scheduling.md

想让 Agent 在你睡觉时继续干活？先给它排好夜班

本文将传统 crontab 和定时任务的概念扩展到 AI Agent 领域，探讨「Agent 夜班」——如何让 Agent 在用户离线时继续执行任务。^[agent-nightshift-cron-task-scheduling.md]

核心问题

Agent 执行长任务（代码审查、批量数据处理、慢查询优化等）时，单次对话窗口和用户在线时间往往不够。需要让 Agent 能够：^[agent-nightshift-cron-task-scheduling.md]

  1. 自主排班：识别需要长时间运行的任务，自动安排到夜间执行
  2. 结果汇总：任务完成后整理结果，用户上班时即可查看
  3. 失败重试：夜间任务失败时自动重试或通知

工程架构

  • 任务队列 + Agent Worker 模式：将长任务拆解为可独立执行的子任务，由 Agent Worker 在后台逐个完成
  • 基于系统状态感知：Agent 需要感知系统负载、资源使用率，选择空闲时段执行
  • 定时触发器：类似 crontab 表达式，支持自定义排班（每 12 小时、凌晨执行等）

实践案例

文章描述了 Agent Browser 长时间运行后产生僵尸 Chrome 进程（6 个渲染进程吃满 768% CPU），以及如何通过定时任务 Agent 自动清理的案例。^[agent-nightshift-cron-task-scheduling.md]

深度分析

从 Prompt 到 Loop：Agent 工作单元的重定义

文章中提出的核心转变是 Agent 的工作单元正在从「单次 prompt 调用」变成「可排班、可交接、可检查的运行过程」。这个变化的意义不在于「让模型多跑几小时」，而在于时间维度、成本维度和交接维度的加入。当 /goal 解决「做到什么才算完」、/loop 解决「什么时候回来再看一次」、Routines 解决「任务能不能独立跑」时，Agent 从对话工具变成了可生产部署的工作进程。

无人值守任务的四个运行时能力

文章提炼了 Agent 在无人值守模式下必须具备的四项基础能力：保存现场（知道上次做到哪里）、调用工具（不只生成文本还执行命令）、检查结果（拿出可验证的测试、截图、diff）、停在边界（遇到不可逆动作或连续失败时停止）。这四条既是对 Agent 能力的约束，也是工程保障——它们确保无人值守不会变成无人管控。

GOAL/STATE/EVIDENCE/PERMISSIONS 四件套

文章提出了一套极简的工程实践：四份 Markdown 文件分别承载完成条件、交班状态、验收证据和权限边界。这种设计不是为了让 Agent「更聪明」，而是为了把隐含信息摊开——让 Agent 不必猜测哪些能做、哪些不能做，让人不必第二天从头翻聊天记录。传统定时脚本只负责「到点执行」，而 Agent 引入的正是这套可交接的状态管理。

低峰窗口下的工程经济学

模型 API 的峰谷定价（如 Qwen3.7-Max 在 off-peak 时段 Credits 倍率从 0.5x 降至 0.1x）使得时间排班从「省钱技巧」升级为系统架构考量。但文章指出，真正重要的不是便宜——而是低成本打开了低风险实验空间，让团队愿意让 Agent 在夜间处理那些「白天舍不得用昂贵 API 跑」的任务。

实践启示

  1. 无人值守任务必须先有验收标准 — 没有明确完成条件的任务不适合交给 Agent 夜间执行；强目标应包含可测量的结束状态和约束条件。
  2. 四文件模式可零成本实施 — GOAL → STATE → EVIDENCE → PERMISSIONS 从 Markdown 文件开始，不需要复杂系统，却能从根本上改善 Agent 任务的可交接性。
  3. 渐进的自动化路径更可靠 — 白天手动跑 → /goal 固化验收 → /loop 短周期看护 → 连续稳定后沉淀为 Routine，避免一步到位的全自动化陷阱。
  4. 让 Agent 运行时有「刹车机制」 — 权限分层（可自动做/可生成待审/需人工确认/禁止）和停机条件（连续失败 N 次即停止）是无人值守的安全底线。
  5. 白天的工作重心转向「任务拆解」 — 团队下班前准备 GOAL/STATE 文件的过程，本身就是一种知识显性化实践，生产力价值远超晚上跑的几个任务。

关键洞见

  • Agent 的定时执行能力是「从工具到系统」的关键跨越
  • 类似 QoderWork 的工具提供可视化定时任务配置，降低了门槛
  • Agent 需要具备「持续性」而非「会话式」——这是 Agent 工程化的核心区别

→ 原文存档

关联