Claude Code 架构深度解析本篇主要是对这篇文章的解读：Data Structures & The Information Architecture。也是因为最近开发Agent，所以研究了cc的架构和代码设计，cc还是很值得学习和借鉴的。 一、总体架构视角Claude Code 不是一个“聊天工具”，而是一个： 事件驱动 + 流式处理 + 多层抽象的数据系统 核心链路： 1

从0到算子工程师（上）：CUDA & Triton算子实践全路径 因为最近在做信创化改造，涉及到一些适配工作，也就搞起了算子开发的一些工作，这个博客分为两个部分，上篇是依据trition的官方文档实践的基础入门，下篇会涉及到vllm等框架。 整体内容肯定是用AI润色，稍微有点AI风。 另外，最后的效果，我在colab上反复测试，发现trition如果不调优的话，在矩阵乘法的效率上是低于p

企业级大模型运维（LLMOps）架构深度实践：从模型服务到 Agent 评估的全链路平台设计写在前面：这篇文章是目前我这一年实践MLOps/LLMOps的沉淀。虽然目前主要精力还是在微调和agent开发，但是开发的应用越多，越发现平台治理的问题，所以在年底的时候，花了很大的功夫将整个平台做了一次升级和改造。因为涉及的方面比较多，有些就简单带过，有经验的同学应该能明白大体的架构和逻辑。另

深度解析：LangChain 的“回归”之路 —— 为什么我们不再执着于复杂的图结构？引言：消失的“链”与重生的“图”在 LLM 应用开发的短短两年里，开发者经历了从初见 LangChain Chain 模式的惊艳，到面对复杂业务时对其“黑盒”化、线性结构的痛苦，再到 LangChain 官方强推 LangGraph 解决循环问题的狂热。 但最近，社区出现了一种明显的声音：“我们好像又用回 La

构建企业级提示词管理平台：从“硬编码”转向 PromptOps在大型语言模型（LLM）应用的开发过程中，开发者往往会面临“提示词意面（Prompt Spaghetti）”的困境：提示词散落在代码各处、版本管理混乱、缺乏性能监控以及难以进行 A/B 测试。 为了解决这些痛点，开发了一套基于 FastAPI 的提示词管理平台（Prompt Management System）。本文将深度

这篇博客旨在构建一套完整的、可落地的 AI 中台（AI Platform） 架构指南。它结合了微服务架构的解耦思想与大模型（LLM）时代的特殊需求，涵盖了从底层基础设施到上层业务封装的全栈技术路径。 从微服务到 AI 原生：企业级 AI 中台架构全景指南引言：为什么 AI 需要“中台化”？随着大语言模型（LLM）进入应用爆发期，企业在构建 AI 应用时往往面临“烟囱式”开发的困境：每个业务组都在

这是《企业级 AI Agent 平台建设》系列的终结篇。在经历了接入控制、能力标准化和逻辑编排后，我们迎来了平台进入生产环境前的最后一道关卡：监控与治理。 企业级 AI Agent 平台建设指南（四）：监控与治理——建立评估体系与成本中心引言当数十个 Agent 在企业内部上线运行，管理者面临的不再是“能不能用”的问题，而是“好不好用”、“贵不贵”以及“安不安全”。 由于 LLM 的随机性（No

这是《企业级 AI Agent 平台建设》系列的第三篇。在解决了接入（网关层）和资源（能力层）后，我们来到了平台最核心的“逻辑大脑”——编排引擎。 企业级 AI Agent 平台建设指南（三）：工作流编排——从单 Agent 到多 Agent 协作的架构设计引言在简单的问答场景中，直接调用大模型即可满足需求。然而，面对复杂的企业级业务（如：自动生成季度财报并对比去年同期数据），单一的 Promp

这是《企业级 AI Agent 平台建设》系列的第二篇。在上篇中，我们讨论了如何通过“统一网关”控制流量。本篇将聚焦于如何打破企业内部的资源壁垒，将散落在各处的 API 和数据转化为 Agent 可以直接调用的“原子能力”。 企业级 AI Agent 平台建设指南（二）：原子能力池——从异构资源到标准化工具引言如果说 AI 网关是 Agent 平台的“大脑入口”，那么原子能力池 (Atomic

这是一个非常宏大且具有实战价值的课题。在 AI Agent 走向企业级应用的过程中，“从烟囱式开发转向平台化架构”几乎是所有技术团队都会面临的必然选择。 考虑到开题范围很大，这篇技术博客将分为四篇来介绍。今天我们先深入探讨最核心、也是感知最迫切的第一部分：《企业级 AI Agent 平台建设指南（一）：统一 AI 网关的架构与实现》。 这部分内容将重点解决“API 调用乱象”、“私有与公网模型混杂