学习一下 /btw 的实现机制。 因为 claude code agent 采用的是经典的 ReAct(Reasoning and Acting)单循环。所以我很好奇这个 /btw 是如何在 单 loop 中优雅实现的。 以下内容是通过结合Piebald-AI 逆向工程项目、OutSight AI 的 MITM 代理分析,以及claude code 官方文档整理而来。 --- /btw 在不破坏 claude code 单 Loop 简洁性的前提下,通过"降级调用"(无工具、单次响应)实现轻量级的侧信道交互。 该功能最早在 2025 年 12 月前后出现在二进制中(约 v2.0.73),经过多版本迭代后于 2026 年 3 月正式完善,现已在官方文档中有明确说明。 根据 Claude Code 官方文档(),/btw 被明确定位为 sub-agent 的"逆运算": /btw is the inverse of a subagent: it sees your full conversation but has no tools, while a subagent has full tools but starts with an empty context. 主 Loop 是"有上下文 + 有工具"的完整 Agent;/btw 和 sub-agent 分别是它在两个维度上的降维投影。 三者形成了一个完整的能力矩阵。 我主要是在想,/btw 实现机制是什么样的,才不会破坏 kv 缓存。 Claude Code 使用一套统一的 `<system-reminder>` XML 标签机制来动态修改模型行为。这不是 /btw 独有的,而是一个被约 40 个不同功能共用的基础设施(包括 Plan Mode、文件修改通知、Token 用量提醒等)。 根据 OutSight AI 通过 LiteLLM 代理拦截实际 API 调用的分析,system reminder 是作为 user 角色消息中的额外 text content block 注入的,而不是修改 system prompt。 结合官方文档确认"Claude cannot read files, run commands, or search when answering a side question",工具禁用很可能采用了双重保险策略: API 层: 通过设置 tool_choice: "none" 或省略 tools 数组,从 API 层面彻底阻断工具调用 Prompt 层: System reminder 中明确指示"you have NO tools available",从模型行为层面强化约束 正常情况下 Claude Code 提供 18 个内置工具(Bash、Read、Write、Edit、MultiEdit、Glob、Grep、LS、WebFetch、TodoRead、TodoWrite、Task 等),在 btw 调用中全部被禁用。 /btw 不是在主 loop 中"插队",而是发起了一个独立的 API 调用。主任务继续处理,btw 的调用并行执行。这解释了为什么它能在 Claude 还在工作的时候响应 side question。 /btw 的问答以可关闭的 overlay 形式展示,绝不写入主对话的 messages 数组。这意味着主任务恢复时,对话状态和 btw 之前完全一样,没有任何上下文污染。 由于 btw 调用复用了主对话的完整历史作为上下文,而 system prompt 和前面的对话 turn 都不变,只有最后一条 user message 是新的,因此前缀部分自然命中缓存。额外成本仅为 172 tokens 的 system reminder + 用户问题 + 模型响应。 用户按 Space、Enter 或 Escape 关闭 overlay 并返回主提示符。整个交互在终端的叠加层中完成,不影响底层的主对话流。 由于 btw 的问答完全不写入主对话历史,主任务恢复时发送的 messages 数组和 btw 之前完全一致。因此,主对话的 prompt cache 零损耗。这是整个设计中最优雅的部分。
AlexZ 🦀
4个月前
有意思。 Python 核心开发者发布了一份草案,从 Python 3.15 开始引入 Rust,先可选;到 3.17 版本 Rust 成为 CPython 构建的硬性依赖。 Python 官方计划在 3 年内将 Rust 正式纳入其核心实现。这是 Python 历史上最大的一次语言级重构方向变更之一。 当然,这仅仅是一份草案,先听取社区意见。 然而,这篇帖子下面的评论就更有趣了: 1. 评论区 没有负面情绪,没有喷子,没有“反 Rust 派”!!! 2. 核心开发者(CPython committers)大多支持方向。包括:Guido(Python之父)/ Emma(提案作者)/ David Hewitt(PyO3 maintainer)/ Steve Dower / Antoine Pitrou / Alex Gaynor / Nathan Goldbaum 等等 这些人对 Rust 的态度主要是:“方向正确 -> 需要精细设计 -> 不能一次做太大 -> 安全抽象必须完善 -> Timeline 合理”,没有人提出对 Rust 本身的否定。 3. Guido 则明确支持,认为 Rust 进入 CPython 是好事,还开玩笑说,CPython 是不是要改名成 CRPython ,“Do we eventually have to rename CPython to CRPython?” 4. Rust 生态本身也站在支持 CPython 方向的一边。PyO3 作者主要讨论的是 bindgen 是否能取代 pyo3-ffi?如何复用 PyO3 经验但不直接依赖 PyO3 ?等问题。 5. 少数开发者表达谨慎,不是反对,而是担忧:会不会出现类似 Rust for Linux 的“文化摩擦”问题 ?binary size 增大 以及是否会让 CPython 变复杂 等问题。 不得不说,Python 社区的技术讨论氛围还是非常不错的。