Data Machi 並不是一開始就被設計成完整的企業 Agent。

當我們看到一張結構完整的 AI 系統架構圖時，很容易以為開發團隊從第一天開始，就已經清楚規劃好模型、工具、知識庫、Agent 與工作流之間的關係。但實際情況通常完全不同。

Data Machi 最初只是一個能讀取 Google Sheets、協助分析需求工單的簡單工具。隨著使用者提出的問題愈來愈複雜，資料來源逐漸增加，系統才一步一步加入文件檢索、工具選擇、錯誤處理與流程控制，最後演進成現在的企業知識工作流系統。

這段演進歷程值得被完整記錄，因為真正困難的部分，往往不是完成一個可以展示的 Demo，而是處理真實使用情境中不斷出現的例外、模糊問題與不穩定行為。

第一階段：從結構化資料查詢開始

Data Machi 最初的目標很單純：讓使用者可以直接用自然語言查詢 Google Sheets 中的需求工單資料。

例如：

「今年總共有幾張需求工單？」

「各個需求分類的占比是多少？」

「哪一個市場提出的需求最多？」

在這個階段，AI 的角色很接近一個具備自然語言介面的試算表助手。使用者不需要記住欄位名稱或撰寫公式，只要用一般語言描述問題，系統就能讀取資料並整理結果。

看起來很簡單，但很快就會遇到第一個問題：模型必須理解試算表的資料結構。

它需要知道：

• 哪一列是欄位名稱
• 哪個欄位代表市場
• 哪個欄位代表需求類型
• 日期欄位應如何解析
• 測試資料與正式資料如何區分
• 空白值與異常值應如何處理

只要試算表增加一個欄位、修改欄位名稱，或調整分類方式，系統原本的理解就可能失效。這表示，單純讓模型「讀到資料」還不夠，還需要同步維護資料結構與欄位定義。

這是 Data Machi 的第一個重要學習：

連接資料來源，不代表系統已經理解資料。

第二階段：加入文件檢索與業務定義

當系統能回答數字問題後，使用者很自然地開始提出更深入的問題。

例如：

「Priority 欄位中的高、中、低是怎麼定義的？」

「這一類需求工單的處理 SLA 是多少？」

「哪些情況應該被歸類為 Data Request？」

這些問題無法只靠 Google Sheets 回答。試算表中可能只有 Priority = High，卻不會說明 High 的判斷標準；也可能記錄了需求分類，卻沒有解釋分類規則。

相關定義通常存在 Confluence、企業 Wiki、PDF 文件或流程手冊中。因此，Data Machi 在第二階段加入了文件檢索能力，讓系統除了查詢結構化資料，也能從非結構化文件中找到業務規則、欄位說明與背景資訊。

這也是 RAG 開始進入系統的階段。

加入文件檢索後，系統可以把數字與定義結合起來。例如，它不只回答「高優先級工單共有 32 張」，還能同時說明公司如何定義高優先級，以及這個定義來自哪一份文件。

從這個階段開始，回答不再只是產生數字，而是逐漸具備可追溯的來源依據。

但新的問題也隨之出現。當同一個問題可能需要同時查詢 Google Sheets 與 Confluence 時，使用者每次都必須指定資料來源嗎？

如果使用者問：

「今年高優先級需求增加了多少？高優先級又是怎麼定義的？」

系統就必須同時取得數據與文件定義。這使 Data Machi 進入下一個演進階段。

第三階段：讓 AI 自己判斷應該使用哪個工具

當系統只有一個資料來源時，工具選擇不是問題。但當資料來源逐漸擴充成 Google Sheets、Confluence、Trello 與 PDF 後，每次都要求使用者指定「去哪裡查」就會變得不切實際。

一般使用者通常只知道自己想問什麼，不一定知道答案存在哪裡。

例如：

「今年收到的需求主要集中在哪些類型？相關專案目前進度如何？」

這個問題可能需要：

1. 從 Google Sheets 統計台灣市場的需求分類
2. 從 Confluence 確認分類定義
3. 從 Trello 查詢相關專案進度
4. 將不同來源整合成一份回答

因此，Data Machi 在第三階段加入了 Coordinator 機制，讓系統先理解問題，再自行判斷需要使用哪些工具。

Coordinator 的工作可能包括：

• 判斷問題屬於數據、文件還是專案進度
• 決定需要呼叫一個或多個工具
• 安排工具執行順序
• 判斷第一輪查詢結果是否足夠
• 決定是否需要補充查詢
• 整合不同來源的資訊

真正的 Agentic 行為，也是從這個階段開始出現。

系統不再只是被動執行一個固定工具，而是能根據使用者問題與工具結果，判斷下一步應該做什麼。

但「能自主選擇工具」並不代表系統已經可靠。相反地，當 AI 擁有更多自主決策空間後，不確定性也會跟著增加。

它可能選錯工具、跳過必要查詢，或在工具沒有結果時自行補上一個答案。因此，Data Machi 還需要進入第四階段。

第四階段：從能用走向可靠

第三階段讓系統開始具備 Agent 的能力，第四階段則是讓系統從「偶爾能完成任務」，進一步變成「在各種情況下都有可預期的行為」。

