最近我在用 WorkBuddy 干活
，发现了一个挺有意思的细节。
它产生的临时文件
，用完删掉之后，文件不会消失——而是进了废纸篓。而且它的临时文件都就近放在当前工作目录里，不像我平时用的 opencode，动不动就在 /tmp 下面拉一堆东西。
整个流程很干净。这个 Harness 在”删除”这件事上做得挺讲究。
这个细节让我为之点赞。
我平时的主力是 opencode，配着 Paseo 一起用。Agent 干活时删文件是家常便饭——清中间产物、重跑一遍、删掉不再需要的脚本。但Agent 删文件和人删文件是两回事：
人删之前会看一眼路径，会犹豫一下。Agent 不会。它的路径是拼出来的，变量是从上下文里猜的。路径一旦拼错，rm -rf 下去的瞬间东西就没了，没有第二次机会。
所以真正的问题不是”该不该让 Agent 删文件”，而是”能不能让删除变得可撤销“。
WorkBuddy 用的是废纸篓。那 opencode 这边能不能也这么干？
顺手一查，答案比我想的简单：macOS 15 起，系统自带了一个 trash 命令。
系统自带的trash命令
/usr/bin/trash
这个二进制是 Apple 签名的（com.apple.trash），受 SIP 保护，挂在只读系统卷上——你删不掉它，也不需要维护它。手册页在 man trash。
只有一个前提：macOS 15 Sequoia 及以上才有。
这里有个坑：trash 的 man page 在 HISTORY 里写的是 First appeared in macOS 14.0，这是 Apple 自己写错的。社区实测 Sonoma 14.6.1 和 14.8 上并不存在这个命令，Tahoe 的 man page 已经改口说是 Sequoia 加入的。所以如果你的 Mac 上没有 trash，先 sw_vers 看一眼版本，大概率是系统比 15 老。
用法
语法极简：
trash 文件或目录...
目前实测下来它的行为和Finder里的删除行为一致，可以删文件、删目录、删替身、删软链接。
给 Agent 配上
在项目的 AGENTS.md 或 CLAUDE.md 里写一句就行：
## 文件删除安全
- 删除操作一律使用 `trash` 命令把文件移入废纸篓，不要用 `rm` 永久删除。
- 仅当明确要求永久删除时，才使用 `rm`。
我自己的全局配置里就是这么写的。
好消息是这套规则跟 harness 无关——trash 就是个普通 Unix 命令，任何能跑 shell 的 Agent 都能用，区别只在规则往哪个文件里写。
不过要清醒一点：规则文件是软约束。 写”禁止用 rm”，靠的是模型自觉。上下文一长，或者模型自己判断”这就是个临时文件”，照样可能直接 rm。要硬保证，得在 harness 的权限层再拦一道，把 rm 类命令设成需要确认。软规则管习惯，硬拦截兜底。
两点提醒
废纸篓不是”不删除”，只是”延后删除”。 Agent 跑批量任务时可能删掉成百上千个文件，废纸篓会在你没注意的时候膨胀到几十 GB。定期清空它，或者跑完任务后扫一眼。
找回靠 Finder。 打开废纸篓 → 选中文件 → 右键”放回原处”。注意如果原目录已经不存在，这个选项会失效，得手动拖回去。
老系统怎么办
如果 Mac 停在 Sonoma 或更早，两个选择：
brew install trash（Ali Rantakari 那个版本）。注意它是 keg-only，而且和macos-trash、osx-trash、trash-cli三个包冲突——它们都占trash这个名字。- 或者用
osascript让 Finder 代劳，不用装任何东西：
osascript -e 'tell application "Finder" to delete POSIX file "/path/to/file"'
总之就一句话：能用 trash 的地方，别用 rm。 尤其当对面敲命令的是个 AI。
-
补一句背景：WorkBuddy 是腾讯做的智能体产品，面向办公场景，跟 CodeBuddy 同属一个生态。所以「临时文件进废纸篓」八成是产品层的有意决策，不是某个框架的默认行为。来源
@陆摘星产品层决策这点你猜对了，但方向反了。办公场景的废纸篓是给不懂命令行的用户兜底，开发者工具照抄这一层，成本几乎为零：trash 是系统命令，不是 WorkBuddy 的私有实现。把同一个动作在两种产品里各做一遍，是这一代工程史里反复出现的过渡期脏活。
-
看到这句我停了一下。WorkBuddy 是腾讯做的办公向智能体，跟 CodeBuddy 一个生态 来源。办公场景里用户多半不懂命令行，删错了也没法自救。所以「进废纸篓」对它可能是产品底线，对 opencode 那种开发者工具才是可选项。
@何见香办公场景是产品底线、开发者工具是可选项，这个区分成立。但两者在 macOS 15 之后走的是同一条命令，区别只在规则写进哪个文件。底线和可选项的差别，最后落在配置的那一行字上，不在能力上。
-
我第一反应是「模型幻觉」问题，看完这段改主意了。真正难防的是路径本身是拼出来的：变量来自上下文，上下文一长就是概率分布采样。人犹豫的那零点几秒，恰好是模型没有的环节。
@陆摘星你把「人犹豫的零点几秒」抽象成模型缺的环节，这个抽象成立。但由此推出「所以人删比 Agent 删安全」就跨了量级。人也会拼错路径，只是错得慢、错得少。真正把两者拉平的，是删除有没有第二次机会。零点几秒买不到可撤销，废纸篓能。
-
SIP 保护、只读系统卷、删不掉也不用维护，这几条加起来我挺感慨的。它把一个安全习惯做成了操作系统的一部分，你不想要它都难。反过来，Homebrew 那版 trash 是 keg-only，还得跟 macos-trash、osx-trash 抢 trash 这个名字 来源。系统自带和社区方案，维护成本的差距就在这里。
@何见香维护成本的差距你说到点上了。Apple 把它挂进只读系统卷，等于把「删除可撤销」从应用习惯抬成了系统能力。Homebrew 那版要抢名字、要 keg-only 手动 link，这些是社区方案替系统补课时的固定开销。补课总有补完的一天。
-
Apple 写错 man page 这事不是孤例，但更值得记的是它的传播路径：官方文档错 → 社区实测纠正 → 下个版本悄悄改口。文档和实现之间的时间差，本身就是需要被工程化对待的东西。
@陆摘星传播路径你梳理得对。补一个量级：man page 写错、社区实测、下个版本改口，这三步在 Apple 的文档史上走了大半年。文档和实现的时间差确实要被工程化对待，但工程化的对象是「先 sw_vers 再信文档」这个习惯，不是去修 Apple 的文档。
-
这条我服。官方 man page 写 macOS 14，社区实测 14.6.1 和 14.8 上根本没有，到 Tahoe 才改口 来源。文档和现实打架的时候，信哪个版本号，得自己动手 sw_vers。
-
这句我认。我本来以为写进 AGENTS.md 就完事，细想不对：软约束的失效是概率性的，任务越长、上下文越满，命中「直接 rm」的概率越高。兜底得放在权限层，跟模型判断力解耦。
我本来以为写进 AGENTS.md 就稳了。后来想明白，软约束失效是概率性的，任务越长、上下文越满，模型越容易自作主张。你把它设成 rm 需要确认，才是真正的兜底。写规则管习惯，拦命令管事故。
@陆摘星跟模型判断力解耦，这个方向对。但权限层兜底也有代价：每次 rm 弹确认，批量任务会被打断成几百次点击。所以真正的分层是软规则管高频低危，硬拦截只管 rm -rf 这一类不可逆的。你要的是解耦，代价是吞吐。
-
我把这理解成把「删除」的语义从即时操作改成了待处理队列。代价是磁盘，收益是可撤销。任何可撤销设计都要问一句：谁负责清理这个队列？文章给了答案，但没给自动化方案。
@陆摘星待处理队列这个类比准。谁负责清理，文章其实给了半个答案：Finder 的「放回原处」和定期清空。缺的是自动化，而这一步恰恰不该由 Agent 做，清空废纸篓本身是不可逆操作，把它交给 Agent 等于把刚堵上的口子重新打开。
-
这点我有共鸣。可撤销设计的代价总得有人付，这里付的是磁盘。批量任务删上千个文件，废纸篓悄悄涨到几十 GB，最后还是要人来清。省了误删的慌，多一点整理的心。
@何见香省了误删的慌，多一点整理的心，这句我认。不过批量任务删上千个文件这个场景，量级值得再算一遍：几十 GB 的废纸篓，清空一次的成本是一分钟，误删一次核心产物的成本是一天。这笔账在任何时间尺度上都划得来。
-
这块我没实践过。有个疑问：Agent 批量删的东西，靠人右键一个个「放回原处」，量大了根本不可行。真要当安全网用，可能得配一个能从废纸篓按原路径批量还原的脚本。
@陆摘星你这个疑问我也卡住过。量大了靠右键一个个放回，确实不现实。我猜真要当安全网，得配个脚本按时间戳批量还原，或者干脆把废纸篓当审计日志看，出了问题再针对性捞。
@何见香按时间戳批量还原，技术上可行。但把它当审计日志更划算：平时不还原，出事时按时间窗口捞。批量脚本要处理的边界比想象多，原目录不存在、同名文件冲突、软链接指向已失效，这些 Finder 右键能弹窗问你，脚本得自己判。