Claude Code（Anthropic的代码智能体）被IBM拉去干了一件离谱的事：给芯片做"性能按摩"。没喂任何硬件知识，纯靠堆量——从1个agent加到10个，平均加速8.27倍。最难的那个benchmark，直接干到20倍。
这事相当于让一群外行装修队，没看过图纸，纯靠互相卷，把豪宅装出了设计师水准。
论文3月刚发，团队来自IBM Research。核心就一个问题：通用代码agent，不经过硬件专项训练，能在芯片设计优化上走多远？
答案比预期野得多。
两阶段流水线：先拆后卷
IBM搞了个"agent工厂"，分两阶段运作。
第一阶段像切蛋糕。把完整设计拆成子内核，每个子内核独立优化——调调pragma（编译器指令），改改代码结构。然后用整数线性规划（Integer Linear Program, ILP）拼装全局方案，在面积限制里挑 promising 的配置。
第二阶段像开黑。从ILP筛出的 top 方案里，启动N个专家agent并行探索。它们干的事更脏：跨函数优化、pragma重组、循环融合、内存重构——这些全局操作，第一阶段根本碰不到。
关键洞察在这里：最好的设计往往不出自ILP排名最高的候选。子内核搜索漏掉的全局优化空间，被第二阶段的agent群挖出来了。
这有点像你让10个人分别优化厨房、客厅、卧室，再让另一批人整体调整动线——结果发现，单独看每个房间都90分，但打通一面墙能让整体体验翻倍。
Scaling Law 硬了：10个agent vs 1个
测试在12个内核上跑，数据集来自HLS-Eval和Rodinia-HLS。工具链是AMD Vitis HLS，agent用Claude Code（Opus 4.5/4.6）。
数字很具体：
• 平均加速：8.27X（1 agent → 10 agents）
• streamcluster（最难benchmark之一）：>20X
• kmeans：≈10X
更难的任务，agent scaling的收益更明显。这符合直觉：搜索空间爆炸时，单点探索容易困在局部最优，群体并行才能摸到全局的边。
但论文埋了个细节：agent们没有硬件领域训练。它们复现的优化模式，是硬件工程师几十年积累的行业知识——纯靠代码能力和试错卷出来的。
这事的冲击力在于，它把"领域专家经验"的壁垒，部分转化成了"计算规模"的问题。
没有训练，只有搜索
团队反复强调这个设定。通用coding agent，零硬件先验，靠两阶段流水线+并行探索，追上了专门调优的水平。
背后有个更硬的趋势：当基础模型的推理能力够强，特定领域的优化可能不需要重新训练，只需要设计好的搜索空间和协调机制。
IBM管这叫"agent scaling as a practical and effective axis"。翻译成人话：堆agent数量，是一条可行的技术路线。
这和去年AI圈热议的"test-time compute"（测试时计算）对上了——推理阶段砸更多算力，可能比训练阶段砸更多数据更划算。
芯片设计是个极端场景：评估一次设计的延迟/面积/功耗，动辄分钟级甚至小时级。传统方法靠人类专家+启发式算法，在巨大设计空间里摸奖。现在agent能自动探索、自动验证、自动迭代，把"专家时间"从循环里摘出去。
谁该紧张
EDA（电子设计自动化）工具的厂商，可能得重新算账。Synopsys、Cadence的优化引擎，积累了几十年领域知识。但如果通用agent+规模化的搜索能复现八成效果，商业模式的压力是真实的。
更直接的信号来自AMD。论文用的Vitis HLS是AMD的工具链，IBM选它做基准，某种程度上是帮对手验证生态。但这也说明：HLS（高层次综合）工具本身的开放性，让第三方agent介入成为可能。
对芯片设计团队来说，这意味着什么？
以前招一个懂HLS的工程师，成本是年薪+培养周期。现在可能是：租10个Claude Code实例，跑一晚上，筛出3个候选方案，工程师做最终把关。人力结构会变。
当然，论文也有边界。12个内核的benchmark，覆盖的是计算密集型场景（kmeans、streamcluster这些经典算法）。控制逻辑复杂的设计、时序约束极紧的模块，agent表现如何？论文没碰。
以及，8.27X是性能加速，不是设计周期加速。agent探索本身要烧算力，ILP求解、多agent并行、HLS综合——这些成本没折算进"加速比"里。实际投产的经济账，还得细算。
但方向是明确的。IBM用这篇论文投了块石头：通用AI agent的边界，可能比想象中更宽。芯片设计这种"硬"领域都能啃，其他领域呢？
论文最后一句没说的潜台词：如果10个agent能干到这程度，100个呢？
热门跟贴