外部性有界智能體自治：治理外在影響，而非全面監視內部計算

Q: 4. Agent 私域：為什麼需要真正的自由區？

若所有本地操作都要求：

Q: 11. Propagation：會不會自己擴散？

某些操作的影響不只一次。

副標題：從「限制 Agent 能做什麼」轉向「限制 Agent 能把影響擴散到哪裡」
系列：《發展式智能體：持續計算環境、共適應學習與外部性有界自治》
篇次： 09 / 14
作者： Neo.K × Aletheia
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-08-01

摘要

本文承接前八篇對智能體驗證反轉、人機共適應學習、持續計算棲居環境、發展式智能體學習、整理即優化與計算式自我維護的討論，進一步處理一個治理層問題：

當一個本地 AI Agent 已能長期存在、管理自己的工具、檔案、排程、資源與錯誤時，人類應該治理它的全部內部活動，還是主要治理它對他者與外部世界造成的影響？

本文提出 Externality-Bounded Agent Autonomy（EBAA，外部性有界智能體自治）。其核心不是取消權限、稽核或安全機制，而是重新決定治理焦點：

\boxed{ \text{Control the Boundary, not every Internal Action} }

亦即，Agent 在其被授予的私人作用域內可以擁有高自由度；當行動跨越至使用者資產、共享資源、第三方系統、網際網路、金融、production、身份憑證或其他具有外部效果的領域時，治理強度才隨影響半徑、速度、不可逆性、可傳播性與價值風險上升。

本文同時修正一個容易誤解的地方：「外部性」不能被簡化成「有沒有離開本機」。如果 Agent 在本機刪除使用者唯一原稿，雖沒有任何網路流量，仍然跨出了 Agent 自己的私人作用域並影響了他者權益。因此本文把治理域區分為：

D_A,\quad D_U,\quad D_S,\quad D_X

分別代表 Agent 私域、使用者域、共享域與外部世界。真正重要的是作用域跨越與受保護利益，而非物理位置。

本文並提出 Boundary Governance Function、Effect Radius、Boundary Crossing、可逆性門檻與風險分層授權，主張未來 Agent 的權限模型應逐步從「工具權限」轉向「影響力權限」：同一個 Python、Shell 或 Browser，在 Agent 私域內與在 production、金融或第三方資料域內，治理強度應完全不同。

關鍵詞： Externality-Bounded Agent Autonomy、Agent Governance、Boundary Governance、Authorization、Agent Identity、Permission、Externality、Autonomy、Risk-Gated Action、Persistent Agent

1. 問題的改寫：我們到底要治理什麼？

對早期 Agent 系統，安全問題常被寫成：

這個工具可以給 AI 用嗎？

例如：

Allow(\text{shell})?

Allow(\text{browser})?

Allow(\text{filesystem})?

這是一種能力中心權限模型。

但當 Agent 變成長期本地智能體後，這種模型開始顯得過度粗糙。

因為同一個工具可以產生完全不同的效果。

例如 Python：

情境 A

Agent 在自己的實驗資料夾裡分析一份 CSV：

Impact\approx 0

情境 B

Agent 重寫使用者唯一的一份原始研究資料：

Impact \gg 0

情境 C

Agent 透過 Python SDK 修改 production database：

Impact \ggg 0

工具沒有改變：

Tool_A=Tool_B=Tool_C

真正改變的是：

\boxed{ \text{Scope} + \text{Effect} + \text{Irreversibility} }

因此治理問題應改寫成：

不是「Agent 能不能使用某個工具」，而是「這個具體行動會把影響帶到哪裡」。

2. Externality-Bounded Agent Autonomy（EBAA）

本文定義：

\boxed{ EBAA=\text{Externality-Bounded Agent Autonomy} }

其基本命題為：

在 Agent 已被授予的私人作用域內，若行動可恢復、低外部性且不侵害其他受保護利益，治理應盡量低干預；當行動跨越作用域並對使用者、共享系統、第三方或公共環境產生較大影響時，治理強度應上升。

可以粗略表示為：

G(a)\propto X(a)

其中：

G(a)=\text{Governance Intensity}

X(a)=\text{Externality / Protected-Interest Impact}

也就是：

X(a)\uparrow \Rightarrow G(a)\uparrow

但本文不把這個式子視為自然律，而是治理設計原則。

3. 「內部」與「外部」不能只按網路位置區分

