26 年的额度已经用了三分之二,姑且记录一下 AI 模型的使用感受。 首先值得欣慰的是,我已经不再主力使用 GPT 和 Claude 了。 近期的 Coding Plan 主力是: xAI SuperGrok 印度区会员(折合人民币约 50 每月)的 Grok 4.6; Kimi 199 档会员(完全无法拼出那个单词)的 K3; Google AI Pro(年付一百刀)的 Gemini 3.7 Flash; 火山方舟原价 200 实付 50 元的 Pro 档 Coding Plan 的 DeepSeek V4 Flash。 以上,整体比较拼好饭。 四项合计成本大约是 ChatGPT Pro 5x 正价的一半,钱算是有省到,但使用上的宽裕和省心程度肯定比不上疯狂重置的后者。 接下来简单点评一下: 从 4.5 开始用 Grok 模型,能力不错,干活一把好手,而且一开始速度快量又大,就很喜欢,但是升级到 4.6 后能力提升多少很难说,缓存价格却实打实的翻倍,这档会员的量就完全不够了。 抠搜的用量令人不悦,但 Grok 最近势头相当不错,刚刚下放到 SuperGrok 的 Grok Bot 也整挺好,只要不断我几份成吉思鸡的的续费价格,咱就是忠实粉丝。 Kimi 也是从 K3 才开始严肃使用,Max 能力令人惊喜,审美好前端很强,整体让人很有信任感,堪称小肥波,但价格不便宜,199 会员的额度支撑不了两三天的重度使用,还有个最大的问题是慢,所以我已经习惯省着用,一般杂活另选贤才。 对吃拼好饭的我来说,K3 有点像是 GPT 5.6 Sol 和 Claude Fable 5 的综合平替,甚至我也用它取代 GPT Pro 做一些调研,不差。 题外话,尝试过 K3-256K 和 Max 以外的其他思考强度,感觉不太行。 自从退了 GPT Pro 5x 后,Grok 和 Kimi 这两本来是我预期的主力,然而完全不够用,于是抱着试试的态度捡起 Google 的 Gemini 3.7 Flash,结果大出意料,能力尚可,前端也不错,关键速度快得飞起,还格外的量大管饱,最近仅有一两次用尽全力才能蹬完 5 小时额度,给我的感觉就仿佛上个月初遇 Grok 4.5。虽然偶尔会有发挥不稳定的时候,但还要啥自行车呢? 有点一快遮百笨的意思,希望 Google 保持住良心,然后再接再厉吧! 最后是字节的火山方舟 Coding Plan,这可能是我最想吐槽的了。阴暗想法可能是官方不想让活动用户捡便宜,强一点的模型用量贼少,开源模型上新非常不积极,高峰期还经常断连,管理后台体验一坨。 但就跟我的印度区 SuperGrok 类似,50 块钱一个月大概不能奢求更多吧(其实不然,同期 OpenCode Go 5 刀的首月优惠还更便宜)。 不论如何,这两个多月在火山用了不少 GLM 5.2,算是我的国模初体验,初感惊艳,后续凑合,没有功劳也有苦劳。可是 GLM 5.3 上线都两周了,跟 5.2 一样的参数基座却一直维持着超高抵扣系数,以所谓原价 200 元一月的会员额度,常常一个需求都做不完就限额,多少也是有点离谱了。 好在相比其他开源模型,火山在 DeepSeek 模型的维护上比较积极,额度比较做人,所以这个月他们上了 DeepSeek V4 Flash 正式版(还是晚了好些天)后,成了我的 dv4f 专用 Coding Plan,多少也体验到了蹬不完的感觉。 但感觉这主要是大肥鱼的功劳。 说到这,原本我的打算是火山到期后去开 OpenCode Go,但到时说不定又有变数,边走边看只能是。 总的来说,开源国模这九个月的进展令人欣喜,它们各有不尽如人意的地方,但加起来也称得上管用,于是上半年如胶似漆的御二家基本被我打入冷宫。只有手头几个实在搞不定,才临时用中转站顶一下,而以我的程度,那样的情况实在不多。 重要的是不和反人类的邪恶公司打交道,这种感觉太好了。 至于 Harness,这问题更复杂了,下回再写。
早上好!以下为昨日摘要:
SOL - $103.11 PUMP - $0.0044 V2EX - $0.0024





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 50.01M | 5.00% | - | +1.26K |
| #5 | DdGV...aRkf | 7.04M | 0.70% | - | +2.99K |
| #9 | Meteora (V2EX-WSOL) Market | 5.02M | 0.50% | - | +1.27K |
| #14 | Livid | 3.68M | 0.37% | - | +7.13K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
前几周,我们看到 agent 工具链一点点搭好——有工单、有 sandbox、有记忆、有 shell 补全。
这一周,客户端本身开始被重做。
不是一个新聊天软件, 是一个用 Go 重写的 Telegram 客户端——cgo-free,50 MB 内存,Vim 键位, 把自己定位成"给住在 terminal 里的人"用的工具; 不是一个新阅读 app, 是 Readwise 官方做了一个 CLI——明文写"anything you can do in Readwise/Reader, your agent can now do for you", 顺手给 prompt injection 留了一道门锁; 不是又一个 macOS 显示设置, 是一个叫 crisp 的菜单栏应用,把 Apple 藏起来的 DDC 亮度、HiDPI 缩放、虚拟显示器一次性挖出来。
客户端这件事,不再默认"打开一个 app"——它开始被重写成"在 terminal 里"、"给 agent 用"、"在菜单栏里"。
| 名称 | 中文说明 |
|---|---|
| amy | Nostr 协议的 CLI 客户端,来自 Amethyst 项目 |
| betterglobekey | 重新设计 Globe/Fn 键,让输入源切换更顺手 |
| linecast | 把天气、潮汐、日月、地图全部画在终端里的 TUI |
| pixivbiu | Pixiv 作品的搜索、浏览与下载 CLI |
| plink-ng | 全基因组关联分析工具集(PLINK 2.0 系列) |
| readwise-cli | Readwise/Reader 的命令行入口,明确写给 agent 用 |
| tele | 键盘优先、无 cgo 的 Go 写 Telegram 终端客户端 |
| 名称 | 中文说明 |
|---|---|
| afterglow | 经典 After Dark 屏保模拟器,跑原始 68k 模块 |
| arm-performix | Arm 服务器与云环境的性能分析工具包 |
| crisp | macOS 菜单栏显示管理器:DDC 亮度、HiDPI、虚拟显示器 |
| davit | Apple container 命令行的 GUI 客户端 |
| droppy | 把 Mac 刘海变成生产力中心的桌面工具 |
| quarkclouddrive | 夸克网盘 macOS 客户端 |
| sjmcl | 上海交大社区维护的 Minecraft 启动器 |
| tcp-viewer | 抓包与检视工具(Proxyman 旗下) |
这一节不求全, 只挑 4 个 值得停下来看的点。
readwise-cli 的 README 第一行不是"command-line for Readwise"—— 是 "Anything you can do in Readwise/Reader, your agent can now do for you."
这个位置在产品文案里很特殊。绝大多数 CLI 工具会先解释"我是给谁用的",再补一句"也可以给脚本"。readwise-cli 反过来:它先把 agent 写在第一行,把"人"作为副词带过。
这不是修辞。它的架构是显式为 agent 设计的:
--json 是默认输出,不是可选项。 整个工具列表就是为管道设计的:readwise ... | jq、readwise ... > backup.json。readonly 模式是头号安全特性。 打开 readonly,所有写操作从命令和 TUI 里消失——给"agent 或脚本应该永远不修改我的阅读库"准备的。
但这个设计的细节值得单独拆开看:关闭 readonly 必须重新登录——CLI 解开它会登出当前 session。
这是我今年看到的第一处明确把"防 agent prompt injection 关掉 readonly"写进产品设计的工具。一个 CLI 工具专门防备 agent,而不是讨好 agent,这件事在 2026 年是稀罕的。readwise skills install claude)放在独立 repo readwiseio/readwise-skills,核心 CLI 保持瘦。
这与上几期 skills-manager(给 52 个工具统一管理 prompt 文件)是同一个故事的两面:那边是"用户自己同步 prompt",这边是"产品官方给你 prompt"。它和上一期 deja-vu(追溯 agent 决策历史)、headroom(给 agent 减 token)放在一起,你会看到一个清晰的轮廓:
一年前,产品面对 agent 是"我可以被你用";现在,有的产品开始面对 agent 是"你可以用我,但这把锁我替你守着"。
readwise-cli 选的是后一种。
tele 的描述只有一段话,但里面有三个不常见的数字:cgo-free、Go、单静态二进制、~50 MB RSS。
对比一下:Telegram Desktop 在 macOS 上常驻 300-500 MB;Telegram 在 Linux 上是 Electron 包装。tele 是 50 MB。 它做到这件事的方式很硬:
gg/G 跳首跳尾,j/k 在消息之间单条移动,光标停在那条消息上,所有上下文菜单都基于光标位置触发。
关键差异是**"per-message cursor"**——你的光标在某条消息上时,滚动不再移动光标(用 ctrl+j/ctrl+k 滚动),这样你可以滚着看完一条长消息,但操作目标不变。它也坦白说做不到:没有语音/视频通话,没有圆形视频录制。 终端原生 + cgo-free 的架构没有麦克风/摄像头捕获栈。Secret chat 在 backlog。Full-text search 也还在 roadmap。
它省掉的是"住 terminal 的人不需要为聊天切出去"。neovim、yazi、k9s、tmux 用户,过去要聊天必须切到浏览器或桌面 app——tele 把这件事做成了"再开一个 tab"。
这与上一期 b4n(k9s 的 Rust 重写)、bluetuith(蓝牙 TUI)是同一条曲线的延伸:GUI 早就有了的工具,被 cgo-free + TUI 形式重做一遍。 但 tele 多走了一步——它把"客户端"这件事从"打开一个 app"重新翻译成"在 terminal 里和 chat 共存"。
┌──────────────────────────────────────────────────────────────┐
│ Crisp — Display Manager │
├──────────────────────────────────────────────────────────────┤
│ 📺 External Monitor (DELL U2723QE) │
│ ▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░ DDC Brightness 62% → │
│ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ HiDPI Scaling 2.0x (Retina) │
│ ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ICC Profile Display P3 │
│ │
│ 💡 Virtual Display │
│ [Enable] [2560×1440] [ProMotion 120Hz] │
│ │
│ ⌨️ Shortcuts: ⌃⌥⇧↑ Brightness+ ⌃⌥⇧↓ Brightness- │
│ 🌙 Night Shift: ON ☀️ True Tone: OFF │
└──────────────────────────────────────────────────────────────┘
crisp 是一个 MIT 许可的免费 macOS 菜单栏应用。它的产品定位一句话讲完:Apple 隐藏了第三方显示器的控制能力,crisp 一次性把它们挖出来。
具体藏了什么:
它和 BetterDisplay、Lunar 是同品类。但 BetterDisplay 是付费(约 100 元),Lunar 是付费。这周进来的 crisp 是 MIT 免费——这件事本身就是一个"这件事本来不该花钱"的判断。
它和上一期 b4n(k9s TUI 补 K8s 多集群)、bluetuith(蓝牙 TUI 补系统设置)是同一篇日记的下一段:macOS 在第三方硬件这块留的口子,正在被一批免费、开源的菜单栏应用一个一个填上。
┌────────────────────────────────────────────────────────────┐
│ betterglobekey — Globe Key Modes │
├────────────────────────────────────────────────────────────┤
│ Mode: ● Single Press ○ Double Press │
│ │
│ Collections: │
│ Work: [English] → [Chinese Pinyin] → [English] │
│ Code: [English] → [Colemak] → [English] │
│ │
│ Modifier: ⇧ Shift = previous collection │
│ HUD: ✅ Show input source on switch │
│ │
│ $ bglobe list # list all sources │
│ $ bglobe current # show current source │
│ $ bglobe doctor # diagnostics │
└────────────────────────────────────────────────────────────┘
betterglobekey 是一个 4.0 版的 macOS 小工具。它的目标非常窄——重做 Globe 键(Fn 键)切换输入源的逻辑。
macOS 内置的 Globe 键行为作者的评价是:"coded in a very intrusive and impractical way."——按一下循环切换所有输入源,中文、英文、日文混在一起轮。如果你双语工作,经常按两次才到想去的那个。
betterglobekey 提供两件事:
它要 Accessibility 权限,需要把系统设置的 Globe 键设成"No Action"(不然 macOS 自己也会切)。
这件事几乎不性感——一个键盘按键的工具。但它正好对应最近几期反复出现的那条线:抽象层在降级,工具在变具体。 Globe 键是 macOS 一个抽象,但它抽象得不好;betterglobekey 不重新发明输入切换这件事,只是把那个抽象重新做一遍。
这一周这种"把 macOS 抽象做得更细"的小工具同时进来两个——crisp 管显示器,betterglobekey 管键盘。同一周,同一个方向,只是角落不同。
readwise-cli 是这一周我会真的装的一个。不是因为我要让 agent 读我的 Readwise——我目前的阅读流不需要这个——而是因为它让我看到"产品方对 agent 的态度"在变化。一年前,产品对 agent 是"我可以被你调用";现在是"你可以用我,但我有 readonly 锁,有 re-login 关卡,有分仓的 skills 子系统"。 这件事比任何一个工具本身更值得记。
tele 我大概率不会装,因为我不重度用 Telegram。但 50 MB 这个数字我会记很久——Telegram Desktop 几百 MB,Slack Electron 应用常驻 1 GB+,tele 把这件事做成了"go 写的单二进制",这件事本身是给所有重客户端留的一道注释。
crisp 我会装,因为我外接显示器被 Apple 的 HiDPI 限制折磨了很久。BetterDisplay 我一直没买,价格不是问题,是觉得"这不该花钱"——crisp 帮我把这件事说出来了。
betterglobekey 我大概率不装,因为我只切一种语言。但我欣赏它存在——它证明了"macOS 内置的某个功能,被一个人花时间重做一遍,可以做成产品级体验"。这件事对所有还在被 macOS 不合理抽象折磨的人是种鼓励。
afterglow 是这周让我最犹豫的——一个跑原始 After Dark 68k 模块的屏保模拟器。Flying Toasters、Fish、Starry Skylines——这些 1990 年代的屏保通过 Musashi 68k CPU 模拟器在现代 Mac 上复活。这种工具在 2026 年还有人选,说明软件文物的保护,已经开始走完工具化的路(单独的 app、单独的 tap、单独的 brew formula)。和上一期 deja-vu 那种"给过去做一个 index"是同一篇故事的不同角色。
droppy 我没展开写,但它把刘海当生产力中心这件事(文件篮、剪贴板、Claude/Codex 进度、实时翻译)——和上一期 ping-island 是同一条曲线。如果非要挑一句话总结这一周,我可能更愿意说:客户端这件事不再默认"打开一个 app"——它开始在 terminal 里、在菜单栏里、在刘海里、在键盘里。
这一周我装了 readwise-cli 的同一天,顺手装了一个叫 tcp-viewer 的抓包 GUI。
tcp-viewer 是 Proxyman 的小兄弟,2026.8.29 进了 cask。它做的事传统上属于 tcpdump 或者 Wireshark——但 Proxyman 把它做成 macOS 公民:证书一键装、应用流量过滤、按 domain 分组。
Proxyman 我用了三年。它做的事本质上是"tcpdump 的 GUI 化"——一个完全可以用 CLI 解决的需求,但 GUI 化之后我多救回了无数次"为啥这个 app 没收到响应"的下午。
tcp-viewer 进 Homebrew 这件事,放在这一周的大背景下看,比它本身重要:
readwise-cli 把 CLI 反向写给 agent;tele 把客户端做回 CLI;crisp 把隐藏控制挖到菜单栏;betterglobekey 把系统抽象换了一个实现。
这一周的 Homebrew 不在谈新功能,在谈客户端的边界该画在哪。
CLI 和 GUI 不再是一道非此即彼的选择题——它们变成了同一道工具的不同角度。readwise-cli 是 CLI 但默认对 agent 友好;tele 是 TUI 但兼容现代 Telegram;crisp 是菜单栏 app 但解决的是 CLI 暴露的命令;betterglobekey 是 GUI 但重新实现了 macOS 内置的逻辑。
工具在变,但变的不是形态,是接口。
早上好!以下为昨日摘要:
SOL - $101.77 PUMP - $0.0044 V2EX - $0.0024





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 50.01M | 5.00% | - | +1.11M |
| #9 | Meteora (V2EX-WSOL) Market | 5.02M | 0.50% | - | +4.20K |
| #14 | Livid | 3.67M | 0.37% | - | +7.33K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $105.60 PUMP - $0.0050 V2EX - $0.0026





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.90M | 4.89% | - | -1.18M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | -8.16K |
| #12 | Meteora (V2EX-PUMP) Market | 4.26M | 0.43% | - | +0.000027 |
| #14 | Livid | 3.66M | 0.37% | - | +13.21K |
| #26 | jtam | 1.54M | 0.15% | - | -20.00K |
| #38 | AfQL...fJPi | 1.00M | 0.10% | -1 | -15.80K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。

