企业官网建设流程全解析

做 Infra 的人，手腕和肩颈最先向你抗议。RSI（Repetitive Strain Injury，重复性劳损）这个词，在我连续两周写了十几条告警处理记录、反复 SSH 到同一批机器敲同一串排查命令之后，从医生口中落到了诊断单上。也就是那段时间，我开始认真探索 GLM 的 Infra Agent。本来只想找个替我敲键盘的工具，结果它在磁盘告警、日志定位、配置变更这些场景里跑得又快又稳，甚至让我想明白了一个不太舒服的事实：Infra 被替代，可能真的不远了。这篇文章不是贩卖焦虑，也不是什么产品评测，而是我从亲身实践出发，拆一拆 Infra Agent 到底在做什么、哪些运维工作正在被接管，以及我们这些干 Infra 的人该怎么调整自己的位置和技能组合。无论你是 SRE、运维开发、DevOps，还是打算入行的新人，看完应该都能对自己手里的重复劳动有一个更清醒的判断。

1. 从手腕疼到 Infra Agent：一个“偷懒”需求引发的思考

1.1 Infra 工作的真实痛点：每天重复一万次的小手工

我这次探索的起因，其实特别朴素：手腕疼，疼到拿不起机械键盘。医生说是典型的重复性劳损，诱因很简单，就是常年高频率、低变化的手部动作。

回想一下我们每天的 Infra 工作状态：告警弹出来，先看规则、再看图、然后 SSH 上去、查日志、看磁盘、清缓存、重启服务、记录处理结果。这一套动作里没有一个需要深度思考的环节，但它们极度高频，而且每次占用的时间碎片化到无法专注做别的事。我统计过自己某个工作日的操作：登录跳板机 47 次，执行 df -h、free -m、top 这类基础命令超过 200 次，打开和切换监控大盘页面不计其数。这些操作加起来，差不多吞掉了三分之一的有效工作时间，而它们本质上全是重复劳动。

更麻烦的是，这种重复不只是消耗时间，它还在累积身体损伤。手腕、肩颈、眼睛，每个长期做运维的人多少都有点问题。我身边不少同事已经把日常巡检脚本化、自动化了，但告警的初步研判、变更的常规操作、日志的初步定位，依然大量依赖人工。因为这些任务看起来“每次都不太一样”，不好完全写死。也正是这个“不好写死”，让我动了用 AI Agent 来试试的念头——既然规则不能完全写死，那就让能理解意图的家伙来干。

1.2 为什么偏偏是 GLM 让我动了“用 Agent 干 Infra”的念头

市面上能写代码、能执行指令的 AI 工具不少，我试用过的路线包括 Claude Code 的入门玩法、Trea 这类 Claude 插件，以及用 cc switch 这类配置切换工具把底层模型换到 DeepSeek、Qwen、GLM 等不同家。一圈跑下来，真正让我在 Infra 场景里产生“这玩意儿能干活”感觉的，是 GLM 官方插件配合 Infra Agent 的结构化任务拆解能力。

首先是接入成本。VSCode 里装 GLM 官方插件，填上智谱开放平台的 API Key，再把模型切到带 thinking 模式的版本，比如 glm-5.3-flash 这类带 budget 调节的 flash 系列，它就能直接在编辑器里读文件、看项目结构、执行终端命令。对你没看错，终端执行权限是 Infra Agent 能落地的关键前提。之前很多 AI 编程工具只能改代码，不能碰服务器，那对 Infra 来说就等于废了一半。GLM 官方插件把代码编辑和终端执行打通了，Agent 才能真正去跑命令、看日志、做验证。

其次是中文意图理解。做 Infra 的都知道，告警描述、变更单、故障复盘，大量材料都是中文口语化的。我试过用英文语料为主的模型，它们对“把那个老机器上跑着的定时任务先停掉”这种话反应很迟钝，需要我重新组织成标准英文才能继续。GLM 在这块明显顺畅，这个差异在长对话里尤其明显，能省掉不少来回解释的力气。

