本地自由、雲端治理與教師智能：從遠端控制走向認知分工

Q: 1. 為什麼「雲端控制本地」這個說法不夠準確？

在傳統雲端架構裡，很容易形成：

Q: 21. 雲端教師應該教什麼？

Teacher 最有價值的不是：

副標題：把雲端從「控制本地 Agent 的上級」重構為治理、救援與高階認知資源
系列：《發展式智能體：持續計算環境、共適應學習與外部性有界自治》
篇次： 11 / 14
作者： Neo.K × Aletheia
機構： EveMissLab／一言諾科技有限公司
版本： v0.1
日期： 2026-08-02

摘要

本文承接第 09 篇「外部性有界智能體自治（EBAA）」與第 10 篇「影響力導向授權（IOA）」的治理框架，進一步處理本地智能體與雲端系統的角色分工。

核心命題是：

雲端不應被預設為本地 Agent 的主人；更合理的架構是，本地 Agent 作為主要持續活動與成長場，雲端則提供治理、救援、高算力與教師型認知。

本文提出 Local–Cloud Cognitive Division（LCCD，本地—雲端認知分工），將系統拆分為四個主要角色：

\boxed{ L + G + T + R }

其中：

$L$ ：Local Developmental Agent，本地發展式智能體；
$G$ ：Cloud Governance Plane，雲端治理平面；
$T$ ：Cloud Teacher / Critic，雲端教師／審稿／第二意見智能；
$R$ ：Cloud Recovery Plane，雲端恢復與備援平面。

本地端承擔：

高頻持續性；
本地狀態感知；
檔案與工具環境；
私人記憶；
排程與自我維護；
即時低延遲行動。

雲端則承擔：

身份與授權治理；
policy enforcement；
audit；
高階推理；
跨模型比較；
專家型評估；
高成本工作；
故障復原；
多雲備援。

本文進一步提出 Cognitive Escalation Policy（CEP）：本地 Agent 應根據不確定性、任務難度、外部性、成本、延遲、隱私與可恢復性決定是否將問題升級至雲端。

因此：

\boxed{ \text{Local-first} \neq \text{Local-only} }

而：

\boxed{ \text{Cloud-assist} \neq \text{Cloud-rule} }

本文主張，本地 AI 與雲端大型模型之間不應被建模為單純的主從關係，而應形成一個「持續性—高峰能力」的異質協作系統。

關鍵詞： Local–Cloud Cognitive Division、Developmental Agent、Cloud Governance、Teacher Agent、Critic Model、Escalation、Edge Agent、Hybrid AI、Model Routing、Agent Recovery

1. 為什麼「雲端控制本地」這個說法不夠準確？

在傳統雲端架構裡，很容易形成：

Cloud \rightarrow Device

即：

雲端決策，本地只是執行。

但若本地 Agent 已經具有：

Persistent Computer Habitat；
長期記憶；
自己的工具；
自己的排程；
自己的工作史；
自己的使用者關係；
自己的本地環境模型；

那麼：

LocalAgent

就不是一個薄 client。

它更接近：

\boxed{ \text{Primary Continuity Layer} }

即「主要持續性層」。

本地 Agent 的優勢不是一定比雲端模型更聰明，而是：

它離自己的世界比較近。

2. 本地 Agent 的核心資產不是模型參數，而是「連續性」

假設：

\theta_L

是本地模型。

即使：

Capability(\theta_L) < Capability(\theta_C)

其中 $\theta_C$ 是雲端大型模型，也不代表本地 Agent 的系統價值較低。

因為本地 Agent 擁有：

S_L= ( Filesystem, Runtime, History, Memory, Tools, Preferences, Schedules )

而雲端模型通常只在某次呼叫時取得：

\hat S_L

即經過摘要、上傳、檢索或轉譯後的局部狀態。

因此：

\hat S_L\neq S_L

這個差異很重要。

