Prometheus和Grafana在Kubernetes中的部署与告警实践-北京尧图网络

简介面向Kubernetes集群运维与监控实践者提供一套基于Prometheus和Grafana的完整部署配置用于解决k8s环境下指标采集、存储与可视化的落地问题这套方案涵盖了从指标抓取、规则配置到告警通知的完整链路。压缩包共含3个YAML文件大小约5KB分别是Prometheus服务配置、Grafana部署配置和Node Exporter节点指标收集配置可直接用于集群部署标题标注亲测可用目前已有836人学习/下载。借助这套配置读者既能了解Prometheus通过Service Discovery自动发现Pod、配置alerting规则并交由Alertmanager告警的机制也能掌握Grafana接入数据源与仪表盘展示的完整流程同时理解Node Exporter如何暴露主机负载、磁盘等关键指标。资源文件均为YAML格式简洁易读便于按需修改适合具有基本容器概念、希望快速搭建监控告警体系的中级运维人员也可作为Kubernetes监控学习的参考模板。1. 先从标题说起为什么应该把 Prometheus 和 Grafana 部署进 Kubernetes而不是装在外面一个微服务 Pod 连续重启了八次业务方已经来催你打开 Grafana 面板却发现最近两小时的数据一片空白——这种“出事时拿不出数据”的处境是很多团队下定决心在 Kubernetes 上部署 Prometheus 和 Grafana 的直接原因。这件事表面上是安装两个组件本质上是把监控的发现机制从“写死 IP 列表”改成“跟着标签和服务发现走”让采集能力跟随 Pod 的声明周期伸缩。下面我按自己动手的顺序来讲先拆解采集链路的核心机制再给出可以直接抄的 Helm 部署命令和必调参数然后处理 Grafana 数据源与告警闭环最后列出几个踩过的坑和一套验证监控真的能用的故障演练方法。读完这套你可以在一个现成的集群里用一两天的空闲时间把监控体系立起来并且确认它不只是在页面上好看而是真的会在出事的时候叫你起床。2. 采集链路的核心原理Prometheus 怎么在 Kubernetes 里自动找到监控目标2.1 Pull 模型与 Kubernetes 动态环境的契合点Prometheus 采用 Pull 模型由服务端主动定期访问每个目标暴露出来的 HTTP 指标端点。这一点放到 Kubernetes 里非常关键Pod 是临时资源随时会被调度到别的节点、被重启、被水平伸缩IP 地址变化是常态。如果沿用传统“在配置文件里写死目标地址”的方式每次发布都会引入一批失效配置。Kubernetes 解决这个问题的思路是“服务发现”。Prometheus 通过访问 API Server定时获取 Service、Endpoints 和 Pod 的最新状态再用标签选择器过滤出需要抓取的目标集合。换句话说目标列表是动态生成的新 Pod 一创建、标签匹配上下一次采集就会覆盖它Pod 被删除目标自动从列表中消失。这里需要理解 Prometheus 四种指标类型否则后面写告警规则时容易踩坑类型语义典型用途Counter只增不减的计数请求总数、重启次数Gauge可上下浮动的数值CPU 使用率、内存占用量Histogram带有桶的分布统计请求延迟分位数Summary客户端预聚合的分位数延迟的 median、p99Counter 类型的指标名通常以_total结尾计算速率时必须配合rate()或increase()函数使用。很多人直接把container_restart_count这种原始值拿来告警阈值永远没法写对原因就在这Counter 的总量只会随重启次数增加而单调递增必须用一段时间窗口内的增量才能反映“最近是否频繁重启”。2.2 ServiceMonitor 的标签匹配链从 CRD 到 Target 的完整路径直接用裸 Prometheus 部署时你需要维护一份 scrape_configs把每个服务的指标端点写进去。在 kube-prometheus-stack 或者 prometheus-operator 这套体系里采集配置被抽象成了一个 CRDServiceMonitor。它的工作链路是这样的prometheus-operator 监听集群内 ServiceMonitor 对象的增删改然后把它们翻译成 Prometheus 内部的 scrape_configs再通过 API 让 Prometheus 热加载。一个 ServiceMonitor 里面写了两个关键的标签匹配逻辑第一层ServiceMonitor 对象自己身上的 labels用来匹配 Prometheus 实例的 serviceMonitorSelector。也就是说你的 ServiceMonitor 必须带着 Prometheus 认识的标签它才会被纳入采集范围。第二层ServiceMonitor spec.selector 里写的 matchLabels用来匹配真正要监控的 Service。很多第一次配的人在第二层栽跟头ServiceMonitor 创建成功了但 Targets 页面上一个端点都没有因为两层标签只对上了一层。看下面的例子apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: demo-app-monitor namespace: monitoring labels: release: kube-mon # 这一层标签匹配 Prometheus 的 serviceMonitorSelector spec: selector: matchLabels: app: demo-app # 这一层标签匹配你要监控的 Service endpoints: - port: metrics # 这个端口名必须存在于 Service 的定义里 interval: 30s path: /metrics端口名是第二个常见坑。endpoints 里写的是端口名port 字段而不是端口号它必须与 Service 定义里的ports[].name完全一致大小写敏感。有些应用直接把指标端口叫http或没给名字那 ServiceMonitor 里也得对应改。Prometheus 拿到 Service 后会通过它的 Endpoints 获取背后所有 Pod 的 IP 地址然后逐个去拉/metrics。注意ServiceMonitor 只负责发现目标并不接管网络Prometheus Pod 到目标 Pod 之间的连通性必须保证。默认情况下整套系统部署在同一个集群里走 ClusterIP 没问题但如果你的业务命名空间开启了 NetworkPolicy就要额外放行从 monitoring 命名空间发起的抓取流量。2.3 选型对比kube-prometheus-stack 为什么是默认答案Prometheus 社区给出了一套打包方案把 prometheus-operator、Prometheus、Alertmanager、Grafana、node-exporter、kube-state-metrics 以及一组现成的告警规则和仪表盘打包进同一个 Helm Chart。这对绝大多数团队来说是性价比最高的选择。先列出这套方案里的组件和各自职责组件职责是否必需prometheus-operator管理 Prometheus/Alertmanager CRD必需Prometheus指标采集与存储必需Alertmanager告警去重、分组、路由发送推荐Grafana数据可视化与面板管理推荐node-exporter采集节点层面指标必需kube-state-metrics从 API Server 生成集群对象指标必需如果只部署一个裸 Prometheus 加 Grafana节点指标、Kubernetes 对象指标Pod 状态、Deployment 副本数都需要自己搭 exporter还要自己写一堆 scrape_configs。用打包方案省掉的不是命令行而是从零维护采集配置的成本。资源规划方面我给一个保守的起步值一个 8 核 16 GB 的节点池跑这套监控栈默认配置没问题。Prometheus 和 Grafana 各自预留 2 GB 内存比较稳妥Alertmanager 给 512 MB 就够。如果你的集群节点规模超过 50 台或者单节点上 Pod 密度很高就得多关注kube-state-metrics的指标量级后面会在参数调整节具体讲。3. 用 Helm 部署 kube-prometheus-stack最小命令与必调参数3.1 前置条件先确认三件事再动手不要上来就 helm install先把前置条件检查一遍。第一个是存储类整套方案里 Prometheus、Grafana、Alertmanager 都有可能创建 PVC。如果你的集群没有默认 StorageClass创建 PVC 会一直卡在 Pending后面排查起来要绕一大圈。kubectl get nodes -o wide kubectl get storageclass kubectl get crd | grep monitoring.coreos.com三条命令分别确认节点状态、可用的存储类、以及是否已存在监控相关的 CRD。第三条很重要如果集群里之前装过 operator 或者别的监控套件残留的 ServiceMonitor CRD 会和新的 Chart 冲突轻则标签匹配混乱重则安装报错。如果有残留建议在测试环境里先卸载干净再装新的。实际项目中我就遇到过现场环境里存在旧版 prometheus-operator 遗留的 CRD导致新版 operator 启动后直接以“CRD 版本不支持”为由退出。第二个前置条件是命名空间规划。我一般固定用monitoring作为监控专用命名空间业务应用不要往里放这样权限边界和资源配额都清晰。第三个前置条件其实是一条习惯把 helm repo 更新到最新。直接安装不带版本号拿到的就是当前最新版后续配置字段越新越全。3.2 安装命令与最小 values 文件helm repo add prometheus-community https://prometheus-community.github.io/helm-charts helm repo update helm install kube-mon prometheus-community/kube-prometheus-stack -n monitoring --create-namespace -f values.yamlhelm repo add是把 Prometheus 社区仓库加进来helm repo update拉取最新的 Chart 索引。kube-mon是这次安装的 release 名后面很多内部资源命名都以它开头比如kube-mon-kube-prometh-prometheus所以这个名字要想好别用太随意的字符串。--create-namespace会在 monitoring 命名空间不存在时自动创建省一步。最少只需要这一个命令就能得到一个完整可用的监控栈。但我强烈建议第一次就用-f values.yaml把参数管起来原因是 Helm 的默认值里最不利于生产的有两个Prometheus 和 Grafana 的存储都不持久化Pod 一重启历史数据全没Grafana 默认密码也是公开的。下面是我用于中小集群的起步配置prometheus: prometheusSpec: retention: 7d retentionSize: 20GB storageSpec: volumeClaimTemplate: spec: storageClassName: standard accessModes: [ReadWriteOnce] resources: requests: storage: 50Gi resources: requests: memory: 2Gi cpu: 500m limits: memory: 4Gi cpu: 1 grafana: adminPassword: replace-with-a-strong-password persistence: enabled: true storageClassName: standard size: 10Gi alertmanager: alertmanagerSpec: storage: volumeClaimTemplate: spec: storageClassName: standard accessModes: [ReadWriteOnce] resources: requests: storage: 5Gi这里的storageClassName要按你集群里实际存在的存储类改比如云厂商的托管集群通常是standard或managed-csi自建集群用local-path也很常见。retention控制 TSDB 数据保留时间retentionSize控制数据量上限两者可以同时设置谁先到上限谁触发清理。3.3 必调参数的作用与取舍有几个参数是很容易被忽略但影响深远的我单独拎出来讲。retentionSize和retention的区别在于前者按磁盘占用清理后者按时间清理。如果你的监控数据写入量不大只设retention: 7d就够了但如果业务指标量大时间没到磁盘先满了block 会写入失败导致数据损坏。两个都设是比较稳的做法给retentionSize留出比持久卷容量小 20% 的预算比较合适。resources里的内存限制对 Prometheus 尤其重要。OpenMetrics 格式的指标在内存里是按 series 组织的Pod 数量变化、暴露的指标数量波动都会直接影响内存占用。限制设得太小会导致 OOM Kill设得太大又会在节点上挤占业务资源。提到 4 Gi 是因为 node-exporter、kube-state-metrics 加上十几个业务 Pod 的常规规模下这个量级基本够用。Grafana 的persistence开启后面板配置、用户信息、组织设置都存在 PVC 里。不开启的后果是我在测试环境里真实遇到过的升级 Grafana 版本后新建的面板全部消失连数据源配置都回到默认值只能重新手工配一遍。3.4 部署后的三层验证安装命令跑完不等于部署成功。我习惯按这个顺序检查kubectl get pods -n monitoring kubectl get svc -n monitoring kubectl get prometheus -n monitoring第一层看 Pod所有 Pod 应该是 Running 且 Ready 列是 1/1。第二层看 ServicePrometheus 的 Service 通常是 ClusterIP 类型Grafana 的 Service 会根据 Chart 配置变成 NodePort 或 LoadBalancer。第三层看自定义资源确认 Prometheus 对象状态里没有报错。然后做一次临时端口转发手动进 Prometheus 页面看采集目标kubectl -n monitoring port-forward svc/kube-mon-kube-prometh-prometheus 9090浏览器打开http://localhost:9090进入 Status - Targets你会看到 kubelet、node-exporter、kube-state-metrics 等一批目标。这一步能直观确认采集链路已经活起来了。如果 Targets 有红色 Down 的下一步再去排查是网络策略、端口命名还是标签匹配的问题这会在第五章展开。4. Grafana 数据源与告警闭环让监控从“能看”到“会叫”4.1 默认数据源从哪里来kube-prometheus-stack 在部署时会在 Grafana 里预置一个指向本套 Prometheus 的数据源所以安装完直接登录就能看到数据不需要手动填 url。这个配置是通过 ConfigMap 下发的验证方式如下kubectl get cm -n monitoring | grep grafana kubectl get cm kube-mon-grafana -n monitoring -o yaml | grep -A 10 datasourceConfigMap 里应该能看到datasources.yaml其中url指向 Prometheus 的 Service 地址形如http://prometheus-operated.monitoring.svc:9090。这里值得注意的点是Grafana 与 Prometheus 之间走 Service 内部 DNS而不是 Pod IP。好处是 Go 容器重调度后这个地址不变配置永远有效。如果后续需要接入第二个 Prometheus 数据源不建议直接改这个 ConfigMap改成在 values 里追加grafana: additionalDataSources: - name: Prometheus-2 type: prometheus url: http://another-prometheus.monitoring.svc:9090 access: proxy isDefault: falseaccess: proxy表示 Grafana 通过服务端代理去请求 Prometheus而不是让浏览器直连。默认用 proxy 就好直连模式在浏览器端会出现跨域问题还会把内网地址暴露给客户端。4.2 导入集群大盘与变量调整这套 Chart 安装后自带一组面板节点 CPU、内存、网络、Pod 状态这些通用视角都覆盖到了。登录 Grafana默认端口 3000在 Dashboards 菜单里能看到所有预置面板。如果你所在团队有更高的要求比如想看某个特定中间件的慢查询分布可以到官方 Dashboard 市场搜关键词下载 JSON 后在 Import 页面粘进去。导入面板时最容易翻车的点不是面板本身而是变量。很多社区面板顶层都有namespace、job、pod这类模板变量导入后必须去 Settings - Variables 确认它们用的查询语句在你的集群里有数据。比如默认变量job的查询是label_values(job)如果你的 Prometheus 里确实有那面板就能跑起来但有些面板写死了特定 exporter 的 job 名导入后图表全是 No data。这种不要硬凑直接把对应变量改掉或者放弃这块面板换个更通用的。还有一个细节社区面板的刷新时间默认 5 秒对大部分集群来说过于频繁会把 Prometheus 的查询压力放得很大。导入后我一般把面板级刷新时间改成 1 分钟图表的$__rate_interval变量会自动适配查询区间。4.3 配置一条真正的告警规则并联动 Alertmanager先看告警规则。规则以 PrometheusRule 这个 CRD 表达注意它自身也必须带标签否则 operator 不会加载它。以容器频繁重启为例apiVersion: monitoring.coreos.com/v1 kind: PrometheusRule metadata: name: demo-app-rule namespace: monitoring labels: release: kube-mon app: kube-prometheus-stack spec: groups: - name: demo-app-alerts rules: - alert: DemoAppRestartTooFrequent expr: increase(kube_pod_container_status_restarts_total[5m]) 3 for: 3m labels: severity: warning annotations: summary: Pod {{ $labels.namespace }}/{{ $labels.pod }} 5分钟内重启超过3次规则里expr用了increase()函数计算 5 分钟内重启次数的增量阈值设 3for: 3m意思是这个条件持续 3 分钟才触发告警避免瞬间抖动误报。labels里的severity会在 Alertmanager 里用于路由分组。有了规则还需要 Alertmanager 把它发出去。默认部署里 Alertmanager 只有一个空配置不会做任何通知。常见的做法是接一个通用的 Webhook 接收端配置写在 values 里alertmanager: config: global: resolve_timeout: 5m route: group_by: [alertname, namespace] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://your-alert-sink:8080/hookgroup_by决定哪些维度相同的告警会被合并成一组减少轰炸group_wait是组内第一条告警发出前的等待时间用于吸收短时间内的连续触发repeat_interval控制同一个告警的重复提醒频率设 4 小时比较合适。这套配置改完后执行helm upgrade kube-mon prometheus-community/kube-prometheus-stack -n monitoring -f values.yaml让变更生效。到这里监控体系才算是完整的有采集、有可视化、有规则、有通知渠道。很多团队卡在只装了两个 Chart 就当完成任务结果告警全都憋在 Prometheus 内部从来没人收到。5. 部署与日常维护中的五个避坑记录5.1 坑一Grafana Pod 反复 CrashLoopBackOff问题不在镜像而在存储现象部署后 Grafana Pod 一直 CrashLoopBackOff日志里报无法创建目录或者权限不足。我遇到过最典型的是/var/lib/grafana写入失败。原因常见有两类。一是集群没有默认 StorageClassGrafana 的 PVC 一直 PendingPod 等不到卷就反复重启二是用了 NFS 类的共享存储但挂载目录权限不是 Grafana 运行用户uid 472可写的。解决先看 PVC 状态kubectl get pvc -n monitoring kubectl describe pod -n monitoring -l app.kubernetes.io/namegrafana如果 PVC 是 Pending说明 StorageClass 没配对去 values 里改成实际存在的存储类。如果卷已经 Bound 但 Pod 还报权限错误可以在 values 里给 Grafana 开启persistence.accessModes并挂一个带正确属主的目录或者换用本地存储类。日常排错顺序先 events再日志最后才怀疑配置。5.2 坑二Targets 页面一个端点都没有ServiceMonitor 标签匹配失败现象自己写的 ServiceMonitor 创建成功Prometheus 的 Targets 页面却完全看不到对应的目标状态栏一片空白。原因Prometheus 实例有自己的serviceMonitorSelector在 kube-prometheus-stack 里默认匹配带release: kube-mon标签的 ServiceMonitor。如果你新建的 ServiceMonitor 没有这个标签operator 根本不会把它纳入采集配置。反过来如果 spec.selector 的 matchLabels 和服务 Service 的标签对不上目标就能被发现但在抓取时全部报 404。解决先检查两层标签用下面的命令看 Service 的标签和 ServiceMonitor 的 speckubectl get svc -n demo-app --show-labels kubectl get servicemonitor -n monitoring demo-app-monitor -o yaml第一层确认 metadata.labels 里带release: kube-mon第二层确认 spec.selector.matchLabels 能匹配到 Service 的 labels。另外确认 Service 的 metrics 端口有名字且名字和 ServiceMonitor endpoints.port 一致。这三处都对上之后Prometheus 会在下一次配置文件重载后出现目标通常不超过一分钟。5.3 坑三Prometheus 内存持续上涨只配 retention 没配 retentionSize现象运行一周后Prometheus Pod 的内存占用稳步增长重启后短暂下降又继续涨最终 OOM Killed。原因指标在内存里按时间序列组织活跃的 series 数量越多内存占用越大。只设置时间维度上的retention当数据量巨大时同一时间窗口内的 block 数量暴增内存的 head 区域来不及刷盘落盘持续给压力。解决在 values 里同时设置retentionSize并且给 Prometheus 设内存 limits。另一个有效手段是降低采集频率把常规监控目标的interval从 15s 改成 30sseries 总量直接减半对绝大多数业务指标来说30s 的粒度足够发现故障。5.4 坑四Grafana 面板时间轴断断续续查询超时现象Grafana 面板数据不是连续的每隔一段时间出现空白刷新后又恢复。频繁刷新时出现query timeout或context deadline exceeded报错。原因core 是 Prometheus 查询超时默认query.timeout只有 2 分钟。当面板查询范围过大或者同时打开多个大范围面板Prometheus 计算不过来。解决把面板默认时间范围缩小到 6 小时以内避免一次性聚合一周的数据。如果业务确实需要长周期视图建议使用 recording rule 预聚合比如把 5 分钟的容器 CPU 使用率预先算好存成新指标查询长周期时直接查这个降采样指标。这是 Prometheus 官方推荐的典型用法比无限加大查询超时更健康。5.5 坑五PVC 容量写太小想扩容时发现存储类不支持在线扩容现象监控数据跑了一个季度Prometheus 报磁盘空间不足。查下来发现是持久卷只有 20 Gi写满了。想通过 values 把 storage 改成 50 Gihelm upgrade 之后卷大小没有任何变化。原因PVC 的容量在创建后能否扩大取决于 StorageClass 是否设置了allowVolumeExpansion。很多本地存储方案默认不支持改 values 只对新建 PVC 生效老卷纹丝不动。解决最好的处理是事前规划起步就给 Prometheus 50 Gi中小团队第一年基本不用动。如果已经写满需要扩容先确认kubectl get storageclass -o yaml里有没有allowVolumeExpansion: true没有的话只能备份 TSDB 数据删掉 PVC 后重建再把数据导回来。这个操作有风险动手前先把 Prometheus 的 block 目录完整打包一份。走完这一步之后你会记住这个教训监控存储宁可给大一点也不要指望后面轻松扩。6. 故障演练用一次真实的 Pod 重启验证告警链路6.1 制造一次告警并跟踪它走完整个链路监控系统上线后最容易出现的问题是仪表盘全绿但告警从来没响过。没人知道是系统正常还是告警链路本身断了。我会主动做一次故障演练来确认链条完整。先找一个测试用的 Deployment给它打上能被守则覆盖到的标签然后在另一个终端同时观察三个位置# 终端 1观察 Prometheus 里这条告警的出现和消除 kubectl -n monitoring port-forward svc/kube-mon-kube-prometh-prometheus 9090 # 打开 http://localhost:9090/alerts 看 DemoAppRestartTooFrequent # 终端 2连续重启测试 Pod kubectl rollout restart deployment/demo-app -n test-app触发条件满足后告警从 Pending 变 Active。此时打开 Alertmanager端口转发到 9093能在页面看到这条告警以及它的分组信息再检查 Webhook 接收端是否收到了 JSON 内容。这个流程能从采集、规则评估、Alertmanager 路由到最终通知一层层验证。演练完用kubectl delete pod删一个副本让负载恢复确认告警在resolve_timeout后自动消除。6.2 监控数据质量三个自检指标故障演练之外我还会定期看三个指标它们直接反映采集链路是否健康。up这个指标为 1 表示目标抓取成功为 0 表示失败。它本身就是所有 exporter 的开关状态汇总配合sum by (job) (up 0)能快速定位哪些任务在丢目标。scrape_samples_scraped这个指标表示每个目标实际采集到的样本数用sum by (job) (scrape_samples_scraped)看趋势如果数值骤降说明目标 Pod 暴露的指标变少了这往往是发布变更导致的。第二个是scrape_duration_seconds如果采集耗时接近设置的 interval说明目标响应慢需要优化。prometheus_tsdb_head_series这个指标反映 Prometheus 当前内存里的活跃序列数量。如果它持续上涨不回落该考虑调整 interval 或者清理不需要的指标。我的习惯是每两周打开一次这三个视图顺手把波动大的 job 截图存下来备查。7. 告别模板把监控的告警阈值当代码一样评审7.1 阈值从哪来用历史数据反推而不是拍脑袋很多团队监控上线后第一反应是照搬社区告警规则但社区规则的阈值是针对通用场景的拿不准就直接抄。我的做法是先用 PromQL 拉出最近两周的数据分布比如容器 CPU 使用率的 P99 是多少再结合业务峰值往里填阈值。告警规则写完后不是一劳永逸每个月要根据误报记录调一次。曾经有一个规则因为阈值开得太大集群跑飞了都没通知后来把阈值调低噪音和漏报之间的平衡才慢慢找回来。7.2 告警规则配置模板日常我用这个模板来写新的规则所有字段都有用途不是为了凑数- alert: ServiceLatencyHigh expr: histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, job)) 2 for: 5m labels: severity: critical team: backend annotations: summary: {{ $labels.job }} 接口 P99 延迟超过 2 秒 runbook: http://your-wiki/runbook/service-latencyfor: 5m的消费是让规则在条件成立持续 5 分钟才触发避免瞬时抖动。runbook注解最有价值收到告警的人能直接点进去看排查手册比写一堆描述更实用。团队里约定每新增一条规则必须附带 runbook 链接。7.3 体验回顾这套部署和调试的习惯我经历了从“装完就完事”到“监控体系真正成为团队的眼睛”的过程。中间翻过车也踩过坑最大的教训是监控的价值不在安装的那一下而在规则能不能准确反映业务故障。希望帮到你。本文还有配套的精品资源点击获取

Prometheus和Grafana在Kubernetes中的部署与告警实践

相关推荐

虚拟电厂调度中的两阶段鲁棒优化：应对光伏与负荷不确定性

C++ ATL Shell扩展实战：为资源管理器添加自定义工具栏

无线网络原理与802.11协议演进：从物理层到WPA3的完整复习指南

更多资讯

深入了解C++函数重载解析策略

智能体手机Agent开发实战：从提示词到API接入的完整指南

用Claude Code零代码建站，免费静态托管上线全流程指南

如何用 Git-AI 工作流解决多智能体并行开发的合并冲突

无标定动态视觉伺服：不依赖标定/速度/深度的机械手闭环控制

GPS-RTK高速公路测量实战：从原理到避坑的完整指南

今日更新

电商智能运营体系从0到1：架构设计、落地步骤与避坑指南

压缩空气储能与热网热惯性联合优化调度：热电联产系统建模与求解

若依框架AI代码生成不稳定？用Agent Skill三层结构+五步法搞定

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？