最后是成本模型。Infra 任务和编程任务不一样，编程是小时级的连续工作，Infra 是分钟级的碎片操作。如果每次点一下都按完整对话计费，开销会非常难看。GLM 的 flash 系列在 thinking budget 模式下可以把推理开销控制在一个合理区间，适合反复试错、多轮验证的运维场景。我自己实测下来，一次包含感知、计划、执行、验证四阶段的磁盘告警处理，消耗的 token 量在一个可以接受的范围，比开一个完整 IDE 会话然后长时间空转要划算得多。

2. Infra Agent 到底在替代什么？重新解构运维工作的可自动化份额

2.1 运维工作的四象限：重复、判断、创新、沟通

先说一个容易引起误解的地方：说“Infra 被替代”，不等于说整个运维岗位消失。更准确的说法是，运维工作里有一大块长期靠人肉堆出来的执行类任务，正在被 Agent 以更高的速度和质量接管。要理解这一点，得先把我们每天做的事拆成四个象限。

第一类是规则明确的重复执行。比如确认某个端口是否监听、磁盘使用率是否超过阈值、某类错误日志出现频率有没有上升。这些操作有标准命令、有固定顺序、有明确结论，本质上就是“按流程走一遍”。第二类是模式驱动的常规判断。比如根据日志特征判断是连接数过多还是慢查询堆积，根据监控曲线判断是流量突增还是代码缺陷。这类工作有一定判断成分，但判断模式相对固定，有经验的运维看几眼就能定方向。第三类是架构设计、容量规划、故障根因分析这类高度依赖上下文和业务理解的创新工作。第四类是跨团队沟通、变更协调、事故响应指挥等强协作工作。

过去我们总觉得第一类和第二类必须由人来干，因为环境总在变、命令总有差异。但 Agent 的出现恰恰改变了这个前提：它不依赖固定脚本，而是依赖对自然语言意图的理解加实时环境感知。于是第一类几乎被完整覆盖，第二类的大部分常见模式也开始被覆盖。创新和协作这两类短期看不到被替代的迹象，但前两类占据了我们日常时间的六成以上，这才是“不远了”的真实含义。

2.2 Agent 不是 Ansible：从“写死规则”到“理解意图”

很多人会说，磁盘告警自动清理、日志自动归档，Ansible、SaltStack 加一堆脚本不也能做吗？凭什么说是 Agent 的功劳。这里有个本质区别，值得展开讲一讲。

传统自动化的工作方式是“你告诉它怎么做”。你得把每一条可能的分支都考虑清楚，写成 playbook，然后在特定条件下触发。它的优点是稳定、可审计、结果可预期；缺点是一旦环境偏离预设路径，比如某台机器日志路径变了、某个目录权限异常、某个服务状态不在预期中，自动化流程就会当场卡死，最后还是得人肉上去救火。这就像给厨师写了 100 张详细菜谱，但食材型号稍微一变，厨师就不会做了。

Agent 的工作方式则是“你告诉它做什么，它自己拆解怎么做”。它先感知当前环境——看一下磁盘挂载、看进程列表、看日志目录结构，再基于感知结果规划命令序列，每执行一步都验证输出是否符合预期，不行就自动调整。这对 Infra 来说是代际差异：它不再要求环境必须匹配预设模板，而是实时适应环境本身。用我实际跑过的例子来说，传统脚本面对“某台机器 /data 分区 96%”会执行固定清理命令，而 Agent 会先去查哪些文件最大、哪些日志可以压缩、哪些归档目录超过保留期限，然后给出一个有主次顺序的清理方案再动手。

当然，我对 Agent 的能力边界也保持清醒。它目前更像一个经验丰富的实习生在替你跑腿，而不是完全可信的自动化流程。所以“执行前审批、执行后验证”这两条红线，我在任何场景下都没有放松过，后面会单独讲。

2.3 让我真正感到“不远了”的三个瞬间

关于“被替代”的感觉，不是某个大版本发布时突然产生的，而是三次具体的实操瞬间叠加出来的。

