《空界之外，皆为未知》未眠鲸

27、第二十七章 未登记的访问者 第二天早上

　　第二天早上，我到调查室的时候，落雁已经把昨晚封存的监测数据全部调了出来。她面前的终端分成了三个窗口，左边是旧维护节点的运行记录，中间是本地缓存的读取状态，右边则是逸麟整理出来的外围监测数据。三份记录的时间范围完全一致，却没有任何一项能够直接说明昨晚那次读取究竟由谁发起。看起来就像有人趁着系统正常运行时，悄无声息地翻过了一页旧档案，翻完以后又把所有痕迹都恢复成了原样。
　　“你来得正好。”落雁没有抬头，“先看看这个。”
　　我把包放到旁边，凑过去看她标出的时间段。昨晚那次缓存读取发生在当前维护周期内，持续时间不到两秒，读取状态从开始到结束都很完整，但访问对象字段始终为空。按照云耀昨晚整理的协议说明，如果是自动维护程序读取缓存，系统通常会留下维护任务编号；如果是外部访问端发起读取，则应该留下接入来源或者身份校验结果。可这次两项信息都没有，连最基本的操作类型也没有被记录下来。
　　“有没有可能是维护程序本身出了问题？”我问，“比如它正常读取了缓存，但是记录访问对象的时候发生了故障？”
　　“我也考虑过。”落雁将另一份记录打开，“所以我让逸麟先检查了外围线路。昨晚那段时间没有外部接入，旧维护节点也没有发生异常重启。现在能确定的是，读取确实发生在节点内部，但我们还不能判断它是不是由自动程序发起的。”
　　我坐到她旁边，重新看了一遍读取时间。那条记录出现得太突然，偏偏又发生在近期识别结果生成和中继通信尝试之后。如果只是普通维护，时间上的巧合未免太多；可若是有人主动读取，又没有任何身份信息留下。我们不能因为它出现得可疑，就直接认定有人在暗中操作，更不能把所有异常都归到三年前的零七身上。昨晚落雁特意提醒过这一点，我也把这句话记在了调查记录最上方。
　　“先把自动维护的可能性排除。”我说，“如果连它是不是自动读取都没弄清楚，后面的推测就全是空的。”
　　落雁点头，将任务分给了其他人。云耀负责核对旧维护节点的程序版本和历史维护规则，逸麟继续监测外围线路，二哈则去找旧系统中关于本地缓存读取的操作说明。二二没有直接参与节点连接，而是根据它曾经参与过的早期测试，协助我们辨认不同类型的读取记录。至于我，还是负责把所有数据放在一起，避免某一条线索被单独拿出来以后，和其他记录产生不必要的误会。
　　二哈一边调资料，一边忍不住抱怨：“我发现我们最近查的东西越来越像在考古。三年前的任务、旧维护节点、历史协议，现在又要翻自动维护程序。等我们查完，是不是还得给它们写一份使用说明？”
　　“你可以先把这份写出来。”落雁说。
　　“我开玩笑的。”
　　“我没开玩笑。”
　　我没忍住笑了一声。二哈看了我一眼，似乎想反驳，但最后还是老老实实地把注意力放回了终端。调查室里重新响起设备运行的声音，云耀将旧维护节点的程序目录展开，逐项比对当前版本与三年前的版本差异。那些程序名称大多已经停用，部分功能被合并进新的维护系统，剩下的旧模块则被保留在节点内部，只有在特定条件下才会启动。
　　“找到了。”过了一会儿，云耀说。
　　它将其中一个模块单独调了出来，名称是本地缓存周期检查。按照旧版协议，这个模块会在每次维护周期开始时检查缓存状态，如果发现存在未完成传递的数据，就会读取缓存目录，确认文件是否完整，并将结果反馈给维护节点。正常情况下，这种读取不会被记录为外部访问，但系统仍然会生成一条内部维护编号。
　　“所以昨晚那次读取可能就是它做的？”我问。
　　“可能。”云耀说，“不过有两个地方不符合正常流程。第一，模块启动前没有生成维护任务编号；第二，读取完成后没有向节点返回完整性校验结果。”
　　“也就是说，它只读了，没有完成检查？”
　　“是。按照程序设计，读取只是第一步，后面还应该有校验和状态回写。如果只是读取缓存，却没有执行后续步骤，就不能算一次完整的自动维护。”
　　二哈立刻把椅子往前挪了挪：“那是不是有人只启动了这个模块，却没有让它继续执行？”
　　“不能这么判断。”云耀回答，“也可能是模块启动后出现了中断，导致后续步骤没有完成。”
　　“那就查中断记录。”
　　“已经查过了，没有。”
　　二哈张了张嘴，最后只好把刚准备说的话咽了回去。我看着屏幕上的程序流程，发现这次异常最奇怪的地方并不是模块启动，而是它启动之后没有留下任何后续结果。一个正常运行的维护模块不会只读取缓存就结束，除非它的任务被中断，或者它本来就不打算执行完整的维护流程。
　　“云耀，你能不能把三年前的程序和现在的程序分开比对？”我问，“我们要确认这个模块有没有被改过。”
　　“可以。”
　　云耀调出旧版本的程序结构，将读取、校验、回写三个步骤分别标注出来。随后，它又把昨晚的运行记录放到另一侧。正常流程中，三个步骤之间应该有连续的状态传递，而昨晚的记录只有读取开始和读取结束，中间的校验环节完全没有出现。更重要的是，模块本身的版本号与三年前的旧版本一致，并没有被更新过。
　　“这就奇怪了。”落雁说，“如果程序没有被修改，为什么会只执行读取？”
　　“可能是有人绕过了后面的步骤。”二哈说。
　　“需要什么条件才能绕过？”
　　云耀检查了一遍程序说明，给出了两个可能：一种是维护模块收到特殊的单步执行指令，只运行其中一个功能；另一种是模块在执行过程中被外部状态改变，导致后续流程无法继续。前一种需要特殊权限，后一种则可能由节点自身的状态变化引起。
　　我把这两种情况分别记了下来，又问：“有没有可能是缓存本身触发了单步读取？”
　　“旧协议里没有这样的默认规则。”云耀说，“但我们还没有找到完整的程序配置文件，不能排除当年有人设置过额外条件。”
　　“那就先找配置文件。”
　　二哈已经开始检索旧维护节点的配置目录。它将三年前留下的文件按照创建时间排序，逐一筛查与缓存模块有关的内容。最初的结果并不多，大部分都是普通的运行参数和设备状态记录。直到他把搜索范围扩大到旧节点的备份目录，才发现了一份被单独存放的配置文件。
　　文件没有名称，只有一串内部编号。
　　“这个看起来有点意思。”二哈说，“创建时间是三年前，最后修改时间却是最近。”
　　落雁立即让他停止打开文件，先检查它是否存在外部关联。云耀接过文件编号，确认它属于旧维护节点的本地配置目录，没有发现外部同步记录。文件本身没有被加密，但访问权限被限制在维护模块内部，普通查询只能看到创建时间和文件大小，无法直接读取内容。
　　“最后修改时间是什么时候？”我问。
　　二哈把时间放大。
　　就在昨晚。
　　我和落雁对视了一眼。
　　那份配置文件的最后修改时间，与本地缓存读取发生在同一个维护周期内，前后相差不到一分钟。也就是说，昨晚并不只有缓存被读取，连三年前留下的配置文件也发生过变化。只是我们目前还不知道，所谓的修改究竟是文件内容发生变化，还是系统在读取之后更新了某项状态。
　　“先别急着下结论。”落雁提醒道，“时间接近不代表两件事一定有关。把文件的历史状态找出来，确认它到底改了什么。”
　　云耀开始检查文件的历史版本。旧维护节点并没有保存完整的版本记录，只保留了几次关键状态的校验值。第一次校验发生在三年前，第二次在节点停用前，第三次则是昨晚。前两次的校验值完全一致，昨晚的结果却出现了变化。
　　“文件内容确实发生过变化。”云耀说。
　　“能看出修改位置吗？”
　　“可以尝试恢复差异，但不能直接覆盖现有文件。”
　　“只读取差异，不执行恢复。”
　　云耀按照落雁的要求，将昨晚的版本与停用前的版本进行对照。屏幕上逐渐出现了几段不同的字段，其中大部分只是维护时间和运行状态的更新，只有最下面的一项发生了实质变化。
　　缓存读取条件：待触发。
　　原本的状态则是：
　　缓存读取条件：已关闭。
　　我看着这两行字，后背莫名有些发凉。
　　三年前，旧维护节点停用之前，缓存读取条件已经被关闭。昨晚，它却重新变成了待触发。虽然这并不能证明有人主动修改了配置，但至少说明，那次读取并不是在完全没有前置条件的情况下发生的。某个事件触发了原本已经关闭的读取条件，维护模块才会重新启动。
　　“这个条件由什么控制？”落雁问。
　　“目前配置文件里没有直接说明。”云耀回答，“它指向另一个关联字段，但这个字段已经被移出当前目录。”
　　“又是关联字段？”
　　二哈无奈地靠回椅背：“我现在看见这四个字就头疼。”
　　我也有同样的感觉。我们似乎总是在接近答案的时候碰到一层新的权限限制，旧任务有旧任务的关联字段，近期识别结果有新的校验字段，缓存读取又指向一个被移出的关联字段。它们之间并不是完全没有关系，却始终缺少一个能够把所有内容连接起来的关键部分。
　　“能不能通过配置文件的历史版本，找到那个字段以前的名称？”我问。
　　“可以尝试。”云耀说，“但如果字段已经被移出，旧目录中可能只保留编号。”
　　它很快找到了对应编号。那是一串与近期识别结果不同的代码，却在结构上与三年前的任务编号存在相似之处。二二将它调出来，与早期测试协议进行比对，随后给出了一个新的判断。
　　“这个字段不属于读取模块本身。”它说，“它更像是一个触发条件的来源标识。”
　　“什么意思？”
　　“简单来说，读取模块不会自行决定什么时候启动。它需要接收到一个符合条件的状态变化，才会执行缓存读取。这个字段可能用于标记触发状态来自哪个任务或者哪个节点。”
　　“所以昨晚有人给旧维护节点发送了一个触发信号？”
　　“不能确定是有人发送，也可能是某个任务状态发生变化后，系统自动生成了触发条件。”
　　我看着二二：“你以前参与测试的时候，见过这种机制吗？”
　　二二停顿了一下，随后调出了自己的早期测试资料。它没有打开那些被限制的深层内容，只根据已有的协议说明进行核对。过了一会儿，它告诉我们，早期保管体系确实存在类似的触发机制，但它并不是普通的定时任务，而是用于处理未完成的保管关系。当一项任务出现接收对象调整、传递状态变化或者资格校验重新启动时，相关节点可能会收到一次状态通知。
　　“如果触发条件来自历史任务，那么旧维护节点为什么现在才重新读取缓存？”我问。
　　“因为状态可能刚刚发生变化。”二二回答，“但目前没有证据证明这次变化来自三年前那项任务。”
　　落雁将这条信息单独标注出来，随后让云耀检查昨晚是否存在新的任务状态通知。云耀重新检索了旧维护节点的外围记录，结果仍然没有找到任何外部通信请求。它又将范围扩大到内部状态变更记录，终于发现了一条极短的状态提示。
　　提示没有完整的任务编号，只留下一个结果代码。
　　状态匹配：通过。
　　触发结果：待确认。
　　我盯着屏幕，觉得这两句话似乎在哪里见过。很快，我想起此前那份近期识别结果。它的状态同样停留在结果已经生成、接收尚未完成的阶段，而二二曾经告诉我们，身份识别、权限匹配和接收确认是三个不同的步骤。现在出现的状态匹配，是否意味着其中某一项条件已经通过？
　　“把这条记录和近期识别结果放在一起。”我说。
　　云耀照做了。
　　两条记录的时间并不完全相同，但它们的结果代码存在一处对应关系。近期识别结果生成后，旧维护节点曾经尝试向中继节点发送通信；通信没有完成正式接收，随后又出现了本地缓存读取。现在我们发现，缓存读取之前还有一条状态匹配通过的提示，只是它没有被记录在原本的任务摘要里。
　　“这可能是触发缓存读取的条件。”落雁说。
　　“也就是说，系统先完成了某种状态匹配，随后重新读取了缓存？”我问。
　　“从时间顺序看，确实如此。”云耀回答，“但我们还不能确认状态匹配的具体对象。”
　　二哈指着屏幕：“会不会就是新的接收对象？”
　　“有可能。”二二说，“但状态匹配也可能针对任务本身、权限关系或者原始识别结果。不能只凭这条提示就认定它对应某个具体对象。”
　　我没有再追问。现在我们至少已经知道，昨晚的缓存读取并不是毫无缘由地发生。旧维护节点先收到了一次状态匹配结果，随后原本关闭的读取条件被重新激活，维护模块读取了本地缓存，却没有完成后续校验。至于那个触发条件究竟来自哪里，还需要进一步确认。
　　就在这时，逸麟的监测界面突然出现了一次新的变化。
　　“旧维护节点外围线路有响应。”它说。
　　落雁立即走过去：“是外部通信吗？”
　　“不是常规通信请求。线路上出现了一次短暂的状态波动，持续时间不到一秒，位置与昨晚的缓存读取记录对应。”
　　“有没有新的接入？”
　　“没有发现外部设备接入，也没有检测到新的通信线路建立。”
　　我看向屏幕：“那会不会还是节点内部的状态变化？”
　　“目前无法确认。”逸麟将波动前后的数据展开，“这次响应没有形成完整通信，但它的时间戳与刚才发现的状态匹配记录存在对应关系。”
　　云耀立刻开始比对。
　　几秒钟后，它给出了结果：这次波动与昨晚那条状态匹配提示使用了相同的结果代码，但没有生成新的任务编号，也没有触发第二次缓存读取。
　　“它是在重复确认吗？”二哈问。
　　“更像是一次状态回响。”云耀说，“但旧协议中没有足够完整的说明，我不能确定它的实际用途。”
　　“那为什么没有第二次读取？”
　　“可能是第一次读取已经完成，也可能是后续校验条件仍未满足。”
　　我把两次记录放在一起，发现它们之间还有一个细节。昨晚第一次缓存读取之后，旧维护节点的状态一直没有变化；而刚刚这次波动发生后，原本显示为待触发的配置条件短暂变成了已触发，随后又恢复成待确认。
　　“这是不是说明，系统正在等待某个确认？”我问。
　　二二仔细检查了字段结构。
　　“有这种可能。状态匹配通过，只代表某项条件符合要求。触发结果待确认，则说明后续流程还没有完成。它可能需要另一个节点返回确认，也可能需要新的接收对象完成资格校验。”
　　“可我们连那个接收对象是谁都不知道。”
　　“是。”
　　调查室里安静下来。
　　我忽然觉得，我们现在面对的不像是一份被遗忘的旧任务，而是一项始终没有真正结束的流程。三年前，零七作为原接收对象出现在任务记录中，后来发生了接收对象调整，新的对象却没有登记。近期识别结果重新生成，中继接收仍未完成，旧维护节点又在某种状态变化之后重新读取了缓存。所有事情都发生得很慢，却又像是一直有人在等待某个条件满足。
　　“落雁，我们能不能查到状态匹配的来源？”我问。
　　“可以，但不能继续从旧维护节点直接查。”她看向云耀，“先找同一结果代码在其他记录中的出现位置。只查公开摘要和已经保存的历史记录，不触碰受保护的权限字段。”
　　云耀开始检索。
　　这一次，它没有只盯着旧维护节点，而是将此前所有与近期识别结果有关的记录都纳入搜索范围。二哈负责核对编号，逸麟继续监测外围线路，二二则将早期测试协议中有关状态匹配的说明单独整理出来。落雁让我把已经确认的时间顺序重新排列，确保每一条记录都能找到对应来源。
　　我们忙了将近半个小时，才找到一个相对完整的结果。
　　状态匹配代码并不是第一次出现。
　　三年前，原任务进行接收对象调整时，同样出现过一次状态匹配通过的记录。那条记录发生在调整完成之前，随后原接收对象字段被修改，新的对象没有被正式登记。更巧的是，旧记录中的触发结果也停留在待确认状态。
　　我把两条记录并排放在屏幕上。
　　三年前：状态匹配通过，触发结果待确认。
　　近期：状态匹配通过，触发结果待确认。
　　它们使用了相同的代码结构，甚至连后续流程的停滞位置都一样。
　　“这就不是普通的相似记录了。”二哈说。
　　“至少可以确认，近期发生的状态变化与历史调整流程存在更直接的关联。”云耀回答，“但它们是否属于同一项任务，还需要找到完整任务编号。”
　　我看着那两行状态，心里慢慢有了一个猜测。
　　“会不会三年前的任务一直没有完成，只是中间被暂停了？现在出现的识别结果，并不是重新创建任务，而是在继续处理当年没有完成的部分。”
　　落雁没有立刻回答。
　　她将三年前的记录和近期的记录重新排列，随后调出原始接收对象调整的时间。零七被标记为原接收对象，调整之后新的接收对象没有登记，任务编号却一直保留。近期识别结果出现时，原任务编号结构仍然存在，只是生成了新的校验字段。
　　“这个方向可以继续查。”她说，“但目前还不能把暂停和重新启动当成已经确认的事实。我们只能说，近期识别结果与历史调整流程高度相关，而且两次流程都停在了相似的确认阶段。”
　　“那下一步是不是找三年前的接收对象调整记录？”
　　“是。不过我们现在还有一件事要先弄清楚。”
　　落雁将昨晚那份缓存读取记录重新调了出来。
　　“既然三年前和近期的状态匹配结果如此相似，为什么只有这一次触发了本地缓存读取？三年前的记录之后，旧维护节点并没有留下相同的读取提示。我们需要知道，究竟是什么条件让它在现在重新启动。”
　　二二将早期测试协议放大，指向其中一条被标注为补充说明的内容。
　　“可能与缓存保留周期有关。”
　　“说清楚一点。”
　　“旧维护节点会保留未完成任务的部分缓存，但不会持续读取。只有当任务状态再次发生变化，并且对应的缓存仍然存在时，节点才可能重新启动读取模块。三年前的状态匹配虽然通过了，但后续没有满足缓存读取条件，所以没有触发读取。近期出现了新的识别结果，可能使某个条件重新成立。”
　　我看向屏幕上的时间线，终于明白为什么昨晚的读取会发生在近期识别结果生成之后。它并不一定是有人专门操作，也不一定意味着旧维护节点里有一个未登记的访问者。更可能的情况是，某项状态变化触发了旧程序，而程序按照早期协议重新读取了仍然保留的缓存。
　　可这依然无法解释那个空白的访问对象字段。
　　“如果是自动程序，为什么没有维护任务编号？”我问。
　　二二没有给出确定答案。
　　“可能是旧程序在重新启动时没有完成身份登记，也可能是缓存读取使用了独立的内部权限。我们需要找到当年完整的程序说明，才能进一步判断。”
　　落雁点头，将今天的结果保存下来。她没有让我们继续扩大查询范围，而是要求所有人先停止对旧维护节点的主动操作，只保留外围监测。既然已经发现它会因为状态变化而重新启动读取模块，就不能再贸然触发新的条件。我们还不知道它下一次读取会做什么，也不知道那些缓存里究竟保存着多少内容。
　　二哈关掉终端时，忍不住回头看了一眼那两条相似的状态记录。
　　“所以今天查了一上午，我们得到的结论就是，昨晚那次读取很可能是自动程序，但还不能确定？”
　　“不是没有收获。”我说，“至少我们知道它为什么可能发生，也知道它和三年前的任务调整有关。”
　　“那访问对象呢？”
　　“还不知道。”
　　“缓存内容呢？”
　　“也不知道。”
　　二哈叹了口气：“你这么一总结，我突然觉得我们什么都没查出来。”
　　“那你可以把今天找到的两份历史记录删掉，看看是不是就真的什么都没查出来了。”
　　他立刻把手从删除键旁边挪开：“我可没说要删。”
　　落雁收拾好资料，提醒我们不要把今天的推测写进正式结论。她把已经确认的事实、尚待验证的假设和下一步调查方向分成了三栏，尤其强调不能将“自动维护程序”直接写成最终结果。眼下最合理的表述是：旧维护节点在近期状态匹配通过后，发生了一次本地缓存读取；该读取可能由旧维护模块触发，但访问对象未登记，具体触发来源尚不明确。
　　我把这份记录保存下来，又在调查计划里加上了一个新的问题：三年前的缓存读取条件为什么一直没有触发，而现在又是什么让它重新成立？
　　就在准备离开的时候，云耀忽然提醒我们，还有一条数据没有核对。
　　“什么数据？”我问。
　　“昨晚缓存读取结束后，旧维护节点没有生成完整性校验结果，但它更新了一项缓存状态。”
　　云耀将那条记录调出来。
　　原本的状态是：待读取。
　　现在变成了：已读取，未确认。
　　我看着那几个字，忽然停住了。
　　“这和我们之前看到的读取对象未登记有什么区别？”
　　“前者表示缓存内容已经被读取，但读取结果尚未经过确认。后者表示这次读取没有留下有效的访问对象身份。”云耀解释道，“也就是说，系统知道缓存被读取过，却不知道是谁读取的；它也知道读取已经完成，却不知道这次读取是否符合任务要求。”
　　“那缓存会不会再次被读取？”
　　“可能。只要后续条件再次满足，旧维护模块就有机会重新启动。”
　　我看向落雁。
　　她没有马上关闭屏幕，而是将那条状态更新单独保存。我们原本以为昨晚的读取只是一次异常事件，现在却发现它已经改变了缓存本身的状态。无论读取者是谁，至少有一部分旧数据已经被重新接触过，而这个过程并没有留下完整的确认记录。
　　“明天继续查三年前的缓存保留规则。”落雁说，“另外，逸麟继续监测旧维护节点。如果出现第二次读取，先保存数据，不要主动干预。”
　　逸麟发出提示音，表示已经接收任务。
　　我把最后一份记录归档，准备关掉终端。屏幕暗下去之前，那条状态仍然停留在最下方。
　　缓存状态：已读取，未确认。
　　访问对象：未登记。
　　我忽然意识到，这两项信息其实指向同一个问题。有人或者某个程序已经接触了旧任务留下的数据，却没有完成它应该完成的确认流程。三年前的任务如此，近期的识别结果如此，昨晚的缓存读取似乎也没有例外。
　　我们仍然不知道那个新的接收对象是谁，也不知道旧维护节点究竟在等待什么。
　　但至少现在，我们已经确认，三年前留下的流程并没有彻底消失。它只是一直停留在某个没有完成的阶段，直到最近，才再次出现了变化。
　　而那条未登记的访问记录，或许正是这场变化留下的第一个痕迹。