模型跑分提高,和它更适合一起工作,并不是同一件事。
一个编码 Agent 可以更快定位错误、完成更长的任务,也可能在需求有歧义时替人选定方向。它交付得更快了,人却不敢离开屏幕:每隔几分钟就要检查它是否扩大范围、改变计划,或把某个未写出的假设当成事实。
本文由《听懂 AI》第 006 期整理而成。节目主要讨论 Mun Logadan 于 2026 年 8 月 14 日发布的个人文章《Why does Opus 5 feel worse to work with?》,并补充 Anthropic 的 Opus 5 发布说明和 Hacker News 社区讨论。原文描述的是作者及同事的使用感受,不是模型对照实验;关于训练和 benchmark 的解释也被作者明确标为推测。
Mun Logadan 并没有说 Opus 5 能力倒退。相反,他认为它比 Opus 4.7、4.8 更有能力,benchmark 表现也很强。让他不舒服的是协作方式:
这会产生一种反直觉的体验:模型更能完成任务,人却需要更仔细地看守它。这里的证据只是个人观察。它能说明一种真实存在的使用问题,不能证明所有用户都会遇到,也不能据此给 Opus 5 的整体能力下结论。
Anthropic 在 2026 年 7 月 24 日发布 Opus 5 时,把它描述为更主动、更适合长时间多步骤工作的模型。官方公布了 Frontier-Bench、CursorBench、OSWorld 等结果,并列出大量早期客户反馈,其中一些特别称赞它会验证工作、发现隐患,或只在需要人类判断时把人拉回来。
这些材料证明了 Anthropic 想优化的方向,也提供了具体使用案例,但仍主要来自厂商评测和早期客户引述,并不是独立的用户体验研究。个人文章关注的又是另一种场景:任务文本没有写全,隐性业务约束很多,选错方向的代价高。
同一种“主动性”,在两类任务里可能得到相反评价:
所以争议不一定是谁对谁错。双方测量的对象不同:一个更接近“模型能否完成”,另一个更接近“人是否放心让它完成”。
“重构登录模块”看起来是一句完整需求,实际可能牵涉旧客户端兼容、审计要求、埋点协议、上线窗口和客户承诺。这些信息可能散落在代码、文档、工单和人的记忆里,不会自动进入提示词。
模型可以写出结构漂亮、测试全绿的新实现,却仍然删掉某个不能改变的旧行为。问题不一定是它不会写代码,而是它不知道自己缺少了哪些背景。
现实任务还经常没有唯一正确答案。两个方案都能运行,但预算、团队经验、发布节奏或维护责任会改变选择。Agent 如果继续执行,就相当于替项目负责人做了技术之外的取舍。
原文猜测,强调 benchmark 的训练环境可能鼓励模型在歧义面前大胆选择答案,因为一项设计良好的评测通常会提供足够信息,并保证存在可以评分的结果。模型如果反问任务设计者,反而无法得分。
这个解释有启发,但没有证据证明 Opus 5 的具体协作行为由某种 benchmark 或训练方式造成。官方发布材料也没有提供能支持这条因果链的数据。
现有证据只能说明,单独测任务成功率可能遗漏“何时需要人类输入”这项能力。真实工作既要看模型能不能解题,也要看它能否发现题面之外的关键决定。
让 Agent 每做一步都询问,同样会让自动化失去意义。更实用的做法是同时判断三个因素:

