有一个周末，我几乎全花在一件事上：让一个本地 Agent 能打开浏览器。最后卡住的地方很荒诞——配置文件里写死了一个浏览器路径，而我的机器上不在那个位置。改完之后它跑起来了，我盯着屏幕，没有成就感，只有一种熟悉的不耐烦：这不是我要做的工作。
那之后我把它关了，回到终端。这个决定没有经过多少权衡，更像是把一件一直拖着的事终于做完了。
装得上，和用得下去不是一件事
安装本身只是门票。真正的成本在后面：一次依赖升级、一次换机器、一次系统大版本更新，整套环境就要重来一遍。Node 版本、Python 版本、密钥、网关配置、权限范围，任何一处对不上，报错都藏在几百行日志的中间，而且往往指向一个和真实原因无关的文件。
我并不是不能接受麻烦。折腾静态博客、折腾服务器、折腾检索链路，我都干过，也乐在其中。区别在于，那些折腾有终点：配置好一次，之后是稳定的。而这类本地 Agent 的折腾没有终点，它跟着上游仓库的每次提交一起漂移。今天能跑的组合，下个月可能因为一个依赖的小版本变化就散架。
我也确实被”本地”这两个字吸引过。数据不出机器，模型可以自己换，不用把文件传给任何服务。这种吸引力是真实的，不是营销。但本地部署省下的是数据外流的风险，付出的却是另一笔账：我自己变成了这个项目的运维，而且是一个没有交接文档、没有值班表的运维。出了问题，上游的作者不会知道，也不会负责。
Claude Code 装起来的体验几乎是反过来的：一条命令，一次授权，然后就在当前目录里工作。Cowork 更直接，桌面端打开，指一个文件夹。它们牺牲了很多东西——不能随便换模型，不能任意接平台，不能自己改调度逻辑——换来的是我不用再关心它今天能不能启动。
这不是说官方工具就没有维护成本。它们也在频繁更新，行为也会变，我同样遇到过升级之后某个命令的输出格式变了、某个默认权限收紧了。区别在于变化的幅度和可预期性：一个是产品在迭代，一个是一个大型仓库在所有人的提交里共同漂移。
本地这套还有一类更难查的问题：时好时坏。同一个命令，今天能跑，明天报一个和它毫无关系的错。我曾为一个启动失败翻了两晚日志，最后发现是某个依赖在特定版本下编译出来的产物不一致。这种问题不属于上游作者，也不属于我，只属于正在用它的人。
工具的维护成本不是安装时间，是你在之后半年里为它预留的注意力。
这笔注意力是有机会成本的。我那几天本可以写完一个卡了很久的功能，结果在查 Issue、比对版本、试错路径。工程师最容易低估的就是这种切换成本，因为它不出现在任何账单上。
我后来给自己定了一个很粗的标准：如果一个工具的启动过程需要我重新看文档才能恢复，它就不适合放进每天的工作流。这条标准很粗暴，但它筛掉的东西，几乎没有让我后悔过。
在放弃之前，我试过几种折中。
放进容器。隔离是隔离了，但浏览器控制、文件权限、端口映射又多了几层要调的东西。容器解决了”它弄坏我的系统”，没有解决”我修不好它”。
挂到一台闲置机器上，通过消息入口触发。这个方案活了两周。问题不是它跑不起来，而是我不敢让它碰真实的东西：一旦出问题，我得先登上那台机器，翻它的日志，猜它上一轮做了什么。
用 MCP 把工具接进来。这个方向我是认可的，它把”能做什么”变成了一份明确的清单，比让模型自己想办法调命令可靠得多。但它管的是接口，不管判断。给了它查数据库的能力，不代表它知道哪张表的数字不能动。
每一种折中都在推迟同一个结论：我付出的维护成本，没有换来与之相称的确定性。
自由度是要付利息的
这类项目最有说服力的宣传，是”什么都能接”。多模型路由、跨平台消息、定时任务、自主规划。听起来像是把一整套自动化基础设施交到人手上。
实际用起来，自由度变成了别的东西。任务一旦交给一个会自己改脚本、自己重试、自己决定下一步的循环，我就失去了对它耗时的估计能力。一个本来三十行脚本能解决的事——批量重命名、按正则抽日志——会变成”报错、改脚本、再报错”的循环。它每次重试都带着前面全部的历史，成本不是线性增长的，是滚起来的。
我也不认为这是模型的错。一个把”规划、执行、审查”拆成多个角色互相传递的架构，天然会在中间层丢信息。每一层都觉得自己在做合理的事，合起来就是一个不肯停的循环。相比之下，单线程的工具反而更容易收敛：它错一次，我看得见，改一次，就结束了。
我没有精确的账单数据，也不打算在这里编一个。但从体感上说，最贵的一次并不是它做错了什么，而是它一直在做，而且看起来很像在进步。屏幕上滚动的东西越多，我越难判断它是在收敛还是在发散。
更隐蔽的问题是封号。用订阅账号的授权去接第三方工具，这件事本身就在官方条款的灰色地带。我见过太多”我用了半年都没事”的说法，这种论证的问题在于，它把没出事当成了允许。我的账号里存着几年积累的东西，不值得为省一点 API 费用去赌。
一个需要我持续祈祷它别被封的工具，不算工具，算负债。
我做过一次很朴素的对比。同一个任务：把一个目录下几百个日志按日期归档，抽出一段固定的错误堆栈。我用二十行脚本加一个 cron 写完了，前后不到十分钟，跑完我去泡了杯茶。同样的任务交给那套自主流程，它跑了十几分钟，中间经历了三次自我修正，最后结果是对的，但我不确定它下次还会不会用同样的方式。
这就是我真正介意的地方：结果对了，过程不可复现。脚本我读得懂，明年出问题我还能改。那十几分钟的推理，我复述不出来。
我后来也想明白，我对这类工具的不适，不完全来自技术。它默认了一个前提：把事情自动化本身是有价值的。但很多事情的价值恰恰在于人要经手。
整理一个目录，自动做当然快。可我不知道它按什么规则分类，下次找东西时就要重新猜。发一封邮件，自动写当然省事。但那封邮件带着我的名字，措辞里的分寸只有我知道。自动化的收益是时间，代价是对过程的理解。这个交换在批量任务上划算，在需要负责的事情上不划算。
所以我现在做的事情很土：需要重复的，写三十行脚本放进 cron；需要判断的，自己在终端里一条条跑。脚本会坏，但坏在哪里一目了然。它不会在某天突然换一种方式理解我的意图，也不会在我睡着的时候替我做一个我没授权的决定。写得慢一点，换来的是我随时能接手。
我真正想要的不是全能，是边界
Claude Code 只做一件事：在终端里读写代码、跑命令、看报错。它不理解我的业务，不管我的日程，不发我的推文。正因为如此，我知道它会在哪里出错——在我给它的上下文里出错。
这一点很重要。工具的可靠性不来自它能力的上限，而来自它失败时我能不能看懂。一个只管代码的助手失败了，我看 diff 就知道它在哪一步想歪了。一个什么都管的助手失败了，我要先花时间判断它到底动了哪些地方。
Cowork 我一开始也不喜欢。它会在关键步骤停下来问一句，等一个确认。追求速度的时候，这种停顿很烦。后来我改变看法：如果它要删我的文件、发我的邮件、覆盖我的文档，那个停顿不是效率损失，是它唯一值得信任的地方。真正危险的不是慢，是它在我没看见的时候做完了。
这套分工我用了几个月，暂时是这样定的：需要判断和调试的，留在终端；需要跨文件、跨应用的整理，交给桌面端那个受控的沙箱。两者都不假装自己能做全部。
终端里那个也有它的毛病。它改代码很快，快到我经常不看完就接受了；它在大仓库里读上下文很贵，一次跨模块排查的成本能顶上我半天的手工搜索；它不理解我为什么不想动某个文件，只要那个文件在它的搜索范围里，它就可能顺手改掉。这些我都接受，因为出了问题我能用 diff 兜住。
桌面端那个的毛病是慢，以及对”文件夹”这个边界的依赖。它不知道文件夹之外的事，我不会指望它替我判断一个需求的优先级。
两边都是窄的。窄的好处是我能在心里给它们画一张图，知道什么交给它们、什么不交。宽的工具给不出这张图，它只给我一个模糊的承诺：你想到的它都能做。
如果哪天我自己要做一个这类东西，我会做得很克制：不做全自动，做随时可以中断；不做多模型路由，先把一件事做对；不做常驻后台，每次任务结束就退出。听起来像是退步，但我见过太多项目死在”顺手再加一个能力”上。
至于 OpenClaw 这类项目，我不觉得它没有价值。它更像是研究材料——想看多智能体怎么协作、想看网关优先的架构能撑到什么程度，它是很好的样本。但研究和生产是两件事，前者的目标是探索边界，后者的目标是不出事。把研究原型当生产力工具用，代价最后都会落在使用它的人身上。
我到现在也没有一个完整的判断，说这条路一定走不通。也许某天它的稳定性会好到让我改口。但在我能确认这一点之前，我宁可要一个能力窄、边界清楚、随时能被我关掉的工具。
评论