第一次是磁盘告警处理。我给它一个很口语的指令：“看看哪台机器磁盘要爆了，找一下大头，把超过 7 天的日志清掉。”它自己 SSH 上去，执行 df -h 找到目标机器，用 du 按目录排序找到日志和备份文件，确认文件修改时间后清理了归档，最后又跑一遍 df -h 确认使用率降下来了。整个过程我只负责下达最初指令和最终确认，中间十来分钟完全没碰键盘。那一瞬间我意识到，过去让我手腕疼的那些动作，它一个不少地全干完了。

第二次是慢 SQL 定位。它读了一份 MySQL 慢查询日志，按执行时间排序列出 Top 10，结合表的索引情况判断出三条明显缺少索引的慢查询，给出了加索引的 ALTER 语句建议。但它没有直接执行 ALTER，而是在输出里单独标了“该操作涉及锁表，建议业务低峰期执行，需要人工确认”。这个拿捏让我印象深刻——它知道自己该做什么，也知道什么不该自己做。

第三次是扩缩容演练。我让它检查某服务的当前副本数和负载情况，模拟一次扩容操作。它在执行前主动检查了副本状态、滚动更新策略和健康检查端口，最后给出一个分批扩容的方案。这份严谨程度，已经超过我带过的好几个刚入门的初级运维。三次下来，我彻底打消了“Agent 只适合写代码”的偏见。

3. 实操：在本地环境里亲手跑一轮 Infra Agent 巡检

3.1 环境准备：VSCode + GLM 插件 + API Key 的最小配置

如果你也想复现一轮 Infra Agent 实操，我来梳理一个最小可用的环境配置。整个准备过程大概二十分钟，成本主要花在 API Key 和终端权限准备上。

第一步，装 VSCode 和 GLM 官方插件。这一步没什么特别的，在扩展市场搜 GLM 就能找到，安装后侧边栏会多出一个对话面板。插件安装完成后，进入设置页填入智谱开放平台获取的 API Key。这里有个小建议：第一次配置时可以顺手看一下模型选择列表，通常会有不同版本的 flash 系列和 thinking 模式选项。我建议一开始就选择带 thinking 的版本，因为能看到推理过程，对理解 Agent 的决策逻辑很有帮助。

第二步，配置第三方模型切换环境。如果你不想只绑一个厂商，可以把 cc switch 这类模型配置切换工具用起来。它能统一管理 DeepSeek、Qwen、GLM 等多家 API 的 BaseURL 和模型名，在 VSCode 插件里通过环境变量或配置文件切换。Trea 这类 Claude 客户端插件也可以通过修改 API 端点配置接入 GLM，具体路径是编辑客户端的模型配置项，把 provider 指向兼容 OpenAI 格式的接口。这一套的好处是：以后哪家模型在处理 Infra 任务上表现更好，你切换成本几乎为零。

第三步，给 Agent 准备一个有边界的执行环境。这是我每次都会强调的红线：不要在一开始就给 Agent 生产环境的 root SSH 权限。最稳妥的做法是准备一台测试机或者一台可随时回滚的云主机，用独立 SSH 密钥、受限用户身份接入。权限边界要在 prompt 里明确写清楚：只能操作哪些目录、只能执行哪些命令类别、禁止改动哪些服务。这一步做不好，后面的所有省力都是给自己埋雷。

3.2 一次完整的 Infra Agent 任务：磁盘告警从发现到处置的全程实录

我以最近一次实际跑通的“磁盘告警处置”为例，展示 Agent 从感知到验证的完整路径。任务背景是三台应用服务器中的一台报磁盘使用率超过 85%，我给它下达的原始指令很口语化：“检查一下那台 10.20.30.40 的磁盘，看看什么东西占空间，把超过 7 天的归档日志清掉，确保使用率降到 80% 以下。”

Agent 的行为日志大致如下：

