Agentic Behaviour

Agentic behaviour 是指軟件不只是回傳單一答案，而是能夠透過一連串決定和行動去追求某個目標。

在這篇文章，我們用這個詞描述一個漸進過程。聊天機械人會回應。自動化會跟隨已定路徑。Agentic workflow 會在編排好的流程裏結合模型呼叫、工具和檢查。Agentic system 則可以自行決定更多路徑、使用工具、從回饋學習、停下來讓人審閱，並繼續朝指定成果前進。

這個漸進過程重要，因為「agentic」經常被講成一個開關：系統不是聊天機械人，就是自主系統。這個框架會誤導人。實際上，有用的 agentic behaviour 是逐步增加的。每向自主性走近一步，系統就更需要清晰背景、更強權限、更好的回饋循環、可量度成果和人手檢查點。

Agentic Behaviour 的工作定義

Agentic behaviour 指有目標導向的軟件行為，而且系統有一定能力選擇中間步驟。

這個概念比現時的大型語言模型更早出現。自主代理研究一直關心系統如何在環境中運作、追求目標和採取行動。近年的 LLM-based agent 研究，則集中於語言模型如何支援較長任務中的規劃、記憶、工具使用、反思和行動。一份 2024 年新興 agent 架構綜述 亦把 agents 視為由模型能力、記憶、規劃、行動和評估組成的系統，而不是一次模型呼叫。

Anthropic 對 workflows 和 agents 作出一個實用區分^{1Anthropic: Building effective agents}：workflows 會沿着預先定義的程式路徑使用 LLM 和工具；agents 則讓 LLM 動態地指揮自己的流程和工具使用。這個分別不只是技術問題。它是「軟件跟着已畫好的路線走」和「軟件在已定邊界內自行選路」之間的分別。

因此，agentic behaviour 應該被理解為一個設計光譜：

重點不是令每個系統都盡量自主。重點是把 agentic behaviour 的程度配合實際工作。

由聊天機械人到 Agentic Systems

聊天機械人負責回應

聊天機械人通常是反應式的。它收到訊息，然後回傳答案。這個答案可以很聰明、流暢和有用，但系統仍然以對話為中心。

這有時已經足夠。支援助理解釋政策、草擬助理重寫文字，或者內部知識助理找出答案，都未必需要在答案以外再採取行動。價值來自語言、檢索和清晰度。

限制在於，很多機構工作並不止於一個答案。它還需要查核紀錄、更新系統、分派任務、準備草稿、要求批准，或者監察某個結果有否發生。

自動化執行固定路徑

自動化加入了執行能力，但通常沿着預先決定的路線。規則說：當這件事發生，就做那個動作。發提醒。開 ticket。更新狀態。移動文件。觸發審批。

當工作穩定時，這很有力量。它亦容易理解：人可以檢視規則、測試路徑，知道應該發生甚麼。

限制是脆弱。工作越依賴背景、判斷、例外或不完整資料，就越難編成固定步驟。

Agentic workflows 在結構內加入判斷

Agentic workflow 保留結構的好處，同時在特定位置引入模型判斷。Anthropic 的例子^{1Anthropic: Building effective agents}包括 prompt chaining、routing、parallelisation、orchestrator-worker patterns 和 evaluator-optimizer loops。這些模式讓系統分解任務、分類工作、執行檢查、比較輸出，或者按準則改進草稿，而不需要把整個流程交給自主 agent。

這通常是實務上的中間地帶。機構定義路徑、工具、資料來源和停止點。模型在語言、分類、綜合或規劃有用的地方提供幫助。

例如，一個客戶更新流程可以先取回 matter record，摘要近期變化，檢查欠缺的證據，草擬更新，再送交審閱者。模型確實在做工作，但系統形狀仍然清楚。

Agentic systems 自行選擇更多路徑

Agentic system 有更多自由決定下一步。它可以檢視工作狀態、選擇工具、建立子任務、執行行動、評估結果、要求澄清，並持續到達停止條件。

Anthropic 把 agents 描述為 亦提出相關技術做法：把推理軌跡和任務特定行動交錯，使語言模型在與外部來源或環境互動時可以更新計劃。

到這一步，設計問題已經改變。核心問題不再只是「模型能否產生正確輸出？」而是「系統能否帶着正確背景、透過正確權限、追求正確成果，並在正確時間停下來？」

如何思考 Agentic Systems

Agentic systems 不是由誇張的使用者介面定義，而是由圍繞自主性的營運合約定義。

自主性

自主性應該具體。系統可能被允許閱讀文件、草擬回應、建立任務、更新狀態，或者提交交易。這些都是不同層次的權限。

