这一章只解决一个问题：在看 DSH 之前，先把 Agent、Harness、Tool、LLM、Session 这几个词放到正确位置。
1. 先把“LLM”和“Agent”分开
LLM 本质上是一个函数：输入一串消息与可选工具描述，输出文本或工具调用。它不会自动保存会话，不会自动真的执行 shell，也不会天然知道文件系统，更不会自己无限循环。
Agent = LLM + 环境 + 状态 + 循环策略。 一次典型 agent 行为是：用户给任务 → harness 组装上下文 → 调 LLM → LLM 决定调用工具 → harness 执行工具 → 把结果写回状态 → 再次调 LLM → 直到模型给出最终答案或策略要求停止。
User→Harness→LLM→Tool Call→Environment↺
2. Harness 到底是什么
Harness 不是模型，也不是 prompt。它是把模型“接到真实世界”的宿主运行时。它至少承担：模型路由、prompt 组装、工具注册与执行、权限/审批、会话状态、持久化、取消、错误恢复、并发、UI、日志和插件生命周期。
| 层 | 职责 | DSH 对应 |
|---|---|---|
| 模型 | 推理与生成 | DeepSeek / 其他 provider |
| Agent | 一次活跃智能体实例 | Agent 接口 + scoped context |
| Loop | 决定何时请求模型、何时继续 | dsh-agent-loop |
| Harness | 把整个系统装配、隔离、持久化、扩展 | DeepSeek Harness |
3. 为什么 DSH 值得从“架构”学，而不是从“聊天功能”学
DSH 的关键不是某个神奇循环，而是微内核式插件化：模型适配、工具、会话日志、Agent Loop 本身都可替换。理解这一点，你就能解释为什么它大量使用 service、event、effect、scope，而不是把所有能力塞进一个 Agent 类。
4. 本教程学习法
- 先画架构，不打开实现文件。
- 再追一条真实请求：user message → session event → prompt → LLM → tool → session event。
- 然后拆可替换 seam：LLM、FS、Shell、Persistence。
- 最后自己写 DSH-Lite；当你能替换某个 provider 而不改 consumer 时，才算理解。
不要一上来读 1000 行 Session 类。先知道它为什么必须存在、谁依赖它、事件从哪里来，再读字段和边界条件。