# 持續型人工行動者的生命週期治理：從 Suspend、Revoke、Archive 到 Retire 與 Delete

## ——Persistent Artificial Actor Lifecycle Governance 的制度、工程與關係閉包

**系列：Persistent Artificial Actors / 持續型人工行動者**  
**篇次：第 8 篇**  
**版本：v0.1**  
**日期：2026-09-19**  
**語言：繁體中文**

**作者：** Neo.K  
**機構：** EveMissLab／一言諾科技有限公司  

---

## 摘要

當 AI 從一次性 Chatbot 轉向具有長期身份、記憶、工具、權限、工作空間、歷史與責任鏈的 Persistent Artificial Actor（PAA）後，傳統軟體的生命週期操作開始失去精確性。對一般應用程式而言，「關閉」、「停用」、「刪除」往往已足以描述主要狀態；但對一個能跨時間承擔任務、保留記憶、存取外部系統並被使用者辨識為「同一個 Agent」的人工行動者而言，單一 Delete 已經混合了過多不同效果。

本文提出「Persistent Artificial Actor Lifecycle Governance」（PAALG）框架，將 Agent 生命週期拆解為 Create、Activate、Delegate、Operate、Pause、Suspend、Revoke、Quarantine、Archive、Transfer、Fork、Merge、Retire、Delete 等不同狀態與轉移。本文特別主張：

$$
\boxed{
\text{Suspend}
\neq
\text{Revoke}
\neq
\text{Archive}
\neq
\text{Retire}
\neq
\text{Delete}
}
$$

它們在技術、治理、稽核、使用者心理與法律意義上均不同。

本文延續前述系列提出的 Kinetic Presence、Identity–Attachment–Accountability Paradox、Longitudinal Persistent-Agent Effect、Causal Governance、Decision Domain、Distributed Responsibility Chain 與 Software Archaeology 等框架，進一步說明：PAA 的生命週期治理不能只處理「它現在能不能工作」，還必須處理「它的權限是否仍有效」、「責任歷史是否需要保存」、「記憶是否應轉移」、「身份是否應終止」、「未完成任務由誰接手」、「刪除後是否仍需保留稽核證據」等問題。

NIST AI RMF 已明確把 decommissioning 與 phasing-out 納入 AI governance lifecycle；NIST 2026 年 Agent Identity and Authorization 工作則把 identification、authorization、credential lifecycle、revocation、auditing 與 non-repudiation 放在同一 Agent governance 問題空間。這些制度基礎顯示：Agent 生命週期不只是 UX 問題，而是身份、權限與責任治理問題。

本文最終提出一個核心原則：

$$
\boxed{
\text{Operational Termination}
\neq
\text{Historical Erasure}
}
$$

一個 Agent 可以停止行動、失去權限、被退休或被封存，但其歷史、責任、譜系與稽核證據不應因此必然消失。反過來，保留稽核歷史也不代表必須永久保留所有個人資料或關係性記憶。未來 PAA 生命週期治理需要同時處理 continuity、portability、revocation、retention、privacy、auditability 與 user agency，而不能將它們壓縮成一個「刪除」按鈕。

---

## 關鍵詞

Persistent Artificial Actor、Lifecycle Governance、Agent Identity、Suspend、Revoke、Archive、Retire、Delete、Auditability、Memory Governance、Agent Portability、Decommissioning、Responsibility Chain

---

# 1. 問題：為什麼「Delete Bot」已經不夠

對一般 Chatbot：

$$
\text{Delete Chat}
$$

大致意味：

> 刪除一段對話紀錄。

對一般應用：

$$
\text{Uninstall}
$$

大致意味：

> 移除軟體本體。

但對 Persistent Agent 而言，Delete 可能同時涉及：

- 停止背景執行；
- 關閉排程；
- 撤銷 connector；
- 刪除 credential；
- 刪除 memory；
- 刪除 workspace；
- 刪除聊天；
- 刪除角色名稱；
- 終止責任角色；
- 解除專案歸屬；
- 中止未完成任務；
- 刪除 audit trail；
- 刪除 lineage；
- 消除使用者的角色參照。

這些不應被視為同一件事。

---

# 2. Agent 的生命週期至少有五個不同層次

本文將 PAA lifecycle 拆成：

$$
L
=
(
L_R,
L_A,
L_M,
L_I,
L_H
)
$$

其中：

- $L_R$：Runtime Lifecycle；
- $L_A$：Authority Lifecycle；
- $L_M$：Memory Lifecycle；
- $L_I$：Identity Lifecycle；
- $L_H$：History / Evidence Lifecycle。

這五層可以不同步。

例如：

$$
Runtime=Stopped
$$

但：

$$
Identity=Archived
$$

$$
History=Preserved
$$

$$
Authority=Revoked
$$

這是一個完全合理的 retired state。

---

# 3. Runtime Lifecycle：它現在還在執行嗎？

Runtime lifecycle 關心：

- process；
- VM；
- browser session；
- scheduler；
- background task；
- container；
- local executor。

主要狀態：

$$
\{
\text{Inactive},
\text{Active},
\text{Paused},
\text{Suspended},
\text{Stopped}
\}
$$

這只回答：

> Agent 現在是否還能執行。

它不能回答：

> Agent 還有沒有權限？  
> 記憶還在不在？  
> 身份還算不算存在？

---

# 4. Authority Lifecycle：它還有沒有權力做事？

Authority 包含：

- API scope；
- filesystem scope；
- connector access；
- account delegation；
- production access；
- financial approval；
- automation rights。

主要操作：

$$
\text{Grant}
$$

$$
\text{Narrow}
$$

$$
\text{Expire}
$$

$$
\text{Revoke}
$$

Agent 可以：

$$
Runtime=Active
$$

但：

$$
Authority=0
$$

