在開發 AI 系統時，許多工程師容易陷入一個誤區：試圖用一個巨大的 LLM（大型語言模型）解決所有問題。然而，在生產環境中，尤其是面對像 NVIDIA 這種管理大規模 GPU 叢集的複雜場景時，「通用性」往往意味著「不可靠」。
要打造一個真正可落地且高可靠的 AI 平台，核心在於平衡「決定論工具（Deterministic Tools）」的確定性與「AI Agent（智能體）」的探索能力。
決定論工具與 Agent 的定位
在工程實務中，我們必須區分兩種不同的處理邏輯。決定論工具是指輸入 A 必定得到 B 的系統，例如 SQL 查詢、API 調用或固定的業務邏輯。這類工具解決的是確定性問題，例如：計算 GPU 的數量、執行特定的重啟指令。
而 AI Agent 則是用於「探索（Discovery）」與「推理」。它們擅長處理模糊的指令、分析模式或在大量數據中尋找異常。如果我們強迫 AI 去做決定論的工作（例如用 LLM 直接計算數字），就會出現幻覺（Hallucination）；反之，如果所有流程都寫死在 if-then 邏輯中，系統將失去處理複雜、未知問題的能力。
可靠 Agent 平台的架構設計：分層體系
為了避免 AI 因為面對過多選擇而產生「選擇悖論（Paradox of Choice）」，建議採用類似組織架構的分層 Agent 體系，將複雜問題拆解為小而專精的單元。
第一層：檢索 Agent (Retrieval Agents) 這類 Agent 的職責極其單一，例如將自然語言轉換為特定的 SQL 或 Elasticsearch 查詢。它們不負責分析，只負責從數據庫中精準地取出數據。
第二層：分析 Agent (Analyst Agents) 分析 Agent 不直接接觸數據庫，而是理解特定領域的知識（例如：GPU 過熱的常見原因）。它們會調用多個檢索 Agent 獲取數據，並進行邏輯推理。
第三層：編排 Agent (Orchestrator Agents) 負責接收高層目標，將任務分配給對應的分析 Agent，並整合最終結果。
第四層：執行 Agent (Action Agents) 將分析結果轉化為實際操作，例如在 Jira 開單或發送 Slack 通知。
這種分層設計的關鍵在於「約束」。當你限制 LLM 的任務範圍越小，它的可靠性就越高。
提升 AI 可靠性的三個實務技巧
稀有上下文 (Rare Context) 的注入 通用模型並不了解每家公司的內部術語。例如，維運工程師口中的「殭屍節點 (Zombie Nodes)」在不同公司定義不同。如果沒有注入這些公司特有的稀有上下文，AI 的回答將像個不合格的實習生。這意味著零樣本（Zero-shot）的通用 Agent 在企業環境中幾乎不可行，必須結合 RAG 或微調來注入領域知識。
簡化 Schema 與降低複雜度 不要給 AI 過於複雜的數據庫關聯表（Joins），這會大幅增加推理錯誤率。實務上，提供扁平化的 Schema（Flat Schema）或簡單的讀取 API，能顯著提升 AI 提取數據的準確率。
建立 LLM-as-a-Judge 的測試金字塔 AI 系統的測試不能只靠隨機抽樣，而應建立測試金字塔： 單元測試：針對底層檢索 Agent，驗證其生成的查詢是否正確。 集成測試：驗證分析 Agent 是否能正確聚合多個底層 Agent 的結果。 端到端測試：驗證頂層監督 Agent 是否能達成最終目標。 由於 LLM 的輸出是非決定性的（同樣的問題每次回答措辭不同），建議使用另一個高能力的 LLM 作為裁判（LLM-as-a-judge），來判定輸出結果在語義上是否正確。
對工程師的啟發：保持品味與判斷力
面對 AI 時代，工程師的核心價值將從「編寫邏輯」轉向「定義品味與邊界」。
我們應該尋找那些所謂的「笨鑽石 (Dumb Diamonds)」場景：即那些人類雖然在做，但實際上不需要深思熟慮、僅是為了流程而勾選的重複性工作。這些是 AI Agent 最容易切入且能快速產生價值的地方。
最後，必須牢記：凡是涉及金錢、權限變更或高風險操作的環節，必須保留「人類在環路中 (Human-in-the-loop)」的審核機制，並使用權限受限的獨立身份（Identity）來執行 Agent，而非直接使用使用者的最高權限。
來源：infoq.com (Designing AI Platforms for Reliability: Tools for Certainty, Agents for Discovery)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。