LAYER 03 · 追踪 Agent 主干
LLM Adapter 与流式词汇
统一 ContentBlock、Message、StreamChunk 与错误恢复，让 Provider 留在 seam 后面
ModelSelection → adapter → StreamChunk*DeepSeek、重放模型或其他 Provider 的流式事件为什么能进入同一 Agent Loop？
先建立直觉
国际机场把不同航空公司的内部流程转换成统一登机口协议；塔台只处理标准呼号、航班状态与错误类别。
MECHANISM
机制拆解
ctx.llm 保存按 provider 路由的 adapter registry。LlmCallConfig、ContentBlock、Message、ToolCall 与 StreamChunk 是提供方无关词汇。
每个原始 chunk 先写 assistant/chunk，成功结束再写 assistant/message 与 usage；失败步骤关闭后，agent/request-error 决定是否重试。
第 1 步 / 共 5 步
解析模型路由
ModelSelection 找到 provider 与具体 adapter。
INVARIANTS
无论怎么扩展，都不能破坏
- Adapter 不直接修改 Session
- 一个成功 provider 调用对应一个 assistant/message
- 错误恢复必须有界且保留原错误
FAILURE MODES
最容易踩中的坑
- ×在 Agent Loop 内判断 provider 名称
- ×只记录最终文本导致工具增量和思考块无法回放
- ×无条件重试上下文溢出
VERIFY IN SOURCE
不要相信结论，去源码里复核
以下链接固定到官方 deepseek-harness@47f9438；查看当前上游时请留意后续 breaking changes。
KNOWLEDGE CHECK
先停十秒，再揭晓答案
为什么失败的 provider 调用没有 assistant/message？
为什么下一章紧接在这里
模型可能返回工具调用；下一章进入整个 Harness 最关键的安全流水线。