给研发智脑装上工具，究竟意味着什么？
FitAll Cortex 工具化链路概念图
在很多专业的仿真团队里，并不缺工具。
商业CAE软件装在工作站上，自研求解器跑在超算里，后处理脚本留在工程师的电脑上，还有一些用了很多年的算法，只有少数几个人知道怎样调用。
这些工具都能干活。
但如果有一天，你对AI说：
“用我们现有的求解器，把这个算例跑一下。”
它真的知道该怎么做吗？
程序在哪里？输入文件怎样准备？该用哪个版本？是在Windows 7、国产操作系统，还是超算上运行？任务怎样提交？哪些参数可以改？什么结果才算正常？
只要其中一个问题没有说清楚，AI就只能猜。
所以，把一个软件接口 交给AI，并不等于给研发智脑装上了工具。
一、会用一个工具，和能把它交给AI用，是两回事
熟悉求解器的工程师，知道怎样准备算例、提交作业和检查结果，但未必懂软件封装和平台集成。
熟悉系统集成的开发人员，可以把程序调起来，却未必知道它适合什么问题、哪些参数不能随便改、看到什么现象必须停下来。
这在CAE领域很常见。
更重要的是，程序能够运行，也不代表AI能够正确使用。
求解器可以正常退出，结果文件也可以完整生成，但边界条件、参考量或者物理模型仍然可能设置错误。
因此，一个真正可以交给AI的工具，除了程序本身，还必须带着输入输出、运行环境、适用范围、使用方法、资源要求和验证依据。
程序解决“能不能算”。
Engineering Capability还要回答：什么时候算，怎样算，谁可以算，以及怎样知道没有用错。
二、让软件的使用者，也能完成将工具接入Agent
这正是FitAll Cortex要解决的问题。
它并不是从零开始的。
Mirror长期面向科学计算领域，解决异构环境下计算资源整合、工具软件快速集成、数据衔接，以及批量作业的提交、监控和结果回收等问题。它以微服务架构为基础，把CAE设计分析优化过程中的软件、算力、数据、规则和方法封装成标准组件，再像“搭积木”一样组织成完整流程。
今天回头看，Mirror积累的不只是软件集成能力，更是一套扎实的科学计算运行时基础。
早期的FitAll，也就是“归元”，进一步解决怎样把一个科学计算软件或模型快速封装、集成进Mirror。
现在，接入对象从完整模型扩展到商业软件、自研代码、算法库和后处理脚本。FitAll Cortex在原有经验上加入AI，自动识别入口、参数、目录结构、输入输出和运行方式，再把无法判断的问题交给工程师确认。
软件使用者不需要先学会写接口。他只需回答自己真正懂的问题：工具用来做什么，哪些参数会变化，什么情况下不能用，结果出来后应该检查什么。
FitAll最早解决科学计算模型的智能封装；FitAll Cortex进一步解决工程能力的智能工具化。
Fit All into Cortex。
别的Cortex用工具干活，FitAll Cortex把已有能力变成Engineering Capability。
三、真实运行之后，还要验证结果
工具完成初步接入后，会进入FitAll Cortex的工具集市。
这不是一个只展示名称和图标的货架。每项能力都要带着清楚的说明、版本、输入输出、目标环境、测试状态和使用边界。
工程师可以在在线IDE中修改代码和配置，也可以把任务送入真实环境运行。有些工具依赖Windows 7，有些运行在国产操作系统上，有些需要商业许可证，还有些必须提交到超算，运行几个小时甚至几天。
FitAll Cortex要把任务送到正确的环境，并带回日志、状态、结果和工程产物。
但“真实运行成功”仍然不等于“工程结果可信”。
因此，运行前要检查输入、权限、环境和资源条件；运行后还要由Validator检查文件完整性、参数范围、收敛状态和关键结果。程序无法判断的物理合理性，则继续交给工程师。
真实运行证明工具能执行，Validator判断这次执行能不能被接受。
四、Skill不是说明书，而是工程使用方法
一个工具会运行，还不等于Agent会正确使用它。
工具应用Skill要告诉Agent：这项能力适用于什么问题，需要什么输入，依赖哪个软件版本和哪些工具，有什么工程约束、风险和资源成本，失败后怎么办，最终由什么Validator验收。
到了具体专业场景，还可以增加领域Skill。同一个后处理工具用于外流、内流或者燃烧问题时，关注的参数和判断标准并不相同。
这些内容也不应由最初的接入者独自维护。工具开发者修改代码，软件使用者补充真实问题，领域专家纠正适用条件和验收标准。每个人围绕自己熟悉的部分共同维护。
为专家用法命名、描述适用场景，建立独立的应用技能。
围绕 Fluent 两相流参数，通过对话补充设置流程、参考资料与验收方法；版本差异和待确认项也被明确保留。
五、一次接入，形成四种交付形态
经过运行和验证的同一项Engineering Capability，可以按不同场景构建为四种标准产物：
CLI，用于统一的命令行调用；
Python库，用于代码和计算流程集成；
MCP，让支持MCP的Agent和应用发现并调用；
Skills目录，让Agent理解什么时候用、怎样用，以及怎样验收。
它们不是四套互不相关的工具，而是同一项Engineering Capability的不同交付形态。
MCP负责连接，Cortex负责工程任务。
发布后，这项能力会同步进入MCLink Cortex的能力目录。不同的专业Agent不必重复封装同一套软件，而是在Engineering Mission中按权限、环境、算力预算和验证规则调用它。
任务结束后，留下的不只是一条“调用成功”的消息，还有输入、日志、结果、验证证据和任务状态。模型可以更换，Agent可以演化，但经过验证的Engineering Capability仍然能够继续复用。
六、发布不是终点，成功经验还要被固化
工具进入研发现场后，总会遇到新的工况、软件版本、计算环境和失败方式。
工程师在任务中补充的经验，不应该直接变成一条正式规则，也不应该继续散落在聊天记录里。
它可以先成为候选经验，经过再次运行，由工程师或Validator确认后，再固化为新的Skill、测试案例或Verified Routine。
第一次解决新问题，需要AI探索；第二次遇到同类问题，就应该尽量变得确定。
于是，一项Engineering Capability形成自己的循环：接入、真实运行、验证、补充Skill、构建发布、进入Cortex，在Engineering Mission中使用，再把验证过的经验带回来。
最后
给研发智脑装上工具，不是在界面里增加一个图标，也不只是为软件增加一个接口。
它意味着，把团队已经拥有的软件、代码和算法，连同运行环境、使用方法、权限边界和验证依据，转化为AI可以调用、Runtime可以管理、Validator可以验证、Engineering Mission可以复用的Engineering Capability。
过去，Mirror和FitAll主要解决软件之间怎样连接。
现在，FitAll Cortex要让这些能力真正进入研发智脑，并在一次次真实任务中变得更可靠、更丰富，也更值得信任。
这就是“给研发智脑装上工具”真正意味着的事。
下一篇，我们想继续讨论：
仿真Agent真正难的，真的是调用求解器吗？
