企业官网建设流程全解析

DeepTutor「My Agents」多 Coding CLI 子代理集成的开源合作外联实战：渠道矩阵、风险规避与可复用邮件模板

【免费下载链接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.项目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor

导读：DeepTutor 的 My Agents 允许学习者把本机已安装的 Claude Code、Codex、Gemini CLI、Kimi CLI、opencode、MiMo Code 等 Coding CLI 接进对话，以consult_subagent工具实时"请教"真实代码仓库。本文以仓库内的《outreach-emails-subagent-partners.md》外联文档为骨架，先讲清其背后的子代理集成实现（含源码依据与版本时间线），再完整梳理这套开源合作外联的打法——目标渠道怎么选、措辞有哪些雷区、六家项目的差异化邮件/表单怎么组织。读完你既能理解 DeepTutor 的多 CLI 子代理架构，也能直接套用一套"开源项目互推"的可执行沟通方案。

一、先看清信件在讲哪个功能：My Agents 与consult_subagent

六份草稿反复出现的核心卖点是同一件事：My Agents——让学习者把自己机器上已安装的 coding CLI 接进 DeepTutor，在对话中途对它做"实时咨询"：不是粘贴一段对话记录，而是真的把该 agent 跑起来、让它读真实仓库、把它的工具调用过程实时流式汇入答案。

从当前仓库源码看，这由deeptutor/services/subagent/与deeptutor/capabilities/subagent/两个包承载：

• 后端注册表registry.py 是"系统到底认识哪些子代理"的唯一事实来源，逐一实例化了ClaudeCodeBackend、CodexBackend、GeminiBackend、KimiBackend、OpencodeBackend、MimoBackend以及进程内运行的PartnerBackend——与外联文档列出的六款 CLI 完全对应；
• 咨询工具tools.py 定义了唯一的consult_subagent工具。模型侧只能提供question参数，而"用哪个后端、工作目录、per-backend 配置、本轮次预算与会话状态"等均由服务端注入，杜绝模型越权指定；
• 预算与权限旋钮config.py 给出默认值：consult_budget默认 5、允许 1–12，即用户在设置页看到的"最大轮数"；每个后端还有permission_mode、sandbox、approval、auto_approve、forward_images、extra_args等逐后端参数，默认策略"永不因等待审批而卡死无头运行"；
• 模型与推理档位发现models.py 为每个后端映射一个选项提供者：Codex 读其models_cache.json与config.toml，Claude Code 走缓存化别名，opencode/MiMo 家族用各自的models命令枚举provider/model。

这解释了外联文档里那句"我们不是粘贴记录，而是把它跑起来"为什么站得住脚——consult_subagent每次调用都会把后端的原生事件经事件槽流式转发到侧边栏（Activity 面板），并在一次咨询内复用同一个 agent 会话以保持上下文。

版本时间线（以本仓库发布记录为准）

仓库assets/releases/下的发布记录可以交叉印证外联文档中的版本表述：

• ver1-4-7.md 首次出现consult_subagent工具与"subagent 作为知识源"的形态，起点是 Claude Code；
• ver1-4-8.md 扩展到 Codex；
• ver1-5-3.md 明确写道：在 Claude Code 与 Codex 之外，"你可以从任意对话轮次连接并实时咨询Gemini CLI、Kimi CLI、opencode、MiMo Code"，每个 CLI 都会被本机探测、可选手模型，并通过consult_subagent流式进入 Activity 面板——外联文档反复强调的"v1.5.3 起支持全部六款 harness"由此得到仓库证据；
• Codex OAuth（用 ChatGPT 订阅登录）由 ver1-5-5.md 引入，ver1-5-6.md 补全远程/容器化部署经 SSH 隧道完成回调解的路径。

⚠️ 口径提醒：外联文档正文写的是"since v1.5.4 signing in … via Codex OAuth"，而本仓库发布记录显示 OAuth 登录随 v1.5.5 落地、v1.5.6 完善远程登录。凡是涉及对外描述版本的能力，建议以仓库内 发布记录 的实际内容为准，避免对外口径与代码历史不一致。