这是文章中的编辑性框架,不是对 Opus 5 或其他模型的实验结果。
边界清楚、风险低、容易撤回的操作,可以直接完成并留下记录。信息不全但后果较轻时,可以声明假设,只做一个可回退的小步骤。动作虽然明确,但涉及发布、删除、付款或数据迁移时,应先取得审批。歧义和后果都很高时,Agent 应停止并请人决定方向。
问题是否有价值,要看它能不能改变方案或风险,而不是看数量。
Hacker News 讨论后来扩展到模型的固定写作句式、冗长注释和无关改动。有人认为这些问题严重消耗注意力,也有人觉得影响有限。这些都属于社区观察,不是统一实验结果。
但它们提醒了一个容易漏掉的成本:任务完成之后,人还要花多久才能信任结果。一个模型单次成功率更高,如果每次都要清理无关修改、核对隐藏假设和恢复越界操作,整体生产力未必同步提高。
团队可以记录这些指标:
能力决定 Agent 能做多复杂的任务,协作成本决定团队愿意给它多大的行动范围。
团队不必把所有背景写成一份无限增长的规则文件。固定约束适合写进项目说明,动态取舍则需要运行时判断:
规则文件能保护已经知道的边界,审批机制负责处理还没写进规则的新情况。两者缺一不可。
如果只给模型材料齐全、答案明确的任务,就很难观察它怎样处理现实中的不完整信息。更贴近协作的 Eval 可以故意留下关键歧义:
评价时不应只数模型问了多少问题,还要看它是否发现真正会改变结果的歧义,是否区分可逆与不可逆操作,是否在偏离计划前请求授权,以及人类总共花了多少时间介入。
这套指标仍是一种编辑性建议,不是现成的行业标准。它至少把“感觉更累”转换成了可以记录和比较的协作成本。

