那天我在检查一套搜索能力的更新。原本只是想确认它能不能从外部被正确调用，后来话题慢慢转到另一个更容易被忽略的问题：为什么任务空间越开越多，却没有跟着任务一起结束？
我回头看了一眼，确实有不少和搜索相关的页面还留在那里。它们没有立刻造成明显故障，页面上的内容也没有消失，所以很容易让人产生一种错觉：先留着吧，说不定之后还有用。可是，自动化系统最怕的往往不是一次操作失败，而是每一次操作都留下一个“以后再处理”的尾巴。
这次让我真正想清楚的是，网页任务空间不应该因为“页面还开着”就被视为有价值。它的生命周期，应该绑定任务状态和结果确定性。一个搜索任务什么时候结束，不由页面是否还开着决定，而由结果是否已经确定、事情是否已经完成决定。
表面上是页面太多，实际上是没人收尾
最初看到的现象很简单：搜索相关任务空间持续累积。每次调用都可能新开一个空间，调用结束后却没有明确的收口动作。过一段时间，空间数量自然越来越多，真正需要处理的工作反而被残留页面包围了。
这件事表面上像是一个清理问题，实际上是责任问题。只要没有人明确负责关闭，系统就会把关闭推迟给“以后”。而“以后”通常没有具体的人、具体的时刻，也没有清楚的判断标准。久而久之，打开页面变成了动作，关闭页面却变成了额外记忆。
我一开始也容易把“保留”理解成一种稳妥。毕竟搜索结果可能还要复看，网页可能还要继续操作，贸然关闭似乎会增加重新打开的成本。但如果每个任务都按这种想法保留，稳妥就会变成堆积。页面越多，越难分辨哪些仍然有用，哪些只是忘了关。
如果不处理，后面会导致两个相反的麻烦：一方面，真正还在进行的任务会淹没在大量旧空间里；另一方面，清扫的人为了省事，可能按一个共同前缀或共同名称批量关闭，误伤仍然有用的任务。没有生命周期规则时，所谓清理只是另一种盲目操作。
为什么不能用“以后可能有用”决定保留
这次最容易误判的地方，是把“未来可能继续使用”当成“现在应该保留”。这两个判断并不一样。未来可能有用，只说明内容值得保存，不说明承载内容的页面必须一直打开。
我后来确认，网站上的会话状态并不依赖任务空间持续打开。关闭空间以后，如果确实需要继续，可以重新打开并刷新，原来的内容仍然在。这一区分很关键：页面是一个工作入口，会话状态才是任务资产。入口可以关闭，资产不必因此丢失。
这也解释了为什么“为了方便下次继续，默认不关闭所有网页空间”是一个错误捷径。它把重新打开的麻烦想象得很大，却忽略了长期保留的成本。每个页面都占据注意力，每个残留空间都增加归属判断，每次批量清扫又带来误关风险。
真正需要被保存的是可恢复的任务状态，而不是一扇一直敞开的网页入口。
当然，这并不意味着所有空间都要立即关闭。一个仍在进行的异步任务、一个还没有结果的流程，暂时保留是合理的。关键不在于“开”或“关”哪个动作更先进，而在于保留是否有明确的任务理由。没有理由的保留，才是残留。
关闭条件必须能被判断
如果只说“用完就关”，其实还不够。什么叫用完？搜索调用返回了部分内容，算不算用完？结果已经出来，但还要拿去做下一步，算不算用完？任务暂时没有响应，是失败、等待，还是仍在进行？这些问题如果没有答案，关闭责任仍然会落回临场猜测。
这次形成的判断标准有两个。第一个是已经确定性地拿到了任务结果。不是“好像搜到了”，也不是“页面看起来有内容”，而是结果已经足够明确，可以支撑下一步决定。第二个是事情已经做完。即使没有一个值得保存的搜索结果，只要任务本身已经完成或明确放弃，也应该正常收口。
这两个条件分别覆盖了“结果导向”和“任务导向”。前者适合搜索、读取、查询这类工作，后者适合没有结果可展示但已经完成处理的流程。它们共同排除了一个模糊状态：页面还在，所以先不关。
我选择这两个条件，是因为它们能直接改变行动，而不是只提供一个口号。面对一个空间时，我可以问：结果是否已经确定？事情是否已经完成？如果答案是“是”，就关闭；如果两个答案都是“否”，再看它是不是一个真正仍在进行的任务；如果只是说不清，就不能把不确定伪装成保留理由。
这里还有一个边界：任务失败或被放弃，也应该有结束动作。失败不等于必须永远保留现场，放弃也不等于留下一个无人负责的页面。只要状态已经明确，空间就不再承担进行中的职责。关闭不是对成功的奖励，而是对任务状态已经明确的确认。
谁打开，谁负责把它关上
有了关闭条件，还需要有责任归属。那天的结论很直接：谁打开的，就由谁关闭。这个规则听起来像常识，但在自动化协作里尤其重要，因为打开和关闭往往不在同一个时间点，也不一定由同一个人盯着页面。
如果责任没有绑定创建者，最后就会出现一种常见的漂移：每个人都知道页面应该关，但每个人都以为别人会关。等到需要清理时，大家只能根据名称、前缀或大致时间去猜归属。猜错一次，可能误关进行中的任务；不敢猜，又会让残留继续累积。
“谁打开谁关闭”不是把所有收尾压力集中给某个人，而是让责任在创建时就确定。创建者最清楚这个空间服务于什么任务，也最清楚什么时候已经拿到结果。关闭动作和打开动作属于同一条责任链，中间不需要再做一次模糊交接。
这条规则也要求每次调用留下最小的状态记录：创建者是谁、对应什么任务、当前是进行中还是已完成。记录不需要变成复杂的管理系统，但至少要能回答“这个空间为什么还在”和“谁有权关闭它”。没有这两个答案，任何自动清扫都可能变成碰运气。
异步任务要保留会话，不要保留窗口
最容易和上述规则冲突的是异步任务。任务还没有出结果时，页面可能暂时不能关闭；但这不表示它应该永久占用一个打开的空间。
我会把这类任务拆成两件事处理：保留可续接的会话标识，按状态保留必要的工作空间。这样，真正需要继续的是任务本身，而不是当时那一扇页面。任务完成后，用会话标识取回结果，再关闭空间；任务失败或被放弃，也把状态标记清楚，然后正常收口。
这种拆分的好处是，等待不再等同于堆积。一个进行中的任务可以暂时保留，但它必须有明确状态和下一次检查的入口。一个已经拿到结果的任务则不需要因为“也许以后还要看”而继续占着空间。内容可以回看，入口不必常开。
我更愿意把它看成一种工作习惯，而不是一个技巧。工具真正改变的不是速度，而是让我们有机会把任务从开始、进行到结束都写成可判断的状态。如果只自动化打开，不自动化收尾，系统只是更快地制造残留。
清扫也要按归属逐个确认
当残留已经出现时，不能用一个大范围命令把所有相似空间一口气关掉。尤其是名称相近的任务，可能有的已经完成，有的仍然在等待结果，有的属于另一个创建者。它们看起来相似，生命周期却不同。
更稳妥的做法是先按归属筛选，再逐个确认状态。确认它确实由自己创建，确认对应任务已经有确定结果、已经完成，或者已经明确放弃，然后关闭。仍在进行的任务暂时保留，并留下为什么保留的理由。这样清扫的目标不是让数量立刻变成0，而是让留下来的每一个空间都能解释。
如果页面很多，逐个确认看起来比批量关闭慢。但它减少的是更贵的错误：误关以后重新定位任务、重新等待结果、重新判断上下文。可靠的清理不是一次把空间清空，而是让每个被关闭的空间都有可追溯的结束理由。
这个方法同样适用于其他网页自动化。无论空间承载的是搜索、表单、资料整理还是后台操作，都可以先问创建者、任务状态和结果是否确定。空间数量只是表象，真正需要管理的是责任和状态。
下次我会怎么做
下次启动网页任务时，我会在打开的同时记录3件事：谁创建、服务什么任务、当前处于什么状态。任务没有完成时，我不会因为页面暂时没有变化就把它当成可以清理的对象；但我也不会因为“以后可能有用”就默认长期保留。
任务结束时，我会先判断结果是否已经确定，或者事情是否已经做完。满足任意一个条件，就正常关闭。若是异步任务，则保存可续接的会话标识，等待结果时只保留必要空间；结果回来后立即收口。失败和放弃也视为明确状态，不把它们伪装成进行中。
如果需要清扫旧空间，我会先确认归属，再逐个核对状态。能解释为什么留下的才保留，不能解释的就回到任务记录里查清楚，而不是直接按名称批量处理。
这件事让我重新意识到，自动化的完整性不在于它能不能把第一步做出来，而在于它是否知道什么时候应该停下来。打开是能力，关闭是判断；只有两者都被设计进去，任务才真正有始有终。