技术 · 熟练
没人看着的 agent，平台什么时候把它关掉？
不是「会不会被关」，是「关的那一下按什么算钱」
agent 的活儿有一半是「你已经下班了、它还在跑」——等一个容器起好、等一个工具返回、等一个定时器到点。这类「客户端断开但任务还没完」的进程，平台过去会把它们当空闲资源清掉，现在越来越多平台改成了默认不清理。这一页做的是一次「驻留与计费」体检：先认清你用的平台在这件事上的默认值什么时候变的、变了之后哪些操作算「还在忙」、以及那个保护窗口是按每个操作各算 15 分钟还是总共 15 分钟；再回头把自家 agent 的长任务拆成「真需要扛住断线」和「其实可以断点重来」两堆，只给前一堆付费。关键动作只有一个：把「默认值」当成一个要主动选择的东西，而不是继承下来的事实。
方法 · 一图看懂
1
先确认默认值是什么时候变的 — 平台用「生效日期」而不是公告日期来分档，落在日期之后新建的项目直接继承新默认值，⛔ 没人替你选过
2
数清哪些操作算「还在忙」 — 不是所有等待都算；待决的请求、RPC、`waitUntil()`、未到点的定时器往往各算一类，逐类对照自家 agent 的行为
3
看清窗口是「各算」还是「总算」 — 同一个 15 分钟，解释成「每个操作最多挡 15 分钟、再来一个可以续」与「总共只挡 15 分钟」是两个完全不同的成本模型
4
给长任务做两堆分类 — 必须扛住断线的（付费保）与可以断点重来的（宁可被清），分类依据是「重来一次有多贵」，⛔ 不是「重来难不难写」
原理 · 为什么有效
这件事的原理不在「平台抠门」，而在服务端无状态模型与 agent 负载天生不合：agent 要的恰恰是「客户端走了、进程还在」。过去一年平台用「空闲就清」把成本压住，现在为了支持 agent 改成「有未完成的工作就留着」——代价是驻留按墙钟计费，而墙钟与你干了多少活无关。所以真正的判据不是「省不省」，而是这段驻留时间里有没有必须有人守着的活：有了就付费、没有就让它断点重来。把这条判据落在结构上，比逐月盯账单有用得多 —— 账单只是结果，分类才是变量。
适用场景
适用：跑自动化 / 抓取 / 批量转写 / 定时任务的 agent；任务时长经常超过一次请求的生命周期、且用户会中途关页面/关 ssh 的场景；用 serverless 或托管 agent 运行时、按资源驻留计费的团队。
⛔ 不适用：纯交互式、你在旁边看着的会话（关掉就是结束，本来不需要驻留保护）；以及自己拿服务器跑常驻进程的场景 —— 那里驻留是默认，不需要「保命」，需要的是反向的「该杀就杀」。
自测 · 5 问
我说得出自家 agent 里最长的那次「客户端已断开、任务还在跑」是什么任务、跑了多久吗？
我用的那个运行时，在「有待决操作时会不会驱逐」这件事上的默认值，是哪一天生效的？
那个保护窗口，我知道它是「按每个操作各算」还是「按总时长算」吗？
我把自家长任务分成「必须扛住断线」与「可以断点重来」两堆了吗？重来的成本我算过吗？
我有没有把定时器当成「让进程活着」的手段 —— 而它其实是一个会自动续期的计费开关？
怎么上手 · 验证步骤
第一步只做一件事：把自家 agent 的等待逐个列出来，标上「谁在等」 —— 是你的代码在等工具返回、等容器起好、还是在等一个到点的定时器。多数框架的日志或用量面板能看到任务在内存里待了多久。挑出最长的那一个，回答两个问题：它断线之后能不能从中断处接着跑（能 ⇒ 归类「可重来」）、它的重来成本是多少（重跑一次要花几分钟 / 多少钱）。只有「不能重来 或 重来很贵」的才需要驻留保护。
下次长任务结束后看两个数：① 这轮任务里「客户端断开而进程仍在」的总时长 ② 其中真正在干活的占比。第一个数下降、第二个数不降，说明分类做对了；如果发现总时长在涨而产出没变多，多出来的多半是定时器撑着的空转 —— 那就把那个定时器改成「只在有待办时才挂」。