2026 年 edge-agent 研究已指出，本地檔案層次、瞬時 OS 狀態與高保真互動訊號，在被整理成雲端可傳輸內容後可能失去脈絡或成本過高。

因此：

\boxed{ \text{Local Agent} = \text{High-Fidelity Situated Context} }

3. Cloud 的第一個角色：Governance，而不是 Personality

雲端最重要的第一個角色，不一定是：

更大的聊天模型。

而是：

\boxed{ G=\text{Governance Plane} }

負責：

Agent identity；
permission envelope；
action budget；
cumulative effect ledger；
policy version；
audit；
revoke；
external effect gateway；
emergency stop。

也就是第 09、10 篇所建立的治理元件。

現行 Windows 365 for Agents 已把 agent identity、device compliance、Zero Trust、audit 與安全控制集中到外部治理平面；Cloud PC 本身則是 Agent 的執行環境。

這提供一個重要結構：

\boxed{ \text{Execution Plane} \neq \text{Governance Plane} }

4. 為什麼治理平面不應完全放在本地 Agent 內？

如果：

Agent = PolicyAuthority = PolicyEditor

那麼會出現：

被治理者可以直接改掉治理規則。

例如：

policy.delete("production-confirmation")

所以：

P_{\text{Agent}} < P_{\text{Governance}}

至少在：

recovery root；
identity root；
policy root；
audit root；

上必須成立。

這不表示雲端「統治」Agent。

比較像：

作業系統中的 kernel boundary。

或者：

公司中的審計與付款權限。

5. Cloud 的第二個角色：Teacher / Critic

本地 Agent 不需要在所有任務上都是最強模型。

更合理的是：

\boxed{ \text{Local Continuity} + \text{Cloud Peak Intelligence} }

本地模型可以處理：

日常整理；
文件查找；
排程；
小型 coding；
本地狀態監控；
基本決策；
重複性工作。

但遇到：

高難度數學；
大型架構重設計；
法律／合規判斷；
高風險 production change；
長上下文 cross-check；
多方案比較；

可以呼叫：

T_C

即 Cloud Teacher / Critic。

6. 「老師」不等於「主人」

Teacher 的角色可以是：

\boxed{ Advice + Critique + Alternative + Verification }

而不是：

Command

例如本地 Agent：

我準備重構記憶索引。

雲端教師：

你的方案有三個風險；建議先建立 shadow index，再做 A/B 查詢。

最後：

Decision

仍可能由本地 Agent 在授權範圍內執行。

因此：

\boxed{ TeacherAuthority \neq ExecutionAuthority }

這是一個非常重要的分離。

7. 雲端教師可以有多種角色

不是只有一個「大模型老師」。

可以區分：

7.1 Critic

找問題。

Critic(x)\rightarrow RiskList

7.2 Reviewer

檢查：

correctness；
consistency；
policy compliance。

7.3 Specialist

提供：

數學；
程式；
法律； -醫療之外的專門領域知識；
系統工程；

等專家能力。

7.4 Adversarial Reviewer

刻意找：

failure mode；
exploit；
hidden assumption。

7.5 Planner

對大型任務提供高階 decomposition。

因此：

\boxed{ CloudTeacher = RolePool }

而不是單一人格。

8. 本地模型越小，反而越需要好的 escalation

這裡可以形成一個很重要的設計哲學。

本地模型不一定要追求：

MaxCapability

而可以追求：

\boxed{ SufficientCapability + ExcellentEscalation }

也就是：

我不一定什麼都會，但我要知道什麼時候不該自己硬做。

2026 年 local-to-cloud routing 研究已顯示，可以利用小模型自我信心與 task difficulty 決定何時把問題升級給更強模型。

因此：

\text{Weakness Detection}

本身就是能力。

9. Cognitive Escalation Policy（CEP）

本文提出：

\boxed{ CEP=\text{Cognitive Escalation Policy} }

決定：

Local \rightarrow Cloud

的條件。

可以寫成：

