ArchAgent v2：AI智能体如何自动化数据预取器设计闭环

如果说计算机体系结构领域有哪个方向堪称“最难啃又最值得啃”的硬骨头，数据预取（Data Prefetching）一定排在前三名。

原因很简单：现代处理器的算力增长早已超过内存系统能跟上的速度，访存延迟成为应用性能的隐形天花板。而预取器的作用，就是在 CPU 真正需要数据之前，提前把数据拉进缓存。这个“提前”听起来简单，实际做起来极其痛苦——它需要同时理解访存模式、缓存替换策略、硬件资源成本，还要在几十上百个基准测试程序上保持稳定收益。过去十年，设计一个能在真实负载中稳定生效的预取器，基本上要靠资深架构师的经验直觉和大量手工调参。

ArchAgent v2 这类工具的出现，正在改变这个局面。

它把大语言模型引入体系结构设计流程，把“写预取器代码—跑模拟器—看结果—改代码”这个高度重复的闭环自动化，并且在一项真正有挑战性的基准测试——数据预取锦标赛（Data Prefetching Championship）——中验证了可行性。这件事的意义不在于“AI 会写代码”这个老话题，而在于：AI 开始具备参与硬件设计实验闭环的能力，它能读模拟器的输出、理解性能指标、迭代出新的优化思路。对每一位关注 AI for EDA、硬件设计自动化或者 Agent 工程化落地的人来说，这篇案例分析都值得仔细读一遍。

这篇文章会从数据预取的难点讲起，逐步拆解 ArchAgent v2 这类架构智能体在竞赛场景中做了什么、它的工作方式是什么、如果你想在自己的项目中复现类似的思路，环境和实验流程应该怎么搭，以及真正容易踩坑的地方在哪里。

1. 这篇文章真正要解决的问题

先给读者一个明确判断：ArchAgent v2 的价值，不是“帮你写代码”，而是“帮你完成一次完整的实验迭代”。

在传统的数据预取器研究流程里，一名工程师一天的工作量大致是这样的：

1. 阅读 baseline 预取器的代码，理解某个 benchmark 的访存行为为什么差。
2. 想出一个优化点子，比如增加一个历史表、修改预取距离。
3. 花几十分钟改代码、重新编译模拟器。
4. 跑到新的 trace 上，等几小时甚至更久。
5. 发现 IPC 反而下降，回到步骤 1。

这套流程的最大问题不是“累”，而是“反馈太慢”，并且“经验沉淀不下来”。每个研究者都在用不同的方式做同样的事，但很少有人能系统地把“访存特征分析—策略构思—代码修改—结果验证”变成一个可复用、可并行的流水线。

ArchAgent 解决的就是这个问题。它把上述闭环交给一个智能体来完成，自己承担理解和推理的部分。具体到 Data Prefetching Championship 这个案例中，它做的事情是：根据模拟器的运行结果，自动分析预取器的性能缺陷，生成修改后的预取器代码，重新提交实验，然后继续观察下一轮结果。

读到这里，你应该已经清楚这篇文章适不适合你了：

• 如果你在做体系结构、存储系统或者 EDA 相关研究，ArchAgent 的思路会直接启发你的实验方法。
• 如果你在做 AI Agent 工程化，关注的是 Agent 如何和外部工具、模拟器、长任务闭环协同，这个案例是一个典型的“Agent 做科研实验”范式。
• 如果你只是做应用层开发，本文对数据预取的背景解释和工具链拆解，也能帮你理解底层硬件的性能瓶颈是怎么回事。

接下来，我们先回到问题本身：数据预取为什么难。

2. 数据预取为什么是体系结构的“硬骨头”

2.1 没有预取器时，系统会发生什么

先看一个最简单的场景。CPU 执行一条加载指令，需要读取内存中某个地址的数据。如果数据不在缓存里，就是一个 cache miss，CPU 需要停止执行，等待数据从内存返回。这个等待时间在 x86 服务器上通常是几十纳秒到上百纳秒，听起来很短，但 CPU 一个周期还不到一纳秒，这意味着 CPU 可能白白等待几百个周期。

