Yifan Xu 对 DSH 的系统性批评：八个独立命题

支持它的证据

DSH README 和早期 Git 历史明确显示 everything-is-a-plugin、生命周期与可逆 effect 建立在 Cordis 上。

与它冲突的证据

DSH 随后实现了独立 agent loop、会话/工具恢复语义与大量测试；这些不是未经修改的 Cordis 包装。

反方核心论据

自建代码和集成难度不自动等于新的 agent capability 原理；这些工作仍可能主要是既有架构上的工程增强。

缺失证据

缺少逐抽象 provenance、可访问的早期设计推导，以及预先定义的 novelty 判断标准。

验证方案

由外部评审者按预先定义标准审查 Architecture Provenance Ledger，并核对同时期系统与固定历史版本。

修正结论的前提

若核心行为几乎都可逐项追溯且 DSH 仅改名或胶合，判断将加强；若多个机制有独立设计记录、实现和外部采用，判断将减弱。

支持它的证据

早期架构文档逐字把执行 waterfall 与 context injection 对应到 Claude Code。

与它冲突的证据

当前 DSH 还实现了 live-runtime Cordis 工具、生命周期和显式 trust stance；仅凭名称相似不能判断行为相同。

反方核心论据

新增工具数量不等于形成独立设计理论；核心 schema、交互范式和权限流水线仍可能主要来自成熟 coding agent。

缺失证据

缺少逐工具历史版本对照，也缺少支持“从 Codex 搬几个”的具体一手对应关系。

验证方案

比较同期 Claude Code、Codex、Pi 与 DSH 的输入 Schema、返回值、权限、隔离、错误恢复和生命周期。

修正结论的前提

若核心行为逐项复制且没有独立设计记录，批评将加强；若多个机制显著不同并改善真实任务结果，批评将减弱。

支持它的证据

官方公开页只给出 minimal variant 运行入口，没有任务、分数、重复次数、轨迹或逐题结果。

与它冲突的证据

Minimal 是明确固定的完整 persona 加两工具 composition，可用于隔离接口敏感性，并非随意删减。

反方核心论据

若公开传播只突出 Minimal 高分而不并列完整 preset 与范围限制，它对产品选择的解释价值可能接近于零。

缺失证据

缺少明确 estimand、同协议 preset 对照、run count、task-level results、raw trajectories、token、latency 与 cost。

验证方案

在相同模型 revision、任务集、scorer、环境和预算下重复比较三个 preset，并公开全部运行。

修正结论的前提

跨公开任务可重复定位到 prompt/schema 对齐并能解释失败，会增强诊断价值；差异消失或继续被外推为完整产品能力，会加强批评。

支持它的证据

公开 Benchmark 页面没有 Standard vs Code 的结果、失败任务或重复运行。

与它冲突的证据

官方 note 明确记录 Cloudflare 来源、presentation/runtime 设计和隔离边界，未作无条件性能承诺。

反方核心论据

一个以减少 round trip 为卖点的公开 preset 长期没有效果数据，外部用户有理由把缺失视为高优先级证据债务。

缺失证据

缺少完整 Code vs Standard 运行、负结果、token、latency、cost、代码错误率和发布决策记录。

验证方案

在预注册任务集上盲审重复运行，并把全部结果与预先声明的发布规则对应。

修正结论的前提

带时间戳的内部结果和决策记录若证明因负分不发布，会支持因果主张；完整公开且可复现的目标任务收益会削弱它。

支持它的证据

官方架构把 plugin composition 和 reversible effects 放在核心位置，当前没有受控数据证明它们提高 task success。

与它冲突的证据

同一文档把 dsh-web-app 与 dsh-headless 分开，并将可逆生命周期落实为卸载与重配置语义；这具有可靠性与开发体验价值。

反方核心论据

架构合理不等于资源配置合理；若长期缺少基础能力与可靠性基线，工程基础设施仍可能喧宾夺主。

缺失证据

团队资源分配、故障恢复收益、preset 组合收益，以及“社区把 UI 当 harness”的可定义样本均缺失。

验证方案

预先定义用户场景与权重，同时比较 task success 和插件开发、卸载、回滚、恢复，使用非插件化 baseline。

修正结论的前提

若资源审计显示 UI/组合性压倒 capability 且没有用户结果收益，批评将加强；若两类结果同步改善，批评将减弱。

支持它的证据

当前没有公开采用率、time-on-task、task success、错误率或留存数据，团队无法用公开证据反驳体验质疑。

与它冲突的证据

官方 preset 确实提供 live runtime 检查、自修改工具和 composition guidance，理论上可减少外部编辑—reload 往返。

反方核心论据

“原位”不是自动优势；若 Agent 的代码能力和失败恢复较弱，额外工具可能增加复杂度而非节省时间。

缺失证据

缺少真实使用人数、重复使用率、完成时间、正确率、人工干预、失败日志以及新手/专家分层。

验证方案

随机分配同等经验用户完成新增工具、修改 preset、定位 lifecycle bug 与回滚失败插件。

修正结论的前提

外部 Agent + reload 若稳定更快且更正确，批评将成立；Creation Mode 若在原位检查、试运行和回滚上稳定胜出，批评将减弱。

支持它的证据

官方只公开 Minimal variant 运行入口，没有固定结果、跨 Harness 对照或 task-level evidence。

与它冲突的证据

原帖没有给出任何对照分数、失败轨迹、版本或平均线；孤立社区高分也只能构成有限反例。

反方核心论据

公开基准缺失不能被当作性能良好的证据；团队有责任用系统 eval 回答持续出现的能力质疑。

缺失证据

缺少对照集合、等价工具映射、模型 revision、任务、run count、置信区间、轨迹、token、latency、cost 与失败分类。

验证方案

固定模型和工具能力，在公开与污染受控任务上比较 DSH 三个 preset 与多个 Harness，由独立方复核。

修正结论的前提

若重复实验显示 DSH 显著且大幅落后多数对照，批评成立；若持平或胜出且可独立复现，批评减弱。

支持它的证据

Cordis 论文确实讨论 future self-evolving harness，DSH 同时缺少严格公开 capability baseline。

与它冲突的证据

论文使用 future 和 may，没有声称 DSH 已实现自进化；未找到团队一手 AGI 表述，研究两条路径也不必完全串行。

反方核心论据

即使措辞谨慎，强调自进化仍可能让社区高估当前能力并分散对基础可靠性的注意力。

缺失证据

缺少团队 AGI 一手来源、真实资源分配、自修改收益、安全违规、审批成本和长期漂移数据。

验证方案

在公开基础基线上，比较固定 Agent 与仅能生成受限组件的 Agent，预注册成功率、回归、安全违规、审核成本与稳定性。

修正结论的前提

若资源与产品承诺确实把未经验证的 AGI/self-evolution 放在基础能力之前，批评加强；若其明确限定为远期研究且受限自修改可复现获益，批评减弱。