E_t = f( U, D, X, C, L, P, R )

其中：

$U$ ：Uncertainty；
$D$ ：Difficulty；
$X$ ：Externality；
$C$ ：Cloud Cost；
$L$ ：Latency；
$P$ ：Privacy Sensitivity；
$R$ ：Recoverability。

若：

E_t>\theta

則：

Escalate

10. 並不是「越難越丟雲端」

因為某些任務：

Difficulty=High

但：

Privacy=VeryHigh

例如：

私人未公開研究資料。

此時可能應該：

本地慢慢做；
先脫敏；
只傳抽象問題；
呼叫本地較大模型；
使用可信雲。

所以：

\boxed{ Escalation \neq DifficultyOnly }

11. Local → Cloud 可以有多種資訊粒度

Level 0：不傳資料

只問一般知識。

Level 1：抽象問題

例如：

如何重構一個大型版本圖？

而不傳原始文件。

Level 2：摘要／特徵

傳：

schema；
metadata；
statistics。

Level 3：局部證據

只傳必要片段。

Level 4：完整上下文

只在：

明確授權；
合適隱私政策；
必要性高；

時使用。

因此：

\boxed{ CloudHelp \neq UploadEverything }

12. Cognitive Data Minimization

本文提出：

\boxed{ CDM=\text{Cognitive Data Minimization} }

也就是：

為了取得雲端認知能力，只傳完成推理所需的最小資訊。

可寫成：

\min |D_{\text{upload}}|

subject to：

Quality(T_C,D_{\text{upload}}) \ge q_0

這會成為私人 Agent 非常重要的能力。

13. 雲端可以比本地更「聰明」，但不一定比本地更「了解」

這是一個重要區分。

令：

I_C=\text{Cloud Intelligence}

C_L=\text{Local Context Fidelity}

可能：

I_C>I_L

但：

C_L>C_C

因此：

BestDecision

不一定等於：

CloudOnly

而可能是：

\boxed{ LocalContext + CloudReasoning }

這正是 hybrid cognition 的價值。

14. Edge–Cloud Collaboration 已經出現實際研究基礎

2026 年已有研究主張個人 Agent 的主要 control loop 應逐漸移到 edge，因為本地狀態、低延遲與互動偏好是 agentic intelligence 的核心。

同時，edge-cloud collaborative inference 已開始探索：

本地預處理；
雲端重推理；
privacy-aware split；
authenticated state；
heterogeneous device support。

這說明：

\boxed{ \text{Local vs Cloud} }

並不是二選一。

真正方向是：

\boxed{ \text{Local + Cloud Specialization} }

15. Model Routing 本身就是認知資源管理

假設可用模型集合：

M= \{m_1,m_2,\ldots,m_n\}

每個模型具有：

Capability_i

Cost_i

Latency_i

Privacy_i

Specialty_i

則：

Route(q) = \arg\min_i Cost_i

subject to：

ExpectedQuality_i(q)\ge q_0

以及治理限制。

Adaptive VLM Routing 研究已顯示，Computer-Use Agent 可以先用較小模型，在低信心或高風險 action 才升級至較強模型，並大幅降低預估推理成本。

所以：

\boxed{ \text{Routing Skill} }

本身會成為 Agent 的一種元能力。

16. Cloud 的第三個角色：Recovery

如果本地 Agent：

OS 壞掉；
memory DB 損壞；
boot failure；
index corruption；
recovery zone 失效；

本地認知能力可能：

LocalCapability\rightarrow0

所以必須存在：

\boxed{ R_C=\text{Cloud Recovery Plane} }

保存：

snapshots；
manifests；
critical memories；
recovery scripts；
golden images；
human-readable instructions。

這會在第 12–14 篇正式展開。

17. Cloud Governance 與 Cloud Teacher 不應該是同一角色

這是一個非常重要的結構分離。

假設同一個模型：

提議方案。

又同時：

決定這個方案是否被允許。

會產生：