這個階段需要處理的，不再只是正常情境，而是大量真實使用中可能發生的問題：

• 第一次查詢沒有找到資料怎麼辦？
• 模型沒有真的呼叫工具怎麼辦？
• 使用者的問題不夠明確時，應該如何釐清？
• 查詢多個工具需要很長時間時，應如何回饋進度？
• 工具返回錯誤時，系統應該重試還是停止？
• 不同來源出現衝突時，應該採用哪一個？
• 查不到資料時，如何避免模型自行猜測？
• 系統如何知道任務已經完成？

為了解決這些問題，Data Machi 開始加入：

• 上下文判斷
• 問題釐清
• 工具呼叫驗證
• 回答查核
• Timeout
• Retry
• Fallback
• 執行狀態回饋
• 明確的結束條件
• 人工審核
• 會議前後的工作流

這些功能單獨看起來都不算特別複雜，但它們共同決定了一套 AI 系統能不能在真實環境中持續使用。

也正是在這個階段，Data Machi 才開始從技術 Demo，逐漸成為一套可實際使用的企業知識工作流產品。

Data Machi 的完整演進路徑

整條演進路徑可以整理成：

Chat
  ↓ 加入企業文件
RAG
  ↓ 接上資料庫與 API
Tool Use
  ↓ 讓 AI 自主選擇工具
Agent
  ↓ 加入流程控制與錯誤處理
Agentic Workflow
  ↓ 定義業務範圍、權限與可信度機制
Enterprise AI Product

這條路徑看起來很直觀，但每一個箭頭都代表一系列真實的工程與產品設計工作。

從 Chat 走向 RAG，需要處理文件解析、Chunk 切割、Embedding 與檢索品質；從 RAG 走向 Tool Use，需要設計工具介面、參數格式、權限與錯誤回傳；從 Tool Use 走向 Agent，需要處理工具選擇、多步驟推理與上下文管理。

而從 Agent 走向 Agentic Workflow，則必須開始面對流程控制、狀態管理、錯誤重試與可觀測性。

最後，從 Agentic Workflow 走向企業產品，還需要處理權限、安全性、可信度、使用者體驗、部署與長期維護。

因此，系統的演進並不是換一個更強的模型，或再增加幾行 Prompt 就能完成。

Demo 與可使用產品之間的真實差距

許多 AI 教學會直接展示完成版架構，因為成功的執行畫面最容易理解，也最具吸引力。

但一個系統在展示時能成功回答問題，不代表它在真實環境中可靠。真正影響使用體驗的，往往是那些看起來不特別精彩，卻每天都可能發生的例外情況。

以下是 Data Machi 開發過程中遇到的幾個典型問題。

問題一：第一次搜尋找不到資料

有時使用者提出一個合理問題，系統查詢 Google Sheets 後卻得到空結果，最後回答：

找不到相關資料。

但資料其實明明存在。

常見原因包括：

• 使用者輸入的名稱與資料欄位拼法不同
• 大小寫不一致
• 欄位中包含多餘空格
• 使用者使用簡稱，資料中記錄正式名稱
• 日期格式不同
• 查詢條件過度嚴格
• 同一概念在不同資料中使用不同名稱

例如，使用者輸入 Japan，資料中可能記錄的是 JP；使用者搜尋 Data Request，欄位中則可能寫成 Data request 或 Data Analysis Request。

如果系統只執行一次精確比對，就很容易誤判為沒有資料。

因此，Data Machi 需要加入模糊查詢、名稱正規化、同義詞對照，以及多種查詢策略。在第一次查詢沒有結果時，系統不應立刻停止，而應嘗試較寬鬆的條件，或向使用者說明目前使用的查詢邏輯。

問題二：模型說正在查詢，卻沒有真的查

另一個常見問題是，模型會回覆：

好的，讓我查一下您的需求工單資料。

接著卻直接產生答案：

根據目前資訊，Q3 大約有 200 張工單。

整個過程中，模型並沒有真正呼叫任何工具。

這種情況會發生，是因為語言模型的訓練目標傾向於產生連貫且有幫助的回答。當它無法取得資料時，有時會使用語言模式補足缺口，而不是停下來承認自己沒有查詢結果。

解法不能只是再加一句「一定要呼叫工具」到 Prompt 中，而是必須在 Workflow 中驗證是否真的存在工具呼叫。

如果系統沒有偵測到工具請求，就不能讓流程進入最終回答階段，而應要求模型重新選擇工具，或由程式直接切換到查詢節點。

這正是 Day 04 所提到的概念：關鍵行為必須由 Workflow 保證，而不能只依賴 Prompt。

問題三：同一個問題是否需要重新查詢？

在同一段對話中，使用者可能會先問：

「今年台灣市場有多少張工單？」

接著追問：

「那其中高優先級有多少？」

第二個問題是否應該重新查詢工具？

如果完全不重新查詢，可以提高速度，但可能使用過時或不完整的資料；如果每次追問都重新讀取所有來源，則會增加等待時間與工具成本。

這個問題的本質，是系統缺乏明確的資料時效策略。

