作为 Cron 任务的智能体：当定时触发优于对话循环时

如今，生产环境中的大多数 “智能体”（agents）其实都是套着对话界面的后台任务。它们不需要用户向其输入内容，而是需要一个触发器、一个状态文件，以及一种在不可避免的超时后恢复运行的方法。对话循环 —— 请求、工具调用、请求、工具调用，无限循环 —— 是为了演示方便而提供的功能，却悄然间成为了默认的执行模型。然而，对于大多数交付的智能体工作负载来说，这其实是一个错误的模型。

这并非一个哲学层面的决定。它直观地反映在账单上、值班告警中，以及任务的运行成功率上。对话循环会在多轮对话中保持模型会话开启，不断累积上下文，一旦链路中任何一环出错，整个过程就会中断。而调度触发则在确定的边界处启动，运行至完成或达到检查点，并在退出前将状态写入持久化存储。前者像是一通电话，而后者则是一个工作队列。将两者混为一谈，会导致一个每月 200 美元的功能在没有任何人修改提示词的情况下，变成每月 4 万美元的负担。

默认循环继承了从未测试过的失败模式

当你将模型封装在对话式的循环中时，你同时也继承了有状态长会话的各种失败场景。在大多数生产代码中，这些场景非常复杂且缺乏充分测试。

第一种失败是上下文腐化（context rot）。2025 年的研究证实了从业者们一年多来的私下抱怨：随着对话的增长，模型对窗口早期指令的理解准确度会下降，即使是宣称拥有 20 万 token 上下文的模型也不例外。早期的系统提示词（system prompt）和用户的实际目标会被工具输出、重试记录和过时的计划所淹没。模型不会宣布它已经遗忘 —— 它只是会产生更浅层的推理，在同一回复中推荐自相矛盾的模式，并悄然放弃第一轮对话中的约束。

第二种失败是矛盾堆积。当工具调用失败时，该错误会保留在上下文中。当智能体尝试不同的方法时，新的尝试会与失败的尝试并列。到第四十轮时，上下文中可能包含同一函数的三个实现、三条错误消息以及三条放弃每种尝试的指令。此时模型正在推理自己的混乱，而不是在处理任务。

第三种失败是资源耗尽。一个没有硬性轮数限制的对话循环，离一个下午耗尽整个月 token 预算的距离，仅隔着一个提示词注入（prompt-injection）或一次糟糕的工具响应。安全研究人员已经为这种模式命名 —— 智能体资源耗尽（agentic resource exhaustion），即 AI 时代的死循环攻击 —— 而唯一的持久防御措施就是从一开始就不采用无界循环。

第四种失败是存活性（liveness）。从基础设施的角度来看，长运行的对话会话就像是一个伪装成无状态的 TCP 风格状态机。任何网络波动、任何模型限流、任何容器重启都会导致整个对话丢失。除非有人明确进行了持久化，否则第 1 到 30 轮的工作都会付诸东流。

大多数 “智能体” 不需要对话

一个有用的诊断问题是：谁在智能体循环的另一端？如果答案是 “另一个软件、按计划运行、没有人类在等待”，那么该智能体就不应该是对话式的，而应该是一个任务（job）。

看看 2026 年人们称之为智能体的实际工作负载：

• 每晚运行的任务：扫描昨天的支持工单，进行聚类，并将摘要发到 Slack。
• 定时爬虫：监控竞品价格并将增量写入数据库。
• 每周合规机器人：将新的 SaaS 合同与政策模板进行比对。
• 每小时监控：对新的 GitHub issues 进行分拣并打标签。
• 数据增强流水线：每当文件进入 S3 时运行。

这些工作负载都没有用户在输入。它们都不受益于长会话。相反，每一个都能从确定性的、幂等的、可重试的任务中获益 —— 在已知边界运行，将发现写入持久存储，并干净利落地退出。对话式框架不仅是不必要的，它还是这些系统在运行两个月后遇到可靠性和成本问题的根源。

将它们包装成对话的直觉源于 SDK，而非工作负载。框架往往将对话循环作为阻力最小的实现路径，团队在开发首个原型时也会采用这种循环，因为演示就是这么做的。随后，这种循环被带入生产环境，结果发现它比等效的批处理任务成本更高、故障更多、且更难运维。

Cron 风格的替代方案

将智能体视为 Cron Job 意味着三项承诺：

确定性触发。 智能体因某种触发而运行 —— 一个计划任务、一个 Webhook、一个队列事件 —— 而不是因为用户维持着一个会话。触发器是唯一的入口点。不存在 “然后它就一直运行下去” 的情况。

检查点状态，而非上下文内状态。 智能体在每一个有意义的边界，将其计划、中间发现和进度写入磁盘或工作流运行时（如 Temporal、Restate、Microsoft Agent Framework 检查点 API、LangGraph persistence）在每一个有意义的边界。上下文窗口被视为可以随时消失的暂存缓冲区，而不是事实来源。如果进程在十个步骤中的第七步挂掉，第八步会读取状态文件并恢复，而不是将前七轮对话重新输入给一个新的模型会话。

