始终在线的 AI 智能体，是在没有任何对话打开时，仍然能为工作负责的智能体。它可以保存一项任务的状态，等待时间推移或外部世界发生变化，在合适的环境里恢复工作，并在下一个决定属于某个人时把控制权交还。
“始终在线”并不意味着大语言模型在不停思考。它不意味着一台电脑必须昼夜不停地满负荷消耗资源。它也不应该意味着智能体不停地发消息，或在没有许可的情况下行动。真正有用的承诺是连续性：即使系统的大部分都在休眠，责任依然存在。
定时执行一条提示词，或保留聊天记录，并不能回答那些实际的问题：重启后还剩下什么？什么会唤醒智能体？它在哪里继续工作？用户怎样才能让它停下？对这些问题的回答，才会把“24/7”从一句口号变成系统的一种属性。
始终在线关乎连续性，而不是正常运行时间
正常运行时间描述的是一个进程是否在运行。连续性描述的是工作是否仍然有人负责，以及是否有一个有效的下一步。
设想你让一个智能体盯着一份签好的合同，等合同回来后更新发布清单，并为你准备下一个决定。合同可能明天回来，也可能下周才回来。在等待期间，并没有有用的推理在发生。智能体不需要一个开着的聊天窗口、一个保持热状态的模型会话，或一个每分钟刷新收件箱的浏览器。它需要的是这份责任的持久记录，以及一种可靠的方式，让相关事件能把这份责任重新推动起来。
在出故障时，这个区别就一目了然了。一个进程可以一直运行，却在崩溃后丢掉任务。另一个系统可以缩容到零好几个小时，然后在事件到来时重建状态并正确恢复。后者才更称得上始终在线。
这就是为什么持久化智能体的基础设施会把等待和计算分开。比如微软当前的 Agent Framework 持久扩展 描述了这样的智能体：在多次 worker 执行之间保存状态，暂停时不消耗计算资源或模型 token，并由外部事件恢复。谷歌关于 以事件驱动方式恢复的长时间运行智能体 的指南，用持久检查点和 webhook 演示了同样的原则。实现细节各不相同，但架构上的经验是一致的：一份始终在线的责任，并不需要一个始终在运行的模型。
可信的始终在线智能体背后的六个条件
没有哪一个单独的功能能让智能体始终在线。这种属性是在六个条件共同起作用时出现的。
一个持续的身份承担这份责任
系统需要一个稳定的身份，让消息、事件、权限、任务和用户的预期都能挂在它上面。如果每次对话都创建一个毫不相干、没有共享运行上下文的智能体，那么后来的事件就无从唤醒任何人，也没有谁对继续这项工作负责。
持续的身份并不需要无限的记忆。它意味着用户可以回到同一个智能体，系统也知道哪些责任属于它。个人信息、对话历史和任务状态仍然可以有不同的生命周期和控制方式。
工作状态能熬过空闲时间
一项任务需要保留的不只是最初的提示词。恢复所需的状态可能包括预期结果、已完成的操作、工作中的产物、约束条件、当前的阻碍，以及下一个有效步骤。
这种状态应当足够持久，能扛过日常的中断：关掉的浏览器、休眠的电脑、一次上线更新、一次 worker 重启，或者几天时间的流逝。对话记录可以帮助重建发生过的事，但重建不等于恢复。可信的系统知道哪份状态是权威的，而不是每次醒来都让模型从一长串对话里推断真相。
更深入的 如何让一项任务跨越各种依赖持续推进 的机制，是另一个话题，不属于这个品类的定义。在这一层，检验标准更简单：系统能否保存足够的有效状态，不需要重新交代一遍就能继续？
时间和事件可以重新进入系统
外部世界的工作，并不只在用户发消息时才推进。截止日期会到来。文件会变化。回复会送达。一台设备会重新上线。一项批准会被记录在另一个应用里。
因此，始终在线的智能体需要的不只是一个交互输入框。它需要一条路径，让定时器或外部事件能到达它所影响的那份责任。这条路径可以是 webhook、消息队列、日程、连接器，或一个范围很窄的监视进程。关键在于，事件能和正确的智能体、正确的状态关联起来。
这并不意味着每个事件都值得进行一次完整的推理。事件驱动的运行之所以有价值，恰恰是因为系统的大部分可以在有工作要评估之前保持安静。判断某个事件是否应该唤醒主智能体，以及这次唤醒是否应该打扰某个人，是一个独立的策略问题，与定义始终在线的系统本身是两回事。
工作恢复时有可用的执行环境
如果智能体没有地方去执行，记住下一步也不够。有些工作可以通过 API 完成。另一些工作需要浏览器、云端电脑、本地机器或专门的智能体运行时。当这份责任再次变得活跃时，环境必须可用，并且具备下一步所需的文件、工具和权限。
“可用”不等于一直在运行。云端电脑可以在存储保留的同时休眠，需要时再唤醒。本地机器可以一直断开连接，直到某个任务需要它。重要的是，智能体能识别出所需的环境，并诚实地处理它不在的情况。
环境的边界也是正确性的一部分。Comma 的 设备文档 说明，Salix 不会悄悄把工作从一台离线设备转移到另一台电脑上。请求可以失败，等那台设备回来后再重试。这比假装每台电脑都可以互换要少一些“魔法”，但它保留了这项工作所依赖的位置、访问权限和执行条件。
恢复是正常运行的一部分
始终在线的系统迟早会遇到重启、重复事件、不可用的服务、过期的凭证或断开的连接。因此，可靠性不能依赖于某个进程永远完美。
系统需要一条恢复路径：持久状态、检查点或等价的事实来源；有上限的重试；避免重复执行外部操作的方法；以及在自动恢复不再安全时一个看得见的失败状态。悄悄忘掉已经确认过的事情的重启不叫恢复。消耗资源却不改变结果的无限重试循环也不叫恢复。
Comma 的 Loop 文档 提供了一个具体的例子。一个 Loop 可以保存检查点，并在再次启动时拿到它。出现故障后，Salix 会在有上限的重试策略内从该检查点重启它；反复失败会让 Loop 停止，并通知智能体。完整的实现，包括持久事件、去重、调度位置和能力限制，在 为分布式智能体框架打造的可编程事件循环 里有详细介绍。评估一个产品时，看看中断和恢复是否是计划中的状态，而不是意外。
用户能看见并约束这种连续性
持续存在让掌控变得更加重要。一次性的聊天会自然结束。一份后台的责任则需要一个容易理解的范围、一个看得见的状态，以及一个真正有效的关闭开关。
用户应当能看出智能体在负责什么、它在盯着哪些来源、它能用哪个环境，以及它在那里有什么权限。用户应当能暂停或结束这份责任、撤销访问权限，并取回已经产出的工作。系统应当把失败和有后果的决定摆出来，而不是把沉默当成一切正常的证据。
这也是为什么始终在线和自主不是同义词。持续存在说的是系统可以保持可用。自主描述的是哪些决定或动作它可以不经询问就采取。一个智能体可以非常持久，同时刻意保持保守：它可以准备、核实、整理和等待，同时把对外承诺或不可撤回的选择交还给用户。
四种运行模式，而不是一次无尽的运行
“始终在线”这个说法让人联想到一种单一的连续活动。实际上，一个有用的智能体会在几种不同的模式之间切换。
它可能在工作，模型和工具在积极推进一项任务。它可能在等待，因为某个时间、事件、环境或人的决定还没有到来。一个轻量的监视器可能在监控一个范围很窄的条件，而不唤醒主智能体。或者这份责任已经停止，因为用户结束了它，或者故障超出了安全恢复策略的范围。
这些模式对成本和注意力的重要性，不亚于对可靠性。模型推理、云端计算、事件接收、存储和第三方 API 的计费方式可能各不相同。产品不应该把它们混成一句不加限定的“智能体 24/7 运行”。一份安静的后台责任可能在使用存储和监控资源的同时完全不用大模型 token；一个活跃的任务可能同时消耗模型和计算资源；一份已停止的责任除了保留的状态之外，两者都不应该消耗。
Comma 在自己的运行时里体现了这种区分。Salix 让智能体运行在一个始终保持热状态的沙箱之外。需要用电脑工作时，它可以唤醒一台云端虚拟机，这台虚拟机的存储在两次使用之间保留。对于持续的关注，小型 Loop 可以盯着事件，而不必让主智能体循环保持活跃。只有当某个 Loop 判断需要智能体时，主循环才会运行。
这种架构是 Comma 的实现方式，而不是通用的定义。别的产品可能用持久化工作流、队列、无服务器函数或长时间运行的 worker。检验的标准是整个系统能否在空闲期间保住责任，而不是它是否用了某种特定的运行时。
始终在线、定时执行和长时间运行是不同的承诺
定时自动化在已知的时间执行一条指令。它可能非常有用，却不需要维护一个持续的智能体身份，也不需要响应计划之外的变化。如果一个每日任务根据固定输入生成报告，那么一个日程可能就是系统需要的全部。
长时间运行的工作流可以跨越多个步骤保存状态，并等待某个信号。当模型参与解读信息、选择工具或调整计划时，它就具备了智能体的特征。当这个持久化工作流属于一个持续的智能体，能接收新的相关事件，并在用户管控的边界内行动时，它才真正称得上始终在线。
聊天机器人也可以记住过去的对话并提供提醒。这些功能提升了用户的连续性，但它们本身并不能证明工作在聊天之外持续存在。决定性的问题不是系统是否记得关于你的某些事。而是一份活跃的责任能否等待、恢复、从故障中复原，并到达一个经授权的环境，而无需手动重新创建。
这个区别也能防止过度建设。并不是每个请求都需要一个始终在线的智能体。一次性的解释、改写、计算或头脑风暴，往往由一个交互式模型来完成更好。只有当结果取决于时间、外部变化、多个工作环境，或者一份在当前对话结束后仍未完成的责任时，始终在线的运行才值得它带来的复杂性。
一个实用的连续性测试
要评估一个“始终在线”的产品，就给它一份包含空档的真实责任。让它监控一个定义好的条件、准备下一步，并在有后果的动作之前停下。
然后看看这个产品能给你看什么。关掉界面之后，任务存在哪里？到底是什么条件让它重新动起来？它知道哪个环境存放着工作材料吗？它能在重启后恢复，而不重复已完成的操作吗？事件重复了，或所需设备离线了，会发生什么？你能否暂停监视、撤销访问权限，或结束这项任务，而不删除你所有的历史？
最后，看看有什么到达了你这里。一个转发每个事件的系统，搭建的是一条通知管道，未必是一个智能体。一个对每个事件都采取行动的系统，把可用性和权限混为一谈了。一个有用的始终在线智能体，会把变化与已有的责任联系起来，完成已经获准的工作，并只在你的关注能改变结果时才请求你的关注。
Comma 如何保持可用而不吵闹
Comma 是一个免费、开源的私人智能体，围绕一个跨越对话和设备的持续智能体来设计。快速的问题可以留在聊天里，较大的责任会成为 Task。Comma 可以在已连接的应用和文件中工作，在接入的 Mac 或 Linux 设备上工作，也可以在需要时被唤醒的云端电脑上工作。
它始终在线的这一层是 Salix。Comma 智能体可以创建一个 Loop，去盯着一个有边界的来源，比如收件箱、代码仓库、订阅源、API 或 webhook。Loop 与主推理循环分开运行，可以维护一个小小的检查点，并在工作需要时通知智能体。因为主智能体不需要检查每一段安静的时间，“始终可用”就不会变成“始终在消耗模型 token”。Loop 仍然可能调用一个快速决策模型或其他服务，所以后台工作并不自动免费；成本取决于 Loop 实际做了什么。
同样的连续性仍然受用户掌控。接入的电脑一开始是只读的，直到用户允许操作，设备访问权限也可以撤销。Loop 有能力和唤醒次数的限制。当某个决定属于用户时，较大的 Task 可以回到 待审核。Comma 也可以 自托管，不过那样运营者就要负责可用性、升级、备份、模型配置以及维持该实例运行所需的其他基础设施。
Comma 的做法是对这个品类核心问题的一种回答：让责任持续存在，同时让昂贵的计算、模型和用户的注意力保持空闲，直到真正需要它们。
常见问题
始终在线的 AI 智能体会 24/7 运行模型吗？
不会。设计良好的系统可以在主模型不活跃时保存状态，并监听定时器或事件。只有当系统需要推理或生成时，模型才会运行。智能体等待期间，轻量的监控、存储和外部服务仍然可能消耗资源。
始终在线的智能体和自主智能体是一回事吗？
不是。始终在线描述的是跨越时间的连续性和可用性。自主描述的是智能体可以不经人批准就决定或做什么。一个始终在线的智能体可以在很窄的权限下运行，并把有后果的决定交还给用户。
定时执行的 AI 任务算是始终在线的智能体吗？
不一定。一个日程可以在固定时间启动一条无状态的提示词。始终在线的智能体还会保存这份责任和相关状态，能响应合适的外部事件，能从中断中恢复，并在持续的用户控制范围内继续工作。
智能体的电脑需要一直开着吗？
这取决于所需的环境。云端或服务器端的工作可以在个人笔记本合上时继续。依赖只存在于某台本地设备上的文件或应用的工作，必须等那台设备。有些云端环境可以在两次操作之间休眠，同时保留存储。
始终在线的智能体出故障时会怎样？
系统应当从已知的检查点或持久状态恢复，避免重复已完成的外部操作，并使用有上限的重试。如果无法安全恢复，它应当以看得见的方式停下，告诉智能体或用户哪里失败了，而不是无休止地重试，或悄悄放弃这份责任。
我能关掉始终在线的智能体吗？
你应该能暂停或结束一份后台责任，并撤销它使用的访问权限。“始终在线”应当意味着在获得授权时可用，而不是无法停止。在 Comma 里，Loop 可以被暂停或删除，已连接设备的访问权限也可以撤销。
智能体可以休眠，责任不能消失
始终在线的 AI 智能体不是靠持续的模型活动来定义的。它由一条连续的责任链来定义：一个稳定的负责者、持久的状态、一条让时间和事件发挥作用的路径、一个可用的执行环境、可恢复的运行，以及始终留在用户手里的控制。
当这些部分都具备时，系统的大部分在大部分时间里都可以保持安静。模型可以停下。云端电脑可以休眠。用户可以关掉应用。工作之所以能恢复，是因为责任依然完好，而不是因为有人记得输入“继续”。
