53 篇博文 含有标签「Engineering」

本文是 AI Agent 技能拆解系列的一篇。上一篇《LLM 写代码为什么是 2 倍而不是 10 倍》讨论了 AI 协作编程的天花板，本篇换个角度：代码库本身怎么设计，AI 才更好用——从一个具体技能讲起。

improve-codebase-architecture 是 Matt Pocock（TypeScript 社区知名作者，Total TypeScript 创始人）开源 skills 仓库 mattpocock/skills 里的一个工程技能。它做的事可以概括成一句话：

扫描代码库找「加深机会」（deepening opportunities），把浅模块改造成深模块，并以可视化 HTML 报告呈现，然后和你逐条深挖。

这不是又一个"找代码异味"的 Lint 工具。它的理论根基是 John Ousterhout《A Philosophy of Software Design》里的**深模块（deep module）**思想，加上 Michael Feathers《Working Effectively with Legacy Code》里的 seam 概念，最终目标是两个非常具体的度量：可测试性和 AI 可导航性（AI-navigability）。

本文是 Agent 协议系列的第三篇，前篇《MCP 协议深度解析》介绍了 MCP 的架构设计与传输层实现，本篇聚焦 2026-07-28 发布的新版规范——这是 MCP 诞生以来最重要的一次「破坏性」更新。

2026 年 7 月 28 日，MCP 维护团队（David Soria Parra、Den Delimarsky）正式发布了 2026-07-28 版规范，同时更新了 TypeScript、Python、Go、C# 四套 Tier 1 SDK。用团队自己的话说，这是「自远程 MCP 发布一年多以来最重要的一次版本」。

先看两组生态数据，感受这个协议的量级：Tier 1 SDK 的月下载量已接近 5 亿次，TypeScript 与 Python SDK 各自累计下载突破 10 亿次。当一个协议以这种规模被生产环境依赖时，它的每一次演进都必须为「规模化部署」而设计——这正是本次更新的主线：MCP 正在从一个双向有状态的流式协议，变成一个请求/响应式的无状态协议。

2026 年 7 月底，两篇关于 AI 编程的文章先后登上 Hacker News 首页：一篇是独立开发者 obryant 的《2x, not 10x: coding with LLMs in 2026》（214 分），另一篇是 Thoughtworks CTO Giles Edwards-Alexander 在 Martin Fowler 博客发表的《The Economic Benefit of Refactoring》（194 分）。

两篇文章放在一起读，恰好构成了 2026 年 AI 编程最完整的一幅现实图景：模型能力已经跨过「可用」门槛，但生产力红利的上限不是模型智商，而是工程系统——代码组织、反馈回路、工具链——的匹配度。 本文梳理两篇的论点，并用 Thoughtworks 实验中的真实数据，量化「重构 = 投资」的 Token 经济学。

2026 年 7 月 31 日凌晨，OpenAI 发布公告《Advancing the price-performance frontier with GPT‑5.6》，正式推出 GPT-5.6 系列模型，并在 Hacker News 上引发热议（发布数小时内即获 500+ 分）。公告的核心信息只有一句话：GPT-5.6 Luna——最快的模型，也是最便宜的模型——价格直降 80%。

这不是一次普通的版本迭代。在 Kimi-K3（2.8T 开源 MoE）、GLM 5.2、DeepSeek V4 轮番降价的开源围剿下，OpenAI 选择用「推理效率工程」而非「削减利润」来回应。本文从工程角度拆解这次降价的技术逻辑、成本结构，以及对推理基础设施团队的启示。

本文是 Agent 工程系列的综合篇。前文分别探讨了 Agent 推理与执行分离 和 Agent 安全防护（ToolGuardian），本篇从可观测性、安全管控与错误恢复三个维度，系统梳理生产级 Agent 系统的工程实践。

2025-2026 年，AI Agent 从「Demo 阶段」迈入「生产阶段」。Gartner 的 2026 年 Hype Cycle 报告将 Agentic AI 定位在「泡沫破裂前的过热期」——这意味着大量系统正在实际生产环境中运行，相关的工程教训也在加速积累。

本文不讨论 Agent 的理论架构，而是聚焦于三个工程问题：怎么知道 Agent 在做什么？怎么确保它不会做不该做的事？当它失败时怎么恢复？

本文是推理优化系列的第二篇。前篇《vLLM 架构深度解析》从推理引擎层面探讨了性能优化，本篇聚焦另一个关键维度——模型量化。

2025-2026 年，量化技术从「部署技巧」演变为「训练流程的一等公民」。FP8 被 Blackwell GPU 原生支持，INT4 通过 AWQ/GPTQ 等算法几乎追平 FP16 的准确率，而 KV-cache 量化更是成为长上下文推理的标配。

本文从工程实现角度，系统梳理 LLM 量化的核心概念、主流方案的生产级对比，以及关键陷阱。

大模型推理的内存需求正在走向一个矛盾：MoE 模型的参数量动辄数百亿甚至上千亿，但消费级硬件的 RAM 上限在过去五年几乎没有质变——一张显卡 24GB，一台笔记本电脑 32GB，已是多数工程师的日常。

2026 年 7 月，一位机械工程背景的开发者（HN: LozzKappa）用约 50 行 C++ 代码，以一套来自控制理论的直觉，将 gpt-oss:120b MoE 模型的内存占用从 58.5GB 压到了 19.1GB，输出与全量加载完全一致（SHA-256 验证）。这项技术被命名为 HotPin。

本文将从工程实现的角度，拆解 HotPin 的核心原理、边界条件与适用场景。

LLM 推理的性能瓶颈早已不只在 GPU 算力上。当模型权重达到数百 GB、上下文窗口突破百万 token、服务需要弹性扩缩时，存储 I/O 就是那条被低估的瓶颈。

本文是 AI Infra 系列的实战篇，前篇《AI Infra 到底是什么》梳理了 AI 基础设施的四层架构，本文聚焦推理层最核心的开源项目——vLLM。

前言：为什么 vLLM 是推理引擎的标杆​

大模型推理引擎有很多：TGI（HuggingFace）、TensorRT-LLM（NVIDIA）、SGLang、CTranslate2……但在开源社区中，vLLM 是目前最流行、生态最好的通用推理引擎。

它解决了 LLM 推理中三个核心痛点：

1. 显存浪费：传统方案 KV Cache 需要预分配最大序列长度，实际序列通常短得多，造成高达 60-80% 的显存浪费
2. 吞吐量低：静态批处理无法动态管理请求，GPU 利用率难以提高
3. 调度僵化：不支持抢占、不可用请求灵活排队

vLLM 凭借 PagedAttention 和 Continuous Batching 两项核心技术，在上述三个维度都实现了数量级的提升。

本文是 Agent 协议系列的第二篇，前篇《Function Calling 诞生的背景》探讨了函数调用能力的起源，本篇聚焦更通用的协议层——MCP。

为什么需要 MCP？​

Function Calling 解决了「LLM 如何调用外部函数」的问题，但它有一个根本性局限：每个模型厂商的函数定义格式不同。OpenAI 有 tools 参数，Anthropic 用 tools 但 schema 略有差异，Google Gemini 用 tools / tool_config，Llama 系列模型需要特定的 prompt 模板。

这意味着你的工具代码需要为每个模型写一个适配层。更麻烦的是，工具本身的注册、发现、安全策略并没有一个统一的标准——每个 Agent 框架都在自己造轮子。

MCP（Model Context Protocol） 就是来解决这个问题的。它由 Anthropic 提出，本质上是一个通用的、模型无关的上下文与工具交互协议，定义了 LLM 应用与外部工具/数据源之间的标准通信方式。