Lark Loom

团队做项目的 context 其实都在 IM 里，需求、结论、分工全是聊出来的。

但这些内容没办法很好地变成模型可以消费的东西，所以后面要辅助产出文档、分工表、汇报材料的时候，模型用不上这些 context。

为什么会这样，要看 IM 协作这个场景本身。IM 里的信息是碎片化的：一个需求可能散在几天的几十条消息里，中间夹着闲聊和别的话题，说法也很口语。而模型要辅助产出，需要的是和当前任务相关、完整、干净的上下文。

所以这个场景本质上是两个问题：

• 储存：怎么把聊天里的 context 更好地存下来。
• 筛选：在需要的时候，怎么准确地选出对应的 context，用来帮用户辅助生成内容。

Lark Loom 是一个住在飞书群聊里的项目协作 Agent。它持续监听群聊，不需要 @ 就能感知意图，把群里的讨论变成需求文档、分工表格、演示文稿这些结构化产出。产出就落在团队本来工作的地方：分工表进飞书多维表格，需求和会议纪要进飞书云文档，汇报材料是原生的飞书幻灯片。它的设计对应刚才的两个问题。

储存这一侧是 Memory。 群里的讨论会被整理成结构化的记忆存下来，而不是只留原始消息。

筛选这一侧是召回。 每种产出能力是 13 个预置 Skill 中的一个，只有问答 Skill 需要 @。Skill 执行时，按当前任务从 Memory 里选出对应的 context，再交给模型生成内容。

我主要做了两件事。

重做了储存和筛选。 原来的做法是直接对历史消息做语义相似度检索，取 top-20 给模型。问题是 IM 消息太碎，语义相近的不一定是当前任务需要的，召回的内容会漂。我改成了两步：

• 储存：用 Seed 1.5 Lite 把消息抽取成结构化的 Memory。
• 筛选：按关键词和任务类型两路定向提取。关键词用精确匹配来收敛语义漂移，任务类型用来限定召回范围。

在一个 60 条的评测集上，通过率从 65% 提到 80%。

按子任务的复杂度分层调用模型。 上下文抽取、结构化这类确定性的处理交给 Seed 1.5 Lite，Seed 2.0 Pro 只做核心的推理和生成，减少大模型要处理和输出的 token。单任务平均响应时间从 95 秒降到 50 秒，降了 47%，人工抽检质量没有明显差异。

怎么衡量存和选做得好不好？看两个指标。

• 质量：评测集上的通过率。这个评测集是从任务完成的维度和模型的推理链里提炼出来的，看的不是召回了什么，而是模型拿到这些 context 之后能不能把任务做对。
• 速度：单任务的平均响应时间。Agent 住在群聊里，回得太慢，对话的节奏就断了。