核心结论： Pi Agent 内置终端图片显示，在兼容终端中默认开启，无需安装扩展。
那天我像往常一样打开 cmux 里的 Pi Agent 会话,屏幕上出现了一张图片。
不是文件路径,也不是"图片已保存到本地"的文字占位符——而是一张真正嵌在终端会话里的图片。过去我一直把终端当成纯文本界面,没想到现在连图片都能直接渲染在对话里。
我不是第一次用 Pi,却是第一次看到这张图
我并不是冲着这个功能去用 Pi 的。7 月初 Claude 账号被封,我才被迫重新尝试各种 Agent 工具,Pi 是其中之一。
那时候我就让它读取过截图。我记得很清楚,会话里并不会直接出现图片。直到这几天,我更新版本后再次使用,一张真实的截图突然显示在终端里,我才注意到这个内置功能已经在当前环境里生效。
(图示: 当时第一次看到终端图片渲染的截图)
后来一查才发现,这不是额外安装的扩展。Pi 的官方设置把终端图片显示列为默认开启的内置能力；终端支持相应图形协议时直接显示图片,不支持时退化为文字占位符。Kitty、Ghostty、WezTerm 使用 Kitty 图形协议,iTerm2 使用自己的内联图片协议；需要关闭时,可以把 terminal.showImages 设为 false。
于是我就很好奇, Pi 并没有独占更强的模型,甚至它本身就不是模型。那为什么 Codex CLI、Claude Code 这些更主流的工具,反而没有这个看起来很自然的功能?
主流 CLI 为什么没有默认这样做
在我目前使用的 Codex CLI 和 Claude Code 中,图片可以作为输入交给模型分析,但不会像 Pi 一样直接显示在终端会话里。
把一张图显示出来并不难,难的是别让它添乱。窗口大小变了不能错位,往上翻不能留下残影,换个终端也不能突然失效。一个看起来很小的功能,做得不稳还不如不做。
Codex 团队也公开说过,他们试过更彻底地接管终端界面,但滚动、选择和复制在不同环境里反而变得更难用,最后没有把它设为默认。这让我意识到,这些主流工具不是不知道更丰富的界面更好看,而是更怕破坏用户每天都在用的基本体验。
Claude Code 同样要运行在不同系统、终端和远程环境里。但我没有找到 Anthropic 对“不显示终端内联图片”的官方解释,所以兼容性和维护成本只能算可能的工程背景,不能当成它的产品结论。
能确认的只有结果
截至 2026 年 7 月 31 日,能确认的是,Pi 会在支持的终端里直接显示图片,不支持就继续显示文字；在我使用的 Codex CLI 和 Claude Code 环境中,图片没有默认内联显示。
至于三个团队为什么做出不同选择,公开资料里没有直接答案。说 Pi 更愿意照顾一部分人的体验,或者说主流工具更看重稳定,都只是我的推测。我能看到的是功能上的差别,但不能替他们解释动机。
我最后没有找到那个答案
我原本想弄明白,Codex 和 Claude Code 为什么不显示图片。查了一圈之后,我只能确认它们现在没有这样做,却找不到三个团队对这个选择的完整解释。再继续往下说,就只能靠猜了。
但这次意外还是改变了我对 Pi 的看法。7 月初,我是因为 Claude 账号被封,才把它当成替代品打开。那时我默认它只是一个更小、能力更弱的工具。直到这张图片直接出现在终端里,我才发现小工具也可能在某个具体体验上,走在主流工具前面。
这张图不能证明 Pi 比 Codex、Claude Code 更强,只能证明工具没有一张从上到下固定不变的排行榜。名气更大、模型更强,不代表每个细节都更好。到底哪一个更适合自己,还是得真正用过才知道。
一个月前,我是因为用不了 Claude 才打开 Pi。一个月后,我开始因为 Pi 本身留下它。