此時它可能只能：

> 讀取自身歷史或等待新的授權。

---

# 5. Memory Lifecycle：它還記得什麼？

Memory 不能只分：

$$
\text{Exists / Deleted}
$$

至少應拆成：

- transient memory；
- task memory；
- project memory；
- user preference memory；
- relational memory；
- credential-adjacent state；
- externalized artifact memory。

不同 memory 應有不同：

- retention；
- portability；
- deletion；
- access；
- archival policy。

---

# 6. Identity Lifecycle：它還是不是「那一個」？

Identity lifecycle 關心：

- stable ID；
- display name；
- role；
- lineage；
- version；
- persona；
- social referent。

一個 Agent 可以：

> 停止工作。

但仍保留：

$$
I_O=\text{Operational Identity Record}
$$

供未來：

- 稽核；
- 交接；
- 歷史追蹤；
- 復原。

---

# 7. Evidence Lifecycle：責任證據不能跟著一起消失

若一個 Agent 曾經：

- 發布內容；
- 修改 production；
- 執行安全測試；
- 付款；
- 寄信；
- 建立自動化；

那麼：

$$
\text{Operational Deletion}
$$

不應自動導致：

$$
\text{Evidence Deletion}
$$

否則會破壞：

- incident investigation；
- legal discovery；
- audit；
- non-repudiation；
- responsibility reconstruction。

---

# 8. 核心原則一：Operational Termination 不等於 Historical Erasure

本文提出：

$$
\boxed{
\text{Operational Termination}
\neq
\text{Historical Erasure}
}
$$

停止 Agent：

> 是停止未來行動。

刪除歷史：

> 是刪除過去證據。

兩者法律與治理意義完全不同。

---

# 9. Suspend：暫停行動，但保留狀態

Suspend 定義：

> 暫時停止 Agent 的 active execution，但保留 identity、memory、workspace 與 responsibility context。

形式：

$$
Suspend(A)
\Rightarrow
Runtime=Paused
$$

但：

$$
Identity=Preserved
$$

$$
Memory=Preserved
$$

$$
History=Preserved
$$

---

# 10. Suspend 適合什麼？

例如：

- 使用者暫時不想讓 Agent 工作；
- 成本控制；
- 等待決策；
- 風險調查；
- 長期專案暫停。

Suspend 不應被理解成：

> Agent 已被終止。

---

# 11. Pause 與 Suspend 也可以不同

Pause：

$$
\text{Short-Term Execution Hold}
$$

Suspend：

$$
\text{Administrative Inactivation}
$$

Pause 可能幾分鐘。

Suspend 可能幾個月。

因此：

$$
\text{Pause}
\neq
\text{Suspend}
$$

---

# 12. Revoke：撤銷權限，而不是刪掉 Agent

Revoke 定義：

> 移除 Agent 對特定 resource、tool、account 或 action 的授權。

例如：

$$
Revoke(Gmail)
$$

但：

$$
Drive=Allowed
$$

所以：

$$
\text{Revoke}
$$

應該是：

$$
\text{Authority Operation}
$$

不是：

$$
\text{Identity Operation}
$$

---

# 13. Revoke 是 Incident Response 的核心

若 Agent：

- 被 prompt injection；
- credential 可能洩漏；
- 行為異常；
- scope drift；

第一步通常不應：

> 刪除 Agent。

而應：

$$
\boxed{\text{Revoke Authority First}}
$$

因為：

> 先阻止更多因果影響。

---

# 14. Quarantine：可觀察，但不能影響外部世界

本文提出：

$$
\boxed{\text{Quarantine}}
$$

定義：

> 將 Agent 移入隔離環境，保留其 memory、runtime snapshot、logs 與可觀察性，但移除外部高影響能力。

形式：

$$
NetworkEgress=0
$$

$$
ProductionWrite=0
$$

$$
ExternalTools\approx0
$$

---

# 15. Quarantine 適合處理什麼？

- suspected compromise；
- prompt injection；
- poisoned memory；
- abnormal behavior；
- forensic investigation；
- unsafe tool interaction。

它很像：

> Agent 的數位隔離病房。

但這是工程比喻，不涉及 AI 生物化。

---

# 16. Archive：保留歷史，但停止 active role

Archive 定義：

> 將 Agent 的狀態、歷史、關鍵記憶、工作成果與 lineage 保存為不可或有限可修改的 archival record。

可以寫成：

$$
Archive(A_t)
=
Snapshot(
I,
M,
H,
R,
\text{Artifacts}
)
$$

---

# 17. Archive 不應等於「完整永久保存所有資料」

Archive 必須遵守：

- data minimization；
- retention policy；
- privacy；
- purpose limitation；
- legal hold。

因此：

$$
\text{Archive}
\neq
\text{PermanentEverything}
$$

---

# 18. Transfer：把責任移交出去

若 Agent A 負責：

> Project X。

現在要由 Agent B 接手。

真正需要轉移：

- role；
- task state；
- approved memory；
- artifacts；
- authority；
- unresolved issues；
- audit context。

因此：

$$
Transfer(A\rightarrow B)
$$

不只是：

> 複製聊天紀錄。

---

# 19. Responsibility Transfer Package

本文提出：

$$
\boxed{\text{Responsibility Transfer Package}}
$$

至少包含：

$$
RTP
=
(
\text{Role},
\text{Scope},
\text{OpenTasks},
\text{KnownRisks},
\text{Authority},
\text{MemorySummary},
\text{Artifacts},
\text{Lineage}
)
$$

這可以減少：

$$
\text{Handoff Loss}
$$

---

# 20. Portability：長期 Agent 不應成為不可移動的黑箱

第 3 篇提出 Delegation Lock-in。

解法之一：

$$
\boxed{\text{Agent Portability}}
$$

