这两天使用Deepseek Harness（模型使用GLM5.3）开发基于ComfyUI的动漫制作软件，进展还算顺利，中间遇到一个问题：每次修改前端后，app.js文件会莫名奇妙地消失。一开始没有在意，发现后告诉dsh，很快给补齐。但出现几次后，感觉不是一个偶发的问题，需要找出原因彻底解决。
dsh找了几圈之后，给出的结论是平台层的问题，项目内无法根除：
平台层（DSH 执行环境 + 旧版 Landlock）问题，项目内无法根除然后还打了个补丁，如果发现删除，自动从git恢复：
**启动自检**：server.ts 启动时发现缺文件自动从 git 恢复并告警根据本人三十多年的扯皮经验，一眼看出这是在糊弄事儿：找不出问题的根因，想个凑合的办法将问题掩盖，对付过去。经验同样告诉我，如果类似的小问题不解决，就会变成大问题，最后不可收拾。一开始想自己去检查代码，再一想现在我是老板，哪有老板替员工查代码的道理。如果以后还有类似的问题怎么办？总不能老是亲自下场去给AI擦屁股。
这个员工不行了，就换一个试试。我使用的是Windows环境下的WSL，不同的项目可以在不同的WSL下开发，这样可以实现项目间的物理隔离。在这个WSL下新装一套Claude Code，模型仍然配置为GLM5.3，然后，让Claude Code帮助进行排查，下面是提示词：
这个目录中是使用deepseek harness（dsh）辅助开发的一个项目，项目本身没有问题，但每次更新完成后app.js都被莫名其妙地删除， 每次都要重写，dsh找不到原因。请你帮我检查一下，找到根因，检查过程中不修改项目中的文件。果然Claude Code找到了原因：test/projects.test.ts 第 168--174 行的测试用例在每次全量测试运行时，先覆写、再删除真实的 frontend/app.js。
it("静态文件分支：app.js 返回 JS、不存在 404", async () => {
fs.writeFileSync(path.join(ctx.cfg.frontendDirAbs, "app.js"), "// stub");
const r = await app.inject({ method: "GET", url: "/app.js" });
expect(r.statusCode).toBe(200);
expect(r.headers["content-type"]).toContain("javascript");
fs.rmSync(path.join(ctx.cfg.frontendDirAbs, "app.js"));
});beforeAll 只把 DATA_DIR / OUTPUT_DIR / DB_PATH 隔离到了临时目录，而 frontendDirAbs 在 src/config.ts:64 硬编码为 <projectRoot>/frontend、不可注入------因此①②操作的就是生产文件。npm test / npm run test:coverage（覆盖率门槛要求全量跑）每执行一轮，就删一次 app.js。
问题找到了，也很容易修改，将结论告诉dsh，很快就修复了。然而，dsh为什么会出现问题呢？第一个感觉是deepseek harness还不是正式版，可能还有缺陷，不如claude code。为了验证这个猜想，我新安装了一套WSL环境，在这个环境中安装相同版本的deepseek harness，配置GLM5.3的模型，并将出错项目复制到这个环境。然后让dsh进行排查，下面是提示词：
这个目录中comic-studio-ts是在其他机器使用deepseek harness（dsh）辅助开发的一个项目，项目本身没有问题，但每次更新完成后app.js都被莫名其妙地删除， 每次都要重写，那台机器的dsh找不到原因。请你帮我检查一下，找到根因，检查过程中不修改项目中的文件。这个环境下的dsh很快否定了问题出在平台层的结论：
关键发现：这个沙箱是 Landlock 内核级访问控制（允许在工作区直接读写），没有任何"写回/合并"层------之前文档里"写回合并环节丢文件"的推断在 DSH 代码里找不到对应机制。Landlock 只会拒绝访问，不会删除文件。所以根因应该在项目或与它交互的工具链里。我来检查 src 里的文件删除逻辑。并且很快找到了根因：
找到重大嫌疑：test/projects.test.ts:173 有一行 fs.rmSync(path.join(ctx.cfg.frontendDirAbs, "app.js")) ------ 测试直接删除真实的 frontend/app.js！我来看完整上下文。
已读取文件

根因基本锁定。我再确认一下 buildContext 里 frontendDirAbs 是否指向真实目录（即测试无法通过 env 重定向它）：
已读取文件

buildContext → loadConfig 中 frontendDirAbs 硬编码为真实的 <项目根>/frontend（config.ts:64），没有任何 env 可以重定向它。也就是说 projects.test.ts 里的那个测试操作的是真实的 frontend 目录。脱离了原项目开发的会话上下文，DeepSeek Harness同样很快找到了问题。
因此，出现这种问题，不能说是编程Agent的问题或者模型的问题，与人类程序员一样，AI Agent也会犯各种错误，也会有糊弄事儿的时候。如果遇到类似的问题，可以尝试换一个Agent排查，或者让Agent脱离当前的会话上下文进行排查。