二、外联文档的整体定位：六份草稿 + 一份诚实评估

这份文档不是泛泛的公关话术，而是"先调研、再写信"的产物。它的结构可以拆成四层：

1. 公共落款：全文统一使用作者署名——Bingxi Zhao（赵炳熙），香港大学数据智能实验室博士生；
2. 渠道矩阵：针对六个目标项目逐一核实"真正会有人读的通道是哪一条"，并给出诚实评级；
3. 三条发送前警告：对初稿中"we're open-source partners"式定位的两处重大修正；
4. 六份差异化草稿：每个项目一套措辞，避免千篇一律。

文档首部还有一句关键的工作状态说明：签名与 star 数已填好，唯一待补的是可选的 demo 链接。也就是说，草稿里出现的 star 数字是成稿当时的口径，属于会随时间漂移的字段（仓库内亦无法核实该数字），正式发送前需要逐一刷新；demo 链接按文档提示保持"可选"。

三、渠道矩阵：先想清楚"发给谁"，再决定"怎么写"

文档最直白的结论是：这六个项目里，没有一个是靠邮件接受开源合作请求的——六个 CLI 仓库都没有公开维护者邮箱；能查到的邮箱大多属于公司市场/增长团队，而不是 CLI 开发组。因此渠道优先级必须是GitHub/Discord 为主、邮件为辅，而不是反过来。

原文渠道矩阵的完整内容如下（措辞与评级均保留原文口径；邮箱、页面等外部信息会随时间变化，发送前应逐条复核，后文统一给出时效性提醒）：

修正后的触达顺序

基于上述调研，文档给出明确的执行顺序修正：MiMo 第一（团队有真实的邮件邀请），Kimi 走 GitHub 第二，Codex 基金申请第三；opencode 放到最后，且从 Discord 进入——前提是先拥有"已存在的合作关系"这一说法，而不是去向对方"提议"一段关系。

四、发送前的三条硬警告

这是文档里最值得记住的方法论部分，本质上是"如何避免把一封合作信写成冒犯信"：

警告一：opencode 明确防范"暗示隶属关系"。其 README 的 "Building on OpenCode" 一节要求使用 opencode 名称的项目在自己的 README 中声明"并非由 OpenCode 团队构建、与我们无任何隶属关系"。这几乎与"我们是开源合作伙伴"的表述相反——所以对 partner 式话术而言，opencode 是最差的第一目标，而不是最好的；文档承认最初判断反了。修订版草稿删掉了 "partner" 一词，改为问一个更窄的问题。

警告二：opencode 已迁移且体量远大于 DeepTutor。仓库现位于anomalyco/opencode（Anomaly 旗下，不再是sst/opencode），体量约为 162k stars（成稿时口径）。其 CONTRIBUTING.md 明确写道："No AI-generated walls of text… respect the maintainers' time."（不接受 AI 生成的长篇大论，请尊重维护者的时间。）因此给它的草稿被刻意压缩，不要加长。

警告三：修正后的顺序。即上文第三节的 MiMo → Kimi（GitHub）→ Codex 基金 → opencode（Discord，放在最后）。

五、六份草稿拆解：定位、措辞取舍与可复用骨架

六封信大体共用一套骨架，差异在于每一家"能答应什么、不能答应什么"：

• 通用骨架（Kimi / MiMo 版）：自我介绍（DeepTutor 是 Apache-2.0 的 agent-native 学习工作台，来自港大数据智能实验室）→ 讲清 My Agents 机制与"不是粘贴记录而是真的跑起来"的差异 → 说明该项目自 v1.5.3 起即为支持的 harness 之一 → 提出小请求：在 README 列为开源合作伙伴，并期待对方一句类似的提及 → 主动澄清"partner 不隐含任何协议/排他/义务，只是互相指路"→ 给对方留足退路："不方便也完全没关系，集成会保留，欢迎给我们调用方式的反馈。"
• 各项目的差异点：如下逐一说明。