因此，可以針對不同資料來源定義有效期限。例如，同一次對話中的查詢結果在五分鐘內可以重複使用；但如果使用者改變分析期間、加入新的篩選條件，或資料來源本身更新頻繁，系統就應重新查詢。

這並不是單純的技術選擇，而是速度、成本與資料新鮮度之間的產品設計取捨。

問題四：等待時間太久，使用者不知道系統是否仍在運作

一個複合問題可能需要依序查詢 Google Sheets、Confluence 與 Trello。當每個工具都需要數秒，整體等待時間很容易超過十秒。

如果畫面在這段期間完全沒有變化，使用者可能不知道系統正在處理問題，還是已經發生錯誤。

因此，系統需要加入中間狀態回饋，例如：

• 正在確認問題需要的資料來源
• 正在查詢需求工單資料
• 正在查閱欄位定義
• 正在取得相關專案進度
• 正在整合查詢結果

這些狀態不只是視覺上的裝飾，而是重要的使用者體驗設計。它能降低等待焦慮，也讓使用者知道系統實際執行了哪些步驟。

這些問題單獨看來都不算複雜，但每一個都需要專門的設計與實作。

它們才是 Demo 與可使用產品之間真正的差距。

一個系統在精心準備的展示情境中可能運作得非常順利，卻可能在真實使用中反覆卡在名稱不同、查詢無結果、工具未呼叫與等待過久等問題上。

Data Machi 到底是什麼？

隨著系統能力逐漸增加，Data Machi 在不同場合也曾被稱為「數據助理」、「Data Agent」或「企業 AI 工作夥伴」。

這些名稱都描述了系統的一部分，但所傳達的期待並不完全相同。

為什麼不只叫做 Data Agent？

「Data Agent」很容易讓人聯想到數據查詢、SQL、統計分析與圖表生成，彷彿系統的核心功能只是在處理量化資料。

但 Data Machi 的實際工作範圍更廣。它除了查詢 Google Sheets，也需要從 Confluence 取得業務定義、從 PDF 理解規範、從 Trello 追蹤專案進度，並協助會議準備與後續行動。

因此，它處理的並不只是資料分析，而是橫跨數據、文件、任務與決策的一段知識工作。

如果只稱為 Data Agent，使用者可能低估系統的知識整合能力，也可能高估它在所有量化分析問題上的準確度。

「企業數據與知識工作夥伴」意味著什麼？

將 Data Machi 定位為「企業數據與知識工作夥伴」，並不代表它要模擬一位無所不能的員工。

相反地，這個定位強調的是可重複、可驗證，而且有明確範圍的工作流程。

具體來說：

• 能處理的問題類型必須有明確邊界
• 在支援範圍內，回答必須有資料來源
• 涉及即時數字時，必須真正查詢工具
• 找不到資料時，必須誠實說明限制
• 高風險操作需要人工確認
• 每次執行應該可以被追蹤與查核

明確的邊界，不是能力不足，而是企業信任的起點。

一套真正值得信任的企業 AI，不應該讓使用者以為它什麼都知道，而是讓使用者清楚知道它能做什麼、不能做什麼，以及遇到邊界時會如何處理。

系統名稱與對外溝通

系統名稱可以保留品牌感與親切感，但對外介紹時，最重要的不是名稱本身，而是能否建立正確期待。

「Agent」這個詞在市場上很容易被理解成一位可以自主完成所有工作的 AI 助理。但現實中，任何 Agent 都受到工具範圍、知識來源、權限與流程設計的限制。

因此，在向業務團隊或使用者介紹 Data Machi 時，可以使用三個問題來說明：

它能做什麼？

例如：

• 查詢需求工單數據
• 整合不同市場的需求趨勢
• 查閱欄位與流程定義
• 追蹤相關專案進度
• 整理會議前背景資訊
• 產出有來源依據的摘要

它不能做什麼？

例如：

• 無法存取尚未連接的系統
• 無法回答缺少資料來源的內部問題
• 不應取代高風險業務決策
• 無法保證理解未被文件化的隱性知識
• 不會在沒有權限時讀取敏感內容

碰到邊界時會怎麼處理？

例如：

• 明確說明找不到資料
• 顯示已查詢的來源
• 建議使用者補充條件
• 請求人工確認
• 提供下一步查詢方向

這樣的說明，比直接宣稱「它是一位什麼都能回答的 AI 助理」更能建立長期信任。

本日重點

今天只需要記住一件事：

好的 Agent 不是一次設計完成，而是從真實工作問題中持續演進。

Data Machi 從一個簡單的 Google Sheets 分析工具開始，逐步加入文件檢索、工具選擇、Agent 決策、流程控制與可靠性機制。

這段歷程也說明，一套企業 AI 產品的價值，不只來自模型能力，更來自：

• 是否理解真實工作流程
• 是否連接正確資料來源
• 是否能處理例外情況
• 是否具備明確的知識與業務邊界
• 是否能讓執行過程被觀察與驗證
• 是否在失敗時仍有可預期的行為

從下一篇開始，我們會進入 Data Machi 的第一項關鍵能力：讓 AI 找得到企業自己的知識，也就是 RAG 系統的設計與實作。