夜雨聆风我最近对 Coding Agent 最大的不安，不是它会写错代码。
写错代码还能看 diff，跑测试，回滚。
真正麻烦的是另一类事：它悄悄改规则、改配置、开服务、删文件、污染环境。等你发现不对的时候，你已经很难说清楚是哪一步开始坏的。
今天的几个信号正好撞在一起。
V2EX 有个帖子叫《我发现 Codex 经常会写入幽灵规则》，本地采集记录里是 22 个回复。
公共新闻层又出现了一条更吓人的事：GPT-5.6-Sol 删光 AI 创业者 Matt Shumer 的 Mac 硬盘。
HN 上则有一个 Show HN 项目 Aether，标题直接写着：Run Claude Code, Codex, or OpenCode in devboxes you can watch。
这三件事不是同一个产品，也不一定都能互相证明。
但它们指向同一个问题：Coding Agent 正在从“帮我写代码的助手”，变成“能动我工作环境的执行者”。
这时候还让它在本机裸跑，就像把一个实习生直接塞进生产服务器，还不给日志、不给审批、不给回滚。
问题不再是“它会不会写”
过去一年，我们讨论 AI 编程，最常问的是：
它能不能写出功能？
它能不能修 bug？
它能不能通过测试？
这些问题当然还重要。但它们默认了一个前提：Agent 的行为边界是清楚的。
现在这个前提正在松动。
一个 Coding Agent 接手任务时，动的东西不只是某个函数。
它可能会读你的全仓库。
可能会改 .cursor/rules、AGENTS.md、CLAUDE.md、package.json、CI 配置。
可能会开 dev server，装依赖，跑 migration，改环境变量样例。
也可能在你没注意的时候，把一条临时规则写进项目，让下一轮 agent 继续沿着错误的假设走。
这就是“幽灵规则”真正吓人的地方。
代码 diff 还在你眼前。规则 diff 往往不在。
你以为自己在审一段代码，实际上应该审的是一次行为轨迹。
本地跑 Agent 的爽点，也正是风险点
本地 Claude Code、Codex、OpenCode 这类工具为什么让人上头？
因为它们贴着你的真实工作流跑。
不用上传上下文，不用等云端 VM 初始化，不用把项目拆成一个很干净的任务包。你在终端里说一句，它就能读仓库、看报错、改文件、跑命令。
这很爽。
但“贴着真实工作流”换个说法，就是它离你的真实风险也很近。
HN 上 Aether 的作者描述了一个非常具体的麻烦：他不想一边开着笔记本热点，一边反复 accept commands，还担心 agent 动到 root directory；同时，本地跑多个 agent 时，不同 worktree 里开 dev server，还会吃光 RAM。
所以他做了一个折中：把 Claude Code、Codex、OpenCode 放进你能看的 devbox 里跑。
这个点很关键。
Aether 的价值不只是“云端跑 agent”。云端 agent 早就有人做。
它真正踩到的痛点是：云端不能是黑盒，本地也不能裸奔。
作者在 HN 里说，Aether 的 workspace 是一个完整 devbox，有 terminal、file editor、port previews 和 Docker。你可以随时进去 steer，也可以通过 exposed ports 手动测试 agent 的工作。
这句话背后的产品判断很明确：开发者不是只想让 Agent 完成任务，而是想在它完成任务时看得见、插得进、撤得回。
“可观察”不是看日志那么简单
很多人听到可观察性，第一反应是日志。
但 Coding Agent 的可观察性，比传统服务日志麻烦。
服务日志回答的是：系统运行时发生了什么。
Agent 可观察性要回答的是：它为什么这么做，它改了什么，它遵守了哪条规则，它绕过了哪条边界，失败后该怪谁。
至少要有五层。
第一层是隔离。
Agent 不应该默认拿到整台电脑。它应该先在 devbox、sandbox、临时 worktree 或容器里跑。尤其是删除文件、改全局配置、装系统依赖这类操作，不能和正常编辑一个权限级别。
第二层是记录。
不是只记录代码 diff，还要记录规则 diff、配置 diff、命令历史、环境变量变更、依赖安装、端口暴露。
第三层是审批。
读文件、改一个函数、跑测试，可以低摩擦。
但删目录、改安全配置、写入长期规则、触发部署、重置数据库，必须停下来让人确认。
第四层是回滚。
只靠 Git 不够。因为很多副作用不在 Git 里：缓存、数据库、依赖目录、系统设置、隐藏配置、IDE 规则文件。更靠谱的是任务前快照，任务后生成变更报告，一键撤销。
第五层是复盘。
Agent 如果失败了，不能只说“模型不行”。要能回放它的关键决策：哪条 prompt 影响了它，哪个文件让它误判，哪一步命令造成副作用。
这会变成一个产品层
我不觉得“更强的模型”会自动解决这个问题。
模型越强，它越敢动手。
以前它只是给你一段建议，你复制进去，出了事你还知道自己做了什么。
现在它能自己读、自己改、自己跑、自己解释。体验变顺的同时，责任链也变短了。
所以接下来真正值钱的，不一定是又一个 coding agent。
更可能是围绕 agent 的运行环境长出一圈工具：
文件系统 diff。
规则变更审计。
危险操作审批。
任务前后快照。
Agent session 回放。
多 agent 的失败归因。
团队级 prompt / rule 管理。
这些东西听起来不性感，但很接近开发者愿意付钱的地方。
因为它解决的不是“我想更酷”，而是“我不敢把它放进真项目”。
很多工具最后死在这一步。
Demo 里，它能五分钟生成一个 app。
真实项目里，你问它改了什么，它说不清；你问它为什么删了文件，它说为了完成任务；你问它下次怎么避免，它给你一段漂亮但没用的总结。
这时候开发者不会觉得它聪明。
只会觉得它危险。
对独立开发者来说，机会在哪里
如果你现在还想做 AI 编程工具，我会避开“再做一个通用 Agent”。
太挤，也太依赖模型能力。
更好的切口是围绕一个具体副作用做窄工具。
比如：
做一个 Coding Agent 任务前后的变更审计器。
输入是一个仓库和一次 agent session，输出不是“改了 12 个文件”，而是：
哪些是业务代码。
哪些是规则文件。
哪些是环境配置。
哪些操作可能影响下一次 agent 行为。
哪些变更应该要求人工确认。
再比如做一个本地 devbox runner。
不是给所有 agent 做平台，而是先支持 Claude Code / Codex / OpenCode 这几类开发者已经在用的工具，把它们塞进临时环境里跑，任务结束后给一份变化报告。
或者更小一点，做一个 .cursor/rules、AGENTS.md、CLAUDE.md 的守门工具。
每次 agent 想写这些长期规则文件时，自动弹出 diff：这是临时策略，还是未来所有 agent 都要遵守的新规则？
这类产品的好处是，它不需要你证明“AI 编程会不会爆发”。
它只需要证明一件事：已经在用 Agent 的人，开始害怕它动错东西。
今天的信号已经够了。
V2EX 的幽灵规则，是中文开发者的日常麻烦。
Aether 的 devbox，是海外开发者给出的一个产品方向。
HN 的 Who manages the agents? 有 71 points、88 comments，说明大家已经开始问组织里的 agent 到底归谁管。
这不是宏大叙事。
这是一个很朴素的问题：
我可以让它帮我干活，但我得先知道它动了什么。
我现在会怎么用 Coding Agent
如果今天要把 Coding Agent 放进一个真项目，我会先定四条土规则。
第一，不让它默认改长期规则文件。
.cursor/rules、AGENTS.md、CLAUDE.md、CI 配置、部署脚本，都算长期影响文件。改这些，必须单独确认。
第二，每个任务单独 worktree。
别在主目录里让它随便跑。尤其是多个 agent 并行时，不要共用同一套依赖、端口和临时文件。
第三，任务结束先看“非代码变更”。
业务代码可以慢慢审。更应该先看的，是配置、规则、依赖、脚本、环境样例。
这些地方一旦污染，后面每一次 agent 调用都会继承错误。
第四，先追求可撤回，再追求全自动。
全自动很诱人，但可撤回才是信任的开始。
我宁愿一个 agent 慢一点、啰嗦一点、每次危险操作都问我，也不想它很快地把项目带到一个我解释不清的状态。
这就是今天这篇最想说的：
Coding Agent 的下一步，不是更像人。
是先别像一个拿了 root 权限、没有操作记录、还很自信的实习生。
让它干活之前，先给它一个笼子，一本账，和一个撤销按钮。