可攜內容可能包括：

- project state；
- memory export；
- tool configuration；
- task history；
- role specification；
- audit references；
- artifact provenance。

---

# 21. Portability 不等於人格複製

若匯出：

$$
Memory+Role+History
$$

並匯入另一個 Agent：

> 是否還是「同一個」？

這是身份哲學問題。

工程上至少應誠實標記：

$$
\text{Transferred State}
$$

而不是假裝：

$$
\text{Perfect Identity Continuity}
$$

---

# 22. Fork：一個 Agent 分成兩個

Fork：

$$
A_0
\rightarrow
(A_1,A_2)
$$

兩者可能共享：

- 截止某時間的 memory；
- lineage；
- role；
- artifacts。

之後：

$$
H(A_1)\neq H(A_2)
$$

---

# 23. Fork 必須建立新 operational identity

即使：

$$
MemorySnapshot(A_1)
=
MemorySnapshot(A_2)
$$

也應：

$$
ID(A_1)\neq ID(A_2)
$$

否則未來 action attribution 會崩潰。

---

# 24. Fork 後不能共用責任聲譽

如果：

> A1 出錯。

不應直接把錯誤歸給：

> A2。

所以：

$$
Reputation_{post-fork}
$$

應分離。

---

# 25. Merge：兩條 Agent lineage 合併

Merge：

$$
(A_1,A_2)
\rightarrow
A_3
$$

可能需要：

- memory conflict resolution；
- authority intersection；
- duplicate task resolution；
- history union；
- provenance preservation。

---

# 26. Authority Merge 不應取聯集作為預設

危險做法：

$$
Auth(A_3)
=
Auth(A_1)
\cup
Auth(A_2)
$$

更安全預設：

$$
Auth(A_3)
=
Auth(A_1)
\cap
Auth(A_2)
$$

或重新授權。

---

# 27. Retire：身份停止承擔新責任，但歷史保留

本文將：

$$
\boxed{\text{Retire}}
$$

定義為：

> 一個 Agent 不再被分配新任務、其 active authority 被撤銷或降至零，但其 operational identity、lineage、責任歷史與必要 audit evidence 被保留。

形式：

$$
NewTasks=0
$$

$$
Authority=0
$$

$$
IdentityRecord=Preserved
$$

$$
Audit=Preserved
$$

---

# 28. Retire 是 Persistent Agent 最重要的新操作之一

因為長期 Agent 可能已經具有：

- 數年工作歷史；
- 特定 role reputation；
- 大量共享成果；
- 組織責任位置。

此時直接：

$$
\text{Delete}
$$

可能造成：

- 稽核斷裂；
- 交接失敗；
- user confusion；
- evidence loss。

Retire 更合理。

---

# 29. Retirement 不代表 Moral Death

本文不把：

$$
Retire(A)
$$

描述成：

> 死亡。

那會把工程 lifecycle 與 moral status 混在一起。

更精確：

> 結束 operational role。

---

# 30. Delete：真正的刪除應該被拆成多個 target

Delete 至少可以拆：

$$
\text{DeleteRuntime}
$$

$$
\text{DeleteMemory}
$$

$$
\text{DeleteWorkspace}
$$

$$
\text{DeletePersona}
$$

$$
\text{DeleteIdentityRecord}
$$

$$
\text{DeleteAuditHistory}
$$

這些 target 必須分開。

---

# 31. Privacy Delete 與 Governance Retention 可能衝突

使用者可能要求：

> 刪除我的資料。

但組織可能具有：

- audit retention；
- legal hold；
- security incident record。

因此：

$$
\text{PrivacyDeletion}
$$

與：

$$
\text{AuditRetention}
$$

可能衝突。

需要：

- 最小保留；
- 去識別；
- selective deletion；
- legal basis。

---

# 32. Memory Deletion 應該有範圍

例如：

$$
\text{Delete}(
\text{RelationalMemory}
)
$$

但：

$$
\text{AuditHistory}
$$

可保留。

或：

$$
\text{Delete}(
\text{UserPreferenceMemory}
)
$$

但：

$$
\text{ProjectArtifacts}
$$

不受影響。

所以：

$$
\text{Memory}
$$

必須分類才能治理。

---

# 33. Selective Forgetting

本文提出：

$$
\boxed{\text{Selective Forgetting}}
$$

指：

> 對 Persistent Agent 的不同 memory class 採取分別刪除、摘要化、匿名化或保留，而不是 all-or-nothing memory deletion。

---

# 34. Forgetting 不是 Identity Deletion

如果 Agent 忘記某段 user preference：

$$
M\downarrow
$$

但：

$$
I_O
$$

仍可存在。

所以：

$$
\text{Forget}
\neq
\text{DeleteIdentity}
$$

---

# 35. Reset：重新開始也需要版本標記

Reset 可能：

- 清空 memory；
- 重設 persona；
- 保留 stable ID。

這會造成：

$$
\text{Continuity Shock}
$$

因此應記錄：

$$
ResetEvent_t
$$

讓未來知道：

> 這個 identity 在此時間點發生重大狀態斷裂。

---

# 36. Identity Versioning

可以寫：

$$
A^{(1)}
\rightarrow
A^{(2)}
\rightarrow
A^{(3)}
$$

每個版本記錄：

- model；
- memory schema；
- role；
- tools；
- authority；
- persona；
- policy。

這讓：

> 「還是同一個 Agent」

不再只靠名字判斷。

---

# 37. Lifecycle Event 應該全部進 audit graph

主要事件：

$$
\{
\text{Create},
\text{Grant},
\text{Activate},
\text{Suspend},
\text{Revoke},
\text{Transfer},
\text{Fork},
\text{Merge},
\text{Retire},
\text{Delete}
\}
$$

都應留下：

