最後一篇，回到一個很普通的 Request。

使用者在聊天視窗裡說：

幫我把剛才那幾筆工作整理一下，確認哪些真的完成了，還沒完成的往下處理。

這句話裡沒有 Tool 名稱。

沒有 API。

沒有 Internal ID。

也沒有寫執行順序。

但真正把它做完時，後面其實發生了很多層轉換。

AI 先把 Request 拆成幾個工作意思：

Target
Operation
Completion condition

接著找到對應的工作物件。

系統把自然語言轉成自己的 Identifier。

某些資訊從文件裡讀。

某些狀態從正式系統裡查。

要改變 State 的地方，再進 Write Path。

最後還要重新讀回結果，確認工作真的到達預期狀態。

從頭到尾，沒有任何兩層長得一樣。

人看到的是一句話。

AI 看到的是 Intent。

Tool 看到的是 ID、Field、Action。

最後驗證的人看到的，又是另一組 Evidence。

但如果這些東西都在處理同一份工作，它們中間必須有一些東西不能跟著介面一起改掉。

統一介面，看起來是最簡單的答案

在很多 AI 導入裡，一致性很容易被理解成：

大家用同一套工具。

所以公司會想統一 Portal。

統一 Template。

統一 Agent。

統一 Workflow。

這些事情不是沒有價值。

但前 29 天一直反覆出現的問題，幾乎都不是因為畫面長得不一樣。

同一個 Ready，不同人可能代表不同 State。

同一個 Search Result，不一定是同一個 Object。

同一份 SOP 和 Runtime Log，也沒有資格證明同一件事。

知道怎麼做，不代表被授權去做。

API 回成功，不代表 Resulting State 已經成立。

同一個 Runtime 裡，不同 Scope 甚至可以有不同 Source of Truth。

這些問題，就算全部搬進同一個 UI，也不會自動消失。

真正需要留下來的，是跨層不變的東西

回到一開始那個 Request。

使用者要的不是：

呼叫某個 API。

也不是：

把某個欄位改成某個值。

他真正要的是一個 Work Result。

所以當工作從 Human 往 AI、再往 Tool 傳時，至少有幾件事不能漂掉。

第一個是 Meaning。

我們現在到底在處理哪一件工作？

第二個是 Evidence。

什麼資料有資格支持這個判斷？

第三個是 Decision / Boundary。

誰可以判斷？什麼情況必須停？什麼情況才允許往下？

第四個是 Action。

真正要改變的是哪個 State？

最後是 Verification。

做完後，什麼結果才算真的完成？

這五件事在不同介面裡可以有不同表達方式。

但它們不能各自長成不同答案。

Human、AI、Tool 不需要講同一種語言

這點很重要。

如果要求所有人都理解底層 Tool，最後只會把 implementation complexity 丟回使用者。

使用者不需要知道 Internal ID。

也不需要知道哪個 Specialist Skill 會接手。

AI 不需要把所有 Runtime Detail 全部丟回聊天視窗。

Tool 更不需要理解人的完整敘事方式。

所以真正的目標不是：

Human = AI = Tool

而比較像：

Human language
    ↓
AI interpretation
    ↓
System action
    ↓
Verification evidence

表面可以不同。

但底下處理的必須是同一份 Work Contract。

前 29 天其實一直在補同一張圖

Day 1 的問題是：

大家都做得更快，卻不一定在做同一件事。

後來我們一路拆到：

Meaning
Evidence
Decision / Boundary
Action
Verification

有時問題出在 State 的意思。

有時出在 Evidence 被拿去證明不該證明的東西。

有時出在 Handoff 把 Original Intent 弄丟。

有時 Write 已經發出去了，但沒有人確認 Resulting State。

這些看起來像不同種類的 IT Operation 問題。

但放在一起後，可以看見一個共通結構：

一份工作在經過不同 Human、AI 與 Tool 時，需要有一組可以跨介面保存的共同契約。

到了這裡，才需要替它取一個名字。

我現在比較習慣叫它：

Shared Work Protocol

它不是另一個 Agent Framework

這個名字如果只拿來畫一張 Architecture Diagram，其實沒有太大意義。

它真正要解決的，是很普通的工作問題。

例如使用者說：

幫我把剛才那幾筆工作處理完。

系統最後應該能回答的不是：

Tool call succeeded.

而是更接近：

3 items checked
2 completed and verified
1 stopped before write
Reason: approval still undecided

中間可以換 Tool。

可以換 API。

可以換 AI。

甚至不同角色可以看到不同的文件。

只要這份工作的 Meaning、Evidence、Boundary、Action 與 Verification 沒有在交接中漂掉。

最後留下來的不是同一個畫面

那張工作單最後被貼到 Review Room 的白板上。

左邊是使用者原本的一句話。

中間是 AI 拆出的 Target 和 Action。

右邊是系統最後的 Resulting State。

最下面放著驗證結果。

四塊內容長得完全不一樣。

沒有人想再把它們改成同一種格式。

白板旁邊只多寫了五個詞：

Meaning
Evidence
Boundary
Action
Verification

工具可以不同。

但工作的意思，不能不同。