honey-hive

Honey Hive

委托处理令牌密集型的阅读工作，保留思考。一名子 Agent 的返回结果会注入你的上下文——Honey Hive 会以压缩后的 Lever-3 交接内容返回结果，因此，智能体会话中最耗费令牌的部分可缩减约 25–55%，而协调器可用的信息不会有任何损失。

何时委托（满足任一条件即可）

• 搜索密集型——需要跨多个文件查找“X 在哪里 / 谁调用了 Y / 找出所有 Z” → hive-scout。
• 审查密集型——审查差异或一组文件，查找错误和臃肿之处 → hive-reviewer。
• 保留上下文——阅读会将许多文件内容倾倒进上下文，但你只需要结论。
• 并行处理——彼此独立的定位 / 审查任务，可同时运行。

何时不要委托（直接处理）

• 只有一个已知文件、只需简单编辑，或相关内容已在上下文中。
• 调度和返回的开销超过自己直接阅读的成本（只有一两个文件）。
• 你需要完整的文件正文，而非概览。

这支团队的设计初衷是只读——他们负责定位和审查，由你决定并编辑。

团队成员

Agent	工作内容	返回内容
hive-scout	定位符号 / 调用方 / 配置 / 模式	紧凑的、以 ID 为键的 JSON 映射
hive-reviewer	审查差异 / 文件中的错误、过度设计和冗长之处	按列排列的、以 ID 为键的 JSON 问题清单

阅读 Hive 返回结果（反向使用 Lever 3）

每个返回结果都是紧凑的、按列排列的 JSON，记录通过稳定的 id 标识，并包含 n 计数。请将其视为数据来读取：

• 通过 id 定位，切勿说“第 3 个问题”——序号查找容易解析错误，前沿模型也不例外。
• 在代码中汇总——需要计数或筛选时，以编程方式处理，不要目测表格行。
• 核对 n，确保它与收到的行数一致——密集数据解析错误时不会发出提示。
• 安全例外——有关身份验证 / 金钱 / 迁移 / 删除的问题会明确返回，不会被缩写。请原样处理。

ESON 为可选项：仅在你端到端负责的高吞吐量、带缓存的审查流水线上请求使用。