SSE详解
什么是 SSE？SSE（Server-Sent Events，服务器推送事件）是一种基于 HTTP 协议的服务器向客户端单向推送数据的技术。与 WebSocket 的双向通信不同，SSE 只允许服务器向客户端发送消息，但它的实现更加简单，天然支持断线重连和事件 ID 追踪，非常适合实时通知、新闻推送、AI 流式输出等场景。 SSE vs WebSocket vs 轮询在介绍 SSE 之前，我们先对比一下常见的实时通信方案： 特性 轮询（Polling） SSE WebSocket 通信方向 客户端→服务器 服务器→客户端 双向 协议 HTTP HTTP WS/WSS 断线重连 需手动实现 内置自动重连 需手动实现 实现复杂度 低 低 中 浏览器兼容性 全部 现代浏览器 现代浏览器 数据格式 JSON/XML 纯文本 任意二进制/文本 连接开销 每次请求新建连接 长连接 长连接（握手较重） 轮询的问题在于客户端需要不断发起请求询问”有新数据吗”，大量请求在没有新数据时白白浪费带宽和服务器资源。 WebSock...
RAG 工程实践：让大模型基于证据回答
RAG 到底在解决什么问题RAG 是 Retrieval-Augmented Generation 的缩写，中文通常译为“检索增强生成”。如果只用一句话解释，它不是一种模型，而是一种让大模型回答问题之前先查资料的系统架构。 大语言模型本身像一个压缩过的知识系统：它在训练阶段见过大量文本，因此可以生成流畅、连贯、看似有逻辑的回答。但模型参数里的知识并不等于业务事实。它有几个天然限制： 知识会过期：模型训练完成后，后续发生的新政策、新版本、新故障、新业务规则，它并不会自动知道。 私有知识不可见：公司内部文档、项目接口说明、客户工单、数据库字段含义、测试用例规范，并不会出现在通用模型训练集中。 事实不可追溯：模型直接回答时，很难判断某个结论来自哪里，是否有证据支撑。 不确定时仍会生成：模型的目标是续写最可能的文本，不是天然保证每句话都被事实验证。 RAG 的核心思路就是把“回答问题”拆成两个动作：先检索，再生成。系统先从外部知识库中找到与问题相关的资料，再把这些资料作为上下文交给大模型，让模型基于证据组织答案。 所以，RAG 的价值并不是让模型变得“更聪明”，而是让模型回答时有可用...
Claude Code 命令大全：分类速查与使用指南
Claude Code 提供了几十个内置命令，覆盖从会话管理到代码审查、从项目初始化到远程控制的方方面面。输入 / 即可查看所有可用命令。 本文将所有命令按用途分组，方便快速查找。 会话管理 命令 说明 /clear [name] 清空对话历史，开始新会话。之前的会话可通过 /resume 恢复。传参可为之前的对话命名 /resume [session] 按 ID 或名称恢复历史对话。不传参时打开交互选择器 /branch [name] 在当前对话处创建分支，切换到新分支的同时保留原对话，可用 /resume 返回 /rename [name] 重命名当前会话。不传参时从对话历史自动生成名称 /recap 生成当前会话的简短摘要。用于快速回顾 /export [filename] 导出当前对话为纯文本。指定文件名直接写入，否则弹出保存对话框 /compact [instructions] 将对话压缩总结，释放上下文窗口空间。可传参指定聚焦内容 /exit 退出 Claude Code 任务执行与工作流 命令 说明 /plan [...
Claude Code 状态行自定义指南：让终端信息一目了然
为什么要折腾状态行？如果你用过 Claude Code，应该注意到终端底部有一条灰色栏——那就是状态行（Status Line）。默认情况下它只显示模型名称和一些基本信息，但这条栏其实是一个完全可编程的信息面板。 你可以让它显示： 上下文窗口用了多少（百分比 + 进度条） 当前会话花了多少钱 Git 分支和文件修改状态 会话运行了多久 甚至任意自定义信息 这些数据是实时刷新的，每次交互后自动更新。对于重度用户来说，把关键信息放在眼前比频繁敲命令查状态要高效得多。 配置方式：两条路方案一：用 /statusline 命令这是最简单的方式。直接在对话中输入： 1/statusline 显示模型名称、上下文使用百分比和进度条 Claude Code 会自动在 ~/.claude/ 目录下生成脚本文件并更新配置。你不需要手写任何代码。 方案二：手动配置手动配置的核心是在 ~/.claude/settings.json 中添加 statusLine 字段： 1234567{ "statusLine": { "type"...
应用开发视角的 Transformer 架构：从 Self-Attention 到 Decoder-Only
为什么应用开发也要懂 Transformer？不管你投什么岗位，面试官都可能问一句：你了解 Transformer 吗？ 很多人的第一反应是：我又不训练模型，Transformer 和我有什么关系？ 确实有关系。你日常开发中遇到的这些问题，答案全在 Transformer 架构里： Token 怎么计费的？为什么一次交互消耗几万 Token？ 上下文窗口为什么有上限？GPT-4 是 128K，Claude 是 200K，为什么不能无限长？ 为什么模型会”忘记”前面的内容？长对话到后面，模型对开头的信息越来越模糊。 为什么结构化 Prompt 比大段文字效果好？ 不了解 Transformer，你只能靠经验去试；了解了，你就能从原理出发去推。 Transformer 之前的困境Transformer 之前，主流架构是 RNN 和 CNN，它们各有各的致命伤。 RNN（循环神经网络） 有两个核心问题： 梯度消失：序列越长，前面的信息传到后面就越弱。处理 1000 个 Token 时，第 1 个 Token 的梯度信号到第 1000 步基本就没了。这就是为什么 RNN 记不住长距...
2026 年 AI Agent 生态全景与未来展望
引言：2026 年，Agent 进入深水区如果 2024 年是 AI Agent 的概念验证年，2025 年是工程化探索年，那么 2026 年就是 Agent 全面走向生产的一年。从年初各大云厂商密集发布 Agent 相关产品，到企业的客服系统、数据分析平台、代码仓库中大量部署智能 Agent，我们正在见证一个关键转折点：Agent 不再只是技术博客和 Hackathon 中的演示项目，而是真正开始创造商业价值的工程系统。 本文将系统梳理 2026 年 AI Agent 生态的全景图，涵盖编排框架、开发工具、基础设施、部署平台、企业采用、标准化运动，并展望到 2027 年的关键趋势。 编排框架：Agent 的”操作系统”Agent 编排框架是 2026 年生态中最活跃的一层。它们提供 Agent 的状态管理、工具集成、多 Agent 协作等能力。以下是当前主流的几个框架及其定位： LangGraphLangChain 团队推出的有状态 Agent 框架，基于有向图定义 Agent 的控制流。LangGraph 的核心抽象是 StateGraph——你将 Agent 的各个节点（L...
LLM 应用的可观测性：监控、追踪与评估
LLM 可观测性的独特挑战传统的软件监控关注的是 CPU、内存、响应延迟和错误率等相对确定的指标。LLM 应用的可观测性则面临着截然不同的挑战：输出是非确定性的——同样的输入你永远无法期待完全相同的输出；质量是多维度的——准确性、相关性、安全性、公平性、格式合规性，每一个维度都可能出问题；链条是长的——一条用户请求可能经过 Prompt 模板渲染、LLM API 调用、多个 Function Call、RAG 检索、再聚合，任何一个环节的偏差都可能导致最终输出的失败。这意味着我们需要重新定义”系统正常工作”的含义。 可观测性三支柱：追踪、指标与日志经典的可观测性三支柱在 LLM 场景下同样适用，但内涵有所扩展。**追踪（Tracing）**记录一次用户请求从入口到最终响应的完整路径，对于 LLM 应用而言，追踪不仅需要覆盖 LLM API 调用本身，还要覆盖检索增强生成（RAG）中的文档检索、工具调用（Function Calling）、多步推理链（Chain/Agent）等环节。**指标（Metrics）**提供聚合层面的系统健康状态，核心指标包括 TTFT（首 To...
Hello World
Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post1$ hexo new "My New Post" More info: Writing Run server1$ hexo server More info: Server Generate static files1$ hexo generate More info: Generating Deploy to remote sites1$ hexo deploy More info: Deployment
MCP 与 LangChain 集成：构建企业级 AI 应用
引言随着 AI 应用从实验性原型走向企业级部署，对架构的可靠性、安全性、可观测性提出了更高要求。MCP 提供了标准化的工具集成协议，LangChain/LangGraph 提供了成熟的 AI 编排框架——两者的结合，为构建企业级 AI 应用铺平了道路。 为什么 MCP 对企业 AI 至关重要企业环境中的 AI 应用面临独特的挑战： 异构系统集成：企业通常拥有数十甚至上百个内部系统（数据库、CRM、ERP、OA、文件服务器），每个系统都有独特的接口。 安全合规：数据访问需要细粒度的权限控制，所有操作必须可审计。 供应商中立：避免被单一 AI 供应商锁定，需要支持多模型切换。 可维护性：几十个团队并行开发 AI 能力，需要统一的集成标准。 MCP 恰好解决了这些痛点：它将「如何连接系统」与「如何使用系统」解耦，让企业可以建立统一的能力层。 MCP Adapter：桥接 MCP 与 LangChainLangChain 通过 MCPToolkit 或自定义适配器将 MCP 工具映射为 LangChain 的 BaseTool，实现无缝集成。 123456789101112...
Chain-of-Thought 与推理优化：让 LLM 学会思考
什么是 Chain-of-ThoughtChain-of-Thought（CoT，思维链）是一类通过引导模型展示中间推理步骤来提升复杂任务表现的技术。其核心洞见是：很多问题不是一步到位的——从问题到正确答案，中间需要经历若干推理步骤。如果模型直接跳到答案，出错率很高；但如果模型在输出答案之前，先逐步展示它是如何推导出这个答案的，准确率就会大幅提升。 CoT 的工作机制可以从几个角度理解：第一，它将一个复杂的推理问题分解为一系列更简单的子步骤，每一步的推理难度被降低；第二，它迫使模型”显式思考”——在生成答案 token 之前，模型已经通过中间步骤为正确答案铺好了概率路径；第三，中间步骤为最终答案提供了”自我验证”——如果推理过程自洽且合理，最终的答案也更可能是正确的。 CoT 在数学问题求解、逻辑推理、代码调试、多步骤规划和需要复杂因果推断的任务中效果最为显著。研究表明，对于需要多步推理的任务，CoT 可以将准确率提升 20% 到 50% 不等。 零样本 CoT：一句话的魔力零样本 CoT（Zero-shot CoT）是最简单的推理增强技术，只需要在提示词末尾加上一句：”让我们一...