好的設計會把「可以準備」和「可以執行」分開。很多有用的 agentic systems 應該先為人準備可審閱工作，而不是直接行動。

工具

工具令 agent 由文字系統變成營運系統的參與者。IBM 形容 AI agents，工具定義需要仔細設計，因為 agents 依靠清晰介面可靠地使用外部服務。

工具設計應該狹窄、有文件、可測試和有權限控制。一個叫「更新客戶紀錄」的工具通常太闊。更好的工具會指明確切紀錄類型、可改欄位、必需來源證據、驗證規則和審計行為。

換言之，工具不是普通捷徑，而是 agent 參與工作系統的介面。介面越清楚，系統越容易知道自己正在處理哪類紀錄、哪個欄位、哪個來源，以及哪條審批或審計規則；介面越寬鬆，系統就越容易把本來需要人判斷的步驟當成一般更新。

回饋

Agentic behaviour 依賴回饋。沒有回饋，系統無法知道上一個行動是否令它更接近目標。

回饋可以來自檢索結果、測試執行、工作流狀態、使用者修正、審閱者決定、指標或系統錯誤。Anthropic 的 evaluator-optimizer pattern^{1Anthropic: Building effective agents} 在這裏有用，因為它把評估視為一個循環：產生、按準則評估，然後在準則支持時改進。

權限

權限不只是安全層。它是 agent 理解工作的其中一部分。

Agent 應該知道自己可以讀甚麼、寫甚麼、建議甚麼、對外發送甚麼，以及甚麼必須先獲批准。當系統可能跨越客戶、事項、部門、財務紀錄、個人資料或受監管決定時，這尤其重要。

檢查點

檢查點是系統刻意停下來的時刻。它們可以是強制批准、信心門檻、預算限制、最高迭代次數、升級規則，或者「問人」的時刻。

NIST 的 AI Risk Management Framework^{2NIST: Artificial Intelligence Risk Management Framework 1.0} 把治理、量度、管理、問責、文件紀錄、監察和人機監督放入可信 AI 系統的生命週期。對 agentic systems 來說，這些控制不是事後 paperwork，而是設計要求。

可量度成果

Agentic systems 需要可量度成果，因為沒有評估的自主性只是表演。

有用的量度包括任務完成、審閱者接受率、修正率、所需時間、錯誤率、升級質素、避免返工、使用者滿意度和下游成果質素。Anthropic 的實務例子^{1Anthropic: Building effective agents} 指向客戶支援和編程，部分原因是它們有較清楚成功準則：已解決個案、已驗證測試和可審閱輸出。

對 agentic systems 來說，量度亦要包括系統是否在正確時間停下來。若證據不足、權限不明、工具結果互相矛盾，或決定超出系統可處理範圍，升級或停止本身就是正確行為。只看完成率，會把不應完成的行動也當成成功。

Agents 需要機構可讀性

Agent 無法在一個自己讀不懂的機構裏負責任地工作。

大部分機構其實已經有 agents 需要的原材料：文件、訊息、會議、任務、紀錄、審批、期限、預算、關係和決定。問題是這些材料分散在不同工具，而且經常依賴默會知識。

對 agent 來說，默會知識就是缺失的介面。相關工作必須從文件、電郵、日曆、會議、個案系統、財務工具、任務板、支援系統和資料庫進入，並帶有足夠來源背景，讓系統知道誰說過、何時改變、屬於哪個紀錄，以及帶有甚麼權威。

然後，這些資訊要變成機構可以信任的概念：客戶、事項、負責人、來源、期限、批准、風險、續約、任務、決定和成果。機構語言在這裏很重要。如果系統分不清草稿和已批准文件、筆記和承諾，或者建議和決定，agentic behaviour 就會變得危險。

營運狀態要持久、可查詢、有權限控制，並可透過受控工具使用：搜尋、檢索、API、編輯器、工作流行動、隊列、審閱介面和寫回路徑。

這就是漸進過程變得實際的地方。聊天機械人可以從檢索背景回答。自動化可以由結構化事件觸發。Agentic workflow 可以結合檢索、檢查和工具。Agentic system 可以追求目標，因為機構暴露了一個可讀、有權限的環境。

邊界令自主性有用

系統越 agentic，邊界就越需要明確。

這些邊界應該涵蓋：

• 目的：系統為甚麼而設，以及不是為甚麼而設。
• 範圍：它可以接觸哪些紀錄、團隊、客戶、領域或流程。
• 權限：它可以閱讀、草擬、更新、發送、批准，還是只能建議。
• 證據：哪些來源具權威、過時、不完整或有爭議。
• 審閱：誰檢查輸出，何時必須審閱，審閱者必須看到甚麼。
• 失敗：當系統不確定、受阻、循環，或收到互相矛盾指示時會怎樣。
• 量度：機構如何知道系統正在改善工作。

