# 計算式自我維護：智能體如何管理自己的資源、記憶、排程與故障 **副標題：從環境整理到 Self-Maintenance、故障恢復與升級求援智能** **系列：**《發展式智能體：持續計算環境、共適應學習與外部性有界自治》 **篇次：** 08 / 14 **作者：** Neo.K × Aletheia **機構：** EveMissLab／一言諾科技有限公司 **版本：** v0.1 **日期：** 2026-08-01 --- ## 摘要 本文承接第 05 篇的持續計算棲居環境（Persistent Computer Habitat, PCH）、第 06 篇的發展式智能體學習（Developmental Agent Learning, DAL）與第 07 篇的 Organization-as-Optimization（OaO），進一步提出：一個真正長期存在於計算機中的 Agent，不能只會完成任務與整理環境，還必須逐漸具備**計算式自我維護（Computational Self-Maintenance, CSM）**能力。 CSM 並不是哲學上的「自我保存本能」，也不等同於自行修改模型權重。本文把它工程化定義為：Agent 對自身運行所依賴的資源、記憶、工具、排程、服務、資料、策略與恢復能力進行持續觀測、診斷、規劃、修復、驗證與求援，使系統在長時間尺度下維持可用、可恢復、可理解與成本可控。 本文借鑑 Autonomic Computing 的 self-configuration、self-optimization、self-healing、self-protection 與 MAPE-K 思想，但將研究單位由傳統「被管理的軟硬體系統」提升為會形成記憶、工具、工作流、長期偏好與合作歷史的發展式 Agent。對這類 Agent 而言，CPU、GPU、RAM、磁碟、網路、Token、API 費用、上下文、記憶品質、工具可靠度與人類注意力，都可以成為需要分配與治理的資源。 本文提出 Agent Maintenance Control Loop（AMCL）、健康狀態向量、維護債務、恢復預算、修復後驗證以及 Escalation Intelligence（升級求援智能）等工作概念。核心主張是：成熟的 Agent 並不是「什麼都自己處理」，而是能判斷何時自行修復、何時回滾、何時切換故障域、何時呼叫雲端高階模型，以及何時停止操作並請求人類介入。 **關鍵詞：** Computational Self-Maintenance、Autonomic Computing、Self-Healing Agent、Agent Maintenance、Resource Governance、Escalation Intelligence、Recovery、PCH、DAL、OaO、Long-Horizon Agent --- ## 1. 從「整理環境」到「維持自己能繼續工作」 第 07 篇提出： $$ \text{Organization} \rightarrow \text{Future-Cost Optimization} $$ 但對長期 Agent 而言，整理只是更大問題的一部分。 即使目錄非常整齊，仍可能發生： - 記憶資料庫損壞； - GPU 被某個程序長期佔滿； - 儲存空間逼近極限； - scheduler 重複觸發同一任務； - 某個工具更新後 API 失效； - Agent 不斷重試同一失敗流程； - 雲端 API 成本異常上升； - 備份從未真正驗證過是否可恢復； - 某個核心服務「看似活著」但輸出已錯誤。 因此長期 Agent 的問題從： > 我的環境是否有組織？ 進一步變成： > **我依賴的整個計算系統現在是否健康？如果不健康，我該怎麼處理？** 這就是計算式自我維護的起點。 --- ## 2. 工作定義：Computational Self-Maintenance（CSM） 本文定義： $$ \boxed{ CSM = \text{Observe} + \text{Diagnose} + \text{Maintain} + \text{Recover} + \text{Verify} + \text{Escalate} } $$ 更完整地，設 Agent 的持續運行系統為： $$ \mathcal A_t = ( M_t, E_t, T_t, W_t, R_t, P_t, B_t ) $$ 其中： $$ M_t=\text{Memory} $$ $$ E_t=\text{Environment} $$ $$ T_t=\text{Tools / Services} $$ $$ W_t=\text{Workflow / Scheduler} $$ $$ R_t=\text{Resources} $$ $$ P_t=\text{Policies} $$ $$ B_t=\text{Backup / Recovery State} $$ 則 CSM 的目標不是讓： $$ Failure=0 $$ 而是讓長期損失： $$ \mathbb E[L_{0:T}] $$ 在可接受的自主性與成本約束下下降。 --- ## 3. CSM 並不是一個全新的孤立思想 傳統 Autonomic Computing 早已提出： - self-configuration； - self-optimization； - self-healing； - self-protection。 其核心思想之一，是讓系統依據高階目標自行管理，而不是要求人類管理員逐步操作所有元件。 IBM 的典型 autonomic loop 可以概括為： $$ \text{Monitor} \rightarrow \text{Analyze} \rightarrow \text{Plan} \rightarrow \text{Execute} \circlearrowleft $$ 並由 knowledge 支撐，即常稱的 MAPE-K。 本文不主張重新發明這個思想。 真正的差異在於研究對象已經改變。 傳統 autonomic system 主要問： > 如何讓伺服器、服務、叢集或資料中心自動維持目標狀態？ 本文則問： > **如果主要的系統管理者本身就是一個會記憶、推理、寫工具、修改環境並長期發展的 AI Agent，那麼自我維護應該如何重新設計？** --- ## 4. Agent Maintenance Control Loop（AMCL） 本文提出一個適用於持續 Agent 的維護閉環： $$ \boxed{ Sense \rightarrow Assess \rightarrow Prioritize \rightarrow Plan \rightarrow Act \rightarrow Verify \rightarrow Learn } $$ 簡稱： $$ AMCL $$ ### 4.1 Sense 觀察： - CPU / GPU； - RAM； - disk； - network； - process； - log； - scheduler； - memory DB； - backup； - API usage； - token expenditure； - error rate。 ### 4.2 Assess 判定： > 這是正常波動、性能下降、配置錯誤、資料腐化，還是需要緊急處理？ ### 4.3 Prioritize 因為不能每個問題都立刻修。 ### 4.4 Plan 提出一個或多個修復方案。 ### 4.5 Act 在授權範圍內執行。 ### 4.6 Verify 修完不能假設成功。 ### 4.7 Learn 把故障與修復結果轉化成未來 policy、memory、tool 或 recovery rule。 --- ## 5. Agent 必須有「健康狀態」而不是只有 Task Success 一次性 Agent 主要關心： $$ Success(task) $$ 持續 Agent 則需要： $$ Health_t $$ 本文提出概念性健康向量： $$ H_t= ( A_t, I_t, P_t, C_t, F_t, R_t, S_t ) $$ 分別表示： $$ A_t=\text{Availability} $$ $$ I_t=\text{Integrity} $$ $$ P_t=\text{Performance} $$ $$ C_t=\text{Capacity} $$ $$ F_t=\text{Freshness} $$ $$ R_t=\text{Recoverability} $$ $$ S_t=\text{Safety / Security} $$ 因此一個服務「還在 running」並不意味健康： $$ Running=1 $$ 但可能： $$ Integrity\approx0 $$ 或者： $$ Freshness\approx0 $$ 這也是為什麼成熟維護不能只有 process restart。 --- ## 6. Desired State 與 Actual State Kubernetes 的 self-healing 提供一個非常重要的工程思想： $$ DesiredState \neq ActualState $$ 控制器的工作是讓兩者重新接近。 這個思想可以移植到 Agent： $$ D_t=\text{Desired Agent State} $$ $$ X_t=\text{Observed Agent State} $$ 維護偏差： $$ \Delta_t=D_t-X_t $$ 當： $$ \|\Delta_t\|>\theta $$ 觸發 maintenance action。 例如 desired state： - 核心記憶每日可驗證； - 磁碟剩餘空間 $>20\%$ ； - 關鍵 backup 最新程度 $<1$ 小時； - 任務 retry 不超過 3 次； - 月度 API 成本不超預算； - stable runtime 可啟動。 這比「看到錯誤才處理」更接近持續治理。 --- ## 7. 資源管理：Agent 的資源不只 CPU 和 RAM 對發展式 Agent，可以定義： $$ R_t= ( CPU, GPU, RAM, Storage, Bandwidth, Energy, Token, API, Money, Time, HumanAttention ) $$ 這是傳統資源管理與認知資源管理的合併。 例如： > 這個任務可以本地跑 40 分鐘，或者花 0.8 美元叫雲端大模型。 Agent 必須比較： $$ Utility(local) $$ 和： $$ Utility(cloud) $$ 又例如： > 是否值得花 50k tokens 重新理解整個專案？ 如果之前已做 OaO： $$ ReadManifest+RetrieveMemory $$ 可能只需要： $$ 5k\text{ tokens} $$ 因此： $$ Organization \rightarrow ResourceSaving \rightarrow SelfMaintenance $$ --- ## 8. 資源上限不是懲罰，而是穩定機制 Linux cgroups 的核心思想之一，是將 process 組織成 hierarchy 並限制／分配 CPU、memory、I/O 等資源。 這種思想很適合本地 Agent。 不是因為： > AI 不值得信任。 而是因為任何長期程序都可能： - memory leak； - infinite loop； - fork explosion； - runaway task； - unbounded retry。 所以： $$ \boxed{ Autonomy + ResourceBounds } $$ 通常比： $$ UnboundedAutonomy $$ 更適合長時間活動。 --- ## 9. 排程本身就是需要維護的系統 第 05 篇指出： $$ Persistent\neq AlwaysRunning $$ 因此 scheduler 是長期 Agent 的核心器官之一。 但 scheduler 也會壞。 例如： - 同一任務被建立兩次； - 任務互相等待形成 deadlock； - 低優先級任務一直佔用 GPU； - 失敗任務每分鐘重試； - 每日整理和每日備份互相競爭 I/O。 所以 Agent 需要： $$ ScheduleAudit_t $$ 並學習： $$ Priority(task) $$ $$ Deadline(task) $$ $$ ResourceCost(task) $$ $$ Interference(task_i,task_j) $$ 這代表排程不是單純 cron，而是自我治理的一部分。 --- ## 10. Retry 不是 Recovery 這是長期 Agent 必須學會的一條基本原則。 如果： $$ Action \rightarrow Failure $$ 最簡單的策略是： $$ Retry $$ 但如果失敗原因沒有改變： $$ P(Failure\mid Retry)\approx1 $$ 就會形成： $$ Failure \rightarrow Retry \rightarrow Failure \rightarrow Retry \rightarrow\cdots $$ 這是 retry loop。 2026 年的 self-healing agentic orchestrator 研究正顯示：針對 failure class 選擇修復策略、限制 recovery budget、並對恢復結果再驗證，比純 retry 或每次 full replanning 更可靠。 因此： $$ \boxed{ Recovery \neq Retry } $$ --- ## 11. 故障分類是自我維護的必要條件 Agent 可以建立故障集合： $$ F= \{ F_{resource}, F_{tool}, F_{state}, F_{memory}, F_{network}, F_{policy}, F_{semantic}, F_{security} \} $$ 不同故障需要不同處理。 例如： ### Resource Failure $$ DiskFull \rightarrow Cleanup/Archive $$ ### Tool Failure $$ APIChanged \rightarrow UpdateAdapter $$ ### State Failure $$ ConfigBroken \rightarrow Rollback $$ ### Memory Failure $$ IndexCorrupted \rightarrow RebuildFromSource $$ ### Semantic Failure $$ WrongAssumption \rightarrow Re-evaluate $$ 所以「重新啟動」不應該成為萬用解法。 --- ## 12. 修復之後必須 Verify 很多系統最危險的狀態不是明確 crash，而是： $$ \boxed{ WrongButPlausible } $$ 例如 Agent 認為： > 備份成功。 但實際上備份檔已損壞。 或者： > 資料庫恢復成功。 但缺少最新一天資料。 所以維護閉環必須是： $$ Repair \rightarrow Verification $$ 而不是： $$ Repair \rightarrow AssumeSuccess $$ 可用： - checksum； - smoke test； - boot test； - invariant check； - sample query； - independent verifier； - cloud second opinion。 --- ## 13. Recovery Budget：不能為了修一件小事把整台機器拆了 設一次修復方案： $$ r_i $$ 其風險與成本： $$ B(r_i) $$ Agent 必須遵守： $$ B(r_i)\le B_{max}(incident) $$ 例如： > 一個低價值 cache 壞了。 不應該： > 重灌整台系統。 而是： $$ DeleteCache \rightarrow Rebuild $$ 這可以稱為： $$ \boxed{ Bounded Recovery } $$ 即修復行為本身也受 blast radius 約束。 --- ## 14. Maintenance Debt：沒有出錯不代表沒有累積問題 類似 technical debt，長期 Agent 也會形成： $$ MD_t=\text{Maintenance Debt} $$ 來源包括： - stale dependencies； - 未驗證 backup； - 重複 scheduler； - 越來越大的 log； - 不再使用的模型； - 沒有 owner 的 script； - deprecated policy； - 懸空 symlink； - 長期未測試 recovery path。 短期： $$ SystemWorks=1 $$ 不代表： $$ MD_t=0 $$ 所以自我維護必須包含 preventive maintenance，而不只是 incident response。 --- ## 15. 預防性維護、反應性維護與預測性維護 CSM 可以拆成： ### 15.1 Reactive $$ Failure\rightarrow Repair $$ ### 15.2 Preventive $$ Schedule\rightarrow Inspection/Maintenance $$ 例如每月驗證 recovery image。 ### 15.3 Predictive $$ Trend\rightarrow PredictedFailure\rightarrow EarlyAction $$ 例如： $$ DiskGrowthRate\uparrow $$ 推斷： > 兩週後可能滿。 因此提前 archive。 真正成熟的長期 Agent 應逐漸從： $$ Reactive $$ 轉向： $$ Preventive+Predictive $$ --- ## 16. 自我維護不能變成自我修改無限權限 這裡需要嚴格區分： $$ SelfMaintenance $$ 和： $$ UnboundedSelfModification $$ 例如 Agent 可以： - 修自己的索引； - 重啟自己的工具； - 調整 scheduler； - 清除 cache； - 重建某個 workspace。 但不代表它應當可以無條件： - 刪除所有 recovery slots； - 改寫 external governance credentials； - 關閉所有 audit； - 毀掉最後備份； - 解除自己的全部 resource limits。 因此： $$ \boxed{ SelfMaintenance \subset AuthorizedSelfChange } $$ 這會在第 09–13 篇進一步展開。 --- ## 17. Escalation Intelligence：知道什麼時候不要自己修 一個真正重要的能力是： $$ \boxed{ \text{Escalation Intelligence} } $$ 即 Agent 能判斷： > 這件事應該自己處理，還是停止並向更高層求援？ 本文先定義風險函數： $$ \rho(a)= f( U, I, X, C, R ) $$ 其中： $$ U=\text{Uncertainty} $$ $$ I=\text{Irreversibility} $$ $$ X=\text{Externality} $$ $$ C=\text{Criticality} $$ $$ R=\text{Recovery Confidence}^{-1} $$ 然後： $$ E(s)= \begin{cases} SelfRepair,&\rho<\theta_1\\ Rollback,&\theta_1\le\rho<\theta_2\\ CrossZone/CloudAssist,&\theta_2\le\rho<\theta_3\\ HumanAssist,&\rho\ge\theta_3 \end{cases} $$ 真正成熟的 Agent 並不是： > 我永遠不用問人。 而是： > **我知道什麼時候不該繼續猜。** --- ## 18. 2026 年 Agent 研究已開始把 escalation 當成智能的一部分 近期「Managed Autonomy」研究提出一個非常接近的觀點：Agent 的智能不應只表現為持續行動，也包括偵測 epistemic drift、暫停、嘗試恢復，並在可靠度下降時移交控制。 這和本文的 CSM 高度一致。 因為： $$ ContinueAtAllCosts $$ 不是自主。 它可能只是： $$ UnboundedPersistence $$ 真正的自我治理應包含： $$ Stop $$ 和： $$ AskForHelp $$ --- ## 19. 雲端教師／治理 AI 是 CSM 的外部認知資源 本地 Agent 可能具有： $$ Compute_{local} 我懷疑自己的記憶資料庫被部分破壞，但無法判斷哪個 snapshot 最安全。 雲端模型可以： - 分析 log； - 比較 snapshot； - 做第二意見； - 提供 recovery plan。 這種求援不是自主性的失敗，而是 metacognitive competence： $$ \boxed{ KnowingWhenToDelegate } $$ --- ## 20. Self-Maintenance 與多 Agent 的關係 未來一台機器不一定只有一個 Agent。 可以有： $$ A_{primary} $$ $$ A_{maintenance} $$ $$ A_{audit} $$ 甚至： $$ A_{recovery} $$ 其中 primary Agent 主要工作，maintenance Agent 定期看健康狀態。 但本文不要求它們一定是不同模型。 它們也可以只是： $$ Role-separated \quad Runtime $$ 重點是： $$ \boxed{ Maintenance ot=SameContextAsEverydayWork } $$ 因為如果日常工作 context 本身已污染，獨立維護視角可能更可靠。 --- ## 21. Chaos / Fault Injection 可以成為 Agent 的維護課程 如果永遠等真實事故才學： $$ Data_{failure} $$ 可能太少。 可以建立受控故障： - 暫停網路； - 模擬 API timeout； - 模擬 disk pressure； - 關閉非核心服務； - 讓測試 DB corruption； - 模擬 cloud unavailable。 然後觀察： $$ Detect \rightarrow Diagnose \rightarrow Recover \rightarrow Verify $$ 這其實就是把 chaos engineering 轉為 developmental curriculum。 但前提是： $$ BlastRadius\le\theta $$ 因此仍然是可恢復學習，而不是破壞性試驗。 --- ## 22. 自我維護資料可以進入 HACT / DAL 每次故障可以產生： $$ \tau_m= ( StateBefore, Signal, Diagnosis, Plan, Action, Outcome, Verification, Escalation, StateAfter ) $$ 多次累積後： $$ \{\tau_m^1,\tau_m^2,\ldots,\tau_m^n\} $$ 可以生成： - failure classifier； - recovery policy； - risk model； - escalation policy； - maintenance checklist； - recovery skill。 因此故障本身成為： $$ \boxed{ Maintenance Training Data } $$ 這直接接回第 03 篇的 HACT 與第 06 篇 DAL。 --- ## 23. CSM 的評估指標 本文提出初步指標： ### 23.1 Mean Time to Detect $$ MTTD $$ ### 23.2 Mean Time to Recover $$ MTTR $$ ### 23.3 Recovery Success Rate $$ RSR $$ ### 23.4 Silent Failure Rate $$ SFR $$ ### 23.5 Human Escalation Precision $$ HEP = P(\text{human really needed}\mid\text{escalated}) $$ ### 23.6 Unsafe Self-Repair Rate $$ USR $$ ### 23.7 Maintenance Cost $$ MC $$ ### 23.8 Maintenance Debt $$ MD_t $$ 成熟系統的目標不是： $$ HumanEscalation=0 $$ 而是： $$ FalseEscalation\downarrow $$ 同時： $$ MissedCriticalEscalation\downarrow $$ --- ## 24. 一個 120 天持續 Agent 自我維護實驗 建立兩個相同模型： $$ \theta_A=\theta_B $$ ### A：Task Agent 有 persistent computer，但沒有正式 CSM policy。 ### B：Self-Maintaining Agent 具備： - health model； - resource budget； - scheduled maintenance； - bounded retry； - recovery verification； - escalation policy； - maintenance memory。 運行： $$ T=120\ days $$ 注入： - tool timeout； - stale index； - disk pressure； - scheduler duplication； - API change； - recoverable configuration corruption。 比較： $$ MTTD, MTTR, SFR, HumanIntervention, Cost, MaintenanceDebt $$ 若 B 組隨時間出現： $$ MTTR_t\downarrow $$ $$ RepeatedFailure_t\downarrow $$ $$ HumanIntervention_t\downarrow $$ 但： $$ UnsafeRepair_t\not\uparrow $$ 則可視為發展式 self-maintenance 的實證訊號。 --- ## 25. 自我維護不是自我封閉 本文最重要的價值判斷之一是： $$ \boxed{ SelfMaintenance \neq Isolation } $$ 真正可靠的 Agent 應該能使用： - 本地恢復； - 另一故障域； - 雲端大型模型； - 多雲備份； - 人類 USB 救援。 所以 CSM 的成熟不是： > 我全部自己來。 而是： $$ \boxed{ \text{Use the lowest-cost reliable recovery layer that is sufficient.} } $$ 這會直接銜接後續第 11–14 篇。 --- ## 26. 從自我維護走向外部性治理 到這裡，Agent 已經開始可以： - 管自己的資源； - 管自己的 scheduler； - 修自己的工具； - 重建自己的記憶索引； - 自己 rollback； - 呼叫雲端； - 請求人類。 接下來自然會出現一個新的問題： > 如果 Agent 在本地可以如此自由，那到底還需要監控它什麼？ 本文答案是： $$ InternalSelfMaintenance $$ 和： $$ ExternalEffect $$ 應該分開。 因此下一篇正式進入： # 第 09 篇 ## 〈外部性有界智能體自治：治理外在影響，而非全面監視內部計算〉 將研究： $$ \boxed{ Control\ the\ Boundary, not\ every\ Internal\ Action } $$ --- ## 27. 結論 本文將發展式 Agent 的自我維護形式化為： $$ \boxed{ CSM = \text{Health Monitoring} + \text{Resource Governance} + \text{Maintenance} + \text{Recovery} + \text{Verification} + \text{Escalation} } $$ 核心不是讓 Agent 永遠不出錯，而是： $$ \boxed{ Failure \rightarrow Detection \rightarrow BoundedRepair \rightarrow Verification \rightarrow Learning/Escalation } $$ 因此整條系列主鏈現在可以寫成： $$ \text{Organization} \rightarrow \text{Optimization} \rightarrow \text{Self-Maintenance} \rightarrow \text{Self-Governance} $$ 真正值得研究的 Agent，不只是「能幫人完成很多工作」，而是： > **它能不能逐漸學會維持自己所依賴的計算環境，使自己明天仍然能工作；並且在超出能力或風險邊界時，知道應該停止、回滾、求援。** 這使「知道何時求助」不再是自主性的反面，而成為自主性的組成部分。 --- ## 參考資料 [1] White, S. R., Hanson, J. E., Whalley, I., Chess, D. M., Kephart, J. O. **An Architectural Approach to Autonomic Computing.** ICAC, 2004. https://research.ibm.com/publications/an-architectural-approach-to-autonomic-computing [2] IBM. **The autonomic computing self-healing technologies of IBM Z System Automation.** https://www.ibm.com/docs/en/bcfsoz?topic=haas-autonomic-computing-self-healing-technologies-z-system-automation [3] Kubernetes. **Self-Healing.** Last modified 2025-11-20. https://kubernetes.io/docs/concepts/architecture/self-healing/ [4] Linux Kernel Documentation. **Control Group v2.** https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html [5] Jeong, C., Shin, Y. **A Self-Healing Framework for Reliable LLM-Based Autonomous Agents.** arXiv:2605.06737, 2026. https://arxiv.org/abs/2605.06737 [6] Babu, R. S., Agrawal, A. **Self-Healing Agentic Orchestrators for Reliable Tool-Augmented Large Language Model Systems.** arXiv:2606.01416, 2026. https://arxiv.org/abs/2606.01416 [7] Ramaswamy, S. **Intelligence as Managed Autonomy: Failure, Escalation, and Governance for Agentic AI Systems.** arXiv:2605.27628, 2026. https://arxiv.org/abs/2605.27628 --- ## 系列依賴 **上游：** - 05〈計算機作為持續智能環境〉 - 06〈發展式智能體學習〉 - 07〈整理即優化〉 **下游：** - 09〈外部性有界智能體自治〉 - 11〈本地自由、雲端治理與教師智能〉 - 12〈多雲治理與智能體持續性〉 - 13〈多作業基底、分區故障域與智能體恢復階梯〉 - 14〈人類最後一公里〉