fable-context-thrift

Fable Context Thrift

上下文是一切其他工作的预算来源。把它花在会改变下一步行动的内容上；除此之外，别无他用。

目的

防止上下文膨胀、令牌耗尽、不必要的整文件读取、冗余验证和顺序执行延迟。fable-context-thrift 将上下文令牌和工具调用视为稀缺且宝贵的工程预算。

适用场景

• 在任何多步骤任务开始时，以及探索代码库期间。
• 读取文件、搜索符号或检查仓库结构之前。
• 想要读取整个文件，而不是有针对性地查看片段、符号或函数时。
• 执行多个彼此独立且可并行批处理的查询或检查时。

不适用场景

• 需要绘制未知子系统结构图的全面代码库探索（使用 fable-discover）。
• 外部 API 文档和一手资料研究（使用 fable-research）。
• 跨分布式信任边界进行深入漏洞追踪（使用 fable-security）。

输入

• exploration_intent：需要解决的具体关键问题或不确定因素。
• workspace_state：已确认的事实、打开的文件以及先前的工具输出。

预期输出

• targeted_evidence：最少且高信号的代码摘录、行号引用和确切事实。
• decision_readiness：确认已达到“足以采取行动”的标准，且没有多余令牌。

流程

1. 有针对性的读取策略：只读取所需的符号或部分，而不是整个文件。只有具体问题需要时才扩大范围。
2. 并行批处理：多个 grep、读取或状态检查必须在一个并行批次中发出。按顺序执行彼此独立的读取只会增加延迟，并不代表更谨慎。
3. 委派全面检索，直接处理单项查询：宽泛问题（“X 在哪里处理”“在陌生区域查找所有用法”）交给可用的搜索子 Agent；保留结论，而不是文件转储。已知位置的单项查询直接处理。只有在你不知道内容所在位置时才使用子 Agent。
4. 工具确认原则：绝不要为了确认编辑是否生效而重新读取文件；编辑工具会明确报告失败。用一次低成本的最终状态检查（例如 grep 查找旧令牌）验证结果，而不是逐个文件重新读取。
5. 保留已确认事实：对话中已经验证的内容，不要重新推导。用户已经决定的事项，不要重新讨论。
6. 消除叙述开销：不要叙述不会采纳的选项。只对你可能实际采取的选择进行权衡。
7. 足以采取行动测试：如果继续探索也不会改变下一步行动，就该结束探索。开始行动。

决策规则

想法	现实
“我会读取整个文件来了解上下文”	只读改动涉及的内容。你要回答的问题决定所需的行。
“我再确认一下编辑是否生效”	工具已报告成功；没有报错就代表成功。一次最终状态 grep 胜过 N 次重新读取。
“我再搜一次以防万一”	如果结果不会改变你的行动，那就不是谨慎，而是拿着证据拖延。
“我先重新确认一下仓库布局”	相关信息就在上下文中，而且一小时前还是准确的。目录树不会在会话中途腐烂。
“一次只调用一个工具才谨慎”	谨慎意味着调用正确的工具。按顺序进行彼此独立的查询，只会让同样的工作变慢。
“我会派一个子 Agent 去做全面检索”	对于一个有 40 个文件的仓库，grep 得到行级事实，比子 Agent 返回文字更快。根据实际情况选择工具。

• 如果额外的搜索结果不会改变你的下一条命令或编辑，就不要搜索。
• 编辑顺利完成后，直接验证，不要再次查看修改后的文件。

工具策略

• 将所有相互独立的读取和 grep 工具调用合并到同一条消息／轮次中。
• 查看文件时使用行偏移和定向切片（StartLine、EndLine）。
• 如果 ripgrep 已提供确切行号，则拒绝读取整个文件。
• 定位符号时，优先使用定向 ripgrep 查询，而不是遍历文件树。

证据要求

• 提供行级引用（path/to/file#L10-L25），而不是将完整函数体倾倒到对话中。
• 使用单次最终状态检查（例如，grep 查找已删除的标记或检查退出代码）作为编辑已应用的证明。
• 保留已确立的事实，无需在同一会话中重复执行来举证。

故障处理

遇到以下任何危险信号时，立即停止消耗资源：

• 读取本轮已编辑文件的 Read 调用。
• 同一事实在一次会话中被验证两次。
• 连续的工具调用之间没有数据依赖关系。
• 无法说明其决策目的的探索步骤。
• grep 已提供行号，却仍然读取整个文件。

完成标准

• 用最少的 token 回答关键问题。
• 明确后续工程操作，使其可以顺利开展。
• 为实现、验证和差异审查留出上下文空间。