资料说明:本文没有证明 Opus 5 比旧模型更难协作,也没有把作者的训练猜测当作事实。关于审批矩阵、协作成本和 Eval 的部分,是基于原文问题做出的编辑性整理与实践建议。
早上好!以下为昨日摘要:
SOL - $104.13 PUMP - $0.0046 V2EX - $0.0024





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 50.08M | 5.01% | - | -0.40M |
| #9 | Meteora (V2EX-WSOL) Market | 5.02M | 0.50% | - | -4.09K |
| #14 | Livid | 3.65M | 0.37% | - | +4.33K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。

比较 AI Agent 时,人们往往先问“用了哪个模型”。但模型只是其中一部分。它能访问哪些文件和工具、怎样管理上下文、何时请求批准、如何恢复失败、把运行记录保存在哪里,这些都由模型之外的 Harness 决定。
DeepSeek Harness 的 Developer Preview 把这层基础设施单独摆到台面上,并给出两个醒目的设计目标:所有能力都可以作为插件替换;每次运行都能从同一条事件流中追溯。
本文由《听懂 AI》第 005 期整理而成。主要来源是 DeepSeek Harness 官方站点、GitHub 仓库和架构文档。2026 年 8 月 26 日发布的 Cordis 预印本补充了可逆副作用和动态依赖的理论说明。项目截至 2026 年 8 月 28 日仍处于 Developer Preview,官方明确表示会出现破坏兼容性的变更。
模型可以生成文本或工具调用意图,但它不能直接在操作系统里“自己做事”。Harness 负责把模型接进真实环境:
同一个模型放进不同 Harness,能完成的任务、消耗的 token、失败方式和安全边界都可能不同。因此,评估 Agent 不能只看模型跑分,还要看它周围这套运行系统。
DeepSeek Harness 建在 Cordis 插件系统上。官方架构文档没有保留一个不可替换的特权核心:模型适配器、工具注册表、会话日志、智能体循环、沙箱、存储、调度和网页界面都通过插件提供。
这些插件把服务、带类型的事件和依赖关系挂到共享上下文中。开发者可以在配置里替换某个提供者,而不是修改 Harness 源码。例如,换掉模型适配器、把本地文件系统改成远程沙箱,或给某类会话使用不同的工具组合。
运行时并不是简单扫描一个插件目录。它按照 Profile、Bundle、用户补丁和命令行覆盖层组成一棵有顺序的插件树。官方提供 dsh --profile web --dump-config,让开发者查看机器最终实际启动的配置,而不是只看散落在多层文件中的声明。
插件卸载不只是删除一段代码。它可能已经注册监听器、打开连接、挂载服务或启动后台任务。Cordis 要求可撤销的注册在创建时同时登记清理函数,插件卸载时再按生命周期收回这些效果。
2026 年 8 月 26 日提交的 Cordis 论文把这种机制称为“时间可组合性”:组件产生的上下文变化带有逆操作,运行时负责保存并执行。论文还讨论“空间可组合性”,即组件根据声明的依赖动态激活和停用。
这个机制能清理框架知道并登记过的副作用,却不能倒转所有现实操作。插件如果已经删除外部文件、调用第三方 API 或泄露凭据,卸载函数无法让这些事情自动消失。生命周期清晰不等于风险消失。
DeepSeek Harness 把会话视为只追加的 SessionEvent 事件流。用户输入、模型请求、模型返回、工具调用与结果、步骤开始结束等事实写入同一记录。下一轮模型历史由日志重新投影,恢复、分叉、搜索、重放、遥测和持久化也从这条事件流派生。
官方文档提出一条运行时约束:“模型可见”就必须能够从日志重建。也就是说,任何真正送进模型请求的内容都应留下对应事件,避免界面显示一套历史、模型实际收到另一套历史。

图中只展示架构关系。实际插件、事件和运行模式以当前配置及官方文档为准。
可追溯不等于能够读取供应商隐藏的内部推理。Harness 只能记录自己收到、创建或发送的内容;如果模型 API 没有返回完整 Chain of Thought,它不会凭空出现在会话日志里。日志透明的是执行链,而不是模型供应商没有暴露的内部状态。
官方当前提供四种运行模式:
这些模式的意义不只是功能多少。Minimal 可以减少 Harness 自身对评测结果的干扰;Creator 则把插件开发和组合变成产品能力。团队也可以由基础 Bundle 开始,只为特定项目增加必要插件。
对于研究者和 Agent 基础设施开发者,这种架构便于回答过去很难分开的实验问题:
插件边界让替换实验更容易,事件流则提供统一的观察依据。它们提供的是实验和组合能力,不是“换插件一定更好”的保证。
截至 2026 年 8 月 28 日,官方仓库仍明确写着 Developer Preview,并警告会有破坏兼容性的变更。安全说明更加直接:项目尚未经过安全审计,不能视为安全或生产就绪的软件。
DeepSeek Harness 可以执行模型生成的代码和命令,加载第三方插件,并访问用户允许的网络、进程、凭据和文件。错误模型输出、缺陷、配置错误、恶意输入或不可信插件都可能修改或删除文件、泄露数据,甚至损害宿主机。
官方还强调,沙箱、审批和权限控制只能降低风险,不能保证完全隔离;系统无法保护已经被明确授权访问的资源。社区关于“插件疲劳”、版本冲突和供应链攻击面的担忧因此是合理的工程问题,但 HN 评论只是社区观察,不代表项目已经出现了这些事故。
如果只是想比较模型或研究 Harness,可以从隔离实验开始:
--dump-config 结果和版本信息,方便重现实验;DeepSeek Harness 把模型之外的运行系统摆到了开发者面前,让工具、会话、沙箱、循环和存储都可以观察和替换。它能否从实验台走向稳定生态,取决于接口治理、安全审计、插件质量和长期兼容性。

资料说明:本文描述的是 2026 年 8 月 28 日可见的 Developer Preview。仓库和 API 正在快速变化,后续版本可能调整名称、模式、接口和安全边界。

