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