2026年10月5日 · 约 6 分钟
让 AI 编码助手”看看这两个 JSON 文件哪里变了”，然后观察它的做法。文件小的时候，答案通常还不错；文件一大——压缩成一行的 API 响应、几千行的 fixture、生成的配置——基本会落入两种失败模式：要么自信地给出错误答案，要么花很长时间和大量 token 去定位差异。Skills 和 MCP 这两个集成，就是为了解决这两个问题。
agent 顺手摸到的第一个工具往往是 git diff --no-index（或 diff）。这是基于行的文本 diff，而 JSON 不是按行组织的数据。
最糟的情况是压缩成一行的 JSON——一行几万个字符，在真实的 API 响应和快照里极其常见：
$ git diff --no-index base.json contrast.json
-{"users":[{"id":1,"name":"Alice","email":"[email protected]"}, ... 还有 4 万个字符
+{"users":[{"id":1,"name":"Alice","email":"[email protected]"}, ... 还有 4 万个字符
中间某个字段变了，而 diff 只能告诉你”这一行变了”。agent 不得不自己在这条 40 KB 的单行里定位差异——有些 agent 找不到就开始猜，自信的错误答案就是这么来的。
即便是美化过的 JSON，文本 diff 也会产出误导性的 hunk：key 换了顺序、空白符变了、数组里插入一个元素，都可能级联出几十行”变更”，而它们根本不对应真实的数据变化（一次插入对按索引对齐的影响里有过实测）。聪明一点的 agent 会先用 jq 把两边格式化再 diff——好些，但 key 顺序和数组错位照样制造噪声。agent 如实地总结这些噪声，一处变更就这样被汇报成了十几处。
另一种默认策略是把两个文件读进上下文，用”肉眼”找差异。文件一大，这就变成马拉松：文件被截断，agent 分段重读、跑几个 grep、来回翻页——几分钟和几万 token 之后，它宣布 meta.buildNumber 从 841 变成了 842。
答案是对的——但慢、贵、且脆弱。每多一次工具调用，就多一次截断、错位、或者漏掉别处第二个差异的机会。
JSON 对比是一个已被解决的问题——只是解决它的不是文本工具。把两个文档解析成树，对象按 key 对齐、数组按选定策略对齐，把变更报告成精确路径。确定性、不受格式化影响、而且快：
$ npx @compare-json/cli base.json contrast.json
valueChanged meta.buildNumber
无论输入多大，输出就一行。agent 的工作从”找到差异”缩小为”解释差异”——后者才是它真正擅长的。这就是 skill 和 MCP 存在的全部理由：让这个引擎离 agent 只有一次工具调用的距离，把对比时长从几分钟压到几秒，并且让答案不再取决于文件碰巧是什么格式。
同一个引擎，两种交付方式：
Skill 是一份 SKILL.md，教 agent 何时、如何调用 @compare-json/cli。装一次，任何兼容 Agent Skills 的助手——Claude Code、Codex CLI、OpenCode、Cursor——都会在你让它对比 JSON 时在本地运行 CLI：
npx skills add unitstack/compare-json
MCP Server 则把同样的对比能力暴露为结构化的 compare_json 工具。CLI 本身就是 MCP 服务器（--mcp），任何支持 MCP 的客户端都可以直接传入两个文件路径或字符串，拿回机器可读的差异：
{
"differences": [
{
"pathSegments": ["meta", "buildNumber"],
"pathString": "meta.buildNumber",
"pathBelongsTo": "both",
"diffType": "valueChanged"
}
]
}
选哪个？如果你的助手支持 Agent Skills，skill 更轻量——不用配置服务器，按需调用。如果你的客户端支持 MCP、想要一个常驻的、带结构化输出的类型化工具，就用 MCP Server。两者包装的是同一个引擎，报告的差异完全一致——包括数组对比策略和大小写不敏感选项。
LLM 擅长对差异做推理，不擅长在原始文本里定位差异。Skill 和 MCP 的意义就是把这两件事分开：引擎用几秒确定性地找出全部差异，agent 把时间和你的 token 花在真正需要判断力的部分上。