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 并列阅读。