背景最近 Claude 的 SKILLS 很火，忍不住也来体验了一下，发现确实是有些东西的；但也发现身边的一些同事对这些新出的概念总是很懵逼，所以便有了这篇文章。 从最早的 Function Call，到 MCP 协议，再到如今的 Agent Skills。 本文将从技术演进的角度，带你理解这些概念之间的关系，以及它们如何让 AI 从一个”只会说话的聊天机器人”变成真正能”动手做事”的智能助手。

背景因为最近在基于 RAG 对我们的 code repo 做 AI 分析，其中有一个非常核心的流程就是需要将我们的代码库里的源码进行分割，分割之后会作为 chunk 供 RAG 查询；然后再将查询到的 chunk 提交给 LLM 做分析。

原文链接：https://github.com/sweepai/sweep/blob/main/docs/pages/blogs/chunking-2m-files.mdx 最近在研究 Code Splitter 的算法，发现 llama_index 的代码分割使用的是 sweepai 的代码分割算法，同时还提供了一篇博客，也就有了这篇文章。

上一篇文章：大模型应用开发必需了解的基本概念 分享了关于 LLM 大模型应用开发的一些基础知识，本文乘热打铁，借助一个真实的大模型应用来分析下其中的流程 deepwiki 介绍这里我们还是以 deepwiki-open为例进行分析。 通过这个截图可以知道它的主要功能：一键把任意 GitHub/GitLab/Bitbucket 仓库生成“可浏览的交互式 Wiki” 支持 RA

背景AI/LLM 大模型最近几年毋庸置疑的是热度第一，虽然我日常一直在用 AI 提效，但真正使用大模型做一个应用的机会还是少。 最近正好有这么个机会，需要将公司内部的代码 repo 转换为一个 wiki，同时还可以基于项目内容进行对话了解更具体的内容。 实际效果大概和上半年很火的 deepwiki 类似。 而我们是想基于开源的 deepwiki-open进行开发，提供的功能都是类似的。

最近在做持续剖析 Profile 与链路系统打通的工作，就查到了 grafana 在 24 年初写的这篇文章；觉得比较有参考意义，在这里分享给大家。 原文链接：https://grafana.com/blog/2024/02/06/combining-tracing-and-profiling-for-enhanced-observability-introducing-span-profil

StarRocks 监控中有一个很关键的指标，就是针对慢 SQL 的监控。 在 StarRocks 中审计日志记录了所有用户的查询和连接信息，理论上我们只需要对这些日志进行分析就可以得到相关的慢 SQL，高 CPU、高内存的 SQL 信息。 类似于这样的监控界面：

背景前段时间我在实现 StarRocks 的一个关于资源限制的特性，由于该功能需要基于最新的 3.5 tag 进行开发，所以我需要需要从 3.5 的 tag 里拉出一个分支（3.5-feature）开发完成后再向上游的 main 分支提交 PR。

背景 前段时间有朋友问我关于 spring cloud 的应用在调用到 Go 的 API 之后出现 Trace 没有串联起来的问题。 完整的调用流程如下： 123456789101112131415┌──────┐ │Client│ └┬─────┘ ┌▽──────────────────┐│SpringCloud Gate

之前写过一篇 StarRocks 开发环境搭建踩坑指北之存算分离篇讲解如何在本地搭建一个可以 debug 的存算分离版本。 但最近在本地调试一个场景，需要 CN 节点是以集群的方式启动，我还是按照老方法通过 docker 启动 CN，然后 export 端口的方式让 FE 进行绑定。 比如用以下两个命令可以启动两个 CN 节点。 1docker run -p 9060:9060 -p 8040:8