1. 项目概述从“黑盒”到“白盒”的科学探索最近和几个做AI科研的朋友聊天大家不约而同地提到了一个痛点现在的大语言模型LLMAgent在辅助科学发现时能力确实越来越强能读论文、提假设、设计实验甚至分析数据。但整个过程就像一个“黑盒”Agent为什么提出这个假设它基于哪些证据链进行了推理在多个备选方案中它又是如何一步步筛选和演进的我们往往只能看到一个最终结论却无法追溯其思考的“足迹”。这对于追求严谨、可重复、可辩论的科学领域来说无疑是一个巨大的信任瓶颈。这也正是“Toward Auditable AI Scientists: A Hypothesis Evolution Protocol for LLM Agents”这个项目标题直击的核心——我们需要的不是只会输出答案的“神谕”而是其思考过程可审计、可追溯、可理解的“AI科学家”。简单来说这个项目探讨的是一种为LLM Agent设计的“假设演化协议”。它不是一个具体的软件工具而是一套方法论和框架旨在规范Agent进行科学假设提出与验证的完整工作流。其核心目标是让Agent的“科学发现”过程变得像实验室的原始记录本一样每一步操作、每一次决策、每一个证据的引入都有据可查。这不仅仅是技术上的可解释性XAI更是流程上的可审计性Auditability。想象一下未来一篇由AI辅助甚至主导发现的科学论文其附录里可以附上一份完整的“假设演化日志”同行评审员可以像审查实验步骤一样审查AI的推理路径质疑其证据权重甚至复现其演化过程。这将是人机协作科研范式的一次深刻变革。这套协议尤其适合那些探索性、交叉性强的研究领域比如药物早期靶点发现、新材料设计、复杂系统建模等。在这些领域人类研究者常常面临海量文献和庞杂数据的“信息过载”一个能系统化梳理知识、生成并迭代假设的AI伙伴价值巨大。但前提是我们必须信任它。因此无论是AI算法工程师、计算科学研究员还是希望引入AI工具提升科研效率的领域科学家理解并实践“可审计的AI科学家”这一理念都将是未来几年的关键课题。2. 协议核心设计构建假设演化的“四步循环”一个可审计的AI科学家其核心不在于它多么“聪明”而在于它的工作方式是否“规范”。这里的“规范”指的就是一套清晰、结构化、可记录的假设演化协议。经过对现有自治智能体框架如AutoGPT、BabyAGI及Lilian Weng等人提出的智能体架构的思考我认为一个健壮的假设演化协议至少应包含四个核心阶段形成一个闭环的“观察-假设-实验-评估”循环并且每个阶段都必须强制输出结构化的“审计日志”。2.1 阶段一结构化观察与知识锚定一切科学探索始于观察。对于LLM Agent而言“观察”就是其输入的信息源。但“可审计性”要求我们不能简单地把一堆PDF或数据库链接扔给Agent了事。协议的第一步是强制Agent对其接收到的所有“观察”数据、文献、先验知识进行结构化处理和信息锚定。具体操作上Agent需要执行以下任务信息源标注为每一条输入信息如一篇论文的某个段落、一个数据库的特定条目生成唯一的、可追溯的标识符如Source_PMID_12345678_para3。关键信息提取与向量化不是简单地进行文本摘要而是按照预设的模板提取结构化信息。例如在生物医学领域模板可能包括[基因/蛋白]、[生物过程]、[表型]、[调控关系上调/抑制]、[证据等级临床/动物/细胞]等。提取后将这些信息转换为向量存入知识图谱或向量数据库并建立与源标识符的链接。矛盾与共识识别Agent需要主动识别不同信息源之间的冲突矛盾和一致性共识。例如文献A说蛋白X促进癌症转移文献B说抑制蛋白X对转移无影响。这将被记录为一个“知识冲突点”。注意此阶段的审计日志至关重要。日志必须记录原始输入源、提取的结构化信息、提取时使用的“提示词模板”、以及识别出的冲突/共识列表。这确保了后续任何假设的提出都可以回溯到具体的、被处理过的证据片段而不是模糊的“模型所学知识”。2.2 阶段二假设的生成与形式化表达基于结构化的观察Agent进入假设生成阶段。这里的风险在于LLM可能会天马行空地生成无数个看似合理但缺乏证据锚定的假设。协议在此阶段的核心约束是每一个生成的假设必须明确关联到支撑它的“核心观察集合”。操作流程如下假设触发可以基于一个突出的“知识冲突点”也可以基于一组高度相关的“共识观察”。例如观察到“多个独立研究显示化合物Y在体外抑制蛋白Z”和“临床数据提示蛋白Z高表达与不良预后相关”这可能触发假设“化合物Y可能通过抑制蛋白Z改善患者预后”。假设模板化强制Agent使用标准化的语言模板来表述假设。例如采用“[干预]会导致/影响[对象]的[指标]其机制可能与[路径]有关”的形式。这避免了自然语言的歧义便于后续的验证设计。证据链接生成的假设必须附带一个证据支持度列表列出所有支持该假设的“结构化观察”及其源标识符并可以初步计算一个置信度分数例如基于支持证据的数量、证据等级的加权和。实操心得在这一步我们常常需要给Agent设定“生成边界”。比如在药物发现中限定假设中的[干预]必须是已知的、可获取的化合物或基因操作工具[指标]必须是可测量的表型。这能防止Agent提出“用反物质治疗感冒”这类无法验证的科幻式假设。2.3 阶段三可执行的验证方案设计假设提出后需要设计验证它的方案。这是将思想实验转化为实际行动的关键也是审计的重点。协议要求Agent设计的验证方案必须是可执行、可量化、且具有明确成功/失败标准的。方案设计应包含以下要素验证类型选择是计算模拟如分子对接、网络分析、体外实验细胞实验、还是需要利用现有公开数据集进行回顾性分析选择必须与假设的规模和现有资源匹配。具体操作步骤如果是在线分析需给出具体的数据库查询语句、分析工具如R包、Python库及代码片段如果是实验建议需列出具体的实验方法如Western Blot、MTT法、所需的试剂、仪器和大致流程。预期结果与判据明确地定义什么样的结果算支持假设什么样的算反驳。例如“如果化合物Y处理组相比对照组的细胞增殖抑制率 50%且p值 0.05则初步支持假设否则反驳。”对照设置Agent必须说明需要设置哪些对照组阳性对照、阴性对照、溶剂对照等这是科学严谨性的体现。审计日志在此阶段需要记录完整的方案描述、选择该方案的理由例如为什么选择MTT法而不是CCK-8法、以及所有步骤的可追溯标识如使用的分析工具版本号、数据库版本。2.4 阶段四结果评估与假设迭代执行验证方案无论是通过调用API运行代码还是由人类研究员完成实验后Agent进入评估阶段。这里不仅仅是判断“对错”更重要的是根据结果动态更新假设的状态和置信度并决定下一步行动形成演化。评估与迭代逻辑结果解析与比较将实际得到的结果数据与阶段三定义的“预期结果与判据”进行自动化或半自动化比较。假设状态更新根据比较结果将假设标记为“初步支持”、“强支持”、“被反驳”、“需修正”等状态。置信度更新使用贝叶斯更新或其他算法根据新证据调整假设的置信度分数。被强证据支持的假设置信度上升被反驳的则下降。演化决策强化如果假设被支持Agent可以探索相关但更深入的子假设例如从“化合物Y抑制增殖”深化到“化合物Y通过诱导细胞周期阻滞在G1期来抑制增殖”。修正如果结果部分支持或存在矛盾Agent需要修正原假设。例如将“化合物Y通过抑制蛋白Z起效”修正为“化合物Y可能通过抑制蛋白Z或影响其上游信号通路起效”。淘汰如果被强证据反驳假设将被归档但审计日志中必须保留其完整生命周期记录包括被淘汰的理由。这能防止未来重复提出无效假设。融合当多个关联假设都被部分支持时Agent可以尝试将它们融合成一个更全面、解释力更强的超级假设。这个四阶段循环构成了假设演化的主干。每一次循环都伴随着一份增量的、结构化的审计日志。整个科研过程就变成了一个由这些日志串联起来的、可浏览、可查询、可质疑的“思维链”。3. 实现可审计性的关键技术栈要让上述协议从蓝图变成现实需要一系列关键技术的支撑。这不仅仅是调用GPT-4 API那么简单而是一个系统工程。3.1 审计日志的标准化与存储这是可审计性的基石。日志不能是自由文本必须是结构化的数据。推荐使用JSON-LD或类似格式因为它既能表达复杂关系又具有良好的可读性和互操作性。一个简化的日志条目可能长这样{ “context”: “https://schema.org/AuditLog”, “action_id”: “HYPO_GEN_001”, “timestamp”: “2023-10-27T10:00:00Z”, “agent_id”: “BioExplorer_Agent_v1”, “action_type”: “Hypothesis_Generation”, “input_observations”: [“Source_PMID_12345678_para3”, “Source_DB_GO_0006915”], “output_hypothesis”: { “id”: “HYP_001”, “statement”: “Inhibition of protein P53 increases cellular sensitivity to radiation in lung cancer cells.”, “confidence_initial”: 0.75, “evidence_list”: […] }, “prompt_used”: “Based on the following observations about DNA damage and apoptosis…”, // 记录生成时使用的具体提示词 “llm_model”: “gpt-4-1106-preview”, “llm_config”: {“temperature”: 0.2, “top_p”: 0.9} // 记录模型参数 }关键点必须记录prompt_used和llm_config。因为同样的数据不同的提示词和温度设置可能会得到完全不同的假设。这是实现“可复现性”的关键。3.2 工具调用Tool Calling的精确追踪现代LLM Agent的强大之处在于能调用外部工具搜索引擎、数据库、代码解释器、专业软件API。每一次工具调用都必须被完整记录。记录内容应包括工具名称与版本例如“pubmedpy v1.2.1”,“RDKit 2023.09.1”。调用参数具体的查询语句、函数输入参数。返回结果摘要如果结果很大如返回了1万条文献摘要至少记录结果的数量、关键统计信息或前几条样本。调用耗时与状态成功还是失败耗时多少这样当审计人员质疑“你这个结论是怎么从PubMed数据中得出的”我们可以精确地回溯到Agent当时执行的查询“P53 AND radiation AND lung cancer AND apoptosis[Title/Abstract]”并复核返回的结果。3.3 知识图谱作为“审计线索”的骨架结构化的观察和假设之间的复杂关系支持、反对、修正最适合用知识图谱来管理。每个观察、每个假设、每个实验方案都可以作为图谱中的节点它们之间的关系来源于、支持、验证了、反驳了作为边。这样做的好处可视化审计审计者可以直观地看到假设是如何从一系列证据节点中“生长”出来的以及不同假设之间如何竞争或协作。影响分析当一个底层观察被新的研究证实或推翻时我们可以快速在图谱中定位所有依赖于此观察的假设并评估其置信度是否需要批量更新。发现盲区图谱可以揭示哪些领域的观察很多但生成的假设很少可能缺乏连接思维或者哪些假设有很多间接证据但缺乏直接验证提示下一步实验方向。3.4 置信度传播与更新机制假设的置信度不是一成不变的。一个健壮的协议需要定义一套数学或逻辑规则来描述新证据如何影响假设及其相关网络的置信度。一种实用的方法是基于规则的加权系统不同等级的初始证据赋予不同权重如随机对照临床试验 队列研究 病例报告 体外实验。支持性证据增加置信度反驳性证据降低置信度。增减的幅度可以与证据权重成正比。当一个假设被修正时其置信度可以从原假设继承一部分并根据修正的幅度进行折扣。对于相互关联的假设如一个假设是另一个的子集置信度的变化可以部分传播。虽然这不如完整的贝叶斯网络精确但在计算复杂度和可解释性之间取得了很好的平衡并且其规则本身也是审计的一部分。4. 构建一个最小可行审计Agent的实操指南理论说再多不如动手搭一个。下面我将以“基于公开数据的药物副作用预测”为场景勾勒如何构建一个具备基本假设演化与审计能力的MVP最小可行产品Agent。我们假设任务是让Agent分析文献和数据库提出关于“某已知药物可能具有未被报告的新的治疗用途”的假设。4.1 环境与工具准备核心组件LLM选择支持良好函数调用Function Calling的模型如GPT-4 Turbo或Claude 3。这是Agent的“大脑”。框架使用LangChain或LlamaIndex。它们提供了构建Agent工作流、管理工具和记忆的基础设施。这里以LangChain为例。知识库需要接入一些公共生物医学API。PubMed/PMC E-utilities API用于获取文献摘要和基本信息。CTDComparative Toxicogenomics DatabaseAPI用于获取化学品-基因-疾病关系。DGIdbDrug Gene Interaction database用于查询已知的药物-基因相互作用。审计存储使用SQLite或PostgreSQL数据库。为简化我们可以用SQLite存储结构化的审计日志。更高级的可以用Neo4j来同时存储知识图谱和审计关系。代码环境Python 3.9安装langchain,openai,requests,sqlite3等库。4.2 定义Agent的工作流与工具首先我们定义Agent可以使用的“工具”Tools每个工具都必须是可追踪的。from langchain.tools import BaseTool from pydantic import BaseModel, Field import requests import json import hashlib from datetime import datetime # 一个简单的审计日志记录函数 def log_audit(action_type, agent_id, input_data, output_data, prompt_snapshotNone, llm_configNone): log_entry { “action_id”: hashlib.md5(f”{datetime.utcnow().isoformat()}{agent_id}”.encode()).hexdigest()[:8], “timestamp”: datetime.utcnow().isoformat(), “agent_id”: agent_id, “action_type”: action_type, “input”: input_data, “output”: output_data, “prompt_snapshot”: prompt_snapshot, “llm_config”: llm_config } # 这里简化处理打印并存储到文件。实际应存入数据库。 with open(‘audit_log.jsonl’, ‘a’) as f: f.write(json.dumps(log_entry) ‘\n’) return log_entry[“action_id”] # 工具1搜索PubMed文献 class PubMedSearchTool(BaseTool): name “pubmed_search” description “Search PubMed for scientific literature based on a query. Returns a list of article IDs and titles.” args_schema: Type[BaseModel] PubMedQuerySchema # 定义查询参数模型 def _run(self, query: str, max_results: int 5): # 1. 记录工具调用开始 tool_call_id log_audit(“tool_call_start”, “drug_repurposing_agent”, {“tool”: self.name, “query”: query}, None) # 2. 实际调用API base_url “https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi” params {“db”: “pubmed”, “term”: query, “retmax”: max_results, “retmode”: “json”} response requests.get(base_url, paramsparams) data response.json() id_list data.get(“esearchresult”, {}).get(“idlist”, []) # 3. 获取文章详情简化 results [] for pid in id_list: # 调用efetch获取摘要此处省略细节 title f”Placeholder Title for PMID {pid}” # 模拟 results.append({“pmid”: pid, “title”: title}) # 4. 记录工具调用完成和结果 log_audit(“tool_call_end”, “drug_repurposing_agent”, {“tool_call_id”: tool_call_id}, {“results”: results}) return results关键点每个工具的执行都被log_audit函数包裹记录了输入、输出和上下文。prompt_snapshot和llm_config将在Agent主循环中记录。4.3 实现假设演化循环接下来我们构建主Agent循环它遵循我们的四阶段协议。from langchain.agents import AgentExecutor, create_openai_functions_agent from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.memory import ConversationBufferMemory from langchain.chat_models import ChatOpenAI # 1. 定义系统提示词明确要求Agent遵循协议 system_prompt “”” You are an AI scientist assistant for drug repurposing. You MUST follow this workflow strictly: 1. OBSERVE: When given a drug name, use tools to gather structured knowledge about its known targets, pathways, and indications. 2. HYPOTHESIZE: Based on observations, generate a NEW, testable hypothesis about a potential NEW therapeutic use for this drug. Format it as: “Drug [DrugName] may treat [Disease] by modulating [Pathway/Target].” 3. DESIGN: Propose a concrete analysis to test this hypothesis using available public data (e.g., gene expression correlation, clinical trial data mining). 4. EVALUATE: Based on the (simulated) results, update the hypothesis confidence and decide next step (refine, reject, or explore further). For EVERY action, you must think step by step and link your reasoning to specific observations. “”” # 2. 创建Agent llm ChatOpenAI(model“gpt-4-turbo-preview”, temperature0.1) tools [PubMedSearchTool(), CTDQueryTool(), DGIdbQueryTool()] # 假设其他工具已类似定义 prompt ChatPromptTemplate.from_messages([ (“system”, system_prompt), MessagesPlaceholder(variable_name“chat_history”), (“human”, “{input}”), MessagesPlaceholder(variable_name“agent_scratchpad”), ]) memory ConversationBufferMemory(memory_key“chat_history”, return_messagesTrue) agent create_openai_functions_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, memorymemory, verboseTrue, handle_parsing_errorsTrue) # 3. 封装执行函数注入审计日志 def run_auditable_agent(query): # 记录本次任务开始和使用的LLM配置 session_id log_audit(“session_start”, “drug_repurposing_agent”, {“user_query”: query}, None, prompt.template, {“model”: llm.model_name, “temperature”: llm.temperature}) try: # 执行Agent result agent_executor.invoke({“input”: query}) # 从Agent的中间步骤通过callback或解析verbose输出提取关键决策点 # 这里需要更精细的Callback Handler来捕获每个LLM调用和工具调用并记录到审计日志。 # 假设我们有一个自定义的CallbackHandler audit_callback 做了这件事。 # 记录最终输出 log_audit(“session_end”, “drug_repurposing_agent”, {“session_id”: session_id}, {“final_output”: result[“output”]}) return result[“output”] except Exception as e: log_audit(“session_error”, “drug_repurposing_agent”, {“session_id”: session_id}, {“error”: str(e)}) raise # 启动任务 hypothesis_output run_auditable_agent(“Investigate potential new uses for Metformin beyond diabetes.”)在这个简化示例中我们通过系统提示词强制Agent遵循四阶段协议并通过log_audit函数在关键节点会话开始/结束、工具调用记录日志。一个完整的实现需要更复杂的回调处理器Callback Handler来捕获LLM每次推理的输入输出这是实现细粒度审计的关键。4.4 审计日志的查看与质疑执行完毕后所有的交互都被记录在audit_log.jsonl文件或数据库中。我们可以编写一个简单的查看器import json from tabulate import tabulate def view_hypothesis_evolution(session_id): with open(‘audit_log.jsonl’, ‘r’) as f: logs [json.loads(line) for line in f if json.loads(line).get(‘session_id’) session_id] print(f”Audit Trail for Session: {session_id}”) print(“”*50) for log in sorted(logs, keylambda x: x[‘timestamp’]): if log[‘action_type’] ‘tool_call_start’: print(f”[{log[‘timestamp’]}] AGENT called tool {log[‘input’][‘tool’]} with query: {log[‘input’][‘query’]}”) elif log[‘action_type’] ‘tool_call_end’: print(f” - Got {len(log[‘output’][‘results’])} results.”) elif log[‘action_type’] ‘llm_reasoning’: # 假设我们记录了LLM的思考链 print(f”[{log[‘timestamp’]}] REASONING: {log[‘output’][‘thought’]}”) elif ‘hypothesis’ in log[‘action_type’]: print(f”[{log[‘timestamp’]}] HYPOTHESIS {log[‘action_type’].upper()}: {log[‘output’].get(‘statement’, ‘N/A’)}”)通过这样的审计追踪我们可以清晰地看到Agent为了研究“二甲双胍”先搜索了哪些关键词的文献获取了哪些已知靶点如AMPK然后基于哪些证据提出了关于“抗癌”或“抗衰老”的新假设以及它打算如何验证这个假设。5. 协议落地中的挑战与应对策略将这样一个理想的协议应用到真实复杂的科研场景中会面临诸多挑战。以下是我在实践中总结的几个关键难点及应对思路。5.1 挑战一信息源的可靠性与偏差处理LLM Agent的“观察”完全依赖于输入的信息源。如果输入的数据存在发表偏倚、数据错误或领域共识尚未形成Agent会“学”到错误的知识并在此基础上提出有偏的假设。应对策略多源交叉验证要求Agent对任何关键信息必须从至少两个独立的数据源进行交叉验证如同时查询PubMed和Embase或对比不同的专业数据库。证据等级标签在信息结构化提取阶段就为每个“观察”打上证据等级标签如“随机对照试验”、“回顾性研究”、“专家观点”、“临床前研究”。在后续假设生成和置信度计算中赋予不同等级的证据不同的权重。主动识别冲突如前所述将识别“知识冲突点”作为协议的必要步骤。当冲突出现时不是简单地选择一方而是将其作为一个待解决的关键问题可能触发更深入的文献调研或设计实验来澄清。5.2 挑战二LLM的“幻觉”与可控性即使提供了完美的信息源LLM本身也可能产生“幻觉”捏造不存在的引用或事实关联。在假设生成阶段这尤为危险。应对策略严格引用锚定强制要求假设陈述中的每一个关键事实元素如“药物A抑制靶点B”都必须附带一个或多个来源标识符。在最终输出或审计日志中这些引用必须是可点击/可查询的链接。假设合理性过滤器在Agent输出假设前增加一个独立的“审查”步骤。可以用另一个LLM或同一LLM的不同提示扮演“魔鬼代言人”专门对生成的假设进行批判性审视检查其逻辑连贯性和证据支持强度。设置“置信度阈值”对于自动进行的操作如将假设标记为“强支持”设定一个较高的置信度阈值例如0.8。低于此阈值的假设必须标记为“待人工复核”或“需进一步证据”。5.3 挑战三验证方案的可行性与成本Agent设计的验证方案可能理论上完美但实际中不可行、成本过高或伦理上不允许。例如它可能直接建议进行一项为期十年的随机对照临床试验。应对策略资源与约束条件输入在任务开始时就将约束条件明确告知Agent。例如“你只能建议利用现有的公开基因组学数据库如TCGA、GTEx进行的生物信息学分析或简单的体外实验。不能建议涉及动物或人体的新实验。”方案可行性评估工具开发或集成一个工具能够对Agent提出的实验方案进行快速成本、时长和复杂度的评估。这个工具本身也可以被审计。人机协同决策将验证方案设计分为“提议”和“批准”两个阶段。Agent生成多个备选方案并附上优缺点分析由人类研究员最终选择和敲定具体方案。这个选择过程也应被记录在审计日志中。5.4 挑战四审计日志的“信息过载”一个活跃的科研项目可能产生海量的审计日志如何让人类研究员高效地审查这些日志而不是被淹没在细节中应对策略分层级审计视图摘要视图只展示假设的演化树显示主要分支、关键转折点和当前状态。关键决策视图聚焦于那些导致假设状态发生重大变化的事件如被强证据支持或反驳。完整追溯视图提供所有原始日志的查询和过滤功能供深度调查时使用。自然语言查询接口允许审计者用自然语言提问如“为什么在第三步放弃了关于NF-κB通路的假设”系统能自动定位到相关的日志片段并生成摘要回答。自动化审计报告生成定期或按需生成一份可读性强的审计报告总结一段时间内假设的生成数量、演化路径、主要发现和遇到的挑战。6. 未来展望从可审计的助手到可信的协作者实现“可审计的AI科学家”协议其意义远不止于让AI的工作更透明。它正在重塑人机科研协作的关系。首先它建立了信任。当科学家能够像检查同事的实验记录本一样检查AI的推理过程时他们会更愿意采纳AI的建议甚至将一些探索性的、高风险的假设生成任务委托给AI。这种信任是深度协作的基础。其次它提升了科研效率与质量。可审计的流程迫使AI的思考更加结构化、逻辑化这本身就能减少无意义的探索分支。同时完整的审计轨迹为论文写作提供了极其丰富的素材方法学部分可以写得更加扎实补充材料也可以更加详实。再者它促进了科学发现的“可重复性危机”的解决。如果每一篇AI辅助的论文都附带其完整的假设演化日志和代码其他团队要复现或验证其结论就会容易得多。他们可以检查数据来源、重复分析步骤、甚至尝试不同的参数来看结论是否稳健。最后也是最具革命性的一点它为AI驱动的“规模化科学”铺平了道路。我们可以想象未来会有多个遵循同一套可审计协议的AI科学家Agent在云端7x24小时不间断地阅读全球新发表的论文交叉验证数据提出和筛选假设。人类科学家则更像研究总监负责设定宏观方向、审核关键决策、并设计最终的验证实验。这种“人类指挥AI执行”的范式将极大加速科学发现的进程。当然这条路还很长。协议需要标准化工具链需要成熟社区需要形成最佳实践。但“Toward Auditable AI Scientists”无疑指出了一个明确且正确的方向——我们需要的不是更强大的“黑箱”而是更透明、更可靠、更能与人类思维接轨的科研伙伴。从这个项目开始一步步构建起这个伙伴的“思维透明层”或许是当下AI for Science领域最值得投入精力的工作之一。