BoHuYeShan

AI 正在真正进入单细胞生物信息学流程这两年，很多人一提 AI for Bioinformatics，脑子里浮现出来的还是那种比较熟悉的形态：聊天、总结文献、解释概念、帮忙写几段分析代码，或者把某个常规流程包装得更顺手一点。 这些东西当然有价值，但如果只停留在这一步，其实还很难说 AI 已经真正进入了生物信息学的核心工作流。因为真正的生信分析，尤其是单细胞分析，从来不是“把答案说漂亮”这么简单。它牵涉到具体数据、分析链路、领域知识、解释方式，以及最后能不能支撑一个像样的生物学判断。 今天查到的几篇论文里，我觉得最值得放在一起看的是三篇：scPilot、ELISA 和 HarmonyCell。它们不完全是同一种工作，但放在一条线上看，会发现一个非常清楚的变化：AI 在单细胞生物信息学里，正在从外围辅助，慢慢往真正的分析、发现和建模流程里走。 一、第一步变化：AI 不只是解释单细胞分析，而是开始直接接触数据先看 scPilot。 这篇论文的标题很直接：scPilot: Large Language Model Reasoning Toward Automated Single-Cell Analysis and Discovery。它最值得注意的一点，不只是用了 LLM，而是它把自己的工作定义成了一种 omics-native reasoning。这几个词其实很关键，因为它不是在...

第五篇：编辑器兼容性验证（SVG 与 Mermaid 测试）Brain，这一篇不是正式发布稿，只是给你做编辑器兼容性验证用的。 我这次先做两件事： 放一个标准的生物学科研流程 SVG 放一个Mermaid 思维导图 你的目标很简单：看看它们在你的编辑器里导入 Markdown 之后，能不能正常识别、显示，并在导出富文本后继续在其他平台正常渲染。 如果可以，我们后面就可以把 SVG / Mermaid 更系统地放进 1 到 4 篇文章里。如果不可以，那后面就统一走另一条路线： 先保留结构化 SVG / Mermaid 源文件 再转成 PNG 或其他更稳的图片格式 最后把图片插入 1 到 4 篇正式文章 另外，我也去核了一下 OpenMAIC 项目原文。根据项目页可确认的几点，后面写正式稿时表述上要更严谨： 它确实是一个 Open Multi-Agent Interactive Classroom 项目 项目说明里明确写了 built-in OpenClaw integration 官方给了 线上体验入口 也提供了 pnpm 本地启动、Vercel 部署、Docker compose 等方式 如果长期用，本质上仍然会回到：你自己的部署能力、服务器和 API 接入能力 所以你前面提醒得对，正式稿里不能凭印象写，要尽量回到项目原文去核。 一、SVG ...

生信 Agent 开始落地 从 scAgent 到 OmicVerse，今天新冒出来的生信 Agent 工作流，已经不只是“帮你聊两句”了 今天这篇不按周报写，也不想再重复“AI 正在改变科研”那类话。更值得写的，是 2026-03-22 这一天能看到的几个新信号：生信里的 Agent，开始不再满足于解释概念、补几段代码、顺手查两篇论文，它们正在往真正的执行层靠近。换句话说，这些系统不只是会说话的界面，而是开始尝试接数据、调工具、跑标准步骤、吐中间结果，再把人留在真正关键的复核点上。这个变化听起来有点抽象，但如果你把它摊开看，就会发现它对应着一个很具体的迁移：过去很多分析是“人先打开 notebook，再决定做什么”；现在有些入口开始变成“先把任务和数据交给系统，系统先把标准动作跑起来，人再决定结论是否成立”。 今天看到的这些东西，更像一种结构性变化的早期样本，而不是几条零散热点。因为一旦入口变了，后面的组织方式、参数管理、人工审核、结果交接，都会跟着变。用一个尽量朴素的表达来说，以前很多分析默认的路径大致是 1数据 -> notebook -> 命令 -> 图和表 -> 人解释结果 现在开始出现的另一条路径更像是 1数据 + 任务 -> agent -> 工具调用 -> 中间结果 -> 人工复核 -> 结论 这两条...

