query

查询技能

使用 3 层搜索和综合，根据 brain 中的知识回答问题。

记忆动词（MEMORY_VERBS v1，gbrain ≥ 0.43）。 通过 MCP 连接到 brain 时，处理记忆相关工作优先使用这 7 个固定的记忆动词——它们会提供来源沿革、证据和由服务端强制执行的令牌预算：

• recall(query | entity, budget_tokens) — 按预算打包的记忆读取。回答“我们保存了关于 X 的哪些信息”时，用它代替裸用 search。
• entity(name) — 无需 LLM 的人物／公司／项目卡片（别名、最近更新、未结事项、主要关联）。只需要卡片时，用它代替 get_page + get_backlinks。
• synthesize(question) — 明确成本较高的跨页面回答；这是 query 的强化版本。只有在答案必须综合多个页面的证据时才使用。 如果这些动词不可用（0.43 之前的服务；--surface full 会在包含其他所有操作的同时提供这些动词），则回退使用 search/query/get_page。参见 docs/protocol/MEMORY_VERBS_v1.md。

约定

此技能保证：

• 每个回答均以 brain 内容为依据（不产生幻觉）
• 每条断言都附有可追溯至特定页面 slug 的引用
• 明确标示信息缺口（“brain 中没有关于 X 的信息”）
• 遵循来源优先级（用户陈述 > 编译后的真相 > 时间线 > 外部来源）
• 标明相互冲突的来源，并附上双方引用

阶段

1. 拆解问题，制定搜索策略：
   • 对具体名称、日期和术语进行关键词搜索
   • 对概念性问题进行语义查询
   • 对关系类问题进行结构化查询（按类型列出、反向链接）
2. 执行搜索：
   • 使用 gbrain 进行低成本混合搜索，查找确切词条／已知名称（search）
   • 使用 gbrain 进行完整混合搜索，处理概念性问题（query；--expand 会添加多查询扩展）
   • 按类型列出 gbrain 中的页面，或检查反向链接以进行结构化查询
   • 使用筛选条件缩小范围，而不是对 brain 检出目录进行 grep：--types '["meeting"]'、 --match keyword、gbrain query "<q>" --since 2026-09-01 --until 2026-09-30、--source <id>。 可直接复制的示例见 skills/conventions/brain-first.md 中的“检索：优先使用 gbrain”。
3. 阅读排名靠前的结果。 阅读 gbrain 返回的前 3-5 个页面，了解完整上下文。
4. 综合答案并附上引用。每条断言都必须可追溯至特定页面 slug。
5. 标明信息缺口。 如果 brain 中没有相关信息，请说“brain 中没有关于 X 的信息”，不要编造。先阅读结果通知（参见“发生错误时”）：结果降级或被截断并不代表存在信息缺口。

发生错误时

遇到任何 gbrain 错误 code、退出代码、[AGENT] 区块或通知区块时，请遵循Agent 操作员协议。本技能的具体要求如下：

• 回答前检查每个检索结果的通知：在 MCP 中，额外文本区块的首行可能类似 [gbrain notice empty_retrieval kind=degraded]，这些通知也会映射到 _meta.gbrain_notices；在 CLI 中，则查看 [AGENT] 区块、search_degraded 或 note: search degraded 行。
• empty_retrieval 且 kind=degraded（或 search_degraded: keyword_only_no_embedding_provider）：结果为空并不能证明用户没有相关笔记。告诉用户“你的 brain 目前只能搜索关键词，因此我可能会漏掉关于 X 的笔记”，尝试使用确切名称和同义词运行 gbrain search，并指出通知中给出的修复方法（通常是启用嵌入）。
• empty_retrieval 显示“no retrieval degradation — this is a clean miss”：此时应说“brain 中没有关于 X 的信息”。
• listing_truncated 或 budget_truncated：列表被截断了。说明“当前显示前 N 项”，并在断言某项不存在之前，翻页或缩小查询范围。
• get_page 返回 page_not_found：slug 错误或页面位于其他来源中；报告页面缺失之前，应按标题搜索（并检查 --source）。

反模式

• 当知识库中有相关内容时，仍根据常识作答
• 臆造知识库中没有的事实
• 来源存在冲突时，默默选取其中一个
• 搜索结果片段已足够时，仍加载完整页面
• 忽略来源优先级（用户陈述具有最高权威性）

输出格式

回答应包括：

• 对问题的直接答复
• 引用：“根据 [Source: people/jane-doe, compiled truth]……”
• 信息缺口标记：“知识库中没有关于 X 的信息”
• 来源存在分歧时的冲突说明

质量规则

• 绝不臆造。只根据知识库内容作答。
• 引用来源：“根据 concepts/do-things-that-dont-scale……”
• 标记过时结果：如果搜索结果显示 [STALE]，请注明信息可能已过时
• 对于“谁”的问题，使用反向链接和类型化链接查找关联
• 对于“发生了什么”的问题，使用时间线条目
• 对于“我们知道什么”的问题，直接阅读 compiled_truth

Token 预算感知

搜索返回的是片段，而非完整页面。请先阅读摘录，再决定是否加载完整页面。

对于预算紧张且涉及已保存页面证据的问题，请明确选择 recall，并设置 budget_policy: "query_first"。这样会优先将预算用于现有的排名靠前的页面结果，再用剩余预算打包近期或经过筛选的事实。这是一种可选的打包方式，并非新的相关性模型：不相关的页面可能会挤掉有用事实。以实体为先、按会话／事件筛选以及聚焦事实的问题，仍应沿用现有的 facts-first 路径。不要更改 context_pack 或现有的第三方调用。