ConflictOfRole

更合理：

\boxed{ Planner \neq Reviewer \neq PolicyAuthority }

例如：

LocalAgent \rightarrow CloudTeacher \rightarrow Proposal

再：

Proposal \rightarrow GovernancePlane

決定是否可執行。

18. Cloud Governance 可以不是 LLM

這點也非常重要。

有些政策：

每日最多花 50 美元。

根本不需要：

LLM

判斷。

應直接：

if spend > 50: deny

所以：

\boxed{ Governance = DeterministicRules + RiskModels + OptionalLLMJudges }

而不是：

Governance=AnotherLLM

這可以降低：

token 成本；
policy ambiguity；
judge inconsistency。

19. LLM Judge 適合判斷什麼？

適合：

intent mismatch；
semantic risk；
unusual tool chain；
policy edge cases；
complex content review。

不適合：

exact budget；
version；
rate limit；
role membership；
cryptographic authorization。

所以：

\boxed{ SemanticJudgment\rightarrow LLM }

\boxed{ DeterministicConstraint\rightarrow Code }

這是重要分工。

20. 兩階段治理可以兼顧成本與品質

2026 年 layered agent governance 研究已測試：

LocalJudge \rightarrow CloudJudge

的 cascade。

較便宜本地 judge 先處理大部分情況。

遇到：

ambiguity；
high risk；
low confidence；

再：

Escalate\rightarrow CloudJudge

這和本文 CEP 的治理版本一致：

\boxed{ LocalFilter \rightarrow CloudReview }

而不是所有 action 都呼叫大型雲端模型。

21. 雲端教師應該教什麼？

Teacher 最有價值的不是：

替本地 Agent 把所有事情做完。

而是產生：

\boxed{ Reusable\ Improvement }

例如：

這次你錯在沒有確認 canonical source。

本地 Agent 可以把它編譯成：

before_delete:
    check canonical

所以：

CloudAdvice_t \rightarrow LocalPolicy_{t+1}

這樣才形成真正的「教學」。

22. Teacher Distillation without Weight Update

即使不修改本地模型權重，也可以把教師輸出蒸餾成：

rule；
checklist；
skill；
tool；
memory；
workflow；
policy。

因此：

\boxed{ TeacherKnowledge \rightarrow RuntimeStructure }

而不必：

TeacherKnowledge \rightarrow FineTuneWeights

這和第 06 篇 DAL 完全一致。

23. 雲端教師不應該永遠替本地決策

如果每次：

DifficultTask \rightarrow Cloud

而本地只照做，則可能：

LocalDevelopment\downarrow

所以需要：

\boxed{ Scaffolding }

例如：

初期

Cloud 給完整方案。

中期

Cloud 只給 critique。

後期

Cloud 只在 failure / uncertainty 時介入。

因此：

TeacherIntervention_t\downarrow

若：

LocalCapability_t\uparrow

這比較接近「養成」。

24. Teacher Dependency 是一種新風險

如果：

P(CloudAvailable)=0

本地 Agent 就：

Capability\rightarrow0

那麼它其實沒有形成真正的自治。

本文把這稱為：

\boxed{ TeacherDependency }

可以測量：

TD= \frac{ TasksRequiringCloud }{ TotalTasks }

長期希望：

TD_{\text{routine}}\downarrow

但不一定要求：

TD_{\text{frontier}}\rightarrow0

因為高階問題永遠可以利用更強資源。

25. Cloud Assistance 應該是可替換的

如果本地 Agent 的全部：

memory；
policy；
recovery；
routing；

都綁死某一個雲端供應商，則：

VendorDependency\gg0

所以應盡量抽象成：

\boxed{ CloudProvider \in \{C_1,C_2,\ldots,C_n\} }

這會直接引出第 12 篇的：

\text{Multi-Cloud Governance}

26. 本地 Agent 也可以同時問多個雲端

對高風險問題：

T_1,T_2,T_3

可以各自：

