一条抗体序列，怎样才能从计算机里的预测，变成实验室中真正有效的候选分子？
一副机翼，怎样才能从屏幕上的设计方案，变成兼顾不同飞行状态的工程成果？
这两个问题看似相隔很远，却把 AI 带到了同一道门槛前：给出一个看起来合理的答案，和完成一项经得起验证的研究，是两回事。
在华为 HC 大会上，“纳米抗体智造”、“民机总体与气动设计” 两个案例，让这道门槛变得具体起来。
它们关注的，不只是让模型"更懂生物"或"更懂空气动力学"，而是把文献、模型、工具、实验和反馈组织起来，让一个研究问题能够连续地向前推进。
两个案例背后，共同出现了一个名字：openJiuwen ScienceDiscovery。
不妨设想这样一个场景。
研究者让 AI 寻找一个新方向。它很快给出完整的论证，列出参考文献，甚至写好了实验代码。真正开始核查时，却发现：某篇文献并不支持那条结论，代码还没有实际运行，报告中的结果只是模型对"应该会发生什么"的推测。
问题不在于回答不够流畅，恰恰在于它太流畅了，容易让"推测"看起来像"事实"。
在 AI 辅助科研的公开梳理中，这类问题通常被归为两类：一是工具碎片化，文献阅读、假设提出、代码编写、实验试错、参数调优分散在不同平台，链条长、切换频繁；二是科研幻觉，复杂长链条任务容易出现文献引用失实、因果推导跳跃、实验流程造假等问题，破坏可复现性。
因此，科研智能体要解决的第一件事，是让结论与证据建立可检查的联系。ScienceDiscovery 的评审与溯源设计，正是把输出产物关联到执行记录、引用证据和内容存储，而不只保留最终回答。
第二件事，是允许研究走弯路。
科研不是一张预先知道所有步骤的流程表。同一个目标可能对应多种假设，同一种设计也可能有不同优化方向。第一版方案失败了，下一步不一定是继续修补，也可能需要退回之前的分岔口。
第三件事，是把"想到"接到"做到"。
读文献、写代码、调用专业模型、分析实验数据，使用的是不同工具。让这些能力出现在同一个页面上，还不等于它们能围绕同一个研究目标协作。ScienceDiscovery 将文献阅读、假设提出、代码开发、实验试错和参数调优放进统一工作环境，试图解决的就是这种流程断裂。
所以，科研需要专用 Agent，并不意味着一定要重新训练一个包办所有学科的大模型。
更重要的是，把通用模型的理解与推理能力，放进一套有专业工具、有执行约束、有证据记录、有验证反馈的科研系统。
一条抗体序列，不能只在计算机里"表现优秀"判断一个科研智能体是否真正达到 L4，不在于它能调用多少工具，而在于它能否接管一条完整的科研链路：自主理解目标、组织计算与实验，并根据验证结果持续优化。曹小宝老师分享的广州实验室抗体智造系统，正是这一方向的实践。广州实验室联合华为，依托 openJiuwen ScienceDiscovery、昇思 MindSpore 与昇腾算力，尝试把纳米抗体研发从一系列分散的模型和实验，重构为一条能够自主运行、闭环迭代的智能工作流。智能体通过精准文献检索和知识图谱形成可追溯的证据链，降低大模型幻觉；调用 RFAntibody 等 SOTA 生物模型，完成表位分析、抗体从头设计、结构复评筛选及密码子优化；再由多个专业智能体协同完成计算调度和实验编排，将设计结果转化为可合成的核酸序列与可执行的湿实验方案。全流程可查看、可回溯、可复现，推动抗体研发从“算得出”走向“做得出、验得准、迭代快”。这条链路在 ScienceDiscovery 上已有可对照的形态：平台可自动调用 RFDiffusion、ProteinMPNN 与 Protenix 等模型，把骨架生成、序列设计、复合物预测串成完整流程，最终输出的是含筛选信息与空间结构的辅助决策报告，而非一堆零散文件。
值得留意的是这里的分工：大模型负责理解任务、组织步骤，真正面向分子设计与预测的工作由专业生物模型承担。不是让一个聊天模型凭语言经验"写出抗体"，而是让智能体调用合适的科学计算能力。两者的结合也有前期积累——昇思 MindSpore 此前公布的资料显示，广州实验室已与昇腾围绕纳米抗体序列基础模型和结构预测开展合作。
一副机翼，也不能只在一种工况下"表现漂亮"商飞联合上海交大，基于 openJiuwen ScienceDiscovery 打造首个民机总体与气动设计智能平台"御风"，解析自然语言需求，串联"总体方案设计、气动设计与预测、翼型高速设计、诊断与协同优化、方案对比与决策"几大流程，实现总体设计快速闭环。平台基于前期昇腾 +MindSpore 原生的"东方·御风"、"东方·翼风"等合作成果，通过大模型和专用模型的能力融合，实现飞行器设计的效率、精度、规模突破和场景泛化，改变原有高低速串行设计流程，实现全流速智能并行协同设计，迭代效率提升 3~5 倍；平台进一步实现数据、模型和 Skill 的协同演进，未来将从智能设计逐步拓展到智能飞行，构建国产大飞机全场景智能体系。
其中"全流速智能并行协同设计"这一改变值得单独看一眼。过去更像几项工作依次交接：上一项完成，下一项才能继续；新的思路是让不同流速下的设计与评估更早进入同一个优化过程，及时交换约束和反馈。它的价值不只是"同时多跑几个任务"，更在于避免某个局部方案已经优化很久，才发现无法满足另一组要求。（"迭代效率提升 3~5 倍"对应的是设计迭代效率，并不意味着整架飞机的研制周期可以等比例缩短。）
从抗体到飞机，两个案例最终指向了同一件事：
科研智能体的价值，不只在于某一步做得更快，还在于让原本分散的步骤能够相互反馈。
为什么同一个科研工作台，既能服务抗体研发，也能进入民机设计？
答案不是它拥有一个"什么都懂"的超级模型。按照公开介绍，ScienceDiscovery 是基于 Agent OS（JiuwenSwarm）开发的一站式 AI 科研工作台，近期发布 v0.1 版本。它真正做的，是两件底层的事：把过程记下来，以及让产物自己迭代。
研究过程一旦变长，光保存聊天记录就不够了。
某张图由哪个版本的数据生成？某个判断引用了哪篇文献？后来的报告修改，是否仍然对应原来的计算结果？
ScienceDiscovery 通过高维结构化记忆图谱维护任务时序与产物证据链，核心是两条链：
任务链连接研究目标、任务、工具调用，以及产生的代码、文件和文献，回答"做过什么"。
引用链连接报告中的断言、支持它的证据和来源文献，回答"依据什么"。
两条链在结论与产物处交汇，使研究者能够从报告中的某个判断，一路回溯到它的来源和过程。这也解释了多智能体协作的结果为什么能被检查：以公开的脓毒症数据分析任务为例，平台自主组建 code-engineer、result-evaluator、report-writer 三类 Agent，分别负责计算与聚类、多维审核、报告输出，每个 Agent 的产物都作为节点挂在图谱上，支持点击溯源到代码、环境和日志。
配合内容寻址存储，需要核验的文件与记录会获得基于内容哈希的标识——可以给内容留下"指纹"：之后检查的，应该是当时那一版数据与产物，而不只是一个相同的文件名。
在报告生成阶段，零幻觉 Reviewer 多级审核机制会对引用缺失、占位内容和产物溯源链路进行检查。支撑这套机制的一个整体效果是：在行业权威的生物医学智能体基准 BiomniBench-DA 任务中，基于 GLM-5.2 模型，评测分数达到 77.4，为业界 SOTA。
这里有一个必须分清的边界：可追溯，不等于结论天然正确；有引用，也不等于假设已经得到验证。
这些机制的作用，是把原本藏在流畅回答背后的过程摊开，让错误、缺失与不一致更有机会被检查出来。最终的科学判断，仍然需要与具体证据和验证结果相匹配。
科研里常见的情形是：写一个能算准振荡积分的程序，把一段数值代码调快十倍，从一张数字表里反推出背后的方程——第一版实现通常都不够好。主要工作量不在实现第一版，而在其后的几十到上百次试错。
这类工作的形式是搜索，不是单次执行。
ScienceDiscovery 把这段试错交给了程序自己：被演进的是科研代码本身，模型不训练、搜索规则也不改，每一轮变的只有产物。
搜索展开的形状是一棵树。每一版产物是树上的一个节点，可以被再次选中、改写并长出新的分支，也可以暂时搁置、几十版之后再被选中继续修改。一轮迭代包含四步：选择一个父版本，交给模型改写，进沙箱评分并挂成新节点，最后把这次访问记账到它的全部祖先上。运行失败的版本同样入树，只是被标记为失败。
沙箱由底座提供，运行失败、死循环和超时都会被隔离，因此不必对模型生成的代码预设限制。有了分数，程序才知道哪一版更好、下一轮该从哪里接着改。当这棵树能够持续生长、不需要人工逐轮介入时，产物就在自行迭代。
一个具体例子是半无穷区间上的振荡积分——这是物理计算里绕不开的一类量，通用积分器在这里会失灵：它靠局部误差估计决定往哪里加密采样，而这些函数振荡一直不停，给不出可靠的收敛判断。
取 38 道这样的积分，题面和答案全程不对模型开放，唯一的反馈是精度分。作为基线，直接调用 scipy.integrate.quad 的成绩是−3.40：19 道打分题中只有 3 道进入 3% 容差，最差一道与真值相差约 24 亿倍。搜索历时 2 小时、产生 236 个版本后，最好成绩出现在第 119 版，得分−0.0007：用于打分的 19 道全部算准，平均相对误差 0.07%。最终那份 247 行的程序会先判断被积函数在何处发散、振荡有多快，再分情况选算法——不是为 38 道题各写一个分支，而是一套通用规则，因此在未参与打分的另外 19 道题上同样有效。
同一套方法换到别的对象上也有结果：在高斯超几何函数₂F₁的双精度求值上，48 次扩展、598 秒产出的程序把平均正确有效数字从 9.836 提升到 11.771；在 AlgoTune 收录的 154 个真实数值计算任务上，按官方评分规则平均加速 2.279 倍、耗时降至原来的四成多；在从观测数据反推方程的符号回归任务上，111 道题中有 41.4% 写出了正确方程，每题平均仅需 16.5 次模型调用。
这些数字的意义不在大小，而在于它们是跑出来的，不是写出来的。
更值得注意的是搜索走过的路线。最终版本的父节点是第 116 版，而第 116 版由第 65 版改写而来——一个得分仅−2.22、早已被超越的版本。它被重新选中时，当时的最优版本第 95 版已经被连续改写 5 次没有更好结果，预算随之转向别处。如果选择规则只盯着当前最优版本往下改，这条路径根本不会出现。
这正是树搜索与"第一版不行，就一直改第一版"的本质区别：当前最好的方案，未必是通向更好方案的唯一入口。
支撑它的是一层演进底座，把循环固定成四个插槽：改什么、从哪个候选出发、怎么跑怎么打分、怎么合并提交。循环本身不动，换算法只更换插进去的对象，换任务只更换评分函数和根节点——积分、代码加速、符号回归跑的是同一套底座。
所以，搜索树负责决定"下一步试什么"，记忆图谱负责说明"之前做了什么、判断依据什么"。两者配合，探索才既有方向，也有记录。
从纳米抗体到大飞机，AI 进入科研现场之后，衡量标准也随之改变。
回答得快，只是起点。
接下来要看的是：证据能不能查清，工具有没有真正执行，不同路径能不能比较，失败有没有留下有效信息，验证结果能不能推动下一轮研究。
这里还有一个更根本的约束，值得放在最后说。
前面那棵 236 个版本的搜索树，之所以能在 2 小时内跑完、全程无需人工干预，是因为它的结果能被机器判定：积分算得准不准、代码快了几倍、方程写没写对，跑一遍就有答案，几秒到几十秒。
但科研里的大多数问题不是这样。验证一个抗体候选要合成样品、等一批细胞长起来；验证一副机翼要吹风洞。周期以天甚至月计，每错一次的成本都不低。
在这些领域，卡住搜索的往往不是改不改得出更好的版本，而是要等多久才知道这一版到底好不好——验证慢一个数量级，整个循环就慢一个数量级。
所以，把干湿实验闭环、全流速并行协同设计做快，本质上是在做同一件事：把验证做快、做便宜，让反馈能更早回到设计端。
openJiuwen ScienceDiscovery 及两个案例所呈现的，是一种更具体的科研智能化方向：不是让 AI 替科学家宣布发现，而是让它承担更多组织、执行、记录和迭代工作，让研究者能够把精力放在目标、判断与关键验证上。
科研智能体最值得期待的，不是把"我认为"说得更像"我知道"，而是帮助研究者把"我认为"，一步步变成"我验证过"。
社区贡献
欢迎每一位开发者、科研人员以及领域专家参与共建，通过 issue 提出反馈或贡献内容，我们会持续迭代优化。
ScienceDiscovery 代码仓：
ScienceDiscovery：https://gitcode.com/openJiuwen/sciencediscovery
openJiuwen 社区：https://gitcode.com/openJiuwen ｜ https://www.openjiuwen.com