[感知] 执行 df -h，发现 /data 分区使用率 94%（目标阈值 85%） [感知] 执行 du -x --max-depth=2 /data | sort -nr | head -20， 定位到 /data/applogs 目录占用 68G [规划] 检查 /data/applogs 内文件时间分布，确认 7 天前归档文件共 41G， 其中 .log.20250316.tar.gz 等压缩包符合清理条件 [执行] rm /data/applogs/*.tar.gz.old （仅清理超过保留期限的归档） [执行] find /data/applogs -mtime +7 -name "*.log" -delete [验证] 再次执行 df -h，/data 使用率降至 73%，任务完成 [汇报] 输出磁盘空间回收前后对比，并提示 cron 日志轮转策略是否需同步调整

看完这段日志，你应该能理解我前面说的“感知—规划—执行—验证”闭环是什么意思。它没有直接按预设脚本一顿乱删，而是先确认哪些文件值得清、哪些文件不能动，然后再动手，最后还留了一句关于日志轮转策略的提示。这个提示对资深运维来说很熟悉——清理旧日志只是治标，轮转策略才是治本。Agent 能在执行完之后多往前走一步，这种思考惯性已经超出普通自动化工具的范畴了。

在实际操作过程中，我并不是完全放手。我在下达指令时加了几个约束条件：只允许清理 /data/applogs 目录下的文件、不允许动数据库相关目录、执行前必须打印完整命令。把 Agent 当作一个能力很强的执行者，但同时给它划好护栏，这是目前阶段最合理的人机协作姿态。实验做完之后，我建议你把本次会话的完整输出保存成一份 Markdown 文件，作为后续优化 prompt 的语料。

3.3 我踩过的坑和调参心得

第一次以 Infra 视角跑 Agent，我踩的坑比想象中多，挑几个典型的来说。

第一个坑是任务拆得太粗。最开始我给它一个大而全的指令：“全面检查一下这三台机器，有问题一起处理掉。”结果它在环境感知阶段就花了大量 token，输出变得非常啰嗦，处理到第二台机器时上下文已经很长，后续质量明显下降。后来我改成“一台机器一次任务，每个任务一个明确目标”，成功率明显提升。经验是：把任务按机器维度和目标维度拆细，一次会话只做一件事，做完立刻开新会话。

第二个坑是 thinking 模式的 budget 和速度的平衡。thinking 模式很稳，但响应时间偏长；非 thinking 模式速度快，但处理复杂任务时容易出现步骤跳跃。我的做法是：新场景、高风险操作开启 thinking，跑熟后的常规巡检任务切到低 budget 的闪速模式。GLM 插件里如果能看到 budget 相关的参数配置，建议第一次先用默认值，跑三五次之后根据实际响应质量再调。如果你通过 cc switch 管理的多个模型里有一个运行速度特别慢，大概率是 thinking 模式没关。

第三个坑是日志量太大导致上下文爆炸。让 Agent 去“看看日志里有什么异常”，它会把几百 MB 日志读完，然后在输出里给你一个非常长的报告，既费 token 又难抓重点。我自己摸索出来的办法是让 Agent 先 tail 最后 200 行，或者先用 grep 把关键词频率统计出来，再做下一步判断。这就像看病先查血常规，不会一上来就做全身核磁。

还有一个容易忽略的细节：执行环境的内网访问范围。Agent 的机器能访问哪些主机、哪些端口，直接影响它能做什么事。我一开始没给测试环境配置内网 DNS，结果它连目标主机都 ping 不通，白白浪费了好几个来回。建议在 prompt 里直接告诉它“你可以访问的内网网段是哪些、目标主机的别名是什么”，这比让它自己慢慢探测高效得多。

4. 常见问题与排查技巧实录

4.1 Agent 跑偏了怎么办：幻觉与误操作的三道防线

AI Agent 跑 Infra 任务，最让人担心的问题永远是一个：它会不会乱来？我的回答是：会，而且一定会，只是概率大小问题。应对这个问题，我给自己定了一套三道防线的纪律，这里分享给你。

第一道防线是沙箱环境。所有高风险操作先在测试环境完整跑一遍，再把同一套 prompt 搬到生产环境高受限账号上执行。这一步验证的是 Agent 对任务的理解是否准确，而不是验证生产配置是否兼容。第二道防线是变更审批。我不会给 Agent 完整的写权限，而是在 prompt 里要求所有变更类命令执行前，先把命令完整打印出来等待确认。在 Agent 工具链支持交互确认的情况下，从设置里打开确认开关，效果比在 prompt 里写“请确认”更可靠。第三道防线是强制验证。要求 Agent 在任务收尾时把变更前后的状态对比输出，比如磁盘使用率前后对比、服务状态前后对比、受影响文件清单。如果它拿不出验证结论，就视为任务未完成。

实际过程中，我遇到过 Agent 幻觉的情况。有一次它跟我汇报“已删除超过 30 天的归档文件”，但我要求它输出验证结果时，它给出的 df -h 数据和真实不一致。后来排查发现，它在执行删除命令时根本没有检查文件路径是否存在的细节，而是基于它对“应该被清理的文件”的推测生成了汇报。这种情况一旦出现，立即终止会话，检查它在沙箱中的完整行为日志，并且把这次经验总结进后续使用的风险提示词里，比如“你删除的文件路径必须来自 du 的真实输出，禁止推测”。

4.2 私有化环境与内网限制怎么处理

很多做 Infra 的朋友关心一个问题：我的环境在内网，甚至完全离线，Agent 怎么跑？这个问题需要拆成两层看。

第一层是模型本身的部署位置。如果内网完全无法访问外部 API，你需要私有的模型部署方案，市面上有不少可以本地或私有化部署的开源模型，GLM 系列也有相应的开源版本。部署完成后把客户端的 BaseURL 指到内网网关就行，VSCode 插件和第三方客户端的配置方式都支持这种自定义端点。第二层是 Agent 执行环境与目标服务器的网络连通性。如果你的 Agent 跑在本地开发机上，目标服务器在内网核心区，中间隔着堡垒机，那就必须提前解决跳板登录、密钥转发、端口转发这些问题。我遇到过最常见的情况是：Agent 说得头头是道，但一执行命令就超时，原因就是它根本无法访问目标主机。

这里给一个折中方案：让 Agent 只负责生成和执行脚本，而把脚本下发到目标服务器的动作交给现有的自动化通道，比如通过内部作业平台推送。这样 Agent 只需要能访问执行机，不需要直连每一台内网服务器，同时还能利用已有的审批审计机制。私有化环境里，镜像源、依赖仓库、基础软件源都要提前配好。Agent 如果没有安装某个命令行工具，它会尝试自动安装，但如果你的内网没有对应的软件源镜像，这一步就会卡死，非常影响体验。

4.3 从“会用”到“用得稳”：几个参数和习惯建议

同样的 Agent，有人用起来稳如老狗，有人用起来天天翻车，差别通常不在模型能力，而在使用习惯。整理几条我自己的实操习惯，供你参考。

第一条，一个会话只做一个大任务。这是我自己吃过亏后总结的最重要一条纪律。Infra 任务往往涉及多轮工具调用和状态验证，中间如果穿插其他话题，Agent 的注意力会被稀释，后续行为质量明显下降。第二个习惯是任务描述按固定模板来。我通常的格式是：背景（当前告警或现状一句话）、目标（要达成的可量化结果）、约束（哪些不能动、哪些必须先确认）、验收标准（任务完成时应该看到什么输出）。这个模板看着机械，但在多轮交互中能显著减少 Agent 的困惑。

第三条，变更类任务一律先 dry-run。在正式执行前，先让 Agent 把将要执行的命令和预计影响范围用文字描述出来，我看完确认后再让它动手。这一步的成本很低，但能挡住大部分低级误操作。第四条是上下文管理。如果任务没跑完但上下文已经很长，不要硬着头皮继续，而是让 Agent 先总结当前状态、输出一个中间结论，再开新会话继续。这比在一个长会话里硬扛更可靠，也更好控制成本。

我给这些习惯起了个名字，叫“Agent 使用礼仪”。它和做人际协作很像：信息给足、边界划清、预期对齐、确认闭环。做到了这四点，Infra Agent 就是一个很靠谱的协作对象；做不到，它就是一台昂贵的错误制造机。

5. RSI 之后：当重复劳动被接管，Infra 工程师的价值在哪里

5.1 身体已经够累了，心态别再卷错了方向

聊完技术，我想把话题拉回到这次探索的起点：RSI 和职业健康。说实话，当我看到 Agent 把那些让我手腕疼的重复劳动一件件处理掉的时候，我的第一反应不是恐惧，而是一种后知后觉的轻松。

过去我们太习惯把“手熟”等同于“价值”了。谁的命令敲得快、谁对监控页面切换得溜、谁能不看文档就背出排查步骤，谁就显得专业。但这些能力本质上都是重复劳动的副产品，它们建立在持续消耗身体的基础上。Agent 把这些部分接管之后，很多 Infra 人可能会经历一段“无事可做”的迷失感，因为你过去赖以自信的技能突然没那么重要了。这种心理落差，比技术冲击更值得认真对待。

我的建议是，把注意力从手指转移到判断力上。Agent 能帮你执行命令，但不能替你做决策。它告诉你磁盘该清了，但你要判断清到什么程度、要不要考虑业务影响、要不要顺手优化轮转策略；它告诉你慢查询缺索引，但你要判断加索引的时机、是否影响写入性能、是不是还有更底层的设计问题。这些判断，才是未来 Infra 工程师真正的护城河。人不可能靠着磨损手腕和颈椎，去和 AI 竞争谁的命令敲得标准。

5.2 人机协作的 Infra 工作流雏形

经过了这轮探索和几十次实操，我慢慢形成了自己的一套人机协作工作流，写出来给同行参考。

日常巡检类任务完全交给 Agent。它按照我给的标准模板，定时或按需巡检磁盘、负载、日志告警，产出一个结构化的巡检报告。报告中只有异常项才会进入我的审核视野，没有异常的例行项自动归档。这就把原来每天早上雷打不动的“逛一圈监控大盘”的时间压缩到了接近零。常规变更类操作进入“Agent 执行 + 人审批”的流程。Agent 先出计划、列命令、预估影响范围，我审核确认后它再去执行，执行完自动输出验证结果。

真正需要我深度介入的是三类事：一是异常升级，Agent 无法判断的高风险故障，它直接呼叫我来处理；二是架构与设计决策，容量规划、高可用方案、成本治理方向；三是事后复盘，把 Agent 记录的行为日志和故障时间线转换成团队的流程经验。这个分工让我每天的精力有更大部分花在真正需要“人”的事情上。我自己的体会是，过去我像一个每天忙着抹桌子的服务员，现在我更像一个负责排菜和检查菜品质量的厨师长。

5.3 给同行的建议：别等替代找上门，先把它变成你的杠杆

最后想给还在观望的同行一些建议。我理解“被替代”这三个字听起来很刺耳，但它更像是行业转型的预警，而不是末日宣判。关键不在于这个岗位会不会消失，而在于你愿不愿意先把自己从重复劳动中解放出来，去做那些更重要的判断和设计。

我的建议有三条。第一条，从明天开始，挑一个你最讨厌的重复性运维任务，尝试用 Agent 跑通它。不要挑太复杂的，就从一条告警的处理开始。这一步的目的是建立你对 Agent 的体感，知道它在什么场景可靠、什么场景需要人工兜底。第二条，建立你自己的 Agent 使用规范，把约束、审批、验证这些安全护栏变成肌肉记忆。不要因为任务简单就跳过安全流程，翻车往往发生在你以为不会出问题的时候。第三条，把你在重复劳动上省出来的时间，投入到业务理解、架构设计和稳定性工程这些高价值领域。你要让别人记住你，是因为你解决了别人解决不了的技术难题，而不是因为你删日志比别人快。

从 RSI 开始探索 Infra Agent，这个过程对我个人而言是一次重新审视工作的契机。真正该被替代的，从来不是 Infra 这个岗位，而是那些让我们一个个落下手腕和肩颈毛病的重复动作。那次探索给我最大的收获，不是省下了几个小时，也不是发现了一个好用的工具，而是逼我重新看清了自己的时间都花在了哪里。如果你也是每天跟告警、日志、变更打交道的人，我建议找一个小任务让 Agent 先试试，就从最不重要的那台机器开始。它做得好，你的手腕会感谢你；它做得不够好，你至少会想清楚，自己为什么要继续做那些重复劳动。日子还长，别把手腕拼完了才发现，那些功夫本来就不该是人的专长。