受限的执行封包。 每次运行都有实际时间超时、token 预算和最大步骤限制。如果工作在封包结束时未完成，该次运行会记录当前的检查点并退出。下一次调度启动时再恢复。这就是操作系统运行可靠工作负载五十多年来的方式，AI 领域也不例外。

经济方面的论据同样具体。Anthropic 和 OpenAI 都为具有数小时完成窗口的异步工作负载提供批处理 API（Batch API），在输入和输出 token 上提供 50% 的折扣。结合提示词缓存（prompt caching），批处理风格的智能体运行成本，相比在实时对话循环中执行相同逻辑，可以降低 90% 以上。对于那些确实不需要亚秒级响应的工作负载 —— 绝大多数 “智能体” 都是如此 —— 停留在同步层级实际上是在为你不需要的低延迟支付高额溢价。

当你混淆两者时，你继承了什么

最昂贵的 Bug 并不是那些显而易见的崩溃，而是源于将批处理任务（batch workload）套用在对话基座（conversational substrate）上，或者反之亦然。

将批处理任务作为长对话运行，你将面临：随着上下文在原本应该是独立运行的任务间不断累积，导致 Token 无限制增长；跨任务污染（cross-run contamination），即昨天的陈旧指令泄漏到今天的运行中；难以调试，因为每次运行的上下文历史都不同；以及定价随会话长度呈平方级增长，而非随工作量线性增长。

将对话式任务作为一系列独立的定时任务（cron jobs）运行，你则会面临另一组问题：对话连贯性完全丧失，因为每次启动都无法看到前一轮的推理；用户已经建立的上下文需要不断重新推导；以及面向用户的延迟受限于调度器的心跳速率（tick rate），而非模型本身。

从外部看，这两种失效模式的表现是一致的：“智能体（agent）不可靠”。但在内部，诊断结果却截然相反。用同样的剧本来处理两者——增加更多工具、丰富提示词、更换模型——都无济于事，因为问题的根源在于基座（substrate）错了。

在发布前，有一个很有用的试金石：如果是由人类来完成这项工作，他们会一直坐在键盘前盯着吗，还是会启动任务然后稍后再来检查？如果答案是“启动后离开”，那么实现方式也应如此。底层工具是 Chat Completions API 只是一个实现细节，而不是用户体验（UX）的强制要求。

设计触发器、状态与封装

有三个具体的、具象的设计选择可以将“定时任务型智能体”与“伪装成任务的对话型智能体”区分开来。

触发器应该是唯一的变更来源。 定时运行的智能体之所以运行，是因为 cron 触发了、队列中有消息了，或者 Webhook 到达了。它不应该有一个“用户也可以直接调用它”的侧向通道。你增加的每个入口都是一个需要测试的状态机分支，而整个可靠性故事都建立在任务运行相互独立的基础上。如果确实需要人类手动调用，请将他们的请求路由到其他人都在使用的同一个队列中，不要为他们提供进入同一代码路径的后门。

状态文件即智能体。 将模型视为从 state -> next_state 的无状态函数。编排器（orchestrator）从持久化存储中读取状态，仅使用与下一步相关的状态切片来调用模型，将结果写回并退出。这是 Temporal 和 Restate 这类工具的设计模式，通过 Postgres 行、JSON 文件或团队已经运行的任何工具也可以实现。重点在于状态是有名称、有版本且可检查的——你可以恢复、回放或审计任何运行，而无需费力让一个长期运行的进程配合。

封装（Envelope）是不可妥协的。 挂钟时间（wall-clock）超时、Token 上限和最大步数必须由编排器强制执行，而不是依靠模型的“良苦用心”。提示词（prompt）中的任何内容都无法阻止智能体陷入无限循环，只有运行时（runtime）可以。当封装关闭时，运行会写入检查点（checkpoint）并退出。下一个触发器会从该检查点继续。这就是一个可以在假期期间维持运行的系统与一个因为工具调用挂起而在凌晨 3 点叫醒运维人员的系统之间的区别。

哪些内容应保持对话式

这并不是说对话型智能体毫无用处。某些工作负载确实需要对话基座：人类实时迭代的 Copilot、客户在另一端等待的支持机器人、用户输入并纠错的代码助手。在这些情况下，长期运行的会话正在完成实际工作——它以任何检查点文件都无法实现的方式，编码了人类不断演进的意图。

错误在于默认选择。今天，大多数团队选择对话循环是因为 SDK 就是这么提供的，而不是因为工作负载需要它。扭转这一默认设置——除非有人参与其中，否则将任务视为任务，仅在用户的持续存在构成价值的一部分时才应用对话基座——是 2026 年大多数智能体团队可以获得的最廉价的可靠性和成本优化方案。这不需要更好的模型、新的框架或更大的上下文窗口，它只需要你意识到：这项工作从一开始就不是一场对话。