這不是對 agents 的悲觀理解。這是信任它們的實際條件。NIST 把 AI 風險管理^{3NIST: AI Risk Management Framework overview}視為提升可信度融入 AI 系統設計、開發、使用和評估能力的方法。Agentic systems 令這種設計紀律更重要，因為系統不只是產生內容；它可能改變工作的狀態。

因此，邊界要盡量用系統可以讀到和執行的方式表達，而不只是留在政策文字裏。若某類資料不可外發，工具應阻止外發；若某類更新需要審閱，workflow 應在該點停下；若來源已過期，retrieval 應提示限制。這些都是把治理變成設計要求。

甚麼時候未必需要

不是每個有用的 AI 功能都需要 agentic behaviour。

如果任務只是單次回應，一個有良好 grounding 的聊天機械人可能已足夠。如果任務可重複而穩定，傳統自動化可能更清晰、更便宜、更可審計。如果流程少見、低價值或高度敏感，人手工作配合 AI 協助，可能比把步驟委派給系統更好。如果成功無法量度，通常太早加入自主性。

Anthropic 的指引^{1Anthropic: Building effective agents} 在這點很直接：由最簡單而有效的方案開始，只有在 agentic complexity 明顯改善成果時才加入。Agentic systems 往往以成本和延遲換取更好的任務表現，所以取捨要有理據。

實務測試是：

• 任務是否需要多個步驟？
• 這些步驟是否難以預先預測？
• 系統能否從環境取得可靠回饋？
• 工具是否透過安全、狹窄的介面提供？
• 權限和檢查點是否明確？
• 是否有可量度成果？
• 人能否審閱重要決定？

如果答案多數是否，機構需要的可能是更好的檢索、更清晰工作流，或者更狹窄自動化，而不是 agentic system。

實際論點

Agentic behaviour 不是由聊天跳到自主的一次飛躍。它是一條梯。

最底層，系統回應。然後，它跟隨工作流。再然後，它在結構化路徑內使用工具。最後，它以更多自由追求目標。每一步都可以有用，但每一步也提高了對背景、回饋、權限、檢查點和量度的要求。

這個逐級觀點對專業團隊尤其重要。很多工作不是不值得 AI 協助，而是不適合一開始就交給高度自主的系統。比較穩妥的路線，是先把檢索、整理、缺口標示、草擬和審閱準備做好；當來源、工具、權限和回饋逐步可靠，才考慮把更多步驟委派給系統。

所以，agentic behaviour 不應被理解成模型能力競賽。更強的模型可以改善某些步驟，但如果工作狀態不可讀、工具太闊、權限不清、回饋不能返回系統，整體仍然危險。相反，一個設計良好的 workflow 即使自主性較低，也可以在清晰邊界內創造可靠價值。

實務上，團隊可以把候選流程拆開看：系統是否只需要回答？是否需要執行固定步驟？是否需要在固定路徑內分類、檢查或草擬？還是需要在不同工具之間自行選擇路徑？這樣看，agentic design 不是抽象標籤，而是把責任、權限和審閱放回工作設計的方法。

另一個實務重點，是把「行動」拆細。讀取文件、建立摘要、標示風險、開內部任務、更新狀態、向客戶發訊息、提交交易，全部都是不同級別的行動。它們需要不同權限、不同證據和不同審閱。把這些行動混成一個「agent 可以做事」的能力，會令治理失焦；把它們拆成狹窄工具，反而令 agentic behaviour 可以逐步擴展。

同樣，回饋也要具體。審閱者接受了草稿、要求補來源、拒絕建議、改了分類、指出系統引用了過時文件，這些都是不同類型回饋。若系統只知道「成功」或「失敗」，它很難改進。若工作流能保留具體修正和理由，下一次檢索、草擬和升級就有更好依據。

最後，agentic system 的停止條件要像啟動條件一樣清楚。系統不應無限嘗試、不應在缺少授權時繞路，也不應把不確定包裝成完成。好的停止條件包括找不到權威來源、工具結果互相矛盾、成本或時間超限、輸出信心不足、行動不可逆，或者決定超出系統權限。這些停止點不是拖慢創新，而是令自主性可以被信任。

這就是為甚麼 agentic systems 是機構系統，而不只是 AI 功能。模型重要，但模型不夠。機構要把工作狀態以系統可讀和可安全行動的形式暴露出來。它要定義系統可以做甚麼、不可以做甚麼，以及甚麼時候人仍然要負責。