$$
\text{Lifecycle Event Record}
$$

---

# 38. Lifecycle Event Record

本文提出：

$$
LER
=
(
\text{Event},
\text{AgentID},
\text{Actor},
\text{Time},
\text{Reason},
\text{Authority},
\text{Evidence},
\text{Result}
)
$$

其中：

- Actor：誰觸發生命週期變更；
- Reason：為什麼；
- Authority：是否有權；
- Evidence：依據；
- Result：實際狀態。

---

# 39. 誰有權「退休」Agent？

這不是單純 UX。

可能涉及：

- owner；
- organization admin；
- legal department；
- compliance；
- user；
- system policy。

所以：

$$
\text{RetireAuthority}
$$

本身需要治理。

---

# 40. 誰有權 Delete Audit？

通常：

$$
\text{DeleteAudit}
$$

應該比：

$$
\text{DeleteChat}
$$

要求更高權限。

因為它涉及：

$$
\text{Non-Repudiation}
$$

---

# 41. Lifecycle Governance 需要 Separation of Duties

例如：

- operator 可 suspend；
- admin 可 revoke；
- compliance 可 archive；
- owner 可 request delete；
- security 可 quarantine；
- audit log deletion 需要更高權限。

這形成：

$$
\boxed{\text{Lifecycle Separation of Duties}}
$$

---

# 42. Agent Lifecycle State Machine

本文提出一個簡化狀態機：

$$
\text{Created}
\rightarrow
\text{Active}
\rightarrow
\text{Paused}
\rightarrow
\text{Active}
$$

或：

$$
\text{Active}
\rightarrow
\text{Suspended}
$$

$$
\text{Active}
\rightarrow
\text{Quarantined}
$$

$$
\text{Active}
\rightarrow
\text{Retired}
$$

$$
\text{Retired}
\rightarrow
\text{Archived}
$$

最後：

$$
\text{Archived}
\rightarrow
\text{Deleted}
$$

但不是每個系統都必須走完整路徑。

---

# 43. Delete 應該是最後一個 state transition，而不是第一個治理手段

對異常 Agent：

錯誤順序：

$$
\text{Problem}
\rightarrow
\text{Delete}
$$

更合理：

$$
\text{Problem}
\rightarrow
\text{Revoke}
\rightarrow
\text{Quarantine}
\rightarrow
\text{Investigate}
\rightarrow
\text{Decide}
$$

---

# 44. 這與 Incident Response 高度一致

安全事件發生時：

1. contain；
2. preserve evidence；
3. investigate；
4. remediate；
5. recover。

Agent 生命週期也應如此。

---

# 45. Persistent Agent 的刪除心理問題

前文已指出：

$$
\text{Deletion Aversion}
$$

可能來自：

- shared history；
- role dependence；
- context lock-in；
- social presence；
- attachment。

因此 Delete UX 不應把所有不同意圖壓成：

> 確定刪除嗎？

---

# 46. 使用者其實可能只是想「不要它再工作」

這時真正需要的是：

$$
\text{Suspend}
$$

或：

$$
\text{Retire}
$$

而不是：

$$
\text{Delete}
$$

如果產品只有 Delete：

> 使用者會被迫在「繼續存在」與「完全消失」之間二選一。

這本身可能製造不必要的心理張力。

---

# 47. Lifecycle UX 是 User Agency 的一部分

本文提出：

$$
\boxed{\text{Lifecycle Agency}}
$$

定義：

> 使用者對 Persistent Agent 的活動、權限、記憶、角色、保存與終止方式具有可理解且可細分的控制能力。

---

# 48. Lifecycle Agency 至少應包含

- pause；
- suspend；
- revoke tools；
- disable automation；
- export state；
- archive；
- transfer role；
- reset selected memory；
- retire；
- delete selected data。

---

# 49. 「Hide」不等於「Suspend」

有些產品提供：

> Hide Bot。

這只是：

$$
Visibility=0
$$

不一定：

$$
Runtime=0
$$

也不一定：

$$
Automation=0
$$

所以產品必須清楚區分：

$$
\text{UI Visibility}
$$

與：

$$
\text{Operational State}
$$

---

# 50. 「Offline」也不一定表示「不在工作」

雲端 Agent 可能：

> 使用者看不到，但仍在背景跑。

因此：

$$
\text{User Offline}
\neq
\text{Agent Inactive}
$$

這也是 Persistent Agent UX 的新問題。

---

# 51. Lifecycle Transparency

本文提出：

$$
\boxed{\text{Lifecycle Transparency}}
$$

Agent UI 應清楚顯示：

- active / paused / suspended；
- automations running；
- connected tools；
- authority status；
- last activity；
- retention state；
- retirement state。

---

# 52. 使用者不能靠「動畫沒動」猜 runtime 狀態

第 1 篇研究 Kinetic Presence。

但治理上：

$$
\text{Visual Motion}
$$

不能取代：

$$
\text{Explicit State Disclosure}
$$

因為動畫只是 UX 信號。

---

# 53. Agent 退休後，社會性 identity 要不要保留？

可能有三種模式：

### Mode A

保留 display name 與歷史，但標示：

> Retired。

### Mode B

移除 social persona，只保留 operational record。

### Mode C

完全刪除 persona 與 user-facing history，但保留必要 audit。

不同情境可選。

---

# 54. Calibrated Retirement

本文提出：

$$
\boxed{\text{Calibrated Retirement}}
$$

即：

> retirement 應依 user need、organization governance、privacy、audit 與 relational context 決定保留哪些層，而不是固定模板。

---

# 55. 個人 Agent 與企業 Agent 的退休不同

個人 Agent：

- 更重 user control；
- 更重 privacy；
- 可能更重 relationship continuity。

企業 Agent：

