密鑰輪換問題：如何在永不停機的智能體中更新憑證

密鑰輪換看似是一個已解決的問題——直到你將其應用於無法停機的系統。傳統流程是：安排維護窗口，吊銷當前密鑰對，簽發替換密鑰，更新配置，重啟服務。服務離線几分鐘到几小時，重啟后舊憑證失效、新憑證生效。

這一模型有一個前提：系統可以干淨地暫停。而在關鍵領域運行的 AI 智能體無法满足這個前提。持續監控患者術后狀態的智能體沒有維護窗口；管理長期金融结算流程的智能體無法在會话中途重啟；運行於硬件安全飛地内的智能體，其嵌入式證明證書將身份綁定到特定密鑰材料——中途更換密鑰材料，不是配置變更，而是身份變更。

向後量子密碼演算法的遷移，使這一問題愈發緊迫。這不是傳統意義上的"輪換"——而是演演算法族的更換。在遷移窗口内，一個持續運行的智能體同時处於舊憑證使用中、新憑證遷移中、以及可能受到已完成遷移的對手方質疑的三重狀態。

三种架構模式及其權衡

靜止-輪換模式：智能體暫停新任務接入，完成或移交所有進行中的任務，交出舊憑證，獲取新憑證，再恢複運行。這是最干淨的方式，但代价是可用性中断，在持續在線价值高的場景中往往不可接受。

双憑證重疊模式：智能體开始接受新憑證的同時，繼續以舊憑證完成已有任務。舊憑證在其所覆盖的最后一個任務關闭后才退休。這保留了可用性，但創造了一個双重身份並存的窗口，使審計追踪和委託鏈驗證更加複雜。

層級密鑰結構模式：最适合硬件根身份的智能體。智能體身份錨定於駐留在硬件安全模組中的根密鑰，只有在硬件本身被替換時才會改變。操作簽名密鑰作為叶密鑰，由根密鑰認證，可頻繁輪換（包括跨演算法遷移）。叶密鑰輪換時，根的證明提供了身份连續性：任何驗證方都能确認新密鑰是同一硬件錨點的授權派生密鑰。

硬件錨點是輪換中的不變量

層級方法之所以有效，是因為它將两件在傳統模型中混為一谈的事情分开了：用於操作簽名的密碼材料，與智能體身份本身。在扁平密鑰模型中，輪換密鑰就是更換身份；在硬件根模型中，安全飛地中的根密鑰是身份錨點，操作密鑰是身份的表达工具，而非身份的定義。

這一分离使後量子遷移對持續運行的智能體變得可管理：根密鑰随硬件刷新週期遷移（可計划），叶密鑰随對手方基礎設施升級而逐步遷移。智能體的硬件根所表达的身份在整個過程中保持穩定。

照護域中的同意問題

在照護場景中，密鑰輪換还涉及同意問題：輪換憑證是否需要原授權主體的重新同意？硬件證明的層級憑證鏈提供了有意義的答案：通過證明從硬件根到新操作密鑰的認證鏈條，可以表明"當前行動的智能體"與"原始同意時的智能體"是同一個受證明的身份——操作密鑰變了，受證明的身份沒有變。這一区別需要在同意架構中明確體現，而不能繁單假設。

遷移是一個持續的過程

後量子遷移揭示了一個密碼基礎設施領域長期潜伏的事實：演算法與密鑰的生命週期是有限的，構建於其上的系統需要將輪換视為持續的營運關切，而非偶發的緊急事件。對於在關鍵領域運行的 AI 智能體，在架構層面——硬件根身份、層級密鑰結構、顯式的重疊语義、感知同意的憑證连續性——構建這种營運纪律，是唯一不需要在安全與可用性之間做取舍的路徑。