看起来你的问题核心在于通过COM对象创建Excel实例的方式，和老旧的Add-in2加载逻辑不兼容，结合你的补充信息和脚本片段，我来拆解问题根源和解决思路：

问题根源分析 #

你的脚本用New-Object -ComObject Excel.Application创建了一个受控的COM Excel实例，但你的Add-in2有两个致命限制：

1. 不支持COM自动化加载
2. 版本老旧，与Excel 2016兼容性差

这种情况下，当你用COM实例打开依赖Add-in2的工作簿时，Add-in2的加载逻辑会触发它自己启动一个独立的Excel实例（因为它无法在你通过COM创建的受控实例里正常注册加载），而目标工作簿仍留在最初的COM实例中——这就是为什么会出现两个分离的Excel窗口：一个带PI Datalink，一个带Add-in2菜单。

脚本里的关键触发点 #

你脚本中的这一行是直接诱因：

$objExcel = New-Object -ComObject Excel.Application

通过COM创建的Excel属于「自动化实例」，这类实例的加载项注册逻辑和手动打开的普通实例完全不同。老旧的Add-in2只能识别手动启动的Excel环境，无法适配COM创建的自动化实例，所以会自行启动新实例来加载自身。

解决方案：模拟手动启动Excel #

既然Add-in2不支持COM自动化，我们换个思路——绕过COM对象，直接用PowerShell启动Excel进程打开文件，完全模拟手动操作的逻辑：

替代脚本示例 #

$FilePath = "你的文件完整路径"
# Excel 2016默认安装路径，根据你的实际安装位置调整
$excelPath = "C:\Program Files\Microsoft Office\Office16\EXCEL.EXE"

# 直接启动Excel进程打开目标文件，完全模拟手动打开的行为
$excelProcess = Start-Process -FilePath $excelPath -ArgumentList "`"$FilePath`"" -PassThru -Wait

# 等待宏执行完成（根据你的宏运行时长调整等待时间，也可以用窗口检测做精准等待）
Start-Sleep -Seconds 12 # 示例等待12秒，按需修改

# 关闭Excel进程
Stop-Process -Id $excelProcess.Id -Force

额外优化建议 #

1. 宏自动触发：在Excel文件中配置Workbook_Open()事件，让文件打开时自动运行目标宏，无需脚本额外调用
2. 预配置加载项：确保Add-in2已在Excel的加载项列表中设置为「始终加载」，避免手动加载的繁琐
3. 兼容性模式：将Excel文件保存为旧版格式（如.xls），或在Excel中启用「兼容模式」运行，可缓解老旧Add-in2的兼容性问题

为什么原脚本行不通？ #

原脚本的COM实例模式是为自动化场景设计的，它会跳过部分手动启动时的加载项注册流程。而你的Add-in2依赖手动启动的Excel环境才能正常加载，换成直接启动Excel进程的方式，完全复刻了手动操作的流程，Add-in2就能和目标工作簿在同一个实例里正常加载了。

内容的提问来源于stack exchange，提问作者Carson