每周文摘 06222025
采用 AAC 后，开发范式会发生转变，开发者的角色从以「写代码」为主，慢慢转向「设计架构、分解任务、优化 Prompt、Review 代码」。越早适应这种转变，强迫自己提升对应的能力，越能取得优势。
非常好的文章，之前我和不同聊的时候提过一个观点，目前其实对于写代码不是要求变低了，而是趋向更高了，这里高了的意思其实指的是上面这个意思，同时也是说低级编码会越来越没空间。
这些框架通过简化调用 LLM、定义/解析工具以及串联多次调用等标准底层操作，使开发者可以更轻松地入门。但它们往往也会增加额外的抽象层，可能掩盖底层提示与回复，从而导致调试难度上升。此外，这些框架也可能让你陷入一种“添砖加瓦”的诱惑：在一个简单的设置就够用的情况下，去增加不必要的复杂性。
因此，我们建议开发者先直接使用 LLM API：很多模式只需几行代码就可以实现。如果使用框架，一定要了解其底层代码的逻辑。对于底层实现存在错误假设，是导致客户出错的常见原因。
是的，非必要不要用封装好的框架，有助于调试问题也有助于了解整个工作机制。
总的来说我今年的感觉是：
- Kubernetes 已经成为一个相当成熟的基座，任何可以在 K8s 上跑的东西最终都会被搬到 K8s 上跑 （
AI 让 CloudNative 社区焕发了新生，围绕 AI 在过去两年间涌现了许多新的 CloudNative 项目。AI 话题已经成为了 KubeCon 绝对的主旋律。
- AI 部署部分主要在讨论 AI 推理，关键技术点：分布式推理、扩缩容与 LLM-Aware 的负载均衡以及 AI 模型分发
- AIOps 也有好几个讨论，简单的用法就是 ChatBot，复杂点的会尝试使用 Multi-Agent 完成更复杂的任务（比如云成本分析优化）。
- 快手尝试在超大规模集群中利用 Logs/Metrcis 为每个服务训练一个模型用于动态调整 HPA，实现 SLA 与成本的平衡（如果我记错了概不负责 hhh）。
OpenTelemetry 日渐成熟，已经很接近它统一 Logs/Traces/Metrics 三大 Signals 的目标了。
- 目前已经出现了 Uptrace 之类的大一统观测平台，充分利用了 OTel 的标签来关联 Logs/Traces.
- 当前的最佳实践是，在 Infra 层面仍然使用传统方式采集 Logs 与 Metrics，而在 APP 层面则改由 OTel 统一采集所有 Logs, Traces 与 Metrics，OTel 会通过 Span ID 把这些数据关联起来， 而且标签语义完全一致。
- WASM 仍在探寻自己的应用场景，今年介绍的场景主要是在边缘侧跑小模型。
说的 OpenTelemetry，有兴趣，需要好好的了解一下，看看如何在发展，其他部分其实不是围绕 K8s 本身，K8s 本身我看着能力其实没啥大的发展，而且对于 K8s 目前其实有很多不同的声音，资源的过度占用以及运维复杂度。
Andrej Karpathy: Software Is Changing (Again)
微信上的总结文章，是个很好的补充：前特斯拉 AI 负责人：随着 FSD 越来越好，神经网络同时也“吞噬”了自动驾驶的软件栈...
还在琢磨中，到底后面自己能干点啥，围绕 AI/LLM?
评论已关闭