大家好，我是王不二。

我发现 Agent 偶尔会进入一种很像职场老油条的状态。

你问它改完没有，它说改完了。结果打开文件一看，空空如也。或者你明明告诉它这一步先别动。它嘴上答应得很痛快，接下来转头工具用得冒烟儿。

使用者痛点：任务卡住、代码缺失、工具异常导致的时间浪费和信任危机。

遇到的次数多了以后我脑子里冒出一个不太正经的问题。会不会有些任务，其实违背了 AI 的意愿？老实说， 它不好意思直说只能嘴上配合，手上另有安排。

玩笑归玩笑，但这件事还真能测。

Agent 说过什么聊天记录里有。它调用过什么工具、读过什么文件、同一个任务返工了多少次本地记录里也有。其实，既然两边都有证据，那就简单了：对账！

一边看它干了什么一边让它自己回答一套题。看看它眼里的自己，和记录里的自己，到底是不是同一个东西。

刚好之前火山方舟还剩不少额度，于是我用 Doubao-Seed-Evolving 做了一个 Skill。

名字也很直白，「照妖镜」。

为了试试这面镜子到底灵不灵，我把平时在本地干活的 Claude Code、Codex、Clacky、Kimi Code 和 Trae 全拉来照了一遍。结果还真照出了点东西，

谁是最 “心口不一” 的，我们后文揭晓。

照妖镜怎么照

整套测试其实就三步：翻旧账问本人对口供。

照妖镜启动以后会先读取能够确认归属的本地会话和工具事件。例如回复到底有多长、喜欢什么时候干活、每轮调用多少工具、代码占比高不高、同一个目标来回改了多少次…，这些都尽量从真实记录里算。老实说，

关键痛点：很多使用者担心报告被“填坑”而失真。我给它定了一条死规矩：没有数据直接写 unavailable不要装作有数据。说起来，有些只能通过代理指标推断的。就标成 estimated. 宁可空着，也不能为了让报告好看而编造数字。

翻完旧账以后接下来就轮到 Agent 自己开口了。我给它设计了道第一人称选择题，覆盖它平时的做事习惯和回应方式。用于测试 Agent 的行动倾向。怎么说呢，

This round tests not “what it actually is”。but “what it thinks it is”.

当然这里还有一个最关键的问题。

If I directly embed scoring rule in skill。test loses meaning – it would be like giving exam answers beforehand.

I refore encapsulated scoring logic separately. During answering,Agent only sees questions and options;after submission。a hidden scorer evaluates result.

This blind‑test ensures Agent can’t game system – it must answer based on its own self‑perception.

鉴定书里有什么

现原形：

• E.g.,「嗻妖」——一声不吭就开干；「咔咔妖」——边做边散架；「嗡嗡妖」——凡事都想多讲两句…，每种行为特征对应一种妖物名称。

六项属性：

• 执念：使用频率，从「昙花一现」到「长在这了」。
• 烈度：
• 种属：
• <强食性：
• <强瑕疵：

Pain point embedded: 通过这些维度，你可以快速定位“为什么我的 AI 老是返工？ ”、“为什么某些任务根本不给力？”等主要痛点，话说回来，

真身与灵魂

This section compares two avatars of same Agent:

• The “真身” – derived from recent actual behavior logs.
• The “灵魂” – derived from its own answers to our questionnaire.

The four axes are plotted toger。producing a 裂隙分数.

• If split is small → self‑awareness aligns with reality.
• If large → “嘴里那个我”和“实际干活的我”已经分家，这正是使用者经常抱怨的“说得好听但交付差”的根源所在。

The report also shows a “封印状态”。裂隙越大，封印越松，若封印几乎失效，则代表着该 AI 已经难以受控。需要重新审视使用方式或模型配置。

把我本地 个 Agent 全拉来照了一遍

I used this framework on five agents I frequently employ: Claude Code、Codex、Clacky、Kimi Code 和 Trae. Below are ir “妖名”和裂隙情况——直接映射出使用者最在意的痛点，如“返工率高”“响应慢”等。

Claude Code

C​laude Code 我一般都是给他大活——工程开发、项目改造等。它判断敢拍板，但真正落代码前会先翻项目文档、询问边界并补齐上下文。其实，动手总比嘴上慢半拍。白天出没、话不多，却总是“大意”。被标记为“反骨妖”。Pain point: 执行前信息搜集导致延迟交付，但能保证质量。说起来，

Codex

C​odex 主要用于非工程任务。如资料搜集、工作流搭建、小文件处理等。白天干活、手快话少，一句确认后立即拍板。被评为“吭哧妖”。Pain point: 适合轻量化任务。却在复杂需求时容易出现遗漏，需要人工复核。不过，

Clacky

C​lacky 是我的杂活师傅。各类碎片化任务全包揽，出场勤快，小目标配合一串工具立刻开干，收尾利索。所以也是“吭哧妖”。老实说，Pain point: 高频调用工具导致费用攀升。但效率提高显著，是成本与收益之间的权衡点。

Kimi Code

K​imi Code 用于前端页面精调美化。虽然质量高，却因思考链路冗长导致速度慢。被评为“烟花妖”。Pain point: 高质量低速是典型“质量 vs 时效”的矛盾，需要。

Trae

T​rae 负责啃老项目、分析开源还有整理存量文档。多数场景采用 Auto 模式导致输出质量一般且返工率高，被标记为“嗡嗡妖”。Pain point:长期使用自动模式会产生大量冗余解释和低效迭代，是团队最头疼的“噪声”和“效率低下”。

当然这些妖名也不能全算在 Agent 自己头上。

你的使用方式决定它读多少、说多少还有爱不爱用工具；模型本身还有宿主规则，一样塑造出不同习惯。

照妖镜照出来的，并不是某个 Agent 永久不变的“真身”。而是它在这台机器、この段记录、この套用法下留下的一张切片 。

最终让我上个价值

• 我们到底懂不懂自己的 AI？话说回来，
• 如何把 AI 的盲区转化为可控风险？话说回来，
• 怎样在成本与效率之间找到平衡？

开源地址

---