定时与后台智能体：CRON、长任务与后台 Agent 的架构

后台 Agent 的形态学：三种触发与两类生命周期

后台 Agent（无人在场、自主运行的智能体）按触发与生命周期分类。按触发：定时触发（CRON——每日简报、每周巡检、每小时的同步；本库站点的定时任务体系就是实例）、事件触发（收到一封邮件、一个 webhook、一条消息——事件驱动的即时响应）、人工派发（像派工单一样丢一个任务给 Agent——Manus 类产品的形态）。按生命周期：短任务（分钟级完成——一次巡检、一份日报）、长任务（小时到天级——深度研究、大规模数据处理、多阶段项目）。两类生命周期的工程难度天差地别：短任务的挑战是「可靠与幂等」，长任务的挑战是「状态与恢复」——本篇的重心在长任务。

与聊天 Agent 的架构差异：无人的世界里信任靠什么

后台 Agent 与聊天 Agent（用户在场）的架构差异本质是「无人在场时，信任靠什么」。聊天 Agent 的信任靠即时反馈（用户看着，错了马上纠）；后台 Agent 没有这个 Luxury——它必须靠机制获得信任。机制四件套。① 幂等与重试（本库幂等性篇的后台版：定时任务的重跑、消息的重复投递——后台世界的重试是常态，幂等是底线）。② 状态持久化（长任务的进度必须在持久层——进程崩了从 checkpoint 继续，本库断点续训思想在 Agent 的翻版）。③ 审计日志（无人看着的操作，事后要能完整回放——每一步的输入输出、决策依据、工具调用全量留痕——本库审计原则）。④ 通知与升级（任务完成/失败/需要决策时的通知通道——以及「连续失败的升级机制」——告警到人而不是无声死掉）。这四件套的哲学：后台 Agent 的可靠性不是模型问题，是工程问题——模型负责「做对」，工程负责「做了必留痕、坏了必知道、重了必无害」。

长任务工程的关键设计：状态、分段与自愈

长任务（数小时到数天）的关键设计，从本库持续运行的工程经验提炼。设计一：任务的分段与断点。把长任务拆成有边界的阶段（研究 → 起草 → 审校 → 交付），每个阶段完成后持久化状态（中间产物落盘：文件、数据库记录）——恢复时从「已完成的阶段」继续而非从头——「阶段产物即 checkpoint」。设计二：上下文的外置化。长任务的上下文远超窗口——把工作状态写在「外部」而非依赖对话历史（todo 文件、进度文档、中间产物文件——每一步从盘上恢复状态，对话历史只是「最近工作记忆」）——本库上下文工程篇的原则在长任务里的生死级应用（长任务的对话历史是最不可靠的记忆，文件才是）。设计三：自愈与升级。可重试的错误自动重试（网络、限流）、不可重试的错误记录并跳过（继续做能做的）、关键决策点的升级到人（方向性判断、风险操作——暂停等人，本库 HITL 篇）。「自愈」的边界要清晰：自动修复「已知模式」的故障，人工介入「未知模式」的异常——无限自动重试是长任务最常见的翻车姿势（烧 token 死循环）。设计四：成本的护栏。长任务的 token 消耗要有预算与熔断（本库 FinOps 篇）——失控的长任务是账单事故的头号来源。

落地的现实：什么时候值得做后台 Agent

后台 Agent 的甜点区：高重复、可验证、异步可容忍的任务——日报与简报（本库飞书简报任务的形态）、数据巡检与告警、定期同步与对账、内容生产的流水线。不适合后台 Agent 的：需要即时交互判断的任务（该聊天 Agent 做）、强合规的关键决策（自动决策的责任链不成立）、以及「伪定时」需求（业务其实是事件驱动，硬做成定时轮询——选错触发模型徒增延迟与成本）。演进的观察：后台 Agent 正在成为各家平台的标准能力（ChatGPT 的定时任务、各家助手的后台模式、企业平台的 Agent 调度）——「Agent 从对话产品变成基础设施」的标志，就是它开始像 cron 与消息队列一样被默认提供——而工程界将重演一遍当年定时任务与消息系统的全部课题：幂等、顺序、重试、死信——历史不会重复，但会押韵；后台 Agent 的最佳实践，一半藏在二十年前的任务调度系统里。

后台 Agent 实战：一个每日简报智能体的完整搭建

后台 Agent（正文架构）的实战：每日简报智能体的完整搭建（本库站点的定时任务形态的通用版）。需求：每天早上 8 点，扫描指定信息源，生成结构化简报，推送飞书。架构的搭建。触发器：定时任务（cron 08:00）。信息源层：RSS/API/网页的抓取节点（每个源一个工具）。智能体层：LLM 节点做「筛选 + 摘要 + 结构化」（判断哪些值得报、生成摘要与分类）——筛选的 prompt 设计：明确「值得报的标准」（相关性、新颖性、影响面）、输出格式（标题/一句话摘要/分类/原文链接）。推送层：飞书卡片（本库通知篇——MCP notification 或 webhook）。工程的四件套（正文机制）：幂等（重跑不重复推送——按日期去重）、状态（已处理源的光标记录）、审计（每日的运行日志）、升级（连续失败的通知——本库正文机制四件套的完整落地）。简报质量的迭代：推送的「用户反馈回路」（哪条有用哪条没用——反馈数据反哺筛选标准）、信息源的定期增删（覆盖面的进化）、成本的监控（每日 token 账单——简报类任务的成本可控但要在预算内）。这个案例的元意义：每日简报是后台 Agent 的「Hello World」——它规模小但五脏俱全（触发、智能、推送、幂等、审计），是后台 Agent 工程的最佳练手项目；本库的飞书简报体系就是这个案例的生产级版本。

