LLM Agent、多 Agent 協作、任務導向對話、Prompt Router
想像一家快速成長的企業中，不同部門都希望擁有專屬的 AI 助理來提升工作效率。
法務部門每天面對大量合約審閱與法規查詢，希望有 AI 幫忙快速摘要合約、對比條款並確保符合內部 SOP。
客服部門則需要一個 24/7 待命的 AI，能即時處理來自 Line、Email 等通路的常見問題，自動產生專業又有親和力的回覆內容，減輕人力負擔。
到了業務銷售部門，業務同仁想要的是一位可以閱讀 CRM 資料庫、為重要客戶產出資料摘要和銷售建議的智慧助手，協助他們準備會議或制定策略。
上述各部門的需求差異極大：法務助理講求嚴謹精確，客服助理注重親切高效，銷售助理則強調洞察力與行動建議。那麼，我們是否能在同一套 AI 平臺上，同時培育出多位風格迥異的部門 AI 助理？答案就是善用 LLM Agent 模組來深度定制每個 Agent 的行為模型與任務導向對話能力，讓一個平台孕育多種專才。
要實現企業多部門的 AI 助理，我們將架構建立在 Odoo 18 平臺上，並引入 FastAPI 及 OpenAI GPT-5 作為中介服務與大模型引擎。整體解決方案包含：企業管理系統 (Odoo) 做為資料與業務邏輯核心，LLM Agent 模組提供多 Agent 管理框架，FastAPI 承接外部通訊，GPT-5 負責智慧應答。下圖展示了這套架構下多部門助理的協作關係：
如圖所示，我們在 Odoo 中部署 LLM Agent 模組作為大腦，創建多個按部門劃分的 AI Agent。每個 Agent 都擁有獨立的模型設定、工具以及系統提示詞，以確保能針對各自用途提供最適切的回應。
例如，「法務 AI 助理」會連結內部合約資料庫或法規文件向量索引；「客服 AI 助理」則掛接常見問題知識庫與客戶資料；「銷售 AI 助理」能讀取 CRM 中的客戶交易記錄。這些 Agent 最終都會透過 GPT-5 模型產生語言回覆。
在實際運作時，各通路的詢問會透過 FastAPI 進入 Odoo 系統。
外部客戶的提問（例如 LINE 訊息或 Email）由 FastAPI Webhook 接收後，透過 Odoo 提供的 API 轉交給對應的 AI Agent 處理；公司內部人員在 Odoo 介面上的提問，則可直接由 Odoo 呼叫相應 Agent。
Odoo 18 採用本地部署，確保資料安全的同時，也讓我們能靈活擴充自定 API 或存取內部資料庫。當 Agent 完成回應生成後，答案會經由 FastAPI 傳回原通路：對外可經由 LINE API 回覆訊息或 Odoo 郵件模組發信，對內則直接在介面顯示結果。
透過這種架構，一套系統多位 AI 助理的目標得以達成——Odoo 扮演企業資料與流程樞紐，各專屬 Agent 提供智慧，加上 FastAPI 接通內外，一同構成靈活強大的 AI 助理生態。
值得一提的是，LLM Agent 模組本身已提供管理多個 Agent 的功能，可讓我們方便地新增/配置不同部門的 AI 助理，指定各自使用的模型及工具，並能在聊天介面中輕鬆切換不同助理。接下來，我們將深入各部門助理的設計細節，看看如何針對法務、客服、銷售場景進行深度定制。
💡 Gary’s Pro Tip｜合適地給予 Agent 工具與能力
在開發 AI Agent 的時候，為了讓其獲得更多有用的上下文資訊，通常會給予其外部工具與能力，例如上面說的例子中，都用到查詢資料庫，所以會賦予 query PostgreSQL 資料庫的相關能力與資訊；又例如大家很常聽到的「連網」，就是讓 Agent 可以使用 web search 的能力。值得一提的是，即便是連網，怎樣的連法也是很細節但是重要的重點，舉例來說，法務部門若要連網，可能是鎖定在幾個有優質法源、法案的網站，這時候就可以限縮連網的域名，進一步提高網路搜尋的精準度。
法務 AI 助理需要處理合約文件與法律法規相關的查詢。我們以檢索增強生成 (RAG) 架構強化它的能力，並設計 Prompt 模板與工作流程，使其在法務場景下表現專業可靠。
首先是資料來源方面。我們將公司的歷史合約文件、範本條款、內部法規摘要等資料進行Embedding 向量化，存入向量資料庫。例如，可利用 PostgreSQL 的 pgvector 外掛向量庫，將每份合約切分成段落後存成向量索引。
當使用者請求合約摘要時，法務 Agent 會先根據合約標題或內容關鍵字，在向量資料庫中檢索相關段落，取得最相關的內容片段。接著，Agent 再將這些檢索結果作為上下文，連同使用者的問題一併發送給 GPT-5。透過這種 RAG 技巧，GPT-5 在生成回答時能參考企業內最新且相關的資料，使回答更有依據、減少法律風險。
例如，假設使用者詢問：「請幫我總結一下 ABC 供應合約 的重點條款」。法務助理會先在向量庫找到 ABC 供應合約 相關的條款段落，可能包括合約期限、付款條件、責任歸屬等片段。然後組裝 Prompt 要求 GPT-5 做摘要。有了檢索片段輔助，AI 的回答將緊扣原合約內容，例如：「ABC 供應合約為一年期，約定每月付款，供應商須承擔延遲交貨的賠償責任...」，確保內容準確。
除合約外，法規查詢也是法務助理的職責之一。此時 Agent 可以切換檢索範圍至法律法規資料庫或內部撰寫的合規手冊。例如，當使用者問：「公司是否可以延長員工試用期至半年？」，Agent 會從勞動法規的向量索引中檢索相關條文（如勞基法關於試用期的規定），再讓 GPT-5 根據檢索結果給出解答，並引用法規內容來支持答案。
透過 RAG，法務助理彷彿隨身帶著整個律所知識庫，能即問即答。
為了讓法務助理的回答風格符合專業要求，我們在設計 Prompt 模板 時特別調整了系統提示 (System Prompt)。在 GPT 對話中，System Prompt 可以為 AI 設定初始身份與語氣。我們為法務 Agent 設定的系統提示可能像這樣：
你是一個專業且嚴謹的企業法務助理 AI，擁有豐富的法律知識和合約審閱經驗。你將幫助公司回答法律相關的問題、總結合約重點，提供的答案需符合公司內部合規標準。
回答時請使用正式且禮貌的語氣，條理清晰，必要時引用相關法規條文。若遇到無法確定的法律問題，坦誠說明並建議諮詢律師。
透過上述系統提示，我們明確限定了 AI 的身份（法務助理）、專業領域（法律、合約）以及回答風格（正式、謹慎）。接下來，在使用者提示 (User Prompt) 中再放入使用者的問題和先前檢索到的知識片段。例如：
使用者問題：請問「XYZ 合約」中的終止條款主要內容是什麼？有哪些注意事項？
合約內容片段：... (此處插入向量檢索得到的終止條款相關段落) ...
最後我們可能再加上一些指示，例如「請以法律助理的口吻進行說明，條列重點並簡潔明瞭地回答」。完整 Prompt 送入 GPT-5 後，AI 便會按照我們設計的身份和語氣要求，基於提供的合約內容產生答案。這種 提示工程（Prompt Engineering ） 手法，確保了不同部門的 Agent 即使背後用的是同一個大模型，表現出來的風格和專長卻截然不同——法務助理永遠嚴謹專業，而非用客服那套語氣回答法律問題。
法務領域的查詢可能多元且複雜，我們需要在 Agent 內部實現條件式的對話流程，根據問題類型執行不同的處理步驟。例如，當法務助理接到提問時，可以先分類是合約摘要還是法規查找，再決定後續行動。下面是一個簡化的指令規則示意表：
| 問題類型 | 判斷條件 | 指派動作 | 處理流程 |
|---|---|---|---|
| 合約摘要請求 | 包含「合約」「摘要」等關鍵詞，且附有合約名稱或內容引用 | 使用 合約向量檢索工具 | 查找合約內容片段 -> GPT-5 總結 |
| 法規條文查詢 | 包含「法規」「規定」「法律」等關鍵詞 | 使用 法規資料檢索工具 | 檢索相關法規條文 -> GPT-5 說明 |
| 一般法律問答 | 未明確提到合約或法規 | 使用 通用法律知識 | （可選）先搜尋內部知識庫 -> GPT-5 回答 |
| 超出範圍或無法回答的問題 | 法務領域無相關資料 | 交還人類或輸出拒答 | 提供道歉或轉交人工的回覆 |
在 Odoo 實作上，我們可以透過 Python 程式碼實現上述邏輯。例如在法務助理的模型方法中，根據輸入文字內容判斷類型：
def answer_legal_query(self, question):
# 簡單的規則判斷問題類型
if "合約" in question and any(x in question for x in ["摘要", "重點"]):
context = self.vector_search_contract(question) # 向量檢索合約段落
prompt = self.compose_prompt(role="legal", user_q=question, context=context)
elif any(x in question for x in ["法規", "法律", "條文"]):
context = self.search_regulation(question) # 檢索法規條文文本
prompt = self.compose_prompt(role="legal", user_q=question, context=context)
else:
prompt = self.compose_prompt(role="legal", user_q=question)
# 呼叫 OpenAI GPT-5 取得回答
answer = self.call_gpt5(prompt)
return answer
上述程式碼中，我們定義了一個 answer_legal_query 方法，內部透過簡單的關鍵詞判斷來分類問題。針對「合約摘要」或「法規查詢」，調用不同的檢索函式取得相關背景內容，再組裝 Prompt 發送給 GPT-5。對於一般法律問答則直接生成 Prompt。這種條件式工作流程確保了法務助理能根據具體情境選擇最佳的解決方案，例如先檢索再回答或直接回答，提升回答的準確性與效率。
值得注意的是，在回答完畢後，法務 Agent 也會將每次對話的結果與依據記錄下來。例如保存 GPT-5 的回答內容、用過哪些檢索結果等，形成可審計的回答紀錄。這對於法律領域尤為重要，方便日後稽核 AI 是否引用了正確的條款，以及在必要時讓律師覆核 AI 的意見。
💡 Gary’s Pro Tip｜精準依據使用者意圖，導向不同流程
在上面的例子中，我們用了一個很簡單的方式來判斷使用者問題的意圖，然而實際應用上，這種判斷經常會遇到錯誤分類的問題，更好的方式還是使用便宜、較小的 LLM 來做意圖的 routing，然後不同的流程可更好的處理不同種類的使用者問題。
除了法務，企業內還有許多部門能受惠於量身定制的 LLM Agent。以下我們簡要介紹客服與銷售 AI 助理的設計亮點，看看它們如何各展所長。
客服 AI 助理主要服務於客戶的即時提問與問題反饋。它需要能處理多通道訊息（如 LINE、電子郵件甚至網站聊天），並且保持一致的服務品質。其設計關鍵包括：
銷售 AI 助理則聚焦於支援業務同仁進行客戶管理和銷售分析。它有幾項特長：
在了解各專屬 Agent 的本領後，我們再把視角拉高一點：如果一個請求同時涉及多個部門知識，例如一個複雜問題需要法務和銷售助理協同處理，該怎麼辦？這就引出「多 Agent 協作模型」的設計思路。我們可以透過 Router Agent 或 Multi-Tool Agent 這兩種方式，實現 AI 助理之間的分工合作。
Router Agent 可以理解為一個負責分配任務的中控 Agent。當使用者提出複合型問題時，Router Agent 先對問題進行解析，拆解出屬於不同領域的子任務，然後將這些子任務路由給對應的專家 Agent 去處理。最後再彙總各路結果，形成統一的回答。
舉例來說，假設使用者詢問：「請幫我摘要這份合約的重點，並提供一段給客戶的後續跟進建議。」這其實包含兩部分：合約重點摘要（法務）和銷售跟進建議（業務）。Router Agent 收到後，會拆解出「合約摘要」和「後續建議」兩項，分別指派給法務助理和銷售助理執行。協作流程如下圖：
如上所示，Router Agent 像個調度員，負責「任務拆解 -> 指派 Agent -> 收集結果 -> 組裝回答」。這種模式充分利用了各專家 Agent 的長處，讓整體回答更加完整。同時在 Router Agent 的實現中，我們可以預先定義子任務類型與對應 Agent 的路由規則（類似前述指令規則表），也可以運用 GPT-5 的自我檢查能力，讓模型判斷需要哪些專家參與。
實務上，這可以結合 OpenAI 的函式調用 (function_call) 功能：定義每個子任務為一個可被呼叫的工具，由 GPT-5 根據問題自主決定呼叫順序，彷彿 AI 自導自演完成任務。多 Agent 的協同作用使得 AI 系統能應對更複雜多樣的需求，正如有研究指出，協調多個專精 AI 代理執行任務，可比單一代理來得更有效且靈活。
另一種協作思路是Multi-Tool Agent，即由同一個 Agent 根據需要靈活使用多種工具或資料源來完成任務。在這種設計下，我們不是啟用多個不同 Agent，而是賦予某個 Agent 多種能力。例如銷售助理本身除了會讀取CRM，可能也能存取法務知識庫成為「全能型助理」。他在需要時可以先用工具A檢索合約內容，再用工具B拿客戶數據，最後綜合兩者回答。
Multi-Tool Agent 的實現也常用到function calling機制。我們定義一系列「工具函式」給 Agent 調用，例如 tool_search_contract()、tool_get_customer_data() 等，並在 Prompt 中告訴 GPT-5 何時該用哪個工具。這樣，AI 可以在一次對話中多次呼叫不同工具，逐步完成複雜任務。雖然從架構上看只有一個 Agent，但它內部其實以多工具達到與多Agent相似的效果。
Router Agent vs Multi-Tool Agent 的選擇，取決於系統複雜度和可維護性。前者邏輯更清晰，各 Agent 模塊責任單一，適合模組化團隊開發；後者減少 Agent 數量，所有能力集於一身，但Prompt設計更繁複。在我們這個企業場景中，如果各部門 AI 助理需求明確且邏輯獨立，採用 Router Agent 協調多個專家是較自然的做法。而無論哪種方式，其目的都是為了讓 AI 系統具備協作能力，在需要時能整合多方智慧共同解決問題，達成1+1>2的效果。
💡 Gary’s Pro Tip｜複雜的 Agent 設計，會使開發除錯變得異常困難
在上面提到了兩種的設計方式，我自己是比較推薦第一種的，下面的心法也會提到一些，對於一開始做 agent 開發的人，會很容易想把單一 agent 賦予非常多的功能，預想其可以完成非常多複雜的任務，然而當你選擇這樣的方式之後，就會發現在測試跟除錯時，由於 AI 輸出的不固定特性，會讓整個過程變得很難追蹤與偵錯。
在設計多 Agent 協作機制時，不只有「Router Agent vs Multi-Tool Agent」的抽象層級，下面介紹幾個業界的設計原則與優秀實作經驗，對我們構建可維護、可靠的多 Agent 系統非常有啟發性：
12-Factor Agents（HumanLayer）：這是一組 LLM Agent 設計準則，強調將 Agent 視為「可靠軟體 + LLM 步驟點綴」的工程體系，而非將 LLM 套在一堆非結構化邏輯上。該指南提到的幾個關鍵因素特別值得在多 Agent 設計中採納：
採納這些原則後，我們在 Router Agent 和子 Agent 的設計中可以更加理性。Router Agent 本身就是一個輕量的任務分派者，而各專屬助理（法務、客服、銷售）則保持它們的小而專注角色。這樣在未來新增部門、優化 Prompt 時，各 Agent 不會互相牽制，能保持良好的維護性與清晰結構。
Decoding Claude Code（MinusX）：這篇文章剖析了 Claude Code 如何在實際運作中展現「用戶感受良好」與「可控性強」的 Agent 設計思路。幾個可借鏡的設計原則：
把這些理念融合進我們的多 Agent 協作設計後，我們可以讓 Router Agent 的控制迴圈更簡潔、有條不紊，避免過度分支。子 Agent 若要開展子任務，也可以設計成「一次 spawn、一層深度」的方式，而不是無限制遞迴。另一方面，在成本與效能考量上，子 Agent 可選擇將簡單查詢任務交給小模型處理（如摘要或分類），只將核心推理任務交給 GPT-5，以控制資源與回應延遲。
說完原理，我們來看看部分實作片段，加深對行為定制與多 Agent 調用的理解。
首先是行為定義與 Prompt 模板的設計。在 Odoo 的 LLM Agent 模組中，每個 Agent 可以有自己的系統提示詞和參數。我們可以透過建立記錄或寫入設定檔的方式來定義。
例如，以下展示如何以 Python 定義三種助理的系統提示：
# 定義不同部門 AI 助理的 System Prompt 模板
SYSTEM_PROMPTS = {
"legal": (
"你是一個專業嚴謹的法務助理 AI。"
"熟悉各類合同條款與相關法律規範，"
"回覆時須引用法律依據，語氣正式嚴謹。"
),
"support": (
"你是一個貼心且知識豐富的客服助理 AI。"
"善於以簡潔友善的語氣回答客戶問題，"
"提供清楚的解答並適時給予關懷。"
),
"sales": (
"你是一個精明可靠的銷售助理 AI。"
"擅長分析客戶資訊與銷售數據，"
"給出具洞察力的建議，語氣自信積極。"
)
}
在運行時，系統會根據使用者所選或路由到的 Agent，取出對應的 SYSTEM_PROMPTS[agent_name] 作為對話開場白，配合使用者的提問組裝完整 Prompt 送給 GPT-5。
這種把角色人格寫死在 Prompt 模板裡的方法，讓我們能明確控制每個 Agent 的回答風格。例如法務助理不管遇到什麼問題，都會遵循「專業嚴謹」的語調，不至於像客服助理那樣開玩笑或使用過度熱情的語句。
接著看多 Agent 調用邏輯的一個簡化實例。我們實作一個 Router Agent 來協調法務與銷售助理，如前節例子：
import openai
# 定義可用的工具/函式，讓 GPT-5 知道如何請其他 Agent 幫忙
tools = [
{
"name": "ask_legal_agent",
"description": "向法務助理提問，參數為使用者的法律/合約問題",
"parameters": {
"type": "object",
"properties": {
"question": {"type": "string"}
},
"required": ["question"]
}
},
{
"name": "ask_sales_agent",
"description": "向銷售助理提問，參數為使用者的銷售/客戶相關問題",
"parameters": {
"type": "object",
"properties": {
"question": {"type": "string"}
},
"required": ["question"]
}
}
]
user_input = "幫我看一下合同X的重點，順便建議下一步該跟進客戶什麼?"
# Router Agent 的提示，指導 GPT 如何拆解
system_msg = "你是一個任務分配 AI，會判斷使用者需求並呼叫適當的工具。"
messages = [
{"role": "system", "content": system_msg},
{"role": "user", "content": user_input}
]
# 請 GPT-5 模型自動決定是否使用工具（哪個Agent）
response = openai.ChatCompletion.create(
model="gpt-5",
messages=messages,
functions=tools,
function_call="auto" # 讓模型自行選擇使用何種工具
)
reply = ""
if response.choices[0].finish_reason == "function_call":
# GPT 判斷需要呼叫子Agent，例如法務Agent
func = response.choices[0].message["function_call"]
if func["name"] == "ask_legal_agent":
legal_answer = legal_agent.answer_legal_query(func["arguments"]["question"])
# 將法務Agent的回答插入，再次讓GPT考慮下一步
messages.append({"role": "assistant", "content": None, "function_call": func})
messages.append({"role": "function", "name": func["name"], "content": legal_answer})
# 續調用GPT
response2 = openai.ChatCompletion.create(model="gpt-5", messages=messages, functions=tools, function_call="auto")
reply = response2.choices[0].message["content"]
以上程式碼片段演示了如何利用 OpenAI 的Functions機制，讓 Router Agent 自主決策調用子助理。我們定義了兩個虛擬函式 ask_legal_agent 和 ask_sales_agent 作為工具介面，描述了何種問題該給哪個 Agent。
當使用者輸入複合請求時，GPT-5 根據 System 指示嘗試解析，如果決定需要法務助理介入，便返回一個 function_call 要求。我們擷取這個要求後，實際調用之前實作的 legal_agent.answer_legal_query 取得法務助理的答案，再將該答案以函式回傳結果的形式 (role=function) 加回對話。
GPT-5 接著會根據新的對話狀態（已經拿到法務資訊）繼續進行，可能下一步再呼叫 ask_sales_agent 或直接產生最終回答。這種階段式的Tool Routing流程，使得整個對話可以靈活地在多個子 AI agent 之間傳遞。
雖然上述代碼僅展示了概念，實際應用中我們需要考慮更多錯誤處理與流程控制，但它已體現出多 Agent 系統背後的關鍵思想：將複雜問題拆解為子任務，交由適當的智慧體處理，最後彙總結果。
💡 Gary’s Pro Tip｜客製化多部門 AI 助理
差異化角色人格：要讓同一套 LLM 在不同部門中扮演不同角色，系統提示詞和Few-Shot 範例是關鍵。針對每個部門撰寫獨特的身份描述和語氣要求，必要時提供該角色的示範 Q&A。比如法務助理的示範回答應嚴謹引用法條，客服助理則親切簡潔。清晰的人格設定能幫助模型在各情境下切換自如，一秒變身對的角色。
控制 Prompt 長度與精度：隨著上下文資訊（合約片段、客戶資料）的增加，Prompt 可能變長，佔據大量 token。建議對檢索到的內容做摘要與篩選，保留要點再給 GPT，以降低 token 消耗。同時可利用 OpenAI API 的 max_tokens 參數限制回答長度，或在提示中明確要求「回答不超過 N 字」。若擔心模型跑題，可以在系統提示加上任務重申（例如：「只回答與合約內容相關的部分」）來提高回覆精度。
對話與執行紀錄：為了讓每次對話可溯源，在實作時應建立 AI 對話與執行日誌機制。可以將使用者問題、Agent 做的檢索動作、GPT-5 產生的每個中間結果，都依序記錄在 Odoo 模組的模型（如 ai.agent.log）中。這麼做有幾大好處：一是方便開發者Debug模型行為，例如檢視哪個步驟出錯導致回答不佳；二是滿足法遵需求，某些領域可能要求保留 AI 給出建議的依據；三是有助於日後優化，透過分析日誌可以調整 Prompt 或規則，使 Agent 表現持續進步。記錄雖增加了一點儲存成本，但換來的是整個 AI 助理系統的透明度與可靠性提升。
透過今天的介紹，我們可以看到企業部署一套多部門 LLM AI 助理，將為日常營運帶來革命性的效率提升與知識復用。
每個部門的專屬 Agent 不僅能快速處理各自領域的大量資訊查詢，更可在需要時協同合作，提供跨領域的綜合答案，彌補傳統單一助手的局限。當 AI 助理們各司其職又互相支援時，企業內部隱性的知識孤島被打破，知識與數據的價值被最大化地挖掘出來。
iThome鐵人賽
看影片追技術