# 本地自由、雲端治理與教師智能：從遠端控制走向認知分工 **副標題：把雲端從「控制本地 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 $$ 那麼會出現： > 被治理者可以直接改掉治理規則。 例如： ```text 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 可以把它編譯成： ```text 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 也是資料最小化機制 例如： ```text 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. 一個簡化架構 ```text 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_CTaskSuccess_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〈人類最後一公里〉