本文探讨了大模型智能体中上下文技术的本质与优化方法。文章指出，上下文技术本质上是动态管理输入模型信息的手段，旨在解决模型token窗口限制带来的成本、延迟和性能问题。核心在于信息存储、检索和整合三大支柱，目前尚无标准范式，需结合具体业务场景设计。优化手段包括信息分块、滑动窗口、向量检索、摘要压缩等技术。作者强调，真正的解决方案在于任务分解与分阶段构建上下文，而非试图突破token物理限制。本文澄清

大家知道，nexus3只有收费版才有高可用。这里，我做了一个oss版的高可用版本。部署是在k8s（k3s）里面，通过helm charts部署。基本逻辑是：1、首次启动后，0号StatefulSet POD作为主，其他作为从2、从POD监控主POD，并且通过rsync从主POD同步数据3、当主POD挂掉，从POD通过一个健康度监测算法，以最小号的POD作为主启动，其他从POD重新从新的主POD同步

有时候我们需要从一个环境中，把当前的Helm-Charts、对应docker镜像文件，甚至有一些通过其他手段搞出来的POD的yaml导出来，然后在另一个环境中使用这里面就是一些我们自己用到的工具，分享出来，自愿使用或修改。有问题不负责 ^_^。所有内容都在https://github.com/wangxi83/migration_util1-导出镜像File: ./save-images-to-t

参考我的这篇文章我们可以知道，通过在K3S中设置L4负载均衡，能够轻松的开放主机端口访问。如果我们的目标是修改默认端口，以及配置Ingress的话，那么已经很好用了。但是，Ingress这种资源，由于被K3S整体接管，因此，Traefik作为IngressController的话（注意噢，这里我着重说的是作为IngressController），无论你新开多少个端口，你基本上都无法做到让某个端口独

前言我们在部署服务的时候，有很多服务是master-slave模式，这些服务可能有自己的故障切换逻辑。我们知道，我们可以通过一个负载均衡器能够指向master服务，当故障发生的时候，在slave切换到master以后，负载均衡也能能切换到新的master上面。但是，这无疑会增加部署成本那么，在K8S（或K3S）里面怎么最低成本的实现呢？假设我有一个服务叫“OrgManager”服务，这是一个典型的

K3S Helm 高可用安装 rancher 修改80和443端口（k8s同理）请注意，本文是基于默认K3S安装了Traefik的基础上来写的。如果是使用自定义的IngressController，仅作参考，不过也具备参考意义。某些时候，我们需要修改rancher的默认端口。如果是单机安装，直接docker的-p就可以解决，因为这个时候，docker容器直接接管了流量。但是高可用部署，由于是部署在

1、常规操作由于k3s证书的默认过期时间是12个月，因此到期之前或不小心到期，需要轮换其实官网有明确的说明以及处理办法——但是你会发现按照官方处理办法，基本上无法生效这里给一个一定可行的办法# 在其中一个节点上执行k3s kubectl --insecure-skip-tls-verify=true delete secret k3s-serving -n kube-system# 在每个节点上执