這個領域還在成形

Day 5 就老實說過：OpenTelemetry 的 GenAI 語意慣例目前仍在 Development／Experimental 階段，尚未正式穩定。這篇作為系列的前瞻收尾，談談這個領域接下來可能怎麼走，以及對實務工作的意義。

目前的不穩定性代表什麼

規格還在演進的實際影響是：不同 SDK 對同一個概念可能用不同的屬性名稱，或是新舊命名並存於過渡期。這對實務工作的意義是——如果你的 Dashboard 直接依賴某個特定屬性名稱做過濾，當 SDK 版本更新導致命名變動時，Dashboard 可能會安靜地漏掉一部分資料，而不會報錯。

務實的因應方式包括：把屬性名稱當成有版本的契約來管理、在匯出層做命名正規化、以及定期驗證 Dashboard 的資料涵蓋率是否符合預期。

三個值得關注的方向

方向一：Agent 編排與多 Agent 的語意標準化。 目前的規格對單次 LLM 呼叫的描述已相對成熟，但對「多 Agent 如何協作」這件事的標準化仍在發展。隨著多 Agent 系統普及，這塊的標準會越來越重要。

方向二：品質評估的標準化。 Day 20 提過品質代理指標目前多半要自己設計。如果評估結果的表達方式能標準化，不同工具之間的品質資料就能互通。

方向三：內容處理與隱私的最佳實踐。 Day 11 與 Day 14 反覆提到的「內容放事件不放屬性」，反映的是這個領域正在形成的一種共識：可觀測性系統本身也需要資料治理。這方面的規範與工具支援還在成熟中。

給讀者的建議

面對還在演進的標準，比起追逐每一個版本變動，更重要的是掌握設計原則：三層次框架（基礎設施／模型呼叫／決策邏輯）、三支柱的分工（Log 記內容、Trace 記結構、Metrics 記趨勢）、以及「先想清楚要回答什麼問題，再設計欄位」——這些原則的變動速度，遠比屬性名稱慢得多。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。
IG：@aid3fend

有想討論的架構細節或不同意見，留言或私訊都歡迎。