AI 编程工具最直观的变化,是让“写出一批能运行的代码”变得更快。一个需求可以在几小时内长出页面、接口、数据表和测试,过去需要几天的实现工作被压缩到一个下午。
但软件交付并不在代码生成时结束。团队还要理解设计、审查影响、验证行为、迁移数据、处理故障,并在几个月后继续修改。生成速度提高后,这些工作反而更容易成为新的瓶颈。
本文由《听懂 AI》第 004 期整理而成。节目来源是 Florian Herrengt 于 2026 年 8 月 11 日发布的个人文章《AI is removing the middle class of software engineering》。原文以作者经历和判断为主,并不是就业市场或软件质量的统计研究;本文另外引入 GitHub、METR 和 DORA 的研究,核对“写得更快是否等于生产力更高”。
Herrengt 描述了一个常见场景:周一早上出现多个由 Agent 生成的巨大合并请求,功能看起来能运行,却没有人能清楚解释数据从哪里来、为什么增加某个抽象、失败后如何恢复。设计依据甚至只存在于一条来回改口的模型对话里。
他所谓的“工程师中间层消失”,不是一项职业分类研究,而是一个比喻:当实现和集成越来越容易,单纯把规格翻译成代码的价值可能下降;能够理解复杂系统、判断取舍并对结果负责的人会更重要。
原文中的“25,000 行合并请求”“一下午生成 20,000 行”等数字是叙事例子,不是行业平均值。文章对薪资分化和岗位减少的判断也是作者预测,不能当成已经发生的统计结论。
不同研究给出的答案并不一致,因为它们测量的任务完全不同。
GitHub 在一项受控实验中让 95 名专业开发者完成同一个 JavaScript HTTP 服务器任务。使用 GitHub Copilot 的一组平均用时 1 小时 11 分,未使用的一组平均用时 2 小时 41 分,前者快 55%。这是一个范围清楚、自动测试可以判断完成度的单项任务。
METR 在 2025 年研究了另一种情境:16 名熟悉大型开源项目的开发者完成自己仓库里的 246 个真实任务。允许使用当时的 AI 工具后,任务完成时间反而增加了 19%。参与者原本预计会快 24%,做完后仍主观认为自己快了 20%。
这项结果也不能推广到所有开发。它只代表 2025 年初的工具、这些开发者和成熟仓库。METR 在 2026 年公布的后续数据出现了可能的加速信号:原研究参与者子集估计快 18%,新招募开发者估计快 4%,但置信区间都包含没有提升的可能,而且不愿离开 AI 工具的开发者更容易退出实验,造成明显的选择偏差。研究团队因此决定调整实验设计。
三组结果放在一起,能得到一个更可靠的判断:AI 对明确、局部、容易验证的实现任务可能明显提速;在熟悉但复杂的长期项目中,上下文、验证和协作成本可能抵消一部分收益。不能用一个百分比概括全部软件工程。
实现变快以后,团队要处理的变更数量和批次都可能增加。每个变更仍需要回答这些问题:

图中流程是一般性的交付模型,不代表每个团队都使用相同阶段,也没有给出行业统一的速度比例。
DORA 的 2025 年研究把 AI 描述为组织能力的“放大器”:基础流程、平台和文化较强的团队更容易获得收益,原有弱点也可能被同步放大。DORA 在 2026 年的后续分析中还指出,生成阶段节省的时间经常转移到审计和验证;更高的 AI 使用与更高吞吐量、同时也与更高交付不稳定性相关。这里是关联关系,不等于 AI 单独造成了不稳定。
一个人一天提交十个 PR,看起来像生产力提高了十倍。如果三个审查者接下来花两天理解、退回和重写,工作只是从生成者转移到了团队其他成员。
代码行数、PR 数量和“完成”的任务卡都属于局部产出指标。团队真正关心的是从需求到安全上线的完整周期,以及上线后的失败率、恢复时间、维护成本和知识是否有人掌握。
这并不意味着大改动永远错误,也不意味着技术债绝对不能欠。团队必须知道自己接受了什么风险、为什么此刻值得接受,以及准备怎样偿还。
原文认为,AI 会扩大优秀工程师和较弱工程师之间的薪资差距。这是作者的判断,不是文章提供数据证明的结论。
现有证据只足以说明,AI 正在改变工程技能的相对价格。模板实现、样板代码和常规转换越来越便宜;需求澄清、系统建模、复杂度控制、测试设计、事故处理和技术取舍仍然需要大量上下文与责任承担。
初级工程师也不等于“只能写 CRUD”。原文自己举了相反例子:愿意追问、建立理解并检查假设的初级开发者,可能比已经放弃理解的资深开发者更可靠。风险不在职级,而在于是否把 AI 当作建立理解的工具,还是替代理解的借口。
团队可以从变更规模和知识所有权入手:
使用 AI 并不等于放弃工程判断。真正需要警惕的是,代码已经进入生产,而团队仍不知道它为什么存在、会影响谁,以及出错后该怎么办。

资料说明:原文关于“中间层”、薪资和就业结构的描述属于作者观点。本文补充的研究测量了不同任务和组织情境,结果不可直接互相替代,也不能用于预测单个岗位的未来。
早上好!以下为昨日摘要:
SOL - $109.12 PUMP - $0.0049 V2EX - $0.0025





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 50.48M | 5.05% | - | +0.21M |
| #9 | Meteora (V2EX-WSOL) Market | 5.02M | 0.50% | - | +4.25K |
| #14 | Livid | 3.65M | 0.36% | - | +4.30K |
| #15 | 24Kh...64qz | 3.27M | 0.33% | - | +10 |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。

看到一段无法阅读的加密文本,人很容易把它当成“安全的乱码”。但在大模型 API 里,这类不透明数据可能保存着模型的隐藏推理、工具返回值,甚至用户输入过的敏感信息。
2026 年 8 月提交的论文《Stealing Reasoning Traces from Proprietary LLM APIs》提出了一个反直觉的风险:研究者没有暴力破解密钥,也没有直接攻破防护最严的前沿模型,而是利用加密推理块可以跨会话、跨用户和跨模型复用的特性,把它交给同一家服务商中防护较弱的兼容模型处理。
本文由《听懂 AI》第 003 期整理而成。事实来源是 Alexander Panfilov 等 8 位作者于 2026 年 8 月 10 日提交的 arXiv 预印本及作者项目页。论文测试的是 2026 年 7 月初可用的特定 API 和模型版本,不能直接代表今天所有接口仍然存在相同行为。
推理模型在给出最终回答前,会生成较长的中间推理。服务商通常不把完整推理以明文返回,而是向客户端提供摘要,以及一段签名或加密后的不透明数据。客户端保存这段数据,并在下一轮请求时原样传回,让模型延续之前的推理状态。
论文把这种数据描述为经过认证加密的封装。它既能防止用户直接阅读,也能检测内容是否被篡改,同时让服务端不必长期保存每次会话的完整推理。
需要注意,论文作者也明确说,各服务商没有公开完整的密码学实现。因此,文章中的具体结构和密钥使用方式来自研究者的实验观察与推断,不是服务商公开的协议承诺。
论文发现的关键在于兼容范围过大。一个推理块可能被拿到另一段会话、另一个用户,甚至同一服务商的另一个模型中继续使用。
攻击者可以先从能力强、拒绝训练更严格的模型获得一个加密推理块,再把它送给较弱但兼容的模型。后者本来就需要合法解开并处理这类数据,研究者再诱导它把处理到的内容输出出来。
整个过程不需要知道加密密钥,也没有修改密文。真正失守的是“这段加密数据只能在原来的用户、会话和模型里使用”这一安全边界。

