很多团队把 Agent 接到终端本意只是让它代查日志、改配置、整理文件。⚠️ 真正上线后麻烦的常常不是命令报错而是命令成功返回0几分钟后才发现删掉的是别的目录、覆盖的是共享配置、移动的是待下游消费的产物。 终端场景最大的错觉就是“命令看起来对副作用就一定也对”。一旦任务跨仓库、跨挂载点或带符号链接这种错觉会被放大。 模型看到的是自然语言目标执行器面对的却是工作目录、相对路径、软链跳转和 shell 展开后的真实对象。 如果平台没有在命令落地前冻结本次任务允许改动的write setrm、mv、sed -i就会把一次局部修复放大成整片工作区的副作用。图 1先绑定对象再放行命令为什么 Agent 一进终端就容易把小偏差放大成事故第一层根因是很多系统只校验“命令能不能跑”却不校验“它最终会写到哪里”。️ 例如任务只要求修改configs/prod.yaml模型却先cd到另一个仓库再执行一条同名覆盖命令又或者相对路径经过软链后实际落到了共享目录。✅ 当执行层只看退出码不回传规范化目标路径、 inode 或挂载点信息时平台根本不知道这次修改是不是还在任务边界内。第二层根因是终端里的破坏性动作往往带有连锁副作用。rm -rf cache/*可能删掉的不只是缓存还可能删掉尚未上传的中间产物mv可能改变下游监听目录一次chmod -R也可能把只读模板改掉。 很多团队喜欢堆命令白名单但真正缺的不是更长的白名单而是把“计划写入对象”和“真实写入对象”做一致性比对。图 2熟悉命令文本不等于知道落点一套更稳的 Write Set 与 Destructive Command Fence 链路更稳的做法是让 Agent 在执行前先产出结构化write set明确本次允许创建、修改、删除的路径集合再由执行器把 shell 展开后的真实对象回填成resolved write set。 两者只有完全落在同一作用域内命令才允许真正落地如果出现越界路径、软链逃逸或挂载点漂移就直接阻断到destructive command fence。️ 这样约束的不是命令语法而是副作用范围。方案放行动作依据误删/误覆盖率平均额外开销典型问题只看命令白名单命令名、参数片段5.6%0 ms对路径漂移没有感知白名单 人工抽查再看人工预览2.1%480 ms高并发时无法持续Write Set Fence计划对象与真实对象一致性0.3%95 ms需要执行器提供路径证明frompathlibimportPathdefallow_command(plan,resolved_paths):allowed{Path(p).resolve()forpinplan[write_set]}touched{Path(p).resolve()forpinresolved_paths}ifnottouched.issubset(allowed):returnFalse,write_set_violationifplan[is_destructive]andnotplan.get(confirm_token):returnFalse,missing_confirm_tokenreturnTrue,ok一次内部回放选了180个终端任务覆盖配置改写、批量重命名、日志清理和产物归档。 基线组只校验命令模板第二组补了write set第三组再加destructive command fence与确认令牌。结果误删和误覆盖事件从5.6%降到1.4%最终压到0.3%平均执行时延只增加95 ms。 这个代价远低于错误删除后的人工回溯和数据恢复。[外链图片转存中…(img-yA2cCHtV-1778480933098)]图 3关键不是限制命令名而是证明对象未越界真正该治理的是副作用证明不是更长的命令白名单很多终端 Agent 迟迟进不了生产不是因为模型不会写bash而是平台说不清这次动作准备改谁、实际改了谁、出问题后能回滚谁。 值得补的监控是write_set_violation_rate、symlink_escape_count、destructive_confirm_latency和rollback_recoverability而不是单看命令成功率。 只要系统解释不了副作用边界自动化就会放大手工失误。接下来3到6个月成熟的终端 Agent 平台大概率都会把write set proof、路径规范化和破坏性动作令牌做成默认能力而不是临时补丁。 谁先把“命令成功”升级成“副作用可证明地正确”谁就更有机会把终端 Agent 从 Demo 推到生产。你们现在的终端自动化记录的是命令跑没跑通还是已能证明它只改了本次任务该改的文件✅[外链图片转存中…(img-4inC5qz5-1778480933098)]图 4终端 Agent 的门槛是证明范围