機制)
Strix 沙箱視覺能力解析view_image 工具的加載原理、截圖工作流與容錯恢復(fù)機制【免費下載鏈接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.項目地址: https://gitcode.com/GitHub_Trending/strix/strix本文面向想要理解 Strix 安全掃描 Agent 如何看見瀏覽器截圖的技術(shù)讀者深入剖析 SDK 內(nèi)建view_image工具在沙箱中的定位、接線方式、截圖默認目錄約定、實戰(zhàn)調(diào)用鏈以及當視覺模型不支持或拒絕圖像輸入時Strix 內(nèi)置的自動剝離與恢復(fù)機制。讀完你既能上手完成截圖→查看→理解的完整鏈路也能讀懂源碼中每一環(huán)的設(shè)計用意。view_image 是什么為視覺模型輸送圖像內(nèi)容的沙箱工具view_image不是 Strix 自行實現(xiàn)的工具而是上游agentsSDK 提供的能力。在 strix/tools/view_image/README.md 中對其定義如下SDK-provided tool that loads an image from the sandbox workspace and returns it as an image content block for vision-capable models.拆開看有三個關(guān)鍵點來源是沙箱工作區(qū)它只能加載 sandbox 工作區(qū)內(nèi)的圖片文件天然限定在掃描容器可訪問的范圍內(nèi)產(chǎn)出是 image content block調(diào)用結(jié)果會被打包成對話中的input_image內(nèi)容塊直接進入模型上下文消費方必須是視覺模型只有支持 vision 的模型如具備圖像輸入能力的多模態(tài)大模型才能理解這個內(nèi)容塊純文本模型會拒收并觸發(fā)后續(xù)的容錯流程見下文。為什么需要這樣一個工具Strix 的安全掃描依賴 agent-browser基于 headless Chromium 的瀏覽器自動化 CLI來做 Web 交互式測試。瀏覽器交互中大量信息只有看見像素才能判斷頁面視覺布局是否符合預(yù)期、驗證碼圖形、自定義控件其可訪問性樹不完整等。但關(guān)鍵約束在 skill 文檔中寫得很直白agent_browser.mdagent-browser screenshotwrites a PNG to disk in the sandbox. The shell command alone doesnotput the image into your context — chain it with the SDKview_imagetool to actually see it.也就是說截圖命令只負責把 PNG 寫到磁盤把圖片送入模型上下文的唯一途徑是view_image。二者是同一流程中不可互相替代的兩環(huán)這正是view_image在 Strix 工具棧中的核心價值——它充當磁盤文件 → 模型視覺上下文的橋。接線方式隨 Filesystem 能力在每次運行時注入view_image并非常駐的基礎(chǔ)工具集成員而是通過 SDK 的Filesystemcapability 在構(gòu)建 agent 時動態(tài)裝配。源碼位置在 strix/agents/factory.pyreturn SandboxAgent( namename, instructionsinstructions, toolstools, tool_use_behavior_finish_tool_use_behavior, modelNone, capabilities[ Filesystem( configure_tools_make_filesystem_configurator( chat_completionschat_completions_tools, strict_schemasstrict_tool_schemas, ), ), Shell( configure_tools_make_shell_configurator( chat_completionschat_completions_tools, strict_schemasstrict_tool_schemas, ), ), ], )build_strix_agent在工廠模塊的 factory.py 中定義root agent 與子 agentchild agent都走同一構(gòu)建路徑因此每次運行的每一個沙箱 Agent 都會獲得Filesystem能力view_image隨之注入。值得留意的是裝配細節(jié)_make_filesystem_configurator返回的 configure 回調(diào)會對 filesystem 工具集做統(tǒng)一包裝factory.py其行為取決于目標后端路由chat_completions 路徑SDK 的CustomTool會被包成FunctionTool_custom_tool_as_function_tool并加_function_tool_with_error_result—— 工具拋出的異常會以文本錯誤形式返回給模型而不是中斷會話Responses / 原生路徑CustomTool走_bound_custom_tool結(jié)果上限封裝兩條路徑都會統(tǒng)一施加_with_coerced_arguments參數(shù)類型矯正包括 JSON 數(shù)組/對象字符串解碼與_with_strictness。這套包裝層對view_image的直接影響是它享受與 Strix 自定義工具一致的參數(shù)矯正、結(jié)果尺寸上限context.tool_output_max_lines/tool_output_max_bytes見 factory.py與錯誤轉(zhuǎn)文本策略。這也是為什么 SDK 原生工具能在 Strix 的統(tǒng)一工具治理模型下工作。Strix 默認約定截圖的落盤目錄與容器級配置view_image讀取的圖片通常由 agent-browser 截圖產(chǎn)生Strix 在容器鏡像層面就把兩者的默認目錄約定固化了下來1. Dockerfile 聲明環(huán)境變量containers/Dockerfile 中設(shè)置了一組AGENT_BROWSER_*環(huán)境變量ENV AGENT_BROWSER_EXECUTABLE_PATH/usr/bin/chromium ENV AGENT_BROWSER_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 ENV AGENT_BROWSER_ARGS--disable-blink-featuresAutomationControlled,--no-first-run,--no-default-browser-check,--langen-US ENV AGENT_BROWSER_SCREENSHOT_DIR/workspace/.agent-browser-screenshots ENV AGENT_BROWSER_IDLE_TIMEOUT_MS180000其中與本文最相關(guān)的是AGENT_BROWSER_SCREENSHOT_DIR/workspace/.agent-browser-screenshots——它把 agent-browser 的默認截圖輸出目錄固定在/workspace沙箱根之內(nèi)。這些變量隨后被寫入/etc/profile.d/agent-browser.sh容器內(nèi)各 shell 會話登錄即可繼承。2. entrypoint 在容器啟動時創(chuàng)建目錄containers/docker-entrypoint.sh 在每次容器啟動時執(zhí)行mkdir -p /workspace/.agent-browser-screenshots保證目錄必然存在截圖命令可直接落盤。3. 為什么目錄必須落在/workspace內(nèi)skill 文檔在 agent_browser.md 中給出了一條硬性約束Default output directory is/workspace/.agent-browser-screenshots/, whichview_imagecan read. ... Never write screenshots to/tmp—view_imagerejects anything outside the workspace root.即view_image會拒絕工作區(qū)根workspace root之外的路徑例如/tmp下的文件無法被讀取。這既是沙箱邊界的體現(xiàn)也是安全設(shè)計的必然——工具的能力被限定在掃描容器自己的工作區(qū)內(nèi)。實戰(zhàn)工作流兩段式調(diào)用讓模型真正看到頁面在 agent_browser.md 的 Skill 文檔中截圖的推薦姿勢是先截圖拿到路徑、再把路徑交給view_imageexec_command: agent-browser screenshot view_image: {path: path printed on stdout}screenshot 命令的常用形態(tài)agent-browser screenshot # 無參形式路徑打印到 stdout agent-browser screenshot /workspace/.agent-browser-screenshots/page.png # 顯式指定文件名 agent-browser screenshot --full # 整頁滾動高度截圖 agent-browser screenshot --annotate # 編號標注 與 snapshot ref 對應(yīng)的圖例實踐要點優(yōu)先無參形式CLI 會把完整路徑打印到 stdout將 stdout 輸出的路徑原樣傳給view_image即可避免路徑拼接出錯自定義文件名需守規(guī)矩若需指定文件名應(yīng)放在默認截圖目錄或/workspace下同級的隱藏目錄中絕不能寫到/tmp--annotate專為多模態(tài)模型設(shè)計每個標注[N]對應(yīng)快照snapshot中的 refeN。先拍標注截圖再用view_image查看就能把視覺布局與快照 DOM 結(jié)構(gòu)兩張視圖關(guān)聯(lián)起來——例如定位某個可疑按鈕時視覺上對應(yīng)哪個 DOM 節(jié)點一目了然見 agent_browser.md。Token 成本意識先快照、必要時才像素skill 文檔明確給出了成本提示agent_browser.mdSnapshots (snapshot -i) give you a compact text view that costs ~200-400 tokens; screenshots cost more. Usesnapshotfirst; reach forscreenshot view_imageonly when you actually need pixels.推薦策略是優(yōu)先用文本形態(tài)的snapshot -i獲取 DOM 概覽只有遇到視覺布局、驗證碼、可訪問性樹不完整的自定義控件等真正需要像素的問題時才動用screenshot view_image。這從根上控制多模態(tài)內(nèi)容的上下文開銷。文本模型的降級路徑skill 文檔也寫明了view_image的失敗語義agent_browser.mdIfview_imageerrors back at you (rejected image, vision not supported, or similar), you are running on a text-only model — stop calling it and stop taking screenshots.一旦view_image返回拒絕類錯誤說明當前模型不支持視覺輸入Agent 應(yīng)當停止截圖與view_image調(diào)用完全改用snapshot -i的 ref、eval讀取任何需要的 DOM/JS 狀態(tài)與text ref/get text做內(nèi)容抽取。這套降級說明被寫進了 skill 提示詞模型在遇到報錯時能據(jù)此自糾正。渲染落地截圖在 TUI 與 Viewer 中的呈現(xiàn)view_image的結(jié)果不僅在模型上下文生效也會被 Strix 的兩套人機界面消費保證人類審計者與 Agent 看到同一畫面。終端 TUI在 strix/interface/tui/internal/render/registry.go 中view_image被路由到專門渲染器case view_image: return renderViewImage(args, result)其實現(xiàn)位于 strix/interface/tui/internal/render/image.go。該渲染器會從view_image的工具結(jié)果中抽取 base64 圖像負載extractImageDataURI并在終端能力允許時借助Kitty graphics protocol直接內(nèi)聯(lián)顯示圖像占位/預(yù)覽。對應(yīng)測試 strix/interface/tui/internal/render/image_kitty_test.go 驗證了兩種分支支持 Kitty 時渲染占位符、不支持時TestViewImageWithoutKittySupportShowsNoPreview則不做圖像預(yù)覽。由此可推斷TUI 的圖像呈現(xiàn)能力是檢測到終端協(xié)議才啟用的自適應(yīng)設(shè)計而非依賴固定終端類型。Web Viewer在前端側(cè)ViewImageRenderer.tsx 負責把view_image的返回結(jié)果渲染為內(nèi)聯(lián)圖片其在工具注冊表中的歸屬也印證了它是 SDK filesystem 家族成員——index.ts 把apply_patch、view_image、str_replace_editor、list_files、search_files一并歸入filesystem分組。容錯機制視覺拒絕的自動恢復(fù)與上下文預(yù)算view_image輸出的是圖像內(nèi)容塊體積大且不是所有模型都支持。Strix 在運行層內(nèi)置了兩道防線拒收自動剝離與上下文圖像預(yù)算。二者的實現(xiàn)主體都位于 strix/core/sessions.py。場景一模型拒收圖像輸入自動恢復(fù)多模態(tài)場景下模型/供應(yīng)商可能因「vision not supported」等原因直接拒絕包含圖像的輸入。執(zhí)行循環(huán)在 strix/core/execution.py 中捕獲到這類異常時啟動恢復(fù)except Exception as exc: if ( image_strips 3 and session is not None and getattr(exc, status_code, None) in _INPUT_REJECTION_CODES ): try: stripped await strip_all_images_from_session(session) ... if stripped: image_strips 1 ... input_data [] continue其中_INPUT_REJECTION_CODES frozenset({400, 404, 422})execution.py最多執(zhí)行3 次圖像剝離后重試image_strips 3。strip_all_images_from_session的具體實現(xiàn)見 sessions.py遍歷會話條目把每個含圖像的工具輸出替換為文本占位符_IMAGE_REJECTED_TEXT [image rejected by the model]替換邏輯是塊級、保兄弟的_elided_output只把output列表中type input_image的塊換成文本塊同一條function_call_output里其他文本塊原樣保留sessions.py。判定函數(shù)_output_has_image則專門匹配function_call_output且其 output 列表中含input_image塊的條目sessions.py。所有會話改寫都在session_write_lock寫鎖內(nèi)以讀-改-寫方式進行失敗時恢復(fù)原條目sessions.py避免在 Agent 并發(fā)寫會話時互相覆蓋。整個恢復(fù)流程的效果是視覺模型不可用時掃描不會中斷——圖像被文本占位符替代后會話繼續(xù)推進Agent 轉(zhuǎn)入純文本驅(qū)動模式。場景二上下文圖像預(yù)算裁剪即使模型支持視覺大量截圖也會撐爆上下文。執(zhí)行循環(huán)在每輪開跑前按上下文配置執(zhí)行圖像預(yù)算execution.pymax_images context.get(max_context_images) if isinstance(max_images, int): try: await enforce_image_budget(session, max_images) ...enforce_image_budgetsessions.py只保留最近max_images張圖像輸出更早的截圖被替換為提示文本_IMAGE_ELIDED_TEXT [older screenshot elided to bound context memory]從而把多模態(tài)內(nèi)容對上下文的占用控制在預(yù)算內(nèi)同時保留最近的視覺狀態(tài)供模型引用。場景三繼承上下文中的圖像脫敏當子 Agent 需要繼承父級上下文時圖像不會盲目拷貝。scrub_images_from_itemssessions.py遞歸掃描輸入條目把每個input_image塊替換成_INHERITED_IMAGE_TEXT [screenshot omitted from inherited context]這讓上下文繼承以文本摘要進行避免子 Agent 的上下文被父級的整頁截圖污染。三種占位符文本rejected / elided / omitted各司其職分別對應(yīng)拒收恢復(fù)、預(yù)算裁剪、繼承脫敏三條鏈路從源碼層面看是一個相當完整的圖像上下文治理體系。結(jié)語與延伸閱讀view_image雖只是 SDK 提供的一個小工具卻在 Strix 的視覺閉環(huán)中扮演承上啟下的角色上承 agent-browser 截圖能力把像素送入多模態(tài)模型下接 TUI / Viewer 渲染與上下文治理讓視覺內(nèi)容既可審計又可管理再輔以容器目錄約定與運行層自動恢復(fù)讓視覺能力成為可平滑降級的可選增強項而非掃描的脆弱依賴。想繼續(xù)深入可優(yōu)先閱讀以下文件文檔主體strix/tools/view_image/README.md工具裝配strix/agents/factory.pyFilesystemcapability 注入截圖工作流 Skillstrix/skills/tooling/agent_browser.md容器默認目錄containers/Dockerfile、containers/docker-entrypoint.sh容錯與預(yù)算實現(xiàn)strix/core/sessions.py、調(diào)用點 strix/core/execution.py界面呈現(xiàn)registry.go、ViewImageRenderer.tsx、測試 image_kitty_test.go【免費下載鏈接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.項目地址: https://gitcode.com/GitHub_Trending/strix/strix創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Strix 沙箱視覺能力解析：view_image 工具的加載原理、截圖工作流與容錯恢復(fù)機制
Strix 沙箱視覺能力解析view_image 工具的加載原理、截圖工作流與容錯恢復(fù)機制【免費下載鏈接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.項目地址: https://gitcode.com/GitHub_Trending/strix/strix本文面向想要理解 Strix 安全掃描 Agent 如何看見瀏覽器截圖的技術(shù)讀者深入剖析 SDK 內(nèi)建view_image工具在沙箱中的定位、接線方式、截圖默認目錄約定、實戰(zhàn)調(diào)用鏈以及當視覺模型不支持或拒絕圖像輸入時Strix 內(nèi)置的自動剝離與恢復(fù)機制。讀完你既能上手完成截圖→查看→理解的完整鏈路也能讀懂源碼中每一環(huán)的設(shè)計用意。view_image 是什么為視覺模型輸送圖像內(nèi)容的沙箱工具view_image不是 Strix 自行實現(xiàn)的工具而是上游agentsSDK 提供的能力。在 strix/tools/view_image/README.md 中對其定義如下SDK-provided tool that loads an image from the sandbox workspace and returns it as an image content block for vision-capable models.拆開看有三個關(guān)鍵點來源是沙箱工作區(qū)它只能加載 sandbox 工作區(qū)內(nèi)的圖片文件天然限定在掃描容器可訪問的范圍內(nèi)產(chǎn)出是 image content block調(diào)用結(jié)果會被打包成對話中的input_image內(nèi)容塊直接進入模型上下文消費方必須是視覺模型只有支持 vision 的模型如具備圖像輸入能力的多模態(tài)大模型才能理解這個內(nèi)容塊純文本模型會拒收并觸發(fā)后續(xù)的容錯流程見下文。為什么需要這樣一個工具Strix 的安全掃描依賴 agent-browser基于 headless Chromium 的瀏覽器自動化 CLI來做 Web 交互式測試。瀏覽器交互中大量信息只有看見像素才能判斷頁面視覺布局是否符合預(yù)期、驗證碼圖形、自定義控件其可訪問性樹不完整等。但關(guān)鍵約束在 skill 文檔中寫得很直白agent_browser.mdagent-browser screenshotwrites a PNG to disk in the sandbox. The shell command alone doesnotput the image into your context — chain it with the SDKview_imagetool to actually see it.也就是說截圖命令只負責把 PNG 寫到磁盤把圖片送入模型上下文的唯一途徑是view_image。二者是同一流程中不可互相替代的兩環(huán)這正是view_image在 Strix 工具棧中的核心價值——它充當磁盤文件 → 模型視覺上下文的橋。接線方式隨 Filesystem 能力在每次運行時注入view_image并非常駐的基礎(chǔ)工具集成員而是通過 SDK 的Filesystemcapability 在構(gòu)建 agent 時動態(tài)裝配。源碼位置在 strix/agents/factory.pyreturn SandboxAgent( namename, instructionsinstructions, toolstools, tool_use_behavior_finish_tool_use_behavior, modelNone, capabilities[ Filesystem( configure_tools_make_filesystem_configurator( chat_completionschat_completions_tools, strict_schemasstrict_tool_schemas, ), ), Shell( configure_tools_make_shell_configurator( chat_completionschat_completions_tools, strict_schemasstrict_tool_schemas, ), ), ], )build_strix_agent在工廠模塊的 factory.py 中定義root agent 與子 agentchild agent都走同一構(gòu)建路徑因此每次運行的每一個沙箱 Agent 都會獲得Filesystem能力view_image隨之注入。值得留意的是裝配細節(jié)_make_filesystem_configurator返回的 configure 回調(diào)會對 filesystem 工具集做統(tǒng)一包裝factory.py其行為取決于目標后端路由chat_completions 路徑SDK 的CustomTool會被包成FunctionTool_custom_tool_as_function_tool并加_function_tool_with_error_result—— 工具拋出的異常會以文本錯誤形式返回給模型而不是中斷會話Responses / 原生路徑CustomTool走_bound_custom_tool結(jié)果上限封裝兩條路徑都會統(tǒng)一施加_with_coerced_arguments參數(shù)類型矯正包括 JSON 數(shù)組/對象字符串解碼與_with_strictness。這套包裝層對view_image的直接影響是它享受與 Strix 自定義工具一致的參數(shù)矯正、結(jié)果尺寸上限context.tool_output_max_lines/tool_output_max_bytes見 factory.py與錯誤轉(zhuǎn)文本策略。這也是為什么 SDK 原生工具能在 Strix 的統(tǒng)一工具治理模型下工作。Strix 默認約定截圖的落盤目錄與容器級配置view_image讀取的圖片通常由 agent-browser 截圖產(chǎn)生Strix 在容器鏡像層面就把兩者的默認目錄約定固化了下來1. Dockerfile 聲明環(huán)境變量containers/Dockerfile 中設(shè)置了一組AGENT_BROWSER_*環(huán)境變量ENV AGENT_BROWSER_EXECUTABLE_PATH/usr/bin/chromium ENV AGENT_BROWSER_USER_AGENTMozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36 ENV AGENT_BROWSER_ARGS--disable-blink-featuresAutomationControlled,--no-first-run,--no-default-browser-check,--langen-US ENV AGENT_BROWSER_SCREENSHOT_DIR/workspace/.agent-browser-screenshots ENV AGENT_BROWSER_IDLE_TIMEOUT_MS180000其中與本文最相關(guān)的是AGENT_BROWSER_SCREENSHOT_DIR/workspace/.agent-browser-screenshots——它把 agent-browser 的默認截圖輸出目錄固定在/workspace沙箱根之內(nèi)。這些變量隨后被寫入/etc/profile.d/agent-browser.sh容器內(nèi)各 shell 會話登錄即可繼承。2. entrypoint 在容器啟動時創(chuàng)建目錄containers/docker-entrypoint.sh 在每次容器啟動時執(zhí)行mkdir -p /workspace/.agent-browser-screenshots保證目錄必然存在截圖命令可直接落盤。3. 為什么目錄必須落在/workspace內(nèi)skill 文檔在 agent_browser.md 中給出了一條硬性約束Default output directory is/workspace/.agent-browser-screenshots/, whichview_imagecan read. ... Never write screenshots to/tmp—view_imagerejects anything outside the workspace root.即view_image會拒絕工作區(qū)根workspace root之外的路徑例如/tmp下的文件無法被讀取。這既是沙箱邊界的體現(xiàn)也是安全設(shè)計的必然——工具的能力被限定在掃描容器自己的工作區(qū)內(nèi)。實戰(zhàn)工作流兩段式調(diào)用讓模型真正看到頁面在 agent_browser.md 的 Skill 文檔中截圖的推薦姿勢是先截圖拿到路徑、再把路徑交給view_imageexec_command: agent-browser screenshot view_image: {path: path printed on stdout}screenshot 命令的常用形態(tài)agent-browser screenshot # 無參形式路徑打印到 stdout agent-browser screenshot /workspace/.agent-browser-screenshots/page.png # 顯式指定文件名 agent-browser screenshot --full # 整頁滾動高度截圖 agent-browser screenshot --annotate # 編號標注 與 snapshot ref 對應(yīng)的圖例實踐要點優(yōu)先無參形式CLI 會把完整路徑打印到 stdout將 stdout 輸出的路徑原樣傳給view_image即可避免路徑拼接出錯自定義文件名需守規(guī)矩若需指定文件名應(yīng)放在默認截圖目錄或/workspace下同級的隱藏目錄中絕不能寫到/tmp--annotate專為多模態(tài)模型設(shè)計每個標注[N]對應(yīng)快照snapshot中的 refeN。先拍標注截圖再用view_image查看就能把視覺布局與快照 DOM 結(jié)構(gòu)兩張視圖關(guān)聯(lián)起來——例如定位某個可疑按鈕時視覺上對應(yīng)哪個 DOM 節(jié)點一目了然見 agent_browser.md。Token 成本意識先快照、必要時才像素skill 文檔明確給出了成本提示agent_browser.mdSnapshots (snapshot -i) give you a compact text view that costs ~200-400 tokens; screenshots cost more. Usesnapshotfirst; reach forscreenshot view_imageonly when you actually need pixels.推薦策略是優(yōu)先用文本形態(tài)的snapshot -i獲取 DOM 概覽只有遇到視覺布局、驗證碼、可訪問性樹不完整的自定義控件等真正需要像素的問題時才動用screenshot view_image。這從根上控制多模態(tài)內(nèi)容的上下文開銷。文本模型的降級路徑skill 文檔也寫明了view_image的失敗語義agent_browser.mdIfview_imageerrors back at you (rejected image, vision not supported, or similar), you are running on a text-only model — stop calling it and stop taking screenshots.一旦view_image返回拒絕類錯誤說明當前模型不支持視覺輸入Agent 應(yīng)當停止截圖與view_image調(diào)用完全改用snapshot -i的 ref、eval讀取任何需要的 DOM/JS 狀態(tài)與text ref/get text做內(nèi)容抽取。這套降級說明被寫進了 skill 提示詞模型在遇到報錯時能據(jù)此自糾正。渲染落地截圖在 TUI 與 Viewer 中的呈現(xiàn)view_image的結(jié)果不僅在模型上下文生效也會被 Strix 的兩套人機界面消費保證人類審計者與 Agent 看到同一畫面。終端 TUI在 strix/interface/tui/internal/render/registry.go 中view_image被路由到專門渲染器case view_image: return renderViewImage(args, result)其實現(xiàn)位于 strix/interface/tui/internal/render/image.go。該渲染器會從view_image的工具結(jié)果中抽取 base64 圖像負載extractImageDataURI并在終端能力允許時借助Kitty graphics protocol直接內(nèi)聯(lián)顯示圖像占位/預(yù)覽。對應(yīng)測試 strix/interface/tui/internal/render/image_kitty_test.go 驗證了兩種分支支持 Kitty 時渲染占位符、不支持時TestViewImageWithoutKittySupportShowsNoPreview則不做圖像預(yù)覽。由此可推斷TUI 的圖像呈現(xiàn)能力是檢測到終端協(xié)議才啟用的自適應(yīng)設(shè)計而非依賴固定終端類型。Web Viewer在前端側(cè)ViewImageRenderer.tsx 負責把view_image的返回結(jié)果渲染為內(nèi)聯(lián)圖片其在工具注冊表中的歸屬也印證了它是 SDK filesystem 家族成員——index.ts 把apply_patch、view_image、str_replace_editor、list_files、search_files一并歸入filesystem分組。容錯機制視覺拒絕的自動恢復(fù)與上下文預(yù)算view_image輸出的是圖像內(nèi)容塊體積大且不是所有模型都支持。Strix 在運行層內(nèi)置了兩道防線拒收自動剝離與上下文圖像預(yù)算。二者的實現(xiàn)主體都位于 strix/core/sessions.py。場景一模型拒收圖像輸入自動恢復(fù)多模態(tài)場景下模型/供應(yīng)商可能因「vision not supported」等原因直接拒絕包含圖像的輸入。執(zhí)行循環(huán)在 strix/core/execution.py 中捕獲到這類異常時啟動恢復(fù)except Exception as exc: if ( image_strips 3 and session is not None and getattr(exc, status_code, None) in _INPUT_REJECTION_CODES ): try: stripped await strip_all_images_from_session(session) ... if stripped: image_strips 1 ... input_data [] continue其中_INPUT_REJECTION_CODES frozenset({400, 404, 422})execution.py最多執(zhí)行3 次圖像剝離后重試image_strips 3。strip_all_images_from_session的具體實現(xiàn)見 sessions.py遍歷會話條目把每個含圖像的工具輸出替換為文本占位符_IMAGE_REJECTED_TEXT [image rejected by the model]替換邏輯是塊級、保兄弟的_elided_output只把output列表中type input_image的塊換成文本塊同一條function_call_output里其他文本塊原樣保留sessions.py。判定函數(shù)_output_has_image則專門匹配function_call_output且其 output 列表中含input_image塊的條目sessions.py。所有會話改寫都在session_write_lock寫鎖內(nèi)以讀-改-寫方式進行失敗時恢復(fù)原條目sessions.py避免在 Agent 并發(fā)寫會話時互相覆蓋。整個恢復(fù)流程的效果是視覺模型不可用時掃描不會中斷——圖像被文本占位符替代后會話繼續(xù)推進Agent 轉(zhuǎn)入純文本驅(qū)動模式。場景二上下文圖像預(yù)算裁剪即使模型支持視覺大量截圖也會撐爆上下文。執(zhí)行循環(huán)在每輪開跑前按上下文配置執(zhí)行圖像預(yù)算execution.pymax_images context.get(max_context_images) if isinstance(max_images, int): try: await enforce_image_budget(session, max_images) ...enforce_image_budgetsessions.py只保留最近max_images張圖像輸出更早的截圖被替換為提示文本_IMAGE_ELIDED_TEXT [older screenshot elided to bound context memory]從而把多模態(tài)內(nèi)容對上下文的占用控制在預(yù)算內(nèi)同時保留最近的視覺狀態(tài)供模型引用。場景三繼承上下文中的圖像脫敏當子 Agent 需要繼承父級上下文時圖像不會盲目拷貝。scrub_images_from_itemssessions.py遞歸掃描輸入條目把每個input_image塊替換成_INHERITED_IMAGE_TEXT [screenshot omitted from inherited context]這讓上下文繼承以文本摘要進行避免子 Agent 的上下文被父級的整頁截圖污染。三種占位符文本rejected / elided / omitted各司其職分別對應(yīng)拒收恢復(fù)、預(yù)算裁剪、繼承脫敏三條鏈路從源碼層面看是一個相當完整的圖像上下文治理體系。結(jié)語與延伸閱讀view_image雖只是 SDK 提供的一個小工具卻在 Strix 的視覺閉環(huán)中扮演承上啟下的角色上承 agent-browser 截圖能力把像素送入多模態(tài)模型下接 TUI / Viewer 渲染與上下文治理讓視覺內(nèi)容既可審計又可管理再輔以容器目錄約定與運行層自動恢復(fù)讓視覺能力成為可平滑降級的可選增強項而非掃描的脆弱依賴。想繼續(xù)深入可優(yōu)先閱讀以下文件文檔主體strix/tools/view_image/README.md工具裝配strix/agents/factory.pyFilesystemcapability 注入截圖工作流 Skillstrix/skills/tooling/agent_browser.md容器默認目錄containers/Dockerfile、containers/docker-entrypoint.sh容錯與預(yù)算實現(xiàn)strix/core/sessions.py、調(diào)用點 strix/core/execution.py界面呈現(xiàn)registry.go、ViewImageRenderer.tsx、測試 image_kitty_test.go【免費下載鏈接】strixOpen-source AI penetration testing tool to find and fix your app’s vulnerabilities.項目地址: https://gitcode.com/GitHub_Trending/strix/strix創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考