Codewhale/preview-request命令深度解析零成本预览下一次对外请求的完整清单【免费下载链接】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 的终端原生编码智能体为终端用户提供的一把安全探针在不真正发送任何请求的前提下渲染出下一次主智能体轮次将要发出的出站请求清单request manifest——包括路由、工具面、请求体及各类哈希与预算信息。本文从命令语法、引擎实现、精确性模型、脱敏边界到多路由 A/B 对比完整拆解该命令的设计原理与实战用法帮助你在阅读本文后能够熟练运用三种调用形态与--prompt语法、读懂四段式清单的每一个字段、理解哪一段是精确的、哪一段为何不可用并用手动触发免费做跨路由比对。一、这是什么命令离线、只读、面向人/preview-request渲染的是一种带类型的、已脱敏的请求清单request manifest用于精确描述**下一次主智能体轮次primary agent turn**若被发送将产生的请求。它有三个铁律绝不发送该请求绝不追加到会话绝不写入 engine、session 或 Work 状态。命令存在三个兼容别名/preview-request、/dryrun、/preview_request。这是一个人类命令human command设计上刻意没有暴露给模型的工具——即模型不能自我调用它来偷看自己的请求见 命令实现模块说明。核心使用形态如下来自 关联文档/preview-request # 会话事实路由/请求体标记为不可用 /preview-request json # 同样清单以 JSON 输出 /preview-request --prompt text # 针对该提示词的下一次轮次预览 /preview-request json --prompt text # 两者结合 /preview-request base-prompt # 只输出精确的 base 层无运行时附加内容为什么命令不放在命令层而是放在引擎因为只有引擎能重建下一次轮次的精确状态——工具目录、活动子集、门控、权限姿态与已连接的 MCP 工具命令层只是参数解析的薄分发器。这一架构决策体现在 preview.rs 模块头注释 与 命令层的纯解析实现 中。二、参数文法flag 在前--prompt终态命令的参数文法如下/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这条文法保证两点性质且均有单测背书flag 位置是诚实的所有 flag 必须出现在--prompt之前而--prompt是终态——它之后的一切字节都算提示词文本包括尾随的json。因此/preview-request --prompt fix it json会把fix it json当作提示词并以人类可读表格输出若想输出 JSON 必须写成/preview-request json --prompt fix it。任何输入只有唯一一种解读--prompt之前的未知参数一律拒绝而非猜测对应单测见 preview_request.rs#L287-L308。提示词保留你的字节内部的连续空白与换行原样保留只有分隔--prompt与文本的那一个空白码点作为语法被消费。额外的行首空白、全部行尾空白与换行都算提示词数据。由于提示词会被哈希进预览的请求体任何归一化都会导致描述的请求与你真实键入的请求在唯一一个你亲手输入的字段上不一致。字节级保真有专门的测试用例验证见 preview_request.rs#L256-L281。prompt仍是普通保护清单的兼容别名base-prompt/--base-prompt是显式的仅人类可见披露模式只打印有效的 base-prompt 字节其余一概不打印。它不能与 JSON 或--prompt组合有效的系统文本system text永远不会被打印因为它可能包含项目指令、技能skills与记忆memory。实现上还通过include_str!守卫测试防止命令层引用任何能导出完整系统提示词文本的辅助函数被重新引入见 preview_request.rs#L400-L415。三、精确性模型清单是分段的每段要么精确要么类型化缺席下一次用户消息本身就是请求的一部分。没有它就没有可描述的下一轮请求体而且在**自动模型路由auto model routing**下连路由都不存在——路由是由你尚未键入的文本决定的。因此清单被分段且每一段都有清晰的精确条件分段何时精确session永远——姿态、门控、base-prompt 来源、请求的模型/推理设置route提供了--prompt、活动 goal 未耗尽 token 预算、选择了固定路由、未配置message_submithooks、且共享规划器成功解析该路由tools路由精确且MCP 工具状态可在不连接的情况下快照body工具面与权威 Work 快照精确且没有运行时变换会先重写请求为什么某一段会失去精确资格每段不可用都发布带类型的理由而不是模糊的占位类型化理由真实轮次会做的、而检查不做的事auto-route-unresolved-until-next-prompt根据你尚未键入的文本决定路由auto-route-classification-not-executed调用 provider 支撑的 Auto 分类器预览严格离线生产环境必须解析它no-hypothetical-prompt-supplied发送清单中不存在的那条消息message-submit-hooks-not-executed运行可变的 hooks它们可能重写或拦截文本——连带影响由其派生的路由、工具策略与请求体prompt-resolution-failed在技能权威或文件引用上报同样的错route-plan-failed路由解析或预检失败mcp-state-not-snapshottable连接 MCP 服务器并发现本目录中不存在的工具runtime-transforms-before-send自动压缩、运行上下文溢出恢复、注入后台 shell 完成、放行运行中/未投递的子智能体完成、或在首次请求前冲刷 LSP 诊断work-state-not-snapshottable读取当前基于图graph-backed的 Work 投影预览永不替换为异步发布的、可能过期的 To-do 视图goal-token-budget-exhausted由于持久化 token 用量达到预算在分发前停止活动 goalgoal-state-not-snapshottable判断活动 goal 的终结预算门是否允许下一个请求request-preparation-failed请求体完全构建失败两条关键的传染规则需要格外注意mcp-state-not-snapshottable会连累请求体。缺少 MCP 贡献的目录不是没有 MCP 工具的同一个请求——真实轮次会连接可能发出不同的工具列表、不同的工具区域因此是不同的请求体与哈希。此时 body 继承工具段的理由而不是发布一个永远不会被发送的请求的精确哈希。但route段存活endpoint、dialect、wire model 并不依赖请求上有哪些工具。这段缺陷修复逻辑在 引擎实现注释 中有明确记录——曾经被评审出来的缺陷就是伪造空 MCP 贡献并对其哈希。检测是只读的。为了判断是否有运行时变换不会去排空drain、接收、冲刷或压缩任何东西检查运行中与终端未投递的子智能体是否合格、检查 LSP 块是否为空、shell manager 只查不轮询、压缩决策对着借用的假设消息列表评估并把 slop 门钉住。检查挂起状态不会消费它。实现见 preview_runtime_transforms 方法。没有--prompt时即使在固定模型上 route 段也不可用这是刻意设计只有当路由由将要真正发送该轮次的同一规划器、针对同一条下一条消息解析时才会被报告。大概还是当前这条恰好是此命令存在的意义要去消除的几乎为真的事实。一个不可用段发布的是带类型的理由和零字段当自动路由未解析时整个 JSON 中不存在provider_id、route_id、dialect、endpoint_host_class、endpoint_fingerprint、wire_model、billing、tool_surface_budget或body_sha256——不是null也不是上一轮的值。requested_model读作auto因为这才是你真实的选择。四、什么会跑、什么不会跑确定性生产路径的离线半程带上--prompt时预览执行的是生产路径中确定性的那一部分且在发送之前停止提示词被解析为面向模型的内容与真实提交完全一致——它将被包裹的挂起活动技能克隆而非消费、文件提及、git 提及、暂停命令的注记——错误传播也一致。真实提交会跑message_submithooks 而预览不会只要配置了 hooks清单就如实声明并且不声称文本下游的任何东西为精确。固定路由下内容经过同一个共享路由规划器plan_turn_route真实轮次的spawned_dispatch_inner也用它有效 provider 与模型、路由身份解析、预检、路由限制、压缩策略、reasoning-effort 归一化。Auto 模式在此步之前停止因为规划器会调用模型分类器。引擎把规划好的路由投射进一个一次性客户端throw-away client——与真实轮次安装的是同一套客户端构造逻辑只是不安装。重建工具目录并用轮次循环同一规划器收窄针对该路由的模型与上下文窗口组合系统提示词用生产环境所用的同一构造函数追加假设用户消息turn 元数据、路由戳、来源再像轮次循环那样针对这些消息解析autoreasoning 层级。生产只发送存储的历史、别无其他——Codewhale 不会在模型步骤上重述 To-do 列表——因此被预览的出站消息列表就是这个列表本身一次对存储消息 系统提示词的估算同时覆盖清单数字与溢出决策。通过DeepSeekClient::prepare_outbound_request准备请求并描述其结果——除非有运行时变换会先重写它此时 body 被类型化为不可用。什么都不安装哪怕一瞬间。真实轮次在构建请求前会安装的一切——命令作用域工具门、有效模式与审批姿态、策略收窄事件、观测到新消息的工作集——都以值传递或快照到克隆上。全程没有先写再恢复write-then-restore恢复在await上不原子也经不起取消或 panic。终端续接状态只读不改变计数器。有一条回归测试断言config、caches、session messages、model、system prompt、working set、provider、mode 与 MCP 池在预览后全部字节一致对应测试目录 crates/tui/src/core/engine/preview/tests.rs。不可能发生任何出站调用。固定模型下规划与请求准备都是本地的Auto 模式下命令报告auto-route-classification-not-executed并在共享规划器之前停下——因为解析路由需要调用模型分类器。预览从不读取或写入分类器响应缓存也从不改变 provider 的重试或限流状态。其他一切都无副作用。工具目录构建运行在被动模式绝不创建 MCP 池、调用connect_all、重新加载 MCP 配置源、启动服务器、生成子智能体运行时任务、捕获 fork 快照或发出 UI 状态事件。当已连接的 MCP 状态不恰好是轮次将用的状态还没有池、配置源变了、或启用的服务器未连接tools段报告mcp-state-not-snapshottable而不是连接了再告诉你。相关枚举与四段数据结构的源码定义参见 request_manifest.rs。五、作用域只描述主智能体轮次清单描述的是LlmClient::create_message/create_message_stream——智能体循环所运行的那些模型轮次。它不描述 Codewhale 的各类辅助 provider 调用后者各有形状辅助调用状态Chat-dialect 翻译translate不在受检接缝上直接构建一个小固定请求体无工具、temperature 0.1。超出作用域。Anthropic/Responses-dialect 翻译走prepare_outbound_request以避免第二套构建器但仍是辅助调用仍在清单作用域之外。FIM 补全、语音、provider 原生搜索、/models列表独立 endpoint 与请求体。超出作用域。Auto-router 分类器路由器路由上的独立小轮次。超出作用域且预览绝不执行。文档明确声明见原文档任何每个出站请求都走被预览接缝的说法都是错的本文也不做此类主张。六、数字从哪来被准备好的出站请求与独立哈希的奇偶校验测试被准备好的出站请求。每一次主模型轮次到达线路wire都经过DeepSeekClient::prepare_outbound_request它返回PreparedOutboundRequestdialect、endpoint 身份、canonical wire model、最终请求体与 reasoning 收据。生产分发发送这个值预览描述这个值。没有第二套请求体构建器。请求准备会跑完整生产序列工具历史修复与模型绑定密钥脱敏、协议绑定与路由模型重解析、该 dialect 自己的请求体构建器含每个 provider 专属的 sanitizer 与 reasoning shaper、精确 endpoint 解析。奇偶校验测试parity tests不是把捕获的逻辑请求再喂回构建器。它们对 HTTP mock 跑一次真实生产轮次解析服务器实际收到的第一个请求体独立 canonicalize 这些捕获字节再把哈希与预览对比。覆盖场景包括翻译的提示词上下文、暂停命令分离、原生 Anthropic Messages 塑形。每个生产 dialect 都被端到端保留——没有任何东西被投射成 Chat CompletionsDialect路由chat-completionsDeepSeek、Moonshot/Kimi含 Kimi Code K3 嵌套thinking.effort形态与直接 K3 固定采样形态、Z.ai、xAI、OpenRouter、vLLM/Ollama/SGLang、OpenCode Zen chat 路由、自定义兼容 endpointanthropic-messagesAnthropic、DeepSeek Messages、MiniMax Messages、OpenModelopenai-responsesOpenAI CodexChatGPT 后端路径、OpenCode Zen responses 路由清单同时报告 dialect和路由形态standard、deepseek-beta-strict-tools、kimi-code-k3、direct-moonshot-k3、codex-responses、opencode-zen、custom-compatible因此你可以看清实际跑的是哪个构建器分支。清单由引擎构建而非命令层因为只有引擎能重建下一轮次的精确工具目录、活动子集、门控、权限姿态与工具选择。会话的最后一个工具目录从不被采用——它落后一个轮次存的是激活前的目录。七、流式与工具选择作为线事实而非推断caller_entrypoint说明描述的是哪个传输入口streaming/blocking。body_stream_field说的是请求体自己声明的字段从成品 JSON 上读出Chat Completions 流式 →trueChat 阻塞 → 字段缺席null因为阻塞请求体从不携带它。Anthropic Messages → 镜像调用方。OpenAI Responses →恒为true包括阻塞入口——它打开一条 SSE 流并折叠成一个响应。由于清单描述的是请求体字段本身而非从调用方推断Responses 的阻塞情形不会误报为非流式请求。tool_choice同理从成品 provider 请求体读出而非逻辑请求Anthropic 可能携带对象、Responses 携带映射后的字符串、DeepSeek thinking 请求则整个省略该字段。八、清单字段总览会话 / 路由 / 工具 / 请求体分段字段session精确的主智能体角色/lane/Fleet 非分配、请求的模型auto 时读作auto、路由模式、请求的推理、是否提供了假设提示词、模式、审批姿态、allow/deny 门尺寸、base-prompt 来源 字节数 SHA-256routeprovider id 显示名、命名路由 id、类型化路由来源、dialect、路由形态、安全 endpoint host class/摘要、endpoint 指纹、wire model、caller 入口、请求体stream字段、上下文上限 来源configured、provider-reported、static floor、catalog 或 fallback、路由输入/输出限制或unknown、类型化计费tools活动计数、catalog/延迟deferred计数、逻辑目录 SHA-256、工具面预算、Standard-vs-Full 塌缩、MCP 服务器与 MCP 工具bodyreasoning 解析 wire 控制键 wire effort及其键路径、tool_choice、系统提示词组装 有效 canonical JSON 字节/SHA-256、请求体/系统/tool-schema/消息/tool-result/附件/框架各 canonical JSON 大小、逐类估算、精确输入预算上限与余量、字面 wire 输出上限或unknown、provider 报告的用量明确不可用因为没有请求运行、全请求体 SHA-256、wire tool-schema SHA-256、本地系统/工具组件 SHA-256计数与估算的提取是dialect 感知的Responses 请求体的instructions/input、Anthropic 请求体的system/messages、Chat 请求体内联的system角色消息都从该 dialect 真正存放它们的位置读取。上述数据结构的 Rust 定义与 schema 版本常量见 request_manifest.rs。字节分类是精确对账不是字节切片system tool_schemas messages framing body_canonical_json_bytes在每个 dialect、两个入口上都精确成立。前三者是选定 JSON 值的 canonical 序列化它们不是从请求体缓冲中借用的四段不相交区间。framing是代数余量——包含其余一切顶层字段、以及未被任一选中数组值计入的 JSON 结构。有不变量测试断言该和恒等式突变测试检验归属是否符合预期。不要用这些计数去重构请求字节。tool_result与attachment字节是消息字节的子集仅为归属报告绝不重复累加。余量headroom对输入预算测算estimated_input_headroom_tokens从该路由的输入预算上限中减去生产的保守消息 系统提示词估算——即context_input_budget_for_route正是轮次循环发送前检查的同一个接缝上下文窗口减去输出预留再减去安全余量。它不是裸的context_limit_tokens从一个路由还必须把响应塞进去的窗口里减输入报告的是轮次并不拥有的余量。当请求放不下时该值可为负而不是钳到 0 读作放得下——一旦为负请求体被报告不可用因为轮次循环会跑上下文溢出恢复并改发别的东西。这个生产门控与清单对 canonical JSON 请求体字节的独立保守估算是两回事后者仍可用于 provider 请求体归属但它不决定溢出或余量。清单把那个确切上限发布为input_budget_ceiling_tokens并把三种不同的事实分开上下文上限及其解析来源、可选的 route/offering 输入输出限制、线路上字面序列化的输出上限。若某路由/dialect 未提供某事实值为unknown预览绝不会从相邻模型或已装路由编造一个。reasoning 控制dialect 把键放哪就读哪reasoning_wire_effort读取扁平的reasoning_effort、Kimi Code 的嵌套thinking.effort、Responses 的reasoning.effort、Anthropic 的output_config.effortreasoning_wire_effort_source指明它来自哪一个编译期常量绝不是从请求体里掏出来的键。只报扁平键曾让思考最狠的路由读作没发 effort。reasoning_resolution区分用户显式选择的explicit与用户从未要求过的route-default控制并在请求体完全不需要推理时报告not-applicable。Responses 的include字段是披露推理输出而非请求某个层级因此单独出现include绝不报告为一次推理请求。九、三种哈希全请求体、活动目录、wire 工具区body_sha256覆盖完整 canonical wire 请求体而非前缀。任一变化都会改变它max-token 字段、tool_choice、嵌套 reasoning 控制、provider 变换过的工具 schema、附件、stream 选项、采样参数、或任何消息——包括追加的假设提示词。Canonicalization 会排序对象键所以构建器的插入顺序不会移动哈希任何真实输入变化都会包括日期/工作集/git 元数据、运行时注入、工具发现、提示词设置或路由。tools.active_tool_catalog_sha256是对当前活动工具目录在dialect 塑形之前的独立稳定哈希名称、描述、canonical 逻辑 schema按序。它随成员、顺序与逻辑 schema 变化而移动。它是目录身份而非线事实两条路由在这里一致仍可能发送不同字节因为各 dialect 以各自方式变换 schema、严格模式还会进一步清洗。该哈希的单一定义位于 active_tool_catalog_sha256 函数/tools检查与清单共享同一实现避免两套哈希静默分叉。body.tool_schema_wire_sha256是工具区按 provider 实际收到的样子的哈希。body.local_system_tools_component_sha256把该摘要与最终 wire 系统区摘要合并为本地比较指纹——它不是 provider 缓存键、不声称两区相邻、也不含路由专属的缓存语义保证当工具面不完全已知时被省略。十、披露边界这是可检查性切片不是请求体导出清单是一组固定的计数、哈希、枚举与短来源标签没有任何字段能容纳自由格式的请求文本。它不可能包含系统提示词、项目指令、记忆或技能内容消息内容、tool-result 请求体或附件载荷凭据、Authorization头或查询串URL 路径路径本身可能携带部署密钥绝对工作区或主目录路径。标识符同样不被信任。自定义路由 id 与模型 id 是用户创作的文本可以是绝对路径、URL、URL 路径、或本身就是凭据的部署 id。每个此类值在打印前都穿越 allowlist 边界crate::safe_label实现见 safe_label.rs不含斜杠的通用标识符按原样发布带斜杠的模型 id 还必须精确匹配活动本地模型目录中的某个条目——光有 vendor 前缀不够。其余一律替换为稳定的sha256:12 hex指纹。同一恶意 id 的两次预览仍然可比对相等id 本身永不显示。错误文本同样不被信任且不清洗——它走的是 allowlist。预检、MCP、提示词解析与请求准备失败都会插入主机文本而这些文本常携带路由 id、带引号的服务器名、路径即密钥的 endpoint 或裸凭据。每个空白分隔的 token 都得挣得自己的位置含控制字符的 token 被丢弃URL 只保留scheme://host[:port]且仅当二者本身普通——路径、查询、fragment、userinfo 永不发布token 形态的host会令整个 token 变为不透明而非半发布任何路径形态POSIX 绝对、~/、Windows 盘符或含反斜杠折叠为path-redacted携带、或反引号的 token 整体替换——引号区间正是恶意标识符藏身处其余必须是短普通词ASCII 字母数字加-、_、.长度有界token/密钥形态则拒绝边缘只允许句子标点。其余一切变为redacted连续脱敏区塌缩结果截断。普通诊断句原样存活恶意句变成通用形状。Endpoint 只以两种方式发布有界主机类http loopback或https remote sha256:12 hex与用于同一 endpoint?比对的完整 URL 的 SHA-256 指纹。远程权威authority一律摘要——它可能是凭据形态的租户子域——路径、IDN、userinfo、查询、fragment 从不显示。一条回归测试断言清单中没有任何字段携带序列化消息数组或工具 schema见 request_manifest.rs 与 safe_label.rs 测试。十一、估算就是估算每一个 token 数都是离线估算约 4 字节/token 再加 5% 保守余量永远不是provider 权威计数。它们用于请求之间的相互比较而不是预测账单。字节数、哈希与计数是精确的。tool-result 与附件估算是消息估算的子集仅供归属不再累加进总量。十二、Base-prompt 来源#3928来源、组装、有效哈希受保护清单在不打印有效系统文本的前提下区分三件事单独的/preview-request base-prompt模式只打印精确的有效 base-prompt 字节来源Origin——base-prompt 字节来自哪里bundled in this codewhale-tui build (BASE_PROMPT, compiled in)config-directory override installed at startup (prompts/constitution.md, opt-in enabled)组装Assembly——有效提示词如何构建于该 base 之上base prompt only、base prompt configured static layers、或base prompt configured layers runtime/session additions。有效哈希——已准备请求的系统区的 SHA-256最终 wire 形态的提示词而非独立重组字符串。在真实会话中组装通常是base prompt configured layers runtime/session additions因为环境块、项目上下文、技能与记忆追加在 constitution 之后。Codewhale 不声称配置的 constitution 就是有效 base prompt任何诊断都不引用安装二进制上不存在的源码树路径。实现细节见 preview.rs 的 preview_prompt_provenance 方法 与 base-prompt 运行时来源标签测试。十三、工具面标签塌缩是推导而非断言standard_and_full_surfaces_collapsed是推导出来的不是断言surface shaper 同时以 Standard 与 Full 预算跑过真实当前目录并比较结果。今天它报告true——两个预算产生相同目录——清单用白话说出来而不暗示差异。将来 shaper 一旦对 Standard 收窄得与 Full 不同该字段无需任何文案修改就会自动翻转。任何声称某工具面工具更多的基准结论必须先给出不同的active_tool_catalog_sha256。塌缩推导函数见 standard_and_full_collapse。十四、实战发送前进行零 provider 成本的固定路由 A/B/preview-request使无 provider 的固定路由 A/B成为可能切换路由、用同一提示词预览、比较。操作步骤选择路由/model、/provider或你的 profile——不要发送轮次。运行/preview-request json --prompt 每次相同的文本并保存输出例如glm-5.2.json。对每条路由重复。Diff 这些清单。diff 中该看什么route.dialect/route.route_shape——两条不同 dialect 的路由发送的是结构上不同的请求而不是同一请求到不同主机。route.wire_model——真正上线wire的 id。路由器条目常与你选中的标签不同。tools.active_tool_count/body.tool_schema_wire_sha256——wire 哈希相同即工具字节相同无论 surface 标签说什么。tools.active_tool_catalog_sha256只用于比较逻辑目录两条 dialect 在此一致仍可能发送不同 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——整个请求。若未变出站字节没有任何变化。body.local_system_tools_component_sha256——两条本地实测 wire 组件是否变化。它不证明 provider 缓存复用或失效。route.billing——订阅配额与计量 API 路由不可成本对比unknown意味着成本报告失败即关闭fail closed。每个清单对它所描述的快照都是精确的。只有每个贡献输入都相同时重复预览才逐字节相同路由、当前日期、git 与工作集元数据、提示词设置、工具/MCP 状态、会话历史与挂起的运行时变换。预览不修改会话历史或响应缓存但不做任何跨调用字节稳定性主张。Auto 模式刻意不可用也不能用于此对比直到生产解析出具体路由。十五、schema_version脚本消费者的兼容信号schema_version只要字段被重命名或移除就会递增脚本化消费者因此能检测不兼容清单而不是默默读到null。当前版本是9v8 的work-state-not-snapshottable不可用理由被移除——因为没有请求会携带一个让快照失败的 To-do 块。活动 goal 的 token 预算终结门仍然是一条显式 fail-closed的精确出站请求依赖。常量定义见 MANIFEST_SCHEMA_VERSION 9。十六、仍然近似的东西Auto 路由不被近似它 provider 支撑的分类器从不由预览执行路由相关段以类型化不可用替代。工作集漂移已不在近似列表真实提交在构建turn_meta前调用working_set.observe_user_message预览现在对工作集的克隆做同样观测并从该快照构建块。相同字节无会话写入。其他曾被标记近似的东西现在都被类型化如果运行时变换会改变请求body 段如实声明并一个字节都不发布——而不是发布几乎正确的数字。十七、致谢与设计溯源dryrun概念——从真实请求构建接缝预览下一个请求而非手工拼一个摘要——汲取自 PR #1099作者 TaoMu / GTC2080。该 PR 的代码未被复用此处实现针对 Codewhale 当前的多 dialect 客户端重写。相应的设计注释同时保留在 命令层模块头 与 引擎模块头 中本文不引用任何外部链接。总结/preview-request把下一次出站请求长什么样从黑盒变成一份分段精确、逐字段脱敏、全离线执行的可检查清单。它的工程内核可以概括为四条绝不发布请求文本allowlist 指纹化、绝不执行模型调用Auto 类型化缺席、绝不安装任何状态克隆 值传递、绝不发布几乎为真的数字运行时变换一律类型化不可用。无论你是想在上车前核对路由选择、排查上下文预算、验证 reasoning 控制是否真的上路还是想不花一分钱完成跨路由 A/B这条命令都能给出与生产同一接缝、经回归测试逐字节验证的答案。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考