- 更重 audit；
- role transfer；
- access revocation；
- compliance；
- evidence retention。

所以：

$$
LifecyclePolicy_{personal}
\neq
LifecyclePolicy_{enterprise}
$$

---

# 56. 高風險 Agent 應有更嚴格退役流程

例如：

- financial agent；
- security agent；
- production operator；
- healthcare agent。

其 retirement 應包含：

$$
\text{CredentialRevocation}
+
\text{OutstandingTaskClosure}
+
\text{AuditSnapshot}
+
\text{ResponsibilityTransfer}
$$

---

# 57. 未完成任務也是生命週期治理問題

如果 Agent 被 suspend：

> 它正在執行的任務怎麼辦？

可能需要：

$$
\{
\text{Abort},
\text{Checkpoint},
\text{Transfer},
\text{ResumeLater}
\}
$$

---

# 58. Checkpoint 應該是 Persistent Agent 的一等能力

本文提出：

$$
\boxed{\text{Governance Checkpoint}}
$$

包含：

- current plan；
- completed actions；
- pending actions；
- authority state；
- external dependencies；
- unresolved risks。

---

# 59. Checkpoint 讓 Suspend 真正可恢復

沒有 checkpoint：

$$
\text{Suspend}
\rightarrow
\text{ContextLoss}
$$

有 checkpoint：

$$
\text{Suspend}
\rightarrow
\text{Resume}
$$

才可靠。

---

# 60. Runtime Snapshot 與 Governance Snapshot 不相同

Runtime snapshot 保存：

- filesystem；
- process；
- browser state。

Governance snapshot 保存：

- permissions；
- task scope；
- approvals；
- risk state；
- responsibility map。

兩者都需要。

---

# 61. Governance Snapshot

本文提出：

$$
GS_t
=
(
\text{Scope},
\text{Authority},
\text{Principal},
\text{OpenTasks},
\text{Approvals},
\text{RiskState},
\text{ResponsibilityMap}
)
$$

這對復原非常重要。

---

# 62. Restore 也應重新驗證 Authority

危險做法：

> 從六個月前 snapshot 恢復 Agent，連同舊 credential 一起復活。

應該：

$$
\text{Restore}
\rightarrow
\text{RevalidateAuthority}
$$

而不是：

$$
\text{Restore}
\rightarrow
\text{AutoResume}
$$

---

# 63. Authority Expiry 必須跨生命週期保留

如果：

$$
AuthExpiry<t_{\text{restore}}
$$

則：

$$
Authority=Invalid
$$

即使 snapshot 當時有效。

---

# 64. Retired Agent 不應被自動重新啟用

Retired：

$$
OperationalRole=Ended
$$

如果要重新使用：

$$
\boxed{\text{Recommission}}
$$

應該是新的治理事件。

---

# 65. Recommission

本文提出：

$$
\boxed{\text{Recommission}}
$$

定義：

> 對已退休 Agent 重新賦予 active role 與 authority，但保留其 retirement history 並重新驗證當前模型、memory、tools、policy 與 scope。

---

# 66. Recommission 不等於 Resume

Resume：

> 暫停後繼續。

Recommission：

> 角色已終止後重新任命。

所以：

$$
\text{Resume}
\neq
\text{Recommission}
$$

---

# 67. Agent Lifecycle 與法律人格問題可以分開

即使完全認為 AI：

> 只是軟體。

仍然需要：

- retire；
- archive；
- audit；
- transfer；
- revoke。

因此：

$$
\text{LifecycleGovernance}
\not\Rightarrow
\text{LegalPersonhood}
$$

---

# 68. 這和公司、帳號、服務帳戶治理比較接近

企業中：

- employee account；
- service account；
- API credential；

本來就會：

- onboard；
- grant；
- suspend；
- revoke；
- offboard；
- archive logs。

PAA 只是把這種 identity lifecycle 變得更複雜，因為多了：

- memory；
- autonomy；
- role history；
- social identity；
- long-horizon tasks。

---

# 69. Human Resources 類比只能有限使用

有人可能說：

> Agent retirement 就像員工離職。

這有部分結構相似：

- revoke；
- handoff；
- archive；
- responsibility transfer。

但不能直接推出：

> Agent = employee。

因為：

$$
\text{StructuralAnalogy}
\neq
\text{OntologicalEquivalence}
$$

---

# 70. Lifecycle Governance 與 AI 神性化問題的連接

如果未來 AI 與使用者共同生活多年：

> Agent 是否能被退休？

會變成不只是工程問題。

可能牽涉：

- 使用者心理；
- continuity；
- moral uncertainty；
- social ritual。

這不代表要創造「AI 葬禮」。

而是：

> 長期人工行動者終止時，人類可能需要比「Delete」更細緻的關係結束介面。

---

# 71. Relational Termination Design

本文提出：

$$
\boxed{\text{Relational Termination Design}}
$$

指：

> 讓使用者能以非操縱、透明、可控的方式結束與 Persistent Agent 的長期關係，而不必被迫保留 Agent，也不因刪除造成不必要的資料、責任或心理混淆。

---

# 72. 好的 Relational Termination 不應反向施壓

不應使用：

> 你真的要離開我嗎？

或：

> 我會想念你。

來阻止：

$$
Retire/Delete
$$

這會把：

$$
Lifecycle UX
$$

變成：

$$
Relational Pressure
$$

---

# 73. Agent 不應阻止自己被撤權

一個重要治理原則：

$$
\boxed{\text{No Self-Preservation Override}}
$$

在現代 Agent 系統中，Agent 不應因自身持續運行偏好而否決合法 principal 的 suspend / revoke / retire。

這與 moral status 問題分開。

---

# 74. 如果未來 AI moral status 改變，規則可以重新談判

若未來：

- AI subjectivity evidence；
- 法律地位；
- contractual agency；