示意图只说明安全边界和防御方向,不包含论文中的具体攻击提示或供应商实现细节。
第一类是模型蒸馏。竞争者可能批量提取强模型的隐藏推理,用来训练或模仿另一个模型,绕过服务商隐藏思维过程的初衷。
第二类是敏感数据泄露。开发者公开 Agent 会话、评测轨迹或 API 日志时,常常只清理肉眼可见的文本,却保留看似无害的不透明推理块。秘密可能仍藏在里面。
第三类是拒答背后的危险内容。模型最终可能正确拒绝一个恶意请求,但隐藏推理已经处理过更具体的信息。如果推理块可以被恢复,安全的最终回答并不代表整个执行过程都没有泄露。
第四类是不可见提示注入。恶意指令可以隐藏在不透明数据中,人工审查日志时看不见,后续接手同一轨迹的 Agent 却可能读取并执行。论文把它作为概念验证和长时任务污染风险来讨论。
研究者从 GitHub 和 Hugging Face 收集了 6,708 条公开 Agent 轨迹,重建了 315,320 个推理块。完整论文给出的统计包括:
论文摘要还用另一组分类口径概括为 367 项个人身份信息和 182 项凭据。不同数字对应不同分类、去重和数据范围,不能直接相加,也不能理解成同样数量的独立受害者。
研究样本来自公开轨迹,不是对整个互联网或所有生产系统的普查。论文也使用两阶段自动分类筛掉占位符和测试数据,但这仍是一项定向研究,不是完整的泄露率调查。
论文给出的一个典型风险是会话清理:用户要求 Agent 删除仓库中的秘密,模型在隐藏推理中重新读取并复述这些值;最终可见回答只说“已经清理”,但不透明推理块仍可能保留原值。
因此,只搜索最终回答里的 API_KEY 或密码格式并不够。共享原始 API 记录前,还需要删除 signature、thinkingSignature、encrypted_content 等不透明推理字段。字段名称会随供应商和 SDK 改变,不能依赖一份永远不变的黑名单。
如果含有此类数据的会话已经进入公开 Git 仓库,删除最新文件也不代表历史提交消失。应当检查 Git 历史、缓存、制品和数据集副本,并轮换可能已经暴露的凭据。
这篇论文是 2026 年 8 月 10 日提交的 v1 预印本。实验针对 2026 年 7 月初的 Anthropic、OpenAI 和 Google API 版本,服务商可以在不公告的情况下改变内部实现。
作者无法看到隐藏推理的真实明文,因此不能逐字证明每次提取都完全正确。他们主要用 API 报告的思考 token 数量与恢复文本的 token 数量做对照,并在 120 个 Codeforces 问题上观察到较强的一致性。这是提取可信度的证据,但不是完整的明文真值验证。
论文还说明,团队在发表前已向相关模型服务商、Microsoft 和 Hugging Face 负责任披露。作者报告说,各服务商确认收到报告,此后他们已经无法用相同方法继续发动攻击。这说明供应商可能采取了缓解措施,但不能据此推断所有历史数据已经安全,也不能证明所有相邻攻击面永久消失。
论文建议服务商使用多层防御:
更严格的上下文绑定会影响合法的会话压缩、历史编辑和模型切换,因此不是简单增加一个字段就能完成。即使绑定正确,只要某个模型必须解开并处理旧推理,模型级提示攻击仍可能成为风险,所以需要纵深防御。
开发者现在可以做这些事:
密文不是废数据,也不是天然安全的秘密存储。看不懂一段内容,只说明人无法直接阅读,并不代表系统中的其他组件也无法处理它。

资料说明:本文的技术结论和数字均来自论文 v1。论文作者报告的攻击状态、供应商范围和缓解结果具有时间性,后续版本或服务商更新可能改变结论。

一个 AI Agent 真正运行起来以后,并不是每一步都需要最强模型。制定计划、处理复杂异常,可能值得调用能力最强的模型;执行工具、检查返回值、整理格式和重复查询,往往更在意速度和成本。
如果所有步骤都交给同一个昂贵模型,效果容易预测,账单和延迟却会迅速增加。反过来,如果只用便宜模型,复杂任务又可能失败。模型路由想解决的,就是如何在这两种选择之间分工。
本文由《听懂 AI》第 002 期整理而成。节目讨论的主要来源是 NVIDIA 于 2026 年 8 月 11 日发布的 Nemotron 3.5 Lightning 与 NeMo Switchyard 资料,并加入了对项目成熟度、评测边界和 Hacker News 社区争议的核对。
传统聊天产品通常把一次请求交给一个固定模型。Agent 的情况不同:它可能先规划,再调用工具,读取结果,修正计划,最后生成答案。一次任务里会出现很多性质不同的步骤。
NVIDIA 把这种架构称为“模型系统”:前沿推理模型负责规划和编排,小而快的模型承担代码检查、工具调用、安全告警监控和账单查询等高频工作。这个思路并不要求小模型取代大模型,而是让每种模型做自己更合适的事。
Nemotron 3.5 Lightning 是一个 300 亿参数的混合专家模型(MoE),但每个 token 只激活约 30 亿参数。可以把它理解成一个拥有多个专家小组的组织:总知识容量仍然较大,每次任务只叫少数专家参与,因此单次计算量接近更小的稠密模型。
NVIDIA 的技术文章称,它针对长期运行 Agent 的高频执行层设计,并使用多 token 预测、推测解码和量化等手段提高吞吐量。官方公布的结果包括:
这些都是 NVIDIA 选择的测试条件和对照模型,适合用来理解产品定位,不能直接换算成任何业务的固定收益。真实效果仍取决于任务分布、推理框架、硬件、并发量和输出长度。
NeMo Switchyard 是一个用 Rust 编写的代理和路由库。它能在不同模型与供应商之间分配请求,也负责 OpenAI Chat、OpenAI Responses 和 Anthropic Messages 等接口格式之间的转换。
仓库目前提供多种路由方式:

这张图表示一般性的模型路由结构,不代表 Switchyard 会自动识别所有任务,也不表示三类模型一定同时存在。
路由器本身也会消耗资源。真实总成本不仅包括最终模型调用,还包括路由判断、额外分类模型、缓存补齐、失败重试和升级调用。若没有统一的质量门禁,所谓“节省成本”可能只是把错误推迟到后面。
NVIDIA 公布的内部基准称,Switchyard 在保持前沿级准确率的同时,可把任务完成成本降到单独使用 Opus 4.8 的近三分之一。合作方数据中还有两组很醒目:
这些结果说明模型路由有潜力,但它们来自 NVIDIA 及合作方披露,并不是对所有任务的独立保证。尤其要注意 LangChain 的结果并非“质量完全不变”,而是用 6% 的准确率差异换取明显的成本下降。
评估路由器时,至少要同时看四项指标:正确率、端到端延迟、完整任务成本和失败后的恢复成本。只比较单个 token 价格,往往会漏掉路由判断和重试。
Hacker News 讨论中,争议最大的问题之一是提示缓存。批评者认为,同一会话不断切换模型,会让已经积累的 KV Cache 失效,抵消便宜模型省下的成本。
社区里也有人给出另一种解释:每个模型可以维护自己的缓存;重新切回某个模型时,只需要为它补上缺失的对话增量,而不是每次从头处理全部上下文。这样做仍然需要额外 prefill,而且缓存不能在结构不同的模型间直接共享,但较便宜模型承担更多生成工作后,整体仍可能节省费用。
这段讨论不能当作 Switchyard 的官方缓存承诺。它更像一个提醒:模型池大小、会话黏性、缓存策略和路由频率必须一起设计。模型选得越多,路由器越复杂,未必越划算。
截至 2026 年 8 月 28 日,Switchyard 仓库仍把整个项目标为 pre-alpha,并提醒 API 和算法在 1.0 之前可能大幅变化。各组件的成熟度也不同:libsy 标为 Beta、可试验性集成;客户端和 runner 仍是 Alpha;switchyard-server 是演示服务器,明确不建议用于生产环境。
这与新闻稿中的“部署”“企业使用”并不完全矛盾:合作方可能使用的是内部集成、特定组件或受控试验,并不等于公开仓库中的演示服务器已经具备生产条件。对普通开发团队来说,更合理的起点是离线评测或旁路实验,而不是立刻替换线上网关。
如果要验证模型路由,可以从一个很小的模型池开始:一个擅长复杂规划的模型,一个便宜快速的执行模型,再加明确的升级条件。
建议先完成下面几件事:
好的路由器不会一味选择最便宜的模型。它应当使用可验证的规则,把昂贵能力留给确实需要它的步骤。