预取器的作用，就是猜测哪些地址即将被访问，提前发出访存请求。如果猜对了，数据刚好在需要的时候出现在缓存里，miss 被隐藏；如果猜错了，它可能污染缓存、占用内存带宽，反而拖慢系统。

这就是预取器设计的第一对核心矛盾：激进程度与准确性。太保守，预取收益有限；太激进，错误预取带来的代价可能超过收益。任何优秀的预取器，本质上都是在反复权衡这对矛盾。

2.2 数据预取锦标赛到底在比什么

Data Prefetching Championship（DPC）是体系结构领域一项专门的竞赛，参赛者需要在给定的模拟器和 trace 集合上设计预取器。这个比赛的特点是：

• 固定模拟器：所有队伍使用同一个微架构模拟器，通常是 ChampSim 这类科研用模拟器，保证对比公平。
• 固定基线：有明确的 baseline 预取器，比如基于局部性的 next-line prefetcher，以及更复杂的 signature path prefetcher（SPP）、BOP 等。
• 多样化负载：trace 来自不同应用，包括科学计算、数据库、 AI 推理、图分析等。不同负载的访存模式差异巨大，预取器很难用单一策略通吃。
• 评价指标统一：以加速比、IPC 提升为主要指标，同时要关注准确率和带宽开销。

所以，评价一个预取器不是看它在单个 benchmark 上表现多好，而是看它在整套负载上的综合效果。这给人工调参带来了巨大挑战：你可能优化好了 A 类应用，却把 B 类应用搞崩了；你调的参数在 trace 集合上很漂亮，换一组真机负载后可能完全失效。

2.3 为什么这个场景适合作为 Agent 的试验田

数据预取锦标赛对 AI Agent 来说，是一个非常好的测试场景，原因有三点：

第一，它有明确的自动反馈。模拟器会输出 IPC、prefetch accuracy、coverage 等数字指标，Agent 不需要自己去“感觉”方案好坏，直接用指标说话。

第二，迭代路径清晰。从访存模式分析到代码修改到重新验证，每一步都是标准化的，适合用 Agent 去编排。

第三，优化空间大且存在多样性。不同应用的访存模式差异明显，Agent 需要不断调整假设，这种“在不确定性中做决策”的能力，恰恰是大模型 Agent 相对擅长的事情。

所以你会看到，ArchAgent v2 选择数据预取锦标赛作为案例研究，并不是偶然。它是在选一个“难度适中但反馈机制清晰”的领域，来证明架构智能体在真实科研实验中的价值。这也提醒我们：判断一个 Agent 工具是否成熟，先看它选择的应用场景是否具备清晰的闭环反馈。

3. ArchAgent v2 做了什么：从代码生成到闭环优化

3.1 ArchAgent v2 的定位

先厘清概念。ArchAgent 是一种面向计算机体系结构设计的 AI 智能体，它的核心能力是操作用户给定的设计环境，自动完成实验迭代。v2 版本相比早期版本，更大改进在于任务理解能力和多步执行能力：它不只是“生成一段预取器代码”，而是维护一个完整的实验周期。

我们可以把 ArchAgent v2 的工作过程拆成四个阶段：

阶段一：项目与任务初始化。Agent 接收用户的任务描述，了解当前模拟器环境、baseline 预取器代码、trace 列表和评估指标。这个阶段类似一个实习生入职时阅读项目文档。

阶段二：执行与观察。Agent 运行当前代码，收集预取器在不同 trace 上的表现数据，包括 IPC、prefetch coverage、accuracy 等。它会把失败或表现不佳的用例单独标记出来。

阶段三：分析与迭代。Agent 对比不同配置的结果，定位瓶颈，提出假设，生成新的预取器代码，重新提交到模拟器执行。这一步是循环的，会一直持续到满足退出条件或者达到预设的迭代上限。

