如何评估开源 AI 研究智能体

开源 AI 研究智能体承诺比封闭式问答服务提供更多控制权，但源代码可用只是有用评估的起点。代码仓库可以公开其代码，同时仍让重要问题没有答案：什么证据产生了结果，哪些数据跨越了网络边界，另一位研究人员能否重新运行工作流，以及机构必须承担多少运行工作。

因此，可靠的评估应从研究实践开始，而不是功能数量。目标是确定智能体是否让真实工作流更易检查、重复、治理和维护。AIPOCH Open Science 是有用的案例，因为它在本地优先的桌面应用中结合了文献管理、智能体、笔记本、科学连接器、项目文件和远程计算。它的设计既说明了可检查工作空间的潜力，也说明了已记录活动与可复现科学之间的差距。

定义评估单元

不要只通过询问研究智能体能否回答一个难题来评估它。首先定义完整的工作单元。这可能包括发现论文、附加来源记录、准备代码、选择数据、执行笔记本、提交集群作业、收集结果、制作图表和记录修订。流畅的报告只是该链条中的一种输出，而不是链条本身。

列出合格审查者需要检查的工件和决策。这通常包括原始输入、引文、生成的脚本、笔记本状态、执行日志、环境细节、模型选择、外部调用、中间文件、最终输出和审查者发现。然后检查产品是否保留它们之间的关系。装满文件的文件夹不如一条记录有用；后者能显示哪些输入、代码和执行生成了某个特定版本的结果。

AIPOCH 的技术文档描述了持久项目，其中包含对话、文件、Python 和 R 笔记本、执行记录、预览和工件溯源。0.26.0 版还将参考文献库与已注册远程计算机上的直接 SSH 或 Slurm 执行相连接。只有当这种关联能经受日常研究变动时，这种广度才有意义：修订的提示、替代分析、中断的作业、替换的来源和更新的输出。

绘制真实的控制边界

“本地优先”应被视为一个需要调查的问题，而不是完整的隐私结论。项目状态可以留在本地计算机上，而提示、上下文、搜索查询或任务参数可能传送到选定的模型提供商、科学数据库、代码仓库或远程集群。具有意义的控制边界是信息经过的完整路径。

针对每个工作流，绘制数据从哪里开始、哪个组件接收它、使用什么凭据、什么离开设备以及结果存储在哪里的图。对扩展重复这项工作。可复用技能可能执行代码，而连接器可能向外部服务发送参数。开源使检查成为可能，但不会替用户完成检查。

AIPOCH 提供模型选择、连接器、远程计算机，以及针对命令、文件变更和网络调用等操作的批准策略。这可以帮助机构使该工具与自身的提供商和基础设施相匹配。它也把工作转移给机构：有人必须审查配置、验证端点、维护凭据、理解扩展行为，并决定哪些操作应获得持续授权。

在评估中纳入平台特定的控制措施。AIPOCH 的 v0.26.0 说明称，笔记本网络控制默认适用于 macOS 和 Linux，而 Windows 需要一次性管理员设置。同一发布文档指出，其 Windows 安装程序未经过 Authenticode 签名。这两项细节都不能决定工具是否合适，但都可能影响部署策略和支持工作量。

从声明向后追溯一个结果至证据

有用的研究智能体应让审查者能够从结论向后追溯到其背后的证据和操作。选择一个有代表性的结果，例如由分析得出的表格或由多篇论文得出的主张，并在不依赖原操作员记忆的情况下尝试重建其谱系。

AIPOCH 为此测试提供了一个具体模型。其工件系统可以保留不可变版本和校验和，而其溯源视图可以将输出与可用输入、代码、执行记录、环境信息、对话上下文和审查发现关联起来。其较早的 0.8.0 版还为替代对话路径引入了分支。这些功能共同使变更可见，而不是悄然替换先前状态。

评估仍必须把证据保留与科学有效性分开。校验和可以显示文件是否变更；它不能显示方法是否恰当。执行日志可以显示运行了哪些代码；它不能证实统计假设是可靠的。引文记录可以识别论文；它不能证明智能体正确解读了论文。可检查性为专家审查创造更好的界面，而非自动化真相。

使用几个面向失败的问题。审查者能否识别哪个分支生成了已发布工件？他们能否看到来源是否被替换？他们能否区分生成的代码和已执行的代码？他们能否知道哪些结果来自远程作业？他们能否保留审查者的更正而不抹去原始输出？与精美演示相比，薄弱的答案更可靠地揭示溯源缺口。

区分可审计性与可复现性

可审计性询问过程是否可以检查。可复现性询问是否捕获了足够状态，以再次执行并获得可比较结果。智能体可能在第一项标准上表现良好，同时在第二项上仍不完整。

可复现性审查应寻找已识别的输入、依赖锁定、软件包和操作系统细节、随机状态、执行顺序、模型和提供商信息、远程配置以及外部数据集的身份。它还应记录无法冻结的内容。模型提供商可能改变路由或实现，科学数据库可能更新，远程集群的硬件或库可能不同。仅记录模型名称或对话记录并不能消除这些变量。