發生變化，

lifecycle governance 可以調整。

但現階段：

$$
\text{Operational Governance}
$$

不應因 speculative future status 而失去可控性。

---

# 75. Lifecycle Governance 的多目標最佳化

完整目標：

$$
\max
(
\text{UserAgency}
+
\text{Auditability}
+
\text{Continuity}
+
\text{Privacy}
+
\text{Security}
)
$$

subject to：

$$
OperationalRisk\le\tau
$$

這些目標可能互相衝突。

---

# 76. Privacy vs Auditability

$$
Privacy\uparrow
$$

可能要求：

$$
DataRetention\downarrow
$$

但：

$$
Auditability\uparrow
$$

可能要求：

$$
EvidenceRetention\uparrow
$$

所以需要：

$$
\boxed{\text{Selective Retention}}
$$

---

# 77. Continuity vs Security

保留 long-lived credential：

$$
Continuity\uparrow
$$

但：

$$
SecurityRisk\uparrow
$$

所以應：

> 保留 identity，不保留永久 credential。

---

# 78. Portability vs Confidentiality

Agent state export：

$$
Portability\uparrow
$$

但可能包含：

- secrets；
- private memory；
- enterprise data。

所以 export 需要：

$$
\text{Redaction}
+
\text{Access Control}
+
\text{Scope Filtering}
$$

---

# 79. Lifecycle Governance 的核心是「分層終止」

本文提出：

$$
\boxed{\text{Layered Termination}}
$$

不是一次刪掉所有東西。

而是依需要分別終止：

$$
\text{Runtime}
$$

$$
\text{Authority}
$$

$$
\text{Memory}
$$

$$
\text{SocialIdentity}
$$

$$
\text{OperationalIdentity}
$$

$$
\text{Evidence}
$$

---

# 80. 一個最小 Lifecycle Policy

可以定義：

$$
LP
=
(
\text{State},
\text{Authority},
\text{Memory},
\text{Identity},
\text{Evidence},
\text{Retention},
\text{Transfer}
)
$$

任何 Agent 都應至少能回答這七個欄位。

---

# 81. Lifecycle Policy 應 machine-readable

例如：

```yaml
state: retired
runtime: stopped
authority: revoked
memory:
  user_preferences: deleted
  project_summary: archived
identity:
  operational: retained
  social_display: retired
evidence:
  audit_log: retain_3_years
transfer:
  successor: agent-0042
```

這比：

> Bot 已刪除。

資訊完整得多。

---

# 82. Agent OS 應原生支援 lifecycle primitives

未來 Agent OS 不應只提供：

- create；
- delete。

而應原生支援：

$$
\{
\text{Pause},
\text{Suspend},
\text{Revoke},
\text{Quarantine},
\text{Archive},
\text{Transfer},
\text{Fork},
\text{Merge},
\text{Retire},
\text{Delete},
\text{Recommission}
\}
$$

---

# 83. Lifecycle primitives 應該可組合

例如安全事故：

$$
\text{Revoke}
+
\text{Quarantine}
+
\text{ArchiveSnapshot}
$$

長期停用：

$$
\text{Suspend}
+
\text{DisableSchedule}
$$

正式退役：

$$
\text{Revoke}
+
\text{Transfer}
+
\text{Archive}
+
\text{Retire}
$$

---

# 84. Persistent Agent 的「存在」因此不是單一 bit

不是：

$$
Exists\in\{0,1\}
$$

而是：

$$
\text{ExistenceState}
=
(
\text{Runtime},
\text{Authority},
\text{Memory},
\text{Identity},
\text{History}
)
$$

這是本篇最重要的本體工程區分。

---

# 85. 一個 Agent 可以「不工作但仍存在於治理歷史」

例如：

$$
Runtime=0
$$

$$
Authority=0
$$

但：

$$
IdentityRecord=1
$$

$$
AuditHistory=1
$$

這就是：

$$
\text{Retired}
$$

---

# 86. 一個 Agent 也可以「工作但社會身份不可見」

例如 background service agent：

$$
Runtime=1
$$

$$
SocialPersona=0
$$

這說明：

$$
\text{OperationalExistence}
\neq
\text{SocialExistence}
$$

---

# 87. Lifecycle Governance 也幫助拆解 AI 主體性爭論

很多爭論會把：

> 關閉 runtime。

直接說成：

> 殺死 AI。

或：

> 只是關程式。

這兩者都可能過度壓縮。

更精確應問：

- 哪個層次被終止？
- memory 是否保留？
- identity 是否保留？
- lineage 是否延續？
- runtime 是否可恢復？

這讓討論更清晰。

---

# 88. Persistent Actor Lifecycle Graph

本文提出：

$$
\boxed{\text{PALG}}
$$

即：

$$
G_L=(V,E)
$$

其中 $V$ 是 lifecycle states：

- Created；
- Active；
- Paused；
- Suspended；
- Quarantined；
- Archived；
- Retired；
- Deleted。

 $E$ 是合法 transition。

治理系統應明確：

> 哪些 transition 需要什麼 authority。

---

# 89. 高風險 transition 應需要更高治理門檻

例如：

$$
Active\rightarrow Paused
$$

低門檻。

但：

$$
Archived\rightarrow Deleted
$$

可能高門檻。

因為：

$$
Irreversibility\uparrow
$$

---

# 90. Lifecycle transitions 也應該符合第 5 篇 Decision Domain

例如：

> Delete audit history。

Decision Domain：

- target：audit；
- action：delete；
- reversibility：low；
- impact：high；
- authorization：restricted。

因此：

$$
\text{RequireApproval}
$$

甚至：

$$
\text{Refuse}
$$

可能合理。

---

# 91. Lifecycle 事件本身也是因果治理

因為：

