计算化学公社

 找回密码 Forget password
 注册 Register
Views: 336|回复 Reply: 2
打印 Print 上一主题 Last thread 下一主题 Next thread

[灌水] 有关Agent全自动计算的乱谈

[复制链接 Copy URL]

451

帖子

8

威望

4623

eV
积分
5234

Level 6 (一方通行)

石墨

跳转到指定楼层 Go to specific reply
楼主
有关“利用AI(Agent)全自动进行计算”。这个问题现在很多计算公司、互联网公司在进行探索。需要注意,以下观点不可避免的带有强烈个人色彩、静态观点,而且保质期可能很短。

核心问题其实就是经过验证的资料少,没有成熟的工作规范,和想找一个通才、执行力很强的实习生上岗就能计算略略类似。

例如软件工程,在良好提示的前提下,AI写中等以下复杂度的程序的效果是很好的,但也不是什么魔法。这一切是因为数十年来软件业在实践中积累了大量经验和血泪教训,一方面是语料多,另外一方面形成了包括需求分析、技术选型、模块化开发、CICD...在内的工作规范。换句话说是因为模型厂背后是顶尖程序员和业务专家通过各种方式将”人生经验”注入到产品中。

计算化学Agent的根子上的问题就是:

(1)系统性的、工程化的、经过验证的资料少,注意这三个方面缺一不可。经典文献书籍、公社很多博文包括社长的讲义等,是系统性的、经过验证的资料,但不是工程化的。粗俗点说就是难以通过填表打勾、做台账的方式理解和管理,不能写成产品说明书或SOP。当然这并非贬义。这个资料还包括负面失败的信息。

(2)没有明确的业务形式和产品形式。到底是谁来买单谁来支持?直接卖给特定公司/课题组的话,每个组都是会要求深度定制的,这活不好干。拿纵向经费,其实是一个写本子的问题。计算公司开发用来减少简单-中等项目的工作量,似乎说得通,但是客户自己也可以用AI(包括编一个假大空的需求发过来),单子确实是越来越难了。

(3)没有成熟的工作规范。如果你要把一个工作长期地交给别人、别的单位,不要相信才华,有限相信制度。复杂组织的成功很大程度上是因为通过有效的管理、有效的流程,让任何人在这个岗位上都至少能完成底线任务。然而科研是手工业,没有通用的普适的、血泪教训换来的规范(深层矛盾:科研也不该过度被人为规范)。
举个例子来说,在复杂项目的中期阶段发现不太行,应该放弃还是应该尝试调整、怎么调整是合理的可以预估的、在时间/经费/学术合理性/资源/利益关系等等多重约束下作何抉择。这个时候我们想到项目变更、风险控制等等,作为一个人类专家是可以做出决断的,但是仅限于我们自己,交给别人都不放心。不是别人笨或者坏,而是没有“计算化学专家”的明确定位,没有“在风险达到5级、成本支出未超过40%的情况下可以直接放弃,然后联络谁、做什么工作把这件事收尾”的流程。(部分行业有,但是也还没有到大部分时候可靠、还容易陷入形式主义流程主义)


针对这三个问题(其实问题还很多,这只是说一些表面上的问题抛砖引玉),大致有一些能先走起来的路。

(1)资料问题,大摸底和知识注入。规模化地挑选、精炼数据,重新验证很多计算方式、泛函基组、力场参数、建模方式...形成解决方案书、最佳实践。把分散的知识和工具精心地筛选和编排。例如做金属的确定好边界是LAMMPS、atomsk、一组力场、外力和形变加载模版、后处理的计算范式...,耐心地挖个遍。这是一个烧专家人力的活。

(2)业务和产品问题。我估计最后如果有那么一些赢家,大概率是会和现有计算公司和软件公司有关,主要是有原来的业务模式和客群作为底子。纯初创或者跨界的风险很大,一没先试过市场深浅、尝过酸甜苦辣;二没有原来的业务支撑,卡个一年两年没什么效果/追加投入就得一拍两散。

(3)工作规范问题。还是需要大量真实高压项目的锤炼,不可能凭空想出来或完美移植别的行业的经验。如果你试过用PRD、MVP、迭代开发那一套软件工程的方式来弄,会发现到处似是而非;如果纯为了导向论文发表和评审,走基金项目的路子,也是不可避免刻舟求剑。这是说的技术上的,技术以外的还有预算、不同角色人的偏好、资源分配、权力结构等等,对AI的怀疑、狂热、焦虑都是正常的,也会反过来重塑AI和计算化学的工作方式,这就说虚了些。

