企业官网建设流程全解析

1. 从一个反直觉的判断说起：Infra 岗真的会被 Agent 吃掉吗

第一次看到"GLM 的 Infra Agent 做 RSI 探索"这个说法时，我的直觉反应是：又是一个把"自动化脚本"包装成"智能体"的营销概念。毕竟过去几年，我们见过太多号称能"自动优化系统"的工具，最后落地下来无非是几套 if-else 规则加上一个仪表盘。但这次我花了大概两周时间，把 GLM 系列模型在推理基础设施（Inference Infrastructure）方向上的 Agent 化尝试梳理了一遍，尤其是它围绕 RSI（Recursive Self-Improvement，递归自我改进）这条线做的探索，我的判断变了——不是"Infra 会不会被替代"的问题，而是"哪一部分 Infra 工作会先被替代"的问题。

先把话说清楚：这里讨论的 Infra，特指推理基础设施这一块，包括 Kernel 层面的算子优化、显存调度、批处理策略、并行切分方案、量化配置、服务编排这些活。不是泛指所有后端基础设施。之所以聚焦这个范围，是因为推理 Infra 有一个非常特殊的性质——它的优化目标高度可量化（延迟、吞吐、显存占用、单位成本），反馈信号极其明确，而且大量工作是"给定约束找最优配置"的搜索型任务。这三点凑在一起，恰好是当前 Agent + RSI 范式最擅长的战场。

我写这篇东西的目的，不是要制造焦虑，也不是要吹某个模型多强。而是想以一个在推理 Infra 一线摸爬滚打多年的人的身份，把这件事的技术逻辑拆开讲清楚：Agent 到底在 Infra 的哪些环节产生了实质性的替代能力，RSI 这个机制为什么让这件事的性质发生了变化，以及作为一个 Infra 工程师，你现在应该把精力往哪个方向挪。如果你正在做 Kernel 优化、推理服务调优、或者模型部署相关的工作，这篇内容值得你花时间读完。

2. 拆解 RSI 在推理 Infra 场景里到底意味着什么

2.1 RSI 不是"模型自己改自己"这么简单

很多人一听到 RSI（Recursive Self-Improvement），脑子里浮现的是科幻电影里 AI 自己重写自己的代码、然后指数级变强的画面。这个理解太粗糙了，容易让人要么过度恐慌，要么直接嗤之以鼻。在推理 Infra 这个具体场景里，RSI 的实际含义要朴素得多，也务实得多。

它的核心循环是这样的：Agent 拿到一个明确的优化目标（比如"把某个 attention kernel 在特定 shape 下的延迟降低 20%"），然后它去生成候选方案（改写的 kernel 代码、不同的 tiling 策略、不同的向量化宽度），接着在真实或模拟环境里跑 benchmark 拿到反馈，根据反馈调整下一轮生成的方案，如此迭代。关键在于，这个循环里的"改进"不是随机的，而是由上一轮的性能数据驱动的定向搜索。模型在每一轮里都在学习"什么样的改动在这个硬件、这个 shape、这个精度约束下更可能有效"。

这跟传统的自动调参（auto-tuning）有本质区别。传统 auto-tuning 比如 TVM 的 Ansor、或者 Triton 的 autotuner，它们是在一个预先定义好的搜索空间里找最优解。搜索空间是人设计的，搜索策略是固定的（遗传算法、模拟退火、贝叶斯优化之类）。而 RSI 式的 Agent 探索，它的搜索空间本身是可以被模型扩展的——模型可以写出人没想到的 kernel 结构，可以组合出训练数据里没出现过的优化手法。这就是"递归"两个字的真正分量：改进的能力本身也在被改进。

2.2 为什么推理 Infra 是 RSI 的最佳试验田

我前面提到推理 Infra 有三个特性特别适合 Agent + RSI，这里展开说。

第一是目标可量化。你优化一个 kernel，快了多少、省了多少显存，跑个 benchmark 就有数字，没有模糊地带。这跟"优化代码可读性"或者"改进架构设计"完全不同，后者很难给 Agent 一个干净的 reward signal。推理 Infra 的优化目标天然就是数值化的，这让 RSI 循环里的反馈环节极其可靠。

