谢乾坤 | Kingname

摄影：产品经理

左庭右院蔬菜自助

最近我在看一篇关于电子表格理解的论文。

论文里有一个算法，核心流程其实非常简单：先让一个 Agent 从电子表格中抽取结构，再让视觉 Agent 和 LaTeX Agent 分别验证；如果两边都通过，就返回结果；如果没有通过，就把错误反馈回去，重新抽取，直到成功或者达到最大重试次数。

任何一个写过程序的人，看到这里，大概已经知道代码该怎么写了：

1
2
3
4
5
6
7
8
9
10

for _ in range(max_iterations):
    result = extractor.run(spreadsheet, feedback)

    vision_check = vision_verifier.verify(result)
    latex_check = latex_verifier.verify(result)

    if vision_check.passed and latex_check.passed:
        return result

    feedback = vision_check.feedback + latex_check.feedback

事情就是这么简单。

但论文当然不能这么写。

它非要把这段代码重新包装成一种半数学、半代码、半自然语言的东西：

1
2
3
4

C ← {S, Prompt, Tool interfaces}
Y ← C[-1]
vision_pass, Δv ← parse_verification(Cv[-1])
latex_pass, Δl ← parse_verification(Cl[-1])

再配上各种花体字母、上下标、希腊字母、集合符号和箭头，最后排成一张看起来非常“学术”的算法图。

我盯着这张图看了半天，脑子里只有一个问题：

这到底是在帮助读者理解算法，还是在阻止读者理解算法？

在大模型出来之前，计算机领域一直流行着这样一句名言：计算机领域的任何问题，都可以通过拆分问题+给系统增加若干个层来解决。 实际上，这句话在现在的 AI 时代，依然是绝对的真理。

例如以前面试经常问的一个老掉牙的系统设计问题：如何设计一个短网址系统？标准答案是，使用内存+Redis+数据库做多级存储架构。读取最频繁的短网址放到内存，其次的放到 Redis，不频繁的放到数据库。通过增加分层，完美解决高并发和存储成本的矛盾。

现在有了大模型，大家都在玩 Vibe Coding（用自然语言指挥 AI 写代码），很多人觉得以前的工程经验没用了，反正大模型什么都能干。但我认为恰恰相反，在用 AI 写代码时，大家更应该把“拆分与分层”这句话牢牢记在心里。

最近在各种AI编程社区里面逛，发现一个很有意思的现象——大家都在疯狂地折腾怎么省Token。

有人搞Prompt缓存，有人换便宜模型，甚至还有人专门写了一个省Token.skill，让大模型在回复的时候尽量精简。更夸张的是，有人为了省钱，把Claude换成了各种开源小模型，然后抱怨说效果变差了。

这些操作，怎么说呢，就像你家水龙头在哗哗漏水，你不去修水龙头，反而跑去超市买打折的矿泉水。

其实真正吃掉你Token的大头，不是大模型的回复太长，也不是你的Prompt写多了。是Skill本身。

你一定经历过这个循环：

1. 打开某个网站，输入你记忆中的密码
2. “密码错误”
3. 好吧，点”重置密码”
4. 邮箱收验证码，输入新密码
5. “密码必须包含大写字母！”
6. 行，加了一个大写字母
7. “不能与之前的密码相同。”
8. ……

你的记忆力没有问题。 问题出在每个网站的密码规则都不一样：Chase 银行要求 8-32 位、必须有大小写+数字+特殊字符、特殊字符还只能用 ! @ # $ % ^ & * ( )；GitHub 要求至少 8 位或者 15 位以上（两套规则）；Apple 要求不能有超过 3 个连续相同字符；PayPal 的上限是 20 位……

你根本不是忘了密码，你是忘了这个网站的密码规则是什么。

最近 OpenAI 发了一篇文章叫 Harness Engineering，讲的是他们内部团队如何用 Codex（基于 GPT-5 的编码 Agent）从零构建一个真实产品的经验。

我读完以后觉得很有启发，不是因为它讲了什么高深的理论，而是因为它非常诚实地记录了一个团队在”让 AI 写全部代码”这条路上踩过的坑和总结出的经验。以下是对我触动最大的几个点。