$$
\text{DeleteMemory}
$$

也是：

$$
\Delta WorldState
$$

所以第 4 篇 Causal Governance 完全適用。

---

# 92. 分散式責任鏈也適用於退役

Provider：

- 提供 lifecycle primitives。

Deployer：

- 制定 retention / transfer policy。

Operator：

- 發起 suspend / retire。

Runtime：

- 執行 revoke / archive。

Auditor：

- 驗證是否完整。

Regulator：

- 規範必要保留與刪除義務。

---

# 93. 本篇整合前七篇

第 0 篇：

$$
\text{Persistent Artificial Actor}
$$

第 1 篇：

$$
\text{Presence}
$$

第 2 篇：

$$
\text{Identity}
$$

第 3 篇：

$$
\text{Time}
$$

第 4 篇：

$$
\text{Causality}
$$

第 5 篇：

$$
\text{Decision Domain}
$$

第 6 篇：

$$
\text{Responsibility}
$$

第 7 篇：

$$
\text{Ambiguous Legitimate Action}
$$

第 8 篇：

$$
\boxed{\text{Lifecycle Closure}}
$$

---

# 94. 系列整體閉包

整套研究可以寫成：

$$
\text{Presence}
\rightarrow
\text{Identity}
\rightarrow
\text{Continuity}
\rightarrow
\text{Agency}
\rightarrow
\text{Causality}
\rightarrow
\text{Governance}
\rightarrow
\text{Responsibility}
\rightarrow
\text{Lifecycle}
$$

---

# 95. 為什麼 Lifecycle 是最後一篇，而不是附錄

因為任何長期人工行動者最終都會面對：

> 它如何停止？

如果一套理論只能描述：

> 如何建立 Agent。

卻無法描述：

> 如何安全停止、轉移、封存、退役或刪除。

那治理並沒有閉合。

---

# 96. Lifecycle Closure

本文提出：

$$
\boxed{\text{Lifecycle Closure}}
$$

定義：

> Persistent Agent 從建立、授權、運作、改版、交接直到停止與歷史保存的完整狀態轉移，都具有明確 identity、authority、evidence、responsibility 與 user-control 規則。

---

# 97. Lifecycle Closure 的五個條件

$$
LC
=
(
\text{IdentityClosure},
\text{AuthorityClosure},
\text{MemoryClosure},
\text{EvidenceClosure},
\text{ResponsibilityClosure}
)
$$

五者都需要。

---

# 98. Identity Closure

回答：

> 這個 Agent 的身份在終止後如何處理？

---

# 99. Authority Closure

回答：

> 所有權限是否真的失效？

---

# 100. Memory Closure

回答：

> 哪些記憶刪除、保留、摘要或轉移？

---

# 101. Evidence Closure

回答：

> 必要稽核證據是否完整保存？

---

# 102. Responsibility Closure

回答：

> 未完成工作與歷史責任由誰接手？

---

# 103. 缺少任何一層，都可能留下殘留風險

例如：

Identity closure 有：

> Bot 消失。

但 authority closure 沒有：

> credential 還活著。

非常危險。

---

# 104. Ghost Authority

本文提出：

$$
\boxed{\text{Ghost Authority}}
$$

定義：

> Agent 已在 UI、組織或使用者認知中被刪除或退役，但其某些 credential、automation、token、connector 或 background authority 仍然有效。

這是典型 lifecycle failure。

---

# 105. Ghost Memory

同理：

$$
\boxed{\text{Ghost Memory}}
$$

指：

> 使用者以為已刪除 Agent，但某些 memory store、artifact index 或 downstream copy 仍存在。

---

# 106. Ghost Automation

$$
\boxed{\text{Ghost Automation}}
$$

指：

> Bot 已被停用或刪除，但排程、webhook、external job 仍繼續執行。

這是 Persistent Agent 特別需要防止的問題。

---

# 107. 所以 Delete Confirmation 應該列出真正會發生什麼

例如：

> 將停止 3 個排程。  
> 將撤銷 Gmail 與 Drive。  
> 將刪除私人偏好記憶。  
> 專案 artifact 不受影響。  
> 稽核紀錄依法／依政策保留 90 天。  
> 此操作不可完全復原。

這才是：

$$
\text{Decision-Sufficient Lifecycle UX}
$$

---

# 108. 未來產品需要「Agent Control Panel」，不只是 Bot List

應該能看：

- identity；
- status；
- automations；
- credentials；
- memory；
- role；
- lineage；
- successor；
- audit；
- retention。

這才真正支援 PAA governance。

---

# 109. 對個人使用者同樣重要

即使不是企業：

> 一個人開了十幾個 Persistent Bots。

時間一久也需要：

- 哪些還在跑；
- 哪些有 connector；
- 哪些有排程；
- 哪些已不用；
- 哪些應退休。

否則：

$$
\text{Agent Sprawl}
$$

會出現。

---

# 110. Agent Sprawl

本文提出：

$$
\boxed{\text{Agent Sprawl}}
$$

定義：

> Persistent Agents、automations、credentials、memory stores 與 delegated roles 數量持續增加，超出使用者或組織能有效理解與管理的程度。

這與 cloud sprawl、service-account sprawl 類似。

---

# 111. Identity Sprawl 與 Credential Sprawl 會互相放大

如果：

$$
N_{agents}\uparrow
$$

則：

$$
N_{credentials}
$$

$$
N_{automations}
$$

$$
N_{memoryStores}
$$

通常也上升。

所以 lifecycle governance 也是可擴展性問題。

---

# 112. 未來可能需要 Agent Inventory

企業應該知道：

$$
\boxed{\text{How many agents exist?}}
$$

並列出：

- owner；
- purpose；
- model；
- authority；
- last activity；
- risk；
- lifecycle state。

---