第一阶段是一般性工作助手,这个没我们什么事,而且也进入中场了。第二阶段是窄领域中通过谨慎的取舍,做出如金属专家、溶液专家的智能体(但不光是帮你做计算和出结果,还得包括初步的项目管理和系统思维),这个时候会初具可用性,现在确实也看到曙光了。第三阶段在广度上会达到常规DFT专家、经典MD专家的范围,深度上有时能看到更加全局和哲学的思考,但是我们还无法非常确定具体怎么从第二阶段集成和深化到这个地步。第四阶段或许会囊括种种真正专家的思考,但最重要的是变得”可信”,充其量也就是猜测一下技术表现,除此以外很模糊。我们现在最多只能看见若干矛盾正在聚集:可信与效率、规范与探索、专家判断与流程托管、工程项目规划与科研不确定性。最后会冲和成什么形态,诚实地说还看不清。

再抽象一点,人才问题和叙事问题。需要多方面的人才,不仅是计算方面的人才的高效协作,这个不必多提。需要大家经历不屑-震惊-狂热-冷静-怀疑-重拾信心的多轮循环,不断地磨合,一点点的跑起来,最终坦然地接受和正常发展。至于时间上,初期产品跑起来会很近很赶,但更加深刻的改变要耐心一点。最重要的是新生事物要找到自己的定位,我们也需要找到自己的定位。

评分 Rate

参与人数
Participants 7
eV +34 收起 理由
Reason
qingshan + 5 谢谢
含光君 + 5 我很赞同
dnlx + 5 本文道理也适用于我所在的地质学科。
student0618 + 3 谢谢分享
Serious + 5 欢迎讨论
SharkYYX2025 + 3 欢迎讨论
sobereva + 8

查看全部评分 View all ratings

自在飞花轻似梦,无边丝雨细如愁。

全自动反应动力学(ReaxFF、AIMD、NEP等)后处理工具:github.com/tgraphite/reax_tools

1118

帖子

5

威望

2881

eV
积分
4099

Level 6 (一方通行)

A Student

2#
发表于 Post on 2026-7-10 23:59:08 | 只看该作者 Only view this author
将开源skill打包进主流agent工具大概是个方向,就如开源代码一样,不同之处是现在agent更general,限制比特定工具打包某个库少多了。

现有例子除了现在较有名的claude science背后打包了nvidia bionemo 的Apache 2.0协议 skill外,也见到有开发者社群的人提到自己的开源skill被包装进不知名订阅制工具,还把广告放给满情绪价值的github issue发回去给开发者本人。
习惯了某Agent生态系的很多到直接会继续使用的,尤其是agent比LLM时代以前的程序/软体更普适。我猜这几年还在探索阶段时,各大coding agent 提供者 (尤其是三大家) 会趁机先收集各大领域主要skill纳入自己的工具。不知以后会否有更规范的方法支持本来的开发者,但以后写skill 优化好支持各大agent,让e.g. A社收进去工具(或被直接搬走...),大概会是一个方向。

研究方向的话,计算化学方向大概只余方法开发的路了,反过来wet lab在人力比机器人成本低的情况下较容易。

游客,本帖隐藏的内容需要积分高于 100 才可浏览,您当前积分为 0


敬仰一针见血的指责,厌倦别有用心的赞美。

451

帖子

8

威望

4623

eV
积分
5234

Level 6 (一方通行)

石墨

3#
 楼主 Author| 发表于 Post on 2026-7-12 19:47:41 | 只看该作者 Only view this author
student0618 发表于 2026-7-10 23:59
将开源skill打包进主流agent工具大概是个方向,就如开源代码一样,不同之处是现在agent更general,限制比特 ...

这个没招,SKILL都是明文,放出来就是像教科书一样公开。没有Closed AI、A÷也会有人做,抓博客的人多了。要不动摇现有利益,建立某种能够相对公平透明的知识付费机制,恐怕比较困难。这个技术上不多猜什么,只能说小的窄的领域可能别人不在乎,大的广的肯定天天想办法套出来信息、逆向。

大规模印刷/广播电视/互联网曾经把旧传播者、旧专家洗出局。也让很多人的声音传播到全世界,虽然这些人也不见得从中获得丰厚回报,而是新的体系拿了大头。

湿实验自动化是慢很多,但一般性实验室操作工也早晚受到重大挑战。只能说未来的日子越来越卷,即使我们引以为豪的所谓“化学直觉”“科研视野”也在动摇。至于99%并不天才的人怎么过,就是国家和行业治理问题了,轻易评价不了。但是无论如何要坚信办法总比困难多,自己能找到出路。

自在飞花轻似梦,无边丝雨细如愁。

全自动反应动力学(ReaxFF、AIMD、NEP等)后处理工具:github.com/tgraphite/reax_tools

本版积分规则 Credits rule

手机版 Mobile version|北京科音自然科学研究中心 Beijing Kein Research Center for Natural Sciences|京公网安备 11010502035419号|计算化学公社 — 北京科音旗下高水平计算化学交流论坛 ( 京ICP备14038949号-1 )|网站地图

GMT+8, 2026-7-26 12:59 , Processed in 1.158724 second(s), 22 queries , Gzip On.

快速回复 返回顶部 返回列表 Return to list