幫我申請某張業務資料表，每天抄寫一次，權限給資料分析團隊，最後交給王主管審核。

這是我想像中，第四代 DAP 的起點。

使用者先說明目的。Agent 取得資料表資訊、套用規則與既有模板，提出更新方法和 housekeeping 建議，再把少數需要人決定的內容集中列出來。使用者調整一次，確認後完成申請。

我的目標是把開單收斂在兩個回合：第一回合說明需求，第二回合調整草稿並確認。

• Agent 服務從使用者想完成的任務開始，畫面欄位成為後面的結構化資料。
• 系統查得到的資料直接取得，固定規則自動套用，既有模板先產生建議。
• 使用者集中確認業務目的、例外與正式送出，對話維持在一到兩個回合。
• 表單保留為草稿檢視與最終確認介面，Agent 負責前面的理解、查詢、建議與協調。

把表單搬進聊天室，對話還是很長

現在的 Rawdata 頁面有來源資料表、更新頻率、更新方法、目標 database、是否抄寫到地端、housekeeping、Partition、權限帳號、專案名稱與申請原因。

如果 Agent 直接照著欄位順序詢問，對話會變成這樣：

Agent：資料更新頻率？
使用者：每天。

Agent：資料更新方法？
使用者：我不確定。

Agent：是否抄寫到地端？
使用者：這張表通常怎麼處理？

Agent：是否執行 housekeeping？
使用者：請照目前的規則。

Agent：保留幾個月？
使用者：預設是多少？

這種做法把表單欄位逐題搬進聊天視窗。使用者仍要理解每個欄位、查找預設值、判斷欄位連動，最後再自己把答案組成一張申請單。

Agent 只是換了一種提問介面，服務流程仍由使用者協調。

我想要的是一份完成八成的草稿

同一句需求交給 Agent 後，我期待先收到一份接近完成的申請草稿：

已從需求取得
- 來源資料表：某業務資料表
- 更新頻率：每天
- 權限對象：資料分析團隊
- 審核人：王主管

已從系統取得
- 申請人與所屬單位
- 資料表欄位與資料等級
- 使用者可以申請的目標環境
- 資料分析團隊對應的權限帳號

已套用規則
- 敏感欄位去識別化
- 購物車目標環境一致性檢查
- 審核人資格檢查

Agent 建議
- 更新方法：append
  理由：資料表具有可用的日期欄位，需求為每日增量更新
- housekeeping：套用 Rawdata 現行模板
  理由：目前沒有例外保留條件

待確認
- 專案名稱
- 申請原因
- 是否接受更新方法與 housekeeping 建議

使用者接著回覆：

專案名稱填風險分析，資料保留改成 12 個月，其他照建議送出。

Agent 重新驗證連動規則，顯示最後的申請摘要與 Payload 影響。這句話已經包含調整與送出意圖，通過最終確認後就能建立單據。

上面的更新方法只是設計範例。正式版本必須根據資料表 Metadata、既有模板與業務規則產生建議，也要附上理由和來源。

哪些內容由 Agent 先處理

我把申請資料分成六類，每一類採取不同動作。

這個分類改變了對話的節奏。

Agent 能查到的資料直接查詢，固定規則直接執行，模板提供草稿起點。使用者把時間放在目的、例外與結果上。

Agent 的工作順序從目標開始

表單設計通常從欄位開始：這個畫面需要哪些輸入、哪些欄位必填、按鈕按下後送出什麼 Payload。

Agent 服務從使用者目標開始：他要完成哪一種申請、目前已經說了什麼、系統能補上什麼、接下來哪一個動作最合理。

我把這段工作整理成六步：

理解目的
  ↓
取得使用者與資料脈絡
  ↓
套用規則與既有模板
  ↓
產生建議與申請草稿
  ↓
集中確認少數決策
  ↓
送出並回報結果

這裡的「Agent 思維」是一份可檢查的工作順序。每一步都有資料來源、可以執行的範圍和停止條件。