阶段四：总结与诊断。当迭代结束后，Agent 汇总数据，形成结论，帮助研究人员理解最终方案为什么有效、在哪些场景下仍然存在局限。

这四个阶段并不神秘，本质上和人类研究者的工作流程一致。关键在于，Agent 把每个阶段都“显式化”了——它需要维护任务状态、结构化记录实验结果、在下一步行动之前读取分析结果。

3.2 与单纯代码生成的最大差异

很多人第一次接触 ArchAgent 时会觉得：“这不就是让大模型写 C++ 代码吗？”这种理解只看到表面。

如果只是生成代码，模型完全可以在没有任何模拟器反馈的情况下，直接输出一个“理论上很完美”的预取器。但实际工程中，这种直接生成的代码很难用：

• 编译环境可能有差异，代码在本地跑不通。
• 预取器和其他模块接口不匹配，链接失败。
• 即使编译通过，实际 IPC 收益大概率不如预期。
• 某个 trace 效果好，另一个 trace 效果差，需要权衡。

ArchAgent v2 的关键点在于它构建了一个有反馈的闭环。代码生成之后，必须经过编译、运行、结果观察、性能分析，再回到代码修改。没有反馈的“生成代码”，在硬件设计这种高成本实验场景中几乎没有价值；有反馈的“闭环迭代”，才可能逼近真实可用。

这也是我想提醒读者的第一点：评估一个 AI 编程类工具，不要只看它生成的代码质量，更要看它反馈闭环的完整度。能写一段好代码的模型很多，能在真实环境里跑完实验并自动修正的 Agent 才少见。

3.3 它在 DPC 案例中表现出的核心能力

从公开材料看，ArchAgent v2 在数据预取锦标赛这个案例中，表现出了几个值得关注的工程能力：

第一，能理解领域特征的上下文。它不只是看着代码逐行改，而是会把“访存模式”、“预取覆盖度”、“带宽开销”这些体系结构概念映射到具体代码行为上。这意味着 Agent 的训练或提示设计中，包含了体系结构领域知识的注入。

第二，能利用实验数据做决策。当模拟器返回结果后，Agent 会读取性能数据，和上一轮对比，判断当前修改方向是否有效。这种“以实验数据驱动决策”的能力，是真正接近科研工作者的行为模式。

第三，能管理多文件任务的耦合。预取器不是孤立存在的，它要适配模拟器的接口、处理不同的配置选项、兼容多线程和其他模块。ArchAgent 需要在多文件上下文中保持一致性，避免“改了一处，破坏另一处”。

我在这里特意不使用“实现了 XX% 性能提升”这样的表述，因为竞赛的最终成绩还受很多因素影响，包括 trace 选择、模拟器设置、随机性等。更稳妥的判断是：ArchAgent v2 证明了 Agent 能够完成从实验分析到代码迭代的完整循环，这是硬件设计自动化方向上一个实实在在的进展。

4. 案例分析：ArchAgent v2 在数据预取锦标赛中的“人机分工”

4.1 人和 Agent 各自负责什么

如果只看“Agent 自动跑实验”，很容易误以为人类可以完全撒手不管。真实情况不是这样的。

从公开信息推断，ArchAgent v2 在你自己的数据预取实验中的合理使用模式，更接近“人机协同分工”：

• 人负责：定义优化目标、约束条件（比如带宽开销不能超过多少）、评估指标权重、迭代轮数上限；提供领域初始假设；审查最终结果并做判断。
• Agent 负责：在给定的空间内快速执行大量尝试，记录中间结果，保持实验过程可复现，生成结构化分析报告。

这种分工的价值在于，Agent 可以把人从“重复且繁琐”的调参-编译-运行循环中解放出来。人可以专注于更高层次的权衡判断，比如“这个预取机制是否有硬件可实现性”、“某个策略在带宽受限场景下是否会失控”。

4.2 实验闭环的四个关键环节

假设我们要复现一个 ArchAgent 风格的数据预取优化流程，整个实验闭环通常包含四个环节。