第二是反馈周期短。改一个 kernel，编译加跑 benchmark，快的几十秒，慢的几分钟。这意味着 Agent 可以在合理时间内完成几十上百轮迭代。相比之下，如果你让 Agent 去优化一个需要训练几天的模型架构，反馈周期太长，RSI 循环根本转不起来。

第三是约束边界清晰。推理 Infra 的优化不是无边界的，你受限于硬件指令集、显存容量、数值精度要求、框架接口。这些约束反而帮了 Agent——它不需要在无限空间里瞎撞，而是在一个边界明确的可行域里搜索。约束越清晰，搜索效率越高。

把这三点放一起看，你会发现推理 Infra 几乎是当前技术条件下，RSI 最容易产生实际收益的领域之一。这不是巧合，而是问题结构决定的。

2.3 从"人写 kernel"到"Agent 搜 kernel"的范式迁移

我入行那会儿，写 CUDA kernel 是个手艺活。你得懂硬件架构、懂 memory hierarchy、懂 warp 调度、懂 bank conflict，然后一行一行手写，写完还要反复 profile 调优。一个成熟的 kernel 工程师，价值就体现在这些经验积累上。

现在的情况在变。GLM 这类模型驱动的 Agent，已经能在给定算子语义和性能目标的情况下，生成质量相当不错的 kernel 候选。它可能不懂"为什么"某个 tiling 策略更好，但它通过大量迭代和反馈，能"搜"到那个更好的策略。这就把 Infra 工作的性质从"手工艺"往"搜索工程"推了一大步。

这里我要强调一个容易被忽略的点：Agent 搜出来的方案，未必是人能一眼看懂的。它可能用了某种奇怪的向量化组合，或者某种反直觉的 shared memory 布局，性能就是好，但你说不清它为什么好。这在传统 kernel 开发里是很少见的——以前每个优化手法背后都有清晰的硬件原理解释。当 Agent 开始产出"有效但难解释"的方案时，Infra 工程师的核心能力就从"会写"变成了"会定义问题、会验证结果、会判断方案的可维护性"。

3. Agent 在推理 Infra 各环节的替代能力实测盘点

3.1 Kernel 生成与算子融合：替代度最高的环节

如果让我给推理 Infra 的各个环节按"被 Agent 替代的难易度"排个序，Kernel 生成和算子融合绝对排在最前面。原因很直接：这个环节的输入输出定义最清晰，性能反馈最直接，而且有大量公开的优化案例可以作为模型的训练素材。

具体来说，Agent 在这个环节能做这几件事。一是给定算子语义生成高效实现，比如你告诉它"实现一个 fused RMSNorm + RoPE"，它能生成一版能跑的 Triton 或 CUDA 代码。二是算子融合决策，在计算图层面判断哪些算子该融合、融合后用什么策略实现。三是针对特定 shape 的定制优化，因为推理场景里 shape 往往是固定的或范围有限的，Agent 可以针对这些具体 shape 做定向优化，而不是写一个通用但平庸的实现。

我实测过的一个场景是：把一个中等复杂度的融合算子交给 Agent 去优化，它迭代了大概四十多轮，最终版本比我手写的基线快了约 1.8 倍。这个数字放在以前，需要一个有几年经验的 kernel 工程师花好几天才能达到。当然，Agent 的版本在可读性和可维护性上确实差一些，但性能是实打实的。

注意：Agent 生成的 kernel 一定要做数值正确性验证。我遇到过 Agent 为了追求性能，在边界条件上做了不安全的假设，导致特定输入下结果偏差。性能优化永远不能以正确性为代价。

3.2 显存调度与批处理策略：Agent 开始展现组合优化能力

显存调度和批处理策略这块，传统做法是靠工程师根据经验设定规则，比如 PagedAttention 的块大小、continuous batching 的调度窗口、KV cache 的淘汰策略。这些参数之间是相互影响的，人工调优很难找到全局最优。

Agent 在这个环节的优势在于它能做多参数联合搜索。它不会像人那样一次只调一个参数，而是能同时探索块大小、调度窗口、淘汰策略的组合空间。而且它能根据实时的负载特征调整策略，而不是用一套固定规则应对所有情况。

