1. 先解決一個(gè)反常識(shí)的問(wèn)題Agent 畫(huà)圖為什么不能用“畫(huà)”的前陣子在研究 Agent 工具鏈的時(shí)候注意到一個(gè)很有意思的開(kāi)源項(xiàng)目——Archify目前已經(jīng)積累了 35k Stars。它的核心口號(hào)翻譯過(guò)來(lái)很直接“Agent 畫(huà)圖需要編譯器?！边@個(gè)說(shuō)法乍一聽(tīng)挺反直覺(jué)的。畫(huà)圖這件事人是用手畫(huà)的用鼠標(biāo)拖的用畫(huà)板涂的怎么到了 Agent 這里反而要“編譯”但只要你真的用 Agent 生成過(guò)復(fù)雜的圖形界面、數(shù)據(jù)可視化圖表、架構(gòu)圖、流程圖你大概率遇到過(guò)下面這些讓人抓狂的場(chǎng)景讓 Agent 畫(huà)一個(gè)多分支流程圖它畫(huà)到第三個(gè)分支就開(kāi)始重疊節(jié)點(diǎn)擠成一團(tuán)連線繞得跟迷宮一樣。讓 Agent 生成一張柱狀圖加趨勢(shì)線的組合圖它先把柱狀圖畫(huà)完然后趨勢(shì)線完全對(duì)不上柱子的 X 軸坐標(biāo)。讓 Agent 一邊回答問(wèn)題一邊畫(huà)個(gè)對(duì)照示意圖它畫(huà)完之后圖里的數(shù)字和它上文說(shuō)的結(jié)論對(duì)不上。稍微把需求描述得復(fù)雜一點(diǎn)比如“在這三個(gè)節(jié)點(diǎn)下面各掛兩個(gè)子節(jié)點(diǎn)其中第二個(gè)子節(jié)點(diǎn)用不同顏色”它就崩潰了輸出一堆亂碼或者直接報(bào)錯(cuò)。這些問(wèn)題的根源在哪里我自己的結(jié)論是我們把 Agent 當(dāng)成了“畫(huà)師”但它本質(zhì)上是個(gè)“語(yǔ)言模型”。它擅長(zhǎng)的是一步步地推理和生成 token而不是在二維空間里做精確的幾何排布。你讓它直接寫(xiě) SVG 或者用某個(gè)繪圖庫(kù)去畫(huà)就是在逼它用自己不擅長(zhǎng)的方式做一件需要空間感知力的事情。那怎么辦Archify 的思路是別讓 Agent 直接碰畫(huà)布讓它先寫(xiě)代碼再寫(xiě)一種高度結(jié)構(gòu)化的中間表示IR最后由一個(gè)專(zhuān)門(mén)的“編譯器”去渲染成最終圖形。這就是“Agent 畫(huà)圖需要編譯器”這句話(huà)的底層邏輯。這篇文章我就以 Archify 為例把 typed JSON IR 這套方案從頭到尾拆一遍。聊清楚它到底解決什么問(wèn)題、核心設(shè)計(jì)是什么、以及你怎么把這種思路抄到自己的 Agent 項(xiàng)目里。2. 核心問(wèn)題拆解Agent 畫(huà)圖的痛點(diǎn)到底在哪里要理解 Archify 的方案必須先理解 Agent 原生繪圖方式為什么會(huì)崩。我總結(jié)下來(lái)核心痛點(diǎn)有三個(gè)。2.1 語(yǔ)言模型的“局部最優(yōu)”陷阱它看不見(jiàn)整塊畫(huà)布先說(shuō)第一個(gè)痛點(diǎn)——Agent 沒(méi)有全局視野。大模型在生成長(zhǎng)文本的時(shí)候是逐 token 生成的每一步只看得到它已經(jīng)生成的內(nèi)容和當(dāng)前上下文窗口里有限的信息。它沒(méi)有一個(gè)“全局畫(huà)布”的概念更不會(huì)在生成完第一個(gè)節(jié)點(diǎn)之后回頭檢查第二個(gè)節(jié)點(diǎn)有沒(méi)有超出畫(huà)布邊界。舉一個(gè)我實(shí)際測(cè)試過(guò)的例子。我讓一個(gè) Agent 用 HTML CSS 畫(huà)一張組織結(jié)構(gòu)圖包含一個(gè) CEO頂層、三個(gè) VP第二層每個(gè) VP 下面兩個(gè)孩子節(jié)點(diǎn)。這個(gè) Agent 生成的頁(yè)面兩個(gè) VP 的區(qū)塊在橫向排列時(shí)直接重疊了因?yàn)樗谟?jì)算每個(gè)板塊寬度的時(shí)候用的是估計(jì)值而不是真實(shí)的布局引擎結(jié)果。這就像讓一個(gè)只能看見(jiàn)自己面前 30 厘米范圍的人去布置一個(gè) 100 平米的房間他擺完第一組沙發(fā)之后根本不知道第二組沙發(fā)該往哪兒挪。而人不是這樣畫(huà)的。人畫(huà)圖的時(shí)候眼睛會(huì)反復(fù)掃描整張圖發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)太靠右了會(huì)往回調(diào)整。這種“全局審視 局部修正”的循環(huán)恰恰是大模型在純文本生成模式下不具備的能力。2.2 Token 成本失控像素級(jí)、元素級(jí)指令消耗太大第二個(gè)痛點(diǎn)是畫(huà)一張稍微復(fù)雜一點(diǎn)的圖Token 消耗會(huì)急劇膨脹。比如你讓 Agent 生成一張包含 20 個(gè)節(jié)點(diǎn)的架構(gòu)圖每個(gè)節(jié)點(diǎn)都有文字標(biāo)簽、邊框顏色、坐標(biāo)位置。如果直接讓 Agent 輸出 SVG每個(gè)元素至少需要 4~8 行 XML 代碼每個(gè)節(jié)點(diǎn)的坐標(biāo)、寬度、高度、字體、顏色、描邊全都要顯式寫(xiě)出來(lái)。20 個(gè)節(jié)點(diǎn)、30 條連線、若干分組標(biāo)簽代碼量輕松上千行。Token 一多出錯(cuò)的概率就指數(shù)級(jí)上升。Model 在生成長(zhǎng)序列的時(shí)候注意力會(huì)逐漸衰減尤其是到了輸出序列的后半段非常容易出現(xiàn)“前面定義一個(gè)變量、后面忘了這個(gè)變量”的情況。更頭疼的是如果生成的 SVG 有語(yǔ)法錯(cuò)誤或者坐標(biāo)不對(duì)你要讓 Agent 自己修它可能把整段代碼重新生成一遍而不是只改動(dòng)有問(wèn)題的那個(gè)節(jié)點(diǎn)。這種“局部問(wèn)題、全局重寫(xiě)”的模式成本高得嚇人。2.3 語(yǔ)義鴻溝描述一個(gè)“漏斗圖”不該等同于描述一堆坐標(biāo)第三個(gè)痛點(diǎn)也是最核心的描述意圖和描述圖形之間存在巨大的語(yǔ)義鴻溝。人跟 Agent 說(shuō)“我要畫(huà)一個(gè)銷(xiāo)售漏斗從訪客到成交四層每層寬度遞減”這是業(yè)務(wù)語(yǔ)義。Agent 接到這個(gè)需求之后需要自己把它翻譯成精確的坐標(biāo)、路徑、樣式——這是圖形語(yǔ)義。一旦中間的翻譯過(guò)程出了問(wèn)題你很難定位是“意圖理解錯(cuò)了”還是“坐標(biāo)算錯(cuò)了”。因?yàn)殄e(cuò)誤的根源是混在一起的。Archify 的做法是把“意圖理解”和“坐標(biāo)計(jì)算”這兩件事完全拆開(kāi)意圖理解Agent 只需要把用戶(hù)需求轉(zhuǎn)化為一個(gè)結(jié)構(gòu)化、類(lèi)型化的 JSON 描述比如“創(chuàng)建一個(gè)漏斗圖四層標(biāo)簽分別是 X、Y、Z、W按順序遞減寬度”。坐標(biāo)計(jì)算交給編譯器去算。編譯器內(nèi)部有布局引擎知道怎么讓四層看起來(lái)均勻、怎么擺放標(biāo)簽不會(huì)重疊、怎么處理特殊字符。這個(gè)拆分邏輯跟傳統(tǒng)軟件工程里的“前后端分離”如出一轍——讓專(zhuān)業(yè)的人做專(zhuān)業(yè)的事而 Graph IR 就是那個(gè)“前后端之間的 API 契約”。3. 從“畫(huà)圖工具”到“DSL 編譯器”Archify 的 typed JSON IR 到底是什么Archify 給出的答案是為圖形定義一個(gè)類(lèi)型化的 JSON 中間表示IR約束 Agent 只能輸出 IR再由渲染后端把 IR 編譯成 SVG/Canvas。3.1 先搞明白 typed JSON IR 這個(gè)名詞把 “typed JSON IR” 拆開(kāi)看JSON不用解釋了數(shù)據(jù)交換的事實(shí)標(biāo)準(zhǔn)Agent 和編譯器都能輕松處理。IRIntermediate Representation中間表示這是一個(gè)編譯器術(shù)語(yǔ)。編譯器不會(huì)把 C 語(yǔ)言直接翻譯成機(jī)器碼中間會(huì)先翻譯成一種“既保留程序結(jié)構(gòu)、又去除語(yǔ)法噪音”的中間形式。Archify 把 IR 這個(gè)概念借過(guò)來(lái)了——它不是讓 Agent 直接畫(huà)圖而是讓 Agent 先寫(xiě)一份“關(guān)于圖的中間表示”再由編譯器二次處理。typed JSON這里的 typed 是重點(diǎn)。不是所有 JSON 都叫 typed JSON。Archify 的 IR 在 JSON schema 層面做了很強(qiáng)的約束。每個(gè)節(jié)點(diǎn)必須有指定的 type 字段比如mermaid、flowchart、actor不同的 type 有不同的必填字段編譯器在解析的時(shí)候會(huì)做嚴(yán)格的類(lèi)型校驗(yàn)。結(jié)合來(lái)看Archify 的 typed JSON IR 本質(zhì)上是一種DSLDomain-Specific Language領(lǐng)域特定語(yǔ)言只不過(guò)它不是給人類(lèi)設(shè)計(jì)的 DSL而是為 Agent 和編譯器之間設(shè)計(jì)的一種“協(xié)議語(yǔ)言”。3.2 Archify IR 的兩種表達(dá)方式Mermaid 優(yōu)先代碼塊兜底Archify 的 IR 實(shí)際落地時(shí)支持兩種表達(dá)方式我建議都了解一下因?yàn)槟憬拥?Agent 不一樣熟悉的東西不一樣選錯(cuò)方式會(huì)導(dǎo)致接入成本高出好幾倍。表達(dá)方式描述適用場(chǎng)景Mermaid DSL讓 Agent 輸出標(biāo)準(zhǔn)化 Mermaid 語(yǔ)法Archify 解析后整體轉(zhuǎn)換為圖形Agent 親近文本 DSL生成簡(jiǎn)單流程圖和時(shí)序圖時(shí)比較穩(wěn)代碼塊包裹 IRAgent 輸出 JSON IR 代碼塊由 Archify 的解析器讀取并渲染需要強(qiáng)類(lèi)型校驗(yàn)、更精細(xì)控制節(jié)點(diǎn)屬性和坐標(biāo)計(jì)算時(shí)更合適Mermaid 大家應(yīng)該不陌生是一種很流行的文本圖表 DSL。它的好處是語(yǔ)法相對(duì)簡(jiǎn)單Agent 生成起來(lái)不容易崩。Archify 把它納入 IR 體系相當(dāng)于給 Mermaid 套了一層標(biāo)準(zhǔn)化的殼。而代碼塊包裹 IR適合對(duì)圖形細(xì)節(jié)要求更高的場(chǎng)景。例如你需要給某個(gè)節(jié)點(diǎn)自定義一個(gè)特殊邊框樣式、需要控制節(jié)點(diǎn)之間的相對(duì)位置這時(shí) Mermaid 的表達(dá)能力不夠JSON IR 就能接管。我自己實(shí)測(cè)下來(lái)Mermaid 路線適合 80% 的常規(guī)業(yè)務(wù)圖表流程圖、時(shí)序圖、甘特圖JSON IR 路線適合需要精細(xì)控制布局的高級(jí)場(chǎng)景。Archify 兩種都支持這給了接入手冊(cè)很大的自由度。3.3 IR 代碼長(zhǎng)什么樣來(lái)一段真實(shí)的示例為了讓你有一個(gè)直觀感受這里給出一個(gè)非常簡(jiǎn)單的 Archify IR 示例。假設(shè)我要畫(huà)一個(gè)兩個(gè)節(jié)點(diǎn)、一條邊的流程圖輸入文本{ schema: archify/flowchart, version: 1.0, type: flowchart, direction: LR, nodes: [ { id: a, label: 用戶(hù)輸入, type: process }, { id: b, label: 系統(tǒng)處理, type: process } ], edges: [ { from: a, to: b, label: 提交 } ] }你發(fā)現(xiàn)沒(méi)有這份 JSON 里沒(méi)有出現(xiàn)任何一個(gè)“坐標(biāo)值”。沒(méi)有x、y、width、height。它描述的是圖的結(jié)構(gòu)而不是圖的像素。這意味著什么意味著 Agent 的任務(wù)從“精確計(jì)算每個(gè)元素的位置”變成了“精確描述元素之間的關(guān)系”。后者對(duì)語(yǔ)言模型來(lái)說(shuō)友好太多了。坐標(biāo)計(jì)算、排布優(yōu)化、連線避障這些事情全部由編譯器在渲染階段自動(dòng)完成。這也是為什么 Archify 能將這些任務(wù)從 GPT-4o 等多模態(tài)模型中高效剝離出來(lái)——用公共的、確定性的算法去替代不確定的、高成本的模型推理。3.4 為什么不能直接用現(xiàn)成的 Graphviz 或 D3 庫(kù)你可能會(huì)有個(gè)疑問(wèn)畫(huà)圖編譯器Graphviz 不是一直干這事嗎D3.js 也可以做布局計(jì)算啊為什么 Archify 要大費(fèi)周章造一個(gè) IR我的理解是Graphviz 和 D3 并不服務(wù)于同一個(gè)“用戶(hù)”Graphviz 是為技術(shù)人員設(shè)計(jì)的它接受 DOT 語(yǔ)言功能很強(qiáng)但它的布局風(fēng)格偏“工程感”想要做出好看的現(xiàn)代圖表需要配置很多東西。D3.js 其實(shí)不算編譯器它是一個(gè)渲染工具庫(kù)布局算法也得你自己寫(xiě)。Agent 用 D3 畫(huà)圖就相當(dāng)于讓一個(gè)沒(méi)有圖形學(xué)基礎(chǔ)的人去調(diào)一個(gè)底層 API——可以做但特別容易出邊界問(wèn)題。Graphviz 和 D3 的定位是“面向人類(lèi)的工具”。Archify 的定位則完全不同它是“面向 Agent 的工具”。它要解決的核心問(wèn)題不是“人用起來(lái)順不順手”而是“模型生成起來(lái)穩(wěn)不穩(wěn)定”。IR 的設(shè)計(jì)核心就是讓模型的輸出空間被強(qiáng)約束在一個(gè)很窄的、類(lèi)型安全的范圍內(nèi)——這就是 typed JSON IR 的意義。4. 編譯器設(shè)計(jì)的靈魂P(guān)ipeline 的每個(gè)階段都在解決哪個(gè) Agent 毛病Archify 既然把自己定位成“編譯器”那么它肯定是有一條編譯管線的。我研究它的設(shè)計(jì)之后把它拆成了四個(gè)階段每個(gè)階段直接對(duì)應(yīng)我們要消除的 Agent 問(wèn)題。4.1 詞法分析與語(yǔ)法分析用強(qiáng)制 schema 鎖死輸出格式編 譯 器 的第一個(gè)階段是詞法分析和語(yǔ)法分析。對(duì)于 Archify 來(lái)說(shuō)就是給 Agent 的輸出做一次嚴(yán)格的全身體檢。Agent 生成的 IR 如果沒(méi)有通過(guò) JSON Schema 校驗(yàn)比如nodes字段里缺了id、type寫(xiě)錯(cuò)了、edges引用了不存在的節(jié)點(diǎn) ID這個(gè) IR 就會(huì)被打回要求重新生成。這一步的操作價(jià)值在于把很多原本要在渲染階段才能發(fā)現(xiàn)的錯(cuò)誤提前到了生成階段攔截掉。渲染階段出錯(cuò)你要面對(duì)的是用戶(hù)對(duì)著一張爛圖的困惑生成階段攔截掉你只需要讓 Agent 重新生成一份 JSON。而且強(qiáng)制 schema 校驗(yàn)還有一個(gè)隱藏好處它可以有效減少 Agent 幻覺(jué)。當(dāng) Agent 知道它的輸出會(huì)經(jīng)過(guò)嚴(yán)格的機(jī)器校驗(yàn)而且不合格會(huì)被退回模型會(huì)傾向于生成更保守、更符合格式預(yù)期的內(nèi)容。這種“格式約束 失敗反饋”的組合是當(dāng)前階段讓大模型真正靠譜起來(lái)的重要手段。4.2 語(yǔ)義分析與中間代碼生成把“業(yè)務(wù)意圖”拆成“圖形原子”過(guò)了語(yǔ)法層校驗(yàn)編譯器進(jìn)入第二個(gè)階段語(yǔ)義分析。這一階段的輸入是結(jié)構(gòu)合法的指令列表輸出是經(jīng)過(guò)類(lèi)型檢查、屬性補(bǔ)全后帶具體語(yǔ)義的指令項(xiàng)。Archify 中會(huì)對(duì) IR 中的每個(gè)節(jié)點(diǎn)和邊做類(lèi)型檢查如果發(fā)現(xiàn)某個(gè)節(jié)點(diǎn)引用了不存在的組件類(lèi)型或某個(gè)邊的屬性不匹配箭頭語(yǔ)義編譯器就會(huì)中斷并返回錯(cuò)誤信息。這一步非常關(guān)鍵的地方在于它干的活是把一個(gè)“業(yè)務(wù)層需求”翻譯成“圖形層元素”。拿我們之前的銷(xiāo)售漏斗例子來(lái)說(shuō)業(yè)務(wù)層輸入是我要畫(huà)一個(gè)四層銷(xiāo)售漏斗從訪客到成交。編譯器做的是確定四個(gè)階段節(jié)點(diǎn)、確定連線方向、計(jì)算每層寬度比例、生成mermaid或 SVG 需要的具體語(yǔ)句。這里就是“編譯器”和“模板引擎”的分水嶺。模板引擎是死板的輸入格式稍有偏差就罷工編譯器是有層級(jí)、有抽象能力的它可以在前面兩層就把輸入固定成明確的、可控的格式——這正是“typed”帶來(lái)的優(yōu)勢(shì)。4.3 布局與渲染后端坐標(biāo)交給算法樣式統(tǒng)一輸出當(dāng) IR 被校驗(yàn)通過(guò)、語(yǔ)義檢查完成編譯器就要進(jìn)入“生成目標(biāo)代碼”階段了。這里的“目標(biāo)代碼”可能是 Mermaid 源碼也可能是 SVG 代碼。Archify 在這個(gè)階段真正讓人省心的地方是布局引擎幫我們處理了最耗心力的坐標(biāo)計(jì)算。比如在流程圖中Agent 只需要聲明“節(jié)點(diǎn) A 指向節(jié)點(diǎn) B”編譯器自動(dòng)計(jì)算這條連線從 A 的右側(cè)出、彎折兩次、從 B 的左側(cè)入并確保不穿過(guò)其他節(jié)點(diǎn)。這種避障計(jì)算對(duì)Agent來(lái)說(shuō)很難每次生成都有概率失敗但算法來(lái)做幾乎是確定性的。出了坐標(biāo)之外編譯器還會(huì)統(tǒng)一樣式比如統(tǒng)一的節(jié)點(diǎn)圓角、統(tǒng)一的配色體系。這樣做的好處是不是讓圖“好看”這么膚淺而是保證輸出風(fēng)格的一致性。同一份 IR不管是誰(shuí)來(lái)觸發(fā)編譯出來(lái)的圖都維持同樣的品牌調(diào)性這很符合企業(yè)級(jí)應(yīng)用的需求。4.4 類(lèi)型系統(tǒng)收尾最大化可組合性最小化運(yùn)行時(shí)錯(cuò)誤最后這個(gè)階段的類(lèi)型體系在整個(gè) IR 設(shè)計(jì)里是畫(huà)龍點(diǎn)睛的存在。typed JSON IR 的“typed”在項(xiàng)目里不是一句口號(hào)而是真的把系統(tǒng)里所有元素分成有限類(lèi)型集合比如flowchart類(lèi)型管理節(jié)點(diǎn)和邊有嚴(yán)格的方向約束。sequence類(lèi)型管理參與者、激活條、消息箭頭。gantt類(lèi)型管理任務(wù)、開(kāi)始日期、持續(xù)天數(shù)、依賴(lài)關(guān)系。component類(lèi)型管理組件層級(jí)和組合關(guān)系。每種類(lèi)型在 schema 層面定義了必填字段和可選字段編譯器根據(jù)類(lèi)型執(zhí)行不同的校驗(yàn)邏輯和布局邏輯。這種嚴(yán)格分類(lèi)帶來(lái)的直接收益是可組合性。因?yàn)轭?lèi)型是預(yù)定義好的、經(jīng)過(guò)校驗(yàn)的下游的渲染器、樣式引擎、導(dǎo)出工具都可以基于這些類(lèi)型做標(biāo)準(zhǔn)化處理不需要像老式模板那樣針對(duì)每一種可能的字段組合寫(xiě)特判代碼。跑完這一整套 PipelineAgent 的輸出才能從“像一張圖的東西”變成了“真正結(jié)構(gòu)正確、穩(wěn)定可復(fù)用的圖形”。5. 為什么這套思路值得抄進(jìn)你自己的 Agent 項(xiàng)目里Archify 這個(gè)名字并不只是給你一個(gè)“畫(huà)圖更好看”的庫(kù)。我認(rèn)為它最大的價(jià)值是給所有做 Agent 工具鏈的人提供了一個(gè)范式參考——當(dāng)模型能力達(dá)到上限時(shí)如何用一個(gè)工具去補(bǔ)齊它。5.1 三個(gè)直接的業(yè)務(wù)收益Token 成本、穩(wěn)定性和可緩存性如果你自己搭的是繪圖 Agent引入 Archify 之后最直觀的三個(gè)收益是收益一Token 成本明顯下降。Agent 不用再輸出上千行 SVG 代碼只需要輸出幾十行 JSON IR。我做過(guò)一個(gè)粗糙的對(duì)比測(cè)試畫(huà)同一張 15 節(jié)點(diǎn)的架構(gòu)圖直接用 SVG 大約消耗 3200 tokens用 Archify IR 加 Mermaid 渲染只消耗 900 tokens 左右節(jié)省了 70% 以上。收益二輸出穩(wěn)定性大幅提升。我連續(xù)讓同一個(gè) Agent 畫(huà)同一張圖 10 次直接輸出 SVG 時(shí)有 3 次出現(xiàn)了渲染錯(cuò)位或標(biāo)簽重疊。用 Archify IR 后10 次全部生成正確而且最終效果完全一致。這種穩(wěn)定性對(duì)于面向用戶(hù)的產(chǎn)品級(jí)應(yīng)用來(lái)說(shuō)價(jià)值極大。收益三結(jié)果可緩存。因?yàn)?IR 是一個(gè)純 JSON 結(jié)構(gòu)它可以跟任何緩存系統(tǒng)友好共存。比如 Agent 根據(jù)同樣的需求生成了同一份 IR你可以直接走緩存不需要重復(fù)調(diào)用模型省下時(shí)間和費(fèi)用。這部分對(duì)高頻場(chǎng)景的影響會(huì)在下一節(jié)單獨(dú)展開(kāi)。5.2 不止畫(huà)圖Archify 的“編譯器”思路能遷移到哪些 Agent 場(chǎng)景Archify 的 IR 設(shè)計(jì)看著是畫(huà)圖專(zhuān)用的但它的范式可以遷移到很多鄰近領(lǐng)域。我舉幾個(gè)我實(shí)際看過(guò)或試過(guò)的例子AI 生成演示文稿PPT/Slides。PPT 的核心難點(diǎn)跟畫(huà)圖一模一樣——元素多、依賴(lài)關(guān)系強(qiáng)、對(duì)布局要求高。你讓 Agent 直接生成一個(gè)帶動(dòng)畫(huà)的 PPT 文件它大概率會(huì)瘋。但如果定義一套slide IR規(guī)定每頁(yè)有哪幾種類(lèi)型的元素標(biāo)題、正文、圖片、圖表并讓編譯器統(tǒng)一處理排版和分頁(yè)P(yáng)PT 生成就會(huì)從“一次賭運(yùn)氣”變成“結(jié)構(gòu)化流水線”。目前很多開(kāi)源 PPT Agent走的就是這條路線。AI 生成網(wǎng)站落地頁(yè)。和 PPT 同理。與其讓 Agent 直接輸出整段 HTML/CSS不如定義一套page IR描述區(qū)塊結(jié)構(gòu)、內(nèi)容層級(jí)、樣式 token再讓編譯器把它們編譯成響應(yīng)式頁(yè)面。好處同樣是布局交給算法內(nèi)容交給模型各干各的活出錯(cuò)概率大減。AI 生成數(shù)據(jù)分析報(bào)告。報(bào)告比純圖表多一層復(fù)雜性——一張圖怎么配一段解釋文字圖表之間的數(shù)據(jù)口徑怎么保持一致。你可以定義report IR把圖表、文字、結(jié)論、數(shù)據(jù)源全部結(jié)構(gòu)化再交由編譯器統(tǒng)一渲染。這種方案能讓數(shù)據(jù)分析 Agent 的輸出質(zhì)量上一個(gè)臺(tái)階。5.3 緩存友好性為什么 Agent 生態(tài)遲早都會(huì)走到 IR 這一步最后我想專(zhuān)門(mén)聊一下 IR 和緩存結(jié)合的問(wèn)題。這是我覺(jué)得 Archify 設(shè)計(jì)里最小但最容易被忽略的亮點(diǎn)。Agent 推理是有成本的。用一次模型就消耗一次錢(qián)和時(shí)間。如果能讓 Agent 在做“類(lèi)似的事”時(shí)復(fù)用上一次的結(jié)果成本就會(huì)直線下降。而 IR 恰好是一種適合做復(fù)用鍵cache key的中間形態(tài)。做緩存通常遵循三個(gè)原則結(jié)果要穩(wěn)定同樣的輸入最好產(chǎn)生同樣的輸出。結(jié)構(gòu)要可比兩個(gè)結(jié)果之間容易判斷“相不相等”。錯(cuò)誤要隔離緩存某個(gè)環(huán)節(jié)出錯(cuò)不會(huì)影響其他環(huán)節(jié)。Agent 直接輸出 SVG每次生成的代碼都可能不同——即便意思是相同的字符串層面也會(huì)有差異導(dǎo)致緩存命中率極低。而 IR 是結(jié)構(gòu)化的 JSONAgent 生成的結(jié)構(gòu)只要含義相同基本可以規(guī)范化成一個(gè)一樣的 key加上接近階段的結(jié)果做校驗(yàn)后命中率非常高。這一步帶來(lái)的運(yùn)維收益直接反映在成本結(jié)構(gòu)上。5.4 接入你自己的 Agent動(dòng)手實(shí)操 Archify 的三種路徑根據(jù)你手上的技術(shù)棧和 Agent 框架接入 Archify 的方式可以分成三種按接入難度從低到高排列。路徑一Mermaid 優(yōu)先最省事如果你當(dāng)前使用的 Agent 已經(jīng)能生成 Mermaid 代碼那你可以直接把 Archify 當(dāng)作一個(gè) Mermaid 渲染后端。Agent 輸出 Mermaid 源碼你調(diào)用 Archify 的渲染接口把文本變成可用圖片或 HTML 組件。這種方式幾乎不改造 Agent 本身的邏輯只需要在輸出端加一層適配器。適合現(xiàn)有 Agent 已經(jīng)比較穩(wěn)定、不想動(dòng)核心 Prompt 的團(tuán)隊(duì)。路徑二JSON IR 優(yōu)先推薦如果你正在從零構(gòu)建一個(gè)新的繪圖 Agent我強(qiáng)烈建議你從第一天就讓它輸出 JSON IR。你在 Prompt 里給 Agent 一個(gè) JSON Schema讓它嚴(yán)格按照 schema 輸出一個(gè)code block然后你解析這個(gè) block交給 Archify 渲染。這種方式的核心變動(dòng)是 Prompt 工程不再告訴 Agent “你要畫(huà)一個(gè)流程圖”而是告訴它 “你要構(gòu)造一個(gè) flowchart 類(lèi)型的 IR結(jié)構(gòu)如下……”。語(yǔ)言模型對(duì)這種明確的 JSON schema 指令的遵從度遠(yuǎn)高于對(duì)“畫(huà)得好看一點(diǎn)”這種模糊指令的遵從度。路徑三自建編譯器最高自由度如果你是個(gè)控制欲很強(qiáng)、愿意折騰的開(kāi)發(fā)者也可以參考 Archify 的架構(gòu)自建一套適合你業(yè)務(wù)場(chǎng)景的編譯器。這里的核心工作是定義 tokens、AST 節(jié)點(diǎn)類(lèi)型和你自己的 IR schema再寫(xiě)一個(gè)布局引擎或直接嵌入一個(gè)布局算法。適合業(yè)務(wù)場(chǎng)景很垂直且市面上沒(méi)有現(xiàn)成方案的情況。不過(guò)自己造輪子之前建議先在 Archify 里認(rèn)真跑幾個(gè) case。等到你真的踩到它的邊界再?zèng)Q定要不要自研也不遲。6. 35k Stars 與社區(qū)生態(tài)為什么“結(jié)果可驗(yàn)證”比“功能多”更值錢(qián)最后我想聊聊 Archify 憑什么能拿到 35k Stars。對(duì)于一個(gè)相對(duì)垂直的 Agent 工具來(lái)說(shuō)這個(gè)數(shù)據(jù)相當(dāng)亮眼。我認(rèn)為核心原因有幾個(gè)簡(jiǎn)單梳理一下第一個(gè)原因Archify 讓你對(duì) Agent 的輸出“看得見(jiàn)、摸得著、驗(yàn)得對(duì)”。以前 Agent 畫(huà)圖輸出是一大段代碼你沒(méi)法快速判斷它對(duì)不對(duì)得拿去跑一遍看效果。而 Archify 的 IR 是結(jié)構(gòu)化的你可以像檢查一份有 type 限制的配置或 schema 一樣去檢查它。肉眼掃一遍基本就能判斷這個(gè) IR 的節(jié)點(diǎn)關(guān)系是否符合邏輯。這種可驗(yàn)證性是把大模型從“黑魔法”變成“工程工具”的關(guān)鍵一步。第二個(gè)原因Archify 選了一個(gè)非常準(zhǔn)確的賽道切入——AI 生成圖形的“布局痛點(diǎn)”。你可以說(shuō) Archify 沒(méi)有自己的布局引擎也沒(méi)有自己發(fā)明的圖形語(yǔ)法它更像是一個(gè)“膠水層”和“協(xié)議層”。但從用戶(hù)角度來(lái)說(shuō)它提供了一種“確定性”把整個(gè)鏈路中最大那塊不確定部分交給了可靠的后端去完成天然能被社區(qū)認(rèn)可。第三個(gè)原因也是我想重點(diǎn)強(qiáng)調(diào)的——它的設(shè)計(jì)哲學(xué)呼應(yīng)了 Agent 基礎(chǔ)設(shè)施的演進(jìn)方向。你現(xiàn)在去看開(kāi)源社區(qū)里活躍的 Agent 框架、函數(shù)庫(kù)、工具集會(huì)發(fā)現(xiàn)大家都在往同一個(gè)方向使勁把調(diào)用模型的過(guò)程抽象成可約束的工具把模型的結(jié)果從不可預(yù)測(cè)變成可預(yù)測(cè)。在這方面Archify 提供的不只是繪圖能力更是一個(gè)“如何為 Agent 定義一種協(xié)議、如何構(gòu)造中間表示來(lái)嵌入流程”的絕佳案例。你在自己的項(xiàng)目里遇到過(guò)什么跟 Agent 繪圖相關(guān)的問(wèn)題嗎或者你也在嘗試自定義 IR歡迎帶著自己的看法來(lái)交流一起踩坑一起找方案——開(kāi)源世界的迷人之處常常也因此展開(kāi)。