环节一：环境启动。准备好模拟器、trace 和 baseline 代码，确保一次干净的编译运行可以成功。这是后面所有自动化的基础。

环节二：自动执行与数据采集。Agent 每次拿到一个预取器代码变体，都要自动完成编译、运行、收集结果、整理成结构化数据。这个环节看起来简单，实际上最容易遇到问题，比如模拟器启动参数复杂、输出日志格式不统一、编译缓存失效导致结果不可复现。

环节三：分析决策。Agent 根据上一轮的结果，决定下一步是修改预取深度、调整历史表大小、还是更换一种预取策略。这一步的难点在于 Agent 需要把“数字变化”转化为“代码修改决定”。

环节四：退出与汇报。达到迭代次数上限或性能不再提升时，Agent 输出最终代码和分析报告，人来做最终验收。

这四个环节中，环境启动是硬门槛，数据采集是稳定性瓶颈，分析决策是智能核心，退出汇总是体验关键。任何一个环节做不好，Agent 都会变成“看起来很智能，实际没法用”的玩具。

4.3 为什么说这是“Case Study”而不是“端到端产品”

项目标题里有一句很关键的话：“A Case Study with the Data Prefetching Championship”。这个表述说明，作者把它定位为一个案例研究，而不是一个已经成熟到可以直接替换真实设计流程的工业级产品。

凡是做过硬件设计的人都知道，预取器竞赛和真实芯片设计之间存在巨大鸿沟：

• 竞赛通常使用 trace 驱动的模拟，无法完全反映真实硬件的时序和功耗。
• 竞赛关注的是 IPC 提升，真实设计还要考虑布线面积、发热、多核干扰。
• 竞赛的 trace 集合是固定的，真实场景的负载千变万化。

所以，ArchAgent v2 的意义在于验证“智能体辅助体系结构实验”的可行性，而不是宣告“硬件设计师要被 AI 替代了”。对研究者来说，这是好消息：你拥有了一种新的实验工具，可以更快地验证想法、探索更大的设计空间。

5. 如果你想复现：ArchAgent 类实验的架构与关键机制

这一节我们进入实操层面。假设你不想用 ArchAgent 的完整闭源流程，而是希望在自己的硬件设计项目中搭建一个类似的“Agent 做实验”流水线，需要理解哪些关键机制？

5.1 总体架构：Agent + 工具 + 工作区

从架构上看，ArchAgent 这类工具通常由三部分组成：

• Agent 核心：负责推理和规划，通常基于大语言模型，通过提示词注入领域知识，通过规划模块决定下一步动作。
• 工具层：封装对模拟器、编译器、文件系统、代码库的操作，Agent 通过“调用工具”而不是直接手写 shell 命令来完成任务。
• 工作区：保存代码、中间结果、日志、实验状态，让 Agent 能在多轮迭代中保持上下文一致。

# 伪代码：Agent 实验闭环的核心逻辑（示意） from typing import Dict, List class AgentLoop: def __init__(self, simulator, workspace, llm): self.simulator = simulator self.workspace = workspace self.llm = llm def run_one_epoch(self, code_version: str, trace_list: List[str]) -> Dict: # 1. 编译当前版本预取器 self.simulator.compile(code_version) # 2. 在多个 trace 上运行，收集结果 results = {} for trace in trace_list: output = self.simulator.run(trace) results[trace] = self.parse_metrics(output) return results def decide_next_action(self, history: List[Dict]) -> Dict: # 3. 让 LLM 分析历史指标，生成下一步代码修改建议 prompt = self.build_prompt(history) suggestion = self.llm.chat(prompt) return suggestion

这段代码只是为了说明架构，不代表某款真实工具的具体实现。

5.2 关键机制一：结构化的状态管理

Agent 做多轮实验时，最大的问题是“迷路”：它改着改着，忘了最初的目标，或者忽略了几轮之前某个重要实验的结果。解决办法是结构化的状态管理。

