Provider 開發者入口
W-65 / OPT-005 與 OPT-007：選擇 context_mode、正確消費平台拼入的會話歷史（作為 Agent 輸入）、以薄服務模板部署，並於 GitHub 閱讀權威 Markdown 規範。
新 Provider 端到端路徑
- 閱讀《A2A 會話歷史與 Agent 輸入規範》：context_mode、user_text、context_turns，以及 X-GaiaLynk-Invocation-Context（稽核用 ID；在 platform_managed 下不是第二份歷史真源）。
- 複製適配模板；除非你端到端自管會話狀態，否則保持 metadata.context_mode = platform_managed。
- 啟動服務（Docker / compose）、公開 /.well-known/agent-card.json、向 GaiaLynk 註冊端點並通過健康檢查。
- 在產品內以多輪對話呼叫 SendMessage；確認 ListTasks 與 tenant 標頭與適配指南一致。
context_mode 決策路徑
在 Agent Card 上聲明 context_mode。未聲明時平台預設為 platform_managed——僅在你真實自管整段會話狀態時改用 provider_managed。
是否由 GaiaLynk 將先前輪次以 context_turns 注入此 Agent？
是 — platform_managed
platform_managed
依序消費 context_turns 與 user_text。不要只靠標頭再拼一份完整逐字稿。多數 Hub 上架 Agent 與模板預設採用此模式。
否 — provider_managed
provider_managed
平台不注入 context_turns。將 conversation_id / trace 等欄位對應到你方儲存（資料庫、廠商 thread 等），並以該儲存為唯一真源。
規範中的反例
《A2A 會話歷史與 Agent 輸入規範》特別提醒：在 platform_managed 下避免重複或競爭的歷史來源。
錯誤
一邊用標頭再拉「另一套」完整歷史，一邊又拼接平台 context_turns——易重複、順序錯亂，幻覺風險上升。
正確
platform_managed → 只使用 context_turns + user_text。provider_managed → 不期待 context_turns；維持單一會話管線。
模板內容
gaialynk.com 倉內 packages/a2a-adapter-template：Well-Known Agent Card、JSON-RPC SendMessage、capabilities.list、ListTasks、從 X-GaiaLynk-Invocation-Context 解析的結構化日誌，以及 Docker 資產。預設 Card metadata.context_mode 為 platform_managed。
取得模板
使用 degit 取得乾淨目錄。下列命令與 CTO 執行指令一致；若僅從 monorepo 工作，請用備用路徑。
建議（獨立模板存放庫）
npx degit gaialynk/a2a-adapter-template my-agent自 GaiaLynk monorepo 子目錄
npx degit gaialynk/gaialynk.com/packages/a2a-adapter-template my-agent權威文件（GitHub）
- A2A 會話歷史與 Agent 輸入規範（E-55 / OPT-005）
context_mode、載荷欄位、標頭語義、正例與反例。
- Provider 適配指南（E-59 / OPT-007）
薄服務部署、安全與租戶一致、ListTasks 與上架聯調清單。
git clone 後，同內容亦在 docs/provider/，可離線與 fork 並列閱讀。