科学智能体基础模型：从工具调用到闭环的科研新范式

从标题看Intern-S2-Preview: Scientific Agentic Foundation Model很容易被快速归类成“又一个 Intern 系列大模型的中间版本”。但我更想先把注意力从“Intern-S2”这个名称上移开停在后面的定语上Scientific Agentic Foundation Model。这六个词组合在一起比模型本身更像一个信号。它不是传统的“科学问答模型”也不是“带工具的聊天机器人”它试图代表一个更完整的范式基础模型不再只回答科学问题而是面向科学任务自主规划、调用工具、反复试错、走向一个可验证的结果。“Preview”这个后缀也值得留意。它说明这是一个阶段性版本一个需要研究者和工程用户去试、去反馈、去暴露问题的实验性产物。理解这一点比盲目跟风更重要。这篇文章会把重点放在“科学任务为什么需要 Agentic 范式”“这种基础模型到底改变了什么”“接进真实科研工作流时你要做哪些准备”这几个方向上尽量把范式和工程之间的链路讲透。1. 为什么科研场景现在才需要“智能体基础模型”1.1 过去的科研 AI本质上是一个“知识复述器”很长一段时间里人们接触到的科研大模型核心能力是“记住知识并生成文本”。你输入一个问题它给出结论、公式推导或者参考文献解读。这种能力的巅峰体现在大量科学考试和知识问答榜单上生物医学选择题、化学命名、物理概念解释分数越来越高。但这和真实科研有距离。真实科研不只是“知道”而是“做”。一个材料学研究者要判断合成路线是否可行一个气候科学团队要跑数值模拟并检查中间状态一个生物信息学分析可能涉及几十个处理步骤下载数据、清洗、质控、比对、建模、可视化。这里面的每个环节都不是靠一句“下一步”就能完成的它需要模型理解过程、操作代码、检查输出、发现异常再决定继续还是纠正。传统大模型把“科学”压缩成了文本形态却丢失了科研的“操作形态”。1.2 从“会聊天”到“会把事情做完”智能体Agent范式解决的就是这个断层。一个科学智能体不再只是输出答案而是被放在一个具体的工作环境里环境里有命令行、Python 环境、数据文件、可调用工具、文档系统。它要做的不只是“知道下一步”而是真的执行下一步观察执行结果再根据新信息迭代。背后的差异可以用一个类比理解过去的科研 AI 像一个备考很好的面试者你问什么它答什么智能体更像一个新加入课题组的实习生你给它一个工作台和明确目标它会尝试打开数据、找方法、跑脚本、看报错、改参数中间可能要经历很多次失败但最终会交出一个经过执行的产物。Intern-S2-Preview 的命名里带“Agentic Foundation Model”我理解它想强调的正是一个底座型模型不是只适配某个具体任务的专用模型而是可以驱动多种科研工具链、适应跨学科任务的基础模型。这类模型的关键能力不是“知识覆盖广”而是让行动、反馈、修正形成一个可持续的循环。1.3 为什么过去没有现在才出现现在能往这个方向走有三个客观条件变了。第一工具的标准化程度提高了。代码已经成为大部分科研领域的共同语言AI 不再需要操作硬件设备只需要操作代码接口、数据接口、软件接口这让“执行”变得可行。第二模型获得了更大的上下文和更细的反馈机制。智能体在执行过程中会产生很多中间文本、报错信息、运行状态模型必须有能力处理这些不完美输入并从成功或失败的反馈里更新计划这需要训练方式做出整体改变。第三评测方式开始从“答案正确”转向“任务完成”。一句话答案很难验证但一个脚本能否跑通、一个数据文件能否生成、一个建模流程能否收敛这些都是相对客观的信号让模型有明确的优化方向。所以现在我们不是在做一件全新的场景而是在补上过去十年来缺失的关键环节把“语言能力”翻译成“科研生产力”。2. 科学智能体基础模型的价值不在“拆任务”而在“建闭环”2.1 拆任务只是起点闭环才是壁垒看很多 Agent 项目第一反应都是它能把一个大目标拆成多个子任务。比如“分析这批基因表达数据”拆成读取数据、过滤低质量样本、差异表达分析、富集分析、画图。但拆任务从来不是难点真正难的是“任务拆完之后怎么闭环”。如果模型每一步只是生成工作流描述然后停在那里等用户人工执行那它只是一个规划器连实习生工作流的自动化都算不上。科学智能体的核心闭环是生成一个操作比如写一段 Python 代码。在实际环境中执行它。读取执行产生的输出、错误、日志。判断这个输出是否合理。合理就继续前进不合理就修正方案。循环直到任务完成。这个闭环改变了过去“模型只对文本负责”的评估方式。模型将靠近真实结果通过每一步的客观输出来衡量工作是否有进展而不是通过“下一句话是否流畅”来做判断。从这个角度看Intern-S2-Preview 的“Scientific Agentic Foundation Model”定位本质上是在解决如何让基础模型在大规模多学科的科研工具环境中稳定完成闭环。如果只是单纯堆参数和训练数据并不会自动获得这种能力更关键的是让模型在训练阶段就接触“调用工具—观察输出—修正行动”的完整轨迹。2.2 为什么“可验证的任务”是一个关键设计科学智能体和通用智能体有一个很大的不同科学任务往往有更强的“可验证性”。你可以运行一个模拟器检验预测结果可以对照实验数据验证假设可以用已有代码库测一测新组合是否有效。这个特性让强化学习的反馈信号可以做得很清晰也让模型可以在较少的监督下自我纠错。这也是我判断这种范式会离科学实践更近的原因当模型每次操作都能得到一个输出结果输出和目标的差异就变成了学习信号。一次预测实验没收敛可能是数据问题也可能是参数问题模型可以通过尝试不同路径获得更精细的反馈。这种过程更接近真实科研的试错逻辑而不是标准考试中的非对即错。2.3 但它不是万能替代品要说明的是这个闭环是有边界条件的。它最擅长的是“过程可观测结果可判定”的任务。如果一个任务没有明确验证方式或者中间状态无法读取智能体就会变成一个“看似在做事实际在表演做事”的流程播放器。最常见的表现是模型写了一段脚本脚本运行成功但结果并不科学。它把“没有报错”当成了“结果正确”这恰恰是科研自动化最需要人盯住的点。所以我们会看到这类基础模型的价值不是替代科学家的专业判断而是把科学家从重复性、繁复、容易出错的流程中解放出来让人的精力集中在提出正确问题、定义成功标准、审查异常结果上。3. 接入真实科研工作流先跑通再批量再长期化3.1 选题和任务边界要先收敛很多团队拿到这样的基础模型后第一步容易跑偏直接扔给它一个非常庞大、宽泛的科研课题例如“帮我开发一种新药”或“分析这个课题组的全部数据”。这不是一个可运行的任务更像一个长期项目方向。更合理的做法是先收敛边界。选一个可以被自动验证的具体任务例如“给定一个数据集按预定义指标完成一次特征筛选。”“复现某个算法的实验并输出对比表格。”“对某段模拟程序的日志做异常分类。”“把一组非结构化实验记录清洗成标准表格。”这类任务的特点是有明确输入、清晰输出、客观判断标准、工具链可以搭好。先在这样的任务上观察模型是否形成闭环再逐步扩大任务范围这种投入产出比会高很多。我在之前的项目里见过一种糟糕的用法团队希望智能体直接驱动一座私有数据平台的十几个子服务。结果模型权限范围过大经常为了“完成任务”强行调用没有实际把握的服务中间还产生了一些不可预期副作用。这提醒我们接入真实环境时第一步不是“给模型更多权限”而是“限制它能触达的范围”。3.2 最小环境也要包含四个要素即使只是做一个最小验证科学智能体通常也离不开以下四类元素可执行环境Python Runtime、Shell 或容器沙箱保证代码能实际运行。数据资源样例数据、数据集说明、Schema 或数据字典。工具与文档需要调用的科学计算库、外部 API、软件文档文档的质量直接影响模型正确使用工具的程度。日志与回传执行器需要把标准输出、错误码、耗时、资源占用返回给模型这是闭环反馈的基础。从工程经验看第四点最容易被忽视。很多人搭了环境给了数据也准备了工具但忘了让模型能看到中间结果。模型自然只能盲人摸象凭感觉走下一步。所有看起来“智能”的规划都必须建立在足够的可观察信息之上。一个最小化提示词的设计也建议包含这样几个模块1. 任务目标用一句话描述最终交付物。 2. 数据说明数据集路径、字段含义、文件格式。 3. 工具与限制允许使用的库和命令禁止访问的目录。 4. 输出要求成功定义、结果格式、结束条件。 5. 执行约束最多尝试次数、超时时间、单步最大耗时。这看起来琐碎却恰恰是避免模型“自由发挥”到不可控的基础。3.3 单任务跑通了只代表最小流程闭合一个任务成功运行能说明流程是通的但它不代表稳定。模型可能是在多个尝试中靠运气踩到了一条正确路径而同样的输入再跑一次不一定能复现同样结果。要判断是否稳定不能只看一次输出要做三组测试多次运行相同输入重复执行看结果是否波动。扰动输入在合法范围内变换输入顺序、格式、少量字段看模型是否仍能完成任务。失败注入人为制造缺失文件、格式错误、依赖缺失等故障看模型是否能识别并恢复。这一步相当于把问题从“能不能做”推向“能不能可靠地做”。对科研任务来说尤其重要因为科研要求可复现性一次偶然的成功并不能支撑一篇结论。3.4 批量化和长期化还需要补齐工程拼图真正要进入科研生产的智能体不会只在一个 Jupyter Notebook 里运行。下面的工程拼图迟早要补齐算力与任务调度。沙箱隔离主要是防止模型误删文件或执行危险命令。任务级和步骤级的审计日志。失败重试和回滚机制。成本控制包括算力、API 调用次数、单任务预算。模型版本和工具版本的固定。只要长期使用这些都会变成硬性问题。模型能写出一段代码不意味着整个过程可以直接无人看管地生产化。我通常建议团队从“每次运行都有人审核”的半自动状态开始等确认模型在任务上稳定可控再把审核节点逐步放宽。不要一步跨到全自动。4. 怎样评估一个科学智能体好坏四个层级缺一不可4.1 第一层工具执行力第一个要看的是模型把人规定的操作转换成实际调用工具的能力。能不能选择正确的库函数能不能生成符合语法的脚本能不能理解 API 需要什么参数。这一层出问题通常是直接报错或没有产物。但也别只满足于“跑通了”。要检查它是否用了最合适的方式完成任务。如果模型逢任务就调重量级深度学习库本来一个统计函数能解决那就说明它对工具的整体认识还不够只是碰巧生成了能运行的路径。4.2 第二层过程规划力一个任务从起点到终点往往存在多条路径。好的科学智能体不会只沿着一条固定流水线走到黑而是能根据中间结果切换策略。评估时要留意模型的行为轨迹它是不是先做小样本探测遇到数据不平衡时是否先做分布检查实验失败后是盲目换参数还是先读错误信息推测原因这一层的信号更多来自日志和轨迹而不是最终答案。我在分析 Agent 运行日志时重点关注一个指标无效尝试占比。如果模型大多数时间在尝试和回滚说明它的推理过程并没有真正从失败中学习。高效的智能体应该有能力把无效尝试数量控制得很低同时保持发现新路径的探索性。4.3 第三层结果可信度第三层看结果本身。对科研任务来说“可信”至少包含三层含义结果要能复现。结果的统计量要合理没有明显逻辑矛盾。结果最好附有可解释过程能追溯到每条结论是由哪个步骤产生的。有些智能体会在结果文件中生成看起来整齐但其实无意义的数字比如给缺失值填了同一常数导致统计指标失真。这时候只验证“脚本 exit code 0”是远远不够的。在科研场景里我把这种形态叫作“技术成功科学失败”——流程都执行了但输出在科学意义上不可用。4.4 第四层安全与成本意识最后一个维度经常被低估智能体是否具备成本和风险感知。一个好的科学智能体应该能判断一个任务是大规模遍历还是先做少量样例验证。当数据有几十万行时用全量数据反复调试既拖慢反馈也可能造成算力浪费。它会主动缩小实验范围确认流程再扩展执行。否则一件 5 分钟能跑完的事可能会因为模型不断“过度调用”扩展成一个两小时的恐怖任务。为方便落地我把这四层做成了一个简单检查表层级关注点观察信号工具执行力能不能正确调用工具脚本可运行API 参数正确过程规划力会不会从失败中调整策略错误日志后是否更换方案结果可信度输出是否科学可用结论可复现指标无矛盾安全与成本是否控制风险和计算消耗能先用小样本验证不盲目全量执行四层之间的关系是递进的工具都跑不通谈不上规划规划都凌乱结果也难以可信结果虽然好看但如果不讲究安全和成本长期运行也会埋雷。5. 真实使用中会踩的坑和排查顺序5.1 最容易踩到的四个问题结合我在类似 Agent 系统上看到的情况比较集中的问题有四类**第一类幻觉工具。**模型创建出一个现实中不存在的函数或文件路径靠编造来继续执行链。Python 会立刻报 ModuleNotFoundError 或 FileNotFoundError但有些非标准工具不会只是悄悄返回空结果。这直接导致后续分析建立在无意义的数据上。**第二类死循环式重试。**一次执行失败后模型不读错误信息不断用近似指令重试只是把同一个方案重复几遍消耗资源却没有任何进展。**第三类长任务漂移。**多步任务跑到中间模型渐渐忘记最初目标开始对侧枝问题深入探索最后产出一个和原始任务关系不大的结果。**第四类把“无报错”当成“成功”。**任务确实执行完成了但模型没有校验输出是否满足指标导致下游使用一个污染过的结果。5.2 排查链路从现象到根因遇到问题建议按顺序排查而不是直接怀疑模型能力不够。先看现象到底是报错、卡住、无输出还是输出明显不符合预期卡住要先看网络、外部 API、并发限制无输出要先确认任务是否执行了工具输出不合理才要考虑模型推理。再看输入确认输入数据格式、字段、编码、目录权限。很多时候问题并不在模型策略而是它拿到的信息不够完整。再看环境依赖版本是否匹配、沙箱有没有网络白名单、外部服务是否正常。模型只是环境的放大器环境坏了再聪明的模型也会连续失败。再看工具链工具接口文档是否清晰模型是否理解每个参数的含义文档存在多义词或歧义时它选错参数的概率会显著上升。最后再怀疑模型能力如果前三层都没问题再观察模型是否总在同一个决策点反复失败。如是可以考虑换一个更合适的提示方式或者针对该场景微调。我自己在集成类似智能体时感受最深的一点是不要把所有失败归因于“模型智商不够”。很多失败本质上是设计者没有给它提供足够观察和反馈的通道。5.3 如何设置护栏科学智能体在生产环境中的护栏可以参照一个简化版的安全清单只能访问白名单目录。禁止删除原始数据或覆盖唯一文件。单阶段循环次数设上限例如 10 次。单次任务总耗时和总预算设上限。执行敏感命令前必须二次确认。所有操作记录日志便于回溯。这些听起来不像“智能”的一部分但没有它们再强的智能体也无法平稳落地。6. 从“智能体跑通任务”到“科研范式变化”6.1 它可能重新定义科研管理的颗粒度传统的科研流程中人的判断覆盖在每个环节。智能体基础模型的介入第一次让“科研过程的自动化”和管理“科研过程的自动化”变成了同一个问题。过去我们只能管理项目里程碑例如“三周后有初步结果”。现在我们可以管理更细的执行步骤记录每一步的输入、输出和决策依据。这可能会改变团队的协作方式。文献阅读、假设生成、代码编写、实验执行、结果汇总这些环节都能被智能体辅助甚至部分接管。研究人员提出问题的优先级会越来越高而执行具体计算与分析的时间占比会下降。6.2 但要小心可复现性危机这种高度自动化的流程如果管理不好很可能带来另一种可复现性问题。模型有随机性执行轨迹不是每次相同一条流水线跑出来可能在不同时间给出略有差异的结果。要让科学智能体真正进入严肃科研环境就必须把实验环境渲染成收戳“环境快照 版本固定 日志记录”的模式。也就是说你在数据分析和论文复现中长期遵守的规范性在智能体化之后不仅不能减少还要加强。每一次 Agent 行为都应该像一份实验记录谁发起的任务用了哪个模型版本做过哪些调用结果文件在哪里最终验证过没有。没有这些信息整个流程会快速退化成“黑盒产出结果”而这对科研来说是不可接受的。6.3 长期价值从执行自动化走向知识流程化把执行自动化以后可以更进一步想到一层价值把一次性的成功实验流程固化成“可复用的方法论”。举个例子一个课题组让智能体做了一次单细胞 RNA-seq 分析如果整个过程被记录、被抽象成可复用工作流那么下次拿到新数据就不需要再让模型从零开始探索一遍。它可以直接加载过往的“方法论模板”调整数据路径和参数再跑一次。这就是“流程复用”。它带来的价值不是每一次省几小时而是让科研中真正多余的事项沉淀下来。一次好的方案一旦被打磨稳定团队所有成员都可以站在这套模板上继续推进而不必每次重蹈覆辙。这也正好回应了我对 Intern-S2-Preview 这类项目最大的期待它代表的“Scientific Agentic Foundation Model”不只是接口页面的增强更是把科研从一个人坐在电脑前操作代码慢慢推向一种人机共同复现、共同验证、共同积累方法论的协作系统。研究者的角色因此变得更像“提出问题和判断优劣”而这恰好是真正的科学创造最前端的环节比编写某一段代码更接近科学的本质。7. 不要急着追新实用建议和判断框架7.1 现在最该做的事不是立刻用起来如果你已经看完介绍准备把这样一个科学模型用进自己的课题我会建议你把节奏放慢一点。不要一上来就追求让模型做全自动研究。合适的第一步是选一个你非常熟悉的、几天就能完成的科学任务用你在过去经验里建立的标准去检验它。比如让它复现你昨天刚做过的一段分析流程再对照你的原始输出进行比对。熟悉的任务的好处是你能快速判断它生成的每一步是不是合理有没有走过头有没有把工具用偏。这样做的目的不是测试模型有多厉害而是先理解“一个科学智能体在你这个具体领域里的行为习惯”它的优点是哪些缺陷在哪里。它会犯错你需要认识它的错误模式。7.2 判断一个科学智能体是否适合你的框架在决定要不要投入更多时间前可以用之前提到的四层表做一次小评估。如果它在工具执行、过程规划、结果可信、安全成本四个层面都达到六七成以上的预期再进一步尝试更大任务更合适。对不适合它的场景也要有所预期依赖大量私人默认知识、说不清目标的任务不适合它。需要频繁访问实体设备、离线仪器、私有数据库的任务目前还很难形成闭环。错误很难被自动识别只能靠人反复看结果的任务要谨慎交给智能体否则它可能自欺欺人。涉及高成本、高危险、不可逆操作的任务在没有护栏前绝不要使用全自动模式。7.3 回到我的总体判断现在能看到的方向已经比过去清晰很多。科学 Agent 不是简单意义上的加强版问答工具它是“基础模型科研环境闭环反馈”三者的整合体。要达到所谓“Foundation Model”的水准意味着模型既能处理丰富多彩的工具链也能在多样的科研过程里不断学习改进。而研究者真正的门槛不再只是让模型会“跑”而是会“验证”、会“停止”、会“承认失败”。如果让我给一句最想提醒的话我会这样说把科学智能体当成一个只对结果负责的执行助手太危险把它当成一个永远有新鲜方案、但需要人守着判断的协作伙伴才更接近可靠的使用方式。科学发现这件事仍然依赖问题意识和专业判断。Agent 把低层劳动效率提高之后留给人去做判断的时间变多了我们要做的不是赶紧把一切自动化而是把这些省出来的时间用在真正值得深思的地方。