免費全文 Agent 開發 實戰

把人放進迴圈:需要確認的動作該怎麼設計

刪除資料、寄信、付款這類動作不該由 Agent 自行決定。這篇是確認機制的實作模式。

Agent 開發教程封面

Agent 越有能力,誤動作的代價越高。判斷標準很簡單:這個動作能不能輕易復原。不能的,就要人確認。

把工具分成兩類

  • 唯讀工具:查詢、計算、搜尋。自動執行。
  • 有副作用工具:寫入、刪除、寄送、付款、對外發布。需要確認。
TOOLS = {
  'search_orders': {'fn': search_orders, 'confirm': False},
  'cancel_order':  {'fn': cancel_order,  'confirm': True,
                    'preview': lambda a: f"將取消訂單 {a['order_no']},此操作無法復原。"},
}

中斷與續跑

需要確認時,把當前狀態序列化存起來並回傳待確認事項;使用者同意後再從斷點續跑。這代表 Agent 的狀態必須是可序列化的。

if TOOLS[call.name]['confirm']:
    token = store.save({'messages': messages, 'pending': call.as_dict()})
    return {'status': 'need_confirm',
            'preview': TOOLS[call.name]['preview'](call.arguments),
            'resume_token': token}

確認畫面要顯示什麼

  1. 具體動作,用使用者的語言而非工具名稱。
  2. 受影響的對象,例如訂單編號、收件人、金額。
  3. 是否可復原,不可復原要明講。
  4. Agent 的理由,讓使用者判斷是不是誤解了需求。
不要用「是否繼續?」這種空泛問法。使用者連續按了幾次確認之後就會變成無意識點擊,等於沒有這道關卡。
下一步

這個主題還有更深入的實戰教程

VIP 專區收錄 50 篇進階內容:架構設計、生產環境取捨、成本與合規。 每週五新增 3 篇。

看訂閱方案 → 先逛逛 VIP 專區

延伸閱讀

更多Agent 開發 →