5.1 opencode（Anomaly）——先自证"不隶属"

这份是六份里最特殊的：既然对方要求使用其名称的项目主动声明"非其团队构建、无隶属关系"，就在对方开口之前自己先把免责声明给出去，从而消除对方说"不"的主要理由。通道以 Discord 为主（比marketing@anoma.ly更可能被读到），文本两处皆可用。

关键措辞（原文修订后的要点）：

• 主题保持直白："DeepTutor 支持把 opencode 作为 subagent——是否可能进行一次开源协作？"
• 开头即读对方的 "Building on OpenCode" 注意事项，明确承诺：项目名不使用 "opencode"；乐意在 README 中写明"DeepTutor 并非由 OpenCode 团队构建、与之无任何隶属关系"，如果对方有指定措辞将完全照用；
• 请求降格为"互相可见性"：希望列出 opencode，也欢迎对方一侧的同类提及；若不合适，集成保留，并欢迎对"我们调用 opencode 的方式是否符合你的设计预期"给出反馈。

5.2 Kimi Code CLI（月之暗面）——Issue 为主，中文正文更优

主渠道是MoonshotAI/kimi-code的 Issue，growth@moonshot.cn作为平行投递。文档明确建议正文用中文版、英文版附后。两版信的核心内容一致，均强调"没有任何正式约束——无协议、无排他、无义务，只是两个开源项目之间互相指个路"，并同样预留"是否以你们预期的方式调用 Kimi Code CLI"这一请教式收尾。中文版可完全照抄原文结构，仅替换项目名与链接。

5.3 MiMo Code（小米）——文档标注"从这里开始"

唯一存在明确邮件邀请的项目，因而被文档标注为整个序列的起点（mimo@xiaomi.com）。措辞与 Kimi 版同构：在 README 中把 MiMo Code 列为开源合作伙伴、欢迎用户使用，并期待对方一侧类似的提及。同样的关键句是"这里没有任何实质约束：无需签署协议，不涉及排他，双方都没有开发义务——只是两个开源项目之间互相指路"。同样提供中文版与英文版两个版本。

5.4 Claude Code（Anthropic）——只问两件"他们能答"的事

文档给 Anthropic 版的评语很关键：Anthropic 不会在邮件里答应非正式的 "partner" 安排，且其商标指南明确——未经明确授权，不得以暗示关系或隶属的方式使用其商标。因此这封信不碰 "partner"，只问两个容易拒绝也容易答应的问题：

1. 品牌用法：希望在 README 与文档中把 Claude Code 描述为"受支持且鼓励用户使用的 agent"，并确保不暗示赞助或隶属；如对方有偏好措辞将完全照用；
2. 可被发现性：Powered by Claude 目录（或其它名单）是否适合收录 DeepTutor 这类项目，希望获得一个"如何被考虑"的指引。

信件同时说明 Claude Code 自该功能上线起就是参考实现，并支持把过去的 Claude Code 会话导入为可检索、可续接的上下文。文档还建议并行做一件事：申请 Powered by Claude 目录——那才是最接近"真正想要的东西"的位置。对等提及则不做期待："如果你们一侧将来觉得合适我们当然高兴，但这不是我写这封信的原因。"

5.5 Codex（OpenAI）——不走邮件，走 Codex Open Source Fund

文档判断"这里没有值得写的合作邮箱"，但 OpenAI 运行着一个 $1M 的Codex Open Source Fund：为基于 Codex CLI 构建的开源项目提供最高 $25k 的 API 额度、滚动评审。被资助本身就是一段"真实的关系"，日后描述双方联系时才站得住脚。

因此这封信的正文不是邮件，而是基金表单的申请叙事（如果表单有自由文本字段就填它），要点包括：

