囚笼 ​

你有没有想过, 我们在借助 AI 大人那份如今而言可谓无所不能的力量时为什么常常要把它囚禁在某个 Coding Agent 里? 现在流行的 Agentic 软件大多都做了太多不该自己全部做完的事, 这导致用户不得不对其中的某个或某几个产生了粘性. 如果只是这样其实也没多大问题, 毕竟大部分人本就没有频繁地在各种 Coding Agent 之间换来换去的需求.

然而在这样本地优先的用法里, Agentic 软件做的这些额外的事还会带来一个更严重的问题: 用户的工作流和具体的物理设备形成了绑定.

举个简单的场景作为例子, 你在自己的笔记本上精心调教了某个 Coding Agent, 这包括软件层面的设置, 用户级的 Skills 与交互偏好, 还有连续用了几个月积累下来的长期记忆. 某一天你公司要求在公司的设备上开发, 于是你不仅要重新安装 cli, 配置供应商, 还要从头驯化它的脾气, 把你做的那些调教想办法迁移过去.

安装 CUDA ​

参考 WSL 安装 CUDA

编译 Whisper.cpp ​

git clone https://github.com/ggml-org/whisper.cpp.git
cd whisper.cpp
cmake -B build -DGGML_CUDA=1
cmake --build build -j --config Release

现象 ​

在自己的程序中使用类似下面的代码监听 SSH 的全局请求:

for {
  select {
  case <-ctx.Done():
    return nil
  case req, ok := <-globalReqs:
    if !ok {
      return nil
    }
    // Handle request
    fmt.Println("Received global request:", req.Type)
    req.Reply(true, nil)
  }
}

发现发来的请求有时候没有接收到, 而对端的提示是 reject, 甚至出现 reject, 成功 如此交替出现的情况 (那很公平调度了).

其实很明显是有啥东西和自己的代码在抢同一个通道, 但是因为我一直在找发送端的代码问题, 为这个问题浪费了一晚上的生命, 甚至怀疑这库有 bug

感觉还不如以前的CRT. 😓

场景 ​

1. 同步 upstream 仓库的更改到自己的 fork
2. fork 仓库的分支与 upstream 的分支有冲突
3. 仅更新自己的 fork 分支, 并保持提交记录整洁

省流就是别用 pgloader , 它已经不支持新版 mysql 和 postgresql 了