第四代 DAP 的使用方式，會從一句話開始：

幫我申請一張資料抄寫單。來源是某張業務資料表，每天更新，需要同步到雲端。

Agent 讀完後，先找到「資料抄寫申請」這項功能，帶入使用者身分與資料表資訊，再把缺少的內容列出來：目標資料庫、是否抄寫到地端、更新方法、專案名稱與申請原因。

資料補齊後，Agent 產生一份申請草稿，列出資料流向、去識別化規則、保留期限與最後送出的 Payload。使用者確認內容，Agent 才送出申請並回報單據編號。

這是第四代的設計藍圖。目前的 DAP 還是由使用者操作頁面，Agent 主要協助我開發系統。接下來，我想把 Agent 移到使用者這一側。

• 第四代的目標，是讓 Agent 理解 DAP 的功能與申請規則，協助使用者完成草稿。
• Agent 需要知道每項功能的必要輸入、可自動取得的資料、業務規則、權限與副作用。
• 自然語言理解交給模型；欄位驗證、權限、互斥與 Payload 交給固定規則和受控工具。
• 正式送出保留人工確認，並留下草稿、確認內容、Tool 呼叫與單據結果。

前三代都在改善「怎麼開發」

DAP 的第一代是同事留下的 Notebook。第二代把原本的操作搬到 Web，我用 Vibe Coding 完成前端功能。第三代加入 SDD、五個角色 Agent 與指揮中心，處理需求變多之後的開發與協調。

前三代的 Agent 都站在開發者旁邊：

需求
  ↓
Spec → Plan → Tasks
  ↓
Agent 修改程式與文件
  ↓
驗證 → UAT → 上線

系統上線後，超過 100 位使用者仍要自己找到功能、讀說明、填欄位、檢查規則，再送出申請。

第四代把 Agent 放到這一段：

使用者說明目的
  ↓
Agent 找到對應功能
  ↓
補齊資料、套用規則、產生草稿
  ↓
使用者確認
  ↓
送出申請、追蹤狀態

開發流程仍然保留。新的工作是把 DAP 的功能整理成 Agent 能理解、能查詢、能驗證的能力。

一張 Rawdata 申請，背後有很多隱藏規則

我用「資料抄寫申請」當第四代的第一個案例。

現在的頁面會請使用者選資料表、更新頻率、更新方法、目標資料庫、是否抄寫到地端、housekeeping、Partition 與權限帳號。最後加入購物車，再填專案名稱與申請原因後統一送出。

使用者看到的是表單，程式裡還有一層連動規則：

• 選到聯徵資料後，要再填聯徵單號與使用帳號。
• 選定資料表後，系統會取得欄位、資料等級、更新方式與建議的日期欄位。
• 個資欄位會依類型套用雜湊或清空規則。
• 更新方法選 refresh 時，housekeeping 會切成「不做」並鎖定。
• 目標資料庫選 IRB 時，housekeeping 同樣鎖定，地端抄寫也會連動。
• 同一張資料表不能重複加入購物車。
• 同一個購物車中的 EDB 申請要使用一致的目標資料庫。
• 正式送出前還要補專案名稱與申請原因。

這些規則散落在 Spec、表單驗證、watch、Payload 組裝、共用 Store 與使用手冊裡。Agent 只讀畫面文字，只能知道有哪些欄位；它還需要知道欄位從哪裡取得、何時出現、哪些值會連動，以及這次操作會寫入什麼資料。

Day 25 的文件地圖解決「去哪裡找」。第四代還要再補一層，把找到的知識整理成可執行的功能說明。

Agent 接到需求後，要走八個階段

我先畫一張 Agent Service Blueprint，把使用者、Agent、系統與人工確認排在同一條流程上。

這八個階段和第三代的 8-Step 是兩套流程。

第三代 8-Step 管理程式開發，從需求走到文件；第四代 Service Blueprint 描述使用者提出申請後，Agent 如何完成服務。文章後面統一稱它為「申請流程」，避免兩組步驟混在一起。

模型、固定規則與人，各自負責一段

Rawdata 的申請規則很多。我把模型的自由推理範圍收在語意理解，表單規則交給可驗證的程式。

模型適合處理語意：理解使用者想申請哪一種服務、整理已知資訊、提出缺少的問題，再把系統回傳結果說明清楚。

固定規則與 Tool 負責可判定的工作：查詢使用者可選的資料表、套用欄位連動、驗證目標資料庫互斥、組合 Payload、建立草稿與查詢單據狀態。

人保留業務意圖與正式動作：確認資料用途、選擇無法推導的條件、接受申請內容與送出結果。

模型：理解、補問、說明
規則：驗證、計算、限制
Tool：讀取、建立草稿、送出、查狀態
人：決定目的、確認內容、承擔送出

Anthropic 對 Agent 的描述也包含相同結構：Agent 依任務使用工具，從環境結果取得真實回饋，遇到阻礙或需要判斷時回到人。(Anthropic, Building effective agents)

OpenAI 的 Agent 實作指南將核心拆成 Model、Tools 與 Instructions，也建議高風險或失敗超過門檻時轉交人工處理。(OpenAI, A practical guide to building agents)

第四代 DAP 的重點因此很明確：模型負責彈性，規則與 Tool 提供邊界，人在正式送出前保留控制權。

Agent 需要的資料，比表單欄位更多

要讓 Agent 協助完成申請，每項功能至少要提供以下資訊：

這張表會成為 Day 27 的 Capability Contract。它讓 Agent 在進入對話前，先知道這項功能能做什麼、需要什麼、做到哪裡要停。

第一版先完成申請草稿

第四代可以分三個階段前進。

第一階段：找到功能並補問

Agent 根據使用者描述選出 Rawdata 申請，列出已知資訊與缺少欄位。這一階段只讀文件與功能目錄。

第二階段：取得資料並建立草稿

Agent 呼叫查詢工具取得使用者可見的資料表與欄位，交給固定規則驗證，再產生申請摘要與 Payload 預覽。系統狀態停在草稿。

第三階段：確認後送出

使用者看到完整草稿、資料流向與可能影響，明確確認後，Agent 才能呼叫正式送出工具。每次送出都保存確認人、草稿版本、Tool 輸入摘要與結果。

第一版做到第二階段就有價值。使用者可以少找文件、少填已知資料，也能在送出前看到規則是否正確。草稿階段累積的失敗案例，還能拿來調整 Capability 與後續 Evals。

今天可以先畫一張 Agent Service Blueprint

先挑一個固定流程，填完以下欄位：

| 階段 | 使用者輸入 | Agent 判斷 | 系統資料／Tool | 固定規則 | 人工確認 | 產出 |
| --- | --- | --- | --- | --- | --- | --- |
| 選擇功能 |  |  |  |  |  |  |
| 取得資料 |  |  |  |  |  |  |
| 補問缺項 |  |  |  |  |  |  |
| 驗證規則 |  |  |  |  |  |  |
| 建立草稿 |  |  |  |  |  |  |
| 正式送出 |  |  |  |  |  |  |

這張圖先回答責任分配，再決定使用哪一個 Agent framework 或 Tool protocol。

第四代的第一步，是把功能說清楚

第三代處理的是開發規模。需求變多後，我用 SDD、角色 Agent 與指揮中心管理修改。

第四代處理的是服務使用。Agent 要協助使用者完成申請，就要理解功能目的、輸入來源、業務規則、權限、副作用與人工確認點。

Day 26 先畫出完整旅程。Day 27 會把 Rawdata 申請收斂成第一份 Capability Contract，讓功能從一張給人操作的頁面，變成 Agent 可以讀取的能力定義。