过去两年，语音克隆已经从早期的 Bark、Tortoise、VALL-E-X、XTTS-v2 时代，明显切换到“大模型 TTS + zero-shot/few-shot voice cloning”路线。现在主流体验不再只是“能不能模仿音色”，而是看它能不能稳定说长文本、能不能跨语言、能不能控制情绪和语速、能不能本地跑，以及有没有好用的 WebUI 或 Hugging Face demo。
如果是自用场景，许可证不一定是第一过滤条件。更实际的筛选标准是：效果体验、中文/多语能力、上手成本、长文本稳定性、是否适合长期做自己的声音库。 本文按 2025 年以后仍活跃或有新版路线的项目做一次集中梳理。
录音转写看起来像一个单点能力：给一段音频，返回文字。真的要自建时，它会很快拆成几个完全不同的问题：谁负责录音或进会？是实时字幕还是会后处理？要不要说话人？要不要摘要、行动项和问答？要不要 API、权限、队列和搜索？
如果不先把这些产品形态分开，就很容易把 openai/whisper、faster-whisper、WhisperX、一个 Gradio WebUI、一个会议 bot、一个媒体库平台放进同一张表里比较，最后得到一堆“都能转写”的无效结论。
这篇只做静态调研，关注 GitHub 上可自建、可部署或可封装的项目，重点场景是录音转写、会议笔记和后续 ChatArch/Agent 工作流集成。
过去一年，很多团队已经不再问“哪个模型更会写代码”，而是在问另一个更产品化的问题：当团队里同时存在人类工程师和一组 coding agents，谁来分配任务、记录进度、保存上下文、管理运行机器和复用经验？
Multica 的回答不是再造一个 coding agent，而是把 Claude Code、Codex、Hermes、Cursor Agent、OpenCode 等本地 AI coding tools 包成一个协作系统：Agent 出现在 assignee picker 里，issue 会触发 task，runtime 负责 claim 和执行，结果再写回 issue timeline。
“文件分享”至少有三种完全不同的产品：一种把 目录/文件名 直接变成 URL；一种上传后生成高熵临时链接；还有一种提供 S3 bucket/object API，接近七牛、MinIO 和对象存储。
如果不先把这三类分开，很容易一边比较极简文件服务器，一边又把完整 Web 产品和分布式对象存储拉进来，最后得到一个没有决策价值的功能总表。
这篇围绕 ChatShare 的第一阶段目标做静态调研：一个共享 Key、上传/下载 API、文件名或 object key 与 URL 明确关联、尽量轻量、不把账号体系和存储集群提前塞进来。
AutoResearch 最容易被描述成一条越来越长的流水线：搜论文、提 idea、改代码、跑实验、画图、写 LaTeX，再让另一个模型 review。按照这个口径，覆盖阶段越多，系统就越接近“AI Scientist”。
但两个代表项目给出了相反信号。
karpathy/autoresearch 只允许 Agent 修改一个 train.py，每轮训练 5 分钟，只看一个 val_bpb；AI Scientist-v2 则从主题、idea 和文献一路走到实验树、论文与 review。后者的行动空间大得多，官方 README 却明确提醒：开放探索的成功率低于模板更强的 v1，有强起始模板时也不一定生成更好的论文。
这不是“简单 Agent 比复杂 Agent 聪明”，而是两套系统承担了不同的验证债务：Agent 每多获得一种行动能力，系统就必须多证明一件事——它没有因为扩大搜索、重复看分数、选择性报告或自我审查而制造假改进。
当自托管服务从两三个变成十几个以后，最先失控的通常不是 Docker，而是入口：服务 URL 记不住、端口散落在书签里、手机上找不到常用页面、某个容器挂了也没有直观提醒。这类问题不一定需要上 Grafana，很多时候一个 startpage / homepage / dashboard 就够了。
这篇从 awesome-selfhosted 的 Personal Dashboards 分类里挑了五个最值得优先看的项目：Homepage by gethomepage、Homarr、Dashy、Homer 和 Glance。它们都能自托管，但解决的问题不完全一样。
如果不想从零写视频网页理解流水线，可以先试几个已经能跑起来的开源项目。这里按“能不能直接部署”“是否支持 B 站”“是否有 Web UI”“是否包含 ASR/VLM/知识库能力”来筛了一轮。