OpenAI 的 Agent 實作指南將 Agent 描述為能管理工作流程、選擇工具取得資料或採取行動，並在 guardrails 內完成任務的系統。

對 DAP 而言，重點也落在「完成申請」這項任務。聊天介面只是入口，後面仍需要資料、規則、工具、權限和人工確認。

從表單走向 Agent，我遇到五個挑戰

1. 一句話通常只有部分資訊

使用者會說「每天更新到雲端」，不會主動使用 update_frequency、target_database 這些欄位名稱。

Agent 要先抽出已知資訊，再判斷哪些資料能查詢、哪些條件可以推導、哪些內容需要人決定。自然語言先轉成工作脈絡，後面才進入結構化欄位。

2. 建議要說得出來源

更新方法、housekeeping 與權限對象都可能有預設模板。Agent 可以先提出建議，同時附上模板版本、資料特性或規則來源。

使用者看到「建議保留 24 個月」時，也能一起看到這個數字來自哪一套規則。來源不足的項目直接列入待確認。

3. 修改一個欄位，要重新計算整張單

Rawdata 的欄位彼此連動。更新方法選 refresh 時，housekeeping 會切成略過；目標環境改變時，資料流向與其他購物車項目都要重新檢查。

使用者接受或修改建議後，Agent 必須重新執行驗證，再產生新的草稿版本。

4. 權限和審核人需要驗證

「權限給資料分析團隊」是一個自然語言名稱。系統真正需要的是有效帳號、角色範圍與可申請權限。

「交給王主管審核」也要確認身分、組織關係與目前流程中的審核資格。Agent 可以協助解析與查詢，授權結果仍由權限系統決定。

5. 正式送出要留下確認與證據

查詢資料、套用模板與建立草稿可以自動完成。正式送出會建立單據並啟動後續流程，因此需要一個清楚的確認點。

確認內容至少包含草稿版本、使用者調整、最後 Payload 摘要、確認人與單據結果。Agent 完成任務後，也要能回答這張單送出了什麼、目前走到哪裡。

傳統表單與 Agent 服務的差異

表單仍然保留。它會成為 Agent 草稿的檢視介面，讓使用者修改關鍵欄位、查看規則影響，也提供人工操作的備援入口。

用一張 Agent Service Canvas 開始

在設計 Tool 或選擇 Agent framework 前，我會先把現有表單填進這張 Canvas：

# Agent Service Canvas

- 使用者目標：
- 一句話中已有的資訊：
- 系統可以取得的脈絡：
- 固定業務規則：
- 可以套用的模板：
- Agent 可以提出的建議：
- 需要使用者決定的事項：
- 會改變系統狀態的動作：
- 人工確認點：
- 完成證據與失敗交接：

這張 Canvas 先檢查兩件事：Agent 是否能在第一輪交出有用的草稿，以及使用者要做的決定是否集中在一起。

Anthropic 的 Agent 設計文章提到，Agent 會使用 retrieval、tools 與 memory，根據環境回饋持續行動；工具介面也需要像人機介面一樣被仔細設計。

Canvas 裡的「系統脈絡、規則、模板與確認點」，就是後續 Agent-computer interface 的需求來源。

Day 27 先把服務想清楚

Day 26 定下第四代 DAP 的目標：讓 Agent 從協助開發，走到協助使用者完成申請。

Day 27 把焦點放在服務體驗。使用者說一次需求，Agent 先查資料、套規則、提出建議並產生草稿；使用者集中調整一次，再完成確認。

Agent Service Canvas 記錄的是這段服務如何運作。下一步再把 Canvas 中的目的、資料、規則與控制點整理成 Capability Contract，並拆成 Agent 可以安全呼叫的 Tool。

Day 28 會繼續處理這一層：查詢、驗證、建立草稿與正式送出，要如何定義輸入、輸出、權限和副作用。