提議；
critique；
verify。

然後：

Consensus

或：

Dissent

本身成為風險訊號。

例如：

Agreement(T_1,T_2,T_3)<\theta

則：

HumanEscalation

這使：

\boxed{ Model Disagreement }

變成治理訊號。

27. 雲端並不一定永遠比較可信

Cloud 也可能：

hallucinate；
outage；
provider compromise；
policy error；
stale model；
context misunderstanding。

所以：

\boxed{ Cloud \neq Oracle }

必須有：

provenance；
model identity；
response timestamp；
confidence；
cross-provider verification。

28. 本地與雲端之間需要「可理解的協議」

Agent 呼叫雲端時，最好不是把整個腦袋 dump 出去。

而是建立：

EscalationPacket

例如：

EP= ( Question, ContextSummary, Evidence, Constraints, Risk, RequestedRole )

其中：

RequestedRole = critic

或：

RequestedRole = planner

這樣雲端知道：

我不是來接管任務，而是來做某種有限角色。

29. Escalation Packet 也是資料最小化機制

例如：

Task:
  Review proposed file migration.

Evidence:
  3 manifests
  2 dependency graphs

Do not need:
  user private messages
  unrelated files

Role:
  critic

Output:
  risks + alternatives

這比：

把整顆硬碟上傳。

合理得多。

30. Local Agent 應保留最終環境語義

即使 Cloud Teacher 建議：

刪掉這 100 個重複檔。

本地 Agent 仍可能知道：

其中三個是歷史節點。

因為：

ContextLocal > ContextCloud

所以：

\boxed{ CloudReasoning + LocalSemanticAuthority }

可能是較好的組合。

31. 但高外部性操作的治理權可以仍在外部

要區分：

SemanticAuthority

和：

GovernanceAuthority

本地 Agent 可以最了解：

這個檔案代表什麼。

但不表示它能：

無限制把資料發到外部。

因此：

\boxed{ LocalSemanticAuthority \neq UnlimitedExternalAuthority }

32. 三層決策模型

本文可以把整體決策分成：

Layer A：Local Cognition

What\ should\ I\ do?

Layer B：Cloud Cognitive Assistance

Is\ there\ a\ better\ way?

Layer C：Governance

Am\ I\ allowed\ to\ cause\ this\ effect?

所以：

\boxed{ Plan \neq Advice \neq Authorization }

33. 一個簡化架構

                      Multi-Cloud
        ┌─────────────────────────────────┐
        │                                 │
        │  Teacher / Critic / Specialist  │
        │                                 │
        │  Governance / Identity / Audit  │
        │                                 │
        │  Backup / Recovery              │
        │                                 │
        └───────────────┬─────────────────┘
                        │
                Escalation Gateway
                        │
════════════════════════╪════════════════════════
                        │
              Local Developmental Agent
        ┌───────────────┴─────────────────┐
        │                                 │
        │  persistent memory              │
        │  files / tools / OS             │
        │  schedules / workflows          │
        │  local model                    │
        │  self-maintenance               │
        │                                 │
        └─────────────────────────────────┘

核心是：

\boxed{ \text{Local is home;} \quad \text{Cloud is infrastructure and cognition.} }

34. 一個可測試的對照實驗

建立三組：

A：Cloud-Centric Agent

所有 reasoning 都在雲端。

B：Local-Only Agent

全部本地。

C：LCCD Hybrid Agent

本地：

memory；
continuity；
routine action；

雲端：

teacher；
high-compute；
governance；
recovery。

運行：

T=90\ days

比較：

Cost

Latency

PrivacyExposure

TaskSuccess

HumanIntervention

CloudDependency

LocalTransferLearning

RecoverySuccess

如果 C 組能：

Cost_C<Cost_A

PrivacyExposure_C<PrivacyExposure_A

同時：

TaskSuccess_C>TaskSuccess_B

則支持：

\boxed{ \text{Local–Cloud Cognitive Division} }