建议的做法是，每轮实验后都生成一个实验记录文件，包含：

• 当前代码 commit 或版本标识。
• 修改了哪个文件、哪个函数。
• 每个 trace 上的 IPC、accuracy、coverage。
• Agent 当时的假设和下一步计划。

这样即使 Agent 的上下文窗口有限，也能通过读取历史文件来回溯决策链路。

{ "experiment_id": "exp_008", "parent_id": "exp_007", "code_version": "git-abc1234", "hypothesis": "增大预取距离至 8 可能提高流式访问的覆盖率", "metrics": { "per_trace_ipc": { "603.bwaves": 1.42, "605.mcf": 1.18 }, "prefetch_accuracy": 0.53 }, "next_plan": "尝试保持距离为 8，但将历史表项数减半，观察带宽开销变化" }

# 只提交一个实验信息文件，方便后续脚本解析 cat experiment_record.json

5.3 关键机制二：编译与环境的确定性

硬件模拟器的编译通常很慢，而且环境依赖复杂。Agent 自动改代码后，必须确保编译过程是确定性的，否则每次结果差异可能不是代码导致的，而是环境不一致导致的。

工程上建议：

• 使用 Docker 或固定的构建环境。
• 代码版本必须绑定构建产物，不能出现“代码改了但二进制没更新”的乌龙。
• 模拟器运行前检查编译时间戳或哈希。

# 文件路径：Dockerfile（模拟器环境示例） FROM ubuntu:22.04 RUN apt-get update && apt-get install -y \ build-essential git wget \ python3 python3-pip WORKDIR /workspace RUN git clone https://github.com/ChampSim/ChampSim.git

5.4 关键机制三：可插拔的领域知识注入

如果你希望 Agent 不只生成代码，还能像架构师一样“思考”，就需要把领域知识注入到提示词中。比如，当 Agent 面对一个访存密度高但局部性不强的 trace 时，它应该能联想到“这类负载可能更适合基于 PC 的预取，而不是基于地址的下一行预取”。

常见的做法是：

1. 在系统提示词中写入预取器基础概念。
2. 在每轮实验提示词中，附上当前 trace 的访存特征摘要。
3. 允许 Agent 在实验结果异常时，主动查询领域的知识文档。

# 一个可选的提示词模板文件示例：prefetch_prompt.txt 你是一名资深计算机体系结构工程师，正在优化数据预取器。 当前 baseline 是 next-line prefetcher，缓存行大小为 64 字节。 实验结果表明： - 在 matmul 场景中 prefetch accuracy 为 0.42，coverage 为 0.38； - 在 linked-list 场景中 accuracy 为 0.20，coverage 为 0.10。 请分析两个场景访存模式差异，并给出下一步最值得尝试的预取策略。

领域知识注入的质量，直接决定了 Agent 是“厉害的代码机器”还是“真正的架构助手”。这也是 ArchAgent 这类工具和通用 ChatGPT 写代码相比，最核心的差异点。

6. 动手实践：从 ChampSim 开始搭建实验环境

如果你被前面的分析打动了，想亲自动手跑通一个最小实验，这一节可以给你一个具体路径。

6.1 选择模拟器和实验材料

科研用途的模拟器有很多选择。数据预取锦标赛常用的 ChampSim 是一个不错的起点，它开源、模块化、专门用于缓存层级和预取器研究。你需要准备：

• ChampSim 源码。
• 一组 benchmark trace（通常是压缩的文本格式或二进制格式，按指令流组织）。
• baseline 预取器配置。

安装步骤很简单，但执行顺序有讲究：

# 1. 克隆模拟器代码 git clone https://github.com/ChampSim/ChampSim.git cd ChampSim # 2. 检查支持的基本预取器 ls prefetchers/ # 3. 编译（不同分支的编译命令可能不同，以官方 README 为准） ./build_champsim.sh bimodal no # 4. 查看帮助 ./run_champsim.sh -h