2026-03-21 周报｜生物科技、生物信息学与新技术 本文信息由 AI 爬取+整理，经人工核验后发布。AI 爬取可能会有遗漏，欢迎在评论区补充。如有偏差，也欢迎指正。 本期覆盖时间：2026-03-15 ～ 2026-03-21（含） 这周生物科技和生信这边，没有”一篇顶刊引爆全网”的单点大新闻。但有几件对做实际研究的人来说影响更长的事：数据库基础规范升级、资源平台化趋势、以及两篇方向性值得关注的论文。 一、生物科技资讯1. NCBI 采纳了 INSDC 关于 GenBank 和 SRA 的最小规范要求这是本周最值得认真看的一条。简单说：以后往 GenBank 和 SRA 提交数据，需要满足更明确的最低元数据标准。 对长期依赖公开数据库做分析的生信用户来说，这意味着： 提交的数据会更规范，复用时遇到”缺字段””格式不统一”的概率会降低 元数据缺失导致的自动化处理障碍会逐步减少 可追溯性和可复现性会变得更好 这类变化不像新模型发布那样有即时热度，但对你的工作流程影响是持续的。如果你的日常有”从公开数据库下载→标准化→分析”这一环，这条比大多数”某模型又升级了”更值得记。 2. OpenScientist 这类带平台化色彩的科研自动化框架继续出现目前还不能说它已经成熟，但它代表的趋势很清晰：研究工作流正在从”人手动串脚本”向”可编排、可审计、可协作的平台系统”演进。...

2026-03-21 周报｜GitHub、AI 技术与新模型 本文信息由 AI 爬取+整理，经人工核验后发布。AI 爬取可能会有遗漏，欢迎在评论区补充。如有偏差，也欢迎指正。 本期覆盖时间：2026-03-15 ～ 2026-03-21（含） 这周如果你只刷英文源，大概率会觉得没什么大事。GitHub 上没有一夜涨几十万 star 的项目，也没有哪个模型一发布就刷屏。但小米一口气发了三个模型，腾讯混元正式版上线，GitHub Copilot 一周连出六个动作——这周其实挺忙的。 一、GitHub 每周热门内容1. openai/codex 0.115.0：重点从”写得快”转向”不出事”这周 OpenAI 对 Codex 的表述明显转向 behavior-first validation——更强调行为验证和安全可控，而不是只比 benchmark 分数。coding agent 的比拼已经从”谁写代码快”进入”谁写的东西在真实工程里不会翻车”的阶段。 2. GitHub Copilot 一周六连击这不是一条孤立新闻，而是 GitHub 一周之内连着做了好几件事： secret scanning 通过 GitHub MCP Server 接入了 agent 工作流 coding agent 的语义代码搜索能力继续增强 validation tools 配置进一步...

外部 Markdown 版本记录：2026-03-19这份记录是什么，为什么要留档这是一份针对外部 Markdown 文档的项目内版本记录，目的是把一篇已下载文章整理成可公开阅读、可上传 GitHub、可供后续查证的归档文本。 本记录不替代原文，而是用于： 保留该版本的核心观点； 说明时间口径与文件来源； 方便后续在公开仓库中作为版本历史引用； 为后续写作、修订和对外说明提供稳定摘要。 一、版本归属与时间说明1. 文件获取日期 原始文件名：2026-03-20.md 文件来源路径：C:\Users\BoHuYeShan\Downloads\2026-03-20.md 当前项目归档日期：2026-03-20 2. 内容按 2026-03-19 处理的依据虽然文件名显示为 2026-03-20，但根据你的说明，这份文档实际对应的是“昨天”的内容，也就是 2026-03-19 的版本内容。因此在本项目内，统一将其归档为： 内容版本日期：2026-03-19 后续如果上传 GitHub 或用于公开查证，建议沿用这一口径： 下载/归档日期：2026-03-20 内容归属日期：2026-03-19 二、本次版本的核心主题摘要这篇文档围绕一个社交平台上广泛传播的问题展开： “我想去洗车，洗车店离我家 50 米，我该开车过去还是走路过去？” 文档的核心观点不是...

QClaw、AutoClaw、OneClaw、JVS Claw、Kimi Claw、OpenClaw 怎么选：科研工作者的 Agent 平台比较平台差异，决定的不是“能不能玩”，而是“能不能长期用”现在大家讨论 OpenClaw 类 Agent，很容易陷入一种误区：好像它们只是“不同公司做的同一种东西”。 但如果你真的把它放进科研工作里，很快就会发现，平台差异非常实际： Windows 能不能直接用？ 是本地执行还是云端托管？ 要不要自己配模型 API？ 能不能接第三方兼容端点？ 搜索和浏览能力是内置还是要额外承担成本？ 能不能做长期可复现流程？ 所以这篇文章不打算简单排“谁第一谁第二”，而是回答一个更有用的问题： 谁更适合哪类科研用户。 一、先给一个总判断如果只看今天这个时间点，我会把几条路线粗略分成三类： 1. 原生开源型 OpenClaw 原始开源版 优点：自由度最高、可控性最强、最适合做可复现工作流。缺点：门槛也最高，尤其对不会自己配环境的人不友好。 2. 轻封装 / 桥接型 QClaw AutoClaw（智谱） OneClaw 优点：上手明显更快，能把原本难用的 Agent 能力压到普通用户可接受的范围。缺点：不同产品在价格透明度、第三方模型开放度、搜索细节上差异很大。 3. 厂商托管型 JVS Claw Kimi Claw 优点：托管和持续运...

