用途
fable-context-thrift 的核心主张是：上下文是其他一切开销所依赖的预算，应当只花在会改变下一步行动的信息上。它用于防止上下文膨胀、token 耗尽、不必要的整文件读取、冗余验证以及串行执行带来的延迟，把上下文 token 和工具调用当作稀缺且有价值的工程预算来管理。
何时使用
- 在任何多步任务的开始阶段，以及探索性代码库调查期间。
- 在读取文件、搜索符号或检查仓库结构之前。
- 当倾向于读取整个文件，而不是读取有针对性的片段、符号或函数时。
- 当需要执行多个相互独立的查找或检查、且可以并行批处理时。
何时不使用
- 需要对未知子系统进行结构映射的全面代码库发现（应使用 fable-discover）。
- 外部 API 文档与一手资料研究（应使用 fable-research）。
- 跨分布式信任边界的深度漏洞追踪（应使用 fable-security）。
输入
- exploration_intent：需要解决的具体、承重的问题或不确定性。
- workspace_state：已确立的事实、已打开的文件以及先前的工具输出。
预期输出
- targeted_evidence：最小化、高信号的代码摘录、行引用和确切事实。
- decision_readiness：确认已达到“足够行动”的标准，且没有多余 token。
操作流程
- 目标读取策略：只读取所需的符号或段落，而不是整个文件；仅当某个具体问题要求时才扩大范围。
- 并行块批处理：多个 grep、读取或状态检查必须放在一个并行块中派发；把相互独立的读取串行化只会增加延迟，并不代表更谨慎。
- 委派扫描与保留查找：宽泛的问题（例如“X 在哪里处理”、在不熟悉区域查找全部用法）在可用时交给搜索子代理，只保留结论而非文件转储；已知的单次查找则直接进行。子代理适用于不知道东西在哪里的情况。
- 工具确认原则：绝不要为了检查编辑是否生效而重读文件，编辑工具失败时会明确报错；用一个廉价的终态检查（例如 grep 旧 token）来验证结果，而不是逐文件重读。
- 保留既有事实：对话已经验证过的内容不要重新推导；用户已经决定的事情不要重新打开。
- 消除叙述开销：不要叙述你不会采取的选项；斟酌只用于你可能真正做出的选择。
- 足够行动测试：如果更多探索不会改变你的下一步行动，探索就结束了，应当行动。
决策规则
- “我会读整个文件来获取上下文” → 读取改动所触及的部分；你要回答的问题决定了你需要的行。
- “让我再确认一下我的编辑是否生效” → 工具已报告成功，沉默即成功；一次终态 grep 胜过 N 次重读。
- “再搜一次以防万一” → 如果结果不会改变你的行动，那就不是安全，而是带着凭证的拖延。
- “我先重新验证一下仓库布局” → 它已在你的上下文中，一小时前还是正确的；目录树不会在会话中途腐烂。
- “谨慎意味着一次只调用一个” → 谨慎意味着正确的调用；把相互独立的查找串行化是同样的工作，只是更慢。
- “我会派一个子代理来做到彻底” → 在 40 个文件的仓库上，grep 返回行级事实比子代理返回散文更快；让工具匹配领域。
此外：如果额外的搜索结果不会改变你的下一条命令或编辑，就不要进行该搜索；当编辑干净地成功时，直接进入验证，不要再次查看被修改的文件。
工具策略
- 把所有相互独立的读取和 grep 工具调用批处理到单条消息/单轮中。
- 查看文件时使用行偏移和目标切片（StartLine、EndLine）。
- 当 ripgrep 已提供确切行号时，拒绝整文件读取。
- 定位符号时，优先使用有针对性的 ripgrep 查询，而不是遍历文件树。
证据要求
- 报告行级引用（path/to/file#L10-L25），而不是把完整函数体倾倒进对话。
- 使用单次终态检查（例如 grep 已删除的 token 或退出码）作为编辑已应用的证明。
- 保留既有事实，无需在同一会话中重复执行证据。
失败处理
遇到以下任一红旗信号时立即停止消耗：
- 对本轮已编辑的文件发起 Read 调用。
- 同一会话中对同一事实验证两次。
- 相互之间没有数据依赖的串行工具调用。
- 无法说出对应决策的探索步骤。
- 在 grep 已给出行号的情况下仍进行整文件读取。
完成标准
- 承重问题以最少 token 消耗得到回答。
- 下一步工程行动已解除阻塞且清晰明确。
- 上下文空间被保留给实现、验证和 diff 审查。
限制
该技能不适用于需要全面结构映射的未知子系统发现、外部 API 文档与一手资料研究，以及跨分布式信任边界的深度漏洞追踪，这些场景应改用其他对应技能。