OmniRoute Context Relay 上下文中继Combo 账户轮换时的会话连续性保持机制【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoutecontext-relay是 OmniRoute 提供的一种 Combo 策略用于解决多账户配额轮换场景下的会话断裂问题当同一 Combo 中的活跃账户在对话结束前因配额耗尽而切换时系统会在账户耗尽前自动生成紧凑的结构化摘要并在账户切换后将该摘要以系统消息的形式注入下一次请求从而让新账户无缝接管任务。读完本文你将掌握context-relay的运行时机、交接载荷结构、配置字段、源码实现路径以及推荐的使用模式。本文以 德语版官方文档与 中文版 内容一致为主体并结合 contextHandoff.ts 与 contextHandoffs.ts 的源码进行深度讲解。核心思路优先级路由 交接层context-relay在当前运行时中表现为模型选择阶段仍然执行与普通 Combo 相同的优先级路由只是在此之上额外叠加了一层上下文交接handoff。整个机制由三步构成在活跃账户配额耗尽之前OmniRoute 在后台生成一份紧凑的结构化摘要当身份认证为同一会话解析到不同账户时OmniRoute 将该摘要作为系统消息注入下一次请求交接被成功消费之后会从存储中移除避免重复注入。这套设计的关键前提是配额可见性只有当服务商暴露了足够的配额信息、能预测账户即将达到限制时系统才能提前安排摘要生成。适用场景context-relay并非默认启用所有 Combo 的策略而是需要同时满足以下条件时才值得使用Combo 预期会在同一服务商的多个账户之间轮换丢失短期会话连续性会损害任务质量服务商暴露了足够的配额信息以预测即将达到的账户限制。该策略对可能超出单个账户窗口的长时间编程或研究会话最为有用——例如一个持续数小时的代码重构任务若中途账户切换导致新账户丢失了之前的决策与进度上下文任务质量会明显下滑。运行时流程按配额水位分阶段的交接调度context-relay的行为被刻意拆分为两个运行时层并以配额使用比例作为触发依据。其阈值常量在 contextHandoff.ts 中定义为HANDOFF_WARNING_THRESHOLD 0.85与HANDOFF_EXHAUSTION_THRESHOLD 0.95。配额用量 0% ~ 84%不生成交接请求行为与普通优先级路由完全一致不产生任何额外开销。此时账户余量充足无需预生成摘要。配额用量 85% ~ 94%后台生成交接摘要如果活跃服务商位于handoffProviders白名单中OmniRoute 将在账户完全耗尽前于后台生成结构化交接摘要。此阶段的关键约束如下默认警告阈值为0.85handoffThreshold摘要生成的硬停止线为0.95超过后不再发起新的摘要请求每个sessionId comboName组合只允许一个进行中的交接生成通过内存中的inflightHandoffGenerations集合保证见 contextHandoff.ts如果该会话/Combo 已存在活跃交接则不会生成重复摘要hasActiveHandoff判断。配额用量 ≥95%停止生成系统此时已处于或接近耗尽状态运行时会避免再调度一次摘要请求防止在配额耗尽边缘浪费额外的上游调用。账户轮换后注入交接当同一会话的下一次请求经身份认证解析到不同的认证账户时OmniRoute 将存储的交接载荷转换为context_handoff系统消息并前置注入请求。注意注入仅在实际账户切换被确认之后发生——如果请求仍然落在同一账户上则不会注入。从源码调用链看combo.ts 在 Combo 路由选中目标后会通过fetchCodexQuota(connectionId)获取配额信息percentUsed、各窗口resetAt再调用maybeGenerateHandoff决定是否生成交接而maybeGenerateHandoff内部依次检查handoffProviders是否为空、percentUsed是否达到阈值且低于 0.95、是否存在进行中或活跃的交接全部通过后才通过setImmediate异步执行真正的摘要生成contextHandoff.ts。交接载荷结构与落库持久化的交接载荷存储在context_handoffs数据表中对应的数据访问层见 contextHandoffs.ts完整字段如下字段含义sessionId会话标识与comboName共同构成交接的作用域主键comboName所属 Combo 名称fromAccount生成交接的源账户connectionIdsummary紧凑摘要正文keyDecisions关键决策列表JSON 数组存储taskProgress任务进度已完成、待完成、下一步activeEntities活跃实体列表如文件名、功能、服务商等messageCount参与摘要的源消息条数model生成摘要所用模型warningThresholdPct生成时的警告阈值默认 0.85generatedAt生成时间expiresAt过期时间默认 TTL 为 5 小时upsertHandoff使用INSERT ... ON CONFLICT(session_id, combo_name) DO UPDATE SET ...实现同一作用域下的覆盖写保证每个sessionId comboName最多只有一份交接contextHandoffs.tscleanupExpiredHandoffs以 30 分钟为节流间隔清理过期记录contextHandoffs.ts。摘要模型的 JSON 输出结构摘要模型被指示返回严格结构的 JSON 对象{ summary: 对连续性重要内容的紧凑摘要, keyDecisions: [决策 1, 决策 2], taskProgress: 已完成项、待完成项以及下一步, activeEntities: [fileA.ts, 功能 X, 服务商 Y] }在 contextHandoff.ts 中可以看到实际的HANDOFF_PROMPT_TEMPLATE其硬性约束包括summary不超过 200 词、keyDecisions与activeEntities为数组、只返回 JSON 对象不附带 markdown 与任何解释。解析侧parseHandoffJSON还会做防御性处理剥离代码围栏与omniModel标签、在 JSON.parse 失败时截取首尾大括号区间、并对字段做长度与条数上限约束summary 上限 2000 字符、taskProgress 上限 1200 字符、keyDecisions 最多 8 条、activeEntities 最多 10 条摘要缺失时整体判定为不可用contextHandoff.ts。注入时的系统消息形态注入时OmniRoute 将载荷转换为context_handoff系统消息buildHandoffSystemMessage典型形态如下context_handoff transfer_reasonAccount quota transfer - continuing from previous session/transfer_reason session_summary.../session_summary task_progress.../task_progress key_decisions - 决策 1 /key_decisions active_contextfileA.ts, 功能 X/active_context messages_processed42/messages_processed /context_handoff You are continuing a conversation that was transferred from another account due to quota limits.完整实现见 contextHandoff.ts。XML 内容均经过escapeXml转义防止摘要文本破坏消息结构。注入逻辑injectHandoffIntoBody同时兼容 Chat Completions 风格的messages数组与 Responses API 风格的instructions字段contextHandoff.ts。配置字段与生效范围context-relay支持以下配置字段字段默认值说明handoffThreshold0.85摘要生成的警告阈值取值范围须大于 0 且小于 0.95否则回退默认值handoffModel空可选模型覆盖仅用于摘要生成留空则沿用请求当前模型handoffProviders[codex]允许触发交接生成的服务商白名单在resolveContextRelayConfig中可以看到更多可调参数contextHandoff.tsmaxMessagesForSummary参与摘要的最近消息条数范围 5~100默认 30与relayModeschema-locked或standardschema-locked 模式下摘要源消息只取非系统消息且不会在 token 超限时保留系统提示词。全局默认值可在Settings设置中配置Combo 特定值可在Combos组合页面覆盖。架构说明为何不使用独立处理器当前实现没有独立的handleContextRelayCombo处理器而是刻意拆成两个环节combo.ts 在成功回合的尾部判断是否应生成交接依据配额百分比、服务商白名单、会话绑定等请求处理器即文档所述 chat.ts 所在的 SSE 处理层仅在身份认证解析出请求实际使用的账户之后才注入交接。这种拆分是刻意的Combo 循环本身并不知道请求最终停留在同一账户上还是实际切换了账户——只有身份认证层掌握最终结果因此决策生成与决定注入必须分离才能保证注入发生在真实账户切换确认之后。配套的集成测试见 tests/integration/combo-matrix/context-relay-codex.test.ts 与 tests/integration/combo-matrix/context-relay-handoff.test.ts。局限性使用context-relay前需要明确以下边界有效的运行时支持目前集中于codex配额轮换从源码看maybeGenerateHandoff的上游调用要求provider codex并通过fetchCodexQuota获取配额combo.tshandoffProviders已建模为可配置的界面但实际交接生成仍依赖特定服务商的配额管道quota plumbing就绪摘要刻意保持紧凑并基于近期历史受maxMessagesForSummary与 8000 token 历史预算约束见 contextHandoff.ts它不是完整对话回放机制交接以sessionId comboName为作用域并自动过期默认 TTL 5 小时如果会话最终没有切换账户存储的交接不会被注入。推荐使用模式要充分发挥context-relay的价值建议遵循以下实践为同一服务商配置多个账户让 Combo 具备轮换空间在整个会话中保持稳定的sessionId否则交接无法跨请求关联将handoffThreshold设置得足够早如 0.8 左右为后台摘要请求留出余量——摘要生成本身也是一次模型调用太晚触发可能撞上配额耗尽窗口把该功能视为连续性辅助工具而非持久记忆persistent memory的替代品它只负责短期上下文衔接长周期记忆仍应依赖 OmniRoute 的记忆/上下文管理能力。【免费下载链接】OmniRouteNever stop coding. Free MIT AI gateway: one endpoint, 352 providers (150 free), 1200 models Kimi, Claude, GPT, Gemini, GLM, DeepSeek, MiniMax. Works with Claude Code, Codex, Cursor, OpenCode, Cline Copilot. Quota-aware auto-fallback, RTKCaveman compression saves 15-95% tokens, MCP/A2A, Desktop/PWA. Built by 550 contributors项目地址: https://gitcode.com/GitHub_Trending/om/OmniRoute创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
