自己写了个开源小工具：把 DeepSeek / Gemini / 其他第三方模型接进 Codex 当打工子代理
用大模型做复杂工程时，最关键的其实不是单次推理能力，而是「注意力管理」。
如果让主模型一边负责顶层架构规划，一边又在主会话里塞满海量的具体代码实现、控制台报错和调试日志，大量低信息密度的噪音会迅速污染主上下文。这不仅会导致上下文急剧膨胀，更致命的是会分散模型的注意力权重，导致后续高层决策时出现遗忘或推理漂移。
合理的工程解法，应当是让主模型始终保持清爽纯粹的全局上下文，而把具体的落地实现、排错与探路任务委派给独立的子代理（Subagent）或外部 CLI，执行完毕后只回传精炼摘要与产物。
所以我写了这个调度中继层 —— Relay（开源在 GitHub）：
主要解决这几件事：
1. 保持主模型上下文纯净（Attention 聚焦）利用 Codex 原生协议，把 DeepSeek-V4、Gemini-3.7 等第三方模型接为原生子代理。把局部实现和调试噪音隔离在子任务中，主窗口只保留关键设计决策与最终验收。
2. 外部 CLI 统一调度在需要直接借力 Claude Code、OpenCode 或 Antigravity 时，提供统一调用入口，日志与退出码透明透传，无需在多个终端和工具间反复切换。
3. 凭据与数据隔离API Key 严格通过标准输入安全注入并自动脱敏，避免凭证泄露到命令行历史或本地持久化文件中。
---
使用方式很简单（直接在 Codex 里打字）：
1. 安装：“请帮我在 Codex 里安装这个 GitHub 项目：https://github.com/IkariKr/relay-agent-platform”
2. 配置模型（以 DeepSeek 为例）：“帮我把 DeepSeek 配置为 Relay 的原生子代理：
- Base URL: XXX
- Model ID: deepseek-v4-flash
- API Key: <你的Key>”
3. 派发隔离任务：“请创建一个 DeepSeek 子代理，帮我补齐这个模块的所有单元测试，完成后汇报结果。”
---
项目地址在 GitHub：IkariKr/relay-agent-platform
欢迎有类似工程痛点的同学体验或交流讨论。
用大模型做复杂工程时，最关键的其实不是单次推理能力，而是「注意力管理」。
如果让主模型一边负责顶层架构规划，一边又在主会话里塞满海量的具体代码实现、控制台报错和调试日志，大量低信息密度的噪音会迅速污染主上下文。这不仅会导致上下文急剧膨胀，更致命的是会分散模型的注意力权重，导致后续高层决策时出现遗忘或推理漂移。
合理的工程解法，应当是让主模型始终保持清爽纯粹的全局上下文，而把具体的落地实现、排错与探路任务委派给独立的子代理（Subagent）或外部 CLI，执行完毕后只回传精炼摘要与产物。
所以我写了这个调度中继层 —— Relay（开源在 GitHub）：
主要解决这几件事：
1. 保持主模型上下文纯净（Attention 聚焦）利用 Codex 原生协议，把 DeepSeek-V4、Gemini-3.7 等第三方模型接为原生子代理。把局部实现和调试噪音隔离在子任务中，主窗口只保留关键设计决策与最终验收。
2. 外部 CLI 统一调度在需要直接借力 Claude Code、OpenCode 或 Antigravity 时，提供统一调用入口，日志与退出码透明透传，无需在多个终端和工具间反复切换。
3. 凭据与数据隔离API Key 严格通过标准输入安全注入并自动脱敏，避免凭证泄露到命令行历史或本地持久化文件中。
---
使用方式很简单（直接在 Codex 里打字）：
1. 安装：“请帮我在 Codex 里安装这个 GitHub 项目：https://github.com/IkariKr/relay-agent-platform”
2. 配置模型（以 DeepSeek 为例）：“帮我把 DeepSeek 配置为 Relay 的原生子代理：
- Base URL: XXX
- Model ID: deepseek-v4-flash
- API Key: <你的Key>”
3. 派发隔离任务：“请创建一个 DeepSeek 子代理，帮我补齐这个模块的所有单元测试，完成后汇报结果。”
---
项目地址在 GitHub：IkariKr/relay-agent-platform
欢迎有类似工程痛点的同学体验或交流讨论。