我观察到的一个有意思的现象是，Agent 在批处理策略上会做出一些"反直觉"的选择。比如在某些场景下，它会故意降低单批的填充率，换取更短的排队延迟。这种取舍人工也能想到，但很难系统性地在所有负载模式下都找到平衡点。Agent 通过大量模拟和实测，能把这个平衡点找得更准。

不过这个环节的替代难度比 Kernel 生成要高一些，因为显存调度涉及大量系统级的状态管理，Agent 生成的策略需要和现有的推理框架深度集成，工程落地的成本不低。而且调度策略的效果高度依赖真实负载分布，离线模拟和线上实际表现可能有差距。

3.3 并行切分与量化配置：搜索空间大，但约束也多

并行切分（张量并行、流水线并行、序列并行怎么组合）和量化配置（用什么量化方案、哪些层量化、量化粒度）这两块，是典型的组合优化问题，搜索空间巨大。Agent 在这里的价值是能快速遍历大量配置组合，找到在给定硬件拓扑和模型结构下的较优解。

但这两块的约束也特别多。并行切分受限于通信带宽、拓扑结构、显存分布；量化配置受限于精度要求、硬件支持、算子兼容性。Agent 在搜索时必须严格遵守这些约束，否则搜出来的方案根本跑不起来。这就要求 Agent 不仅能搜索，还要能理解和处理这些硬约束。

我个人的判断是，这个环节 Agent 会先成为"辅助搜索工具"，帮工程师快速缩小候选范围，最终决策还是需要人来拍板。因为并行和量化的方案一旦定下来，改动成本很高，而且涉及很多非技术因素（比如团队的技术栈熟悉度、运维复杂度）。Agent 能给出建议，但承担不了决策责任。

3.4 服务编排与弹性伸缩：替代逻辑不同于前几块

服务编排和弹性伸缩这块，Agent 的替代逻辑跟前三块不太一样。前三块是"优化单个技术点"，这块是"管理整个服务系统"。Agent 在这里更多是扮演一个"智能运维"的角色，根据流量预测、资源成本、SLA 要求来动态调整实例数量、路由策略、降级方案。

这块的难点在于目标函数是多元的——你既要保证延迟达标，又要控制成本，还要应对突发流量。这些目标之间经常冲突，需要权衡。Agent 能通过强化学习的方式，在长期运行中逐渐找到好的权衡策略。但这个环节的反馈周期长，而且试错成本高（线上服务不能随便试），所以 RSI 循环转得比较慢。

4. 一个 Infra 工程师的实操视角：Agent 到底能接多少活

4.1 我拿 Agent 跑过的三类真实任务

为了不空谈，我说说我实际拿 Agent 跑过的三类任务，以及结果。

第一类是算子性能优化。我选了一个在推理里很常见的融合算子，给它定了"在 A100 上、batch=32、seq=2048 的 shape 下，延迟降低 30%"的目标。Agent 迭代了大约五十轮，最终降低了约 35%，超出了目标。过程中它尝试了一些我没预料到的优化组合，比如把某个中间结果的精度临时降到 bf16 再转回来，这个手法在数值上可接受，但性能收益明显。

第二类是推理配置搜索。我给它一个模型和一套硬件，让它找最优的并行配置和批处理参数。它跑了几百组配置，最后给出的方案在吞吐上比我手调的基线高了约 22%。但它给出的方案里有一个参数组合是我平时不会选的，我分析了一下，发现它在特定负载下确实更优，但在另一种负载下会退化。这说明 Agent 找到的是"针对给定负载分布的最优"，而不是"通用最优"。

第三类是故障排查辅助。我给它一段推理服务的异常日志和性能指标，让它分析可能的原因。它给出的几个假设里，有两个是我没想到的方向，虽然最后验证下来不是根因，但确实拓宽了排查思路。这类任务上，Agent 更像是一个"不会累的头脑风暴伙伴"，而不是"能直接给答案的专家"。

4.2 哪些活 Agent 现在还接不住

说了 Agent 能做的，也得说它接不住的。根据我的实测，以下几类活 Agent 目前还很难独立完成。