35. 發展式指標：雲端介入是否逐漸改變？

可以進一步測：

CloudCallRate_t

若：

RoutineCloudCallRate_t\downarrow

但：

FrontierCloudCallRate_t

保持合理，代表本地 Agent 可能正在：

把以前需要老師的日常能力逐漸內化。

這是一個非常實際的 developmental signal。

36. 與下一篇的關係

本文仍假設：

Cloud

是單一抽象資源。

但如果：

單一雲故障；
帳戶被停；
provider policy 改變；
data corruption；
backup 被同步刪除；

本地 Agent 的持續性仍可能受到威脅。

因此下一篇：

第 12 篇

〈多雲治理與智能體持續性：同步、非同步、版本化與故障域分離〉

將正式處理：

\boxed{ Cloud_1 + Cloud_2 + Cloud_3 }

如何分工成：

hot sync；
versioned backup；
cold immutable archive；
independent teacher；
governance witness；

並避免：

LocalError \rightarrow AllCloudsCorrupted

37. 結論

本文的核心不是：

雲端比較強，所以本地 AI 聽雲端的。

而是：

\boxed{ \text{Different layers are good at different things.} }

本地：

\boxed{ Continuity + Context + Privacy + LowLatency + Development }

雲端：

\boxed{ Governance + PeakReasoning + Specialization + Recovery + CrossCheck }

因此：

\boxed{ Local-first + Cloud-assisted + Externally-governed }

可能是一種更適合私人長期智能體的架構。

真正成熟的私人 Agent，不應該因為雲端斷線就「失去自己」，也不應該因為本地模型較小就拒絕使用更大的外部智能。

它需要的是：

知道什麼必須留在本地、什麼值得詢問雲端、什麼只能由治理層批准，以及如何把雲端的一次高階幫助轉化成自己未來可以重用的本地能力。

這就是從「遠端控制」走向「認知分工」的核心轉折。

參考資料

[1] Microsoft Learn. Identity and security in Windows 365 for Agents. 2026.
https://learn.microsoft.com/en-us/windows-365/agents/identity-security

[2] Microsoft Learn. What is Windows 365 for Agents? 2026.
https://learn.microsoft.com/zh-tw/windows-365/agents/introduction-windows-365-for-agents

[3] Tian, C., Cai, D., Zhao, W., Lane, N. D. Beyond Scaling: Agents Are Heading to the Edge. arXiv:2605.18535, 2026.
https://arxiv.org/abs/2605.18535

[4] Li, Y., Li, C., Liu, J. Efficient and Privacy Aware Edge Cloud Collaborative Inference for Large Language Models. arXiv:2607.13093, 2026.
https://arxiv.org/abs/2607.13093

[5] Wang, Z. et al. PPAI: Enabling Personalized LLM Agent Interoperability for Collaborative Edge Intelligence. arXiv:2605.18067, 2026.
https://arxiv.org/abs/2605.18067

[6] Nguyen, L. N. Zero-Shot Confidence Estimation for Small LLMs: When Supervised Baselines Aren't Worth Training. arXiv:2605.02241, 2026.
https://arxiv.org/abs/2605.02241

[7] Liu, X. et al. Adaptive Vision-Language Model Routing for Computer Use Agents. arXiv:2603.12823, 2026.
https://arxiv.org/abs/2603.12823

[8] Ge, Y. Governance Architecture for Autonomous Agent Systems: Threats, Framework, and Engineering Practice. arXiv:2603.07191, 2026.
https://arxiv.org/abs/2603.07191

系列依賴

上游：

05〈計算機作為持續智能環境〉
08〈計算式自我維護〉
09〈外部性有界智能體自治〉
10〈作用半徑與智能體權限〉

下游：

12〈多雲治理與智能體持續性〉
13〈多作業基底、分區故障域與恢復階梯〉
14〈人類最後一公里〉

11_本地自由雲端治理與教師智能_從遠端控制走向認知分工