长任务 Agent 的状态管理实战：一次三小时研究任务的设计

长任务（正文设计二）的状态管理实战：一次三小时的研究任务的状态设计。任务的挑战：三小时的研究（数百次工具调用）——上下文远超窗口、中途可能崩溃、进度需要可见。状态外置的设计（正文设计二的落地）。progress.md：任务清单与完成状态（每完成一项就更新文件——智能体的「记忆锚点」）。findings/ 目录：研究的中间产物（每个子主题一个文件——发现即落盘，不在对话历史里攒）。report_draft.md：报告的滚动草稿（边研究边写——成稿是渐进的而非最后突击）。每一步的恢复协议：智能体每轮开始先读 progress.md（知道到哪了）→ 找下一个未完成任务 → 执行 → 更新文件——崩溃后重启，从文件恢复全部进度（对话历史丢了也不影响——状态在盘上）。对用户的进度可见性：progress 文件的实时可读（用户随时查看进度——本库流式篇的过程透明）、阶段完成的通知推送。这个设计的通用价值：长任务的状态管理，就是把「对话」降级为「工作日志」，把「文件系统」升级为「主内存」——对话历史管最近的上下文，文件系统管全部的状态——这个架构模式适用于一切长任务智能体（Manus 类产品的事件流与本库后台任务体系同构）。

后台 Agent 的通知设计：从「跑完了」到「值得看」

后台 Agent（正文机制四）的通知设计：从「跑完了」到「值得看」的通知工程。通知的分级设计。即时级（需要人决策的——升级机制、审批请求：立即推）、摘要级（任务完成：汇总推送——本库飞书简报的形态）、归档级（日常成功：入库不打扰——通知的最大敌人是「狼来了」：什么都推等于什么都不推）。摘要级通知的设计要点。结构化的卡片（标题、核心结论、关键数字、跳转链接——本库飞书卡片篇：卡片是摘要的载体）、「值得看」的判断（异常优先：失败与异常永远置顶、变化的显著量：与上次对比的差值——通知的内容价值 = 信息的新颖度 × 重要性）、以及频率的控制（同类通知的合并、静默时段）。通知的闭环：通知里的操作回传（卡片上的按钮直接处理——「采纳/驳回/查看详情」——通知不只是看，是操作的入口）、反馈的数据回流（用户对通知的处理行为——通知的打开率是内容价值的度量，低打开率的通知该砍或改）。通知设计的收束：后台 Agent 的通知，是 Agent 与人类之间的「工作汇报系统」——好的汇报让人信任并省心，坏的汇报让人关掉提醒（Agent 的价值归零）；通知工程值得像产品功能一样认真设计。

后台 Agent 的安全设计：无人值守的权限边界

后台 Agent（正文机制）的安全设计：无人值守的权限边界——后台 Agent 没人看着，权限的设计是安全的核心。权限的最小化原则。工具面按任务裁剪（简报 Agent 不需要写数据库的权限——本库执行隔离篇的原则在后台的强化版：无人值守时权限要再降一档）、凭证的作用域（后台 Agent 的凭证是专用的低权限凭证——本库安全篇的凭证治理）、以及时间的限制（凭证的短效与轮换——长期运行不等于长期授权）。危险操作的绝对禁止。后台无人值守时禁止不可逆操作（删除、支付、外发——这些操作在后台 Agent 里要么禁用、要么转成「待人工确认的队列」——后台 Agent 的操作白名单比聊天 Agent 更严格：没人看着的世界里，宽容就是事故）。异常的熔断。预算的熔断（token 超限即停——本库 FinOps 篇）、行为的熔断（异常行为的检测——任务越走越偏、输出异常——自动暂停等人）、以及升级的人工通道（熔断后的处理流程——熔断不是终点，是「转人工」的触发器）。安全设计的收束：后台 Agent 的安全公式 = 聊天 Agent 的安全 − 人的实时监督 + 更严的权限 + 自动熔断——四个变量的平衡点是「无人值守也能睡得着觉」的程度；睡不着的权限配置，就是还没配好。

小结

后台 Agent 按触发（定时/事件/派发）与生命周期（短/长）分类，无人世界靠机制四件套建立信任：幂等重试、状态持久化、审计留痕、通知升级。长任务的四设计：阶段产物即 checkpoint、状态外置到文件（对话历史不可靠）、自愈与升级的边界清晰、成本护栏防失控。甜点区是高重复可验证可异步的任务。后台 Agent 的最大启示：Agent 的可靠性从来不来自模型多聪明，来自工程多诚实——做了必留痕、坏了必知道、重了必无害，这三句话比任何 prompt 都值钱。