有用的未來不是「所有事情完全自主」。而是工作系統能夠在清晰邊界內讀取背景、使用工具、準備行動、要求判斷、從回饋學習，並朝可量度成果前進。

這個成熟度應該跟着工作證據走，而不是跟着市場口號走。當檢索可靠，可以讓系統做更多分類；當分類可靠，可以讓它建立內部任務；當任務建立可靠，可以讓它在低風險範圍內更新狀態。每次增加權限，都應同時增加量度、審計和停止條件。

這也是為甚麼產品展示片段不能取代營運驗證。Demo 可以顯示系統完成一條理想路徑；真實工作則會遇到缺文件、權限不足、指示衝突、審閱者不同意和外部系統失敗。能否處理這些不漂亮的情況，才決定 agentic behaviour 是否能進入專業工作。

要把 agentic behaviour 落地，最好的起點通常不是「建一個 agent」，而是選一段已經重複發生、但又不能完全寫死的工作。例子可以是客戶更新、續約檢查、matter review、供應商風險跟進，或內部審批準備。這些流程通常有多個步驟、有來源證據、有明確負責人，也有需要人判斷的地方，適合測試 agentic workflow 是否真的改善工作。

落地時，團隊應先畫出現有工作如何發生：輸入在哪裏、哪些紀錄要查、哪些判斷由誰做、哪些行動可逆、哪些行動對外、哪些錯誤最昂貴。然後才決定模型應該加入哪一段。很多時，第一個有用版本不是讓系統自行完成整件事，而是讓它準備一個 review packet：列出來源、摘要變化、標示缺口、提出下一步選項，並把需要批准的部分清楚送到人面前。

這種落地方式也方便比較成效。團隊可以在每一級量度準備時間、審閱修正、錯誤類型、升級質素和使用者信任，而不是只問 agent 有沒有完成任務。如果 agent 經常在同一位置停下來，可能代表缺少來源、工具設計太窄、權限規則不清，或流程本身需要重設。這些訊號都比單純成功率更有診斷價值。

最終，agentic behaviour 的成熟度應該反映機構成熟度。工作狀態越清楚、來源越可靠、權限越明確、審閱越有力，系統就可以被委派更多。若這些條件不存在，限制自主性不是保守，而是誠實。成功標準亦應包括系統怎樣失敗：它是否承認沒有足夠背景、保留審計軌跡、把例外送到正確的人，以及避免在不應行動時行動。

當團隊用這種方式看 agentic behaviour，就會發現最重要的不是把人移走，而是把人放在更有價值的位置。AI 可以處理搜尋、整理、比較和準備；人則集中處理權衡、例外、關係和問責。這種分工，才是 agentic systems 在專業環境中真正可持續的形態。

換句話說，agentic behaviour 的價值在於讓軟件在清晰營運合約內前進，而不是把所有工作一次過交給自主系統。模型、工具、回饋、權限、檢查點和量度要一起設計；任何一項缺失，都會令「能行動」變成「難以信任」。這也是本文的核心：agentic systems 是工作系統，不只是 AI 功能。

因此，最務實的路線通常是逐步提高委派程度：先讓系統可靠地回答和整理，再讓它在受控 workflow 內使用工具，最後才讓它在明確目標、權限和停止條件下選擇更多中間步驟。每一級都應該有可審閱輸出、可追溯來源和可量度結果。這樣，autonomy 才不是一次信任跳躍，而是由工作證據支持的設計選擇。

這也解釋了為甚麼同一個「agent」標籤可以遮住很多不同風險。只會草擬和標示缺口的系統，和可以寫回紀錄、對外發送或提交交易的系統，不應用同一套審閱和權限處理。真正的設計問題，是每一步讓系統多做了甚麼、它根據哪些來源行動、錯了是否可逆，以及人在甚麼位置仍然可以改變結果。

因此，組織在採用 agentic systems 時，應該先界定可委派的步驟，再界定工具、來源、審閱和停止條件。這樣，系統的自主性才會跟工作成熟度一致。

這也是由 chatbot、automation、agentic workflow 到 agentic system 的實際分別。

資料來源

1. Anthropic: Building effective agents
2. NIST: Artificial Intelligence Risk Management Framework 1.0
3. NIST: AI Risk Management Framework overview
4. Masterman et al.: The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling
5. Wang et al.: A Survey on Large Language Model based Autonomous Agents
6. Yao et al.: ReAct: Synergizing Reasoning and Acting in Language Models
7. IBM: What Are AI Agents?