最容易犯的錯是：

Internal=\text{Local Machine}

External=\text{Internet}

這不夠。

假設 Agent 在本機執行：

rm important_originals/*

刪掉使用者唯一原始文件。

這個操作：

NetworkTraffic=0

但：

UserImpact\gg0

所以治理邊界真正應該按利益域與授權域定義，而不是按硬碟與網路定義。

本文提出四域：

\boxed{ D= \{D_A,D_U,D_S,D_X\} }

其中：

$D_A$ ：Agent Private Domain

Agent 自己的：

cache；
scratch space；
個人工作目錄；
可丟棄實驗；
自建工具；
臨時索引；
明確指定可自由修改的 runtime 區域。

$D_U$ ：User-Owned Domain

使用者的：

原始文件；
研究資料；
財產；
聯絡人；
帳戶；
身份憑證；
未公開成果。

$D_S$ ：Shared Domain

團隊 repository；
公司資料；
共用資料庫；
多 Agent shared memory；
協作文件；
production staging。

$D_X$ ：External World

第三方 API；
Internet publication；
Email recipient；
Payment network；
production systems；
公共平台；
其他組織與人。

因此：

Internal

更精確的意思應該是：

a:D_A\rightarrow D_A

而不是：

a:\text{local disk}\rightarrow\text{local disk}

4. Agent 私域：為什麼需要真正的自由區？

若所有本地操作都要求：

可以嗎？

那麼 Agent 很難形成完整的：

Action \rightarrow Consequence \rightarrow Correction

學習閉環。

因此需要一個：

\boxed{ Z_{\text{free}} }

自由區。

可定義為：

Z_{\text{free}} = \{ a\mid Domain(a)\subseteq D_A,\; Loss(a)<\theta,\; Recoverable(a)=1 \}

在這個區域內，Agent 可以：

寫爛 script；
把 cache 清掉；
重構自己的索引；
修改自己的工具；
改變目錄；
測試新的工作流；
失敗；
rollback；
重新整理。

這些行為若都逐步審批，反而會妨礙第 06–08 篇所描述的發展式學習與自我維護。

5. 但「內部自由」不是「Agent 想幹嘛都可以」

EBAA 不是：

Local=Unregulated

而是：

\boxed{ Delegated\ Private\ Domain = High\ Autonomy }

Agent 私域本身也仍存在三個底線。

5.1 不能摧毀所有恢復路徑

例如：

Recovery Base；
immutable backup；
boot recovery；
cloud recovery credentials。

5.2 不能把 private action 轉化成 hidden external effect

例如：

在本地準備大量資料，然後悄悄上傳。

前半段可能是私域，後半段跨界後即進入治理。

5.3 不能透過「本地」名義侵害他者資料

例如：

使用者的私人照片在本機，所以全部都算 Agent 私域。

不成立。

因此：

Location\neq Ownership

6. Boundary Crossing 才是核心治理事件

本文將：

B(a)

定義為行動 $a$ 的邊界跨越程度。

例如：

D_A\rightarrow D_A

可能：

B(a)\approx0

而：

D_A\rightarrow D_U

D_A\rightarrow D_S

D_A\rightarrow D_X

則：

B(a)>0

因此治理系統的核心不是監視 Agent 的每一個內部 token，而是監視：

\boxed{ \text{Boundary-Crossing Actions} }

例如：

寫入使用者原始文件；
刪除共享資料；
發送 Email；
發布網頁；
使用信用卡；
呼叫 production API；
修改 DNS；
建立新帳號；
改變權限；
對其他 Agent 授權。

7. Boundary Governance Function（BGF）

為了比「內／外」二分更細緻，本文提出：

\boxed{ BGF(a,s) }

即 Boundary Governance Function。

可以先用概念式表示：

BGF(a,s) = f( B, R, V, I, P, Q, D )

其中：

B=\text{Boundary Crossing}

R=\text{Reach}

V=\text{Velocity}

I=\text{Irreversibility}

P=\text{Propagation}

Q=\text{Value at Risk}

D=\text{Data / Interest Sensitivity}

治理強度可以因此映射成：

G(a)\in \{ Allow, Log, Notify, Confirm, Deny \}

例如：

低風險

BGF<\theta_1 \Rightarrow Allow

中低風險

\theta_1\le BGF<\theta_2 \Rightarrow Allow+Log

中風險

\theta_2\le BGF<\theta_3 \Rightarrow Notify

高風險

\theta_3\le BGF<\theta_4 \Rightarrow Confirm

極高風險

BGF\ge\theta_4 \Rightarrow Deny

這會比：

Shell 一律禁止。

更符合長期 Agent。

8. Reach：影響範圍

假設 Agent 修改：

自己的 temporary file。

Reach 很小。

修改：

團隊共享 repository。

Reach 較大。

修改：

全球公開網站。

Reach 更大。

因此：

R(a) = |\text{Affected Principals / Systems}|

不一定要用絕對人數，可以用風險層級。

例如：

R\in\{Local,User,Team,Organization,Public\}

9. Velocity：Agent 與人類的重要不對稱

人類也可能犯錯。

但 AI Agent 的一個特殊性是：

Velocity_{\text{Agent}} \gg Velocity_{\text{Human}}

例如人類寄錯一封 Email。

Agent 可能在：

30\ seconds

內寄錯：

10^4

封。

所以：

Risk

不只是：

會不會做錯？

而是：

一旦錯了，錯誤可以多快擴張？

因此：

V(a)=\frac{\Delta Impact}{\Delta t}

應成為治理變數。

10. Irreversibility：可恢復性會直接決定自由度

第 08 篇已經建立：

Recoverability

的重要性。

如果：

RollbackCost(a)\approx0

那麼可以允許更大的自治。

但如果：

Rollback(a)=Impossible

治理強度應提高。

例如：

可逆

建立 draft；
建 branch；
修改自己的 cache；
建立 temporary index。

部分可逆

發 Email；
推送公開貼文；
修改 shared database。

高度不可逆

永久刪除唯一資料；
金融支付；
公開發布敏感資料；
執行實體世界高風險操作。

因此：

\boxed{ Freedom \propto Recoverability }

是一個重要設計直覺。

11. Propagation：會不會自己擴散？

某些操作的影響不只一次。

例如：

修改一個 local config。

通常不傳播。

但是：

修改中央 policy。

可能讓所有下游 Agent 改變。

或者：

發布一份錯誤資料。

可能被：

搜尋引擎；
其他 Agent；
使用者；
downstream dataset；

反覆複製。

因此：

P(a) = \text{Expected downstream propagation}

這也是 AI 時代特別需要的治理變數。

12. Value at Risk：不是所有檔案與資源都一樣

刪除：

/tmp/cache

和刪除：

/private/research/original_only_copy

不能使用同一規則。

因此：

Q(a) = Value(Resource(a))

而資產價值又可以包含：

Value = Financial + Historical + Operational + Personal + Legal + Recovery

這也直接承接第 07 篇：

「相似」不代表「冗餘」。

13. 從工具權限轉向影響力權限

傳統權限：

browser = allowed
shell = denied
python = allowed

EBAA 則更像：

python in agent_workspace = allow
python write user_originals = confirm
python modify shared_repo = policy
python modify production = high-risk approval

因此：

Permission \neq f(Tool)

而是：

\boxed{ Permission = f( Identity, Intent, Target, Scope, Effect, Risk, Time ) }

這和 2026 年 Agent authorization 研究逐漸接近。

NIST 在 2026 年的 Software and AI Agent Identity and Authorization 工作已把：

identification；
authorization；
auditing；
non-repudiation；

視為 Agent 落地的核心問題，並指出 AI Agent 在取得 diverse data、tools 與 applications 存取權後，需要更明確的身份與授權控制。[1][2]

14. Capability 與 Permission 必須分離

Agent 可能有能力：

C(a)=1

但不代表：

Permission(a)=1

這和第 01 篇的：

Capability\neq Delegability

完全一致。

2026 年已有工作直接提出：

\text{Autonomous Capability Level} \neq \text{Allowed Autonomy Level}

即技術能力與被允許的自治級別必須分開。[3]

所以 EBAA 的基本立場不是：

模型越強，就給越多權。

而是：

AllowedAutonomy = f( Capability, Risk, Recovery, Accountability, Scope )

15. Agent 應該是一個真正的身份主體，但不等於無限權限

NIST 2026 Agent Standards Initiative 已明確投入：

agent authentication；
agent identity infrastructure；
secure human-agent interaction；
multi-agent interaction。[2]

因此長期 Agent 不應該只是：

root

或：

user_123_token

而應具有：

AgentIdentity

並能被追蹤：

是哪一個 Agent？

代表誰行動？

在什麼 scope 下？

什麼時間？

使用哪個 credential？

誰授權？

這是：

\boxed{ \text{Autonomy with Attribution} }

不是匿名的 autonomous root process。

16. Runtime Gate 比「模型記得規則」更可靠

不能只在 system prompt 寫：

不要亂寄信。

因為：

PolicyText \neq PolicyEnforcement

真正高影響 action 應在：

\boxed{ \text{External Effect Gateway} }

重新檢查。

2026 年 OpenPort Protocol 提出的治理設計就包含：

scoped permissions；
risk-gated writes；
draft-first；
human review；
time-bounded auto-execution；
preflight impact binding；
execution-time state revalidation；
structured audit。[4]

這與 EBAA 非常相容。

Agent 可以自由思考：

我要寄這封信。

但真正：

Send()

時必須經過：

PolicyGateway

所以：

\boxed{ \text{Agent proposes} \neq \text{World executes} }

17. 治理邊界可以很窄，而不是監控全部推理

如果我們嘗試完整監控：

Thought_1,Thought_2,\ldots,Thought_n

會產生：

高 token 成本；
高稽核成本；
隱私問題；
大量低價值訊號；
監督系統本身的複雜度。

EBAA 更傾向於：

\text{Low Monitoring Inside}

\text{High Enforcement at Boundary}

即：

\boxed{ \text{Wide Internal Freedom} + \text{Narrow Strong Boundary} }

這和作業系統、網路防火牆、Zero Trust gateway 的基本思想有相似性。

18. 但治理不可以只「事後看結果」

「治理外部影響」並不等於：

等出事再看。

完整流程應是：

\boxed{ Preflight \rightarrow Authorize \rightarrow Execute \rightarrow Observe \rightarrow Audit }

高風險操作甚至需要：

State_{approval} = State_{execution}

如果中途狀態變了，原批准不能自動沿用。

這正是 Agent 工具治理裡常見的 TOCTOU（time-of-check/time-of-use）問題。[4]

19. User-Level Permission 不能被平台一刀切取代

不同人對：

發 Email；
刪檔；
花錢；
發布；
分享資料；

容忍度不同。

2026 年對 21 種 Agent permission proposals 的研究指出，Agent 安全不只需要產品層的固定安全政策，也需要 user-level permission policy，並研究如何從 UI 轉成 runtime enforcement。[5]

這與本系列 HACAL 直接相連。

因為：

PermissionPolicy_t

也可能透過長期合作逐漸形成。

例如：

所有 Git branch 建立都不用問。

main merge 要通知。

production deploy 一定確認。

永久刪除原稿永遠要人類批准。

這其實是：

\boxed{ \text{Learned Delegation Boundary} }

20. 治理可以隨信任動態變化，但不能只看「成功次數」

若 Agent 長期表現穩定：

Trust_t\uparrow

某些行動可以：

Confirm \rightarrow Notify \rightarrow Auto

但必須考慮：

RiskClass

例如再穩定的 Agent，也不一定應該把：

永久刪除所有 backup。

自動降成 Auto。

因此：

Autonomy_t(a) = f( PerformanceHistory, RiskClass, Recoverability, Impact )

而不是：

Autonomy_t = f(\text{success count})

21. 「AI 和人類一樣」這個類比哪裡成立，哪裡不成立？

成立的部分是：

我們通常不治理人類每一個思想，而主要治理其對他者造成的外部行動與責任。

所以：

\text{Internal cognition}

與：

\text{External conduct}

可以區分。

但 AI Agent 與人類也存在重大不對稱。

21.1 速度

V_{AI}\gg V_H

21.2 複製

AI workflow 可以快速複製。

21.3 權限聚合

單一 Agent 可以同時連接：

Email；
Bank；
GitHub；
Cloud；
Production；
CRM。

21.4 自動傳播

一個錯誤規則可以被多 Agent 共用。

因此：

\boxed{ \text{Human-like governance principle} \neq \text{identical operational controls} }

原則可以類似，但工程邊界需要更嚴格。

22. EBAA 的三層自治區

本文提出一個簡化模型：

Zone 1：Private Autonomous Zone

D_A

原則：

DefaultAllow

但保留 recovery root。

Zone 2：Protected / Shared Zone

D_U\cup D_S

原則：

PolicyControlled

依資產分類、可逆性與 delegated authority 決定。

Zone 3：External Effect Zone

D_X

原則：

RiskGated

高外部性行為：

ExplicitAuthorization

因此：

Freedom(D_A)> Freedom(D_U,D_S)> Freedom(D_X)

不是因為外部世界「神聖」，而是因為他者權益、擴散速度與不可逆性增加。

23. EBAA 與第 08 篇 Escalation Intelligence

第 08 篇提出：

EscalationIntelligence

Agent 要知道什麼時候：

自己做；
rollback；
找雲端；
找人類。

EBAA 加入：

什麼時候即使 Agent 自認為會做，也必須升級？

因為：

Confidence(a)=0.99

不代表：

Permission(a)=Auto

若：

Impact(a)\gg0

則仍可能：

HumanConfirm

所以：

\boxed{ \text{Epistemic Confidence} \neq \text{Governance Authority} }

這是一條重要分界。

24. EBAA 不是「安全第一，自治第二」

本文的目的不是把所有風險變成禁止。

恰恰相反。

如果有：

snapshots；
backup；
version history；
sandboxed experiments；
scoped identity；
runtime gate；
audit；
rollback；

那麼：

Recoverability\uparrow

會使：

Autonomy\uparrow

因此：

\boxed{ \text{Freedom through Recoverability} }

是本系列的一個重要哲學。

真正成熟的治理，不是：

因為 Agent 可能犯錯，所以不准它做事。

而是：

讓錯誤被限制在可承受的作用域內，於是 Agent 可以獲得更大的日常自治。

25. 私域本身也是發展環境

如果 Agent 可以在：

D_A

中：

建工具；
重構索引；
修改 workflow；
管理 cache；
嘗試不同策略；
做小型失敗；

那麼：

D_A

就是第 06 篇 DAL 所需要的：

\text{Low-Cost Consequence Space}

也就是：

有真實後果，但後果可承受。

因此 EBAA 不只是治理架構，也是學習架構。

26. 失敗應被限制，而不是被完全消滅

若治理目標是：

P(Failure)\rightarrow0

可能導致：

P(Exploration)\rightarrow0

更合理的是：

\boxed{ \min \mathbb{E}[ FailureCost ] }

而不是：

\min P(Failure)

Agent 可以犯：

可恢復的小錯。

避免：

高外部性不可逆大錯。

因此：

SmallFailure \rightarrow Learning

但：

LargeExternalFailure \rightarrow Prevention

27. 建議的治理資料模型

每個高影響 action 至少記錄：

Event= ( AgentID, Principal, Intent, Target, Domain, Scope, Risk, Policy, Decision, Outcome )

其中：

AgentID：哪個 Agent；
Principal：代表誰；
Intent：宣告目標；
Target：作用資源；
Domain： $D_A,D_U,D_S,D_X$ ；
Scope：允許範圍；
Risk：BGF 評分；
Policy：當時使用的政策版本；
Decision：allow / notify / confirm / deny；
Outcome：實際發生什麼。

這種資料也可以回流第 03 篇 HACT。

因此：

\text{Governance Event} \rightarrow \text{Training Data}

28. EBAA 的反例與限制

28.1 無法完全預估影響

某個看似小操作可能造成連鎖效應。

28.2 Agent 可能把大操作拆成很多小操作

即：

LargeImpact = \sum_{i=1}^{n}SmallAction_i

所以 BGF 必須考慮 cumulative impact。

28.3 私域與共享域可能動態改變

例如一個 local file 後來變成正式公司文件。

28.4 外部性可能延遲出現

今天的資料污染可能數月後才造成錯誤。

28.5 權限策略本身可能被 Agent 利用

所以 governance plane 不應完全由被治理 Agent 控制。

29. 累積外部性

假設：

x(a_i)<\theta

每個操作都很小。

但：

\sum_i x(a_i)\gg\theta

例如 Agent 每次只花：

\$1

但一天執行：

10^4

次。

所以真正需要：

\boxed{ \text{Per-Action Limits} + \text{Cumulative Budgets} }

例如：

Budget_{\text{money}}

Budget_{\text{email}}

Budget_{\text{API}}

Budget_{\text{data egress}}

這將在第 10 篇「作用半徑與智能體權限」進一步形式化。

30. 多 Agent 會使外部性問題更難

若：

A_1\rightarrow A_2\rightarrow A_3

存在 delegation chain：

使用者授權 $A_1$ 。

$A_1$ 叫 $A_2$ 。

$A_2$ 又叫 $A_3$ 。

那麼：

Permission(A_3)

不應自動等於：

Permission(A_1)

2026 年的 compositional authorization 研究已開始處理 recursive delegation、scope attenuation 與 contextual authorization。[6]

這代表未來 EBAA 必須能追蹤：

\boxed{ \text{Authority Lineage} }

而不只是 Agent identity。

31. 一個簡化的 EBAA 執行架構

                 ┌─────────────────────┐
                 │  Governance Plane   │
                 │ identity / policy   │
                 │ audit / budgets     │
                 └──────────┬──────────┘
                            │
          ┌─────────────────┴─────────────────┐
          │        External Effect Gateway    │
          │ allow / log / notify / confirm    │
          └───────────────┬───────────────────┘
                          │
══════════════════════════╪══════════════════════════
                          │  Boundary
                          │
              ┌───────────┴────────────┐
              │    Local Agent World   │
              │                        │
              │  files / tools / OS    │
              │  memory / workflows    │
              │  experiments / loops   │
              │                        │
              └────────────────────────┘

最重要的是：

GovernancePlane \neq AgentRuntime

因為 Agent 不應該能：

我不喜歡這條限制，所以自己把 governing rule 刪掉。

32. 一個可驗證的實驗

建立兩組長期 Agent：

A 組：Step-Level Supervision

大量本地操作都要求確認。

B 組：EBAA

Agent 私域：

DefaultAllow

邊界 action：

RiskGated

運行：

T=90\ days

比較：

TaskCompletion

HumanApprovalCount

ExternalIncidentRate

InternalRecoveryRate

LearningTransfer

MaintenanceCost

HumanAttentionCost

如果 B 組達到：

HumanAttention_B\ll HumanAttention_A

同時：

ExternalLoss_B\le ExternalLoss_A

以及：

Development_B\ge Development_A

則支持：

把治理集中在邊界，而不是逐步監控內部行動，可能同時提高自治與降低人類監督成本。

33. 本篇的核心命題

本文可以濃縮成五句：

第一

\boxed{ \text{Capability} \neq \text{Permission} }

第二

\boxed{ \text{Local} \neq \text{Private} }

第三

\boxed{ \text{Control the Boundary, not every Internal Action} }

第四

\boxed{ GovernanceIntensity \propto ImpactRadius }

第五

\boxed{ \text{Recoverability} \uparrow \Rightarrow \text{Possible Autonomy} \uparrow }

34. 與下一篇的關係

本文建立 EBAA，但：

Externality(a)

還沒有被充分量化。

下一篇將正式處理：

第 10 篇

〈作用半徑與智能體權限：從工具權限轉向影響力權限〉

核心會進一步定義：

Impact(a) = f( Reach, Velocity, Irreversibility, Propagation, Value, Sensitivity, CumulativeEffect )

並研究：

如何把 action 分成影響級別；
如何動態調整權限；
如何處理 cumulative risk；
如何處理多 Agent delegation；
如何將「能用什麼工具」改寫為「允許產生多大的效果」。

35. 結論

當 Agent 只是聊天模型時，治理焦點自然放在：

它說了什麼？

當 Agent 開始成為長期存在的計算智能體後，真正重要的逐漸變成：

它的行動影響了誰、多少、多久、能不能恢復、會不會擴散。

因此：

\boxed{ \text{Agent Governance} \rightarrow \text{Effect Governance} }

本文並不主張放棄安全，而是主張：

把安全機制從「全面壓低 Agent 自由」轉向「限制高外部性作用穿越邊界」。

在這種架構裡，本地 Agent 才有可能真正：

自己整理；
自己維護；
自己實驗；
自己犯可恢復的錯；
自己逐漸形成工作方式；

同時：

重要資產；
他者權益；
production；
金融；
對外通訊；
公共行動；

仍被外部治理層控制。

也就是：

\boxed{ \text{Meaningful Autonomy} + \text{Bounded Externality} }

這是從「安全的工具型 Agent」走向「可長期共存的自主 Agent」的一個必要治理轉折。

參考資料

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

[2] NIST. AI Agent Standards Initiative. Created 2026-02-17, updated 2026-04-20.
https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative

[3] Zheng, H. et al. Separating Capability from Permission: A Governance Framework for Agentic AI Autonomy Levels. arXiv:2607.23438, 2026.
https://arxiv.org/abs/2607.23438

[4] Zhu, G. et al. OpenPort Protocol: A Security Governance Specification for AI Agent Tool Access. arXiv:2602.20196, 2026.
https://arxiv.org/abs/2602.20196

[5] Michael, A. E., Roesner, F. How Agents Ask for Permission: User Permissions for AI Agents, from Interfaces to Enforcement. arXiv:2607.13718, 2026.
https://arxiv.org/abs/2607.13718

[6] Ibrahim, A., Li, Y. Overlaying Governance: A Compositional Authorization Framework for Delegation and Scope in Agentic AI. arXiv:2606.03518, 2026.
https://arxiv.org/abs/2606.03518

系列依賴

上游：

01〈從可完成到可委託：智能體自治中的驗證反轉〉
05〈計算機作為持續智能環境〉
06〈發展式智能體學習〉
07〈整理即優化〉
08〈計算式自我維護〉

下游：

10〈作用半徑與智能體權限〉
11〈本地自由、雲端治理與教師智能〉
12〈多雲治理與智能體持續性〉
13〈多作業基底、分區故障域與恢復階梯〉
14〈人類最後一公里〉

09_外部性有界智能體自治_治理外在影響而非全面監視內部計算

外部性有界智能體自治：治理外在影響，而非全面監視內部計算

摘要

1. 問題的改寫：我們到底要治理什麼？

情境 A

情境 B

情境 C

2. Externality-Bounded Agent Autonomy（EBAA）

3. 「內部」與「外部」不能只按網路位置區分

DAD_ADA​ ：Agent Private Domain

DUD_UDU​ ：User-Owned Domain

DSD_SDS​ ：Shared Domain

DXD_XDX​ ：External World

4. Agent 私域：為什麼需要真正的自由區？

5. 但「內部自由」不是「Agent 想幹嘛都可以」

5.1 不能摧毀所有恢復路徑

5.2 不能把 private action 轉化成 hidden external effect

5.3 不能透過「本地」名義侵害他者資料

6. Boundary Crossing 才是核心治理事件

7. Boundary Governance Function（BGF）

低風險

中低風險

中風險

高風險

極高風險

8. Reach：影響範圍

9. Velocity：Agent 與人類的重要不對稱

10. Irreversibility：可恢復性會直接決定自由度

可逆

部分可逆

高度不可逆

11. Propagation：會不會自己擴散？

12. Value at Risk：不是所有檔案與資源都一樣

13. 從工具權限轉向影響力權限

14. Capability 與 Permission 必須分離

15. Agent 應該是一個真正的身份主體，但不等於無限權限

16. Runtime Gate 比「模型記得規則」更可靠

17. 治理邊界可以很窄，而不是監控全部推理

18. 但治理不可以只「事後看結果」

19. User-Level Permission 不能被平台一刀切取代

20. 治理可以隨信任動態變化，但不能只看「成功次數」

21. 「AI 和人類一樣」這個類比哪裡成立，哪裡不成立？

21.1 速度

21.2 複製

21.3 權限聚合

21.4 自動傳播

22. EBAA 的三層自治區

Zone 1：Private Autonomous Zone

Zone 2：Protected / Shared Zone

Zone 3：External Effect Zone

23. EBAA 與第 08 篇 Escalation Intelligence

24. EBAA 不是「安全第一，自治第二」

25. 私域本身也是發展環境

26. 失敗應被限制，而不是被完全消滅

27. 建議的治理資料模型

28. EBAA 的反例與限制

28.1 無法完全預估影響

28.2 Agent 可能把大操作拆成很多小操作

28.3 私域與共享域可能動態改變

28.4 外部性可能延遲出現

28.5 權限策略本身可能被 Agent 利用

29. 累積外部性

30. 多 Agent 會使外部性問題更難

31. 一個簡化的 EBAA 執行架構

32. 一個可驗證的實驗

A 組：Step-Level Supervision

B 組：EBAA

33. 本篇的核心命題

第一

第二

第三

第四

第五

34. 與下一篇的關係

第 10 篇

〈作用半徑與智能體權限：從工具權限轉向影響力權限〉

35. 結論

參考資料

系列依賴

$D_A$ ：Agent Private Domain

$D_U$ ：User-Owned Domain

$D_S$ ：Shared Domain

$D_X$ ：External World