• Codex 是被当作 first-class 对待的两个 harness 之一（另一个是 Claude Code）；
• 支持由consult_subagent驱动的多轮实时咨询、把过去的 Codex 会话导入为可检索可续接的上下文；
• 支持用 ChatGPT 订阅经 Codex OAuth 登录（含 SSH 隧道后的远程登录）；
• 用户画像落点很诚实：学生、研究者、自学者用 DeepTutor 去理解真实代码库而不是发布功能——"不是凭记忆解释一个仓库，而是让 Codex 去读它"；
• 额度将流向检索与咨询路径，使共享同一 agent loop 的 Chat、Research、Mastery Path 等模式都更可靠。

文档同时建议把同样的内容以 Discussion 形式贴到openai/codex仓库，让维护者看得到。

5.6 Gemini CLI（Google）——仓库 Discussion 是最优解

该团队没有公开邮箱；文档结论是把它作为 Discussion 发在google-gemini/gemini-cli——"这是产出最高的渠道，且公开可见本身就是目的的一部分"。Gemini CLI 是 Apache-2.0、有开放的贡献文化，维护者在仓库内活跃。

信内含两个都是可选项的请求：一是"我们该如何描述你"（在 README 中列为受支持的 agent，希望措辞符合 Google 品牌指南、不暗示背书）；二是"是否有一个面向基于 Gemini CLI 构建的集成/社区工具名单"，希望 DeepTutor 能被考虑。同样预留完全退路："如果都不合适也没关系，集成会保留，我们仍想听听维护者对调用方式的看法。"

六、落款与"发送前刷新清单"

全文统一落款为文档首部给出的签名：

Bingxi Zhao (赵炳熙) PhD student, Data Intelligence Lab, The University of Hong Kong

外联文档对这份落款有一个很务实的工程化说明：正文用裸 URL 而非 Markdown 链接书写，因为其中大部分将以纯文本邮件发出——这对任何写对外邮件的人都值得借鉴。

综合全文，正式发送前应核对的字段清单：

1. star 数等随时间漂移的数字（成稿时口径为 31k，发送前必须刷新）；
2. demo 链接：文档标注为"唯一待补的可选项"；
3. 各渠道联系方式：下文"来源"一节列出的邮箱、仓库与页面地址均会变动；
4. 版本口径：对外写"自 vX.Y.Z 支持/引入"时，以仓库 发布记录 为准（如 Codex OAuth 实际随 v1.5.5 引入、v1.5.6 完善远程路径）。

七、来源的时效性：地址会过期，先复核再发送

文档末尾专门列出了上述所有邮箱与页面地址的证据来源，覆盖：opencode 的社区渠道与 "Building on OpenCode" 声明、Kimi Code CLI 的社区渠道、月之暗面公司联系方式、XiaomiMiMo 的邮箱、Anthropic 商标指南与 Partner Network、Codex Open Source Fund 说明与申请表单、Gemini CLI 渠道与 Google Brand Resource Center。

这些证据大多来自目标项目各自的 README、CONTRIBUTING 或公司"关于"页——它们不属于本仓库、无法在本仓库内核实，且必然随时间变化。套用这套打法时，请把外联文档当作"调研方法 + 模板"来用，而不是"地址簿"：每一封发出前，都应当重新打开目标仓库的当前 README/社区页面，核实主渠道与联系方式是否仍如文档所述。

八、仓库内的延伸阅读

• 外联文档原文：outreach-emails-subagent-partners.md
• 子代理后端注册表：deeptutor/services/subagent/registry.py
• consult_subagent工具定义与预算执行：deeptutor/capabilities/subagent/tools.py
• 咨询预算与 per-backend 权限配置（默认值 5、范围 1–12）：deeptutor/services/subagent/config.py
• 各后端模型/推理档位同步发现：deeptutor/services/subagent/models.py
• 子代理 API 路由与设置页对接：deeptutor/api/routers/subagents.py
• 版本证据（v1.5.3 起支持六款 CLI）：ver1-5-3.md；Codex OAuth 登录演进见 ver1-5-5.md 与 ver1-5-6.md

【免费下载链接】DeepTutorDeepTutor: Lifelong Personalized Tutoring. https://deeptutor.info/.项目地址: https://gitcode.com/GitHub_Trending/dee/DeepTutor