昨晚刷到了一个AI的skill项目，关于帮助AI更好地通过SSH操作远程设备的。Readme很详细，一切看起来都很“正确”…? 但是这他妈到底是什么? AI当真需要这样一个skill来教他做事吗?
增加了连接复用功能、统一管理服务器、并发操作… 但是OpenSSH在19年前就内置支持了连接复用的能力、ripgrep对于本地配置的检索能力也极高且快、使用command进行并发也是AI手到擒来的事…
那为什么要这么做? 不算这么长的skill激活时的token增量，纯粹shell调用script的指令长度都比AI直接去操作纯粹的原子级工具链要长的多，那么何意味?
对于这个skill对AI操作SSH时的能力增幅我暂且蒙古。
这等skills的「罪」不是它没有灵活性，而是在一个本来就很灵活的地方，它提供的伪灵活反而限制了真正的可能性。
这让我不禁想到两个半月前我和同学争论关于MCP是否已死，skills是否会成为新时代的AI能力外延。但是我意识到了人们争论的根本不是MCP这种协议封装和skills这种自由注入的形式，而是他们的调用方式。只是因为skills可以在shell中调用，所以得到了其他Unix Utilities的增益。
那么倘若MCP可以被在shell中调用组合呢? 其指令的简短和更甚的确定性何尝不会比skills更好用呢? (此处的skills指作为能力外延的、带有脚本等资源的skills，而非说明性质的prompt注入)
以及tmux，这才是真正AI时代的大杀器。AI并不会主动去使用tmux，但是当tmux和AI组合使用后就会发现这完全是另一个级别体验。让AI去积极使用tmux，会发现他的自由程度一定幅度超过了现在躺在agent里调调shell的级别，开一个需要长时间处理或运行的进程，挂到tmux里，人可以随时attach进去看到实时的情况，也可以交互，so do AI，甚至比agent内置的后台终端更加详细更加可控，也可以 send-keys 给里边的进程，进行正常交互。
优势究竟是什么呢，是tmux是Unix原子工具、是可组合的。这意味着你只要有着想象力，他可以做到非常多本来难以做到的事，最大的特点就是异步和双向控制，可以去调试交互式script，或者是非严格交互式、但因时序出现的类交互式。
例如有时候遇到一个长时间处理、或需要等待的任务，agent的确可以直接派发给shell然后进行一个阻塞等待，但是如果你又想要顺便推进一下呢，然后这个阻塞就又失效了。轮询就太野蛮太浪费token了，但是如果AI会用了tmux，就可以 command; tmux send-keys -t claudecode "Done." Enter。就这么一个简单的异步回调，就可以完美解决了，当然，这已经是处于Unix中的组合能力了，那么你就可以创造更加自由、更加强大的组合，甚至链式，一切你想得到的都可以。你甚至可以开好几个agent，让他们通过tmux对谈，自己自定义middleware。
不需要给AI提供任何东西。什么skills，都是多余的。只需要让它知道tmux的存在。Unix有这个能力，AI有用好它的能力。
一旦你可以在终端里 mcp-call some-mcp 、MCP升格为了一个能被pipe的原子util?
一旦tmux成为了一个稳定、可编程的终端状态机、成为了交互逻辑总线?
这就是我为什么说解构和组合是永恒真理。
这两件事早在40年前，Unix就教给我们了。但是人们遗忘了? 还是因AI被遗忘了?
其实这篇文章的起因和核心都只是tmux，虽然他在80%的场景可能并没有什么用，但是在20%的场景真的有难以忽视的奇效。
林翩翩 06-18 05:011楼