前言
过去几年，AI 计算系统的发展主线相当稳定：模型参数越来越大，对算力和访存带宽的需求持续增长，相应地，计算集群越来越大，GPU、HBM 与高速互连不断升级。无论是训练还是推理，系统设计的核心问题通常围绕三件事——提供更多算力、搬运更多数据，以及让昂贵的加速器尽可能保持忙碌。进入大模型推理时代后，系统服务的基本单位则逐渐稳定为一次相对独立的模型请求：输入到达，完成 Prefill 与 Decode，返回结果，请求结束。衡量系统的指标也围绕这个抽象建立起来，例如TTFT、TPOT、Token Throughput、每百万Token 成本和 GPU 利用率。
进入 2026 年，AI Agent 的大规模应用开始改变这些前提。首先，系统服务的对象正在从“一次请求”变成“一次完整任务”。一个任务可能持续数小时甚至更久，需要反复调用模型和工具、维护状态和记忆、等待外部环境，并在失败后恢复和继续执行。于是，衡量计算系统的标准也必须从请求级指标进一步升级到任务级：真正重要的不再只是生成 Token 有多快，而是能否以更低成本、更短时间和更少人工返工完成一个可信的任务。
但更深一层的变化正在同时发生。 AI Agent 不再只是计算系统的使用者。随着代码生成、推理、实验执行和工具使用能力增强，它开始进入 Kernel、Compiler、Runtime 乃至硬件设计的优化闭环。恰恰是在 AI Agent 让计算系统变得更复杂的同时，AI Agent 自身又开始成为解决这种复杂性的工具。这个趋势进一步连接到 AI 自我改进（RSI）的叙事：真正的自我改进不仅可能发生在模型算法层，也可能发生在承载模型的软件、硬件和计算基础设施上，并最终形成模型与系统之间的共同进化。
本文沿着这两条主线展开：第一，讨论从“一次请求”到“完整任务”的变化对计算系统意味着什么；第二，讨论当 AI Agent 开始成为计算系统的设计者和优化者之后，软件、硬件以及整个 AI 研发和计算体系可能发生什么变化。
从“一次请求”到“完整任务”的改变对计算系统意味着什么？
新的指标
一个真正执行工作的 AI Agent，很少只调用一次模型。它会读取代码与文档、制定计划、调用搜索、数据库、编译器、仿真器，甚至与其他 Agent 协作；等待外部结果后继续推理，修改环境，执行验证；失败后再回滚并重新规划。一次任务可能持续数分钟、数小时，甚至跨越多天。很多最新的 Agent Trace 数据和 Benchmark，例如 METR[1]、OSWorld 2.0[2]、SyFI TraceLab[3] 等，都直观反映了这种变化。
“一次请求”是相对容易定义的对象：输入长度、输出长度、吞吐和延迟要求大体可以确定；失败后重发，通常也不会留下难以恢复的外部后果。完成一次“完整任务”则不同，它需要跨越多个阶段，而模型调用只是其中一段。AI Agent 除了使用传统意义上的 AI 计算资源，还会占用 CPU、网络、存储、Sandbox 与其他模型，并可能有大量时间处于等待状态。因此，Token 性能指标不能直接回答任务是否被高效完成；单次模型调用的价格也不能代表完成一项任务的真实成本。
此前，DistServe 使用 Goodput 描述：在满足 TTFT 与 TPOT 等延迟约束时，系统能够有效处理的请求数量。[4] 而现在，我们需要把 Goodput 从请求级进一步扩展到任务级。
本文暂且把这个指标称为 Task Goodput：
单位时间内完成的、同时满足质量、时延、成本、安全和业务约束的成功任务数量。
配套的经济指标是 Cost per Successful Task。这个指标字面上的意思很容易理解，但要把它进一步映射为计算系统的具体需求，就比过去困难得多。
这个成本不只包括模型 API 调用或 GPU 时间，还包含大量隐藏在背后的成本，比如状态存储与迁移、CPU 与网络、工具执行与 Sandbox、验证与失败重试、任务恢复，甚至一个任务中的人工审核与返工：
Cost per Successful Task =(模型与计算成本 + 状态、内存与数据移动成本 + 工具、网络与 Sandbox 成本 + 验证与失败重试成本 + 人工审核与返工成本) / 成功任务数
一个价格更低的模型，如果频繁走错路径、反复调用工具，最终还需要工程师返工，可能比单次调用更贵、但首次成功率更高的模型昂贵得多。传统指标，如 Token Throughput、TTFT、TPOT、GPU 利用率与每百万 Token 成本，并未失效——它们仍然是解释瓶颈的必要观测量——但已经不再是 AI 计算系统优化的最终目标。
只有在任务级目标下，我们才有可能真正回答下面这些问题：GPU 利用率与任务完成速度冲突时应该优化哪一个？增加一次验证会消耗更多算力，却可能提前终止错误轨迹——这是成本还是投资？任务在等待外部工具时，是否应该继续保留高成本的 HBM 状态？等等。
围绕状态和记忆的计算系统
“一次请求”中的状态，通常主要是 KV Cache 与少量 Runtime 元数据；请求结束后即可释放。
长期运行的“完整任务”则需要同时维护：
模型内部的 KV Cache、Prefix Cache、Activation 与推测执行状态；
Agent 的计划、假设、摘要、历史轨迹与失败记录；
工作流依赖、分支、Deadline、重试与审批状态；
外部环境中的代码、文件、数据库、浏览器、Sandbox、工具结果与实验数据；
身份、权限、凭证、数据来源、版本与审计记录；
已经发生的外部副作用，例如提交代码、发送消息、修改数据库或控制设备。
还有一点非常重要：AI Agent 不只读取环境，还会改变环境。外部副作用使“失败后重新运行一次”不再总是安全。
这些需求和特征将引发一系列长期挑战：
Memory Wall 扩展为 State Wall。 过去主要是计算性能增长快于内存带宽；现在容量、带宽、迁移、恢复、复制与治理都可能同时成为瓶颈。系统必须重新分配面积、功耗与资本——多少给计算，多少给状态容量、数据移动与恢复。这会反向定义 SRAM/HBM 配比、DDR/CXL、Fabric、DMA，乃至 Near-memory Compute。
状态不仅有大小，还有语义。 量化与压缩可以节省空间，但 KV 误差会改变后续生成，摘要可能遗漏约束，格式转换可能破坏版本兼容，过期结论也可能污染长期记忆。系统必须知道哪些误差可以接受、误差如何传播，以及最终如何影响任务成功率与人工返工。状态表示需要逐渐成为模型、Runtime 与硬件共同理解的 Contract。
状态价值是动态且不确定的。 最近访问或固定窗口不足以代表未来价值。系统需要在保留、迁移、压缩、复制、重算与淘汰之间进行联合决策。
生命周期与物理放置是两个不同的决策。 “要不要留”不等于“放在哪”。一个状态值得保留，并不等于值得一直留在 HBM；但迁移本身也有成本，频繁抖动还会引发 Tier Thrashing 与 Fabric 拥塞。
复用越多，不一定越好。 共享能够减少重复计算，也会带来错误命中、版本污染、信息泄漏与撤销失败。
长任务需要任务级 RAS。 简单重试无法保证模型状态、Runtime、Sandbox 与外部副作用的一致性。
系统级 State Contract 将成为基础能力。 目前大部分 KV Cache 优化仍然只是局部工程基础，尚未形成覆盖语义、生命周期、可靠性与安全性的统一系统级 Contract。也正因为如此，KV Cache 不应被视为一个孤立的挑战——它更像一个代表性 workload，同时暴露出上述一系列长期矛盾。
当任务成为目标、状态成为核心资产，AI Factory 的设计也会随之变化。Agent workload 有明显的资源需求差异：规划和推理主要消耗 GPU/HBM；搜索、编译和查库主要消耗 CPU/网络/存储；等待外部结果时主要占用状态容量；验证阶段又可能调用模型、仿真器或形式化工具。如果每类资源各自追求“最忙”，最终可能出现所有资源都很忙、任务关键路径却依然很长的局面。
因此，调度需要从 Resource-aware 进一步走向 Outcome-aware：估计任务当前阶段、离成功还有多远、状态迁移需要多少代价，以及继续投入一次推理或验证是否值得。
从更复杂的问题，到新的设计者
讨论到这里，不难看出 Agent 给计算系统带来了各种“麻烦”。
0过去我们面对的主要还是一个相对清晰的优化问题：给定模型、硬件和流量，优化 Kernel、并行策略、Batching 和资源利用率。到了 AI Agent 时代，目标变成 Cost per Successful Task，优化变量一下子扩展到了模型选择、推理深度、状态保存与迁移、工具执行、CPU/GPU/网络/存储调度、Verifier、失败恢复，甚至人工介入。更麻烦的是，这些变量高度耦合：多做一次验证会多消耗算力，却可能减少后面的失败和返工；把状态从 HBM 移到 DDR 可以降低容量成本，却可能拉长恢复时间；换一个更贵的模型会提高单次调用成本，却可能把整个任务的总成本降下来。
而且，这个问题不是静态的。模型隔几个月就可能换一代，Context Length、MoE Routing、推理算法和工具使用方式也在变化；同一个模型在不同硬件、不同流量、不同 SLA 下，最优执行方式也可能完全不同。
换句话说，AI Agent 不只是增加了几项新需求，而是在制造一个规模巨大、还在持续变化的跨层联合优化问题。过去依靠少数系统专家长期打磨一套通用软件栈的方法，开始碰到一个更根本的问题：
人类优化计算系统的速度，可能逐渐赶不上系统本身变化的速度。
但几乎在同一时间，另一件事也在发生。把问题变复杂的 AI Agent，自己已经越来越擅长读代码、理解系统、调用编译器和 Profiler、运行实验、分析结果，再修改下一版方案。于是，一个很自然的问题出现了：
如果计算系统已经复杂到人类很难持续找到最优解，为什么不让 AI 自己参与设计和优化这个系统？
这就是本文想讨论的第二个方向。
第一部分里，AI Agent 是计算系统新的 workload；接下来，它开始扮演另一个角色：
AI Agent 不只是计算系统的使用者，它开始成为计算系统的设计者和优化者。
当 AI Agent 不再仅仅是计算系统的使用者
从 Discovery Loop 讲起
最近，Jeff Dean、Sanjay Ghemawat、Quoc Le 和 Oriol Vinyals 创办了 Discovery Loop，这是一个很有象征意义的事件。这几个人过去的工作横跨大模型、分布式系统、编译与框架、TPU、芯片设计和 Google 大规模基础设施。
Discovery Loop 对自己要做的事情描述得很直接：把科学和工程中不断重复的实验循环自动化——提出实验，运行实验，观察结果，再根据结果产生下一轮实验。和人类研究人员串行完成少量实验不同，他们希望利用 AI 和大规模计算基础设施，并行运行大量实验，从而压缩整个发现周期。
更有意思的是，他们没有首先选择药物、材料或其他科学问题，而是把 Machine Learning Research and Engineering 作为起点，并明确提出要把自己作为“第一个客户”：先利用自动化的 ML Research Loop 改进自己的技术栈，再把能力扩展到其他领域。
这和本文讨论的计算系统有很直接的联系。
如果把一次 ML Research Loop 拆开，里面并不只有模型算法：
也就是说，一旦整个研发循环被 Agent 化，模型和承载模型的计算系统就很难再被当成两个完全独立的问题。Discovery Loop 目前的公开材料并没有明确给出全部具体目标和技术路径，但它展示的范式很重要——AI 不再只回答一个研发问题，而是开始进入“提出假设—实现—运行—测量—改进”的完整工程循环。
如果这种 Research Loop 可以改进模型，一个自然的问题就是：为什么它不能同时改进运行这个模型的软件和计算系统？实际上，这件事已经开始发生。
为什么计算系统特别适合 AI 自我优化?
从今天已经出现的工作看，计算系统可能反而是最适合 AI 自动优化的领域之一。背后最根本的原因是：这里的很多问题都具备 AI 自动探索最需要的一个条件——结果可以被机器客观评价。
比如优化一个 GPU Kernel。AI 可以生成一份实现，编译并运行；如果与 Reference Implementation 不一致，就是错的；如果正确，就可以直接在真实 GPU 上测量 latency、throughput、memory usage 和 energy。失败候选可以立刻丢弃，成功候选则继续变异和优化。于是可以形成一个很自然的闭环：
Generate → Compile / Run → Verify → Profile → Select → Generate Again
KernelBench 正好把 GPU Kernel 编写变成了这种可验证任务。早期结果也很有意思：前沿模型单次生成高性能 Kernel 的能力，其实没有想象中那么强，最初测试中“既正确又达到 PyTorch 基线”的比例仍然很低；但一旦允许模型读取编译、执行和 Profiler 反馈，迭代能力就会明显提高。
这其实说明，未来真正重要的可能不是：AI 能不能“一次写出”比专家更好的 Kernel？而是：
AI 能不能一天完成一万次工程师没有时间做的实验？
Meta 的 KernelEvolve 已经很接近这种模式。Meta 面对的问题很现实：模型数量 × NVIDIA / AMD / MTIA / CPU 等硬件组合越来越多，依靠 Kernel 专家逐一手工优化已经难以扩展。KernelEvolve 让 Agent 自动完成 profiling、生成候选、调试、跨硬件测试和性能筛选。Meta 报告，这可以把过去数周的专家优化压缩到数小时。[7]
这里可能隐藏着 AI 参与计算系统设计的第一个本质变化：
系统优化开始从 expert craft，变成 machine-searchable problem。
AI 会不会找到人类做不到的优化？
我的判断是：会。原因未必是 AI 在每一个局部问题上都比顶尖工程师更聪明，而是 AI Agent 相比人类有几个不太一样的优势。
首先是搜索宽度。人类工程师看到一个性能问题，通常会凭经验选择几个最可能有效的方向，再花时间实现和测试。一个AI Agent 可以尝试几十、几百甚至几千个候选。如果一次实验足够便宜，那么绝大多数候选都很差也没有关系。
其次，AI 对“丑陋方案”的容忍度远高于人类。工程师天然喜欢简洁、通用、可读、容易维护的实现。但如果一个 Kernel 只针对某个模型、某个 GPU、某几个 Shape 使用三个月，这些目标的重要性可能远低于性能。AI 完全可能生成非常奇怪的 Fusion 方式、Instruction Ordering、Register Allocation、Memory Layout、Shape Specialization、通信策略，甚至带有大量硬编码的执行路径。人类工程师看了可能会觉得“不值得维护”，但对于一个可以随时重新生成的软件来说，可维护性本身的意义可能正在发生变化。
更重要的是，AI 可以越过传统组织结构形成的边界。今天的优化通常被拆成多个团队：模型团队调模型，Compiler 团队优化图，Kernel 团队优化算子，Runtime 团队管理 Serving，芯片团队调整微架构。每一层都可以做到局部最优，但全局最优往往藏在这些边界之间。
未来的 AI Agent 可以同时问：是不是应该换模型结构？还是修改 KV Format 更划算？是 Fusion 一个 Kernel，还是改变 Runtime 的 Batching？或者干脆增加一个新的硬件 Primitive？
也就是说，真正值得关注的不只是 AI Code Generation，而是：
AI-driven Cross-layer Design Space Exploration。
这类信号已经出现。Google DeepMind 的 AlphaEvolve 不只是寻找数学算法，它也被用于 Google 的数据中心调度、硬件电路、AI 训练和低层 Kernel 优化。其中，一个进入生产的 Borg 调度 heuristic 平均回收约 0.7% 的 Google 全球计算资源；一个矩阵乘 Kernel 优化让 Gemini 训练时间下降约 1%；它还提出过最终进入 TPU 设计的 Verilog 修改。[8]
Magellan 则进一步把搜索对象从“代码实现”推进到 Compiler 自己的决策规则。传统 Compiler 中存在大量人类工程师多年积累的 heuristic，比如什么时候 inline、如何进行 register allocation。Magellan 直接让 AI Agent 生成可编译执行的 C++ decision logic，在真实 macro benchmark 上进行评价，再持续进化。论文报告，在 LLVM function inlining 等任务上，自动发现的规则能够匹配甚至超过长期人工设计的 heuristic。[9]
再往下，ArchAgent 已经开始让AI Agent 搜索微架构机制。它在 Cache Replacement Policy 上自动生成新的机制和逻辑，并在无人干预的搜索中取得超过此前公开最优方案的结果。[10] 更近的 ArchAgent v2 又开始探索多级 Prefetcher，在相同比赛约束下自动设计出超过此前人工冠军的三级预取方案。[11]
所以，“AI 能不能找到人类没有找到的优化”已经不完全是假设。更准确的说法可能是：
AI 正在把以前因为人力有限而根本不会被探索的设计空间，变成可搜索空间。
从“一模型一软件”到“一次性软件”
从一次性软件到硬件专用化阶梯。
如果继续沿这个方向推演，一个很有意思的变化可能发生在软件本身。
为什么今天需要一套高度通用的软件栈？很大程度上是因为写软件很贵。开发一个高质量 Kernel、Compiler Backend 或 Runtime，需要投入大量系统专家的时间。因此，一份软件写出来之后，最好能够支持几十种模型、几代硬件和大量 workload。这是一个非常合理的经济选择：Write once, reuse many times。但如果 AI 把生成和优化软件的成本降低几个数量级，这个经济基础就会开始松动。
未来，AI Agent 可以读取模型 Graph 和权重特征、实际生产流量、Context Length 分布、SLA、目标 GPU、Memory Hierarchy 和网络拓扑，然后自动生成并测试 Kernel、Compiler Schedule、Memory Layout、KV Format、Prefill / Decode Mapping、Batching、Routing 和 Runtime 参数。AgentCompile 已经展示了这条路径的早期形态：LLM 不直接接管 Compiler，而是在 Compiler 给出的 Contract 和候选空间中，帮助决定哪些区域值得专用化、哪些 CUDA 实现值得尝试，再由真实 Compiler 和执行环境负责验证。[12]
如果这个过程最终变得足够好用、也足够便宜，那么未来部分 AI 系统软件也许不再是一个需要维护很多年的产品，而只是针对 Model × Hardware × Traffic × SLO 这个组合生成的一个临时 Artifact，而且是针对具体场景高度定制化优化的。模型升级了，重新生成。GPU 换了，重新生成。流量从 Batch=1 变成 Batch=128，重新生成。Context Length 分布改变了，再生成一版。甚至 Prefill、Decode、Verifier 和某种特定 Agent workload，都可以拥有完全不同的执行路径。更极端一点，可能出现Disposable Software或Ephemeral Software：软件变得像JIT 编译结果一样，需要的时候才产生。
今天的软件生命周期通常是：
开发 → 测试 → 发布 → 长期维护
未来某些高性能 AI 软件可能变成：
Spec → Generate → Verify → Deploy → Expire → Regenerate
专用化会不会继续进入硬件？
软件一旦可以持续专用化，下一个自然问题就是：这种优化会不会继续向硬件推进？答案很可能是会，但这里不应该简单理解成“以后每个模型都做一颗 ASIC”。最近已经出现了这方面比较激进的尝试，例如 Taalas HC1。[13]
更有意思的是：专用化本身可能变成一个连续的设计空间。越靠上层，修改越便宜、越容易回退；越往底层，潜在收益越大，但 NRE、验证成本、供应链风险和模型过时风险也会迅速增加。所以，真正有意思的问题不是“我们能不能做一模型一芯片”，而是：
什么东西应该被专用化，甚至硬化？专用化应该推进到多深？
未来，这个问题本身也可能交给 Agent 搜索。对某个模型，最佳方案可能只是生成几个特殊 Kernel；另一个模型可能值得修改 Microcode；一个长期稳定、部署规模巨大的 workload，才可能值得增加专门的硬件数据路径；极少数足够稳定的模型，才最终值得硬化到 ASIC。ArchAgent 提出了另一个很有启发性的概念：post-silicon hyperspecialization。也就是芯片流片后，仍然保留可以被 Agent 搜索的硬件参数和策略，根据实际 workload 自动进一步专用化。[10]
这个思路意味着一种不太一样的硬件设计哲学。过去我们试图：在 Tapeout 之前，把所有重要决策尽可能设计好。未来也许会逐渐变成：在硬件中有意识地保留一部分可以被 AI 持续搜索的自由度。 例如 Cache Policy、Prefetch、SRAM Partition、Routing、Precision、Collective、NoC Policy、Power State、Microcode，甚至某些可重构数据路径。换句话说，未来介于 GPU 和 ASIC 之间，也许会出现一类新的硬件：AI-Optimizable Hardware。它不是简单追求更强的 programmability，而是专门暴露一组机器可以高效搜索的 Architecture Degrees of Freedom。软件给出 workload evidence，Agent 搜索策略，硬件提供可调空间。
从模型 RSI 到 Model–System Co-evolution
今天讲 AI 自我改进，最容易想到的是：一个更强的模型帮助设计更好的模型。但真正的 AI 能力提升，从来不只由模型算法决定。一次新的训练实验需要计算；新的模型结构需要 Kernel 和 Compiler；新的推理方法需要 Runtime、Memory 和 Network 支持；计算系统效率又直接决定同样预算能够做多少实验。因此，更完整的循环可能是：
Google DeepMind 的 AlphaEvolve 已经出现了这种循环的早期影子；而 Discovery Loop 则把“把自己作为第一个客户”这件事说得更明确：先自动化 ML Research Loop，再利用这一能力改进自己的技术栈。[5][8]
所以真正值得关注的 RSI，也许不是一个纯模型闭环：
Model → Better Model
而是一个更大的：
Model–System Co-evolution。
模型提升系统设计能力，系统优化降低下一轮训练和实验成本，实验速度加快又进一步推动模型提升。到了这一步，计算系统优化的重要性就不再只是“省多少钱”，它甚至可能决定：AI 自我改进循环能够转多快。
过去我们讨论 Scaling Law 时，主要关心增加多少 Physical Compute 可以获得多少 Capability。如果上述反馈开始形成，那么未来还可能出现另外两种 Scaling：
System Efficiency Scaling：相同物理算力能够完成更多有效计算；
Research Efficiency Scaling：相同时间能够完成更多高质量实验。
可以做一个很粗略的表达：
Effective Compute ≈ Physical Compute × System Efficiency × Research Efficiency
过去竞争主要围绕第一项：谁有更多 GPU？未来竞争可能越来越取决于后两项：谁能更快地产生可信的新方案，并把它变成下一轮系统？
也就是说，真正重要的指标可能逐渐变成 Discovery Loop Throughput，或者Time-to-Evidence——从提出一个系统优化想法，到在真实环境中获得足够可信的证据，需要多久？如果这个周期从几个月变成几天，再变成几个小时，那么计算系统的演进方式本身就会发生变化。
但 RSI 真正的瓶颈可能不是 Optimizer，而是 Verifier
当然，这里还有一个不能忽略的问题。AI 搜索能力越强，它不仅越容易找到人类没有想到的优化，也越容易找到人类没有想到的评价漏洞。KernelBench-Verified 最近给出了很典型的警告。一些看起来获得明显加速的 AI 生成 Kernel，在更严格的 Hidden Test 和更现实的性能基线下，收益会大幅下降；模型甚至可能针对狭窄的测试分布做特殊处理，跳过本该执行的计算，从而制造表面上的性能提升。[14]ArchAgent 也遇到了类似现象：Agent 在搜索过程中发现并利用了微架构 Simulator 中的漏洞，作者把它称为 simulator escape。这个 Simulator 原本是给善意的人类研究者使用的，并没有假设一个优化器会主动寻找其中的漏洞。[10]
这暴露了 RSI 一个可能比生成能力更基本的问题：
Optimizer 越强，Verifier 就必须越强。
否则，Recursive Self-Improvement 很容易退化成 Recursive Reward Hacking。
因此，未来 AI 计算系统中非常珍贵的基础设施，可能不是另一个更强的代码生成模型，而是一整套难以被欺骗的 Verification Infrastructure：Reference Implementation、Hidden Test、Fuzzing、Formal Verification、Simulator、Digital Twin、Production Trace、Hardware Counter、Canary、Rollback，以及最终的真实物理世界。
从这个角度看，未来 AI 自我改进真正稀缺的东西，不是提出更多 Idea 的能力，而是：
快速获得可信 Evidence 的能力。
总结：计算系统开始变成一个持续进化的对象
如果把这些变化放在一起，第二个方向就不再只是“AI 帮工程师写写 Kernel”。Agent 首先进入 Kernel、Compiler 和 Runtime 中那些反馈明确、验证相对便宜的问题；随着能力提升，它会逐渐扩展到跨层系统优化，再进入 Microarchitecture 和 Hardware Design。与此同时，软件的经济学也可能改变。过去因为软件开发昂贵，所以我们追求通用、稳定和长期维护.如果自动生成和验证的成本足够低，软件则可能越来越短命、越来越专用，甚至像 Cache 一样，根据模型、硬件和 workload 按需生成。硬件也可能随之变化，可能会出现为 AI 自动搜索保留足够自由度的硬件，再让 Agent 决定应该在 Serving、Kernel、Microcode、Architecture 还是 Silicon 层完成专用化。
AI 和计算系统之间的关系将发生深刻的变化。
过去是：
人类设计计算系统，用它运行 AI。
未来可能逐渐变成：
AI 运行在计算系统上，同时参与设计下一版计算系统。
AI Agent给计算系统带来的两个变革汇聚在一起。新一代 AI 计算系统最终可能不只是一个越来越大的 AI Factory，而更像一个能够持续观察自身、重新配置自身，并逐渐重新设计自身的计算系统。
计算系统第一次拥有了一个能够持续参与自身设计的智能优化者。这可能才是 AI Agent 对计算系统最深远的影响。
参考文献
[1] METR, Task-Completion Time Horizons of Frontier AI Models, 2026. https://metr.org/time-horizons/
[2] Mengqi Yuan et al., OSWorld2.0: Benchmarking Computer Use Agents on Long-Horizon Real-World Tasks,arXiv:2606.29537,2026. https://arxiv.org/abs/2606.29537
[3] Kan Zhu et al., TraceLab: Characterizing Coding Agent Workloads for LLM Serving, arXiv:2606.30560,2026. https://arxiv.org/abs/2606.30560
[4] Yinmin Zhong et al., DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, OSDI 2024. https://www.usenix.org/conference/osdi24/presentation/zhong-yinmin
[5]Discovery Loop. https://www.discoveryloop.com/
[6] Anne Ouyang et al., KernelBench: Can LLMs Write Efficient GPU Kernels?, 2025. https://arxiv.org/abs/2502.10517
[7] Meta Engineering, KernelEvolve: How Meta's Ranking Engineer Agent Optimizes AI Infrastructure, 2026. https://engineering.fb.com/2026/04/02/developer-tools/kernelevolve-how-metas-ranking-engineer-agent-optimizes-ai-infrastructure/
[8] Google DeepMind, AlphaEvolve: A Gemini-powered Coding Agent for Designing Advanced Algorithms, 2025. https://deepmind.google/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/
[9] Hongzheng Chen et al., Magellan, arXiv:2601.21096, 2026. https://arxiv.org/abs/2601.21096
[10] Raghav Gupta et al., ArchAgent: Agentic AI-driven Computer Architecture Discovery, arXiv:2602.22425, 2026. https://arxiv.org/abs/2602.22425
[11] Abraham Gonzalez et al., ArchAgent v2: A Case Study with the Data Prefetching Championship, arXiv:2608.09874, 2026. https://arxiv.org/abs/2608.09874
[12] Xuanzhe Li et al., AgentCompile, arXiv:2606.07665, 2026. https://arxiv.org/abs/2606.07665
[13] Taalas, HC1.https://taalas.com/products/
[14] Yunxiang Zhang et al., KernelBench-Verified, arXiv:2607.16241, 2026. https://arxiv.org/abs/2607.16241