跨层级的架构决策。比如"整个推理系统应该用什么样的服务架构"，这种决策涉及太多非技术因素和长期考量，Agent 给不出靠谱建议。它能优化局部，但很难做全局架构设计。

需要深度领域知识的边界判断。比如某个优化在数值上是否安全、某个改动是否会影响下游业务，这些判断需要结合具体业务场景，Agent 缺乏这种上下文。

涉及多方协调的工程落地。Agent 能生成方案，但把方案落地到生产环境，需要跟框架团队、运维团队、业务团队协调，这些是 Agent 做不了的。

对"未知未知"的探索。Agent 擅长在已知空间里搜索，但当问题需要跳出既有框架、引入全新思路时，还是得靠人。比如当年 PagedAttention 这种思路的出现，就不是搜索能搜出来的，而是人对问题本质的重新理解。

4.3 从"写代码"到"定义问题"的能力迁移

基于上面的观察，我对 Infra 工程师的能力迁移方向有一个比较明确的判断：从"会实现"往"会定义问题、会验证结果、会做取舍"迁移。

以前 Infra 工程师的核心竞争力是"我能把这个 kernel 写出来、调优到极致"。现在这个能力正在被 Agent 快速追赶。但"定义一个好的优化问题"这件事，Agent 还做不好。什么叫好的优化问题？目标清晰、约束明确、反馈可获取、且优化空间足够大。把一个大而模糊的需求，拆解成一系列 Agent 能执行的优化子问题，这个能力会越来越值钱。

还有"验证结果"的能力。Agent 能生成方案，但方案对不对、稳不稳、可维护性如何，需要人来判断。尤其是当 Agent 给出"有效但难解释"的方案时，你得有能力判断这个方案能不能上生产。

最后是"做取舍"的能力。Agent 优化的是你给它的目标函数，但真实世界里目标函数是多元且动态的。什么时候该追求极致性能，什么时候该优先稳定性，什么时候该为了可维护性牺牲一点性能，这些取舍需要人来拍板。

5. RSI 循环转起来之后，Infra 工作的价值锚点在哪

5.1 当优化本身被自动化，什么变得稀缺

如果 RSI 循环真的能在推理 Infra 里稳定转起来，那么"优化"这个动作本身会变得越来越廉价。你不再需要花几天时间手调一个 kernel，Agent 几十分钟就能给你一个不错的版本。这时候，稀缺的东西就变了。

变得稀缺的第一样东西是判断力。当 Agent 能生成一百个方案时，你需要有能力快速判断哪个方案值得深入、哪个方案有隐患、哪个方案虽然性能好但不适合当前场景。这种判断力来自对系统的深刻理解，不是靠搜索能获得的。

变得稀缺的第二样东西是问题定义能力。Agent 只能优化你给它的目标。如果你定义的目标是错的，或者不完整，Agent 会高效地把你带向错误的方向。定义正确的优化目标，需要你对业务、对系统、对约束有全面的理解。

变得稀缺的第三样东西是系统级思维。Agent 擅长局部优化，但局部最优不等于全局最优。有时候一个局部的性能提升，会带来系统级的复杂度增加或稳定性下降。能跳出局部、看到全局的人，价值会上升。

5.2 一个具体的例子：Kernel 优化之外的系统收益

我举个具体的例子来说明"系统级思维"的价值。假设 Agent 帮你把一个 attention kernel 优化了 30%，单看这个数字很漂亮。但如果你从系统角度看，这个优化可能带来几个副作用：一是这个 kernel 对 shape 更敏感了，导致在某些输入下性能反而下降；二是它的显存占用模式变了，影响了批处理策略的效果；三是它的实现更复杂了，增加了维护成本。

一个只看 kernel 性能的人，会直接采纳这个优化。一个有系统级思维的人，会评估这些副作用，判断整体收益是否为正。很多时候，一个"只快 15% 但更稳健"的方案，比"快 30% 但很脆弱"的方案更有价值。这种判断，Agent 目前做不了，因为它看不到你系统里的那些隐性约束。

5.3 给还在做 Infra 的人的三条实在建议

基于我这两周的观察和思考，给还在做推理 Infra 的朋友三条实在建议。

