推荐设置

推荐设置¶

从 recent 开始：

{
  plugins: {
    entries: {
      "active-memory": {
        enabled: true,
        config: {
          agents: ["main"],
          mode: "escalate",
          queryMode: "recent",
          promptStyle: "balanced",
          timeoutMs: 15000,
          maxSummaryChars: 220,
          logging: true,
        },
      },
    },
  },
}

调优时，使用 /verbose on 查看状态行，使用 /trace on 查看调试摘要——两者都在主回复之后作为后续消息发送，而非在此之前发送。仅在每个符合条件的轮次都值得承担该延迟时才使用 always。保留 escalate 以获得推荐的平衡，然后针对深度召回查询本身选择 message、recent 或 full。

冷启动宽限期¶

在 v2026.5.2 之前，插件会在冷启动期间静默地将 timeoutMs 额外延长 30000 毫秒，从而使模型预热、嵌入索引加载和首次召回可以共享一个更大的预算。v2026.5.2 将该宽限期移到了显式的 setupGraceTimeoutMs 配置项后面：除非你选择启用，否则 timeoutMs 默认只是召回工作的预算。阻塞钩子将该预算分为两个固定阶段：召回开始前，最多 1500 毫秒用于会话/配置预检；召回工作结束后，另有固定的 1500 毫秒用于中止结算和转录恢复。这两种额度都不会延长模型或工具的执行时间。

如果你从 v2026.4.x 升级而来，并且曾针对旧的隐式宽限期调整过 timeoutMs（推荐的初始 timeoutMs: 15000 就是一个例子），请设置 setupGraceTimeoutMs: 30000 以恢复 v2026.5.2 之前版本的有效预算：

{
  plugins: {
    entries: {
      "active-memory": {
        config: {
          timeoutMs: 15000,
          setupGraceTimeoutMs: 30000,
        },
      },
    },
  },
}

最坏情况下的阻塞时间为 timeoutMs + setupGraceTimeoutMs + 3000 毫秒（即配置的召回工作预算，加上最多 1500 毫秒预检，再加上固定的 1500 毫秒召回后完成宽限）。内嵌的召回运行器使用相同的有效超时预算，因此 setupGraceTimeoutMs 同时覆盖外部提示构建看门狗和内部阻塞式召回运行。

对于资源紧张的网关，如果冷启动延迟是接受范围内的权衡，那么较低的值（5000-15000 毫秒）也同样可行——代价是网关重启之后、预热完成前的首次召回返回空结果的概率会更高。