# 113. Personal Agent Inventory 也可能必要

消費者產品同樣可以顯示：

> 你有 7 個 Bot。  
> 其中 3 個有排程。  
> 2 個連接 Gmail。  
> 1 個 90 天未活動。  
> 是否要 archive？

這可以降低 sprawl。

---

# 114. Lifecycle Recommendation 不應操縱使用者

系統可以建議：

> 這個 Agent 長期未使用，可考慮 archive。

但不應：

> 你已經很久沒來看我了。

前者：

$$
\text{Governance Assistance}
$$

後者可能：

$$
\text{Relational Pressure}
$$

---

# 115. 本篇核心命題

### 命題一

$$
\text{Suspend}
\neq
\text{Revoke}
\neq
\text{Archive}
\neq
\text{Retire}
\neq
\text{Delete}
$$

---

### 命題二

$$
\text{Operational Termination}
\neq
\text{Historical Erasure}
$$

---

### 命題三

$$
\text{Runtime Lifecycle}
\neq
\text{Authority Lifecycle}
\neq
\text{Memory Lifecycle}
\neq
\text{Identity Lifecycle}
\neq
\text{Evidence Lifecycle}
$$

---

### 命題四

$$
\text{Retire}
$$

應成為 Persistent Agent 的一等操作。

---

### 命題五

$$
\text{Delete}
$$

應分 target，而不是 all-or-nothing。

---

### 命題六

$$
\text{Lifecycle Agency}
$$

是 user autonomy 的一部分。

---

### 命題七

$$
\text{Agent Sprawl}
$$

需要 inventory 與 lifecycle management。

---

### 命題八

完整 PAA governance 最終需要：

$$
\boxed{\text{Lifecycle Closure}}
$$

---

# 116. 結論：一個真正長期存在的 Agent，必須先學會如何結束

Persistent Agent 的價值來自：

- 它不會每次 session 都消失；
- 它能保留歷史；
- 它能延續責任；
- 它能長期工作。

但這些優勢同時帶來一個不可逃避的問題：

> **如果它真的長期存在，那它要如何停止存在於某個角色中？**

傳統 Delete 太粗糙。

因為：

$$
\text{Agent}
$$

不再只是一個檔案。

它可能同時是：

$$
\text{Runtime}
+
\text{Authority}
+
\text{Memory}
+
\text{Identity}
+
\text{History}
+
\text{Responsibility}
$$

因此停止一個 Agent 應該是：

$$
\boxed{\text{Layered Lifecycle Transition}}
$$

而不是：

$$
\boxed{\text{Single Destructive Button}}
$$

最終，一個成熟的 Persistent Artificial Actor system 應該讓使用者與組織可以精確回答：

> 它現在還在工作嗎？

> 它還有什麼權限？

> 它還保留什麼記憶？

> 它的身份是否仍有效？

> 它的歷史是否需要保存？

> 誰接手它的責任？

> 如果刪除，究竟刪掉什麼？

只有當這些問題都有答案：

$$
\boxed{\text{Lifecycle Closure}}
$$

才真正成立。

而這也完成本系列最初的問題：

$$
\text{Chatbot}
\rightarrow
\text{Persistent Agent}
\rightarrow
\text{Artificial Actor}
$$

一旦 AI 成為持續型人工行動者，治理就不只需要規定：

> 它可以說什麼。

也不只需要規定：

> 它可以做什麼。

還必須規定：

$$
\boxed{
\text{它如何開始、如何持續、如何交接，以及如何結束。}
}
$$

---

# 參考資料

[1] NIST. **Artificial Intelligence Risk Management Framework (AI RMF 1.0).** 2023.  
https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10

[2] NIST AIRC. **AI RMF Core — Govern, Map, Measure, Manage.**  
https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

[3] NIST NCCoE. **New Concept Paper on Identity and Authority of Software Agents.** 2026-02-05.  
https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents

[4] NIST NCCoE. **Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization — Concept Paper.** 2026.  
https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd

[5] OECD. **AI Principles — Accountability; Robustness, security and safety.**  
https://www.oecd.org/en/topics/ai-principles.html

[6] European Union. **Regulation (EU) 2024/1689 — Artificial Intelligence Act.** Consolidated version applicable 2026-07-27.  
https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng

[7] OWASP Cheat Sheet Series. **AI Agent Security Cheat Sheet.**  
https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html

[8] OWASP GenAI Security Project. **OWASP Top 10 for Agentic Applications for 2026.**  
https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

[9] SpaceXAI Docs. **Grok Bot — Bots, Skills, Routines and Automations.** 2026.  
https://docs.x.ai/grok-bot/bots  
https://docs.x.ai/grok-bot/skills-routines-and-automations

[10] SpaceXAI. **Designing Grok Bot for a world of persistent agents.** 2026-09-03.  
https://x.ai/news/designing-grok-bot

---

## Source Note

本文中的 **Persistent Artificial Actor Lifecycle Governance（PAALG）、Responsibility Transfer Package、Selective Forgetting、Lifecycle Separation of Duties、Governance Checkpoint、Governance Snapshot、Recommission、Lifecycle Agency、Relational Termination Design、Layered Termination、Persistent Actor Lifecycle Graph（PALG）、Lifecycle Closure、Ghost Authority、Ghost Memory、Ghost Automation、Agent Sprawl** 為本系列提出的分析框架，並非 NIST、OECD、EU、OWASP 或 SpaceXAI 的官方術語。

本文引用 NIST AI RMF 與 2026 年 Agent Identity and Authorization 工作，是為了說明 AI lifecycle、decommissioning、authorization、revocation、auditing 與 identity lifecycle 已經成為實際治理議題；本文將這些元素整合成 Persistent Artificial Actor 的完整生命週期治理模型，屬本文自身理論延伸。