协议核心

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 也会被拒绝，从而防止出现半工作的组合。