体验了许多的AI工具，我觉得最趁手的还是OpenCode之类的终端agent。决定终端agent优势的因素，我分三个部分：基于本地、终端形态，以及human in the loop。

为什么是本地agent？

当LLM能够通过工具调用和外界打配合的时候，就已经意味着它的能力已经超越了单纯的聊天解闷，或是解决一些逻辑问题。无论是调用Python增强自己的计算精度，还是调用网络搜索获取最新的结果，甚至调用生图工具另请高明生成一张图片，这项能力似乎在至少9个月前就已经在ChatGPT中落地了。然后就是轰轰烈烈的大agent时代，先是Cursor和Claude Code等coding agent使劲从 程序员 vibe coder钱包里榨钱，以及MCP赋予了自定义工具的能力，之后中间省略直到最近千问整合接入了阿里的各种产品，大模型的能力边界也确确实实地随着工具的丰富而不断地扩展。

模型决定了agent分析问题的准确性、调用工具的技巧，工具（或者MCP/Skills）决定了agent可以做到的事情，而agent本身运行的平台，则决定了其在不额外添加工具的情况下能办到什么。回想我体验过agent，在第三个方面都有一些特征：

• ChatGPT普通模式，不清楚是怎么做的，不过可以调用Python，只能用一些已有的包。可以读取用户上传的文件，另有多种App（可能是类似skill的东西），可以连接云盘。
• ChatGPT agent模式，在OpenAI的服务器上起一个类似Debian的容器，天然沙盒化。在上述功能外支持了接近完整的Linux能力。
• 千问App¹，全都做成了单独的模式，单独的deep research，单独的代码执行，而用阿里旗下的点外卖、找路线，嘿，又是一个单独的模式。
• Cursor/Copilot/Cline等AI IDE（插件），在IDE中运行，以代码为中心，改代码甚至写论文都非常方便。
• Codex和OpenCode等终端编码agent，通常依托终端界面，以及本地文件系统和程序工具。
• Claude for Desktop和Codex App，像是Claude Code套了个壳子，不过拥有更友好的GUI界面。

当agent在本地电脑上运行的时候，它更能够像人类一样使用电脑，而不是被局限在某个App或某个平台里。利用现有的环境也可以节省很多重复性的安装依赖等工作，并使用当前人类熟悉的配置文件。更重要的是，本地agent具有本地文件系统的优势，除了代码仓库，也可以十分方便地浏览工作资料等文件，甚至操纵本地运行的客户端程序。相反，在云端运行的agent仿佛带有一种隔阂，不依赖本地的状态则不像是在“为用户”处理工作。，

的确，本地的文件太过繁杂，而现在仍然需要明确告诉agent哪里有文件，它才能自觉去引用、去综合、去整理，而不能自动地附带上下文。而我要说，基于云、连接网盘的方案有一样的问题，且难以推动云存储商实现便捷的文件查找接口（即使强如OneDrive搜索功能，也未必能给ChatGPT相似级别的权限）；而对于本地，大规模RAG是一个理论上可解且工程上可行的问题，但目前确实有一些文件检索路线上的争论。

本地终端的另一个优势在于，通过利用本地的命令行工具链，它能够很好地遵守Unix哲学，通过shell管道和文件系统组合各种小工具，以达到极高的自由度。丰富的训练数据令LLM天生熟练使用shell，而无需花费额外context介绍工具调用或者MCP的spec。这是云端agent难以办到的，而即使是提供一个容器的ChatGPT agent模式，也更难包含所有任务需要的工具。

至于chatbot提供的工具，Codex App和Claude App也能够添加其他MCP/工具，体验也已经基本是对齐的。

为什么是终端？

我们暂且认为本地相对更有优势，好，那么为什么是终端，而不是IDE或者GUI的形式？有主观原因也有客观原因。

其一是大多的AI IDE均基于VS Code，其性能虽然在IDE中算是较为优秀，但打开项目后仍然常有数百至数千MB的开销。这在编码任务中非常方便，因为能随时审查agent对代码的修改；但在常常涉及二进制文件的其他通用任务中，则显得相对累赘。正如朱亦博老师在Step 3.5 Flash博客中提到的，许多人并不会紧盯着执行过程中的过程，写了什么样的Python脚本，而是希望专注于运行结果，而结果很可能并不由代码呈现。

倒不是说终端agent都多轻多快，当然OpenCode和Claude Code等工具由于实现问题，占用内存也很大，所以这里重的感觉也未必客观，或者更多的是一种跟手感。

Claude for Desktop等桌面agent很好，有很强的computer use能力，在代替人解放繁杂工作这一方面，Anthropic算是起步比较早，整得也比较明白的。也有一个比较全面的marketplace，提供了接入各种第三方平台的工具。对于买了Claude订阅的普通人来说，它是一个比较理想的通用agent形态。

大部分GUI形式agent也有自己的问题，就是在远程主机上用起来十分不方便。且不提三大系统唯独缺了一个Linux版本，不管是连接Windows本地的WSL，还是远程Linux服务器，都不能指定agent的实际运行环境。Windows上的PowerShell还是不要谈Unix哲学了，毕竟它连Unix都不是。相比于标准稀碎、网络要求高的远程桌面，SSH（或类SSH）作为既成标准，连接起来一般不会出什么差错，且由于传输的数据量不太大，在处理一些主要依赖远程机器的任务时，效率也更高。当然这并不是一个常见的需求，更多的还是我的个人喜好，如果Claude for Desktop糊一层客户端与服务端通信的协议，或许也会解决这个问题。

为什么不是OpenClaw？

OpenClaw很好，好在它打通了自主行动的链条，比被动的一问一答、等待指令更加灵活；但它坏就坏在过于灵活，对于人类完全是黑盒，几乎完全不可控也不受监管，也没有内置沙盒机制（当然用户应该有这样的自觉），甚至还有Moltbook这样的注入攻击温床。如果说使用Antigravity删除家目录这种事可以通过停止agent运行或者加入命令黑白名单来解决，那么对于并不会全程暴露执行过程的OpenClaw来说，则无异于蒙着眼睛凭感觉开车，一般来说能到达终点，而翻下悬崖也没什么意外。

经过几年的发展，coding agent已经有了很多防止把代码库改炸掉的方案，比如建立多个worktree分别编辑，比如利用git的功能来暂存修改，比如使用bubblewrap把agent装进沙盒，等等等等。然而，显然OpenClaw一个都没做到，顶多也就是个MVP（2026年2月）。Docker并不能解决所有问题，agent的权限范围越大，其能力也就越强，辛辛苦苦写了一大串ACL，到头来总会遇到因权限而无法完成的任务。还不如使用声明式的方案，所有的更改以文件形式暂存，用户审核后再应用到系统中——文件而非命令的配置，某种程度上又是一种Unix哲学。或者甚至直接给整个硬盘打快照，起码给了用户救回来的机会。

毫无疑问这种高度自主化的agent将会是未来的发展方向，但在它彻底融入日常生活，放心地把任务交给它之前，起码还是先加一些安全措施吧。起码现在，我宁愿盯着OpenCode的执行过程，并随时准备停止、接管或者完善任务。