Kubernetes 里管“该开几个副本”和“每个副本该给多少 CPU/内存”的其实是好几套独立工具：HPA 按 CPU 百分比增减副本，VPA 按历史用量调整资源申请，KEDA 按 Kafka 队列积压决定副本数，Karpenter 按声明资源申请新机器。问题是它们各自跑各自的循环，看到的都是局部信息，还同时改同一批配置字段。比如 VPA 把 CPU 申请调小，HPA 的分母就跟着变小，同样的流量会被算成利用率超高，于是猛加副本，结果副本越来越多、每个越来越小，互相把对方越推越远；KEDA 加副本、HPA 又按低 CPU 减回来；GitOps 看到副本数和 Git 不一致还会把它改回去。作者认为水平和垂直扩缩本来就是一道联立方程，应该由一个统一控制面同时看 CPU、队列、延迟、节点价格和 Git 配置，一起给出副本数和资源申请。文中也提到生产集群 CPU 平均利用率只有约 8%，但这些方案的落地细节和可用性文中没有说明。
文中可用工具
- HPA根据 CPU 等运行时指标增减 Pod 副本数
- VPA根据历史用量调整容器的 CPU/内存申请
- KEDA根据 Kafka 等外部事件源的队列积压决定副本数
- Karpenter为 Pending 的 Pod 按声明资源申请节点
- Cluster Autoscaler在有 Pod 无法调度时扩缩节点池
- Argo CD按 Git 仓库内容同步集群状态并检测漂移
- FluxGitOps 工具，按版本控制强制集群基线状态
- Helm用 values 声明副本数和资源规格
展开详情收起详情：为什么 Kubernetes 自动扩缩容器会互相打架（以及为什么解决方案必须是自主的）⌄
The New Stack
原文发布：2026-10-24 21:00收录：2026-10-25
这篇文章讨论的是：当 AI 编程智能体让代码提交量暴增时，团队的交付系统会卡在哪里。作者提到 Anthropic 的代码合并量从 5 月每天约 2500 个涨到 9 月每天超过 3 万个，写代码不再是瓶颈，瓶颈变成了为人类速度设计的开发基础设施。文章用控制回路打比方：意图是目标值，智能体是控制器，验证就是传感器；控制器再快，如果传感器跟不上，它只会拿着过时信息反复重试，把本该被拦下的问题发布出去。作者提出传感器要具备三个特性：延迟（多久能出结果）、保真度（多接近真实系统）、带宽（能同时验证多少个改动），并用 StrongDM 的数字孪生宇宙举例说明保真度为什么最贵。对读者的用处是：如果你在规划智能体编程流水线，这篇文章提醒你先投资验证能力，而不是只堆智能体数量。文章是观点分析，未说明具体产品发布时间或可用状态。
文中可用工具
- Anthropic原文引用其代码合并数据作为案例，并讨论其智能体编程实践
- Digital Twin UniverseStrongDM 用来克隆第三方依赖行为、让智能体跑大量场景的验证环境
- CI持续集成，原文讨论在大量改动并发合并时它意味着什么
展开详情收起详情：构建智能体软件工厂？从传感器开始⌄
The New Stack
原文发布：2026-10-24 22:00收录：2026-10-25
Google 把 Data Agent Kit 正式开放使用了。这是一套免费工具，包含 MCP 工具和 37 个开源技能，能让写代码的 AI 助手直接连接 Google 数据云的 15 种以上服务。它带了两道护栏，但作用不一样：一道是写在技能里的提示，让 AI 助手自己停下；另一道是 IAM 拒绝策略，在权限层面直接拦掉请求，AI 助手想绕也绕不过。对使用者来说，这意味着能连的服务变多，但需要分清两种护栏的强弱，不能把提示当成硬性限制。
文中可用工具
- Data Agent Kit连接 AI 编程助手与 Google 数据云服务的免费工具集
- MCP让 AI 助手调用外部工具和数据的标准协议
- IAM deny policy在权限层直接拒绝请求的硬性护栏
展开详情收起详情：Google Data Agent Kit 正式发布，将 Agent 护栏拆分到技能与 IAM 两层⌄
InfoQ Architecture & Design
原文发布：2026-10-24 16:34收录：2026-10-25