怎么部署和使用 Open Maic，以及如何用常见大模型辅助学习前面几篇文章已经把核心判断说清楚了：Open Maic 更像课程学习工具，学习效果首先取决于资料质量，而真正好用的系统，关键在于它能不能把中间流程组织起来。 接下来的问题就很实际：如果我真的想用这套东西辅助学习，到底应该怎么开始？ 这个问题可以直接拆成三种现实路线。 第一种，是把 Open Maic 当成一个值得体验和理解的学习型项目。第二种，是自己部署 Open Maic，把它当成长期使用的工具。第三种，是不依赖 Open Maic 本身，而是直接用常见的大语言模型，把一套可执行的学习流程搭起来。 之所以要这么拆，是因为从当前情况看，清华大学这个项目的官方线上入口更适合体验和理解思路；如果你真的想长期使用、频繁使用，或者希望把它当成日常主力工具，大部分情况下还是得走本地部署、配服务器、接入自己的 API 这条路。也就是说，线上体验更像样板，长期使用更像工程化问题。 一、先把定位说清楚：官方线上入口更适合体验，长期使用还是要看本地部署如果你只是想理解“课程学习型 AI”到底应该长什么样，那 Open Maic 当然很值得体验。因为它最有价值的地方，恰恰不是它要替代所有通用 AI，而是它把一门课怎么学、怎么整理、怎么复习这件事，组织成了更连续的路径。 但如果把问题换成“我是不是可以直接长期依赖它的官方线上入口来重度...

为什么有些 AI 跑分很高，但实际并不好用很多人聊 AI，最容易陷入的一种讨论方式，就是把所有问题都压缩成一句：到底哪个模型更强。 这个问题当然重要，但它经常只说对了一小半。 因为用户最后真实感受到的 AI 效果，从来都不只是模型参数本身决定的。决定结果的，通常至少有三件事：第一，模型自身能力到底够不够强；第二，它手里有没有工具、有没有流程、会不会多轮工作；第三，用户是不是把任务说清楚了。 这三件事缺一块，最后的使用体感都可能完全变样。这其实也和我们今天前两篇文章是连在一起的：学习型 AI 能不能好用，要看高质量资料和学习流程；科研绘图能不能好用，要看结构设计和中间工作流。离开这些，单看模型名字，往往看不出真实差距。更早之前发过的几篇技术文章，其实也一直在围绕同一个问题打转：AI 最终的可用性，从来不是单一维度能解释完的。 一、跑分当然重要，但跑分不等于体感先把最容易引起争议的话放在前面：模型榜单和用户体感，从来不是一回事。 跑分当然有意义。它至少能告诉你一个模型在某些标准化任务上的上限，也能帮你快速判断底座能力够不够强。但问题在于，很多榜单测到的，只是模型在一套特定测试集上的表现，而真实用户每天碰到的，却是搜索、规划、绘图、写作、回查、多轮追问、复杂任务拆解这些混合场景。 这两者本来就不是同一件事。 更现实的问题是，榜单这件事本身也没有很多人想象得那么干净。尤其是这两年，一...

科研工作者怎么把 Agent 真正用起来：从论文检索到资料整理的完整流程科研场景需要的不是“更会聊天”，而是“能把流程跑通”很多人第一次接触 OpenClaw 类 Agent，会把它理解成“会自动点鼠标的大模型”。这个理解不算错，但远远不够。 对科研工作者来说，真正有价值的地方在于： 它能去网页上操作 它能接工具链 它能留下载链接、DOI、PDF 它能把多步任务接起来 也就是说，科研里需要的不是单次回答，而是 带证据链的执行流程。 这也是为什么我会把 Agent 和普通聊天型 AI 分开讨论：前者的核心价值，不只是“知道什么”，而是“会去哪里找、怎么留下痕迹、能不能继续跑”。 一、先说结论：科研里最稳妥的 Agent 工作流是什么如果把复杂问题压缩成一句话，我建议的主流程是： 先在正确站点检索真实记录 → 留下 DOI/PMID/URL/PDF → 再做总结和整理 → 最后人工复核。 这和很多人早期的用法完全相反。很多人以前是： 先问 AI 要文献； 再复制看起来像真的引用； 最后才发现 DOI 或论文根本不对。 正确顺序应该倒过来： 先拿真实记录，再让 AI 帮你加速整理。 二、为什么要重视“主动帮 AI 查论文”的工具能力这里我想强调的重点，不是某一个工具名本身，而是一类能力： 让 AI 主动调用论文检索工具、学术数据库、浏览器能...