調度器
在這本白皮書中,我覺得最值得我研究的前半部分的一個要點就是這個Orchestrator。 我以前不這么翻譯,我要么翻譯成Scheduler, 要么翻譯成Dispatcher, 都沾點意思。但是我畫圖還是化成個Orchestrator, 因為圖最好看。看來以后可以統一稱作 Orchestrator。
這個白皮書跟Claude Skills完全沒關系,我拿來類比主要是為了方便,有個參照物。
Claude Skills 體系目前只實現了 Orchestrator(調度器) 功能的一部分。
在《Introduction to Agents》這份白皮書中,Google 把智能體架構清晰地劃分為三個層級:
the model → the tools → the orchestrator
有意思的是,我原本也是按三層思考:
Language → Structure → Dispatch(L-S-D)
而其中的 Dispatch(調度),本質上就等價于他們所說的 Orchestration layer ——只是我更強調它作為“生命循環”的機制。
Orchestration = Nervous System — 調度、狀態、記憶(調度 → 生命)
“The orchestration layer is the central nervous system that connects them. It is the engine that runs the ‘Think, Act, Observe’ loop.”— Introduction to Agents (p. 22)
核心職能
維持并驅動整個 Think → Act → Observe 狀態機。
編排推理策略(Chain-of-Thought、ReAct 等)。
維護記憶系統(短期 State 與 長期 Vector Memory)。
處理 Planning、異常恢復、日志與追蹤。
決定 何時推理、何時行動、何時等待反饋。
調度流程分解(我的理解)
感知與語言解析首先是對任務的覺察:理解 mission 是什么、用戶真正想做什么。這與我設計的 Intention Clarifier 卡完全對應——把一段高熵語言解析成可識別的任務單元。
Planner — 推理調度器調度器通過 LM 進行思考與規劃,生成下一步計劃。它在時間中調配“思考”與“行動”的節奏:何時繼續推理,何時調用工具,何時暫停等待。
Tool Router & Executor — 行動執行器根據 OpenAPI 或 MCP 契約封裝調用外部工具。負責參數校驗、超時、重試、冪等與安全沙箱執行。執行結果被記錄為 observation,成為下一輪 planner 的輸入。
Memory System — 智能體的時間記憶負責維持智能體的“連續性”:
短期記憶記錄 (Action, Observation) 軌跡;
長期記憶(RAG/向量庫)保存跨任務知識與歷史。這些記憶被動態裝配進上下文窗口,形成“有時間感的推理”。
其余系統在此之上,還有 Human-in-the-Loop 確認、質量評估(LM Judge)、安全策略與可觀測性等機制,共同形成完整的閉環。我就全部和在一起了。
我說一個我的想法:
我關心的是我們作為開發如何寫調度邏輯。
所謂調度邏輯,本質上就是語言化的時間控制。它不是傳統程序那種“先執行 A 再執行 B”的順序邏輯,而是一種讓智能體在時間中“自我決定節奏”的語言結構。它決定了智能體的生命節拍:什么時候思考,什么時候行動,什么時候暫停、反思、或向人類求助。
在一個循環中,智能體必須不斷地在不同認知模式之間切換。
當環境模糊、信息不足時,調度邏輯會讓系統進入 THINK 模式,調用語言模型展開推理、規劃和假設生成;
當條件充分、計劃清晰時,它會轉向 ACT 模式,調用工具、函數或 API 去執行具體操作;
當風險過高或結果不確定時,它會進入 HITL (人在回路)/ REFLECT 模式,請求人類確認或進行自我反思;
而當行動結束、狀態穩定時,調度邏輯又會自動觸發記憶寫入和上下文壓縮,作為下一輪循環的起點。
因此,寫調度邏輯,等于在定義智能體的“呼吸節奏”:吸收信息(THINK),輸出行為(ACT),暫停自省(REFLECT),更新記憶(LEARN),再重新開始。
調度器不是單純的執行控制器,而是一個語義節拍器.它用語言描述時間、用結構組織行為、用反饋維持生命。
而且問題在于,現實中的任務往往不是單一邏輯,而是多種邏輯并存。我作為人類,我自己的寫的邏輯,真正到了上下文,但是選擇微妙之處,我個人是無法抉擇的。這部分是交給系統的“自由度”(哎呀這個問題你自己去針對一個較為復雜的場景寫你就知道了,是肯定人類無法窮盡所有的可能狀態的)。
此時,調度邏輯的挑戰不再是“如何執行”,而是如何在多條時間線之間做出選擇。
你現在試試多個Claude SKILLS 并行,不是CS專業都可以試試。體驗一下這種調度感覺。我認為Claude 有40% 接近。有雛形,但缺乏跨任務的狀態機與記憶反饋。這個方向的Google Vertex AI Agent Engine,約 60% 接近。循環引擎和可觀測閉環,但策略選擇與元認知判斷(何時 Think/Act)多由開發者在框架層實現,是寫死的,還不是真正自覺的調度。
總之,可以看看。
谷歌AGENT的白皮書:多智能體“社會”——要把另外一個智能體當成「工具」
我說這個把對方當成”工具人“這種事情都卷到AGENT上面了嗎?挺搞笑的。不過這一段還是非常有意義,看原文的話在p15-p18 頁。
總的來說,4個階段你肯定都看得懂:
Level 0 — Core Reasoning System語言的穩定性與推理力
Level 1 — Connected Problem Solver讓語言能行動
Level 2 — Strategic Problem Solver讓系統具備時間邏輯與調度循環
Level 3 — Collaborative Multi-Agent System從單體智能邁向協作智能
Level 4 — Self-Evolving System讓系統具備自我生長能力
0和1就不用說了,屬于比較基礎的功能。我上一個帖子其實說的是 Level 2涉及時間和調度的問題。我自己基本比較熟悉的就到Level 3這里。從Level 3這里就開始有趣了,我展開一下:
在 Level 3 階段,智能系統的核心不再是模型的能力,而是結構之間的協同能力。
Google 在這里提出一個類比:
“Agents treat other agents as tools.”
我噴….把對方看成工具人。他這里其實舉了個例子
一個“Project Manager Agent”收到使命(Mission)后,并不直接執行,而是通過語言去派發任務:
委派給 MarketResearchAgent:「分析競爭對手定價,明日交總結報告。」
委派給 MarketingAgent:「根據 Solaris 產品規格表,起草三版新聞稿。」
每一條指令都是一份結構化的使命聲明(Structured Mission),
說的比較簡要,我就提一個問題,到了Level 3, 還需不需要頂層調度器?
我認為他給的這個流程,實際上是一個“演化路徑”。其實非常好,因為作為開發者,我們現在可以將這個演化路徑作為一個未來1-2年的發展參考。《Introduction to Agents》這四級圖譜——從 Level 0 到 Level 4——幾乎就是未來 AI-Native 系統開發者的進化路線圖。起碼和我現在做的,還真可以跟這條路線搭上。反正我現在看過了,肯定搭。我也不會回到沒看過的這個狀態了。
我的理解是告訴開發者:在不同階段,重點應該構建什么、放棄什么、如何讓語言真正成為系統的核心。
以下內容就是我的解讀了:
一、Level 0 — Core Reasoning System
目標:語言的穩定性與推理力(這個部分大部分人已經完成)
建立“腦子”——讓語言模型能正確理解、思考、生成。
開發者任務:
熟悉各類模型的推理特征與局限(Gemini、Claude、GPT 等)。
學習 prompt 架構、思維鏈(Chain-of-Thought)等上下文設計。
建立最基礎的 LM 調用與日志分析體系。
啟示:
不要急于構建“系統”,先學會與模型對話。這一階段的成果不是產品,而是“理解語言模型的思考方式”。
?? 二、Level 1 — Connected Problem Solver
目標:讓語言能行動 (這個部分大部分開發者也已經完成)
賦予模型“手”,讓推理能觸達現實。
開發者任務:
學習 Function Calling / Tool Use / API Orchestration。
編寫可復用工具(Tools)并用 OpenAPI/MCP 描述其契約。
實現安全沙箱與冪等機制,建立最小閉環。
啟示:
工具化是第一步“結構化語言”實踐。語言不再只是回答,而是能執行任務。
我自己還在這一層構建了開始構建完整的語言協議和系統協議。
?? 三、Level 2 — Strategic Problem Solver
目標:讓系統具備時間邏輯與調度循環(大部分應用開發在這一層)
語言開始有記憶、有節奏、有自我監控。
開發者任務:
建立 Memory System(短期日志 + 長期 RAG)。
實現 Planner / Scheduler 狀態機:Think → Act → Observe 循環。
加入 Agent Ops:軌跡記錄、質量評測、成本監控。
啟示:
這一階段是從“腳本”到“生命”的臨界點。你寫的不再是 prompt,而是“語言的時間控制邏輯”。
但是呢,這一層還是單向的,我稱之為還沒有完整“閉環”回路。我后面會提到,在第四層的高級形態。但是形成一個簡單的系統是沒有問題的。
?? 四、Level 3 — Collaborative Multi-Agent System
目標:從單體智能邁向協作智能
構建“團隊”,讓專長代理協同完成復雜任務。
開發者任務:
設計 Coordinator / Critic / Refiner 等多代理角色。
用 A2A Protocol 或自定義消息總線實現代理互操作。
引入統一的任務語言(Mission Schema),確保語義一致。
啟示:
智能體開發進入“組織設計”階段。開發者從寫代碼的人,變成定義協作語言與調度邏輯的人。
?? 五、Level 4 — Self-Evolving System
目標:讓系統具備自我生長能力
系統能夠發現自身能力缺口,并生成新工具、新 Agent。
開發者任務:
引入學習回路:從 Human Feedback → Policy Update → 新結構生成。
啟示:
這是從工程邁向生態的階段。系統的任務不再是“執行”,而是“進化”。
真正的閉環,不只是「輸入—輸出—反饋」的往復循環,而是包含一個學習回路(learning loop)的系統。當學習機制被納入其中,智能體便不再是被動響應的程序,而是一個能夠持續更新自身結構的生命系統。這一層,標志著我們從“可編排的系統”正式邁向“可演化的復雜系統”——一個會成長、會適應、會產生意外之美的世界。
在傳統系統中,閉環意味著“結果被監測并修正行為”;
而在學習型系統中,閉環意味著“結果不僅修正行為,還反哺結構本身”。
每一次執行任務、處理異常、或獲得人類反饋,系統都在累積結構性經驗。
這種經驗不只是數據,而是調度與結構之間的耦合軌跡。
它逐步演化出一種“結構的記憶”,使得智能體在未來能更高效、更穩健地應對不確定環境。
這便是學習回路的核心意義:
系統通過反饋,不僅學會如何回答問題,更學會如何更新自己的思維方式。
當學習回路被激活,系統就具備了幾個關鍵特征:
自組織(Self-Organization)不同模塊、Agent之間的協作關系不再由外部顯式定義,而是通過經驗、評估與關聯度自動形成。系統像生態網絡一樣,能在任務流動中自我重組。
自學習(Self-Learning)每一次任務執行的軌跡(Trace)、評估(LM Judge)、人類反饋(HITL)都會成為訓練素材。系統學的不僅是答案,而是「如何思考與調度的模式」。學習的對象從“數據”擴展為“結構”。
自生成協議(Self-Generated Protocols)當系統遇到新場景、舊的調度邏輯無法覆蓋時,它會誘導出新的協調機制。這正是白皮書 Level 4 所描述的狀態——智能體能在缺口處創建新工具、甚至生成新 Agent。協議這部分是我加的,因為現在我的系統構想就是先搞定自生成協議。
下面有引用的原話:
《Introduction to Agents and Agent Architectures》在 pp. 42–46(章節標題:“How agents evolve and learn” 與 “How agents learn and self-evolve”):
“Agents deployed in the real world operate in dynamic environments where policies, technologies, and data formats are constantly changing… A more scalable solution is to design agents that can learn and evolve autonomously, improving their quality on the job with minimal engineering effort.”“Much like humans, agents learn from experience and external signals. This learning process is fueled by several sources of information… Crucially, this includes Human-in-the-Loop (HITL) feedback, which provides authoritative corrections and guidance.”“Instead of simply summarizing past interactions, advanced systems create generalizable artifacts to guide future tasks… Enhanced Context Engineering… Tool Optimization and Creation… dynamically reconfiguring multi-agent design patterns or using Reinforcement Learning from Human Feedback (RLHF) are active areas of research.”“This level of autonomy, where a system can dynamically expand its own capabilities, turns a team of agents into a truly learning and evolving organization.”
要能達到這個真的牛爆了。
![]()
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.