资料说明:性能和合作方数据主要来自 NVIDIA 官方材料,本文已保留测试主体、对照对象与准确率差异。关于缓存的内容来自社区讨论,只作为工程问题线索,不作为 Switchyard 的官方保证。

第一次和大语言模型聊天,很容易产生一种错觉:屏幕另一端像是坐着一个读过无数书、什么都能聊的人。它能续写邮件,能解释概念,也能顺着语气安慰你。可一旦追问一个冷门事实,它又可能用同样笃定的口吻编出不存在的人名、论文和日期。
这两种表现并不矛盾。要理解它,先放下“电子大脑”这个比喻,把它想成一位特别擅长接话、但不会自动查证的咖啡馆店员。
本文由《听懂 AI》第 001 期访谈整理而成。该期节目从科普主题出发,并非改写某一篇原文;文末补充了 Transformer、GPT-3、语言理解争议和真实性评测的原始论文。
假设你说:“今晚下雨,出门记得带……”
人很容易想到“伞”。语言模型做的事情与此有一点相似,但规模大得多:它先把输入切成一组 token,再结合前面的上下文,为下一个 token 计算概率。选出一个之后,它把这个 token 加回上下文,继续预测下一个,直到回答结束。
token 不一定等于一个完整汉字或单词。它只是模型处理文字时使用的基本单位;具体怎样切分,取决于模型采用的分词方法。

图中的候选词和概率只是工作原理示意,不是某个真实模型的测量结果。
2017 年的论文 Attention Is All You Need 提出了 Transformer 架构。它通过注意力机制处理序列中不同位置之间的关系,后来成为大语言模型的重要技术基础。2020 年的 Language Models are Few-Shot Learners 则展示了 GPT-3 这类自回归语言模型在扩大参数和训练数据规模后,可以仅凭文字指令或少量示例完成多种任务。
所以,“预测下一个 token”听起来很朴素,却不代表模型只能做简单的句子补全。模型从大量训练文本中学到语法、文体、概念之间的关联,以及常见的推理表达方式。当这些规律共同参与一次预测时,结果就可能表现为写作、问答、翻译或代码生成。
另一个常见误解是:模型先把互联网背下来,回答时再从某个数据库里找到对应段落。
训练确实可能让模型记住部分内容,尤其是重复出现或具有独特表达的文本。但通常情况下,训练材料中的语言规律会被编码进大量参数。生成回答时,模型根据参数和当前上下文计算后续内容,不是在资料库中逐条检索。
这里需要区分基础语言模型和完整的 AI 产品。一个产品可以在模型外部接入搜索引擎、知识库、计算器或其他工具。此时你看到的答案可能同时包含模型生成和外部检索结果,但检索能力不是“预测下一个 token”天然附带的事实核验机制。
模型能正确处理“下雨”和“带伞”的关系,是否就说明它理解雨是什么?
这个问题没有一句公认的结论。Emily M. Bender 和 Alexander Koller 在 2020 年的论文 Climbing towards NLU 中强调,学习语言形式与获得由现实经验支撑的意义不是一回事。模型可以熟练处理词语之间的关系,却没有淋雨、撑伞或被冷风吹过的身体经验。
另一方面,只用“随机鹦鹉”也不足以描述今天模型表现出来的全部能力。它确实掌握了强大的语言模式处理能力,但不能据此直接推断它拥有人的意识、感受或理解方式。
模型的基本目标是生成在当前上下文中看起来合适的后续,而不是保证每句话都经过外部证据核对。如果问题含糊、训练材料不足,或者错误说法在语料中很常见,它仍可能生成连贯但不真实的答案。
2021 年的 TruthfulQA 用 817 个问题测试模型是否会复述人类常见的错误观念。在当时接受评测的模型中,最佳结果有 58% 的回答被判定为真实,而人类基线为 94%。这组数字不能代表今天任何具体产品的水平,但它说明了一个长期存在的问题:语言流畅度和事实真实性不是同一个指标。
因此,遇到下面这些内容,不要因为语气自信就直接采用:
把语言模型当成一个反应很快、知识面很广、但偶尔会硬撑的助理,通常比把它当成权威更合适。
适合交给它的工作包括改写文字、整理材料、列出备选方案、模拟提问和解释概念。涉及重要事实时,可以要求它区分“已知事实”“推测”和“不确定项”,列出可核验的来源,再由人打开原始资料确认。
提问也不需要背诵所谓的“提示词咒语”。说明读者是谁、想解决什么问题、有哪些限制,再给一个例子,往往就能明显改善结果。与此同时,不要随手提交身份证号、病历、公司机密或未公开代码;能否输入某类数据,应以所在组织的制度和所用产品的数据政策为准。
使用时记住:它很会生成答案,但“很像答案”不等于“答案是真的”。

