1. 先区分三件事:研究、工程交付和聊天式解释
研究交付的是一个可以被质疑和复跑的主张,文字只是载体。主张需要说明问题边界、假设、证据、分析程序、反例、结论强度和已知失效条件。Agent 可以帮助串联这些对象,但不会自动赋予它们可信度。
| 工作 | 可以让 Agent 做 | 人必须决定或签字 | 最低可交付物 |
|---|---|---|---|
| 资料研究 | 检索版本、建立引文图、抽取可测试命题 | 来源是否可信、命题是否被原文支持 | 带定位的 source ledger |
| 芯片/系统实验 | 生成 benchmark、编译、反汇编、采集 profiler trace | 实验设计、环境控制、因果解释 | 代码、命令、环境、原始结果 |
| 性能代码 | 实现候选、生成 unit test、做参数扫描 | 不变量、内存所有权、并发与 API 语义 | 正确性门禁与独立基线 |
| AI4Science | 管理参数空间、调用 solver、拟合 surrogate、整理实验 | 物理模型、边界条件、误差模型和安全边界 | 方程、网格/数据、收敛和验证报告 |
因此“Agent 给出了一份研究报告”和“研究已经完成”之间至少隔着一层证据工程。对微架构一类逆向问题,这层尤其重要:模型可能把不同 GPU SKU、CUDA 版本或编译路径的现象拼成一个听起来连贯、却无法在当前机器上复现的故事。
2. 正确的研究闭环:主张图,而不是 prompt 到报告
把研究任务表示为一个有向图。每个主张都必须能回指到原始来源或实验;每个实验必须能说明它是在区分哪两个假设;每个结论都必须标明适用条件。Agent 的角色是图中的执行者和记录员,不是不可追问的裁判。
一个实用的 claim record 可以写成 {claim_id, statement, scope, evidence_ids, alternative_hypotheses, owner, status}。没有 scope 的“结论”通常最危险:例如某条指令在一个 driver、一个编译器 flag 和一个时钟状态下的吞吐现象,不能直接升级为“某代 GPU 的固定微架构规则”。
3. 文章一:用 Agent 做 Nvidia GPU 微架构分析,究竟在研究什么
《使用Agent做Nvidia GPU芯片微架构分析》把文档、指令编码、二进制反汇编和性能计数器接成一个可反复试验的闭环。原文呈现的实践包括让 Agent 协助定位 CUDA/PTX 文档、构造测试、处理反汇编或分析工具并自动化 NCU 测量;作者也明确把首轮生成视为仍需调试和验证的结果。后续的 《用Agent来分析Nvidia RTX系列芯片》也已作为同类研究入口补入目录;两篇标题接近,但公开信息不足以证明它们使用了完全相同的工具或得出了相同结论。
可以把这类任务拆成四层。第一层是规范层:CUDA C++、PTX ISA、编译器/driver release note 明确承诺什么。第二层是二进制层:某个 nvcc 命令和目标架构实际发射了什么 SASS。第三层是测量层:Nsight Compute 的指标、时钟、occupancy、缓存和带宽如何随受控变量改变。第四层才是推断层:哪一种微架构解释同时预测了多个独立实验。
不是 = 一条 profiler 指标 + 语言模型的自然语言解释
这里的 Agent 强项是并行化实验矩阵:改变指令形状、寄存器压力、block 配置、数据类型、依赖链和 cache 状态,自动归档每次构建与测量。人需要防止它把 correlation 当成 hardware law,并为每个实验指定反事实:若 H1 为真、H2 为真,分别应出现什么差异。
4. 微架构研究的可复现实验协议:从文档到反例
- 固定环境:记录 GPU PCI ID、VBIOS/driver、CUDA toolkit、OS、功耗/时钟策略、容器镜像和 CPU NUMA 绑定。不同 revision 的编译器就可能改变指令序列。
- 写最小 kernel:一次只改变一个变量。先保证输出与 CPU/reference kernel 一致,再测吞吐或延迟。
- 保存静态证据:保存编译命令、PTX、SASS、寄存器数、shared-memory 用量和二进制 hash。反汇编是 observation,不等于官方规范。
- 做受控测量:warm-up、重复次数、统计量、时钟波动和 profiler 开销都要入账。将采样模式、stride、占用率、launch overhead 与内存层级分开测。
- 设计反例:换一个指令组合、不同 problem size 或第二张同代卡;若解释只解释一个图,不能称为微架构结论。
用于这一层的权威起点应是 CUDA C++ Programming Guide、PTX ISA和Nsight Compute 文档。它们说明工具和编程模型,不会替任何未公开的内部 pipeline 背书。
5. 文章二:Agent 写高性能 H2D 库,真正需要验什么
《Agent写的一个高性能Host-to-Device 传输库》是另一个更具体的例子。文章的价值在于展示了高层设计由人给定、代码和文档可由 Agent 扩展的协作方式;它并不意味着“生成代码”天然拥有正确的 DMA、同步或性能语义。
Host-to-Device 路径至少包含 host buffer 的生命周期、pinned/pageable 分支、CPU gather/staging、copy engine、CUDA stream/event、GPU 可见性与完成通知。任何一个点错了,都可能出现看似很快、实际数据错位,或者在某种并发顺序下死锁的实现。详情可回到 25 · GPU 内存、缓存与互联;本页只解释 Agent 如何进入验证流程。
| 门禁 | 必须检验的内容 | 不能由什么替代 |
|---|---|---|
| 功能 | 随机大小、非连续输入、边界对齐、长尾大小的字节级比对 | 一次 demo 输出正确 |
| 并发 | 多 stream、取消、back-pressure、buffer reuse、异常路径 | 单 stream benchmark |
| 性能 | 端到端时间与 CPU copy、PCIe/NVLink DMA、同步分别计时 | 只报某个 kernel 时间 |
| 归因 | 基线、warm-up、NUMA、pinned memory、batch size、设备拓扑 | “Agent 生成的版本更快” |
6. 文章三:AI 编程/Agent 的正确用法,是让程序更容易被验证
《一个关于AI编程/Agent的讨论》提出的方向可以归纳为:显式状态机、清晰的不变量、纯函数和测试,会把代码生成从“猜一个大 patch”变成“填充可检查的局部契约”。这是架构方法,不是已经被所有项目证明的万能结论。
对科研代码,建议把 Agent 的权限按风险拆开:它可以创建 branch、写候选实现、生成性质测试和 benchmark;但它不应自行放宽误差阈值、删除失败样本、覆盖原始数据、改写基线或发布结论。每次 Agent 修改都需要代码 diff、测试结果、数据版本、执行环境和审查人。
7. AutoGLM 与 Agentic Infra:科研 Agent 需要可重置的实验世界
《谈谈AutoGLM 2.0以及背后的Agent Infra》和《谈谈Agentic AI对Infra的需求》将注意力放在 Agent 所依赖的执行环境、会话状态、工具与基础设施上。对于科研,这个观察非常关键:若 Agent 通过浏览器、shell、仿真器或远端 GPU 操作系统,那么“实验条件”本身就是研究对象的一部分。
科研执行环境应支持 checkpoint、reset、差分审计与最小权限。浏览网页、下载论文和执行代码是不同风险域;shell 命令、GPU 计费、私有数据和论文提交更不能共用一个无限权限的 Agent session。相关的服务端状态、暂停恢复和工具隔离机制见 09 与 18。
8. Agentic 时代的架构与互连:调度对象从 token 扩展到实验图
《谈谈Agentic时代的架构及互连》的标题提醒了另一层:科研 Agent 不只造成一次模型调用,还会造成检索、编译、文件交换、工具等待、重试和多节点数据移动。把所有资源只按 token/s 计费,无法解释一个实验为何在 GPU 空闲时仍然很慢。
调度器应至少看见 DAG 的节点类型、数据体积、是否有副作用、deadline、重跑成本、缓存命中和隔离级别。GPU LLM 服务、CPU 编译、网络存储和仿真队列是不同资源池;当它们共享一个 cluster 时,需要把 trace id 贯穿 runtime、NIC、文件系统和实验数据库。网络与拓扑的物理约束则仍由 22、23、26 处理,Agent 不会抹掉 RDMA 的拥塞、DMA 的所有权或跨 rack 的尾延迟。
9. Agent Swarm 可以帮助找反例,不能用“多数投票”制造真理
《从Moltbook社交到Agent Swarm》可作为多 Agent 协作与模拟的入口。若多个 Agent 同用一个模型、同一份语料和相似 prompt,它们的错误高度相关;三份一致的语言答案仍可能只是一份错误的复制。
更适合科研的角色分工是异质证据而非角色扮演:一个 Agent 只负责逐条核对来源,一个生成最小反例,一个维护基线和数据版本,一个根据预先写好的判据判定实验是否通过。它们的输出要汇入同一个 evidence ledger,并强制展示相互矛盾的结果。多 Agent 适用于扩大搜索和覆盖面,不适合绕过实验验证。
10. AI4Science 的底座仍是方程、离散化和误差,不是把科学问题改写成聊天
Zartbot 的 《科学智能AI4S-1:偏微分方程数值解》和《科学智能-AI4S-2:变分法和有限元方法》是 2024 的数学基础,故不把它们伪装成 2026 新工作。它们解释的却仍是 2026 AI4Science 的底线:模型若替代或加速 PDE/FEM solver,仍要面对边界条件、守恒量、稳定性、网格/时间步收敛与 out-of-distribution 参数。
discrete experiment: A_h(theta) u_h = b_h(theta)
scientific validity: residual + conservation + grid/time refinement + held-out regime
Agent 可以根据领域语言生成 solver 配置、调度 sweep、比较 surrogate 与高保真基线、寻找不稳定参数区间并写实验报告。但它不能替用户选择物理本构、把数值残差误称为真实误差,或在没有实验/观测验证时宣称“发现”了定律。
11. 一个可执行的 AI4Science 工作流:把 Agent 放在实验编排层
- 研究者写出问题、单位、几何、边界/初值、可接受误差和不可违反的守恒/安全约束。
- Agent 将自然语言需求编译为版本化的实验 manifest,而不是直接改 solver 源码;manifest 包含参数空间、随机种子、网格和资源预算。
- 先跑小规模 smoke test,再跑基线数值 solver;每次 run 保存输入、代码 revision、容器、网格和原始输出。
- Agent 只在预先定义的设计空间中提出新的采样点或 surrogate 候选;高风险参数必须回到高保真 solver 或实验验证。
- 报告将训练误差、验证误差、物理残差、收敛曲线和失败区域分开展示;任何一个通过不代表另一个自动通过。
这条流程适用于材料、流体、分子、芯片热仿真和网络系统实验。不同学科的测量噪声和安全约束不同,因此 evaluator 不能被一个通用 LLM rubric 取代。
12. 证据账本:让别人能重跑、审计和否定你的结果
每一个 Agent 动作都应写入追加式日志,而不是只保存最终对话。最低限度包括 source hash、prompt/template version、模型/工具版本、命令参数、环境、输入数据 hash、输出 artifact hash、wall time、费用和审批人。对私有数据,日志记录指纹和权限证明,不复制数据本身。
| 证据类型 | 需要保存 | 常见伪复现 |
|---|---|---|
| 论文/文档 | URL、版本/日期、定位、提取的命题 | 只存网页标题或二手转述 |
| 代码 | commit、diff、依赖锁、编译 flags、binary hash | 只贴最终脚本 |
| 数据/实验输入 | dataset/mesh/seed hash、生成规则、许可证 | “同一数据集”但版本已漂移 |
| 运行 | 硬件、driver、容器、调度日志、原始 metrics | 只报告挑选后的图 |
| 结论 | 主张范围、反例、未解释误差和 reviewer | 把一次成功拓展为普遍规律 |
13. 如何评估一个科研 Agent:用错误发现率,而不只看任务完成率
单一 success rate 会奖励“快速给出一份答案”。更有用的指标包括:找到多少可复现的反例、错误引用率、未经授权副作用次数、实验重跑成功率、结论被独立复现的比例、从失败到定位 root cause 的时间、每条被接受证据的成本。对系统研究,还需记录 profiler/benchmark 是否覆盖了目标硬件和负载。
可以使用两阶段评估:第一阶段让 Agent 完成一组隐藏的、已知 ground truth 的调试/重现实验;第二阶段让独立 reviewer 在不知道作者是谁的情况下重跑 artifact。前者测工具能力,后者测研究交付物是否足够。
14. 最容易被 Agent 放大的失败模式
- 证据洗白:把博客、旧版本文档、猜测性结果和官方规范混在一起,最后只留下肯定句。
- 实验泄漏:Agent 看到了 hidden test、未来数据或人工答案,再用它“发现”结论。
- 选择性重试:不断改 prompt 或 seed,直到出现预期图形,却没有记录失败 run。
- 环境漂移:driver、compiler、依赖或硬件变化,导致同一脚本不再测同一件事。
- 工具副作用:重复提交作业、删除文件、写入数据库或把私有数据经外部工具泄露。
- 成本失控:递归反思、多 Agent 辩论和大规模 sweep 没有预算/停止条件,烧掉 GPU 仍没有增加证据密度。
这些失败模式需要 runtime policy 约束,包括权限、停止条件、预算、可写对象和证据格式。具体的 Agent 程序级调度、暂停状态和工具幂等性见 09;研究型系统的论文/生产边界见 17。
15. 2026 状态:可用的工程能力,不等于已解决的科研可信度
截至 2026-07-16,能运行浏览器、代码和 GPU 工具的 Agent 已足以把“查资料 - 改代码 - 跑实验 - 汇总”的机械部分自动化;Agentic serving 也正在把程序级调度、KV 生命周期和多阶段成本变成系统研究对象。相关的 2026 论文和工程证据不应被描述为“高引用”的既定共识,详见 17 · 2026 Agentic serving 研究地图。
仍未被自动化解决的部分是科学判断:问题设定是否有意义、测量是否识别因果、数据是否存在偏差、结论是否越过证据边界、复现失败时该相信模型还是相信仪器。研究 Agent 最好的定位是提高实验和审计吞吐,而不是替代同行评审、领域知识或真实世界验证。
16. 本页纳入的相关文章与阅读顺序
下面按具体实践到方法门禁排列相关文章,只保留标题和链接用于溯源。其中两篇 2024 年 AI4Science 文章作为数学基础保留,并在上文明确标为旧基础,不计入 2025–2026 目录。
- 使用Agent做Nvidia GPU芯片微架构分析(2026-05-29):对应第 3-4 节。
- Agent写的一个高性能Host-to-Device 传输库(2026-05-23):对应第 5 节。
- 用Agent来分析Nvidia RTX系列芯片(2026-06-22):对应第 3-4 节;当前只把标题和原始链接作为溯源,不从标题外推实验细节。
- 谈谈如何使用Agentic Workflow进行大模型全栈研究(2026-06-08):对应第 2、7、12-14 节。
- 一个关于AI编程/Agent的讨论(2025-05-25):对应第 6 节。
- 谈谈AutoGLM 2.0以及背后的Agent Infra(2025-08-22)与 谈谈Agentic AI对Infra的需求(2025-07-22):对应第 7 节。
- 谈谈Agentic时代的架构及互连(2026-04-05)与 从Moltbook社交到Agent Swarm(2026-02-01):对应第 8-9 节。
- 科学智能AI4S-1:偏微分方程数值解(2024-04-13)与 科学智能-AI4S-2:变分法和有限元方法(2024-04-17):对应第 10-11 节。