最近中文技术社区里冒出一个很火的论题“JSON 在 AI 时代正走向消亡”。做后端的人看到这句话容易坐不住毕竟手上的接口还在用 JSON 和前端联调搞 AI 的人倒是频频点头因为他们在微调、训练、Agent 调用里已经踩过太多 JSON 的坑。这个标题确实有点标题党的味道但背后的问题是真真切切的AI 时代的数据交换方式到底还在多大程度上依赖 JSONJSON 会不会被某种新格式取代我自己的看法是JSON 不会这么快“死”但它的角色正在发生剧烈的迁移。以前它是数据交换的绝对中心现在它退到了三层位置——AI 内部计算不吃 JSONAI 训练数据不用 JSONAgent 之间的信息传递也开始绕开 JSON。但与此同时JSON 在另一些地方反而更牢固了比如大模型的 Function Calling 结构化输出、RAG 知识库的元数据管理、AI 工具的配置体系。这篇文章我想把这个话题拆开揉碎结合我这两年做 AI 应用开发的实际经验聊聊 JSON 在 AI 时代究竟遭遇了什么哪些地方它真的不行了哪些地方它依然是刚需以及我们这些做工程的到底该怎么选型。1. 这个标题是怎么来的——从“JSON 已死”到“JSON 还活着”1.1 论题的来源JSON 与现代 AI 格格不入的三个信号任何一个耸动的标题背后一定有真实痛点在支撑。“JSON 在 AI 时代正走向消亡”这个说法最早是从大模型应用开发者的吐槽里发酵出来的。第一批给 GPT 类模型写代码的人发现让模型输出一段严格合法的 JSON 是一件既费 token 又容易翻车的事。模型经常给你多一个逗号、少一个引号或者把一个字符串意外截断直接导致json.loads抛异常。如果你在大规模流水线里跑几百个结构化抽取任务你就会对“JSON parse error”产生生理厌恶。第二个信号来自模型推理的“注意力分布”。Transformer 架构对 token 的处理逻辑决定了它会花大量计算在结构符号上。一个包含大量引号、冒号、花括号的 JSON 文本在模型眼里就是大段的“结构性噪音”。同样一段业务信息写成 JSON 消耗的 token 往往是纯文本的两三倍。在按 token 计费、按上下文窗口算容量的时代这就是真金白银的成本浪费。第三个信号出现在模型训练阶段。现在大模型的训练数据主要来自网页、论文、代码仓库、对话记录几乎没有人会把海量 JSON 文档直接喂给模型做预训练。JSON 是为机器间通信设计的它的可读性远不如 Markdown、自然语言或者表格模型学习起来非常低效。所以你会发现ChatGPT 这类产品的接口文档里有 JSON Schema 定义但模型内部对“JSON 格式”的理解其实远没有对“自然语言指令”理解得深。1.2 先别急着唱衰JSON 在 AI 生态中的真实位置上面这些信号都是真实的但“消亡”这个词用得过于浪漫主义了。AI 应用不是凭空长出来的它长在互联网的根基上。而互联网过去二十年最成功的通用数据协议就是 JSON。你要让 AI Agent 去调用一个搜索 API、查一个天气接口、写一条数据库记录这些接口背后全是 JSON。除非我们把整个 Web 基础设施推倒重来否则 JSON 在可预见的未来都会是 AI 与外部世界打交道时的事实标准。我的判断是JSON 没有在消亡它是在“降权”。以前它是数据的唯一主角现在它更像是一个“边界协议”——只在系统边缘、工具调用、人机交互的接口处出现而数据在 AI 内部流转时已经被换成向量、token 序列、二进制张量这些更底层的表达。这个转变对后端工程师的冲击不小因为大家的思维还停留在“一切皆 JSON”的阶段但 AI 原生应用的设计者已经开始把 JSON 当作最外层的一层壳。2. JSON 和 AI 的相爱相杀为什么模型“看不上”JSON2.1 Token 浪费JSON 的结构化语法在模型眼里是“噪音”用生活里的例子来类比可能更直观。你去听一场讲座讲师讲了一个小时但真正有用的信息其实只有三句话。这三句话如果提炼出来可能就 50 个字但讲师为了组织表达用了大量连接词、铺垫、重复强调。JSON 的结构化语法在模型眼里就扮演了“废话连接词”的角色。比如{user_id: 123, user_name: 张三, user_age: 28}这段数据真正有价值的信息是“123、张三、28”这三个值而{user_id:,:,,这些东西对模型理解语义几乎没有任何帮助。在 Transformer 的注意力机制里这些符号虽然不是完全无用它们帮助模型定位字段边界但相比自然语言令牌它们携带的语义信息密度低很多。更麻烦的是大模型的 Tokenizer 通常会把:、等符号切分成独立的 token原本一个单词能表达的信息现在要拆成多个 token。我在实际项目里统计过同一份销售数据用 JSON 表达大约 1200 个 token用纯文本表格表达只要 600 个左右用自然语言描述只要 400 个。在批量处理场景下这是成倍的成本差异。2.2 解析地狱AI 生成 JSON 时的格式不稳定做过 AI 结构化抽取的人大概率遇到过“模型输出的 JSON 差一个引号”的玄学问题。你让模型按指定格式抽取合同里的关键字段它偏偏给你输出一段带解释性前缀的文本。你做了 few-shot 示例它却用错注释符号。你锁死了 JSON Schema结果它在花括号里嵌套了一段啰嗦的自白。这些问题的根源在于大模型本质上是“概率化的语言生成器”而不是“格式化的序列化器”。它生成“看起来像 JSON 的文本”而不是严格符合规范的 JSON 值。为了对付这种不确定性工程上出现了大量的 JSON 修复工具、容错解析库、重试策略。OpenAI 等厂商也推出了json_mode、结构化输出、Function Calling 等功能本质上不是让模型更懂 JSON而是把 JSON 生成过程变成了“受限解码”或“Schema 约束下的标记生成”。这相当于我们用外部规则强行纠正模型的自由主义输出倾向。虽然可靠度大幅提升了但这也说明了一个尴尬的事实JSON 格式对模型而言不是天然友好的母语而是需要“看着说明书手写”的外语。2.3 嵌套地狱复杂 JSON 让模型上下文窗口雪上加霜另一个容易被忽视的问题是嵌套复杂度。业务系统里那种五六层嵌套的 JSON交给人类后端开发者阅读都有压力更别提让模型在有限的上下文窗口里去理解并操作了。上下文窗口就像一个人的工作记忆你往里塞的无效结构越多模型能记住的有效业务信息就越少。为了让模型在长文档上保持高质量表现我现在做提示词工程时都会刻意把输入数据先“拍平”——把多层嵌套 JSON 转成扁平的表格、键值列表或者 JSONL 格式再喂给模型。举个例子一个包含订单、商品、物流、售后四层嵌套的 JSON 对象如果直接塞给模型分析它很容易在第三层就“失忆”。但如果你把它转成行式 JSONL每行一条完整记录或者拍平成多张关系表模型的处理质量会明显上升。这就逼着我们在 AI 工作流里做大量的 json转换和预处理而不是原样把混论结构丢给模型。3. 时代替代品AI 原生数据格式正在崛起既然 JSON 在 AI 内部场景有这么多的不适应那么替代品自然会出现。我这里说的“替代”不是指一夜之间替换而是在 AI 原生链路里越来越多的团队开始选用新的数据表达方式。3.1 JSONLAI 训练和日志领域新的事实标准JSONL 的全称是 JSON Lines说白了就是每一行一个完整的 JSON 对象。它看起来从 JSON 派生而来但在 AI 数据工程里它的地位已经完全独立于 JSON。大模型微调的数据集格式几乎清一色是 JSONL{instruction: ..., input: ..., output: ...}一行一个样本。RAG 向量库的元数据导入、海量日志的采集、批量流水线的输入输出也都在用 JSONL。为什么 JSONL 这么吃香因为它天然适配“逐行处理”的管道模式。你可以用for line in file一条条读取不必把整个文件加载到内存再整体解析。对于动辄几个 GB 的训练集这是最重要的工程优势。而且 JSONL 的每一行是独立的如果中间有一行数据坏了你只需要跳过这一行不会像解析一个大 JSON 文件那样“一损俱损”。在处理大规模数据时这种容错能力是非常现实的考量。3.2 向量存储与嵌入取代“结构”的不是新格式而是新常态AI 时代最深刻的变化其实是数据表达的根本性转移。以前我们关注“字段和类型”现在越来越关注“语义向量和相关性”。一篇文档、一段对话、一张图片在模型内部都会被转换成一串高维向量Embedding。这些向量代表的不是结构化的字段值而是语义空间里的坐标。搜索、推荐、问答全都变成向量之间的相似度计算。这意味着在很多 AI 应用里JSON 里的字段信息反而不重要了重要的是这个对象对应的向量。你在做语义检索时先通过向量召回一批候选结果再把它对应的原始文档很可能是一段文本不是 JSON拿回来交给大模型做分析。数据从“可解析的结构化对象”变成了“不可直接阅读的数值矩阵”。这是对 JSON 统治地位最釜底抽薪的打击。3.3 二进制时代回归Protocol Buffers、FlatBuffers 与 MessagePack如果说 JSONL 和向量改变了数据存储的方式那么序列化协议的变化则直接发生在数据交换的层面。我用过 JSON 做内部服务之间的通信最早图省事、调试方便后来流量上来后开始纠结 JSON 的序列化性能和体积。JSON 的文本格式天生就比二进制格式冗余。后来我换成 Protocol Buffers序列化后的体积只有 JSON 的五分之一左右解析速度提升了近一个量级。在 AI 推理服务里这种体积和性能差异更加致命。推理引擎需要在高并发下快速读写海量的中间数据、特征向量、模型输出。如果每一路调用都走 JSON带宽和 CPU 都会被无谓占用。因此你会看到很多 AI 推理框架的底层数据传输都采用了二进制协议JSON 仅仅保留在对外 HTTP 接口那一层。这也是“JSON 在 AI 时代走向消亡”论调的另一个现实支撑——在最内层、最核心的数据通路上JSON 已经边缘化了。3.4 YAML/TOML 的逆袭配置场景中的“人机友好”偏好还有一个有趣的趋势是在 AI 应用的配置管理里YAML 和 TOML 正在挤占 JSON 的位置。原因很简单人类写 prompt、配模型参数、定义 Agent 行为时需要更贴近自然语言的表达方式。JSON 的每个 key 都要加双引号、每个对象要写大括号在写复杂配置时非常痛苦。YAML 靠缩进表达层级写了就让人眼明心亮TOML 的[section]结构在管理扁平配置时格外清晰。比如我维护一个多 Agent 协作系统里面需要定义每个 Agent 的 system prompt、模型参数、工具列表、温度系数。早期用 JSON 写配置维护成本很高后来改成 YAML不仅可读性好并且可以直接在文件里写注释解释每个参数的含义。对 AI 工程师而言配置文件的“可编辑性”和“可读性”比“严格可序列化”更重要这是从前端 API 时代延续下来的思维惯性所不能理解的。4. JSON 从未离开AI 时代的三大不可替代场景看到这里你可能觉得 JSON 真的不行了。别急接下来我要说它的“护城河”。在 AI 应用中有三个场景不仅离不开 JSON反而因为 AI 的发展变得更加依赖它。4.1 结构化输出大模型 Function Calling 的接口协议Function Calling 是现在 AI Agent 的核心能力之一。模型理解用户的自然语言请求后决定要调用哪个工具、传入什么参数然后以结构化格式输出调用指令。而这个结构化格式目前的标准就是 JSON。比如模型决定查询天气它需要输出{function_name: get_weather, parameters: {city: 北京}}这样的结构才能被 Agent 框架解析并执行。OpenAI 的 API 文档里工具函数的参数定义用的是 JSON Schema模型返回的也是 JSON 格式的函数调用参数。Anthropic 的 tool use 机制大同小异Google Gemini 的 function declaration 同样依赖 JSON Schema。这说明什么说明在未来相当长的时间里AI 与外部工具之间的“接口层”始终要有一种稳定的、类型明确的、机器可读的格式而 JSON 是目前综合成本最低的选择。你可以说这不是 JSON 的胜利而是 JSON 的“偏安一隅”但在 Agent 生态真正成熟之前这“一隅”的含金量极高。4.2 RAG 与知识库元数据管理仍然依赖 JSONRAG检索增强生成是现在企业落地大模型最主流的方式。它的核心是用私域知识库做向量化检索把相关片段取出来作为上下文交给大模型回答。在这个流程中知识片段的主体内容会被切成 chunk做向量化处理但每个 chunk 的元数据——来源文档、标题、章节、作者、时间戳、权限标签——通常就是 JSON 格式。为什么因为元数据需要灵活的支持各种自定义字段而 JSON 恰好提供了这种灵活性。比如我用向量数据库存内部规章制度时会在每条 chunk 的 metadata 里塞{doc_name: 考勤制度, department: HR, version: v2.1, effective_date: 2025-01-01}。检索完之后我会先看这些 metadata决定要不要把这条结果呈现给用户。如果某个文档已过期我可以直接根据 metadata 里的版本字段把它过滤掉。这种灵活的字段扩展能力用 SQL 表结构不一定做不到但开发效率上确实 JSON 最顺手。4.3 API 与 Agent 生态JSON 仍是“工具链的通用语”最后是我开头提到的那个观点AI 不是生活在真空里它必须调用真实的工具、访问真实的 API。而几乎所有公共 API 的默认数据格式都是 JSON。GitHub API 返回 JSONStripe 支付接口用 JSON微信小程序后端用 JSON数据库查询的 HTTP 接口返回 JSON。AI Agent 作为这一代应用的新交互入口本质上是在替你把这些 API 串起来。如果这个世界的 API 不用 JSON 了Agent 的生存基础反而会受到威胁。我在做一个研究助手型 Agent 的时候需要在一次任务里调用搜索、资讯抓取、表格生成、图表渲染四种工具。这些工具的输入输出参数无一例外都通过 JSON 传递。Agent 的规划器在决定调用顺序时也要把中间结果封装成 JSON 缓存传给下一步的处理器。没有 JSON这个轻量级的 Agent 编排流程会变得极其笨拙。这正是 JSON 的生命力所在——它也许不是效率最高的格式却是互操作成本最低的格式。5. 趋势观察与实操建议AI 时代的数据格式选型策略5.1 我的选型经验什么场景坚持 JSON什么场景果断换掉踩过不少坑之后我总结了一套自己的选型原则。这个原则不复杂核心是看数据要经过哪些“域”。第一数据只在 API 边界、用户终端、工具调用之间流转坚持用 JSON不要换。这是它的主场维护成本最低生态支持最好。第二数据要灌给模型做推理或微调尽量转成 JSONL尤其是在处理大批量样本时。第三数据要在服务间高并发、低延迟传输果断考虑 Protocol Buffers 或其他二进制方案。第四数据用于配置文件、提示词模板、Agent 行为定义优先 YAML 或 TOML。用这个原则去审视现有系统你会发现很多“JSON 性能瓶颈”其实是用错了场景。你拿着 JSON 当高并发内部协议用自然痛不欲生但如果你退回到 API 边界场景它依然是最舒服的选择。这和“消亡”无关只是“用对位置”。5.2 给开发者的实操建议与避坑指南第一不要迷信模型的 JSON 输出能力。即使你开了结构化输出模式也一定要在代码侧做二次校验。我见过太多生产事故源于模型返回的 JSON 里多了一个未知字段解析库直接报错。处理方法是用宽容的解析策略比如 Python 里先尝试json.loads失败后用json5库兜底再不行就触发一次重试。第二在提示词里明确“只输出 JSON不要解释”。这是我反复踩坑后总结的经验。模型经常会仁慈悲悯地在 JSON 前后加一段话比如“好的这是你要的结果”。这句话一旦混进输出你的解析器就会崩溃。现在我都会在 system prompt 里严格要求Return ONLY valid JSON, no markdown, no comments, no explanation并在代码里用正则把可能包裹的json代码块剥掉再做解析。第三小心 json parse error 的时间陷阱。有一个经典报错cannot deserialize value of type java.util.Date from String。这不是 JSON 本身的错而是 JSON 没有内置日期类型时间到底存成字符串还是时间戳完全靠约定。Java 这边用 Jackson 解析时如果反序列化配置没指定格式就会炸。AI 时代这个坑更多了因为模型可能用各种格式输出日期字符串。我的建议是在 Schema 里显式定义日期格式正则并且在后端统一做一层日期解析适配器。第四关注 json序列化工具的选择。同样是序列化Python 的orjson比标准json库快数倍Java 的Jackson/fastjson各有取舍Go 的encoding/json标准库在性能上已经越来越跟不上jsoniter的节奏。做 AI 数据管道时我建议能用 C 扩展实现的高性能序列化库就不要用纯 Python 标准库。有时候几十 GB 数据转下来差别是小时级的。5.3 未来推演JSON 的演变而非消亡最后聊聊未来。我个人的判断是JSON 不会消亡但也不会继续保持在“唯一中心”的位置它会回归到“网页和 API 的基础格式”这一本色。AI 内部会有更多自己的原生格式也许是更高效的二进制协议、也许是更语义化的结构化标记、也许是一种全新的数据容器。但这些格式大概率不会直接出现在公共接口层因为公共接口层需要的是“通用性”和“最小摩擦”JSON 依然是现在最优解。一个更现实的演化方向是“JSON 和 AI 互相适应”。当前的大模型正在通过 Function Calling 学习如何输出合法 JSON这是模型向 JSON 的妥协同时工程师也在研究更省 token 的结构化表达方法比如让模型只输出键值对列表而不是嵌套对象、使用短键名、提前拍平数据结构这是工程向 AI 的妥协。两股力量的拉扯会把 JSON 的使用方式推向一个更成熟、更多元的状态。有一点可以确定作为一名从业者你不需要“站队”去拥护或者批判 JSON。真正有用的能力是在合适的场景下选择合适的数据格式并理解每一种格式背后的成本和收益。这比追逐概念、抢着宣布“旧技术已死”要务实得多。 
长河君 · 2026/11/4 4:17:55 · 阅读 1.2k AI时代JSON未死：角色迁移与数据格式选型指南
最近中文技术社区里冒出一个很火的论题“JSON 在 AI 时代正走向消亡”。做后端的人看到这句话容易坐不住毕竟手上的接口还在用 JSON 和前端联调搞 AI 的人倒是频频点头因为他们在微调、训练、Agent 调用里已经踩过太多 JSON 的坑。这个标题确实有点标题党的味道但背后的问题是真真切切的AI 时代的数据交换方式到底还在多大程度上依赖 JSONJSON 会不会被某种新格式取代我自己的看法是JSON 不会这么快“死”但它的角色正在发生剧烈的迁移。以前它是数据交换的绝对中心现在它退到了三层位置——AI 内部计算不吃 JSONAI 训练数据不用 JSONAgent 之间的信息传递也开始绕开 JSON。但与此同时JSON 在另一些地方反而更牢固了比如大模型的 Function Calling 结构化输出、RAG 知识库的元数据管理、AI 工具的配置体系。这篇文章我想把这个话题拆开揉碎结合我这两年做 AI 应用开发的实际经验聊聊 JSON 在 AI 时代究竟遭遇了什么哪些地方它真的不行了哪些地方它依然是刚需以及我们这些做工程的到底该怎么选型。1. 这个标题是怎么来的——从“JSON 已死”到“JSON 还活着”1.1 论题的来源JSON 与现代 AI 格格不入的三个信号任何一个耸动的标题背后一定有真实痛点在支撑。“JSON 在 AI 时代正走向消亡”这个说法最早是从大模型应用开发者的吐槽里发酵出来的。第一批给 GPT 类模型写代码的人发现让模型输出一段严格合法的 JSON 是一件既费 token 又容易翻车的事。模型经常给你多一个逗号、少一个引号或者把一个字符串意外截断直接导致json.loads抛异常。如果你在大规模流水线里跑几百个结构化抽取任务你就会对“JSON parse error”产生生理厌恶。第二个信号来自模型推理的“注意力分布”。Transformer 架构对 token 的处理逻辑决定了它会花大量计算在结构符号上。一个包含大量引号、冒号、花括号的 JSON 文本在模型眼里就是大段的“结构性噪音”。同样一段业务信息写成 JSON 消耗的 token 往往是纯文本的两三倍。在按 token 计费、按上下文窗口算容量的时代这就是真金白银的成本浪费。第三个信号出现在模型训练阶段。现在大模型的训练数据主要来自网页、论文、代码仓库、对话记录几乎没有人会把海量 JSON 文档直接喂给模型做预训练。JSON 是为机器间通信设计的它的可读性远不如 Markdown、自然语言或者表格模型学习起来非常低效。所以你会发现ChatGPT 这类产品的接口文档里有 JSON Schema 定义但模型内部对“JSON 格式”的理解其实远没有对“自然语言指令”理解得深。1.2 先别急着唱衰JSON 在 AI 生态中的真实位置上面这些信号都是真实的但“消亡”这个词用得过于浪漫主义了。AI 应用不是凭空长出来的它长在互联网的根基上。而互联网过去二十年最成功的通用数据协议就是 JSON。你要让 AI Agent 去调用一个搜索 API、查一个天气接口、写一条数据库记录这些接口背后全是 JSON。除非我们把整个 Web 基础设施推倒重来否则 JSON 在可预见的未来都会是 AI 与外部世界打交道时的事实标准。我的判断是JSON 没有在消亡它是在“降权”。以前它是数据的唯一主角现在它更像是一个“边界协议”——只在系统边缘、工具调用、人机交互的接口处出现而数据在 AI 内部流转时已经被换成向量、token 序列、二进制张量这些更底层的表达。这个转变对后端工程师的冲击不小因为大家的思维还停留在“一切皆 JSON”的阶段但 AI 原生应用的设计者已经开始把 JSON 当作最外层的一层壳。2. JSON 和 AI 的相爱相杀为什么模型“看不上”JSON2.1 Token 浪费JSON 的结构化语法在模型眼里是“噪音”用生活里的例子来类比可能更直观。你去听一场讲座讲师讲了一个小时但真正有用的信息其实只有三句话。这三句话如果提炼出来可能就 50 个字但讲师为了组织表达用了大量连接词、铺垫、重复强调。JSON 的结构化语法在模型眼里就扮演了“废话连接词”的角色。比如{user_id: 123, user_name: 张三, user_age: 28}这段数据真正有价值的信息是“123、张三、28”这三个值而{user_id:,:,,这些东西对模型理解语义几乎没有任何帮助。在 Transformer 的注意力机制里这些符号虽然不是完全无用它们帮助模型定位字段边界但相比自然语言令牌它们携带的语义信息密度低很多。更麻烦的是大模型的 Tokenizer 通常会把:、等符号切分成独立的 token原本一个单词能表达的信息现在要拆成多个 token。我在实际项目里统计过同一份销售数据用 JSON 表达大约 1200 个 token用纯文本表格表达只要 600 个左右用自然语言描述只要 400 个。在批量处理场景下这是成倍的成本差异。2.2 解析地狱AI 生成 JSON 时的格式不稳定做过 AI 结构化抽取的人大概率遇到过“模型输出的 JSON 差一个引号”的玄学问题。你让模型按指定格式抽取合同里的关键字段它偏偏给你输出一段带解释性前缀的文本。你做了 few-shot 示例它却用错注释符号。你锁死了 JSON Schema结果它在花括号里嵌套了一段啰嗦的自白。这些问题的根源在于大模型本质上是“概率化的语言生成器”而不是“格式化的序列化器”。它生成“看起来像 JSON 的文本”而不是严格符合规范的 JSON 值。为了对付这种不确定性工程上出现了大量的 JSON 修复工具、容错解析库、重试策略。OpenAI 等厂商也推出了json_mode、结构化输出、Function Calling 等功能本质上不是让模型更懂 JSON而是把 JSON 生成过程变成了“受限解码”或“Schema 约束下的标记生成”。这相当于我们用外部规则强行纠正模型的自由主义输出倾向。虽然可靠度大幅提升了但这也说明了一个尴尬的事实JSON 格式对模型而言不是天然友好的母语而是需要“看着说明书手写”的外语。2.3 嵌套地狱复杂 JSON 让模型上下文窗口雪上加霜另一个容易被忽视的问题是嵌套复杂度。业务系统里那种五六层嵌套的 JSON交给人类后端开发者阅读都有压力更别提让模型在有限的上下文窗口里去理解并操作了。上下文窗口就像一个人的工作记忆你往里塞的无效结构越多模型能记住的有效业务信息就越少。为了让模型在长文档上保持高质量表现我现在做提示词工程时都会刻意把输入数据先“拍平”——把多层嵌套 JSON 转成扁平的表格、键值列表或者 JSONL 格式再喂给模型。举个例子一个包含订单、商品、物流、售后四层嵌套的 JSON 对象如果直接塞给模型分析它很容易在第三层就“失忆”。但如果你把它转成行式 JSONL每行一条完整记录或者拍平成多张关系表模型的处理质量会明显上升。这就逼着我们在 AI 工作流里做大量的 json转换和预处理而不是原样把混论结构丢给模型。3. 时代替代品AI 原生数据格式正在崛起既然 JSON 在 AI 内部场景有这么多的不适应那么替代品自然会出现。我这里说的“替代”不是指一夜之间替换而是在 AI 原生链路里越来越多的团队开始选用新的数据表达方式。3.1 JSONLAI 训练和日志领域新的事实标准JSONL 的全称是 JSON Lines说白了就是每一行一个完整的 JSON 对象。它看起来从 JSON 派生而来但在 AI 数据工程里它的地位已经完全独立于 JSON。大模型微调的数据集格式几乎清一色是 JSONL{instruction: ..., input: ..., output: ...}一行一个样本。RAG 向量库的元数据导入、海量日志的采集、批量流水线的输入输出也都在用 JSONL。为什么 JSONL 这么吃香因为它天然适配“逐行处理”的管道模式。你可以用for line in file一条条读取不必把整个文件加载到内存再整体解析。对于动辄几个 GB 的训练集这是最重要的工程优势。而且 JSONL 的每一行是独立的如果中间有一行数据坏了你只需要跳过这一行不会像解析一个大 JSON 文件那样“一损俱损”。在处理大规模数据时这种容错能力是非常现实的考量。3.2 向量存储与嵌入取代“结构”的不是新格式而是新常态AI 时代最深刻的变化其实是数据表达的根本性转移。以前我们关注“字段和类型”现在越来越关注“语义向量和相关性”。一篇文档、一段对话、一张图片在模型内部都会被转换成一串高维向量Embedding。这些向量代表的不是结构化的字段值而是语义空间里的坐标。搜索、推荐、问答全都变成向量之间的相似度计算。这意味着在很多 AI 应用里JSON 里的字段信息反而不重要了重要的是这个对象对应的向量。你在做语义检索时先通过向量召回一批候选结果再把它对应的原始文档很可能是一段文本不是 JSON拿回来交给大模型做分析。数据从“可解析的结构化对象”变成了“不可直接阅读的数值矩阵”。这是对 JSON 统治地位最釜底抽薪的打击。3.3 二进制时代回归Protocol Buffers、FlatBuffers 与 MessagePack如果说 JSONL 和向量改变了数据存储的方式那么序列化协议的变化则直接发生在数据交换的层面。我用过 JSON 做内部服务之间的通信最早图省事、调试方便后来流量上来后开始纠结 JSON 的序列化性能和体积。JSON 的文本格式天生就比二进制格式冗余。后来我换成 Protocol Buffers序列化后的体积只有 JSON 的五分之一左右解析速度提升了近一个量级。在 AI 推理服务里这种体积和性能差异更加致命。推理引擎需要在高并发下快速读写海量的中间数据、特征向量、模型输出。如果每一路调用都走 JSON带宽和 CPU 都会被无谓占用。因此你会看到很多 AI 推理框架的底层数据传输都采用了二进制协议JSON 仅仅保留在对外 HTTP 接口那一层。这也是“JSON 在 AI 时代走向消亡”论调的另一个现实支撑——在最内层、最核心的数据通路上JSON 已经边缘化了。3.4 YAML/TOML 的逆袭配置场景中的“人机友好”偏好还有一个有趣的趋势是在 AI 应用的配置管理里YAML 和 TOML 正在挤占 JSON 的位置。原因很简单人类写 prompt、配模型参数、定义 Agent 行为时需要更贴近自然语言的表达方式。JSON 的每个 key 都要加双引号、每个对象要写大括号在写复杂配置时非常痛苦。YAML 靠缩进表达层级写了就让人眼明心亮TOML 的[section]结构在管理扁平配置时格外清晰。比如我维护一个多 Agent 协作系统里面需要定义每个 Agent 的 system prompt、模型参数、工具列表、温度系数。早期用 JSON 写配置维护成本很高后来改成 YAML不仅可读性好并且可以直接在文件里写注释解释每个参数的含义。对 AI 工程师而言配置文件的“可编辑性”和“可读性”比“严格可序列化”更重要这是从前端 API 时代延续下来的思维惯性所不能理解的。4. JSON 从未离开AI 时代的三大不可替代场景看到这里你可能觉得 JSON 真的不行了。别急接下来我要说它的“护城河”。在 AI 应用中有三个场景不仅离不开 JSON反而因为 AI 的发展变得更加依赖它。4.1 结构化输出大模型 Function Calling 的接口协议Function Calling 是现在 AI Agent 的核心能力之一。模型理解用户的自然语言请求后决定要调用哪个工具、传入什么参数然后以结构化格式输出调用指令。而这个结构化格式目前的标准就是 JSON。比如模型决定查询天气它需要输出{function_name: get_weather, parameters: {city: 北京}}这样的结构才能被 Agent 框架解析并执行。OpenAI 的 API 文档里工具函数的参数定义用的是 JSON Schema模型返回的也是 JSON 格式的函数调用参数。Anthropic 的 tool use 机制大同小异Google Gemini 的 function declaration 同样依赖 JSON Schema。这说明什么说明在未来相当长的时间里AI 与外部工具之间的“接口层”始终要有一种稳定的、类型明确的、机器可读的格式而 JSON 是目前综合成本最低的选择。你可以说这不是 JSON 的胜利而是 JSON 的“偏安一隅”但在 Agent 生态真正成熟之前这“一隅”的含金量极高。4.2 RAG 与知识库元数据管理仍然依赖 JSONRAG检索增强生成是现在企业落地大模型最主流的方式。它的核心是用私域知识库做向量化检索把相关片段取出来作为上下文交给大模型回答。在这个流程中知识片段的主体内容会被切成 chunk做向量化处理但每个 chunk 的元数据——来源文档、标题、章节、作者、时间戳、权限标签——通常就是 JSON 格式。为什么因为元数据需要灵活的支持各种自定义字段而 JSON 恰好提供了这种灵活性。比如我用向量数据库存内部规章制度时会在每条 chunk 的 metadata 里塞{doc_name: 考勤制度, department: HR, version: v2.1, effective_date: 2025-01-01}。检索完之后我会先看这些 metadata决定要不要把这条结果呈现给用户。如果某个文档已过期我可以直接根据 metadata 里的版本字段把它过滤掉。这种灵活的字段扩展能力用 SQL 表结构不一定做不到但开发效率上确实 JSON 最顺手。4.3 API 与 Agent 生态JSON 仍是“工具链的通用语”最后是我开头提到的那个观点AI 不是生活在真空里它必须调用真实的工具、访问真实的 API。而几乎所有公共 API 的默认数据格式都是 JSON。GitHub API 返回 JSONStripe 支付接口用 JSON微信小程序后端用 JSON数据库查询的 HTTP 接口返回 JSON。AI Agent 作为这一代应用的新交互入口本质上是在替你把这些 API 串起来。如果这个世界的 API 不用 JSON 了Agent 的生存基础反而会受到威胁。我在做一个研究助手型 Agent 的时候需要在一次任务里调用搜索、资讯抓取、表格生成、图表渲染四种工具。这些工具的输入输出参数无一例外都通过 JSON 传递。Agent 的规划器在决定调用顺序时也要把中间结果封装成 JSON 缓存传给下一步的处理器。没有 JSON这个轻量级的 Agent 编排流程会变得极其笨拙。这正是 JSON 的生命力所在——它也许不是效率最高的格式却是互操作成本最低的格式。5. 趋势观察与实操建议AI 时代的数据格式选型策略5.1 我的选型经验什么场景坚持 JSON什么场景果断换掉踩过不少坑之后我总结了一套自己的选型原则。这个原则不复杂核心是看数据要经过哪些“域”。第一数据只在 API 边界、用户终端、工具调用之间流转坚持用 JSON不要换。这是它的主场维护成本最低生态支持最好。第二数据要灌给模型做推理或微调尽量转成 JSONL尤其是在处理大批量样本时。第三数据要在服务间高并发、低延迟传输果断考虑 Protocol Buffers 或其他二进制方案。第四数据用于配置文件、提示词模板、Agent 行为定义优先 YAML 或 TOML。用这个原则去审视现有系统你会发现很多“JSON 性能瓶颈”其实是用错了场景。你拿着 JSON 当高并发内部协议用自然痛不欲生但如果你退回到 API 边界场景它依然是最舒服的选择。这和“消亡”无关只是“用对位置”。5.2 给开发者的实操建议与避坑指南第一不要迷信模型的 JSON 输出能力。即使你开了结构化输出模式也一定要在代码侧做二次校验。我见过太多生产事故源于模型返回的 JSON 里多了一个未知字段解析库直接报错。处理方法是用宽容的解析策略比如 Python 里先尝试json.loads失败后用json5库兜底再不行就触发一次重试。第二在提示词里明确“只输出 JSON不要解释”。这是我反复踩坑后总结的经验。模型经常会仁慈悲悯地在 JSON 前后加一段话比如“好的这是你要的结果”。这句话一旦混进输出你的解析器就会崩溃。现在我都会在 system prompt 里严格要求Return ONLY valid JSON, no markdown, no comments, no explanation并在代码里用正则把可能包裹的json代码块剥掉再做解析。第三小心 json parse error 的时间陷阱。有一个经典报错cannot deserialize value of type java.util.Date from String。这不是 JSON 本身的错而是 JSON 没有内置日期类型时间到底存成字符串还是时间戳完全靠约定。Java 这边用 Jackson 解析时如果反序列化配置没指定格式就会炸。AI 时代这个坑更多了因为模型可能用各种格式输出日期字符串。我的建议是在 Schema 里显式定义日期格式正则并且在后端统一做一层日期解析适配器。第四关注 json序列化工具的选择。同样是序列化Python 的orjson比标准json库快数倍Java 的Jackson/fastjson各有取舍Go 的encoding/json标准库在性能上已经越来越跟不上jsoniter的节奏。做 AI 数据管道时我建议能用 C 扩展实现的高性能序列化库就不要用纯 Python 标准库。有时候几十 GB 数据转下来差别是小时级的。5.3 未来推演JSON 的演变而非消亡最后聊聊未来。我个人的判断是JSON 不会消亡但也不会继续保持在“唯一中心”的位置它会回归到“网页和 API 的基础格式”这一本色。AI 内部会有更多自己的原生格式也许是更高效的二进制协议、也许是更语义化的结构化标记、也许是一种全新的数据容器。但这些格式大概率不会直接出现在公共接口层因为公共接口层需要的是“通用性”和“最小摩擦”JSON 依然是现在最优解。一个更现实的演化方向是“JSON 和 AI 互相适应”。当前的大模型正在通过 Function Calling 学习如何输出合法 JSON这是模型向 JSON 的妥协同时工程师也在研究更省 token 的结构化表达方法比如让模型只输出键值对列表而不是嵌套对象、使用短键名、提前拍平数据结构这是工程向 AI 的妥协。两股力量的拉扯会把 JSON 的使用方式推向一个更成熟、更多元的状态。有一点可以确定作为一名从业者你不需要“站队”去拥护或者批判 JSON。真正有用的能力是在合适的场景下选择合适的数据格式并理解每一种格式背后的成本和收益。这比追逐概念、抢着宣布“旧技术已死”要务实得多。