第一，把 Agent 当成工具用起来，别当对手。与其担心被替代，不如现在就开始用 Agent 帮你做那些重复性的优化工作。你省下来的时间，用来做更有价值的事。我现在的习惯是，遇到性能优化任务，先让 Agent 跑一轮，拿到一个基线，然后我在它的基础上做判断和改进。效率比纯手工高很多。

第二，往"上游"和"下游"走。上游是问题定义和架构设计，下游是结果验证和工程落地。这两个方向都是 Agent 短期内替代不了的。中间的"纯实现"环节，会越来越被压缩。

第三，保持对系统整体的理解。不要把自己局限在某个具体技术点上。Agent 可以比你更懂某个 kernel 的细节，但它不懂你的整个系统。你对系统整体的理解，是你相对于 Agent 的核心优势。

6. 落地层面的几个坑：Agent 做 Infra 优化没那么顺

6.1 反馈信号不可靠时的连锁失效

RSI 循环能转起来的前提是反馈信号可靠。但在真实的 Infra 环境里，反馈信号经常不可靠。比如 benchmark 结果受机器负载影响、受编译选项影响、受随机性影响。如果 Agent 拿到的反馈是噪声，它的搜索就会跑偏。

我遇到过一个情况：Agent 在优化一个 kernel 时，因为测试机器的负载波动，把一次偶然的快结果当成了真实优化，然后在那个方向上继续迭代，结果越走越偏。后来我加了多次测量取中位数、固定测试环境这些措施，才让反馈稳定下来。

这个坑的教训是：在让 Agent 做优化之前，先确保你的测量环境是可靠的。测量不可靠，Agent 再强也白搭。

6.2 过拟合到特定 shape 的隐患

Agent 做优化时，如果你给它固定的 shape 和固定的测试集，它会过拟合到这个特定场景。这在推理场景里特别危险，因为推理的输入 shape 往往是变化的。

我见过 Agent 优化出来的 kernel，在它训练时用的那个 shape 下性能极好，但换个 shape 就崩了。这种"优化"在生产环境里是负资产。解决办法是给 Agent 提供多样化的测试场景，让它在多个 shape 下都要达标，而不是只优化一个点。

6.3 生成方案的可维护性债务

Agent 生成的优化方案，往往可读性和可维护性较差。它可能用了很晦涩的写法，或者依赖一些不明显的假设。这些方案短期能跑，但长期会积累维护债务。

我的做法是，对 Agent 生成的方案做一次"人工审查 + 必要重构"。如果方案的核心思路是好的，但实现太晦涩，我会让 Agent 或者自己重写一版更清晰的。如果方案依赖了不安全的假设，我会要求 Agent 加上边界检查。这个过程会增加一些工作量，但能避免未来的大坑。

提示：给 Agent 生成的代码加上充分的注释和测试用例，尤其是那些"为什么这么写"的说明。Agent 不会主动解释它的思路，但你可以要求它解释，或者自己补上。

7. 我对这件事的最终判断

回到标题那句话——"Infra 被替代也不远了"。我的判断是：Infra 里"纯实现和纯调优"的部分，确实在被快速替代；但 Infra 里"定义问题、验证结果、做系统级取舍"的部分，反而变得更值钱。

这不是一个"替代或不替代"的二元问题，而是一个"工作内容重新分配"的问题。Agent 接手了那些可量化、可搜索、反馈明确的工作，人则聚焦到那些需要判断力、系统思维和业务理解的工作上。对能完成这个迁移的人来说，Agent 是放大器；对完不成迁移的人来说，Agent 是替代者。

我个人的态度是乐观的。推理 Infra 这个领域，过去太多时间花在了重复性的调优工作上，很多有价值的系统级问题反而没人有精力去碰。Agent 把这些重复工作接过去之后，我们终于可以去做那些真正需要人来做的事了。至于 RSI 会不会让这个进程加速到失控，我的看法是：在推理 Infra 这个有明确物理约束和工程边界的领域里，RSI 的加速是有天花板的，它受限于硬件、受限于验证成本、受限于工程落地的现实约束。所以不用恐慌，但也别装看不见。该学的学，该用的用，该转的转。