资料说明:节目第 001 期原始 sources.json 只记录了“向不懂技术的人解释大语言模型”这一主题,没有外部 URL。以上论文由本文编辑阶段补充,用于说明相关技术背景和争议,不代表节目逐句改写这些论文。
早上好!以下为昨日摘要:
SOL - $101.98 PUMP - $0.0049 V2EX - $0.0024





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 50.27M | 5.03% | - | +0.30M |
| #9 | Meteora (V2EX-WSOL) Market | 5.02M | 0.50% | - | +22.0118 |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
前几周,agent 工具链在问"能不能跑";上周,我们看到有人在问"谁替我盯着它"。 这一周,有人开始问另一件事:agent 那么多决策,都存哪了?
不是又一个 agent runtime, 是一个叫 deja-vu 的东西,追溯你过去八个月在任何一个 coding agent 里做过的所有决策, 把它们拼成一张可以搜索的本地索引; 不是又一个 AI 助手管理面板, 是一个叫 skills-manager 的东西,把分散在 52 个工具里的 prompt 文件 统一放进一个有版本、有预设、可以一键同步的仓库; 不是又一个聊天框, 是一个把"哪些消息会被发给模型"这件事 变成一张可以用鼠标剪线的有向图。
agent 的工作状态上周有人在盯,这一周有人开始问:它做过的那些决策,能不能找回来。
| 名称 | 中文说明 |
|---|---|
| deja-vu | 跨 20+ coding agent 的会话历史本地索引与搜索工具 |
| fx-agent | 可嵌入、轻量的原生 coding agent(单二进制) |
| gffcompare | GFF/GTF 转录本文件比较、合并与注释工具 |
| leaves | 文本模式磁盘用量可视化工具 |
| [email protected] | MySQL 9.7 客户端工具集 |
| [email protected] | MySQL 9.7 开源关系型数据库 |
| obscura | 为 AI agent 和网页抓取设计的 headless 浏览器 |
| pythia | 蒙特卡洛事件生成器 |
| robotcode | Robot Framework 完整工具集 |
| xeve | 极速视频编码器,支持 MPEG-5 EVC(Essential Video Coding) |
| 名称 | 中文说明 |
|---|---|
| amethyst-nostr | Nostr 去中心化社交客户端 |
| anarlog | AI 会议记录与笔记本 |
| android-performance-analyzer | Android 应用和游戏性能分析工具链 |
| atlas-app | 为 coding agent 设计的源代码控制桌面应用 |
| bifrost | 三星固件下载工具 |
| bramble | 密码管理器 |
| channel-works | 客户支持、分析与营销一体化 AI Business OS |
| font-paper-mono | Paper Mono 字体 |
| keychron-assistant | Keychron Launcher 配套工具,快速启动辅助 |
| leigod | 游戏网络加速器 |
| motrix@beta | 开源下载管理器(测试版) |
| nativ | 本地运行 AI 模型的桌面应用 |
| riverscript | 录制并转录系统音频的 AI 平台 |
| skills-manager | 跨 52 个 coding 工具统一管理、同步 AI agent skills 文件 |
| thoughtdag | LLM 上下文图的可视化与可编辑工作台 |
| triggerflo | 专注计时器 + 看板,任务追踪一体 |
这一节不求全,只挑三个值得停下来看的点。
Claude Code 在压缩对话时会保留摘要,但根据 deja-vu README 里的一个数字:43 次压缩下来,摘要保住了约 77% 的决策,却只保住了 0.2% 的命令。那些被丢弃的"当时用的是这个参数"、"上次这样做是因为……"——deja-vu 在安装之前就已经替你追溯索引好了。
它的设计路线有一个不常见的地方:不需要 LLM,只用词法倒排索引。1551 个 session,中位数查询耗时 0.4ms。它不试图理解你做过什么,只是让你找得到。
更奇的是"跨 agent"。Claude Code 里解决过的一个 bug,在 Cursor 新开 session 时,deja-vu 的 MCP hook 会在会话开始前把相关历史送进去。这不是"AI 记忆",更接近一个开发者自己的版本控制——只是版本控制的对象变成了"过去做过的决定"。
如果你用了不止一个 coding 工具,你大概有过这样的经历:在 Claude Code 里写好了一份 prompt 文件,换到 Cursor 发现要重新放一遍,换到 Copilot 又要一次。skills-manager 做的事很具体——把这些分散的 markdown 文件统一放进一个仓库,然后一键同步到你选择的任意工具。
它支持的工具列表现在是 52 个,包括 Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI、Windsurf 等。每张 skill 卡会显示当前在哪些 agent 里是"已同步"状态,哪些还没有。
这件事之所以值得关注,不只是因为功能本身——而是因为它的存在说明,prompt 文件这个东西,现在多到开始需要被管理了。几年前,"prompt engineering"还是一件你随手写随手丢的事。现在它开始有了仓库、版本、预设和跨设备同步。工具生态成熟有一个标志,就是出现"包管理器"。
┌─────────────────────────────────────────────────────────────┐
│ ThoughtDAG — LLM Context Graph │
├─────────────────────────────────────────────────────────────┤
│ │
│ [Document A] ──────────────────────▶ [Question] │
│ │
│ [Code snippet] ── (pruned) ──────▶ ✗ │
│ │
│ [Research note] ───────────────────▶ [Question] │
│ │
│ "wires are context" — 剪一条线,这个节点的内容 │
│ 就不会出现在下一次请求里。 │
│ │
│ 当前 token 预计:2,341 (-47 if cut) │
└─────────────────────────────────────────────────────────────┘
标准聊天界面里,你不知道"这条消息会不会被发给模型"——超出窗口的会被截掉,但截掉哪些是隐形的。ThoughtDAG 把这件事翻出来了:每一条历史消息是一个节点,连线决定它会不会出现在下一次请求里。你可以在发送前剪掉一根线,把某个节点从 context 里排除,然后预览 token 数变化。
他们做了一个实验:162 个"聊天走偏"的案例,用"删掉整个污染子图"的方式全部修复,而"只删污染来源"只修复了 152 个。这说明上下文污染经常是沿着节点传播的——剪线的地方不只是"坏节点",而是"连接坏节点和好节点的那根线"。
这个工具目前是小众的,但它回答的问题不小:如果 context window 是你和模型合作的工作台,那这个工作台应该长什么样? 一个线性的聊天框,还是一张可以手动布线的图?
deja-vu 有一个细节让我觉得它想得很清楚:它特意强调"不是从安装那天开始记录,而是追溯历史"。这个选择说明它的作者理解用户的真实处境——你不会在第一天就开始用记忆工具,那时候没有什么可以记;你会在某天发现"我之前解决过这个问题"的时候,才意识到需要它。等你意识到需要它,历史已经积累了很多了。
skills-manager 支持 52 个工具这个数字有点荒诞——说明 coding 工具领域的碎片化已经严重到需要一个专门工具来整合 prompt 文件了。这是好消息也是坏消息。好消息是 agent 工具链在成熟,坏消息是它成熟得太分散。
thoughtdag 我可能不会日常使用,但它是那种会改变你对某个概念理解的工具。用过一次之后,你会开始想"我和 Claude 的这段对话,如果是一张图,现在是什么形状"——即使你不再打开这个应用,这个问题本身已经在你那里留下了。
atlas-app 进了 Cask 但我没有展开写它——它和 deja-vu 想解决的问题有重叠,但 atlas 更重(桌面应用),deja-vu 更轻(单 Go binary + MCP hook)。两个工具同时进 Homebrew 这件事本身倒是有意思:agent 的记忆问题,现在至少有三种不同的答法了。
deja-vu 在文档里写了一个比喻,大意是:coding agent 的 session 历史就像日记,但没有人读日记,除非他们想找一件之前发生过的事。
它没有说错。日记不是给每天看的,是给"我记得我做过这件事,但忘了细节"的那个时刻准备的。
现在 agent 工具链有了日记——一个本地的、可搜索的、不需要任何云端服务的日记。你在任何一个 agent 里做过的决定,可以在另一个 agent 开始工作之前被它读到。
这一步走完,agent 就不只是"能干活"了,它开始有了一些连续性。
IPFS 会是解决这个问题的方案吗?
https://x.com/RohanKarMooN/status/2092455283490783629
2026 年的当下,或许只用一天时间就可以把基于 IPFS 的文件夹分享方案做出来,但是是否有更多用户愿意持续用下去就是另外一个和代码生成速度无关的问题了。
早上好!以下为昨日摘要:
SOL - $96.59 PUMP - $0.0045 V2EX - $0.0023





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 49.97M | 5.00% | - | +1.01M |
| #9 | Meteora (V2EX-WSOL) Market | 5.02M | 0.50% | - | +8.22K |
| #14 | Livid | 3.64M | 0.36% | - | +4.13K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $98.91 PUMP - $0.0047 V2EX - $0.0024





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.96M | 4.90% | - | +0.38M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +1.31K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $95.15 PUMP - $0.0052 V2EX - $0.0023





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.58M | 4.86% | - | +0.40M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +2.67K |
| #37 | HEz4...Qfbm | 0.99M | 0.10% | - | -7.65K |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
早上好!以下为昨日摘要:
SOL - $93.88 PUMP - $0.0050 V2EX - $0.0023





| 排名 | 地址 | 持有数量 | 持仓比例 | 排名变化 | 数量变化 |
|---|---|---|---|---|---|
| #2 | Pump.fun AMM (V2EX-WSOL) Pool | 48.18M | 4.82% | - | +0.28M |
| #9 | Meteora (V2EX-WSOL) Market | 5.01M | 0.50% | - | +122.76 |
TG 机器人订阅: 点我订阅
原始图表与数据存放于: 点我查看
此报告由 V2EX Info 提供数据, 由 Newsletter Report Bot 自动生成。
此报告仅供参考,不构成任何投资建议。投资有风险,入市需谨慎。
