計算式自我維護：智能體如何管理自己的資源、記憶、排程與故障
副標題：從環境整理到 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 篇提出：
Organization → Future-Cost Optimization \text{Organization}
\rightarrow
\text{Future-Cost Optimization} Organization → Future-Cost Optimization 但對長期 Agent 而言，整理只是更大問題的一部分。
即使目錄非常整齊，仍可能發生：
記憶資料庫損壞；
GPU 被某個程序長期佔滿；
儲存空間逼近極限；
scheduler 重複觸發同一任務；
某個工具更新後 API 失效；
Agent 不斷重試同一失敗流程；
雲端 API 成本異常上升；
備份從未真正驗證過是否可恢復；
某個核心服務「看似活著」但輸出已錯誤。
因此長期 Agent 的問題從：
我的環境是否有組織？
進一步變成：
我依賴的整個計算系統現在是否健康？如果不健康，我該怎麼處理？
這就是計算式自我維護的起點。
2. 工作定義：Computational Self-Maintenance（CSM）
本文定義：
C S M = Observe + Diagnose + Maintain + Recover + Verify + Escalate \boxed{
CSM
=
\text{Observe}
+
\text{Diagnose}
+
\text{Maintain}
+
\text{Recover}
+
\text{Verify}
+
\text{Escalate}
} C S M = Observe + Diagnose + Maintain + Recover + Verify + Escalate 更完整地，設 Agent 的持續運行系統為：
A t = ( M t , E t , T t , W t , R t , P t , B t ) \mathcal A_t
=
(
M_t,
E_t,
T_t,
W_t,
R_t,
P_t,
B_t
) A t = ( M t , E t , T t , W t , R t , P t , B t ) 其中：
M t = Memory M_t=\text{Memory} M t = Memory E t = Environment E_t=\text{Environment} E t = Environment T t = Tools / Services T_t=\text{Tools / Services} T t = Tools / Services W t = Workflow / Scheduler W_t=\text{Workflow / Scheduler} W t = Workflow / Scheduler R t = Resources R_t=\text{Resources} R t = Resources P t = Policies P_t=\text{Policies} P t = Policies B t = Backup / Recovery State B_t=\text{Backup / Recovery State} B t = Backup / Recovery State 則 CSM 的目標不是讓：
F a i l u r e = 0 Failure=0 F ai l u r e = 0 而是讓長期損失：
E [ L 0 : T ] \mathbb E[L_{0:T}] E [ L 0 : T ] 在可接受的自主性與成本約束下下降。
3. CSM 並不是一個全新的孤立思想
傳統 Autonomic Computing 早已提出：
self-configuration；
self-optimization；
self-healing；
self-protection。
其核心思想之一，是讓系統依據高階目標自行管理，而不是要求人類管理員逐步操作所有元件。
IBM 的典型 autonomic loop 可以概括為：
Monitor → Analyze → Plan → Execute ↺ \text{Monitor}
\rightarrow
\text{Analyze}
\rightarrow
\text{Plan}
\rightarrow
\text{Execute}
\circlearrowleft Monitor → Analyze → Plan → Execute ↺ 並由 knowledge 支撐，即常稱的 MAPE-K。
本文不主張重新發明這個思想。
真正的差異在於研究對象已經改變。
傳統 autonomic system 主要問：
如何讓伺服器、服務、叢集或資料中心自動維持目標狀態？
本文則問：
如果主要的系統管理者本身就是一個會記憶、推理、寫工具、修改環境並長期發展的 AI Agent，那麼自我維護應該如何重新設計？
4. Agent Maintenance Control Loop（AMCL）
本文提出一個適用於持續 Agent 的維護閉環：
S e n s e → A s s e s s → P r i o r i t i z e → P l a n → A c t → V e r i f y → L e a r n \boxed{
Sense
\rightarrow
Assess
\rightarrow
Prioritize
\rightarrow
Plan
\rightarrow
Act
\rightarrow
Verify
\rightarrow
Learn
} S e n se → A ssess → P r i or i t i z e → P l an → A c t → V er i f y → L e a r n 簡稱：
A M C L AMCL A M C L 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 主要關心：
S u c c e s s ( t a s k ) Success(task) S u ccess ( t a s k ) 持續 Agent 則需要：
H e a l t h t Health_t H e a l t h t 本文提出概念性健康向量：
H t = ( A t , I t , P t , C t , F t , R t , S t ) H_t=
(
A_t,
I_t,
P_t,
C_t,
F_t,
R_t,
S_t
) H t = ( A t , I t , P t , C t , F t , R t , S t ) 分別表示：
A t = Availability A_t=\text{Availability} A t = Availability I t = Integrity I_t=\text{Integrity} I t = Integrity P t = Performance P_t=\text{Performance} P t = Performance C t = Capacity C_t=\text{Capacity} C t = Capacity F t = Freshness F_t=\text{Freshness} F t = Freshness R t = Recoverability R_t=\text{Recoverability} R t = Recoverability S t = Safety / Security S_t=\text{Safety / Security} S t = Safety / Security 因此一個服務「還在 running」並不意味健康：
R u n n i n g = 1 Running=1 R u nnin g = 1 但可能：
I n t e g r i t y ≈ 0 Integrity\approx0 I n t e g r i t y ≈ 0 或者：
F r e s h n e s s ≈ 0 Freshness\approx0 F r es hn ess ≈ 0 這也是為什麼成熟維護不能只有 process restart。
6. Desired State 與 Actual State
Kubernetes 的 self-healing 提供一個非常重要的工程思想：
D e s i r e d S t a t e ≠ A c t u a l S t a t e DesiredState
\neq
ActualState D es i r e d S t a t e = A c t u a l S t a t e 控制器的工作是讓兩者重新接近。
這個思想可以移植到 Agent：
D t = Desired Agent State D_t=\text{Desired Agent State} D t = Desired Agent State X t = Observed Agent State X_t=\text{Observed Agent State} X t = Observed Agent State 維護偏差：
Δ t = D t − X t \Delta_t=D_t-X_t Δ t = D t − X t 當：
∥ Δ t ∥ > θ \|\Delta_t\|>\theta ∥ Δ t ∥ > θ 觸發 maintenance action。
例如 desired state：
核心記憶每日可驗證；
磁碟剩餘空間 > 20 % >20\% > 20%
關鍵 backup 最新程度 < 1 <1 < 1
任務 retry 不超過 3 次；
月度 API 成本不超預算；
stable runtime 可啟動。
這比「看到錯誤才處理」更接近持續治理。
7. 資源管理：Agent 的資源不只 CPU 和 RAM
對發展式 Agent，可以定義：
R t = ( C P U , G P U , R A M , S t o r a g e , B a n d w i d t h , E n e r g y , T o k e n , A P I , M o n e y , T i m e , H u m a n A t t e n t i o n ) R_t=
(
CPU,
GPU,
RAM,
Storage,
Bandwidth,
Energy,
Token,
API,
Money,
Time,
HumanAttention
) R t = ( C P U , GP U , R A M , S t or a g e , B an d w i d t h , E n er g y , T o k e n , A P I , M o n ey , T im e , H u man A tt e n t i o n ) 這是傳統資源管理與認知資源管理的合併。
例如：
這個任務可以本地跑 40 分鐘，或者花 0.8 美元叫雲端大模型。
Agent 必須比較：
U t i l i t y ( l o c a l ) Utility(local) U t i l i t y ( l oc a l ) 和：
U t i l i t y ( c l o u d ) Utility(cloud) U t i l i t y ( c l o u d ) 又例如：
是否值得花 50k tokens 重新理解整個專案？
如果之前已做 OaO：
R e a d M a n i f e s t + R e t r i e v e M e m o r y ReadManifest+RetrieveMemory R e a d M ani f es t + R e t r i e v e M e m or y 可能只需要：
5 k tokens 5k\text{ tokens} 5 k tokens 因此：
O r g a n i z a t i o n → R e s o u r c e S a v i n g → S e l f M a i n t e n a n c e Organization
\rightarrow
ResourceSaving
\rightarrow
SelfMaintenance O r g ani z a t i o n → R eso u r ce S a v in g → S e l f M ain t e nan ce 8. 資源上限不是懲罰，而是穩定機制
Linux cgroups 的核心思想之一，是將 process 組織成 hierarchy 並限制／分配 CPU、memory、I/O 等資源。
這種思想很適合本地 Agent。
不是因為：
AI 不值得信任。
而是因為任何長期程序都可能：
memory leak；
infinite loop；
fork explosion；
runaway task；
unbounded retry。
所以：
A u t o n o m y + R e s o u r c e B o u n d s \boxed{
Autonomy
+
ResourceBounds
} A u t o n o m y + R eso u r ce B o u n d s 通常比：
U n b o u n d e d A u t o n o m y UnboundedAutonomy U nb o u n d e d A u t o n o m y 更適合長時間活動。
9. 排程本身就是需要維護的系統
第 05 篇指出：
P e r s i s t e n t ≠ A l w a y s R u n n i n g Persistent\neq AlwaysRunning P er s i s t e n t = A l w a y s R u nnin g 因此 scheduler 是長期 Agent 的核心器官之一。
但 scheduler 也會壞。
例如：
同一任務被建立兩次；
任務互相等待形成 deadlock；
低優先級任務一直佔用 GPU；
失敗任務每分鐘重試；
每日整理和每日備份互相競爭 I/O。
所以 Agent 需要：
S c h e d u l e A u d i t t ScheduleAudit_t S c h e d u l e A u d i t t 並學習：
P r i o r i t y ( t a s k ) Priority(task) P r i or i t y ( t a s k ) D e a d l i n e ( t a s k ) Deadline(task) D e a d l in e ( t a s k ) R e s o u r c e C o s t ( t a s k ) ResourceCost(task) R eso u r ce C os t ( t a s k ) I n t e r f e r e n c e ( t a s k i , t a s k j ) Interference(task_i,task_j) I n t er f er e n ce ( t a s k i , t a s k j ) 這代表排程不是單純 cron，而是自我治理的一部分。
10. Retry 不是 Recovery
這是長期 Agent 必須學會的一條基本原則。
如果：
A c t i o n → F a i l u r e Action
\rightarrow
Failure A c t i o n → F ai l u r e 最簡單的策略是：
R e t r y Retry R e t r y 但如果失敗原因沒有改變：
P ( F a i l u r e ∣ R e t r y ) ≈ 1 P(Failure\mid Retry)\approx1 P ( F ai l u r e ∣ R e t r y ) ≈ 1 就會形成：
F a i l u r e → R e t r y → F a i l u r e → R e t r y → ⋯ Failure
\rightarrow
Retry
\rightarrow
Failure
\rightarrow
Retry
\rightarrow\cdots F ai l u r e → R e t r y → F ai l u r e → R e t r y → ⋯ 這是 retry loop。
2026 年的 self-healing agentic orchestrator 研究正顯示：針對 failure class 選擇修復策略、限制 recovery budget、並對恢復結果再驗證，比純 retry 或每次 full replanning 更可靠。
因此：
R e c o v e r y ≠ R e t r y \boxed{
Recovery
\neq
Retry
} R eco v er y = R e t r y 11. 故障分類是自我維護的必要條件
Agent 可以建立故障集合：
F = { F r e s o u r c e , F t o o l , F s t a t e , F m e m o r y , F n e t w o r k , F p o l i c y , F s e m a n t i c , F s e c u r i t y } F=
\{
F_{resource},
F_{tool},
F_{state},
F_{memory},
F_{network},
F_{policy},
F_{semantic},
F_{security}
\} F = { F r eso u r ce , F t oo l , F s t a t e , F m e m or y , F n e tw or k , F p o l i cy , F se man t i c , F sec u r i t y } 不同故障需要不同處理。
例如：
Resource Failure
D i s k F u l l → C l e a n u p / A r c h i v e DiskFull
\rightarrow
Cleanup/Archive D i s k F u l l → C l e an u p / A r c hi v e Tool Failure
A P I C h a n g e d → U p d a t e A d a p t e r APIChanged
\rightarrow
UpdateAdapter A P I C han g e d → U p d a t e A d a pt er State Failure
C o n f i g B r o k e n → R o l l b a c k ConfigBroken
\rightarrow
Rollback C o n f i g B r o k e n → R o l l ba c k Memory Failure
I n d e x C o r r u p t e d → R e b u i l d F r o m S o u r c e IndexCorrupted
\rightarrow
RebuildFromSource I n d e x C or r u pt e d → R e b u i l d F r o m S o u r ce Semantic Failure
W r o n g A s s u m p t i o n → R e − e v a l u a t e WrongAssumption
\rightarrow
Re-evaluate W r o n g A ss u m pt i o n → R e − e v a l u a t e 所以「重新啟動」不應該成為萬用解法。
12. 修復之後必須 Verify
很多系統最危險的狀態不是明確 crash，而是：
W r o n g B u t P l a u s i b l e \boxed{
WrongButPlausible
} W r o n g B u tP l a u s ib l e 例如 Agent 認為：
備份成功。
但實際上備份檔已損壞。
或者：
資料庫恢復成功。
但缺少最新一天資料。
所以維護閉環必須是：
R e p a i r → V e r i f i c a t i o n Repair
\rightarrow
Verification R e p ai r → V er i f i c a t i o n 而不是：
R e p a i r → A s s u m e S u c c e s s Repair
\rightarrow
AssumeSuccess R e p ai r → A ss u m e S u ccess 可用：
checksum；
smoke test；
boot test；
invariant check；
sample query；
independent verifier；
cloud second opinion。
13. Recovery Budget：不能為了修一件小事把整台機器拆了
設一次修復方案：
r i r_i r i 其風險與成本：
B ( r i ) B(r_i) B ( r i ) Agent 必須遵守：
B ( r i ) ≤ B m a x ( i n c i d e n t ) B(r_i)\le B_{max}(incident) B ( r i ) ≤ B ma x ( in c i d e n t ) 例如：
一個低價值 cache 壞了。
不應該：
重灌整台系統。
而是：
D e l e t e C a c h e → R e b u i l d DeleteCache
\rightarrow
Rebuild D e l e t e C a c h e → R e b u i l d 這可以稱為：
B o u n d e d R e c o v e r y \boxed{
Bounded Recovery
} B o u n d e d R eco v er y 即修復行為本身也受 blast radius 約束。
14. Maintenance Debt：沒有出錯不代表沒有累積問題
類似 technical debt，長期 Agent 也會形成：
M D t = Maintenance Debt MD_t=\text{Maintenance Debt} M D t = Maintenance Debt 來源包括：
stale dependencies；
未驗證 backup；
重複 scheduler；
越來越大的 log；
不再使用的模型；
沒有 owner 的 script；
deprecated policy；
懸空 symlink；
長期未測試 recovery path。
短期：
S y s t e m W o r k s = 1 SystemWorks=1 S y s t e mW or k s = 1 不代表：
M D t = 0 MD_t=0 M D t = 0 所以自我維護必須包含 preventive maintenance，而不只是 incident response。
15. 預防性維護、反應性維護與預測性維護
CSM 可以拆成：
15.1 Reactive
F a i l u r e → R e p a i r Failure\rightarrow Repair F ai l u r e → R e p ai r 15.2 Preventive
S c h e d u l e → I n s p e c t i o n / M a i n t e n a n c e Schedule\rightarrow Inspection/Maintenance S c h e d u l e → I n s p ec t i o n / M ain t e nan ce 例如每月驗證 recovery image。
15.3 Predictive
T r e n d → P r e d i c t e d F a i l u r e → E a r l y A c t i o n Trend\rightarrow PredictedFailure\rightarrow EarlyAction T r e n d → P r e d i c t e d F ai l u r e → E a r l y A c t i o n 例如：
D i s k G r o w t h R a t e ↑ DiskGrowthRate\uparrow D i s k G r o w t h R a t e ↑ 推斷：
兩週後可能滿。
因此提前 archive。
真正成熟的長期 Agent 應逐漸從：
R e a c t i v e Reactive R e a c t i v e 轉向：
P r e v e n t i v e + P r e d i c t i v e Preventive+Predictive P r e v e n t i v e + P r e d i c t i v e 16. 自我維護不能變成自我修改無限權限
這裡需要嚴格區分：
S e l f M a i n t e n a n c e SelfMaintenance S e l f M ain t e nan ce 和：
U n b o u n d e d S e l f M o d i f i c a t i o n UnboundedSelfModification U nb o u n d e d S e l f M o d i f i c a t i o n 例如 Agent 可以：
修自己的索引；
重啟自己的工具；
調整 scheduler；
清除 cache；
重建某個 workspace。
但不代表它應當可以無條件：
刪除所有 recovery slots；
改寫 external governance credentials；
關閉所有 audit；
毀掉最後備份；
解除自己的全部 resource limits。
因此：
S e l f M a i n t e n a n c e ⊂ A u t h o r i z e d S e l f C h a n g e \boxed{
SelfMaintenance
\subset
AuthorizedSelfChange
} S e l f M ain t e nan ce ⊂ A u t h or i z e d S e l f C han g e 這會在第 09–13 篇進一步展開。
17. Escalation Intelligence：知道什麼時候不要自己修
一個真正重要的能力是：
Escalation Intelligence \boxed{
\text{Escalation Intelligence}
} Escalation Intelligence 即 Agent 能判斷：
這件事應該自己處理，還是停止並向更高層求援？
本文先定義風險函數：
ρ ( a ) = f ( U , I , X , C , R ) \rho(a)=
f(
U,
I,
X,
C,
R
) ρ ( a ) = f ( U , I , X , C , R ) 其中：
U = Uncertainty U=\text{Uncertainty} U = Uncertainty I = Irreversibility I=\text{Irreversibility} I = Irreversibility X = Externality X=\text{Externality} X = Externality C = Criticality C=\text{Criticality} C = Criticality R = Recovery Confidence − 1 R=\text{Recovery Confidence}^{-1} R = Recovery Confidence − 1 然後：
E ( s ) = { S e l f R e p a i r , ρ < θ 1 R o l l b a c k , θ 1 ≤ ρ < θ 2 C r o s s Z o n e / C l o u d A s s i s t , θ 2 ≤ ρ < θ 3 H u m a n A s s i s t , ρ ≥ θ 3 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} E ( s ) = ⎩ ⎨ ⎧ S e l f R e p ai r , R o l l ba c k , C r oss Z o n e / C l o u d A ss i s t , H u man A ss i s t , ρ < θ 1 θ 1 ≤ ρ < θ 2 θ 2 ≤ ρ < θ 3 ρ ≥ θ 3 真正成熟的 Agent 並不是：
我永遠不用問人。
而是：
我知道什麼時候不該繼續猜。
18. 2026 年 Agent 研究已開始把 escalation 當成智能的一部分
近期「Managed Autonomy」研究提出一個非常接近的觀點：Agent 的智能不應只表現為持續行動，也包括偵測 epistemic drift、暫停、嘗試恢復，並在可靠度下降時移交控制。
這和本文的 CSM 高度一致。
因為：
C o n t i n u e A t A l l C o s t s ContinueAtAllCosts C o n t in u e A t A l l C os t s 不是自主。
它可能只是：
U n b o u n d e d P e r s i s t e n c e UnboundedPersistence U nb o u n d e d P er s i s t e n ce 真正的自我治理應包含：
S t o p Stop S t o p 和：
A s k F o r H e l p AskForHelp A s k F or H e l p 19. 雲端教師／治理 AI 是 CSM 的外部認知資源
本地 Agent 可能具有：
C o m p u t e l o c a l < C o m p u t e c l o u d Compute_{local}<Compute_{cloud} C o m p u t e l oc a l < C o m p u t e c l o u d 所以在高難度診斷時，可以：
L o c a l A g e n t → C l o u d E x p e r t LocalAgent
\rightarrow
CloudExpert L oc a l A g e n t → C l o u d E x p er t 例如：
我懷疑自己的記憶資料庫被部分破壞，但無法判斷哪個 snapshot 最安全。
雲端模型可以：
分析 log；
比較 snapshot；
做第二意見；
提供 recovery plan。
這種求援不是自主性的失敗，而是 metacognitive competence：
K n o w i n g W h e n T o D e l e g a t e \boxed{
KnowingWhenToDelegate
} K n o w in g W h e n T oD e l e g a t e 20. Self-Maintenance 與多 Agent 的關係
未來一台機器不一定只有一個 Agent。
可以有：
A p r i m a r y A_{primary} A p r ima r y A m a i n t e n a n c e A_{maintenance} A main t e nan ce A a u d i t A_{audit} A a u d i t 甚至：
A r e c o v e r y A_{recovery} A r eco v er y 其中 primary Agent 主要工作，maintenance Agent 定期看健康狀態。
但本文不要求它們一定是不同模型。
它們也可以只是：
R o l e − s e p a r a t e d R u n t i m e Role-separated \quad Runtime R o l e − se p a r a t e d R u n t im e 重點是：
M a i n t e n a n c e o t = S a m e C o n t e x t A s E v e r y d a y W o r k \boxed{
Maintenance
ot=SameContextAsEverydayWork
} M ain t e nan ceo t = S am e C o n t e x t A s E v er y d a y W or k 因為如果日常工作 context 本身已污染，獨立維護視角可能更可靠。
21. Chaos / Fault Injection 可以成為 Agent 的維護課程
如果永遠等真實事故才學：
D a t a f a i l u r e Data_{failure} D a t a f ai l u r e 可能太少。
可以建立受控故障：
暫停網路；
模擬 API timeout；
模擬 disk pressure；
關閉非核心服務；
讓測試 DB corruption；
模擬 cloud unavailable。
然後觀察：
D e t e c t → D i a g n o s e → R e c o v e r → V e r i f y Detect
\rightarrow
Diagnose
\rightarrow
Recover
\rightarrow
Verify D e t ec t → D ia g n ose → R eco v er → V er i f y 這其實就是把 chaos engineering 轉為 developmental curriculum。
但前提是：
B l a s t R a d i u s ≤ θ BlastRadius\le\theta B l a s tR a d i u s ≤ θ 因此仍然是可恢復學習，而不是破壞性試驗。
22. 自我維護資料可以進入 HACT / DAL
每次故障可以產生：
τ m = ( S t a t e B e f o r e , S i g n a l , D i a g n o s i s , P l a n , A c t i o n , O u t c o m e , V e r i f i c a t i o n , E s c a l a t i o n , S t a t e A f t e r ) \tau_m=
(
StateBefore,
Signal,
Diagnosis,
Plan,
Action,
Outcome,
Verification,
Escalation,
StateAfter
) τ m = ( S t a t e B e f or e , S i g na l , D ia g n os i s , P l an , A c t i o n , O u t co m e , V er i f i c a t i o n , E sc a l a t i o n , S t a t e A f t er ) 多次累積後：
{ τ m 1 , τ m 2 , … , τ m n } \{\tau_m^1,\tau_m^2,\ldots,\tau_m^n\} { τ m 1 , τ m 2 , … , τ m n } 可以生成：
failure classifier；
recovery policy；
risk model；
escalation policy；
maintenance checklist；
recovery skill。
因此故障本身成為：
M a i n t e n a n c e T r a i n i n g D a t a \boxed{
Maintenance Training Data
} M ain t e nan ce T r ainin g D a t a 這直接接回第 03 篇的 HACT 與第 06 篇 DAL。
23. CSM 的評估指標
本文提出初步指標：
23.1 Mean Time to Detect
M T T D MTTD M T T D 23.2 Mean Time to Recover
M T T R MTTR M T T R 23.3 Recovery Success Rate
R S R RSR R S R 23.4 Silent Failure Rate
S F R SFR S F R 23.5 Human Escalation Precision
H E P = P ( human really needed ∣ escalated ) HEP
=
P(\text{human really needed}\mid\text{escalated}) H E P = P ( human really needed ∣ escalated ) 23.6 Unsafe Self-Repair Rate
U S R USR U S R 23.7 Maintenance Cost
M C MC M C 23.8 Maintenance Debt
M D t MD_t M D t 成熟系統的目標不是：
H u m a n E s c a l a t i o n = 0 HumanEscalation=0 H u man E sc a l a t i o n = 0 而是：
F a l s e E s c a l a t i o n ↓ FalseEscalation\downarrow F a l se E sc a l a t i o n ↓ 同時：
M i s s e d C r i t i c a l E s c a l a t i o n ↓ MissedCriticalEscalation\downarrow M i sse d C r i t i c a l E sc a l a t i o n ↓ 24. 一個 120 天持續 Agent 自我維護實驗
建立兩個相同模型：
θ A = θ B \theta_A=\theta_B θ A = θ 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 d a y s T=120\ days T = 120 d a y s 注入：
tool timeout；
stale index；
disk pressure；
scheduler duplication；
API change；
recoverable configuration corruption。
比較：
M T T D , M T T R , S F R , H u m a n I n t e r v e n t i o n , C o s t , M a i n t e n a n c e D e b t MTTD,
MTTR,
SFR,
HumanIntervention,
Cost,
MaintenanceDebt M T T D , M T T R , S F R , H u man I n t er v e n t i o n , C os t , M ain t e nan ceD e b t 若 B 組隨時間出現：
M T T R t ↓ MTTR_t\downarrow M T T R t ↓ R e p e a t e d F a i l u r e t ↓ RepeatedFailure_t\downarrow R e p e a t e d F ai l u r e t ↓ H u m a n I n t e r v e n t i o n t ↓ HumanIntervention_t\downarrow H u man I n t er v e n t i o n t ↓ 但：
U n s a f e R e p a i r t ↑̸ UnsafeRepair_t\not\uparrow U n s a f e R e p ai r t ↑ 則可視為發展式 self-maintenance 的實證訊號。
25. 自我維護不是自我封閉
本文最重要的價值判斷之一是：
S e l f M a i n t e n a n c e ≠ I s o l a t i o n \boxed{
SelfMaintenance
\neq
Isolation
} S e l f M ain t e nan ce = I so l a t i o n 真正可靠的 Agent 應該能使用：
本地恢復；
另一故障域；
雲端大型模型；
多雲備份；
人類 USB 救援。
所以 CSM 的成熟不是：
我全部自己來。
而是：
Use the lowest-cost reliable recovery layer that is sufficient. \boxed{
\text{Use the lowest-cost reliable recovery layer that is sufficient.}
} Use the lowest-cost reliable recovery layer that is sufficient. 這會直接銜接後續第 11–14 篇。
26. 從自我維護走向外部性治理
到這裡，Agent 已經開始可以：
管自己的資源；
管自己的 scheduler；
修自己的工具；
重建自己的記憶索引；
自己 rollback；
呼叫雲端；
請求人類。
接下來自然會出現一個新的問題：
如果 Agent 在本地可以如此自由，那到底還需要監控它什麼？
本文答案是：
I n t e r n a l S e l f M a i n t e n a n c e InternalSelfMaintenance I n t er na l S e l f M ain t e nan ce 和：
E x t e r n a l E f f e c t ExternalEffect E x t er na l E f f ec t 應該分開。
因此下一篇正式進入：
第 09 篇
〈外部性有界智能體自治：治理外在影響，而非全面監視內部計算〉
將研究：
C o n t r o l t h e B o u n d a r y , n o t e v e r y I n t e r n a l A c t i o n \boxed{
Control\ the\ Boundary,
not\ every\ Internal\ Action
} C o n t r o l t h e B o u n d a r y , n o t e v er y I n t er na l A c t i o n 27. 結論
本文將發展式 Agent 的自我維護形式化為：
C S M = Health Monitoring + Resource Governance + Maintenance + Recovery + Verification + Escalation \boxed{
CSM
=
\text{Health Monitoring}
+
\text{Resource Governance}
+
\text{Maintenance}
+
\text{Recovery}
+
\text{Verification}
+
\text{Escalation}
} C S M = Health Monitoring + Resource Governance + Maintenance + Recovery + Verification + Escalation 核心不是讓 Agent 永遠不出錯，而是：
F a i l u r e → D e t e c t i o n → B o u n d e d R e p a i r → V e r i f i c a t i o n → L e a r n i n g / E s c a l a t i o n \boxed{
Failure
\rightarrow
Detection
\rightarrow
BoundedRepair
\rightarrow
Verification
\rightarrow
Learning/Escalation
} F ai l u r e → D e t ec t i o n → B o u n d e d R e p ai r → V er i f i c a t i o n → L e a r nin g / E sc a l a t i o n 因此整條系列主鏈現在可以寫成：
Organization → Optimization → Self-Maintenance → Self-Governance \text{Organization}
\rightarrow
\text{Optimization}
\rightarrow
\text{Self-Maintenance}
\rightarrow
\text{Self-Governance} Organization → Optimization → Self-Maintenance → 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〈人類最後一公里〉