Codewhale/preview-request命令深度解析零成本預(yù)覽下一次對外請求的完整清單【免費下載鏈接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.項目地址: https://gitcode.com/GitHub_Trending/de/Codewhale/preview-request是 Codewhale基于 Rust 的終端原生編碼智能體為終端用戶提供的一把安全探針在不真正發(fā)送任何請求的前提下渲染出下一次主智能體輪次將要發(fā)出的出站請求清單request manifest——包括路由、工具面、請求體及各類哈希與預(yù)算信息。本文從命令語法、引擎實現(xiàn)、精確性模型、脫敏邊界到多路由 A/B 對比完整拆解該命令的設(shè)計原理與實戰(zhàn)用法幫助你在閱讀本文后能夠熟練運用三種調(diào)用形態(tài)與--prompt語法、讀懂四段式清單的每一個字段、理解哪一段是精確的、哪一段為何不可用并用手動觸發(fā)免費做跨路由比對。一、這是什么命令離線、只讀、面向人/preview-request渲染的是一種帶類型的、已脫敏的請求清單request manifest用于精確描述**下一次主智能體輪次primary agent turn**若被發(fā)送將產(chǎn)生的請求。它有三個鐵律絕不發(fā)送該請求絕不追加到會話絕不寫入 engine、session 或 Work 狀態(tài)。命令存在三個兼容別名/preview-request、/dryrun、/preview_request。這是一個人類命令human command設(shè)計上刻意沒有暴露給模型的工具——即模型不能自我調(diào)用它來偷看自己的請求見 命令實現(xiàn)模塊說明。核心使用形態(tài)如下來自 關(guān)聯(lián)文檔/preview-request # 會話事實路由/請求體標(biāo)記為不可用 /preview-request json # 同樣清單以 JSON 輸出 /preview-request --prompt text # 針對該提示詞的下一次輪次預(yù)覽 /preview-request json --prompt text # 兩者結(jié)合 /preview-request base-prompt # 只輸出精確的 base 層無運行時附加內(nèi)容為什么命令不放在命令層而是放在引擎因為只有引擎能重建下一次輪次的精確狀態(tài)——工具目錄、活動子集、門控、權(quán)限姿態(tài)與已連接的 MCP 工具命令層只是參數(shù)解析的薄分發(fā)器。這一架構(gòu)決策體現(xiàn)在 preview.rs 模塊頭注釋 與 命令層的純解析實現(xiàn) 中。二、參數(shù)文法flag 在前--prompt終態(tài)命令的參數(shù)文法如下/preview-request json --prompt fix itargs : flag* [ --prompt whitespace prompt ] flag : json | --json | manifest | --manifest | prompt | base-prompt | --base-prompt prompt : every remaining byte, verbatim這條文法保證兩點性質(zhì)且均有單測背書flag 位置是誠實的所有 flag 必須出現(xiàn)在--prompt之前而--prompt是終態(tài)——它之后的一切字節(jié)都算提示詞文本包括尾隨的json。因此/preview-request --prompt fix it json會把fix it json當(dāng)作提示詞并以人類可讀表格輸出若想輸出 JSON 必須寫成/preview-request json --prompt fix it。任何輸入只有唯一一種解讀--prompt之前的未知參數(shù)一律拒絕而非猜測對應(yīng)單測見 preview_request.rs#L287-L308。提示詞保留你的字節(jié)內(nèi)部的連續(xù)空白與換行原樣保留只有分隔--prompt與文本的那一個空白碼點作為語法被消費。額外的行首空白、全部行尾空白與換行都算提示詞數(shù)據(jù)。由于提示詞會被哈希進預(yù)覽的請求體任何歸一化都會導(dǎo)致描述的請求與你真實鍵入的請求在唯一一個你親手輸入的字段上不一致。字節(jié)級保真有專門的測試用例驗證見 preview_request.rs#L256-L281。prompt仍是普通保護清單的兼容別名base-prompt/--base-prompt是顯式的僅人類可見披露模式只打印有效的 base-prompt 字節(jié)其余一概不打印。它不能與 JSON 或--prompt組合有效的系統(tǒng)文本system text永遠(yuǎn)不會被打印因為它可能包含項目指令、技能skills與記憶memory。實現(xiàn)上還通過include_str!守衛(wèi)測試防止命令層引用任何能導(dǎo)出完整系統(tǒng)提示詞文本的輔助函數(shù)被重新引入見 preview_request.rs#L400-L415。三、精確性模型清單是分段的每段要么精確要么類型化缺席下一次用戶消息本身就是請求的一部分。沒有它就沒有可描述的下一輪請求體而且在**自動模型路由auto model routing**下連路由都不存在——路由是由你尚未鍵入的文本決定的。因此清單被分段且每一段都有清晰的精確條件分段何時精確session永遠(yuǎn)——姿態(tài)、門控、base-prompt 來源、請求的模型/推理設(shè)置route提供了--prompt、活動 goal 未耗盡 token 預(yù)算、選擇了固定路由、未配置message_submithooks、且共享規(guī)劃器成功解析該路由tools路由精確且MCP 工具狀態(tài)可在不連接的情況下快照body工具面與權(quán)威 Work 快照精確且沒有運行時變換會先重寫請求為什么某一段會失去精確資格每段不可用都發(fā)布帶類型的理由而不是模糊的占位類型化理由真實輪次會做的、而檢查不做的事auto-route-unresolved-until-next-prompt根據(jù)你尚未鍵入的文本決定路由auto-route-classification-not-executed調(diào)用 provider 支撐的 Auto 分類器預(yù)覽嚴(yán)格離線生產(chǎn)環(huán)境必須解析它no-hypothetical-prompt-supplied發(fā)送清單中不存在的那條消息message-submit-hooks-not-executed運行可變的 hooks它們可能重寫或攔截文本——連帶影響由其派生的路由、工具策略與請求體prompt-resolution-failed在技能權(quán)威或文件引用上報同樣的錯route-plan-failed路由解析或預(yù)檢失敗mcp-state-not-snapshottable連接 MCP 服務(wù)器并發(fā)現(xiàn)本目錄中不存在的工具runtime-transforms-before-send自動壓縮、運行上下文溢出恢復(fù)、注入后臺 shell 完成、放行運行中/未投遞的子智能體完成、或在首次請求前沖刷 LSP 診斷work-state-not-snapshottable讀取當(dāng)前基于圖graph-backed的 Work 投影預(yù)覽永不替換為異步發(fā)布的、可能過期的 To-do 視圖goal-token-budget-exhausted由于持久化 token 用量達(dá)到預(yù)算在分發(fā)前停止活動 goalgoal-state-not-snapshottable判斷活動 goal 的終結(jié)預(yù)算門是否允許下一個請求request-preparation-failed請求體完全構(gòu)建失敗兩條關(guān)鍵的傳染規(guī)則需要格外注意mcp-state-not-snapshottable會連累請求體。缺少 MCP 貢獻的目錄不是沒有 MCP 工具的同一個請求——真實輪次會連接可能發(fā)出不同的工具列表、不同的工具區(qū)域因此是不同的請求體與哈希。此時 body 繼承工具段的理由而不是發(fā)布一個永遠(yuǎn)不會被發(fā)送的請求的精確哈希。但route段存活endpoint、dialect、wire model 并不依賴請求上有哪些工具。這段缺陷修復(fù)邏輯在 引擎實現(xiàn)注釋 中有明確記錄——曾經(jīng)被評審出來的缺陷就是偽造空 MCP 貢獻并對其哈希。檢測是只讀的。為了判斷是否有運行時變換不會去排空drain、接收、沖刷或壓縮任何東西檢查運行中與終端未投遞的子智能體是否合格、檢查 LSP 塊是否為空、shell manager 只查不輪詢、壓縮決策對著借用的假設(shè)消息列表評估并把 slop 門釘住。檢查掛起狀態(tài)不會消費它。實現(xiàn)見 preview_runtime_transforms 方法。沒有--prompt時即使在固定模型上 route 段也不可用這是刻意設(shè)計只有當(dāng)路由由將要真正發(fā)送該輪次的同一規(guī)劃器、針對同一條下一條消息解析時才會被報告。大概還是當(dāng)前這條恰好是此命令存在的意義要去消除的幾乎為真的事實。一個不可用段發(fā)布的是帶類型的理由和零字段當(dāng)自動路由未解析時整個 JSON 中不存在provider_id、route_id、dialect、endpoint_host_class、endpoint_fingerprint、wire_model、billing、tool_surface_budget或body_sha256——不是null也不是上一輪的值。requested_model讀作auto因為這才是你真實的選擇。四、什么會跑、什么不會跑確定性生產(chǎn)路徑的離線半程帶上--prompt時預(yù)覽執(zhí)行的是生產(chǎn)路徑中確定性的那一部分且在發(fā)送之前停止提示詞被解析為面向模型的內(nèi)容與真實提交完全一致——它將被包裹的掛起活動技能克隆而非消費、文件提及、git 提及、暫停命令的注記——錯誤傳播也一致。真實提交會跑message_submithooks 而預(yù)覽不會只要配置了 hooks清單就如實聲明并且不聲稱文本下游的任何東西為精確。固定路由下內(nèi)容經(jīng)過同一個共享路由規(guī)劃器plan_turn_route真實輪次的spawned_dispatch_inner也用它有效 provider 與模型、路由身份解析、預(yù)檢、路由限制、壓縮策略、reasoning-effort 歸一化。Auto 模式在此步之前停止因為規(guī)劃器會調(diào)用模型分類器。引擎把規(guī)劃好的路由投射進一個一次性客戶端throw-away client——與真實輪次安裝的是同一套客戶端構(gòu)造邏輯只是不安裝。重建工具目錄并用輪次循環(huán)同一規(guī)劃器收窄針對該路由的模型與上下文窗口組合系統(tǒng)提示詞用生產(chǎn)環(huán)境所用的同一構(gòu)造函數(shù)追加假設(shè)用戶消息turn 元數(shù)據(jù)、路由戳、來源再像輪次循環(huán)那樣針對這些消息解析autoreasoning 層級。生產(chǎn)只發(fā)送存儲的歷史、別無其他——Codewhale 不會在模型步驟上重述 To-do 列表——因此被預(yù)覽的出站消息列表就是這個列表本身一次對存儲消息 系統(tǒng)提示詞的估算同時覆蓋清單數(shù)字與溢出決策。通過DeepSeekClient::prepare_outbound_request準(zhǔn)備請求并描述其結(jié)果——除非有運行時變換會先重寫它此時 body 被類型化為不可用。什么都不安裝哪怕一瞬間。真實輪次在構(gòu)建請求前會安裝的一切——命令作用域工具門、有效模式與審批姿態(tài)、策略收窄事件、觀測到新消息的工作集——都以值傳遞或快照到克隆上。全程沒有先寫再恢復(fù)write-then-restore恢復(fù)在await上不原子也經(jīng)不起取消或 panic。終端續(xù)接狀態(tài)只讀不改變計數(shù)器。有一條回歸測試斷言config、caches、session messages、model、system prompt、working set、provider、mode 與 MCP 池在預(yù)覽后全部字節(jié)一致對應(yīng)測試目錄 crates/tui/src/core/engine/preview/tests.rs。不可能發(fā)生任何出站調(diào)用。固定模型下規(guī)劃與請求準(zhǔn)備都是本地的Auto 模式下命令報告auto-route-classification-not-executed并在共享規(guī)劃器之前停下——因為解析路由需要調(diào)用模型分類器。預(yù)覽從不讀取或?qū)懭敕诸惼黜憫?yīng)緩存也從不改變 provider 的重試或限流狀態(tài)。其他一切都無副作用。工具目錄構(gòu)建運行在被動模式絕不創(chuàng)建 MCP 池、調(diào)用connect_all、重新加載 MCP 配置源、啟動服務(wù)器、生成子智能體運行時任務(wù)、捕獲 fork 快照或發(fā)出 UI 狀態(tài)事件。當(dāng)已連接的 MCP 狀態(tài)不恰好是輪次將用的狀態(tài)還沒有池、配置源變了、或啟用的服務(wù)器未連接tools段報告mcp-state-not-snapshottable而不是連接了再告訴你。相關(guān)枚舉與四段數(shù)據(jù)結(jié)構(gòu)的源碼定義參見 request_manifest.rs。五、作用域只描述主智能體輪次清單描述的是LlmClient::create_message/create_message_stream——智能體循環(huán)所運行的那些模型輪次。它不描述 Codewhale 的各類輔助 provider 調(diào)用后者各有形狀輔助調(diào)用狀態(tài)Chat-dialect 翻譯translate不在受檢接縫上直接構(gòu)建一個小固定請求體無工具、temperature 0.1。超出作用域。Anthropic/Responses-dialect 翻譯走prepare_outbound_request以避免第二套構(gòu)建器但仍是輔助調(diào)用仍在清單作用域之外。FIM 補全、語音、provider 原生搜索、/models列表獨立 endpoint 與請求體。超出作用域。Auto-router 分類器路由器路由上的獨立小輪次。超出作用域且預(yù)覽絕不執(zhí)行。文檔明確聲明見原文檔任何每個出站請求都走被預(yù)覽接縫的說法都是錯的本文也不做此類主張。六、數(shù)字從哪來被準(zhǔn)備好的出站請求與獨立哈希的奇偶校驗測試被準(zhǔn)備好的出站請求。每一次主模型輪次到達(dá)線路wire都經(jīng)過DeepSeekClient::prepare_outbound_request它返回PreparedOutboundRequestdialect、endpoint 身份、canonical wire model、最終請求體與 reasoning 收據(jù)。生產(chǎn)分發(fā)發(fā)送這個值預(yù)覽描述這個值。沒有第二套請求體構(gòu)建器。請求準(zhǔn)備會跑完整生產(chǎn)序列工具歷史修復(fù)與模型綁定密鑰脫敏、協(xié)議綁定與路由模型重解析、該 dialect 自己的請求體構(gòu)建器含每個 provider 專屬的 sanitizer 與 reasoning shaper、精確 endpoint 解析。奇偶校驗測試parity tests不是把捕獲的邏輯請求再喂回構(gòu)建器。它們對 HTTP mock 跑一次真實生產(chǎn)輪次解析服務(wù)器實際收到的第一個請求體獨立 canonicalize 這些捕獲字節(jié)再把哈希與預(yù)覽對比。覆蓋場景包括翻譯的提示詞上下文、暫停命令分離、原生 Anthropic Messages 塑形。每個生產(chǎn) dialect 都被端到端保留——沒有任何東西被投射成 Chat CompletionsDialect路由chat-completionsDeepSeek、Moonshot/Kimi含 Kimi Code K3 嵌套thinking.effort形態(tài)與直接 K3 固定采樣形態(tài)、Z.ai、xAI、OpenRouter、vLLM/Ollama/SGLang、OpenCode Zen chat 路由、自定義兼容 endpointanthropic-messagesAnthropic、DeepSeek Messages、MiniMax Messages、OpenModelopenai-responsesOpenAI CodexChatGPT 后端路徑、OpenCode Zen responses 路由清單同時報告 dialect和路由形態(tài)standard、deepseek-beta-strict-tools、kimi-code-k3、direct-moonshot-k3、codex-responses、opencode-zen、custom-compatible因此你可以看清實際跑的是哪個構(gòu)建器分支。清單由引擎構(gòu)建而非命令層因為只有引擎能重建下一輪次的精確工具目錄、活動子集、門控、權(quán)限姿態(tài)與工具選擇。會話的最后一個工具目錄從不被采用——它落后一個輪次存的是激活前的目錄。七、流式與工具選擇作為線事實而非推斷caller_entrypoint說明描述的是哪個傳輸入口streaming/blocking。body_stream_field說的是請求體自己聲明的字段從成品 JSON 上讀出Chat Completions 流式 →trueChat 阻塞 → 字段缺席null因為阻塞請求體從不攜帶它。Anthropic Messages → 鏡像調(diào)用方。OpenAI Responses →恒為true包括阻塞入口——它打開一條 SSE 流并折疊成一個響應(yīng)。由于清單描述的是請求體字段本身而非從調(diào)用方推斷Responses 的阻塞情形不會誤報為非流式請求。tool_choice同理從成品 provider 請求體讀出而非邏輯請求Anthropic 可能攜帶對象、Responses 攜帶映射后的字符串、DeepSeek thinking 請求則整個省略該字段。八、清單字段總覽會話 / 路由 / 工具 / 請求體分段字段session精確的主智能體角色/lane/Fleet 非分配、請求的模型auto 時讀作auto、路由模式、請求的推理、是否提供了假設(shè)提示詞、模式、審批姿態(tài)、allow/deny 門尺寸、base-prompt 來源 字節(jié)數(shù) SHA-256routeprovider id 顯示名、命名路由 id、類型化路由來源、dialect、路由形態(tài)、安全 endpoint host class/摘要、endpoint 指紋、wire model、caller 入口、請求體stream字段、上下文上限 來源configured、provider-reported、static floor、catalog 或 fallback、路由輸入/輸出限制或unknown、類型化計費tools活動計數(shù)、catalog/延遲deferred計數(shù)、邏輯目錄 SHA-256、工具面預(yù)算、Standard-vs-Full 塌縮、MCP 服務(wù)器與 MCP 工具bodyreasoning 解析 wire 控制鍵 wire effort及其鍵路徑、tool_choice、系統(tǒng)提示詞組裝 有效 canonical JSON 字節(jié)/SHA-256、請求體/系統(tǒng)/tool-schema/消息/tool-result/附件/框架各 canonical JSON 大小、逐類估算、精確輸入預(yù)算上限與余量、字面 wire 輸出上限或unknown、provider 報告的用量明確不可用因為沒有請求運行、全請求體 SHA-256、wire tool-schema SHA-256、本地系統(tǒng)/工具組件 SHA-256計數(shù)與估算的提取是dialect 感知的Responses 請求體的instructions/input、Anthropic 請求體的system/messages、Chat 請求體內(nèi)聯(lián)的system角色消息都從該 dialect 真正存放它們的位置讀取。上述數(shù)據(jù)結(jié)構(gòu)的 Rust 定義與 schema 版本常量見 request_manifest.rs。字節(jié)分類是精確對賬不是字節(jié)切片system tool_schemas messages framing body_canonical_json_bytes在每個 dialect、兩個入口上都精確成立。前三者是選定 JSON 值的 canonical 序列化它們不是從請求體緩沖中借用的四段不相交區(qū)間。framing是代數(shù)余量——包含其余一切頂層字段、以及未被任一選中數(shù)組值計入的 JSON 結(jié)構(gòu)。有不變量測試斷言該和恒等式突變測試檢驗歸屬是否符合預(yù)期。不要用這些計數(shù)去重構(gòu)請求字節(jié)。tool_result與attachment字節(jié)是消息字節(jié)的子集僅為歸屬報告絕不重復(fù)累加。余量headroom對輸入預(yù)算測算estimated_input_headroom_tokens從該路由的輸入預(yù)算上限中減去生產(chǎn)的保守消息 系統(tǒng)提示詞估算——即context_input_budget_for_route正是輪次循環(huán)發(fā)送前檢查的同一個接縫上下文窗口減去輸出預(yù)留再減去安全余量。它不是裸的context_limit_tokens從一個路由還必須把響應(yīng)塞進去的窗口里減輸入報告的是輪次并不擁有的余量。當(dāng)請求放不下時該值可為負(fù)而不是鉗到 0 讀作放得下——一旦為負(fù)請求體被報告不可用因為輪次循環(huán)會跑上下文溢出恢復(fù)并改發(fā)別的東西。這個生產(chǎn)門控與清單對 canonical JSON 請求體字節(jié)的獨立保守估算是兩回事后者仍可用于 provider 請求體歸屬但它不決定溢出或余量。清單把那個確切上限發(fā)布為input_budget_ceiling_tokens并把三種不同的事實分開上下文上限及其解析來源、可選的 route/offering 輸入輸出限制、線路上字面序列化的輸出上限。若某路由/dialect 未提供某事實值為unknown預(yù)覽絕不會從相鄰模型或已裝路由編造一個。reasoning 控制dialect 把鍵放哪就讀哪reasoning_wire_effort讀取扁平的reasoning_effort、Kimi Code 的嵌套thinking.effort、Responses 的reasoning.effort、Anthropic 的output_config.effortreasoning_wire_effort_source指明它來自哪一個編譯期常量絕不是從請求體里掏出來的鍵。只報扁平鍵曾讓思考最狠的路由讀作沒發(fā) effort。reasoning_resolution區(qū)分用戶顯式選擇的explicit與用戶從未要求過的route-default控制并在請求體完全不需要推理時報告not-applicable。Responses 的include字段是披露推理輸出而非請求某個層級因此單獨出現(xiàn)include絕不報告為一次推理請求。九、三種哈希全請求體、活動目錄、wire 工具區(qū)body_sha256覆蓋完整 canonical wire 請求體而非前綴。任一變化都會改變它max-token 字段、tool_choice、嵌套 reasoning 控制、provider 變換過的工具 schema、附件、stream 選項、采樣參數(shù)、或任何消息——包括追加的假設(shè)提示詞。Canonicalization 會排序?qū)ο箧I所以構(gòu)建器的插入順序不會移動哈希任何真實輸入變化都會包括日期/工作集/git 元數(shù)據(jù)、運行時注入、工具發(fā)現(xiàn)、提示詞設(shè)置或路由。tools.active_tool_catalog_sha256是對當(dāng)前活動工具目錄在dialect 塑形之前的獨立穩(wěn)定哈希名稱、描述、canonical 邏輯 schema按序。它隨成員、順序與邏輯 schema 變化而移動。它是目錄身份而非線事實兩條路由在這里一致仍可能發(fā)送不同字節(jié)因為各 dialect 以各自方式變換 schema、嚴(yán)格模式還會進一步清洗。該哈希的單一定義位于 active_tool_catalog_sha256 函數(shù)/tools檢查與清單共享同一實現(xiàn)避免兩套哈希靜默分叉。body.tool_schema_wire_sha256是工具區(qū)按 provider 實際收到的樣子的哈希。body.local_system_tools_component_sha256把該摘要與最終 wire 系統(tǒng)區(qū)摘要合并為本地比較指紋——它不是 provider 緩存鍵、不聲稱兩區(qū)相鄰、也不含路由專屬的緩存語義保證當(dāng)工具面不完全已知時被省略。十、披露邊界這是可檢查性切片不是請求體導(dǎo)出清單是一組固定的計數(shù)、哈希、枚舉與短來源標(biāo)簽沒有任何字段能容納自由格式的請求文本。它不可能包含系統(tǒng)提示詞、項目指令、記憶或技能內(nèi)容消息內(nèi)容、tool-result 請求體或附件載荷憑據(jù)、Authorization頭或查詢串URL 路徑路徑本身可能攜帶部署密鑰絕對工作區(qū)或主目錄路徑。標(biāo)識符同樣不被信任。自定義路由 id 與模型 id 是用戶創(chuàng)作的文本可以是絕對路徑、URL、URL 路徑、或本身就是憑據(jù)的部署 id。每個此類值在打印前都穿越 allowlist 邊界crate::safe_label實現(xiàn)見 safe_label.rs不含斜杠的通用標(biāo)識符按原樣發(fā)布帶斜杠的模型 id 還必須精確匹配活動本地模型目錄中的某個條目——光有 vendor 前綴不夠。其余一律替換為穩(wěn)定的sha256:12 hex指紋。同一惡意 id 的兩次預(yù)覽仍然可比對相等id 本身永不顯示。錯誤文本同樣不被信任且不清洗——它走的是 allowlist。預(yù)檢、MCP、提示詞解析與請求準(zhǔn)備失敗都會插入主機文本而這些文本常攜帶路由 id、帶引號的服務(wù)器名、路徑即密鑰的 endpoint 或裸憑據(jù)。每個空白分隔的 token 都得掙得自己的位置含控制字符的 token 被丟棄URL 只保留scheme://host[:port]且僅當(dāng)二者本身普通——路徑、查詢、fragment、userinfo 永不發(fā)布token 形態(tài)的host會令整個 token 變?yōu)椴煌该鞫前氚l(fā)布任何路徑形態(tài)POSIX 絕對、~/、Windows 盤符或含反斜杠折疊為path-redacted攜帶、或反引號的 token 整體替換——引號區(qū)間正是惡意標(biāo)識符藏身處其余必須是短普通詞ASCII 字母數(shù)字加-、_、.長度有界token/密鑰形態(tài)則拒絕邊緣只允許句子標(biāo)點。其余一切變?yōu)閞edacted連續(xù)脫敏區(qū)塌縮結(jié)果截斷。普通診斷句原樣存活惡意句變成通用形狀。Endpoint 只以兩種方式發(fā)布有界主機類http loopback或https remote sha256:12 hex與用于同一 endpoint?比對的完整 URL 的 SHA-256 指紋。遠(yuǎn)程權(quán)威authority一律摘要——它可能是憑據(jù)形態(tài)的租戶子域——路徑、IDN、userinfo、查詢、fragment 從不顯示。一條回歸測試斷言清單中沒有任何字段攜帶序列化消息數(shù)組或工具 schema見 request_manifest.rs 與 safe_label.rs 測試。十一、估算就是估算每一個 token 數(shù)都是離線估算約 4 字節(jié)/token 再加 5% 保守余量永遠(yuǎn)不是provider 權(quán)威計數(shù)。它們用于請求之間的相互比較而不是預(yù)測賬單。字節(jié)數(shù)、哈希與計數(shù)是精確的。tool-result 與附件估算是消息估算的子集僅供歸屬不再累加進總量。十二、Base-prompt 來源#3928來源、組裝、有效哈希受保護清單在不打印有效系統(tǒng)文本的前提下區(qū)分三件事單獨的/preview-request base-prompt模式只打印精確的有效 base-prompt 字節(jié)來源Origin——base-prompt 字節(jié)來自哪里bundled in this codewhale-tui build (BASE_PROMPT, compiled in)config-directory override installed at startup (prompts/constitution.md, opt-in enabled)組裝Assembly——有效提示詞如何構(gòu)建于該 base 之上base prompt only、base prompt configured static layers、或base prompt configured layers runtime/session additions。有效哈?！褱?zhǔn)備請求的系統(tǒng)區(qū)的 SHA-256最終 wire 形態(tài)的提示詞而非獨立重組字符串。在真實會話中組裝通常是base prompt configured layers runtime/session additions因為環(huán)境塊、項目上下文、技能與記憶追加在 constitution 之后。Codewhale 不聲稱配置的 constitution 就是有效 base prompt任何診斷都不引用安裝二進制上不存在的源碼樹路徑。實現(xiàn)細(xì)節(jié)見 preview.rs 的 preview_prompt_provenance 方法 與 base-prompt 運行時來源標(biāo)簽測試。十三、工具面標(biāo)簽塌縮是推導(dǎo)而非斷言standard_and_full_surfaces_collapsed是推導(dǎo)出來的不是斷言surface shaper 同時以 Standard 與 Full 預(yù)算跑過真實當(dāng)前目錄并比較結(jié)果。今天它報告true——兩個預(yù)算產(chǎn)生相同目錄——清單用白話說出來而不暗示差異。將來 shaper 一旦對 Standard 收窄得與 Full 不同該字段無需任何文案修改就會自動翻轉(zhuǎn)。任何聲稱某工具面工具更多的基準(zhǔn)結(jié)論必須先給出不同的active_tool_catalog_sha256。塌縮推導(dǎo)函數(shù)見 standard_and_full_collapse。十四、實戰(zhàn)發(fā)送前進行零 provider 成本的固定路由 A/B/preview-request使無 provider 的固定路由 A/B成為可能切換路由、用同一提示詞預(yù)覽、比較。操作步驟選擇路由/model、/provider或你的 profile——不要發(fā)送輪次。運行/preview-request json --prompt 每次相同的文本并保存輸出例如glm-5.2.json。對每條路由重復(fù)。Diff 這些清單。diff 中該看什么route.dialect/route.route_shape——兩條不同 dialect 的路由發(fā)送的是結(jié)構(gòu)上不同的請求而不是同一請求到不同主機。route.wire_model——真正上線wire的 id。路由器條目常與你選中的標(biāo)簽不同。tools.active_tool_count/body.tool_schema_wire_sha256——wire 哈希相同即工具字節(jié)相同無論 surface 標(biāo)簽說什么。tools.active_tool_catalog_sha256只用于比較邏輯目錄兩條 dialect 在此一致仍可能發(fā)送不同 schema。body.estimates.tool_schemasvsroute.context_limit_tokens——對話開始前每條路由付出的固定開銷對窗口。body.reasoning_wire_control_keys/body.reasoning_wire_effort/body.reasoning_resolution——路由是否真的被要求思考、用哪個 dialect、是來自你還是自動路由。兩條有效 effort 不同的路由不可比。body.body_sha256——整個請求。若未變出站字節(jié)沒有任何變化。body.local_system_tools_component_sha256——兩條本地實測 wire 組件是否變化。它不證明 provider 緩存復(fù)用或失效。route.billing——訂閱配額與計量 API 路由不可成本對比unknown意味著成本報告失敗即關(guān)閉fail closed。每個清單對它所描述的快照都是精確的。只有每個貢獻輸入都相同時重復(fù)預(yù)覽才逐字節(jié)相同路由、當(dāng)前日期、git 與工作集元數(shù)據(jù)、提示詞設(shè)置、工具/MCP 狀態(tài)、會話歷史與掛起的運行時變換。預(yù)覽不修改會話歷史或響應(yīng)緩存但不做任何跨調(diào)用字節(jié)穩(wěn)定性主張。Auto 模式刻意不可用也不能用于此對比直到生產(chǎn)解析出具體路由。十五、schema_version腳本消費者的兼容信號schema_version只要字段被重命名或移除就會遞增腳本化消費者因此能檢測不兼容清單而不是默默讀到null。當(dāng)前版本是9v8 的work-state-not-snapshottable不可用理由被移除——因為沒有請求會攜帶一個讓快照失敗的 To-do 塊?；顒?goal 的 token 預(yù)算終結(jié)門仍然是一條顯式 fail-closed的精確出站請求依賴。常量定義見 MANIFEST_SCHEMA_VERSION 9。十六、仍然近似的東西Auto 路由不被近似它 provider 支撐的分類器從不由預(yù)覽執(zhí)行路由相關(guān)段以類型化不可用替代。工作集漂移已不在近似列表真實提交在構(gòu)建turn_meta前調(diào)用working_set.observe_user_message預(yù)覽現(xiàn)在對工作集的克隆做同樣觀測并從該快照構(gòu)建塊。相同字節(jié)無會話寫入。其他曾被標(biāo)記近似的東西現(xiàn)在都被類型化如果運行時變換會改變請求body 段如實聲明并一個字節(jié)都不發(fā)布——而不是發(fā)布幾乎正確的數(shù)字。十七、致謝與設(shè)計溯源dryrun概念——從真實請求構(gòu)建接縫預(yù)覽下一個請求而非手工拼一個摘要——汲取自 PR #1099作者 TaoMu / GTC2080。該 PR 的代碼未被復(fù)用此處實現(xiàn)針對 Codewhale 當(dāng)前的多 dialect 客戶端重寫。相應(yīng)的設(shè)計注釋同時保留在 命令層模塊頭 與 引擎模塊頭 中本文不引用任何外部鏈接?？偨Y(jié)/preview-request把下一次出站請求長什么樣從黑盒變成一份分段精確、逐字段脫敏、全離線執(zhí)行的可檢查清單。它的工程內(nèi)核可以概括為四條絕不發(fā)布請求文本allowlist 指紋化、絕不執(zhí)行模型調(diào)用Auto 類型化缺席、絕不安裝任何狀態(tài)克隆 值傳遞、絕不發(fā)布幾乎為真的數(shù)字運行時變換一律類型化不可用。無論你是想在上車前核對路由選擇、排查上下文預(yù)算、驗證 reasoning 控制是否真的上路還是想不花一分錢完成跨路由 A/B這條命令都能給出與生產(chǎn)同一接縫、經(jīng)回歸測試逐字節(jié)驗證的答案?！久赓M下載鏈接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.項目地址: https://gitcode.com/GitHub_Trending/de/Codewhale創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考