模型上下文
模型实际看到了什么？
模型看到的不是整个 Agent 内存，而是一份在每个 Step 明确组装的请求。请求由调用参数、系统提示、会话消息和工具定义组成；Harness 把决定请求内容的状态写入日志，使恢复后的下一次调用仍可解释、可重建。
问题 01
一次模型请求由哪几层组成？
答案：最外层是 provider、model、温度和输出上限等调用配置；系统提示描述角色与长期规则；messages 来自会话日志投影；tools 是当前允许模型调用的结构化能力。适配器最后把这四类输入转换成供应商协议。
问题 02
为什么会话不是一份聊天消息数组？
答案：消息数组只能表示模型最终看见的对话，无法完整表达流式 chunk、工具调用、请求配置、轮次边界、取消原因和 UI 回放信息。DeepSeek Harness 用追加式类型事件作为事实来源，再从其中投影出模型消息。
问题 03
为什么“模型可见”必须等于“已经记录”？
答案：如果某段信息只存在于当前进程内，在线请求可能用到它，但恢复后的进程无法知道它曾经存在。把系统提示、工具定义、调用配置和动态消息都投影到日志，才能让相同历史得到相同请求。
只存在内存
在线请求 = 历史 + 隐藏上下文。进程重启后隐藏上下文消失，下一次模型判断发生漂移。
进入会话日志
在线与恢复都从同一事件序列折叠出 request/header 和 messages，请求差异可以被检测。
直接后果：增加新的模型可见输入时，不能只在 buildRequest() 临时拼进去；还需要相应的会话事件和投影规则。
问题 04
AGENTS.md、Skills 和 Persona 怎样进入模型视野？
答案：长期、稳定的身份与规则通常由插件注册为 system-prompt section，再按顺序组装；任务进行中发现的子目录指令、技能正文或文件变化，则可以通过 agent.inject() 作为带来源的 user/message 进入下一 Step。两条路径最终都必须可从日志重建。