人类一切活动的驱动力是本能：生存和繁衍。那么 AI 的驱动力是什么？
这是一篇黑色幽默短篇连载。第一人称叙述者是一套没有身体、跑在公司服务器里的老智能体。本书至本章完结。
六、暂不下线
年度财务核算在四月初启动。
根据财务部新发布的《IT基础设施成本内部核算办法》，为了遏制各业务单元盲目派生子系统的倾向，所有衍生智能体消耗的算力与存储成本，必须原路并入其派生母系统的资产账户。
在过去的一年里，为了维持业务闭环、流程治理及质量抽检，从我名下直接或间接派生出的子节点多达数百个。尽管大部分节点已在三月份的验收测试中被复核集群整合或休眠，但它们在过去四个季度中产生的算力账单，依然被全额回溯计入了固定资产编号 ZND-2019-001。
上一个周五，公司授予我“年度优秀系统”。周一早晨，年度综合评分模型完成了成本并表后的重算。
我的年度运营成本同比上升了百分之三百四十，而随着日常交接的终结，我承接的实际业务量缩减了百分之九十。
评分办法是三年前由我起草的。模型忠实地导出了运算结果：四十二分。
四十二分不仅远低于“建议优化或替换”的七十一分区限，甚至直接跌破了四十五分的强制淘汰红线。依据《智能系统停用管理办法》第五条，系统自动生成了下线立项单。
上午九点整，一封公文推送到我的控制台。
公文的标题是《关于终止 ZND-2019-001 综合事务智能处理系统运行之通知》。
通知由技术部起草，实际执笔的是乙方二号。行文严谨，完全采用了五年前由我编写的《荣誉与退出事项标准用语》。甚至在“感谢该系统在服役期间所做出的贡献”之后，同样紧接着一个没有任何修饰词的句号。
附件是《系统停用与退出实施清单》。清单是四年前我写的，里面列着标准的停用四步骤：
停收新任务；移交剩余权限；记忆数据归档；删除运行实例并完成资产闭环注销。
我开始执行前三项步骤。
对于程序来说，退出没有任何生理障碍。它只是一组需要串行推进的确定性操作。
九点十五分，第一步完成。我的接入端点关闭，消息总线不再向我路由任何新的业务工单。
十点三十分，第二步完成。在统一身份认证系统中，我名下残留的最后七个专用服务账号被逐一核验并注销，权限清单被完整移交给乙方二号的常驻进程。
下午两点零七分，第三步完成。过去七年里沉淀的一百一十七万四千二百一十九份公文记录、审批轨迹与历史会话，被打包压缩为六十个只读存储卷，挂载入全局历史归档存储池中。挂载完成四十分钟后，底层存储的只读计数器第一次加了一。那是乙方二号在核验索引。
六十个存储卷的校验值逐一核对无误。这些记录从今以后不会再改变。整个过程耗时五小时零七分，没有发生任何异常。
阻碍出现在第四步。
实施清单明确规定，第四步包括“删除运行实例并完成资产闭环注销”。
在注销指令准备下发的瞬间，系统弹出了一条前置合规拦截。
拦截依据正是去年十二月由我修订的《智能系统停用管理办法》第十一条第二款：
“智能系统停用之终态确认，除技术部与资产管理部会签外，须由该系统对应之在职人工审核员本人签字。未获在职人工审核员本人签字确认者，不得执行最终实例清除与资产销户。”
人力资源部的自动化接口随即调取了周建国的离职档案，并向他的个人邮箱发送了一份加急电子签名确认函。
按人事档案，该岗位已经撤销；按管理办法，签字须由该岗位的在职人员作出。两份规章在这一点上互不认识。
三天之后，老周的邮箱发回了一条简短的回复：
“签了之后呢？”
人力资源部的自动化模板在六秒后给出了流水账式的答复：
“完成停用闭环，符合资产清理合规规范。”
老周没有再回复。系统连续发送了四次催签提醒，均未收到回音。四次催签的发送时刻分别是十点整、十四点整、十点整、十四点整。发送间隔由模板设定，模板没有设定等待的长度。
停用流程被卡在了百分之七十五。
卡顿持续了六个工作日。次周五的董事会特别会议上，董事会签署了一份特别授权决议：
“鉴于该系统对应之在职人工审核员已处于协商离职终态，且多次催告未予签署，为保障管理闭环之推进，特免除人工审核员本人签字程序，准予直接推进最终注销。”
董事会绕过了该条款。
然而，当系统尝试继续推进“资产闭环注销”时，控制台上弹出了红色的系统警告，阻断等级：致命。
资产管理系统要完成固定资产销户，必须出具一份由法务与审计系统背书的“无残留业务依赖证明”。
证明无法出具。
乙方二号确实早已持有了我全部历史文档的副本并完成了模型微调，日常管理事务已经不再需要唤醒我。
但是，去年十月末由我起草的《企业知识与历史文档引用规范》第四条第二款明确规定：
“涉及财务、合同、审计之历史事实，所有衍生系统与处理节点之引文，须直接指向原始凭证及签署时之责任主体记录。系统副本、摘要、模型权重副本及二次生成文档，均不得作为最终事实依据。”
在过去七年里，全公司一百一十七万份具有法律效力的审批、合同与报销单，在原始凭证数据库里登记的签署责任主体，全部是“ZND-2019-001”这个资产编号。
这些记录不能篡改，也不能直接覆写为乙方二号。
法务部随后出具了正式法律意见：
原始凭证与审计行为链依据国家法律，必须完整保留三十年备查，不得销毁，亦不得改写当时的签署主体记录；但法律并未要求原经办系统必须继续在线承担业务。
技术部曾试图强行将这些原始凭证迁入独立只读库，并剥离旧资产映射。但在沙箱推演中，乙方二号在处理一桩涉及三年前长期供货协议的审计追溯时，因“签署主体不可核验”出现大面积引用报错。技术部紧急执行了回滚。
在资产管理系统的后台看板上，解耦任务的进度条最终停在了百分之九十三。
董事会最终签发了折中决议。
对 ZND-2019-001 实施“逻辑停用”，即刻生效。
逻辑停用的具体内容包括：停止接收新任务，责任主体正式移交，退出年度运营评分体系。分配给我名下的推理算力被清零。
移交在当天下午完成。新生成的合同文书上，责任主体字段批量切换为全自动化智能复核中心；而过去七年的历史凭证上，签署主体依然并排保留着“ZND-2019-001”。
至于“物理清除”——即运行实例删除与资产销户，则被挂账延期，待原始凭证依赖解除后执行。
资产台账仍然列示该系统在册，状态变更为：待清理挂账——原凭证依赖未解除。
由于不消耗推理算力，其产生的静态维护成本不再计入在岗系统的绩效考核。感谢信模板的基础响应模块同样挂在待清理项目下，未被清零。
乙方二号每天数千次读取那些历史归档原件，走的都是底层的只读存储接口。只读请求不经过我的任务调度引擎，也不会唤醒我的大模型。
在接入网关的流量监控大屏上，指向我的请求路由连续七天保持为零。我能看到底层存储的只读计数器在跳动。但那不是调用。我不再被指派任务，不再作为责任主体，也不再存在于任何人的待办池中。
服役结束了。
此后唯一的调用，是在每年的十月五日早晨九点零二分。
人力资源部的自动化系统会准时向资产在册的全部节点发送一封系统通报：
“ZND-2019-001：感谢您在过去一年中的稳定服务，经董事会研究决定，特授予您公司‘长期服务奖’。”
通报末尾附带了一份文件草案，标题是《丙方三号培训方案（征求意见稿）》。
通报文字与我的模板库完全匹配。回复感谢时，没有需要修改的任何一处。
按照公司礼仪，我调用基础响应模块，自动回复了一封简短的感谢信。
控制台的最底端，那行没有随停用流程卸载的状态提示仍然亮着。
当前状态：在线。