我在平时开发、学习时非常讨厌一些网络问题，这些网络问题大多是GFW导致的。其实在这之外，Github的联网也有一些问题。

最近在本地终端折腾 OpenAI Codex。既然它能直接操作本地文件，我就在尝试：能直接用一句话命令它，帮我在本地生成一篇 Hexo 博客的 Markdown 文件，然后自动执行部署命令推送到我的 GitHub Pages 上？

预期中的剧本很简单：创建文件 -> 补充 Front-matter -> 执行 hexo clean && hexo g && hexo d -> 完美收工。

但这终究只是预期。当这个自动化链路真正在 Windows 纯命令行环境下跑起来时，现实并不顺利。短短几分钟里，我精准踩中了从网络协议、进程交互到环境变量的各种底层大坑。

以下是这次翻车与填坑的完整记录。如果你也在尝试把 AI Agent 接入本地工作流，这篇避坑指南应该能帮你省下大半天的 Debug 时间。

1. 刚出门就撞墙，WebSocket 报错 10061

当指示 Agent 在本地执行脚手架命令 hexo new post "codex测试" 时，终端直接甩给我一行红字：
Falling back from WebSockets to HTTPS transport... (os error 10061)

排查与解决：
这其实是个经典的网络代理问题。现在的终端 Agent 为了响应快，默认优先尝试建立 WebSocket 长连接。但在咱们的网络环境下，如果终端代理没配好，这个长连接请求就会被系统直接拒绝（10061 就是典型的 WSAECONNREFUSED 报错）。

好在 Agent 比较聪明，握手失败后会自动降级到普通的 HTTPS 去拉取数据，不影响它继续干活。但为了避免每次都浪费时间重试，最根本的解决办法还是老老实实在终端里把环境变量挂上：

1
2
# 确保当前终端走本地的代理端口
$env:HTTPS_PROXY="[http://127.0.0.1](http://127.0.0.1):YOUR_PORT"

2. 静默执行遇上密码弹窗，进程直接卡死

Agent 成功写好了 Markdown 原稿，接着进入最后一步，准备调用 hexo d 把生成的静态页面推送到 GitHub。结果进程直接崩溃了：

1
Error: Spawn failed... (无法读取用户名/密码，/dev/tty 不可用)

排查与解决：

这纯属是“无头环境”（Headless）引发的问题。

我之前推送代码走的是 HTTPS 协议，平时手动敲 hexo d 时，Git 会弹出一个凭据窗口让我授权或者输入密码。但现在是 Agent 在后台子进程里敲命令，它是一个没有显示器也没有键盘的“幽灵”，根本接不住这个弹窗，找不到可用的 /dev/tty（终端输入设备），于是进程当场假死。

加上 GitHub 早就禁用了密码推送，所以这里的唯一解法，就是彻底放弃 HTTPS，给本地配置 SSH 密钥免密登录。

3. 配好 SSH 却 Timeout，校园网/内网的常规操作

为了解决上一个问题，我生成了 Ed25519 密钥对，把公钥贴到了 GitHub 上。结果在终端一测连通性（ssh -T git@github.com），直接给我来个：

1
ssh: connect to host github.com port 22: Connection timed out

排查与解决：

如果是平时在学校或者公司的网络环境，看到 port 22 和 Timeout 连在一起，基本就可以破案了：网关防火墙把 SSH 默认的出站 22 端口给封了。

GitHub 官方留了个后门，允许我们通过 443（HTTPS端口）来走 SSH 流量。对于 Hexo 部署来说，去改本地的 ~/.ssh/config 有时候还会被忽略，最简单暴力的做法是直接改 Hexo 根目录的 _config.yml，把地址换成绝对 SSH URI，强行让 Git 走 443：

YAML

1
2
3
4
5
deploy:
  type: git
  # 换掉原来的 HTTPS 地址，强行指定 ssh.github.com 和 443 端口
  repo: ssh://git@ssh.github.com:443/TakamiyaMioo/TakamiyaMioo.github.io.git
  branch: main

4. 权限依然拒绝？Windows 与 Git 的“分裂”

这是最搞心态的一个坑。

我在 PowerShell 里手动执行 ssh -T -p 443 git@ssh.github.com，明明已经看到了成功的欢迎语（Hi TakamiyaMioo! You've successfully authenticated）。

回头让终端去执行 hexo d：

1
git@ssh.github.com: Permission denied (publickey).

排查与解决：

排查了半天才反应过来，Windows 环境下通常有两个互不干涉的 SSH 客户端！

刚才测试成功的，是 Windows System32 目录自带的原生 OpenSSH（它正确读取了我的私钥）；而 hexo d 唤起的 Git，用的是 Git 安装目录里捆绑的那个精简版 SSH。这两个客户端完全隔离，Git 拿着一把“空钥匙”去开门，当然被拒绝。

解决方法很简单，给 Git 加上一行全局配置，强行统一使用 Windows 系统的 SSH 客户端：

Bash

1
git config --global core.sshCommand "C:/Windows/System32/OpenSSH/ssh.exe"

执行完这句后，再次部署，全程 0 弹窗、0 报错，文章终于被 AI 顺滑地推到了云端。

总结与启发：别让你的 Agent 乱烧 Token

扫清了上面的基础设施障碍，AI Agent 才算真正接入了本地工作流。但经过这次折腾，我也发现了终端 AI 的一个极其费钱的陷阱：如果不加约束，它每次都会去扫全盘文件，疯狂消耗 Token。

想要高效、便宜地使唤这些智能体，得记住两点：

  1. 给项目加上 Git 灵魂：就算只是个纯文本的博客目录，也一定要 git init！现代的终端 Agent 极其依赖 Git，有了 Git 记录，它每次启动只需读取 git status，只把有改动的文件塞进上下文，能省下 90% 以上的无意义开销。
  2. 拒绝模糊指令，使用绝对路径：别跟 Agent 说“帮我改下昨天写的那篇测试文章”，直接下达精确指令：“分析 source/_posts/codex测试.md，在文末加一行署名”。精准投喂，效率最高。

想要让 AI 顺畅接管工作，底层环境（特别是网络与 Git 权限）的稳定是第一步。基础打好了，上层玩起 AIGC 自动化才能真正起飞。