先別急著買 agent framework：企業先寫清楚 AI 代理的介面合約

周一早上 5 點，營運中心正在換班，客服、採購、財務三邊同時開會。客服主管請第一組 AI 代理把 48 件客訴整理成回覆草案，採購主管再叫第二組代理抽取供應商延遲資料，財務要求再用第三組代理核對付款例外。回報都很快，主管暫時放下了警訊，直到第二版資料上線後，卻發現有兩筆訂單同時被標成「可補貨」，一筆卻已經停產，另一筆又少了法務核可時間戳記。

這不是模型太弱，也不是工具太少，最初問題是沒有先寫介面合約。

[IMAGE:opening]

> ALTOS LAB 判斷：先別追逐框架名單，先定義交接邊界與回復責任，這是企業可持續擴張 AI 代理的起跑線。

Anthropic 的重點

Anthropic 的 Building Effective AI Agents 提醒：先用最簡可行解開始，明確區分預先定義的流程與需要代理動態決策的場景。固定流程的部分可以固定成工具化標準步驟，真正需要代理處理的部分才交給代理調度。

第一條：上下文交接卡（Context Contract）

在每個任務前先約定「可用資料、禁入資料、更新時效、資料權責」四件事。這不是文件美學，是營運記憶保險。當後續追問「為什麼這個答案是這樣」時，能立刻回到該卡。

先定義「交接面」：工具、授權與批准節點

OpenAI Agents SDK 的設計核心在於：若應用要自己掌握編排、工具執行、核准流程與狀態，才值得採用。企業可直接對應到「誰能呼叫哪個工具、什麼情況要人審核」這條線。

建議把這三個欄位放進日常運行文件：

• 入口：此任務可以讀到哪些欄位？
• 動作：可自動執行、需核准、需人工拒絕的清單？
• 結束：任務完成要留下什麼證據，誰能最後按下發佈鍵？

[IMAGE:mechanism]

Google ADK 與 MCP：讓多模型與多工具能合作，前提仍是「合約可落地」

Google 的 ADK 把 build、interact、evaluate、deploy 當作常態節奏，並支援多代理協作與 MCP 工具介面。這組訊號很重要：ADK 的價值在於把流程拉長，而非把責任取消。 MCP 像一個通用插孔，把 AI 應用、資料庫、工作流連起來；插頭越多，端口越容易錯接。

在這個階段，Source Card 的欄位最好納入：任務目的、輸入快照、工具清單版本、授權等級、結果驗證方式。它不求華麗，但能讓來源與決策關係成為日常操作習慣。

NIST AI RMF：將可回退、可驗證、可維持當成一體

NIST AI RMF 1.0 是自願框架，但它的方向非常實際：信任度要嵌進設計、開發、使用、評估四段。也就是「先定義，再驗證，最後保留可修正空間」。只要設計成「可回到人工」的結構，代理就不會是黑盒，而是工作隊列中的一個受控角色。

ALTOS LAB 的現場實務建議是：每天固定 10 分鐘做「來源卡回寫」，確認今天有無任務缺失簽核節點、證據鏈不全、或無回復路徑。你會發現，這個動作比再加一個新 framework 更快帶來實際穩定。

建議企業先走的三步

第一步，做「代理啟動前檢查表」：輸入是否完整、授權是否清楚、預期結果是否可證明。 第二步，設計「工具與批准矩陣」：高風險動作只能到人機共識。 第三步，建立「每日 Source Card」：每一筆重要代理任務都要回寫目的、證據與回復人。這三步，讓速度和風險都被放在同一個控制台。