傳統自動化遵循固定指令，簡單的聊天機器人只回應眼前的訊息。目標導向 Agent 的運作方式不同：它從期望的結果出發，規劃達成該結果所需的行動，並在任務推進過程中評估新資訊。本文將說明這一概念、支撐它的架構以及主要應用場景，同時將目標導向 Agent 與其他類型的 AI Agent 進行比較，並介紹 Kimi Agent 作為體驗目標導向任務執行的實用方式。
什麼是目標導向 Agent？
目標導向 Agent 是一種圍繞既定目標做出決策並採取行動的 AI 系統。它會評估當前狀態，考量可能的下一步，並選擇能讓系統更接近期望結果的行動。該 Agent 可以使用工具、追蹤進度，並在新資訊改變情況時修改計劃。
舉例來說，一個客服 Agent 可能只回答單一問題，而目標導向 Agent 則會致力於解決整個客戶問題。它可以查閱帳戶歷史記錄並參考經核准的知識庫，然後診斷問題、準備解決方案，或在證據不足時將案件升級處理。
目標導向 Agent 如何運作？
目標導向 Agent 通常遵循一個重複的循環：先定義期望的結果並觀察當前環境，接著制定計劃、選擇行動，再評估結果。如果結果未能推進任務，Agent 可以重新規劃或請求協助。
定義目標
這個過程始於對成功的精確定義。目標可能包含多個相關條件，但每個條件都應可測試。目標還可以包含限制條件，例如截止日期、經核准的資料來源、支出限額、所需核准以及禁止的行動。語言模型可能將模糊的請求轉化為具體的子目標，但最終的成功標準應對工作流程負責人保持透明可見。
感知環境與狀態
Agent 會從使用者請求、外部系統、檔案、資料庫、API 回應或系統事件中收集有關當前狀態的資訊。在機器人環境中，感測器會提供關於周圍物體及環境變化的資訊。狀態還應記錄已完成的任務、待核准事項以及失敗的假設。清晰的錯誤與狀態值有助於 Agent 決定是繼續、重試還是升級處理。
規劃與任務拆解
規劃模組會將目標轉化為可執行的路徑，把宏觀目標拆解為較小的任務，並識別任務之間的依賴關係。以員工入職為例，計劃可能從收集及核實文件開始，然後準備帳戶申請並等待相關職務的核准。穩定的流程可以採用固定計劃，而變化中的工作流程則需要設置決策點，以便逐步重新規劃。
選擇並執行行動
制定計劃後，Agent 會選擇下一個經核准的行動。它可能會查詢系統、搜尋文件、更新記錄，或向人員詢問缺失的資訊。每個行動都應有明確的輸入及預期結果。Agent 必須在將該步驟標記為完成之前驗證結果，而高影響的行動則應暫停以等待人工核准。
反饋與重新規劃
執行並非單向過程。Agent 會將最新結果與目標進行比對，並檢查該計劃是否仍然合理。新的證據可能證實當前路徑可行、揭露障礙，或提供更安全的替代方案。
該循環可以表示為：
目標可能保持不變，而路徑則可能改變。倉儲機器人在偵測到障礙物後可以選擇另一條路徑；研究型 Agent 在第一個資訊來源無法回答問題時，可以搜尋另一個來源。執行預算，例如對輪次、工具呼叫次數、重試次數或時間的限制，可以防止無限期運作，並使性能更容易衡量。
目標導向 Agent 架構的核心組成
目標導向 Agent 架構將目標與狀態、規劃、工具及監督機制連接起來。具體實作方式各有不同，但每個組成部分都應具備明確的職責。
目標與成功標準
目標層定義了期望達到的狀態，說明代理必須完成什麼、以及怎樣才算完成。它還可以指出執行過程中可能出現的失敗情況與限制條件。
例如，某個文件處理流程可能要求所有必填欄位都經過驗證後才能提交紀錄。如果流程要求完整驗證，那麼未完成驗證的紀錄就不能算作部分成功。明確的判定標準有助於代理在恰當的時機停止。
世界模型與知識庫
世界模型為代理提供了對其所處環境的工作表徵，可能包括目前的系統狀態、可用資源、已知的關係，以及各種行動可能帶來的後果。知識庫則在代理需要做出決策時提供支援資訊。
世界模型之所以有用，是因為代理無法僅憑目標就進行規劃，它還必須了解流程目前所處的階段。它也需要區分暫時的任務情境與較長期存在的知識。檢索機制應提供相關資訊，而不是把整個資料集全部塞進活動情境中。
一份管理良好的狀態紀錄可以顯示已完成的步驟、待處理的依賴項、失敗的嘗試以及審核狀態。對於任何供之後使用而保存的內容，都應由存取規則與資料來源管控。
規劃模組
規劃模組負責建立並更新通往目標的路徑，可能是產生一連串動作、將工作分配給不同的專責單元，或動態選擇下一步。
好的規劃會考慮依賴關係與不確定性，不會假設每個工具都會回傳預期的結果。它可以包含備援路徑、驗證步驟以及升級處理的條件。當新的證據可能改變最佳下一步時，計畫應保持可調整的狀態。
工具與行動層
工具讓代理能夠與模型以外的系統互動，常見的例子包括搜尋、資料庫查詢、檔案處理、瀏覽器操作、業務 API，以及紀錄更新。
每個工具都需要有清楚的約定，說明有效的輸入、預期的輸出、權限、錯誤以及副作用。讀取操作與寫入操作應盡可能分開處理。敏感操作應採用更嚴格的驗證與審核規則。
執行、評估與防護機制
執行層負責執行所選定的動作，評估層則依據計畫與成功標準檢查結果，防護機制界定代理能做什麼、以及何時必須停止。
正式運作的工作流程應記錄決策、工具呼叫、觀察結果與狀態變化，這些紀錄有助於除錯與人工審查。在執行不可逆的動作、對外溝通、財務異動或正式環境更新之前，設置審核關卡尤其重要。
目標導向代理與其他類型 AI 代理的比較
目標導向代理只是眾多 AI 代理設計中的一種，這些類別之間可能有重疊，但各自強調不同的決策方式。
| Agent 類型 | 決策方式 | 規劃能力 | 最適用場景 |
|---|---|---|---|
| 簡單反射式 Agent | 對當前輸入做出反應 | 幾乎沒有或完全沒有 | 固定規則與即時反應 |
| 基於模型的反射式 Agent | 使用內部狀態模型 | 有限 | 需要基本記憶能力的環境 |
| 基於目標的 Agent | 選擇能朝既定目標推進的行動 | 是 | 目標明確但路徑可能變化的情況 |
| 基於效用的 Agent | 選擇價值最高的結果 | 進階的取捨分析 | 存在多個相互競爭的目標 |
| 學習型 Agent | 從經驗或回饋中改進 | 能隨時間演進 | 受益於自我調整的任務 |
反應式代理只依據當下所見做出回應，而目標導向代理則會考慮某個動作對未來狀態的影響。這種著眼未來的行為，使得目標導向系統更適合用在目標明確、但達成路徑不固定的情況。
效用導向代理處理的是另一種決策問題，它會比較各種可能的結果並對其賦予價值。例如，客服系統在選擇回應方式時，可能需要在解決速度、退款成本與客戶滿意度之間權衡。目標導向代理通常只關注是否達成目標狀態。當工作流程有需要時，目標導向系統仍然可以納入學習機制或效用導向的元件。
目標導向代理與任務導向代理的比較
任務導向代理與目標導向代理都能將有用的工作自動化，兩者的差別在於系統接收指令與衡量成功的層級不同。
| 維度 | 基於任務的 Agent | 基於目標的 Agent |
|---|---|---|
| 起點 | 一項具體指令 | 一個期望達成的結果 |
| 範圍 | 單一明確任務 | 彼此關聯的工作流程 |
| 下一步行動 | 通常由使用者或工作流程指定 | 由 Agent 自行選擇 |
| 成功衡量標準 | 任務完成度 | 目標達成情況 |
| 適應能力 | 通常有限 | 條件變化時可重新規劃 |
| 人工輸入 | 可能每一步都需要 | 通常只在邊界或例外情況下需要 |
當所需動作已經明確時，任務導向代理較為適用；當結果明確、但路徑可能有所變化時，則適合採用目標導向代理。任務導向系統可以從文件中擷取某個欄位，而目標導向系統則可以將這個擷取動作作為更大流程中的一個步驟，用來驗證資訊並處理例外情況。
兩者的區別在於工作流程的責任層級，而不在於代理的數量。單一代理可以追求一個範圍較大的目標；多個代理也可以各自執行獨立的任務，而不需要共享一個更大的整體計畫。
目標導向代理的應用場景
目標導向代理適合用在目的地明確、但任務結束前條件可能發生變化的環境中。
機器人與倉儲自動化
倉儲機器人可能會接到將包裹搬運到出貨區的目標，它必須辨識包裹、規劃路線、避開障礙物並監控自身位置。如果另一台機器人擋住了原定路徑，代理就可以評估替代路線。
目標始終不變，但動作順序會依環境而改變。這使機器人成為一個很好的例子，說明代理是在朝向未來狀態進行規劃，而不只是對眼前的障礙做出反應。
客戶支援與問題處理
客服工作流程可能將成功定義為：以準確且經過核准的回應解決客戶的問題。代理可以閱讀對話內容、擷取帳戶資訊、查閱知識庫，並判斷問題是否需要升級處理。
系統不應在草擬回覆之後就宣告成功，而應檢查該回應是否確實解決了問題、以及所需的動作是否已經完成。敏感的變更應保留人工審核這道關卡。
員工入職
員工入職涉及一系列彼此關聯的任務，這些任務取決於職位、地點、到職日期與審核狀態。目標導向代理可以追蹤整體結果，而不是把每個請求都當作孤立的動作來處理。
它可能負責收集文件、驗證資訊、準備帳戶申請，並等待主管核准。如果缺少必填欄位，代理可以暫停或要求補齊資訊，而不應為了讓計畫繼續推進而繞過權限規則。
研究與內容產出流程
研究工作流程的起點可能是產出一份以可靠證據為依據的結構化報告。代理可以將問題拆解成幾個子主題、在核准的來源中進行檢索、整理發現，並找出資料缺口。
如果某個來源無法支持某項論點，代理可以調整研究計畫。審查步驟可以檢查最終報告是否回答了最初的問題。當報告將影響重大決策時，人工審查仍然十分重要。
事件應變與維運
負責事件應變的代理可能致力於找出服務問題的根本原因，它可以檢視日誌、查看近期的部署紀錄、確認依賴關係，並在不同系統之間比對證據。
隨著新訊號出現,工作流程可能會有所調整。Agent 可以建議回滾或修改配置,但涉及生產環境的操作應該需要授權。基於目標的循環有助於組織調查工作,而不會讓「建議」變成「不受控的執行」。
基於目標的 Agent 有哪些優勢
更擅長處理多步驟工作
基於目標的 Agent 可以圍繞最終結果組織一系列相關操作。只要工作流程的邊界清晰,就不需要為每個低風險步驟都提供指示。
比基於規則的自動化更靈活
固定規則在穩定條件下運作良好。當輸入發生變化或預期操作失敗時,基於目標的系統可以選擇另一條經過批准的路徑。
成功標準更明確
明確的目標讓評估更有意義。系統可以檢查是否達成了預期結果,而不是靠回應的長度或流暢度來衡量成功與否。
工作流程的連續性更好
Agent 可以保留任務狀態,並辨識哪些工作尚未完成。這在工作流程因等待審批或等待其他系統提供資訊而暫停時尤為重要。
讓人的授權更有價值
人可以設定結果、限制條件和審批節點。Agent 則可以在這個運作邊界內處理常規決策,而例外情況和影響重大的選擇仍由人來處理。
如何設計可靠的基於目標的 Agent
可靠的設計應該從工作流程出發,而不是從模型出發。使用能夠安全完成任務的最精簡架構。
定義一個可衡量的目標: 寫出評估者能夠驗證的完成條件。
設定成功與失敗條件: 說明 Agent 應在何時繼續、停止或上報。
將目標拆分為子任務: 為每個子任務設定明確的輸出和依賴關係。
限制工具存取權限: 只提供當前角色所需的工具。
區分讀取和寫入權限: 將資訊檢索與改變狀態的操作區分對待。
加入審批關卡: 在執行敏感或不可逆的操作前要求確認。
記錄執行過程: 記錄計劃、工具呼叫、結果和狀態變化。
設定執行限制: 設定時間、輪次、重試次數和成本方面的邊界。
測試完整的工作流程: 評估最終結果,而不只是單個模型回應。
逐步擴展: 先從單一 Agent 開始,只在實際需要出現後才加入協同機制。
實際的原則很簡單:使用能夠可靠完成工作流程的最低複雜度架構。更高的自主性只在解決具體運作問題時才有用。
認識 Kimi Agent:一個你現在就能使用的基於目標的 Agent
本指南中的規劃循環並不只是理論,它正是 Kimi Agent 執行實際任務的方式。你只需用一句話描述期望的結果,Kimi 就會將其拆解為子任務,並用內建工具逐步執行。它會在交付最終結果之前先評估結果是否達成。你不需要搭建編排層,也不需要維護工作流程程式碼。
說出目標,獲得成果
Kimi Agent 的運作方式正是基於目標的 Agent 應有的樣子:給它一個目標,而不是一套流程。它會自行規劃路徑,產出可以直接使用的成果。
透過 Kimi Deep Research 生成附有引用來源的研究報告
根據簡短需求構建的可運行多頁網站
即用型 PPT 演示文稿、文件或表格
你可以一次上傳最多 50 個檔案作為素材,已有的 PDF、幻燈片和圖片都能成為任務內容的一部分。
長時間任務可自行運行至完成
基於目標的 Agent 在需要多個步驟的工作中才能真正體現價值。Kimi Deep Research 通常每個任務需要運行 10 到 25 分鐘,並在後台持續執行,你可以離開頁面,回來時就能看到完成的報告。Agent 會自行追蹤進度,不需要你在每一步都給出提示。
將一個目標擴展為數百個並行任務
當單個 Agent 不足以應付任務規模時,Kimi Agent Swarm 會將目標拆分給 100 多個子 Agent,並支援最多 1,500 個並行工具呼叫。它專為大規模搜尋、長篇寫作和批量處理而設計——同樣是基於目標的循環,只是規模更大。
邊界仍由你來設定
基於目標的設計讓人始終掌控結果,Kimi 的運作方式也是如此。你設定目標和限制條件,然後審核計劃和成果。重要事實和影響重大的決策始終由人來審核。自主性負責路徑規劃,判斷則始終掌握在你手中。
限制與挑戰
以目標為導向的 Agent 比固定式自動化提供更高的靈活性，但也帶來新的失敗模式。目標若定義模糊，可能讓 Agent 朝錯誤的結果前進；決策空間過大，則會使規劃成本升高。隨著環境變化，計畫也可能變得過時。當優先事項互相衝突時，可能需要基於效用的推理或人工判斷，而不是簡單的完成檢測。工具失敗與過時資料會帶來額外風險，尤其是在 Agent 能夠變更外部系統的情況下。因此，可靠的部署需要經過驗證的工具結果、受控的重新規劃、有限的權限、可見的日誌，以及對高影響動作的人工核准。
結語
以目標為導向的 Agent 會朝著明確的結果努力，而不是只回應最新的輸入。它透過一個循環，把規劃與行動連結起來，並在選擇下一步之前評估觀察到的結果。這種方式適合終點明確、但路徑可能改變的工作流程。一開始就設定明確的成功標準與有限的權限，只有在工作流程確實需要時才增加複雜度。Kimi Agent 提供了一種實用的方式，讓你在不必從零打造 Agent 架構的情況下，探索以目標為導向的任務執行。