使用者給 Agent 一個不算複雜的要求：

「把這幾筆相關工作都標成處理中，然後把剛才整理的 Note 分別放到對應的項目下面。」

Entry Agent 先解析：

Target: multiple work items
Operation: status update + note update

接著交給 Workflow Router。

Router 再把 Status 和 Note 拆給兩個 Specialist。

幾秒後，系統回覆：

5 items updated
Notes added successfully

使用者打開第一筆。

五段 Note 全部在這裡。

其他四筆只有 Status 被改了。

每個 Tool Call 都成功。

每個 Specialist 也完成了自己收到的任務。

問題發生在交接時：

原本那句「分別放到對應的項目下面」，在第二次 Handoff 後只剩下：

add notes to related items

工作沒有在任何一層突然做錯。

它只是每交接一次，就少了一點原本的意思。

Handoff 不是只傳下一個動詞

很多 Orchestration 設計會很重視 Routing：

這個 Request 應該交給哪個 Specialist？

但找到正確的人，只解決一半。

另一半是：

交出去時，原本 Request 還剩多少？

如果 Entry 只傳：

status update

Specialist 不知道哪些 Object。

如果只傳：

add notes to 5 items

它又可能不知道 Note 與 Object 之間原本有 Mapping。

所以 Package 裡 Router 的 Handoff 明確要求保留：

• original request
• target
• operation
• platform / interface context
• known identifier

不是因為 Specialist 需要重新讀一遍所有聊天紀錄。

而是交接不能只剩下一個被壓縮過的動詞。

每一層的 Summary 都可能讓 Intent 變薄

AI 很會 Summary。

這在 Handoff 時看起來尤其漂亮。

原始要求可能很長：

這五筆是同一批工作，全部進入處理中；剛才的五段 Note 各自對應不同項目，不要合併。

第一層整理成：

Update five related items and add notes.

第二層再整理：

Add notes to related items.

第三層收到後，最合理的做法可能就是把所有 Note 加到第一個已知 Target。

沒有任何一層在「故意省略」。

只是每一層都在替下一層做合理簡化。

結果 Original Intent 被一點一點壓掉。

保留 Context，不代表把整個 Conversation 全丟下去

另一個極端是：

那就每次 Handoff 都傳完整聊天紀錄。

這確實比較不容易漏。

但 Specialist 會被迫重新解析所有內容，也失去 Routing 本來應該提供的結構。

比較實際的做法，是保留能決定 Action 的 Context。

例如：

Original request:
Update all related items and distribute notes by item.

Targets:
A, B, C, D, E

Operation 1:
Set status = In Progress for all

Operation 2:
Map Note A→A, B→B, C→C, D→D, E→E

Router 可以重組。

但不能把會改變工作結果的條件整理掉。

後來他們在 Handoff 多保留了一格

那次錯誤之後，團隊沒有要求所有 Specialist 彼此聊天。

也沒有做一個更複雜的 Multi-Agent Meeting。

只是在 Handoff Payload 裡多保留：

original_intent

以及這次 Action 真正需要的 Target / Constraint。

下一次又有一批多項目的更新。

Router 拆成兩條 Specialist Path。

Status Specialist 完成五筆狀態。

Note Specialist 收到的不是「add notes」。

而是一組清楚 Mapping。

最後五筆都被正確更新。

使用者沒有看見 Handoff。

也不知道底下經過幾個 Specialist。

他只看到原本那句話，走過幾層之後，最後做出來的仍然是同一件事。