我们几乎都经历过这样的落差：
Demo 环节，Agent 一口气修好了三个 bug、画出了一张漂亮的架构图、把一坨数据变成了可视化大屏，全场掌声。可一旦把这套东西接进生产流程，团队的第一反应往往是------"它说的对吗？怎么证明？"
这个落差，不是模型能力的问题，而是**可验证性（Verifiability）**的问题。
一个 Agent 输出"看起来都对"，却没有客观判据能证明它对，那它就永远只能停留在"演示"，走不进"落地"。在我看来，可验证，才是 Agent 从演示走向落地的分水岭，甚至可以说是它的第一性原理。
这篇文章想用三条线索来论证这件事：AI coding 的发展、text-to-viz 的演进、以及最近很火的开源 Agent Skill------Archify。最后聊聊落地时应该怎么设计"可验证"，以及它为什么不是万能的。
一、AI coding 为什么发展最快？因为代码天生自带"验证闭环"
同样是 Agent，AI coding 是落地最快、最激进的那一个。很多人把它归因于"模型会写代码了"，但更底层的推动力是：代码，是少数天生自带"可验证闭环"的产物。
代码有一套别的产物没有的验证设施：
- 编译与类型检查------语法对不对、类型通不通，机器一秒钟给出结论，不用人肉眼逐行审；
- 单元测试与集成测试------行为对不对，跑一遍测试就知道，对就是对、错就是错；
- Lint 与静态分析------风格、隐患、坏味道，工具能自动扫出来。
这让 AI 写代码的每次迭代，都能跑在"生成 → 编译/测试 → 拿到机器可读的失败信息 → 修复 → 再验证"的闭环里。这个闭环，才是 AI coding 高速发展的真正引擎：Agent 的自我纠错有了客观基准，人类也敢放手把它放进真实工程流程------因为就算它错了，错误也是可发现、可定位、可控成本的。
而且这个闭环不是天然就有的，它是软件工程几十年积累的验证设施（编译器、测试框架、CI/CD）被 AI 继承和复用的结果------原本给人用的"质检线"，变成了 AI 的健身房。
再回头看 coding benchmark 的演进，就能更清楚地看到这条线索。从 HumanEval 的函数题，到 SWE-bench 的仓库级真实 issue 修复（让 Agent 产出的 patch 跑隐藏测试来机器判分），再到 Verified 的人工过滤、SWE-bench Pro 的更严格标准，业界做的其实是同一件事：把"改得对不对"度量衡化，并不断加固验证闭环本身的可靠性------测试要先被验证可靠，才有资格拿来验证 Agent。连 OpenAI 审计出 Verified 的测试存在缺陷和污染、行业转向更严的 SWE-bench Pro，本质上也是在加固这个闭环。所以业内连"选哪个模型"都建议自建 20~100 条真实任务的小测试集去跑------把验证闭环从 benchmark 下沉到自己的业务上。
反过来看，这也是很多其他类型 Agent 落地偏慢的原因：文案、设计、分析这类产物没有内置的、机器可判定的闭环，只能靠人看、靠主观判断，一次迭代的成本和不确定性都高得多。AI coding 的快，吃的是代码的"可验证性红利"。
二、text-to-viz：为什么偏偏是 Vega-Lite 让可视化"可以被验证"
第二条线索来自"自然语言生成可视化"这个领域（NL2VIS / text-to-viz）。
这个方向很早就开始了。2019 年就有 Text-to-Viz 的研究，尝试从自然语言自动生成信息图；随着 LLM 兴起，Chat2VIS 等系统让用户用大白话就能得到可视化。但生成物的形态很关键：模型不直接"画"图，而是生成一段声明式的图规范（DSL），其中最主流的载体就是 Vega-Lite。
为什么偏偏是 Vega-Lite？因为它把"可验证"做成了基础设施。Vega-Lite 用 JSON 描述图表，并且官方为它发布了完整的 JSON Schema （https://vega.github.io/schema/vega-lite/v5.json，每个版本都有对应的 schema）。这意味着任何一段生成的 spec，都可以被机器逐字段校验：mark 用错了图元、encoding 用错了通道、字段类型写错、属性层级放错位置------校验器（比如 ajv）能精确指出错在哪；Vega Editor 这类编辑器也是靠 spec 里的 $schema 实现自动校验和补全的。整个生态甚至把这当成了默认动作：Altair 对自己的定位就是"生成已验证的 Vega-Lite 规范"，VegaChat 等系统也明确写着"生成的 spec 会先用 schema 和启发式规则校验"。
于是 text-to-viz 也跑进了和代码一样的闭环：自然语言 → 生成 Vega-Lite DSL → schema 校验 → 拿到精确错误 → 修复 → 再校验 → 渲染。DSL 准不准，不再取决于模型嘴上说得多自信，而取决于它过没过 schema------这正是"可验证"在发挥作用的体现。对比之下，如果模型直接吐一张位图，没人能校验；而吐的是带 schema 的 Vega-Lite spec，机器就能在渲染前拦住错误。可视化领域自己还长出了评测基准（如 Text2Vis），本质也是给"生成对没对"下客观判据。
所以回到那个关键的区分：一个可验证的可视化，别人能重新执行它、用 schema 校验它、核对它的数据、指出它错在哪；一个不可验证的可视化，只能"信我"。 前者是证据，后者是配图。对 Agent 落地而言，你要的是证据，不是配图。
三、Archify：连一张架构图，都开始要求"可验证"
如果说前两条线索还比较宏观，那 Archify 这条线索是最具体的------它几乎是把"可验证"写进了产品哲学。
Archify 是一个开源 Agent Skill（GitHub 上的 tt-a1i/archify，MIT 协议，目前已有 42.9k star），给 Claude Code、Codex CLI、Cursor 这类 coding agent 用。作用是：用大白话描述你的系统，让 Agent 直接生成专业的架构图、时序图、数据流图。
它和传统"让 AI 画图"的路径有什么区别？传统路径（包括让模型生成 Mermaid 代码）最大的痛点是：自动布局引擎把布局决策权拿走，8 个组件和 40 个组件的图长一个样；颜色语义每次对话都不一致；最要命的是，图无法验证对错。
Archify 的解法是反过来的：
- 把布局决策权还给 LLM------因为"布局本身就是信息"，Agent 决定坐标、颜色、层级，工具不越俎代庖；
- 工具层只做确定性校验------Agent 产出的是类型化的 JSON 中间表示（Typed JSON IR），再用 JSON Schema 校验、渲染后检查器逐项把关；
- 原子交付------"先检查、再替换"，只有通过全部检查的产物才会覆盖上一个好版本，失败不会破坏现状；
- 失败反馈是机器可读的 repair receipt------告诉你哪条规则失败、具体哪个对象、支持哪些修复方式，而不是一句玄学的"请重试"；
- Architecture Delta------对比两个经过校验的架构快照，精确到 added / removed / changed / moved / rerouted，让 PR 阶段的架构评审可以像 diff 代码一样 diff 架构。
注意它选型的细节：中间格式用 JSON 而不是 YAML，理由是 LLM 生成 YAML"看着对、解析错"的比例高------一个做"可验证"的工具，连中间格式都要选最不容易被糊弄的。
更诚实的部分是，Archify 自己在文档里也标注了边界：schema 校验不等于语义正确------校验器只能保证结构合法，不能保证"这张图是否准确反映了真实系统"。这个自我设限非常值得赞赏，它说明真正的"可验证"工程，是有自知之明的。
我的判断是：当一张架构图都要开始讲"可验证"的时候，说明"可验证"已经渗透到了 Agent 产物的最末端。这不是一个孤立工具，而是整个行业对 Agent 输出不信任的集体回应。
四、落地时，请把"可验证"设计成分级约束
讲完三条论据，落到实操：Agent 落地时，应该怎么设计"可验证"？
我的建议是把它当成一条光谱，而不是一个开关，按下面四步走：
1. 先定义"对"是什么。 每个 Agent 任务都要回答：成功判据客观吗？有测试、schema、数据对账这类机器判据，还是只能靠人工判断？没有判据的任务，别急着让 Agent 全自动。
2. 为可验证设计产物格式。 像 Archify 的 Typed JSON IR 那样，给 Agent 的中间产物一个结构化、可校验的表示；失败信息做成机器可读（精确到哪条规则、哪个对象、支持什么修复），而不是一句"重试一次"。
3. 建立"生成→校验→反馈→迭代"的闭环，并坚持"先检查再替换"。 校验不通过的产物不进入下一步，失败不覆盖最后的好状态。这个闭环让 Agent 的自我纠错有据可依，也让人类敢放手。
4. 分级验证。 数据正确性、代码正确性、格式合法性，用机器验证；语义、体验、审美，留给人工复核。高风险、高复用、高频的任务，验证设施做深；反之做浅。
最后给你一个自检清单：这个 Agent 的输出，如果错了，系统能以多低的成本发现？以多快的速度修正？失败信息能不能指引修复？ 这三个问题的答案，基本决定了它能不能真正落地。
五、但"可验证"并不适合所有场景
看到这里，别急着把"可验证"当成万能灵药。它很重要，但不是所有场景都适合，至少有三类例外：
第一，过度可验证会杀死创造力。 写文案、做创意、情绪表达类任务，如果强行套客观指标，你会得到一堆"可测量但平庸"的产物。对这类任务，"好"与"可测"本来就是两回事，强行验证等于把上限给砍了。
第二，验证设施本身有成本。 定义判据、建设测试与校验管线，都是实打实的投入。对低频、低风险、一次性任务（比如随手画个示意图），花大力气搭验证体系是典型的过度工程。
第三，有些任务客观上就无法客观验证。 开放性问题、审美判断、探索性写作，它们没有标准答案。这时候"可验证"应该退化成更轻的形态：可追溯 （每个结论都能找到出处）、人工复核点 （在关键节点让人把关）、可控的失败范围（错了也只影响局部）。
所以更准确的说法是：可验证是手段，不是目的。 它的作用是------当 Agent 出错时，我们以多低的成本、多快的速度发现并修正。按任务的风险、频次、复用价值来分配验证投入，而不是一刀切。
结语
回看这三条线索：AI coding 靠代码自带的验证闭环，把"改代码"滚成了仓库级工程能力；text-to-viz 靠 Vega-Lite 的 schema 校验，把生成的 DSL 变成了可验证的证据；Archify 连一张架构图都要上 JSON Schema 校验和原子交付。
它们指向同一个结论：可验证，把 Agent 从"表演者"变成了"协作者"。 表演者只需要让观众一时信服，协作者必须能对自己的产出负责。
Agent 落地的分水岭，从来不在模型参数有多强，而在于------你的系统，敢不敢让 Agent 的产物接受检验。
当"产物自带验证"成为标配的那天，Agent 才真正开始融入工程，而不只是站在那里，等你鼓掌。
参考资料：
- SWE-bench（Princeton / SWE-bench 团队）：swebench.com
- 《聊聊 SWE-Bench Pro：Claude Mythos 5 / Fable 5 的 80.3 分，真的可信吗？》（51CTO）：www.51cto.com/article/845...
- Text-to-Viz（arXiv, 2019）：arxiv.org/abs/1907.09...
- Chat2VIS（arXiv, 2023）：arxiv.org/abs/2302.02...
- Archify（GitHub, tt-a1i/archify）：github.com/tt-a1i/arch...
- 《Archify：让 AI Agent 直接生成可校验架构图的 Agent Skill 深度解析》（掘金）：juejin.cn/post/766890...