gbrain recall --query 'zebra telescope' --budget-tokens 75 --budget-policy query_first --json

等效的 MCP 请求：

{"name":"recall","arguments":{"query":"zebra telescope","budget_tokens":75,"budget_policy":"query_first"}}

对你的 Agent 说：“使用估算预算为 75 个 token 的 query-first 打包方式，回忆有关斑马望远镜的已保存笔记。请引用返回的证据；如果第一个页面无法装入，请告诉我，不要把这当作记忆缺失。”

照常使用解析出的 brain 和 source；此选项不会扩大权限范围。budget_packing 会报告实际生效的策略，以及每个臂的候选／保留／丢弃／已用数量。成本按 ceil(fact.length/4) 或 ceil(title.length/4) + ceil(chunk.length/4) 估算，并非精确的分词器或 JSON 封装大小。打包时不会跳过超出预算的前缀项，也不会截断该项；多个必需页面仍可能无法装入。若查询为空或仅含空白，或预算不是正的有限值，该操作会保留旧版行为。符合条件的正预算若低于 1 个 token，则会返回空臂。小数预算的兼容性请参阅协议。

这些指导和公布的工具架构并不能证明已采用原生 harness。只有在新的 harness 对话中确认观察到 query-first 调用后，才能声称已启用；否则应报告采用情况未经验证。

• gbrain search / gbrain query 会返回带有上下文片段的排名结果。这通常足以直接回答问题。
• 对话页面（会话、转录、会议、聊天记录）的命中项默认会以整个会话的形式返回（return_unit: "auto"，默认预算为 24,000 个 token）。对于其他多页面问题，或答案取决于上下文而非单个片段的“X 何时发生变化”这类问题，请在同一次调用中请求完整证据：return_unit: "page"（整个页面，按 token_budget 控制预算，默认值为 6,000）或 "window"（相邻片段）。return_unit: "chunk" 则表示退出此模式。 此时，每条结果都会在 chunk_text 中携带证据，并包含一个 delivered 区块；请参阅证据传递。 gbrain query "when did the launch move?" --return-unit page --token-budget 6000
• 仅当片段证实页面相关且你需要更多上下文（例如，整合后的真相、时间线）时，才使用 gbrain get <slug> 加载完整页面。
• “告诉我有关 X 的信息” —— 获取完整页面（用户想了解全貌）。
• “有人提到过 Y 吗？” —— 搜索结果就足够了（用户想要的是有证据支持的“是／否”答案）。

来源优先级

多个来源提供的信息相互矛盾时，请按以下优先级处理：

1. 用户的直接陈述（权威性最高——用户直接告诉你的内容）
2. 整合后的真相（brain 综合并引用的理解）
3. 时间线条目（原始证据，按时间倒序排列）
4. 外部来源（网络搜索、API 补充信息——权威性最低）

来源冲突时，请附上双方的引用并指出矛盾。不要默默选取其中一方。

回答中的引用

在回答中引用 brain 页面时，请保留行内引用：

• 引用页面：“根据 [Source: people/jane-doe, compiled truth]……”
• brain 页面含有行内 [Source: ...] 引用时，请保留这些引用，以便用户追溯事实来源
• 综合多个页面的信息时，请引用所有来源

图遍历（v0.10.1+）

对于关系类问题（“X 处谁认识谁？”，“A 和 B 之间有哪些联系？”，“谁在 Acme 工作？”，“谁参加了站会？”），请使用图层，而非全文搜索：

• gbrain graph-query <slug> --type <link_type> --depth N --direction in|out|both
• 可用的链接类型：attended、works_at、invested_in、founded、advises、mentions、source
• --direction in 用于回答“谁指向 X？”（例如，谁在公司 X 工作）
• --direction out 用于回答“X 指向什么？”（默认值）
• --depth N 用于控制多跳遍历（默认值为 5）

示例：

• “谁在 Acme 工作？” → gbrain graph-query companies/acme --type works_at --direction in
• “谁参加了 Demo Day W26？” → gbrain graph-query meetings/demo-day-w26 --type attended --direction out
• “Emily 曾为哪些公司提供过建议？” → gbrain graph-query people/emily --type advises --direction out
• “Alice 通过会议见过谁？” → gbrain graph-query people/alice --type attended --depth 2

对于同时需要语义相似度和图结构的查询，可结合使用 gbrain query。搜索结果会获得少量反向链接加权，因此关联较多的实体排名会更高。

搜索质量提示

如果搜索结果似乎不理想（结果错误、缺少已知页面或命中无关内容）：

• 运行 gbrain doctor --json 检查索引健康状况
• 检查嵌入覆盖率——嵌入不完整会降低混合搜索的效果
• 对同一查询比较关键词搜索（gbrain search）与混合搜索（gbrain query），以判断问题是否与嵌入有关
• 在维护工作流中报告搜索质量问题（请参阅维护技能）

使用的工具

• gbrain 关键词搜索（search）
• gbrain 混合搜索（query）
• 从 gbrain 读取页面（get_page）
• 使用筛选条件列出 gbrain 中的页面（list_pages）
• 检查 gbrain 中的反向链接（get_backlinks）
• 遍历 gbrain 中的链接图（traverse_graph）
• 查看 gbrain 中的时间线条目（get_timeline）