協定核心

Bricoop 協定是 Application 與 Provider 都要實作的契約，這樣 Bricoop 才能在兩者之間路由。Application 以協定的公共形態傳送請求；Bricoop 把它適配到選中的 Provider，把回應串流傳回，並以 Application 可以處理的標準化類別回報任何錯誤。協定從不會在請求主體中攜帶憑證，從不會在串流傳輸時緩衝完整回應。

請求

Application 傳送一個請求，命名模型槽位、要使用的能力以及訊息負載。Bricoop 讀取請求，解析選中的 Provider 和模型，把負載適配到 Provider 的 API，然後轉送。Application 從不直接與 Provider 通訊；本機連線層是唯一的路徑。

回應

Bricoop 把 Provider 的回應規範化為 Application 期望的公共形態，無論 Provider 傳回的是 chat completion、tool call 還是 image。Application 讀取規範化後的回應並渲染它；它不必理解 Provider 的原生格式。正是這種規範化讓每個受支援的 Application 都能與每個受支援的 Provider 協作。

串流

token 和 stream 事件穿過 Bricoop 時不緩衝完整回應。Bricoop 把每個 chunk 適配為協定的串流形態並立即轉送，因此 Application 可以在 token 到達時即時渲染。連線層增加的延遲以微秒計，而不是秒，因為它從不會等待完整回應。

錯誤

錯誤被規範化為明確的類別：無效憑證、速率限制、不支援的能力、Provider 不可達。每個類別都帶有產生它的 Provider 和模型，使 Application 能顯示精確的訊息。Bricoop 從不會把錯誤靜默降級為通用失敗；不支援的請求會被回報為不支援，而不是傳回空回應。

版本管理

協定透過 schema_version 和 minimal_client_version 進行版本管理。低於最低版本的 client 會在握手時被明確拒絕，並指出所需版本，讓使用者知道需要升級。目標 schema 比執行中 client 更新的 Provider 或 Application 也會被拒絕，從而防止出現半運作的組合。