昨天把「description 是 prompt」這件事定了性，也點出它同時是路由依據跟計費依據，而且這個模式泛化到 tool description、MCP 工具說明、subagent 描述，全部是同一件事。既然要當 prompt 寫，就有寫法上的講究，這篇整理我自己踩過之後留下的兩條底線。

寫法上的兩個推論

第一，寫「什麼情況該找我」，不要寫「我是什麼」。 LLM 做的是條件匹配，需要的是判斷依據。「處理訂單相關查詢」比「訂單服務」有用，因為多給了一個可以匹配的動詞；「使用者提到取消、退款、修改已下訂單時使用」又比前者更有用，因為觸發條件寫得更具體，模型不用自己腦補「相關查詢」到底包含什麼。觸發詞越具體，路由判斷的變異就越小。

第二，邊界模糊的兩個 agent 要在各自 description 裡互相排除。 如果 A 是「查詢商品」B 是「查詢訂單」，使用者問「我上次買的那個還有貨嗎」時路由會抖，因為這句話同時沾到商品跟訂單兩邊。解法是在 A 裡明講「若使用者指涉特定歷史訂單，交給訂單 agent」，把模糊地帶的判斷權明確交出去，別讓兩邊都覺得自己可以接。

這個做法本質上是在 prompt 裡寫 if-else，看起來很土，但目前沒有更好的辦法。路由的判斷力上限就是模型讀那幾行字的理解力上限，寫得越含糊，模型能做的判斷就越粗。

沒有靜態檢查，那怎麼防

兩條底線都寫得出來，不代表寫完就安全。既然 lint 跟 type check 都碰不到這一層，能防的手段大概只剩一種：把「這句話該路由到哪」列成一組固定的測試問句，每次改動 description 就手動跑一輪，看路由結果有沒有變。這比較像回歸檢查的土法煉鋼版，不是正式的自動化測試，但總比完全不檢查好。這個做法我自己還在想怎麼落地，先當一個推論方向記下來。

收尾

Agent Card 這三篇的重點：那張卡是程式的一部分，會計費也會影響路由，但沒有任何靜態檢查在保護它。寫壞了不會有紅字，只會在某一天路由歪掉的時候才被發現。