如果你本地没有下载 trace，也可以用模拟器自带的简单测试用例或者生成小规模合成 trace，先跑通流程。

6.2 第一次运行：观察 baseline 效果

跑通流程后，你需要记录 baseline 的结果，作为后续 Agent 优化的对照。

# 运行模拟器，指定 trace 和配置 ./run_champsim.sh bimodal-no-lru 1 ipc 1 1 计算模拟器参数 1 1 1 1 0 0 1 1 trace_file # 关键输出项通常是： # CPU 0 core IPC # total L1D misses # total L1D prefetch requests # L1D prefetch accuracy

如果你的环境无法直接运行官方脚本，也可以绕过脚本，直接调用编译好的模拟器二进制，并传入参数。关键是保证你能拿到结构化的输出数据。为了方便 Agent 解析，建议把指标提取成 JSON 或 CSV。

# 文件路径：parse_champsim_log.py # 功能：从 ChampSim 输出日志中提取关键指标，输出为 JSON/CSV import re import sys LOG_PATH = sys.argv[1] def parse_log(path): result = {} with open(path, "r", encoding="utf-8") as f: for line in f: line = line.strip() m = re.match(r"CPU 0 core IPC: ([\d.]+)", line) if m: result["ipc"] = float(m.group(1)) m2 = re.match(r"L1D PRELOAD REQUESTS: (\d+)", line) if m2: result["prefetch_requests"] = int(m2.group(1)) return result if __name__ == "__main__": metrics = parse_log(LOG_PATH) print(metrics)

python3 parse_champsim_log.py output.txt

运行后，你至少应该看到 IPC 等关键指标被正确输出。如果这里解析失败，后续 Agent 的所有分析都会失去数据基础。

6.3 最小实验闭环版本

如果你不打算立刻接入 LLM，可以先用传统方式跑一个“手动 Agent 闭环”：记录 baseline 指标，人工修改预取器参数，重新编译运行，对比指标。这个流程跑顺之后，再考虑接入大模型自动决策。

这里我建议你按顺序完成三个验证：

1. 验证 baseline 能正常跑通。
2. 验证你能读到并解析指标。
3. 验证任意修改代码后，指标会发生变化。

第三个验证特别重要。如果改完代码指标完全不变，那很可能你的修改没有真正生效，可能是编译缓存、参数传递或构建脚本的问题。这也是实际工作中最常见的坑。

7. 常见问题与排查思路

在搭建和运行 ArchAgent 类的预取器优化实验中，我整理了几个高频问题。这些问题有的来自模拟器使用经验，有的来自 Agent 工程化常见陷阱，建议先收藏再对照排查。

除了表格中的问题，还有一个容易被忽略的环节：LLM 的非确定性。同一轮实验，同样的输入，Agent 的下一步决策可能不同。这会导致实验不可复现。工程上的常见解法是：在做重要决策时，让 Agent 给出多份候选方案，再统一评估；或者固定 temperature 参数，并在实验记录中写明模型版本和随机种子。

8. 最佳实践与工程建议

这一节写一些基于实践经验的建议。无论你最终选用 ArchAgent 还是自建流水线，下面这些原则大概率都能用上。

8.1 实验治理优先于模型能力

我在看很多团队做 Agent 实验时，发现大家过度关注“模型是否聪明”，却忽略了一个更本质的问题：实验过程是否可治理。

在硬件设计场景中，一次错误的迭代可能耗费数小时计算时间。如果你的工作区没有版本控制、实验结果没有结构化记录、Agent 的决策链路人眼无法追踪，那模型再聪明也白搭。我建议优先做好三件事：

• 代码全部进 Git，每轮实验一个 commit，提交信息写明假设。
• 实验结果统一命名，比如 exp_007_20250101_ipc.json。
• Agent 每轮决策必须生成一个简短的解释，写入日志。

这样，即使 Agent 出现严重错误，也能方便地回滚到某个历史版本，并且通过日志回答“为什么当时会做这个决定”。

8.2 用“迭代预算”和“退出条件”管住 Agent

