本教材作者的判断与理由

这一页是作者的观点，不是课程内容，也不代表 DeepSeek AI 的立场。 其余课文只解释固定版本源码里能读到的东西。这里放的是作者对 Agent 和 Harness 这类系统的判断——它们影响了教材的编排顺序，但你不同意也能照样读完全部课程。

第一课原来把这些判断放在正文开头。那样安排有两个问题：新人还没有任何 DSH 概念，就先读到六段对别人观点的反驳；而反驳里引用的说法没有出处，读者无法自己去核对原文。所以判断集中到这一页，第一课只留教学。

为什么单独成页

课程内容和作者观点的证据强度不一样。

	课程内容	这一页
依据	固定版本源码、测试、可重跑的实验	作者读完源码和公开资料后的判断
可核对方式	打开链接里的文件，或自己跑一遍	只能看理由是否成立
说错的后果	教材有事实错误，应当报错并修	一种可以反对的意见

把两者混排，读者就无法分辨哪句话能拿去引用。

判断一：组件变多，不等于效果已经变好

能分步完成任务的程序，基本工作方式仍然是「观察 → 决定 → 动手 → 看结果 → 更新情况 → 再观察」。

运行框架、可渐进加载的说明、浏览器操作、截图、记忆、资料检索、工具筛选和自动修改，主要是在改变这个循环能看到什么、能做什么、以及怎样判断结果。这些改动让循环更复杂；复杂本身没有让程序更聪明，判断变好只能靠证据。

读 DSH 时，先问「哪一层变了、引入了什么失败、有什么证据」，再问「要不要继续加组件」。

判断二：「底层都是 loop」是个有用的抽象，但推不出架构等价

可以把一次任务写成：

Agent
  = loop
  + 模型与提示词
  + 上下文与记忆
  + 工具与运行环境
  + 权限与失败恢复
  + 评估标准

Planner、Executor、路由器、状态机和多 Agent，通常是多个循环、嵌套循环，或循环与状态机的组合。说它们「底层都是循环」是对的，但由此推出「能力相同」就错了——差别在循环之外的那五行。

判断三：单循环式 Agent 遇到的是边际收益和验证瓶颈

「纯软 Agent 基本到头了」这个判断，作者不同意。更准确的说法是：朴素的单循环式 Agent 已经遇到明显的边际收益和验证瓶颈。

这不等于后面没有研究方向。分层 Agent、事件驱动流程、专用模型、外部执行环境、工具路由、权限控制和更好的记忆系统，仍然可能改善可靠性、延迟、成本或可维护性。

它们都要回答同一组问题：改变了循环的哪一层，改善了哪个指标，付出了什么新成本，失败时能不能恢复。

判断四：自然用户日志不能直接证明因果收益

用户数据通常同时混入任务难度、用户熟练度、模型版本、模型服务方、工具数量、工具顺序、提示词、上下文长度、网络延迟和失败重试策略。

只看到「改完之后成功了」，还不知道成功来自 Harness 改动、模型变化、任务变化、用户熟练度，还是只记录了成功样本。要回答「哪次改动造成了多少提升」，这已经是因果比较，不是普通日志统计。

因此本教材的用词规则是：只有相关日志时写「观察到关联」；有受控实验时才写「在指定任务、模型和时间范围内观察到差异」。

具体怎样搭这种对照，见后续研究路线里的 A/B 一节。

判断五：DSH 可以借鉴 Linux，但现在还不能叫「新时代 Linux」

把 DSH 这类系统比作 Linux，是个有启发的比喻；但它描述的是一个目标，不是已经达到的状态。

Linux 不是一个插件框架，而是内核、发行版、软件包、工具和社区规则一起形成的基础系统，这些规则也是多年维护后才稳定下来的。Linux 里确实有一些和 DSH 面对的同类问题，但它们分散在不同层次：

Linux 已经解决的问题	对应到 DSH 的问题
稳定的系统调用和软件接口	插件按什么规则接入，哪些规则会长期不变？
命令只在需要时才运行	工具可以装很多，但不必每轮都把全部说明交给模型。
内核执行用户和进程权限	权限应由宿主真正检查，不能只让插件自己声明「我安全」。
软件包、版本和系统快照	插件要能说明版本，出错时能禁用、卸载或退回旧版本。
内核测试、发行版测试和性能测试	改动要用固定任务重复测试，不能只看一次成功回答。

DSH 还多一个 Linux 没有完全对应的问题：工具的名称、参数和说明要占用模型上下文。系统里「已经安装」不等于模型「这一轮看得见」，模型「看得见」也不等于当前任务「有权使用」。

所以作者认为最值得记住的是：工具可以很多，但每轮只给模型真正需要的那一小部分；能看见、能调用、运行可靠，是三件不同的事。「看得见」的三层收窄在工具可见性实验里可以亲手拆，「有权使用」的审批结局在审批流实验里逐步推。

Linux 也没有一本能代表全部 Linux 的统一白皮书：内核有开发文档，发行版有自己的手册，社区再补充教程和案例。DSH 也需要这种分工：内核行为看架构文档，发行版差异看各 Bundle 的 README，教程和案例由社区补充；前提是官方先把公开规则和不保证的部分说清楚，分工才有落点。

关于工具数量的取舍，见工具预算与插件责任决策卡。

这些判断怎样影响了教材编排

判断	对教材的影响
组件多不等于效果好	每一课都要求分开写「已经证明」和「还没有证明」。
架构不因同为循环而等价	课文按数据流讲，不按架构名词讲。
验证瓶颈是真的	实验一律用固定输入和独立校验，不用一次成功当结论。
日志不等于因果	用词分「观察到关联」和「受控实验中观察到差异」两档。
Linux 只是目标	讲扩展时先分清公开接口、配置补丁、源码分叉和运行时注入。

你可以从哪里反对

• 如果你认为某条判断错了，它不影响你读课程：课程结论都落在固定版本源码上，可以独立核对。
• 如果你认为某条判断该写进课程正文，那需要先有可核对的证据，而不是更强的措辞。
• 教材当前没有验证的部分列在完成度审计与证据矩阵。

固定入口

• 回到第一课：从零开始读 DSH
• 研究方向与验收条件：后续研究路线
• 教材自身的设计取舍：源码学习项目的渐进式设计