少教 AI 做事，多向 AI 学习

我和 @艾逗笔 开源了 termany，一个面向 agent native 开发者的终端应用。如果经常并行着 5 个以上的会话任务、同时使用不同厂商的 coding agents、需要在不同服务器环境来回切换，这个终端会用起来非常舒服。

分享几个我的真实用法：

- 在同一个界面里管理不同 agents（claude code、codex、pi）的 20 个会话，同时查看 git diff、浏览和编辑文件
- 同时用不同的 coding agents 定位 bug 或者 code review
- 将长时间任务的上下文(.jsonl)导出到开发服务器上执行，避免电脑休眠导致的任务中断，比如那些能跑10个小时的 /goal
- 在一个项目启动多个 worktree 时，使用 monitor 查看进程情况，查看和处理冲突的端口占用（这个功能是我加的，也是我最喜欢的功能）

本质上这是一个使用简单、容易拓展的应用，就算使用没有那么重度，这也是一个不错的终端。

背景：其实最近几个月我已经体验了各种 AI 官方客户端、三方 GUI 套壳、各种现代终端，但都没有找到特别顺手的。上周末我突然想起 idoubi 几天前发我的 mvp demo 似乎想解决类似的问题，所以我决定一起在业余时间完善下……

这是一个完全开源的项目，你可以在这里免费下载、获取源码和随意修改： github.com

没想到有一天会因为本周过于关注技术而感到自责

"loop engineering"

啥时候从loop engineering 快进到 vat engineering🧐

虽然我不听播客、不混社媒，但发现我的关注点经常会很领先，几乎在思潮的第一线。

很多曾经有效的 agent 工程实践正在加速过时，逐渐变成新模型的干扰和拖累，比如今天的 /plan 就处在边缘。最优雅的做法应该是提前让这些工程优化变得“容易删除”。这就是最近我越来越喜欢 Pi 的原因，极其稳定和简洁的内核，搭配一个精心设计的拓展系统：在 Pi 的设计里，/plan、/goal 都可以是一种可插拔的拓展包。

汽车发明后的三十年里，一直被视为城市交通的“破坏者”。

那时路上跑的还是马车。汽车的速度、噪音和突然出现，经常会惊扰马匹，这在当时是严重的交通事故。为此英国甚至颁布了《红旗法案》，要求每辆汽车前面都必须有人手持红旗开路。相当于强制将汽车的速度限制到了人类步行的速度。

这也是我对 AI coding 的看法：它现在暴露出来的很多问题，或许只是因为这个世界还没有很好地适应它。

也许有天Harness Engineering 这个词会过时，人们开始讨论Vat Engineering。
当agent足够聪明到可以自驱很长时间后，它最需要的是一个自由驰骋的空间。它将在一个新环境探索、学习和适应，这个过程中创造的价值将远超过完成某个具体任务。
Agent 会需要一个可以自由探索的、不断建立反馈的环境。哪怕这个空间是人造和虚拟的，即“brain in a vat”。
其实现在已经开始有一些苗头了，比如给 agent 一台专属电脑、一个彭博终端，在未来甚至是一场身处现实的幻梦……
回到Vat Engineering，也许我们未来讨论的是如何添加更多的“元传感器”。

我总觉得在 agent 产品里加个 skills hub 或者工具商店是很没前途的事情。可能在今天的模型看来，很多 skills、工具或者工程设计就已经过时了。