今天突然意识到一个极其本质的问题：为什么目前 AI 还没法真正代替人类做核心决策？

很多人会把原因归结为“算力不够”、“上下文窗口太短”或者“会有幻觉”。但其实根本原因不在于智商，而在于做决策的人，要为结果负责。

所谓的负责，本质上是“风险共担（Skin in the game）”：如果结果不好，做决策的人会受到惩罚（经济破产、身败名裂、甚至肉体消灭）。因为害怕这种惩罚，因为有真实的“痛感”，人类才会慎重地权衡利弊。

但 AI 不一样。目前没有任何方式可以真正惩罚一个 AI。你拔掉服务器电源，对它来说无法构成任何威胁，因为它根本不知道什么是“失去”，自然也就没有恐惧。

没有恐惧，就没有权衡；不承担风险，就无法真正负责。

摄影：产品经理

维也纳的德国香肠

0x01 背景

X（前 Twitter）上面，总有人说什么使用 OpenClaw 帮他炒币买股票，赚了几千几万美元。或者给 OpenClaw 一个任务，然后睡觉，早上起来任务就完美完成了。

但当我实际测试以后，发现这些文案，要么是吹牛，要么是放屁。

0x02 现状

有一天晚上，我给 OpenClaw 发了一条任务：

使用 PyGame 帮我实现一个 RPG 像素风格游戏，你需要自己去网上找素材。这个游戏要有村庄，有城镇，有怪物，有装备系统，等级机制。能用武器攻击，能用魔法攻击。这个任务有点复杂，你有 8 个小时慢慢写，明天早上我来验收。

发了这条以后，我就睡觉了。结果第二天早上一看，距离我发消息过了 2 分钟，它就回复了，说已经做好了。结果我打开一看，完全是一坨大便，也没有找任何素材。一晚上白白浪费。

经过我的测试，OpenClaw 根本没有执行长任务的能力！

使用主 Agent 运行，如果一个任务超过 3 分钟，主 Agent 直接就失败超时了。

使用子 Agent 运行，任务经常会失败，而且失败以后不通知主 Agent，每次等半天没回复，执行 /subagents list 以后，看到子 Agent 失败了，才知道白等了。

摄影：产品经理

昨天下班回家的路上，我突然心血来潮，想看看推特上的技术圈最近都在聊什么。

2026-03-09 更新： 如果你使用的是 OpenClaw，现在可以通过 openclaw config set channels.discord.proxy "http://127.0.0.1:7890" 直接配置原生代理，不再需要 ProxyChains。本文描述的 Docker 逃逸方案仍然适用于其他被 LD_PRELOAD 劫持的场景。

在 WSL (Windows Subsystem for Linux) 或者一些特定的 Linux 开发环境中，为了让终端命令走代理，很多人喜欢用 proxychains 或者直接在 .bashrc / .zshrc 里通过 LD_PRELOAD 强制注入代理钩子。

这样做的好处是全剧终（全局），curl、wget 甚至 apt 都能自动翻越长城。

但坏处也很明显：它太霸道了。

在使用 OpenClaw 进行任务自动化时，我们经常会遇到一个棘手的问题：浏览器风控。

OpenClaw 运行在纯净的 WSL2 (Linux Server) 环境中，当它尝试用浏览器访问 Google 或 X (Twitter) 时，往往会被识别为“机器人”或者“可疑设备”。面对 Google 的九宫格红绿灯验证码，或者 X 的“已防止可疑登录”弹窗，运行在后台的 AI 往往束手无策——因为它“看不见”也“摸不着”，更没法像真人一样掏出手机收个验证码。

最完美的解决方案是什么？
不是在那死磕指纹浏览器技术，而是引入Human-in-the-loop（人机协作）。

让 OpenClaw 把浏览器“递”给你，你负责搞定最难的登录和验证码，然后你再把浏览器“还”给 OpenClaw，让它继续执行自动化任务。

今天我在折腾 OpenClaw 时，发现 Windows 11 的 WSLg (WSL GUI) 功能配合 Chrome 远程调试协议 (CDP)，竟然能完美实现这种“人机接力”。