AIPOCH 明确将可移植环境恢复和完整会话重放列为尚未完成的工作。这是重要边界，而非小小的遗漏。其保留的工件和溯源如今可以支持调查，但不应被描述为确定性重建的证明。评估应在决策本身中记录这一区别，使用户知道哪些工作流仍需要外部环境管理。

使用非敏感数据进行受控重跑。把保留的项目记录交给第二位合格人员，移除非正式知识，并要求他们复现一个工件。记录每一项缺失依赖、未记录批准、不可用服务、手动文件移动和含糊指令。所得缺口列表比“工作流可复现”的一般性主张更可操作。

将基准测试视为有界证据

基准测试可以在定义条件下比较系统，但不能证明跨学科的研究质量。在接受分数前，检查任务来源、公开与私有划分、所选模型、评判方法、执行预算、基线配置和轨迹可用性。询问外部团队能否复现设置，以及报告指标是否暴露具有后果的失败模式。

AIPOCH 使用特定模型和两名自动评判者，在 BiomniBench-DA 的公开部分报告了 79.05 的结果。该基准的数据集卡片描述了源自出版物的 100 项生物医学数据分析任务，其中 50 项公开任务和 50 项私有任务。这是关于多步骤分析轨迹的有用、有界证据。它不是对所有研究领域、模型、机构或未公开数据集的验证。

比起单一平均值，应更重视独立复现和详细失败分析。引文错误、单位错误、不当的统计选择、编造的解释和恢复失败可能被汇总分数掩盖。可检查智能体只有在其记录确实帮助审查者定位并更正这些失败时才具有优势。

测试运行适配性，而非仅测试能力

集成可以减少参考工具、聊天界面、笔记本、终端和文件浏览器之间的交接。它也扩大了维护者必须支持的表面。桌面打包、数据库迁移、凭据、模型 API、笔记本执行、科学预览、连接器和集群调度器都可能各自独立失败。

AIPOCH 的 Slurm 支持说明了集成与提供基础设施之间的区别。桌面应用可以从配置好的主机上的作业提交、监控、恢复、取消、清理和收集结果。它不会把笔记本电脑变成高性能计算环境，也不提供内置云 GPU 服务。实验室仍需要正常工作的算力、访问控制、调度器策略以及能够诊断失败的人员。

权限值得进行基于任务的可用性测试。早期 AIPOCH 版本的一个公开 issue 描述了编写代码期间反复出现授权提示；该 issue 后来关闭，后续版本包含了权限变更。这段历史不能证明当前行为，但它指出了一项富有成效的测试：提示是否出现在可理解的风险边界，还是变成用户自动批准的例行中断。

衡量安装工作量、失败作业恢复、升级行为、扩展审查、日志清晰度和让第二位操作员上手所需的时间。记录采用后谁负责每项任务。工具可能提供有价值的控制，但如果组织无法维护其周围的控制平面，它仍可能不合适。

使用分阶段评估清单

从有代表性的非敏感工作流和既定基线开始。将试点保持得足够狭窄，以便检查每一步。然后使用此清单：

1. 在运行智能体前，定义研究问题、预期工件、可接受证据和专家审查者。
2. 清点每个本地和外部组件，包括模型、连接器、技能、数据库、代码仓库和远程计算机。
3. 记录哪些数据跨越每个边界，并验证权限符合机构规则。
4. 通过引文、输入、代码、执行、中间文件和工件版本，将一项最终主张向后追溯。
5. 改变一个假设，并确认替代路径仍可与原始路径区分。
6. 将保留记录交给第二位操作员，并记录重新运行工作流的每项障碍。
7. 检查基准条件和轨迹；将分数仅视为已测试配置的证据。
8. 引入一次执行或网络失败，并评估恢复、日志、清理和工件完整性。
9. 审查导入扩展的来源、许可证、脚本、网络行为、版本和维护者。
10. 将输出质量、审查时间、设置工作量、失败率和支持负担与现有流程比较。
11. 将未解决缺口归类为科学、安全、可用性或运行风险，并指定负责人。
12. 只批准证据和控制符合所需标准的工作流；避免默认给予产品更广泛的信任。

最终决策应具体。说明智能体可以执行哪些任务、可以访问什么数据、哪些操作需要批准、输出必须附带什么证据，以及何时必须进行人工审查。还应说明评估没有证明什么。

开源研究智能体在让重要工作更容易被质疑时最有价值。AIPOCH 展示了如何将文献记录、笔记本、远程执行、分支和工件溯源组装成可检查的工作空间。它也表明，开放代码仓库、基准分数或可见工作流本身都不足够。持久的标准是另一位合格人员能否理解路径、质疑方法、重跑可重跑的部分，并在明确的机构边界内运行系统。