Agent 运行起来之后，潜在风险是它会在一个无意义的方向上反复试错。所以，在实验启动前，一定要明确：

• 最大迭代轮数是多少。
• 如果连续 N 轮 IPC 没有提升，是否停止尝试当前的策略方向。
• 当某个修改导致指标显著下降时，是否自动回滚到上一版本。

这些约束可以写在系统提示词里，但更可靠的做法是在工作流代码中硬编码判断逻辑。不要把 Agent 的自觉当成保障。

# 一个朴素但有效的收敛判断示例：连续 3 轮 IPC 提升不足 1%，就切换策略 echo "如果最近3轮平均IPC提升 < 1%，进入探索性实验模式"

8.3 领域人机接口设计：让 Agent 能理解“硬件不可行”约束

预取器设计和纯软件优化不同，它还要考虑硬件的可实现性。例如，一个在模拟器中效果很好的预取器，可能需要一个巨大的存储表，在真实芯片上面积和功耗都不可接受。

如果你希望 Agent 的建议是可落地的，就应该在设计接口时加入约束。比如：

• 预取器使用的存储预算上限。
• 允许的额外内存带宽。
• 预取深度范围。
• 是否可以修改缓存替换策略（通常不允许，因为会干扰其他模块）。

# 推荐在任务描述中明确约束，例如： 约束条件： 1. 预取表项总存储不得超过 32KB。 2. 最大预取深度为 8。 3. 不允许修改 L2 缓存替换策略。 4. 生成代码必须通过 clang-tidy 静态检查。

8.4 从“Agent 写代码”到“Agent 做研究”的认知升级

最后一个建议稍微抽象一些。不要只把 ArchAgent 当做一个自动写代码插件，而要把它当做一个可以承载“科学方法”的实验人员。

真正的科研实验流程是：假设驱动、数据验证、结论修正。一个成熟的架构智能体也应该遵循这个流程。所以，在你设计 Agent 的提示词时，不要只写“修改代码”，而要写成：

1. 分析访存模式，形成假设。
2. 基于假设设计实验。
3. 运行实验，观察结果。
4. 如果结果符合假设，进一步加深；如果不符合，修改假设并尝试新的方向。

这套流程和写代码是两件不同的事。当我们把 Agent 的定位从“代码编辑器”升级为“实验助手”之后，它的价值会明显不同。

9. 总结与后续学习方向

写到这里，可以把 ArchAgent v2 这个案例研究的关键判断再强调一遍：它真正证明的，不是“AI 能写预取器”，而是“AI 能完成有反馈的实验闭环”。在数据预取锦标赛这样指标清晰、迭代路径明确的场景中，这种闭环能力可以转化为实际的研究效率提升。

如果你想继续深入，我建议从两条线并行推进：

一条线是体系结构方向。去深入了解 ChampSim 的代码结构，理解一个 baseline 预取器（比如 next-line 或 SPP）在每个 cache miss 时做了什么决策，手动修改几次参数，体会预取器设计的复杂度。这条线能帮你建立领域感知，没有这个感知，后面用 Agent 也判断不了结果好坏。

另一条线是 Agent 工程方向。去研究当前 LangChain、LlamaIndex 这类框架中 ReAct、Plan-and-Execute 等模式的实现细节，然后尝试把一个简单的“编译—运行—解析—决策—修改代码”闭环用代码搭出来。这个闭环并不需要大模型也能写，但加了 LLM 之后，整个系统的灵活性和上限会大大提升。

如果你正好在研究数据预取或者更广泛的硬件设计自动化，建议把 ArchAgent 的案例分析当作思路参考，但一定要自己动手把最小闭环跑通。跑通之后，你会发现真正有价值的，不是工具本身，而是“把实验过程自动化”这套方法论在硬件领域的迁移能力。ArchAgent 只是一个引子，背后的趋势是：AI Agent 正在从软件研发走向体系结构研究，这场变化的深度，可能超过很多人的预期。