最近行业里有两件事放在一起特别值得琢磨一边是谷歌AI领域的核心人物Jeff Dean再次把职业重心压向AI驱动的科学研究方向另一边是一支清华系团队开源了35B参数规模的AI4AI模型。两件事表面无关指向却是同一个结论——AI4AI也就是“用AI来自动化AI研究本身”正从论文里的概念走向开源社区可以动手验证的工程课题。先做一个事实澄清。标题里说Jeff Dean“离职创业”严格讲并不是最准确的公开表述。从公开信息看他目前的身份仍然是Google DeepMind首席科学家主攻AI for Science方向外界关于他可能以创业形式进一步押注AI自动研究的讨论更多属于行业预期。我们不去追这个八卦真正值得关注的是他这几年反复强调的一条主线AI最大的价值之一是帮助人类更快做出更好的AI。另一条信息更值得工程师关注。35B规模的开源AI4AI模型放在今天不算最大但它恰好卡在一个微妙位置比7B、14B模型有更强的多步推理和研究规划能力又比70B、405B模型更容易部署、更容易微调。对那些没有万卡集群、又想尝试“AI自动研究”的团队来说这是一个非常现实的选择。这篇文章不打算复述新闻而是围绕四个问题展开AI4AI真正要解决什么问题一个能自动做研究的系统需要哪些模块35B开源模型在中间扮演什么角色开发者现在能做什么、该避开哪些坑看完你会清楚AI自动研究这个东西到底和你有什么关系。1. AI4AI 到底是什么它要解决什么问题先给定义。AI4AI全称是 AI for AI翻译过来就是“用AI来加速、自动化AI研究本身的研发流程”。它和更常见的AI4Science、AI4Code是同一类提法区别只在于研究对象不同AI4Science用AI加速物理、化学、生物等自然科学发现。AI4Code用AI辅助写代码、修Bug、做代码审查。AI4AI用AI辅助设计实验、生成模型、评测模型、写论文把AI研究自身当作自动化对象。传统AI研发链条大概是这样的问题定义 → 文献调研 → 提出假设 → 设计实验 → 写代码 → 训练与调参 → 评测 → 写论文或进入下一轮迭代。这个流程里研究员的人力消耗是最大的瓶颈。文献要一篇篇读实验要一个个跑模型要一次次调评测报告要一份份写。很多时候真正卡住项目进度的不是“想不到好点子”而是“没有足够人力把想法验证完”。AI4AI要解决的正是这个“研究人力瓶颈”。它希望把上面链条里的环节逐个自动化让AI读论文、让AI提假设、让AI设计实验、让AI生成代码跑实验、让AI写评测报告。研究员从“亲自做每一件事”变成“定义问题和审核结果”。这里需要区分一个容易混淆的概念AutoML。很多人觉得AI4AI就是换了个名字的AutoML其实完全不同。AutoML自动化的是“模型选择和超参数调优”这一个环节它解决的是“怎么把模型调到最好”。AI4AI自动化的是完整的研究闭环它解决的是“整个实验项目怎么推进”。AutoML可以视为AI4AI系统里的一个组件但AI4AI的野心要大得多。这一章的核心判断可以浓缩成一句话AI4AI的本质是把研究流程从“人写代码、人看结果”变成“人定义问题、AI迭代实验”。它解决的不是模型能力不够而是研究效率上不去的问题。2. 为什么35B模型会成为这个赛道的焦点清华系团队开源的35B模型具体型号细节建议以官方仓库为准这里重点讨论为什么是“35B”这个体量而不是7B、14B也不是70B、405B。先看为什么需要大模型。AI自动研究不是简单的问答任务它要求模型能连续完成多步推理读一篇论文提炼出研究方法发现其中的局限性再提出一个可验证的新假设最后还要能把这个假设转成实验方案。每一步都有上下文关联前一步出错后面全盘皆输。7B、14B模型做单点任务够用但做这种长链路推理能力上限很快暴露。再看为什么不需要最大模型。AI4AI的核心使用方式是“多轮迭代”。一个Agent可能连续跑几十次实验每次实验都要调用模型多次。如果把模型换成70B甚至405B推理成本和显存占用会指数级上升。到那时不是能力不够而是成本根本不可控。35B正好落在中间能力足够支撑研究级长链路推理部署成本又比超大模型低一个数量级。我们有理由把这个体量看作当前阶段“能力与成本性价比最好的一个点”。还有一个更重要的因素开源。AI4AI系统有一个天然需求就是“可被信任”。当AI自动生成实验、自动执行代码、自动给出研究结论时如果模型是闭源的用户很难判断结论是否存在系统性偏差。开源模型的好处在于权重透明、推理过程可审计、可以被垂直领域数据继续微调。对科研场景来说这种透明性不是加分项而是必需品。这里顺带回应一个很多人在社区里讨论的问题为什么35B级别的模型尤其是采用稀疏专家结构的模型TTFT首Token时延偏高这是AI4AI应用中很现实的工程问题。原因通常集中在四方面总参数量大即使启用稀疏激活每次推理也需要把相关专家权重从显存或内存中调度出来访存开销高。路由机制会引入额外计算和决策延迟。长上下文场景下KV Cache占用大量显存与大参数权重形成资源争抢。如果推理框架没有做好连续批处理和前缀缓存预处理阶段的延迟会被放大。所以如果要在真实项目里部署35B级AI4AI模型vLLM、SGLang这类做了PagedAttention和Prefix Caching优化的推理框架基本是必选项。这一章的结论是35B在AI4AI赛道会成为主力选手不是因为参数数字好看而是因为它在能力、成本和透明度之间取得了当前技术条件下最好的平衡点。3. 从AI辅助研究到AI自动研究能力演进的三步路AI自动研究不是一步到位的从目前的公开案例和技术发展路径看大致经过了三个台阶。第一步是Copilot阶段也就是AI辅助研究。人类研究员主导一切AI负责读论文、润色文字、生成初稿代码。这个阶段的技术基线是通用大模型加插件工具今天的多数研究团队已经用上了。第二步是AutoML阶段系统自动化的是单一环节。AI自动调参、自动搜索网络结构、自动做特征工程。代表性方向包括自动化机器学习以及AlphaTensor这类自动搜索算法结构的系统。这个阶段的特点是AI管一段人管全局。第三步才是Agent阶段AI管理完整的研究循环。系统不仅能读论文还能提出假设、设计实验、生成代码、运行实验、分析结果并根据结果进入下一轮假设修正。这是AI4AI真正想要到达的位置。为什么把三个阶段分开说因为太多人混淆了它们。看到AlphaTensor能发现新的矩阵乘法算法就以为AI已经能自动做研究了其实AlphaTensor自动化的只是“算法搜索”这个具体环节而不是完整的研究流程。从“单点自动化”到“闭环自动化”中间隔着实验设计、结果验证、失败归因、知识积累等大量未解决的问题。从公开案例看当前业界更多处在第二步向第三步过渡的状态。已经有自动科研Agent能够完成“读论文→生成复现代码→跑通实验→生成报告”这类封闭流程但一旦遇到实验结果与假设矛盾需要AI自己提出修正方案时系统的稳定性就会明显下降。结论是AI自动研究的落地顺序不会是“一步到位替换研究员”而是先把可标准化的环节逐个自动化再慢慢组合成闭环。理解这个演进顺序能帮你避免对AI4AI抱有不切实际的预期。4. AI4AI系统的核心架构一个自动科研Agent需要哪些模块如果现在就要动手做一个AI4AI系统技术架构该怎么搭这里给出一个通用拆解不绑定具体框架适合大多数人理解。一个面向AI4AI场景的自动化科研Agent至少要包含六个模块。第一个是文献理解模块。负责解析PDF论文把标题、研究问题、方法、结果、局限性结构化抽取出来。这是整个流程的输入层抽取质量直接决定后面所有环节的上限。第二个是假设生成模块。它基于文献信息和领域知识库提出可验证的新假设。这里的难点不是“生成一句话”而是“生成的假设可被实验验证”意味着模型必须理解哪些变量是可控的、哪些指标是可以测的。第三个是实验规划模块。把自然语言形式的假设转换成结构化的实验配置包括数据集、模型、训练参数、评测指标。这个模块的产出应该是一份机器可读的YAML或JSON。第四个是代码执行模块。根据实验配置生成可运行的训练和评测代码并在受控环境里执行。这是整个系统里安全要求最高的部分因为自动生成的代码可能访问文件系统、调用外部API、消耗大量算力。第五个是结果分析模块。读取实验输出判断结果是否支持假设并把结论写回知识库。这里需要特别警惕模型的幻觉AI可能把失败的结果描述成成功。第六个是记忆与知识库模块。保存每一次实验的假设、配置、结果、失败原因形成结构化的研究历史。没有这个模块Agent每次做实验都是从零开始无法积累经验。可以用一张表快速理解各模块的职责和常见技术选型模块解决什么问题技术选型示例文献理解把论文转成结构化数据PDF解析工具、信息抽取模型假设生成提出可验证研究假设大模型 领域知识库实验规划把假设转成实验配置大模型 JSON/YAML Schema代码执行自动运行实验沙箱环境、任务队列结果分析判断实验是否支持假设大模型 统计分析记忆与知识库沉淀历史实验经验向量数据库 关系数据库这一章的结论是AI4AI系统的核心不在单个模型有多强而在闭环能力有多完整。六个模块任何一个断了整个系统都会退化成“一个会聊科研的大模型”。5. 一个最小可运行的AI4AI工作流示例理解了架构我们来看一个最小闭环的代码示例。目标是跑通“读论文 → 提出假设 → 生成实验配置”这个流程不追求完整自动化而是让你能直观理解AI4AI系统是怎么运转的。5.1 科研Agent骨架论文阅读到实验设计# research_agent_demo.py # 说明这是一个示意性的 AI4AI 工作流骨架 # 用于演示“论文阅读 - 假设生成 - 实验设计”的最小闭环。 # 实际使用时要替换成你自己的模型服务地址和数据结构。 import json from dataclasses import dataclass, asdict from typing import Dict, List dataclass class PaperInfo: title: str research_question: str method: str result: str limitation: str class ResearchAgent: def __init__(self, llm_endpoint: str): self.llm_endpoint llm_endpoint self.history: List[Dict] [] def read_paper(self, paper_text: str) - PaperInfo: 将论文文本结构化抽取为 PaperInfo。 prompt ( 请从论文中抽取以下字段title, research_question, method, result, limitation。只返回 JSON。 ) raw self._call_llm(prompt, paper_text[:6000]) return PaperInfo(**json.loads(raw)) def propose_hypothesis(self, paper: PaperInfo) - str: 根据论文的不足提出一个可验证的假设。 prompt ( 结合这篇论文的研究问题与局限性提出一个可以自动验证的新假设 并给出验证所需的实验变量。 ) return self._call_llm(prompt, asdict(paper)) def design_experiment(self, hypothesis: str) - str: 将假设转换为实验方案数据集、模型、评测指标。 prompt ( 请把下面的假设转化为实验设计包括数据集、基线模型、 评测指标、最小实验步骤。以 JSON 输出。 ) return self._call_llm(prompt, hypothesis) def run(self, paper_text: str) - Dict: 执行最小科研循环记录中间产物。 paper self.read_paper(paper_text) hypothesis self.propose_hypothesis(paper) experiment self.design_experiment(hypothesis) result { paper: asdict(paper), hypothesis: hypothesis, experiment: experiment, } self.history.append(result) return result def _call_llm(self, prompt: str, content: str) - str: # 这里换成真实模型服务OpenAI 兼容接口、vLLM、Ollama 均可。 # 示例中先返回一个占位 JSON方便你验证流程是否跑通。 return ( {title: demo, research_question: demo question, method: demo method, result: demo result, limitation: demo limitation} ) if __name__ __main__: agent ResearchAgent(llm_endpointhttp://localhost:8000/v1/completions) paper_text 这里粘贴一篇论文的摘要和核心方法段落 result agent.run(paper_text) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码的逻辑很清晰read_paper负责把论文文本转成结构化数据propose_hypothesis根据论文的局限性提出新假设design_experiment再把假设转成实验设计。三个方法串起来就是这个最小闭环。代码里的_call_llm目前是占位实现只是为了让你在没有模型服务时也能跑通流程。实际使用时把它替换成requests.post调用你自己的模型服务即可。5.2 用开源35B模型做本地推理如果你已经下载了开源35B模型最简单的推理方式是用Transformers库加载# local_inference_demo.py # 以 Hugging Face Transformers 为例加载 35B 级开源模型做推理。 # 模型名、依赖版本以实际仓库 README 为准。 from transformers import AutoModelForCausalLM, AutoTokenizer model_name your-team/your-35b-model # 请替换为实际开源模型 ID tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, device_mapauto, torch_dtypeauto, ) prompt 论文摘要your paper text。请提出一个可验证的假设。 inputs tokenizer(prompt, return_tensorspt) outputs model.generate(**inputs, max_new_tokens512, do_sampleTrue, temperature0.7) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))需要注意35B参数的模型以BF16格式加载权重就要占约70GB显存不是单张消费级显卡能跑动的。预算有限的话可以改成4bit量化加载大约能把显存需求压到20GB级别再配合Ollama或vLLM这类框架做本地推理。5.3 配置驱动的自动化实验流水线AI4AI系统不能每次实验都靠手写代码更合理的做法是把实验方案做成结构化配置再由程序读取执行。# experiment_config.yaml experiment: name: hypothesis_demo_001 hypothesis: 增加稀疏专家数量可以提升35B模型的推理速度 dataset: source: hf name: your_dataset split: test model: base: your-team/your-35b-model load_in_4bit: true inference: max_new_tokens: 512 temperature: 0.7 evaluation: metrics: [latency, accuracy, ttft] baseline: your-team/your-14b-model# run_experiment.py import yaml from pathlib import Path config yaml.safe_load(Path(experiment_config.yaml).read_text()) print(实验名:, config[experiment][name]) print(假设:, config[experiment][hypothesis]) print(评测指标:, config[experiment][evaluation][metrics]) # 这里继续接入本地推理和评测逻辑实验配置和代码分离的价值在AI4AI场景里会被放大因为Agent需要自动生成实验方案如果实验方案是一段自由文本后续解析会很痛苦如果实验方案是结构化的YAML程序可以轻松读取也可以反向校验方案是否完整。5.4 运行与验证依次运行两个示例python research_agent_demo.py # 预期输出一个包含 paper / hypothesis / experiment 的 JSON 结构 python run_experiment.py # 预期输出实验名、假设、评测指标如果输出符合预期说明你的最小AI4AI闭环已经跑通。下一步就是替换_call_llm里的占位逻辑接上真实模型服务然后把experiment_config.yaml里的字段扩展成你实际的实验参数。6. 怎么判断AI4AI系统真的有效评测的三个层次很多团队做AI4AI系统最后都卡在同一个问题上怎么知道它到底行不行这里给出三个评测层次由浅入深。第一层是子任务级评测。单独测文献抽取的准确率、工具调用的成功率、代码生成的可运行率。这个层次的评测最容易落地因为每个子任务都有明确标注集和自动化判断方法。大多数AI4AI项目应该先在这一层打磨。第二层是闭环级评测。给系统一个研究问题看它能否完成“提出假设→设计实验→运行实验→给出结论”的完整闭环并且过程中不需要人工干预。这个层次的评测指标可以是“闭环完成率”和“人工干预次数”。目前大多数系统在这一层表现还不稳定能做出来已经是很好的成果。第三层是发现级评测。判断系统是否产生了真正超出已有知识的新发现。这个层次需要专家评审和独立实验复现成本极高目前只适合头部研究机构做长期目标。可以用表格快速对照评测层次评测对象方法示例当前成熟度子任务级论文抽取、工具调用、代码生成人工标注集 自动化断言较高可以落地闭环级假设→实验→结论的完整循环在固定研究问题集上测试完成率中低需要人工复核发现级是否产生新知识专家评审 实验复现低长期目标结论是评价AI4AI系统先看闭环成功率再看单步准确性。如果一个系统单步指标很高但闭环经常中断说明模块之间的衔接设计有问题反过来如果闭环能跑通但单步准确率很低说明生成的实验结果可信度不够。两条腿都要走路。7. AI4AI和开源模型落地时最容易踩的坑AI4AI系统如果从原型走向真实使用很多工程坑才会暴露出来。这里列出六个最常见的问题。第一个坑是模型幻觉。AI在生成研究假设、引用文献、总结实验结果时可能编造不存在的论文、编造统计数字、把失败实验描述成成功。应对方式是把输出结构化强制模型引用来源ID再由程序做来源校验。第二个坑是实验不可复现。Agent自动生成实验代码后如果没有记录运行环境、依赖版本、随机种子实验结果是无法复现的。科学研究的底线就是可复现AI4AI系统必须把这个要求落实到工程中。第三个坑是成本失控。Agent循环意味着系统可能在无人看管的情况下连续跑几十次训练任务算力账单可能让你措手不及。上线之前必须设置预算上限、最大执行步数和人工审批机制。第四个坑是权限越界。自动生成的代码可能访问敏感数据或者调用你不希望被调用的接口。安全做法是给Agent的执行环境设置最小权限并在沙箱容器里运行。第五个坑是推理性能问题。35B模型如果部署不当TTFT会高得无法接受导致整个Agent循环变得极其缓慢。承接前文的分析请优先使用vLLM或SGLang并配合量化、连续批处理和前缀缓存。第六个坑是评测误导。系统在子任务上表现很好但端到端闭环实际是断的。这种“假成功”比“明显失败”更危险因为你会误以为系统已经可以商用。建议用一张表作为项目里的风险检查清单风险点典型表现应对措施模型幻觉引用不存在的论文编造实验结论强制输出引用ID做来源校验实验不可复现未记录环境和依赖结果无法再次运行每次实验生成容器镜像和requirements成本失控Agent循环反复训练账单超预期设置预算上限、最大步数、人工审批权限越界自动代码访问敏感数据或接口沙箱执行最小权限服务账号推理性能35B模型TTFT偏高并发上不去量化 连续批处理 Prefix Caching评测误导子任务强但闭环断端到端评测优先于单点评测8. 工程落地与最佳实践建议如果你准备把一个AI4AI原型带到真实项目里下面几条工程建议值得直接采纳。第一先做“人机协同”不要一上来就追求全自动。让AI负责文献调研、假设生成、实验配置模板这类低风险环节人类负责审核假设可行性和最终结论。全自动环留在试点环境中迭代。第二把中间产物全部结构化。假设、实验配置、实验结果、失败原因都按统一格式存库。只有数据沉淀下来系统才能从每次实验里积累经验也才能支持后续的分析和复盘。第三为每次实验建立可复现环境。用容器镜像固定操作系统、Python版本、CUDA版本、依赖清单。AI自动实验尤其需要这个约束因为代码不是人工review后再运行的。第四设置明确的预算和资源上限。在Agent配置里写入最大执行步数、单次实验耗时上限、月度算力配额。宁可多几次人工审批也不要让系统在夜里跑掉大量算力。第五推理层优先用框架而不是裸Transformers。生产环境建议vLLM或SGLang配合量化、PagedAttention、Prefix Caching。35B模型的推理性能问题大部分可以通过框架选择解决。第六安全权限遵循最小化原则。给AI4AI系统独立服务账号只授权它访问实验必需的目录和API。自动生成的代码如果涉及数据库或生产环境操作必须在沙箱或预发环境验证并且在变更前做好备份和回滚方案。第七日志要完整。Agent每次决策的理由、调用的工具、生成的结果都要有日志记录。出现问题时日志是唯一的追溯渠道。第八分阶段选型。先用7B或14B模型把流程跑通验证闭环设计无误后再切换到35B模型。大模型解决的是能力上限问题不是流程设计问题流程没理顺之前换再大的模型都是浪费。9. 总结AI4AI会重演开源大模型的老路吗回看过去几年开源大模型的爆发路径其实有很明显的规律先是闭源实验室跑通能力上限然后开源版本逐步追平接着工具链和生态爆发最后垂直场景应用大量出现。AI4AI很可能也会沿着这条路线走。现在这个阶段开源35B模型就像是当年那个“追平闭源能力”的转折点它让自动做AI研究这件事从只有头部实验室能玩变成有正常预算的团队都能开始尝试。接下来的关键变量不是模型再大多少而是数据、评测、实验闭环这套基础设施能不能跟上。对普通开发者来说现在最值得做的不是等一个“完全自动的AI研究员”产品而是用工程思维把AI4AI流程的闭环搭起来。先从文献阅读Agent做起或者先把实验配置和评测流程结构化。等这些基础能力到位AI自动研究离开实验室的日子也就不远了。要说最终的判断那就是AI4AI不是换了个名字的AutoML也不只是又一个AI概念它代表的是AI研究范式的变化。越早用工程化的方式去做研究闭环在这个新赛道上的积累就越深。