「一次性答完」与「一直追下去」是两件事
多数智能体现在的工作方式，隐含一个前提：任务在单次交互里结束。问一个问题，得到一段答案；给一个指令，返回一个结果。可真实业务里大量高价值工作并非如此：一段销售推进要跨几周，一次合规核对要等上游数据，一个采购流程要经历多轮审批。这类工作的目标不是「答完」，而是「挂起、过阵子再接着干，且别把上下文弄丢」。
Salesforce 在 9 月 11 日为 Agentforce 引入的长期运行时，正是对准这一点。它让 Hunter 这类智能体去追一个跨天数周的目标，而不是只在一次会话里完成任务。把它抽象出来看，长期运行时其实由三块能力组成，值得单独拆开。
记忆：跨会话保住上下文与进度
其一，是记忆。普通对话结束时，状态随之清零；长期运行时要求把上下文与进度跨会话保留下来。一个被中途打断的销售推进，恢复后应当记得已经联系过谁、卡在哪一步、上次的承诺是什么。这听起来像持久化，但难在「结构化」：要保留的不是聊天记录原文，而是可继续推进的任务状态。
要注意，记忆解决的是「别从头再来」，不解决「恢复之后那一步到底有没有对外生效」。后者属于业务系统自身的权威，不能靠托管会话的完成信号来背书。可防御的做法是：把长期运行时当作连续性托管层，关键动作的生效与否，始终由拥有业务状态的那一方系统来验证。
持久执行：计划能随时间推进、可恢复可纠偏
其二，是持久执行。它让一个计划能在时间上铺开，而不是被一次调用的生命周期绑死。当中途环境断开，执行可以从断点恢复；当外部情况变化，计划可以调整方向。对企业来说，这意味着一个长程任务不必依赖某次请求常驻内存，也不必担心进程重启就前功尽弃。
持久执行的代价是复杂度上移：要定义清楚什么是「一个任务单元」、失败在哪个边界重试、恢复后如何对账。很多框架把这部分留给应用方自己补，结果长程任务成了最容易被写出隐蔽 bug 的地方。把它收进平台层，至少让重试与恢复有一致语义。
动态纠偏：把人的反馈变成运行期输入
其三，是动态纠偏。长期任务最怕的是「一条道走到黑」：目标设定后，执行过程不再听人话。动态纠偏让智能体根据人的反馈调整行为，把人类介入从「事后review」提前到「运行期steering」。哪些环节自主、哪些环节等人批准，成为可配置的策略，而不是写死在 prompt 里。
这一点对企业尤其重要。一个跨周任务里，早期可以放手让智能体搜集信息，临近对外动作（发邮件、改记录、下订单）就必须升级给人确认。把审批点嵌进运行时，而非依赖模型自觉，是可控性的来源。
它补的是当前框架的短板
把长期运行时单独看成一类能力，就能看清它与主流框架的关系：很多 Agent 框架擅长单轮闭环、工具调用与子智能体协调，却把「状态跨天保留、计划可恢复、人工可纠偏」默认交给应用方。长期运行时把这三项收进平台，降低了长程任务的工程门槛。
但它不是银弹。跨天任务带来的是成本与风险的同步放大：运行越久，工具调用与 token 消耗越多，出错的暴露面也越大。上生产前，应当实测长程任务的成本系数与失败恢复率，而不是只看单次调用的标价。
几点需要保留的谨慎
其一，长期运行时把目标持续追下去，但「目标本身是否正确」仍要人来定，平台不替企业做业务判断。
其二，跨会话记忆涉及敏感数据驻留，数据出境与留存合规需前置评估，不能上线后再补。
其三，动态纠偏的审批点若配置过松，长期任务可能在无人察觉时越界；过紧又会退化成纯人工，失去自动化的意义。
其四，各平台长期运行时的通用可用时间表、状态驻留区域与恢复语义，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。