Shadow Walker | 松烟阁修改

2025-11-30 20:40:41

引子

从工程师的视角来观察，随着Scaling Law失效问题被更多的人提起，我越来越认同LLM正在逐渐进入「精打细算，收割果实的平庸时代」。Andrew Ng在他的感恩节给读者的来信中提到，AI可能存在泡沫但是一定不是在AI应用开发：

• AI 应用层： 投资不足。其潜力远超大多数人的认知。
• AI 推理基础设施： 仍需大量投资。
• AI 模型训练基础设施： 我对这一领域仍持谨慎乐观态度，但可能存在泡沫。

1. 大模型推理的物理瓶颈：透视KV Cache

在探讨具体的优化技术之前，必须从第一性原理出发，理解为何KV Cache会成为大模型推理的阿喀琉斯之踵。这不仅是显存容量的问题，更是显存带宽（Memory Bandwidth）与计算强度（Arithmetic Intensity）之间矛盾的体现。

1.1 Transformer解码的自回归特性

Transformer模型的推理过程分为两个阶段：预填充（Prefill）和解码（Decoding）。

1. 预填充阶段（Prefill）：模型并行处理输入的所有token。由于可以并行计算，这一阶段主要受限于GPU的计算能力（Compute-bound）。此时，GPU的利用率通常很高。
2. 解码阶段（Decoding）：模型逐个生成后续token。这是一个自回归（Autoregressive）过程，即生成第 $t$ 个token需要依赖于前 $t-1$ 个token的内部状态。

在标准的注意力机制（Self-Attention）中，计算公式为：

$$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$$
其中，$Q$（Query）是当前时间步的查询向量，而 $K$（Key）和 $V$（Value）则包含了所有历史token的信息。为了避免在生成每一个新token时都重新计算前面所有token的 $K$ 和 $V$ 投影，系统会将这些计算好的向量存储在显存中，这就是 KV Cache。

1.2 显存占用的数学推导

KV Cache的显存占用量是序列长度的线性函数，且随层数、头数和隐藏层维度倍增。对于一个标准的Transformer模型，其KV Cache的大小可以通过以下公式精确计算：

$$ \text{Size}{KV} = 2 \times L{seq} \times B_{batch} \times N_{layers} \times H_{heads} \times D_{head} \times P_{prec} $$

其中：

• $2$：代表Key和Value两个矩阵。
• $L_{seq}$：当前的序列长度（上下文窗口大小）。
• $B_{batch}$：并发请求的批处理大小（Batch Size）。
• $N_{layers}$：Transformer的层数。
• $H_{heads}$：注意力头的数量。
• $D_{head}$：每个注意力头的维度（通常为 $D_{model} / H_{heads}$）。
• $P_{prec}$：数据精度（FP16为2字节，FP32为4字节）。

案例分析：Llama-2 70B模型
假设我们使用FP16精度（2字节），序列长度为4096，Batch Size为1。

• $N_{layers} = 80$
• $H_{heads} = 64$ (GQA之前)
• $D_{head} = 128$

单次请求的KV Cache大小为：

$$2 \times 4096 \times 1 \times 80 \times 64 \times 128 \times 2 \approx 10.7 \text{ GB}$$
如果我们将上下文扩展到100k tokens（如Claude或GPT-4 Turbo常见场景），单次请求的KV Cache将膨胀至 260 GB。这已经远远超过了单张NVIDIA A100 (80GB) 甚至 H100 (80GB) 的显存容量。这意味着，在长文本场景下，显存容量直接限制了Batch Size，导致GPU的算力无法被填满，推理成本急剧上升。

1.3 内存墙与带宽瓶颈

除了容量限制，更致命的是带宽限制。在解码阶段，每生成一个token，GPU都需要从高带宽内存（HBM）中读取整个KV Cache到片上SRAM进行计算。

• 计算量（FLOPs）：随着KV Cache的增长，计算量仅线性增长。
• 数据传输量（Bytes）：数据传输量也线性增长，但由于矩阵乘法中的一维退化为向量（Query vector），算术强度（Arithmetic Intensity，即FLOPs/Bytes比率）极低。

现代GPU（如H100）具有极高的算力（~1000 TFLOPS FP16）和极高的带宽（~3.35 TB/s）。然而，在解码阶段，由于每次矩阵向量乘法（GEMV）都需要搬运庞大的KV Cache，GPU大部分时间都在等待数据从HBM传输，导致计算单元闲置。这就是所谓的“内存受限”（Memory-bound）场景。

为了缓解这一问题，业界在过去两年中经历了从算法架构改革到系统工程优化的剧烈演变。

2. 注意力机制的架构演进：从MHA到MLA

为了从根本上减小KV Cache的体积，模型架构师们对Transformer的核心——注意力机制进行了多次手术。这一演进路径清晰地展示了从追求极致性能到追求效率与性能平衡的过程。

2.1 多头注意力（MHA）：昂贵的基准

在《Attention Is All You Need》原论文中提出的多头注意力（Multi-Head Attention, MHA）机制中，模型拥有 $H$ 个查询头（Query Heads），同时也对应拥有 $H$ 个键值头（Key/Value Heads）。

• 机制：每个Query Head都有自己独立的Key和Value投影矩阵。这意味着模型可以从 $H$ 个不同的子空间（Subspaces）捕捉信息，理论上表达能力最强。
• 代价：正如第1节中的计算所示，KV Cache的大小与头数 $H$ 成正比。对于大模型，这意味着巨大的显存开销。
• 现状：早期的BERT、GPT-2、GPT-3以及Llama-1均采用MHA。但在长上下文时代，MHA已成为不可承受之重。

2.2 多查询注意力（MQA）：激进的压缩

为了解决推理性价比问题，Noam Shazeer在2019年提出了多查询注意力（Multi-Query Attention, MQA）。

• 机制：无论有多少个Query Heads，整个层只保留1个 Key Head 和 1个 Value Head。所有的Query Heads共享这唯一的KV对。
• 压缩比：$H : 1$。如果模型有64个头，KV Cache的大小直接缩小64倍。
• 优势：极大地减少了显存占用和数据搬运量，使得推理速度显著提升，且能支持更大的Batch Size。
• 劣势：这种压缩过于激进，导致模型在处理复杂任务时，无法同时关注输入序列的不同方面，造成性能（Perplexity）下降和训练不稳定性。
• 应用：Google的PaLM模型和Falcon系列采用了MQA，但在开源社区并未立刻成为主流。

2.3 分组查询注意力（GQA）：中庸之道的胜利

在Llama-2发布时，Meta引入了分组查询注意力（Grouped-Query Attention, GQA），这一机制迅速成为当今开源大模型（如Llama-3, Mistral, Qwen）的实际标准。

• 机制：GQA是MHA和MQA的折中方案。它将Query Heads分为 $G$ 个组，每个组内的Query Heads共享一个KV Head。
• 配置：例如，Llama-2 70B使用了8个KV Heads（$G=8$），而Query Heads为64个。这意味着每8个Query Heads共享1个KV Head。
• 压缩比：$H : G$。在上述例子中，压缩比为8:1。
• 效果：研究表明，GQA在显存占用和推理速度上接近MQA，而在模型效果（Accuracy/Perplexity）上几乎等同于MHA。它成功地在帕累托前沿（Pareto Frontier）上找到了最佳平衡点。

2.4 多头潜在注意力（MLA）：DeepSeek的架构革命

DeepSeek-V2（及其后的V3）引入的MLA（Multi-Head Latent Attention）不仅仅是分组策略的调整，而是对KV Cache存储方式的根本性重构。这是DeepSeek能够提供极低API价格的核心技术支撑。

2.4.1 低秩矩阵压缩（Low-Rank Compression）原理

传统的注意力机制直接存储投影后的 $K$ 和 $V$ 矩阵，维度为 $d_{model} \times L$。MLA认为这些高维矩阵中存在大量的冗余信息，可以通过低秩分解来压缩。MLA不直接存储 $K$ 和 $V$，而是将输入的隐藏状态投影到一个低维的“潜在向量”（Latent Vector, $c_{KV}$）。

• 压缩：输入向量首先经过一个下投影矩阵，变为极低维度的潜在向量（例如，压缩比可达数十倍）。
• 存储：在KV Cache中，只存储这个压缩后的潜在向量。
• 还原：在计算注意力分数时，通过一个上投影矩阵，将潜在向量实时还原为用于计算的Key和Value。

这种方法将KV Cache的显存占用从 $O(H \times d_{head})$ 降低到了 $O(d_{latent})$，其中 $d_{latent}$ 远小于前者。

2.4.2 解耦旋转位置编码（Decoupled RoPE）

低秩压缩的一个巨大挑战是如何兼容旋转位置编码（RoPE）。RoPE对向量的旋转操作具有几何敏感性，直接在压缩向量上应用RoPE会破坏其位置信息，或者在还原时引入巨大误差。

DeepSeek创造性地提出了“解耦RoPE”策略：

1. 内容头（Content Head）：负责捕捉语义信息，采用上述的低秩压缩（不带RoPE）。
2. 位置头（Position Head）：一个单独的、维度很小的向量，专门用于携带RoPE位置信息。
3. 拼接（Concatenation）：在计算Attention Score时，将还原后的内容头与位置头拼接，共同参与计算。

通过这种方式，MLA既实现了极致的KV Cache压缩（仅存储压缩内容+少量位置信息），又完美保留了长上下文所需的位置感知能力。根据DeepSeek的报告，MLA使得KV Cache的大小在同等参数规模下只有GQA模型的1/5甚至更低，这使得将KV Cache放入显存之外的介质（如内存或SSD）成为可能，因为数据传输的带宽压力被大幅减轻了。

3. 系统级显存管理与优化：从分页到流式

如果说Transformer架构决定了KV Cache的“理论最小体积”，那么系统软件则决定了如何在物理硬件上高效地“摆放”这些数据。2023年以来，以vLLM为代表的推理框架通过引入操作系统领域的经典思想，彻底改变了显存管理的范式。

3.1 显存碎片化与PagedAttention (vLLM)

在vLLM出现之前，主流推理框架（如FasterTransformer）采用的是静态显存分配。对于一个请求，系统必须按照其“最大可能长度”（Max Sequence Length）预先分配一块连续的显存空间。

• 内部碎片（Internal Fragmentation）：如果预分配了2048长度，但用户只生成了50个token，剩余的空间全部被浪费。
• 外部碎片（External Fragmentation）：不同请求的显存块大小不一，导致显存中出现许多无法被利用的空隙。

据统计，这种方式导致的显存浪费率高达60%-80%。

3.1.1 PagedAttention的原理

vLLM团队受操作系统虚拟内存（Virtual Memory）分页机制的启发，提出了PagedAttention。

1. KV Block：将KV Cache切分为固定大小的块（Block），例如每块存储16个token的KV数据。
2. 非连续存储：这些Block在物理显存（HBM）中不需要连续存放，可以分散在任意位置。
3. 页表（Block Table）：系统维护一张映射表，记录每个请求的逻辑token顺序对应哪些物理Block。
4. 按需分配：只有当新的token生成填满当前Block时，系统才申请下一个Block。

优势：

• 零浪费：内部碎片仅存在于最后一个未填满的Block中，浪费率降至4%以下。
• 显存共享（Memory Sharing）：这是PagedAttention最强大的特性。对于这就如Python中的引用计数，如果多个请求共享相同的System Prompt（例如“你是一个有用的助手...”），vLLM只需在物理显存中存储一份该Prompt的KV Block，所有请求的页表都指向这一份数据。只有当各自生成不同的后续内容时，才触发“写时复制”（Copy-on-Write）。这为由Prompt Cache奠定了系统基础。

• 并行采样（Parallel Sampling）：在 Parallel Sampling 中，同一个 prompt 会生成多个候选输出，便于用户从多个备选中选择最佳响应，常用于内容生成或模型对比测试。在 vLLM 中，这些采样序列共享相同的 prompt，其对应的 KV Cache 也可以共用同一组物理块。PagedAttention 通过引用计数和 block-level 的 copy-on-write 机制实现共享与隔离的平衡：只有当序列出现不同分支时，才会触发复制操作。

3.2 动态前缀复用与RadixAttention (SGLang)

虽然vLLM解决了分配问题，但在处理复杂的、非线性的对话历史时，如何自动发现可复用的KV Cache仍是难题。SGLang框架提出了RadixAttention，将缓存管理提升到了一个新的维度。

3.2.1 Radix Tree（基数树）结构

SGLang不再将KV Cache视为线性的数组，而是将其维护为一个基数树（Radix Tree）。

• 节点：树的边代表token序列，节点代表KV Cache的状态。
• 路径：从根节点到叶子节点的路径代表一个完整的对话历史。

Hash RadixAttention 代码走读：

3.2.2 自动复用机制

当一个新的请求到达时，系统将Prompt作为搜索键在Radix Tree中进行最长前缀匹配（Longest Prefix Match）。

• 场景A（多轮对话）：用户问“A”，模型答“B”。用户接着问“C”。RadixAttention自动匹配到“A->B”的路径，直接复用其KV Cache，只需计算“C”。
• 场景B（Few-Shot Learning）：多个请求使用相同的Few-Shot示例，但在最后的问题上不同。RadixAttention自动锁定公共前缀节点，无需人工干预。
• LRU淘汰：当显存不足时，系统根据最近最少使用（LRU）原则，从叶子节点开始剪枝，释放显存。

prefix hash 代码走读：

与vLLM早期的前缀缓存相比，RadixAttention无需用户手动配置，且能处理更复杂的分支结构（如Tree-of-Thoughts推理），显著提高了复杂Agent任务的吞吐量。

3.3 无限流式生成与StreamingLLM

对于需要7x24小时运行的数字人或长期助理，KV Cache理论上会无限增长直至显存溢出。简单的“滑动窗口”（Sliding Window，只保留最近N个token）会导致模型崩溃，因为Transformer在训练时并未适应这种信息的突然截断。

3.3.1 注意力汇聚（Attention Sink）现象

MIT的研究人员发现，Transformer模型在推理时，会倾向于将大量的注意力分数分配给序列开头的几个token（通常是前4个）。这些token充当了“锚点”（Anchor），稳定了后续层的注意力计算，即使它们本身可能没有太多语义信息。

3.3.2 StreamingLLM机制

基于上面的发现，StreamingLLM提出了一种特殊的缓存策略：

1. 保留汇聚点：永久保留序列开头的几个token（Attention Sinks）的KV Cache。
2. 滑动窗口：对后续的token使用滑动窗口，只保留最近的N个。
3. 位置编码调整：对RoPE进行相对位置的平移，使模型感知到正确的距离。

这种方法使得模型可以在有限的显存（例如只缓存2048个token）下，处理长度达到400万甚至无限的输入流，且困惑度（Perplexity）不发生爆炸。

4. 极致压缩：KV Cache量化技术

除了架构和系统优化，降低数据本身的精度是另一个维度的压缩手段。KV Cache量化（Quantization）正从研究走向生产环境。

4.1 精度格式的演变

• FP16/BF16：传统的基准，每个参数2字节。
• FP8 (E4M3/E5M2)：NVIDIA H100原生支持。将KV Cache压缩到1字节/参数。vLLM和TensorRT-LLM已经支持FP8 KV Cache，通常能带来2倍的吞吐量提升，且精度损失微乎其微。

4.2 激进量化：INT4与非均匀分布挑战

将KV Cache压缩到4-bit（INT4）可以将显存占用减少4倍，但这面临巨大挑战。

4.2.1 异常值（Outliers）问题

研究发现，Key和Value矩阵中的数值分布并非均匀的高斯分布。特定的通道（Channels）或Token会出现数值极大的异常值。如果使用标准的均匀量化（Uniform Quantization），这些异常值会拉大量化范围（Range），导致大部分小数值的精度被严重吞噬，模型彻底失效。

解决方案：

1. SmoothQuant / Atom：引入平滑因子，将激活值（Activation）中的异常值迁移到权重（Weight）中，或者在量化前对通道进行缩放（Per-channel scaling），使得分布更平滑，适合INT8/INT4量化。
2. KIVI / KVQuant：采用非均匀量化策略，或者将少量的异常值单独以高精度（FP16）存储，而对绝大部分数据进行INT4甚至2-bit量化。
3. 分组量化：类似于GQA，对每128个或64个元素进行独立的量化统计，减小异常值的影响范围。

目前，INT4 KV Cache在部分长文本场景下已可投入使用，但在高精度要求的逻辑推理任务中仍需谨慎评估。

5. 各大厂商Prompt Cache支持情况深度评测

2025年以来，随着上述技术的成熟，各大模型厂商纷纷推出了面向开发者的“Context Caching”或“Prompt Caching”服务。这一功能被视为RAG（检索增强生成）和Agent（智能体）应用的经济基石。

5.1 DeepSeek：磁盘缓存与价格屠夫

DeepSeek（深度求索）是目前市场上最具颠覆性的玩家。依托于其独特的MLA架构，DeepSeek实现了真正的磁盘级上下文缓存。

• 技术原理：由于MLA将KV Cache压缩到了极小（约为MHA的1/10甚至更低），数据量小到足以从SSD硬盘阵列中实时读取，而不会造成严重的延迟瓶颈。这打破了“KV Cache必须在显存”的铁律 6。
• 缓存策略（Implicit）：自动触发。无需用户显式创建缓存ID，系统自动识别重复的前缀。
• 价格体系：
  • 缓存命中（Cache Hit）：$0.014 / 百万tokens。这是一个惊人的数字。相比之下，GPT-4o的输入价格约为$2.50，DeepSeek的价格仅为OpenAI的 0.5%。
  • 缓存未命中（Cache Miss）： 约 $0.14 - $0.27 / 百万tokens（取决于具体版本），依然远低于竞品。
  • 存储费：免费。得益于磁盘存储的低成本，DeepSeek不收取额外的时间存储费。
• 持久性：由于存储在磁盘，其TTL（生存时间）远长于基于显存的竞品，理论上可达数小时甚至数天（取决于系统调度），非常适合低频但长尾的知识库查询。

5.2 Google Gemini：TPU加持下的灵活双模

Google Vertex AI利用其TPU Pod的庞大显存池，提供了最为灵活的“隐式+显式”双轨制。

• 隐式缓存（Implicit）：针对Gemini 2.5 Flash等模型。自动检测，无需代码更改。
  • 门槛：1024或2048 tokens以上。
  • 价格：命中时约为标准输入价格的25%（即75%折扣）。无存储费。
• 显式缓存（Explicit）：针对企业级长文档。
  • 机制：用户调用API创建CachedContent对象，获得一个ID。
  • 价格结构：包含两部分。
    • 计算费：命中缓存的Token价格极低（甚至在某些层级接近免费）。
    • 存储费：按小时计费。例如，Gemini 2.5 Pro约为$4.50 / 100万tokens / 小时。
  • 适用场景：** 这是一种“租赁显存”的模式。只有当你的查询频率非常高（例如每小时数百次查询同一份文档），节省的计算费才能覆盖存储费。如果只是偶尔查询，显式缓存反而更贵。

5.3 Anthropic Claude：极速流转的显存租赁

Anthropic的策略非常激进，专注于“高频会话”场景，尤其是配合Claude 4 Sonnet强大的编码能力。

• 显式断点：用户需在API参数中设置 cache_control: {"type": "ephemeral"} 断点。
• TTL（5分钟）：这是最大的争议点与特点。缓存仅保存5分钟。每次命中（Read），TTL重置为5分钟。这意味着它不适合长期存储，只适合连续不断的对话。
• 价格：
  • 写入（Write）：1.25倍标准输入价格。你需要支付溢价来创建缓存。
  • 读取（Read）：0.1倍（10%）标准输入价格。90%的折扣。
• 盈亏平衡点：由于有25%的写入溢价，用户必须在5分钟内至少复用一次缓存（即第二次提问），才能开始省钱。如果写入后5分钟内没有再次提问，缓存失效，用户的写入溢价就“白花了”。

5.4 OpenAI：保守的黑盒策略

OpenAI在Prompt Cache上显得相对保守和不透明。

• 机制：纯隐式。自动匹配1024 tokens以上的块。
• 支持模型：GPT-4、5等系列。
• 价格：
  • 写入：原价（无溢价）。
  • 读取：50%折扣。
• 分析：50%的折扣力度远小于DeepSeek (95%+) 或 Anthropic (90%)。但由于没有写入溢价，这是一种“无风险”的优惠——即使没命中也不会亏。
• TTL：不透明，通常为5分钟-24小时，受系统负载影响极大。这使得开发者很难依赖它来做严格的成本控制。

5.5 阿里云 Qwen (通义千问)：混合模式

阿里云Model Studio紧跟国际步伐，提供了类似的机制。

• 隐式：命中时按标准价的20%计费（80%折扣）。
• 显式：
  • 写入：1.25倍价格。
  • 读取：20%价格。
• Qwen-Long：支持文件ID引用的长上下文，本质上是一种持久化的上下文缓存，支持高达10M tokens，适合超长文档分析。

5.6 厂商对比汇总表

5.7 成本情景模拟：法律文档分析

场景：上传一本50,000 tokens的法律法典，并在接下来的2小时内进行100次问答查询。

1. Anthropic (Claude 3.5 Sonnet):
   • 首单（写入）：$50k \times $3.75/M = $0.1875$
   • 后续99次（读取）：$99 \times 50k \times $0.30/M = $1.485$
   • 总计：~$1.67
   • 风险：如果中间停顿超过5分钟，需重新支付写入费。
2. Google (Gemini 2.5 Pro - 显式缓存):
   • 写入：$50k \times $1.25/M = $0.0625$ (假设基础价)
   • 存储：$2 \text{小时} \times 0.05M \text{ tokens} \times $4.50/M/hr = $0.45$
   • 读取：$100 \times 50k \times $0.30/M = $1.50$
   • 总计：~$2.01
   • 优势：即使2小时内没人提问，缓存也在。
3. OpenAI (GPT-4o):
   • 首单：$50k \times $2.50/M = $0.125$
   • 后续99次：$99 \times 50k \times $1.25/M = $6.18$
   • 总计：~$6.30
   • 劣势：读取折扣力度不够。
4. DeepSeek (V3):
   • 首单：$50k \times $0.14/M = $0.007$
   • 后续99次：$99 \times 50k \times $0.014/M = $0.069$
   • 总计：~$0.076

6. 语义缓存与应用层优化

除了依赖模型厂商的Prompt Cache，开发者在应用层（Client-side）还可以通过语义缓存（Semantic Caching）进一步降低成本。这与Prompt Cache是互补关系。

6.1 语义缓存的原理

传统的缓存（如Redis）基于Key-Value精确匹配。如果用户问“苹果的价格？”和“苹果多少钱？”，传统缓存会视为两个请求。
语义缓存引入了向量嵌入（Embedding）技术：

1. Embedding： 将用户Query转化为向量。
2. 向量搜索： 在向量数据库（如Milvus, Qdrant, Redis Vector）中搜索历史Query。
3. 相似度阈值： 如果发现一个历史Query的余弦相似度大于阈值（如0.95），则直接返回之前缓存的LLM回答 36。

6.2 开源工具：GPTCache

GPTCache是目前最流行的开源语义缓存库，支持LangChain集成。

• 模块化设计： 支持多种Embedding模型（OpenAI, HuggingFace）和多种向量存储（Redis, FAISS）。
• 后处理： 甚至支持对缓存的回答进行评估，确保时效性。
• 对比：
  • Prompt Cache (服务端)： 解决的是“长Context复用”的问题。输入是旧的（书），问题是新的。
  • Semantic Cache (客户端)： 解决的是“高频重复问题”的问题。输入是新的（问题），但意义是旧的。
• 最佳实践： 只有当用户的提问具有高重复性（如客服系统常见问题）时，语义缓存才有意义。对于开放式分析任务，Prompt Cache更为关键 。

7. Prompt Cache在X-Sec中的应用

7.1 Prompt Cache

# Qwen3 等支持 Cache 的 LLM 使能 Prompt Caching
from langchain_core.prompts import ChatPromptTemplate

prompt = ChatPromptTemplate.from_messages([
  SystemMessage(
    # Qwen启动显示prompt cache能力
    content=[
      {
        "type": "text",
        "text": app_prompt_template.format(vars),
        "cache_control": {"type": "ephemera"},
      }
    ]
  ),
  HumanMessage(content=app_user_prompt_template.format(input_data),
])

# OpenAI 使能 Prompt Caching
from openai import OpenAI

client = OpenAI()

completion = client.chat.completions.create(
    model="gpt-4o",
    # openai 支持 24h 保存 cache
    prompt_cache_retention: "24h"
    messages=[
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Tell me a joke."},
    ]
)

7.2 Semantic Cache

语义cahce需要Memory系统的支持（langchain checkpoint支持vector store），所以当前还没有进行深入探索，后续Agent应用开发进入到这个阶段再行总结和探索。Stay Tuned！

8. 总结

大模型推理的演进史，本质上是一部与显存带宽和容量搏斗的抗争史。

1. 架构与硬件的协同：DeepSeek MLA的成功证明了算法创新（低秩压缩）可以解锁硬件潜力（SSD存储），从而颠覆商业模式。这预示着未来模型设计将更多地考虑底层硬件特性，而非单纯追求参数量。
2. 有状态API（Stateful API）的兴起：HTTP无状态协议已不再适应LLM应用。Prompt Cache的普及标志着LLM服务正演变为“有状态”的操作系统。开发者必须学会管理“Context 生命周期”，像管理数据库连接池一样管理Prompt Cache。
3. 成本的断崖式下降：随着$0.014/M tokens这种价格的出现，RAG应用的瓶颈将从“检索多少文档省钱”转变为“模型能处理多少文档不幻觉”。全量知识库注入（Full Context）正在取代部分切片检索，成为新的技术趋势。
4. 对于Agent应用开发者而言，当下的最优策略是：对于高频低延时任务（如代码助手）选择Anthropic或vLLM自建服务；对于海量数据分析和知识库问答，DeepSeek的磁盘缓存方案提供了目前无法匹敌的性价比优势。

References

1. Optimizing Transformer Inference with Grouped Query Attention | Towards AI, accessed November 27, 2025, https://towardsai.net/p/machine-learning/optimizing-transformer-inference-with-grouped-query-attention
2. arXiv:2305.13245v3 [cs.CL] 23 Dec 2023, accessed November 27, 2025, https://arxiv.org/pdf/2305.13245
3. Attention Mechanisms in Transformers: Comparing MHA, MQA, and GQA | Yue Shui Blog, accessed November 27, 2025, https://syhya.github.io/posts/2025-01-16-group-query-attention/
4. Understanding Multi-Head Latent Attention, accessed November 27, 2025, https://planetbanatt.net/articles/mla.html
5. DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model, accessed November 27, 2025, https://arxiv.org/html/2405.04434v2
6. DeepSeek API introduces Context Caching on Disk, cutting prices by an order of magnitude, accessed November 27, 2025, https://api-docs.deepseek.com/news/news0802
7. MLA: Redefining KV-Cache Through Low-Rank Projections and On-Demand Decompression - Hugging Face, accessed November 27, 2025, https://huggingface.co/blog/NormalUhr/mla-explanation
8. How PagedAttention resolves memory waste of LLM systems - Red Hat Developer, accessed November 27, 2025, https://developers.redhat.com/articles/2025/07/24/how-pagedattention-resolves-memory-waste-llm-systems
9. Introduction to vLLM and PagedAttention | Runpod Blog, accessed November 27, 2025, https://www.runpod.io/blog/introduction-to-vllm-and-pagedattention
10. vLLM and PagedAttention: A Comprehensive Overview | by Abonia Sojasingarayar | Medium, accessed November 27, 2025, https://medium.com/@abonia/vllm-and-pagedattention-a-comprehensive-overview-20046d8d0c61
11. vAttention: Dynamic Memory Management for Serving LLMs without PagedAttention - arXiv, accessed November 27, 2025, https://arxiv.org/html/2405.04437v1
12. When to Choose SGLang Over vLLM: Multi-Turn Conversations and KV Cache Reuse, accessed November 27, 2025, https://www.runpod.io/blog/sglang-vs-vllm-kv-cache
13. SGLang: Efficient Execution of Structured Language Model Programs - arXiv, accessed November 27, 2025, https://arxiv.org/pdf/2312.07104
14. Fast and Expressive LLM Inference with RadixAttention and SGLang | LMSYS Org, accessed November 27, 2025, https://lmsys.org/blog/2024-01-17-sglang/
15. Arxiv Dives - Efficient Streaming Language Models with Attention Sinks - Oxen.ai, accessed November 27, 2025, https://ghost.oxen.ai/arxiv-dives-efficient-streaming-language-models-with-attention-sinks/
16. Efficient Streaming Language Models with Attention Sinks - arXiv, accessed November 27, 2025, https://arxiv.org/html/2309.17453v4
17. [2309.17453] Efficient Streaming Language Models with Attention Sinks - arXiv, accessed November 27, 2025, https://arxiv.org/abs/2309.17453
18. Attention Sinks for LLM - Endless Generation - Analytics Vidhya, accessed November 27, 2025, https://www.analyticsvidhya.com/blog/2023/12/attention-sinks-for-llm/
19. FP8 E5M2 KV Cache - vLLM, accessed November 27, 2025, https://docs.vllm.ai/en/v0.6.3.post1/quantization/fp8_e5m2_kvcache.html
20. FP8 quantization with AMD Quark for vLLM — Tutorials for AI developers 8.0, accessed November 27, 2025, https://rocm.docs.amd.com/projects/ai-developer-hub/en/latest/notebooks/gpu_dev_optimize/fp8_quantization_quark_vllm.html
21. KVQuant: Towards 10 Million Context Length LLM Inference with KV Cache Quantization, accessed November 27, 2025, https://www.stat.berkeley.edu/~mmahoney/pubs/neurips-2024-kvquant.pdf
22. AsymKV: Enabling 1-Bit Quantization of KV Cache with Layer-Wise Asymmetric Quantization Configurations - ACL Anthology, accessed November 27, 2025, https://aclanthology.org/2025.coling-main.158.pdf
23. FireQ: Fast INT4-FP8 Kernel and RoPE-aware Quantization for LLM Inference Acceleration, accessed November 27, 2025, https://arxiv.org/html/2505.20839v1
24. NQKV: A KV Cache Quantization Scheme Based on Normal Distribution Characteristics, accessed November 27, 2025, https://arxiv.org/html/2505.16210v1
25. Gemini Developer API pricing, accessed November 27, 2025, https://ai.google.dev/gemini-api/docs/pricing
26. Context caching overview | Generative AI on Vertex AI - Google Cloud Documentation, accessed November 27, 2025, https://docs.cloud.google.com/vertex-ai/generative-ai/docs/context-cache/context-cache-overview
27. Context Caching In Google Gemini: Better Than RAG For Memory - Empathy First Media, accessed November 27, 2025, https://empathyfirstmedia.com/context-caching-google-gemini/
28. Prompt Caching Support in Spring AI with Anthropic Claude, accessed November 27, 2025, https://spring.io/blog/2025/10/27/spring-ai-anthropic-prompt-caching-blog
29. Prompt caching - Claude Docs, accessed November 27, 2025, https://platform.claude.com/docs/en/build-with-claude/prompt-caching
30. Prompt Caching is a Must! How I Went From Spending $720 to $72 Monthly on API Costs | by Du'An Lightfoot | Medium, accessed November 27, 2025, https://medium.com/@labeveryday/prompt-caching-is-a-must-how-i-went-from-spending-720-to-72-monthly-on-api-costs-3086f3635d63
31. Prompt caching - OpenAI API, accessed November 27, 2025, https://platform.openai.com/docs/guides/prompt-caching
32. Prompt Caching in the API - OpenAI, accessed November 27, 2025, https://openai.com/index/api-prompt-caching/
33. How does Prompt Caching work? - OpenAI Developer Community, accessed November 27, 2025, https://community.openai.com/t/how-does-prompt-caching-work/992307
34. Context Cache feature of Qwen models - Alibaba Cloud Model Studio, accessed November 27, 2025, https://www.alibabacloud.com/help/en/model-studio/context-cache
35. Qwen context window: token limits, memory policy, and 2025 rules - Data Studios, accessed November 27, 2025, https://www.datastudios.org/post/qwen-context-window-token-limits-memory-policy-and-2025-rules
36. Semantic Cache: How to Speed Up LLM and RAG Applications - Medium, accessed November 27, 2025, https://medium.com/@svosh2/semantic-cache-how-to-speed-up-llm-and-rag-applications-79e74ce34d1d
37. Semantic Cache: Accelerating AI with Lightning-Fast Data Retrieval - Qdrant, accessed November 27, 2025, https://qdrant.tech/articles/semantic-cache-ai-data-retrieval/
38. Semantic caching for faster, smarter LLM apps - Redis, accessed November 27, 2025, https://redis.io/blog/what-is-semantic-caching/
39. zilliztech/GPTCache: Semantic cache for LLMs. Fully integrated with LangChain and llama_index. - GitHub, accessed November 27, 2025, https://github.com/zilliztech/GPTCache
40. Reducing LLM Costs and Latency via Semantic Embedding Caching - arXiv, accessed November 27, 2025, https://arxiv.org/html/2411.05276v2
41. If your app process many similar queries, use Semantic Caching to reduce your cost and latency : r/LangChain - Reddit, accessed November 27, 2025, https://www.reddit.com/r/LangChain/comments/1f4rlx0/if_your_app_process_many_similar_queries_use/
42. 图解vLLM Automatic Prefix Cache(RadixAttention), https://zhuanlan.zhihu.com/p/693556044
43. Gemini 3技术是跳蛙式超越 https://www.youtube.com/watch?v=EMQxQwoFSb4
44. Andre Ng issue 329 | deeplearning.ai batch https://www.deeplearning.ai/the-batch/issue-329/

2025-10-26 15:58:59

Introduction: An Illusion of "Simplicity"

A narrative has recently become common within the team: "Building an Agent is simple now. You can just piece it together with LangChain, BaiLian, or Flowise, and it runs."

At first glance, this statement is hard to refute—frameworks have indeed lowered the barrier to entry. But that "simplicity" is more of an illusion, a facade created after the complexity has been temporarily absorbed by the platform. From a technical standpoint, Agent development involves:

• Orchestration and task planning;
• Context and Memory management;
• Domain knowledge fusion (RAG);
• And the "agentification" of business logic.

These steps are not accomplished just by writing a few prompts. When developers feel it's "simple," it's because the complexity has been absorbed by the platform. The difficulty of Agents lies not in getting a demo to run, but in making it operate reliably, controllably, and sustainably over the long term.

Why Is Agent Development Mistakenly Seen as "Simple"?

On the surface, we are in an era of explosive AI growth, with platforms and tools emerging endlessly. It's true that by writing a few prompts and connecting a few chains, a "functional" Agent can be born. But this doesn't mean the complexity has vanished. Instead, the complexity has been relocated.

I break this "simplicity" down into three illusions:

1. Encapsulated Complexity

Frameworks help you string prompts and trim context, shielding developers from the details. But the underlying mechanics—debugging, tracing, and state recovery—are still burdens you must bear alone.

Take LangChain as an example. A "question-answering" Agent can be created with just a few lines of code:

from langchain.agents import initialize_agent, load_tools
from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
tools = load_tools(["serpapi", "llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description")

agent.run("What is the current weather in Singapore, and convert it to Celsius?")

This code hides almost all complexity:

• Prompt assembly, call chains, and context management are encapsulated internally.
• But if the task fails (e.g., API rate limiting, tool failure), the Agent defaults to neither retrying nor logging a trace.

What looks like a "simple run" actually means sacrificing the interfaces for observability and debugging.

2. Outsourced Complexity

Memory, RAG, and Embeddings are all handed over to the platform for custody. The price is the loss of the ability to intervene and explain.

In LangChain, you can quickly add "memory":

from langchain.memory import ConversationBufferMemory
memory = ConversationBufferMemory(memory_key="chat_history")

But this is just a short-term memory buffer. It doesn't handle:

• Conflicts with old information;
• State drift over multiple turns;
• Or context truncation issues due to excessive length.

As the Agent scales, memory consistency and state cleanup become new sources of system complexity.

3. Postponed Complexity

It doesn't disappear; it just reappears during the execution phase:

• Output drift
• Inability to reproduce results
• Collapse of correctness and stability

Being able to run does not equal being able to run correctly over the long term. What we call simplicity is often just us temporarily avoiding the confrontation with complexity.

The Three Layers of Agent System Complexity

1. Agent Complexity

The complexity of an Agent system manifests in its ability to be run, reproduced, and evolved. Most current Agent frameworks have solved "runnability," but "reproducibility" and "evolvability" remain significant system engineering challenges.

At the "Runnability" level, the abstractions designed by frameworks like LangChain are indeed efficient. But to make an Agent's behavior stable, explainable, and continuously optimizable, additional infrastructure—such as logging systems, prompt version management, and feedback loops—is still required.

From a system engineering perspective, the difficulty of an Agent lies not in "generation" but in "execution." All platforms will eventually expose their costs along these two lifecycles.

In the implementation phase, stability is often more critical than correctness. Only when stability exists can correctness even be verified and optimized.

Intelligence's uncertainty must be underpinned by engineering's certainty. Stability and observability are the prerequisites for an Agent to be truly evolvable.

2. The Agent Amplification Effect

As shown in the image above, the same model (qwen-max), the same time, and the same prompt produce different results. This is the amplification effect that LLM uncertainty brings to Agents. Compared to the traditional software systems developers are most familiar with, the complexity and difficulty of Agents stem from this uncertainty, amplified at each semantic level by the LLM.

If a single LLM interaction has a 90% correctness rate, an Agent system requiring 10 LLM interactions will have its correctness drop to just 35%. If it requires 20 interactions, the correctness plummets to 12%.

Memory's Uncertainty Amplification

Traditional software state management is deterministic (e.g., what's in the database is what's in the database). An Agent's memory, however, relies on LLM parsing, embedding, and retrieval. The results are highly uncertain. Therefore, memory is not a storage/retrieval problem, but a semantic consistency problem. This is unique to Agents.

Orchestration's Dynamic Amplification

In traditional systems, orchestration (workflow) is a fixed, predefined process. In an Agent, the orchestration—which tool to call next, and how—is often dynamically decided by the LLM. This means the orchestration problem isn't just about "sequence/concurrency"; it's about an explosion of the decision space, making testing, monitoring, and optimization far more complex.

Testability's Unpredictability Amplification

Traditional software is predictable: given input → expected output. An Agent's output is a probability distribution (a stream of tokens from the LLM); there is no strict determinism. Therefore, testing cannot rely solely on unit tests. It must incorporate replay testing, baseline comparison testing, and simulation environment testing, which is far beyond the difficulty of standard application testing.

3. From "Runnable" to "Usable"

The "'It Runs, Doesn't It?' Fallacy"

Some might say, "I can get the Agent to work just by modifying the prompts. Am I amplifying the problem myself, rather than the Agent?"

"Getting it to run by tweaking prompts" essentially means: Short-term goal + High tolerance = Good enough.
The goal of an Agent system, however, is: Long-term goal + Engineering-grade reliability = Drastic increase in difficulty.

Let's first look at why tweaking prompts seems to work. Many Agent Demos or POCs (Proofs of Concept) aim for one-off tasks, like "write a summary for me" or "call this API." In these low-requirement scenarios, the raw power of the LLM masks many underlying issues:

• Memory can be passed purely through context (long-term persistence is never really tested).
• Orchestration can be hard-coded or hinted at in the prompt.
• Testability is irrelevant; if it gets the right answer once, it's a win.

The problem is that when the requirement shifts from a "Demo" to a "Sustainably Usable System," these issues are rapidly amplified:

• Prompt Modification ≠ Reliability Guarantee. Changing a prompt might fix the immediate bug, but it doesn't guarantee the same class of problem won't reappear in another case. You haven't established reproducible, maintainable decision logic; you've just engaged in "black-box tweaking."
• Prompt Modification ≠ Scalability. Prompt hacking works for a single-task Agent. But in a multi-tool, multi-scenario Agent, the prompt's complexity grows exponentially and eventually becomes uncontrollable.
• Prompt Modification ≠ Engineering Controllability. Traditional software can be covered by test cases to ensure logical coverage. Prompts can only partially mitigate the LLM's probabilistic fluctuations; they cannot provide strong guarantees.

This is why, ultimately, we need more structured methods for memory, orchestration, and testing—which is to say, Agent systematization.

Limitations of Agent Frameworks

Let's use the LangChain framework as an example to see if frameworks can solve the three layers of Agent complexity. LangChain provides a basic CallbackManager and LangSmith integration for tracing an Agent's execution. This functionality is often overlooked, but it is key to understanding "reproducibility" and "observability."

from langchain.callbacks import StdOutCallbackHandler, CallbackManager
from langchain.llms import OpenAI
from langchain.agents import initialize_agent, load_tools

# Create a simple callback manager
handler = StdOutCallbackHandler()
manager = CallbackManager([handler])

llm = OpenAI(temperature=0, callback_manager=manager)
tools = load_tools(["llm-math"], llm=llm)

agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description")

agent.run("Calculate (15 + 9) * 2")

When executed, LangChain will output every Thought and Action to the console:

Thought: I need to use the calculator tool.
Action: Calculator
Action Input: (15 + 9) * 2
Observation: 48
Thought: I now know the final answer.
Final Answer: 48

This seemingly simple output reveals three important facts:

1. The Agent's internal decision process is traceable (this is the prerequisite for reproducibility).
2. The CallbackManager must be actively enabled by the engineer (it doesn't log by default).
3. The granularity of observation is limited (it cannot directly trace context trimming, memory overwrites, etc.).

LangSmith provides a more complete visual trace, but it remains an external observation tool. The Agent framework itself still lacks built-in verification mechanisms. In other words, the framework gives you the ability to "see," but it doesn't solve the problem of "control" for you.

Although frameworks like LangChain are making interesting attempts to solve the complex problems in Agent systems, we must admit that most engineering dimensions remain unresolved. (In short, frameworks solve the problem of "using an LLM to do things," but not the problem of "making the LLM do things in a way that is controllable, sustainable, and scalable like a system"):

• ✅ Runnability: Generally well-supported (low barrier to entry)
• ⚙️ Reproducibility: Only partially supported (requires self-built state and observation layers)
• ❌ Evolvability: Still relies on manual effort and system design

LangChain makes Agents "buildable," but it makes the system lose its "explainability." Complexity didn't disappear; it just migrated from the code layer to the runtime.

Let's delve deeper into runtime complexity. The new problem Agent systems bring is that they don't just "run"; they must "continuously think," and the side effect of thinking is instability. This is not "traditional code complexity" but "system uncertainty introduced by intelligent behavior." It makes Agent engineering feel more like managing a complex adaptive system than a linear, controllable piece of software.

The Only Solution for Agents is Systematization

1. Prompt Hacking fails when the problem scales. For a single, simple scenario, tweaking a prompt works. But as task complexity and the number of scenarios increase, the prompt becomes bloated and uncontrollable (e.g., one prompt stuffed with dozens of rules). It's like concatenating strings to build SQL queries: it runs at first, but inevitably leads to injection vulnerabilities and a maintenance disaster. Systematization helps by providing structured constraints and automated orchestration, rather than manual prompt tuning.
2. Uncertainty demands controllability. Getting it right once is a win for a demo. But in a production environment, you need 99% correctness (or 100%). Even a 1% hallucination rate will accumulate into a disaster. For example, a log analysis Agent that misses or false-reports an issue just once could lead to an undiscovered online incident. Systematization ensures controllability through testing, monitoring, and replay verification, rather than gambling on luck every time.
3. Knowledge persistence vs. repeating mistakes. Today, an Agent's bug is fixed by changing a prompt. Tomorrow, a new requirement comes in, and the exploration starts all over again. Knowledge isn't retained. The Agent can't remember or reuse past solutions, leading to constant redundant labor. A colleague complained that in one business system, prompt modification commits made up over a third of all code commits. Yet, when another colleague tried to reuse that prompt for a similar problem, it was completely non-transferable and had to be hacked again from scratch. Systematization, through Memory + Knowledge Bases, ensures an Agent can learn and accumulate knowledge, not reinvent the wheel every time.

Prompt Hacking / Demo Agents solve "small problems." Only Systematized Agents can solve the problems of "scalability, reliability, and persistence." These issues might not be obvious now, but they will inevitably explode as usage time and scope expand.

A Demo Agent can solve today's problem. A Systematized Agent can solve tomorrow's and the day after's.

From "Smart" to "Reliable"

Some Real-World Agent Cases

Looking at history, we can understand rise and fall. Looking at others, we can understand our own successes and failures. The problems I've encountered in Agent system development are surely not mine alone. I asked ChatGPT to search Reddit, GitHub, and blogs for Agent development cases, hoping to use others' experiences to validate my own thinking and reflections:

1. Typical Failures of Toy-Level Agents

• Auto-GPT community feedback: looping, getting stuck, unable to complete tasks (the classic early example of "runnable but not reliable"). Auto-GPT seems nearly unusable
• Developer questioning if agents can go to production, noting severe step-skipping/hallucinations in multi-step tasks (system prompt + function calling isn't enough). Seriously, can LLM agents REALLY work in production?
• OpenAI Realtime Agents official example repo issue: Even the "simple demo" has too many hallucinations to be usable non-demo contexts. Lots of hallucinations?

2. Engineering Problems Exposed After Production (Not solvable by prompt changes)

• LangGraph deployment under production concurrency pressure: "can't start a new thread" (a resource/concurrency issue triggered by parallel nodes in Celery). Handling "RuntimeError: can't start a new thread" error at production.
• LangChain version upgrade breaks a production multi-agent app (__aenter__): Highlighting the need for explicit dependencies, version locking, and regression testing. AgentExecutor ainvoke stopped working after version upgrade

3. Industry/Big-Tech Postmortems: Why "Systematization" is Needed

• Anthropic: Effective agents come from "composable simple patterns + engineering practices," not from piling on frameworks (summarized from many client projects). Building Effective AI Agents
• OpenAI: Released Agents SDK + built-in observability, stating clearly "it's hard to turn capabilities into production-grade agents" and requires visualization/tracing/orchestration tools. New tools for building agents
• AWS Strands Agents SDK: Official emphasis on production-grade observability as a key design point, with built-in telemetry/logging/metrics hooks. Strands Agents SDK: A technical deep dive into agent architectures and observability
• Salesforce (Agentforce) Blog: Summarizes 5 top reasons for production failures (silent retrieval failures, lack of fault tolerance, using ReAct as orchestration, etc.), advocating for engineered RAG/fault-tolerance/evaluation. 5 Reasons Why AI Agents and RAG Pipelines Fail in Production (And How to Fix It)
• LangChain Team: Why build LangGraph/Platform—for control, durability, long-running/bursty traffic, checkpoints, retries, and memory. Claims it's used in production by LinkedIn/Uber/Klarna (vendor claims, but highlights the "systematization elements"). Building LangGraph: Designing an Agent Runtime from first principles

4. Positive Case: Treating it with a "Distributed Systems Mindset"

• Community experience: Treating LLM orchestration as a distributed system. Using retry/backoff/idempotency/circuit-breakers/persistent queues to get a multi-step workflow completion rate to 99.5% (an engineering post, emphasizing "systematic" methodology). Production LLM reliability: How I achieved 99.5% job completion despite constant 429 errors

5. Community Reality: People are using it in production, but focus on "de-complexing + limited agents"

• Developer feedback on LangGraph being production-viable: Migrated from LangChain's Agent Executor; the prototype→streamline→retain-necessities path is more robust (de-hallucinate/de-fancy, retain control). Anyone Using Langchai Agents in production?

The Four Stages of Agent Development

Over more than a year of Agent development, I've gone through a cognitive shift from "Agents are simple" to "Agents are truly complex." At first, I treated frameworks as black boxes, writing prompts and piecing things together to run a demo. As the complexity of the scenarios increased and I needed to go deeper into Agent system R&D, the difficulties gradually revealed themselves. I've tried to break down this "simple → truly hard" process:

Stage 1: The "Hello World" Stage (Looks simple)

Using frameworks like LangChain / AutoGen / CrewAI, you can get something running in a few lines of code. Most people stop at "it can chat" or "it can call tools," so they feel "Agent development is just this."

Stage 2: The Scene Adaptation Stage (Starting to hit pitfalls)

As the complexity of the problems the Agent solves increases, you slowly run into the LLM context window limit, requiring trimming, compression, or selection (i.e., Context Management problems). You find that vector retrieval results are often irrelevant, leading to non-answers, requiring optimization of preprocessing and query rewriting (RAG Knowledge Management). It runs in simple scenes, but falls into traps in slightly more complex ones.

Stage 3: The Systematization Stage (Complexity explodes)

Going further, as tool calls and context management increase, the Agent must ensure consistency across sessions and tasks. You must consider persistence, version control, and conflict resolution. A single Agent can't adapt to complex tasks; you need multi-Agent collaboration. At this point, you must solve deadlock, task conflicts, and state rollbacks. When task complexity rises, debugging the Agent flow can't be solved by tweaking prompts; you must add tracing and observability tools.

Stage 4: The Engineering Landing Stage (The real hard part)

• Agentifying Business Logic: How to test it? How to guarantee controllability and stability?
• Security & Compliance: Permissions, privilege escalation, data leakage. Strict security boundaries are a must.
• Monitoring & SLOs: Like operating microservices, you need monitoring, alerting, and failure recovery.

In summary, frameworks like LangChain lowered the "barrier to entry" for Agents, but they did not lower the "barrier to implementation."

My Cognitive Evolution in Agent Development

I have been developing an Agent system focused on vulnerability and security assessment in my own work. As I experienced the four stages of Agent development mentioned above, my thinking and understanding of Agents also changed:

Level 0: The Framework Illusion Layer

• Typical Behavior: Install LangChain / AutoGen / CrewAI, run an official demo, modify a prompt.
• Cognitive Trait: Believes "Agent Development = Writing Prompts." The barrier to entry is extremely low, similar to writing a script.
• Misconception: Thinks the framework solves all complexity, ignoring memory, orchestration, testing, and security.

Level 1: The Scene Splicing Layer

• Typical Behavior: Can stitch together RAG, tool calls, and simple multi-agent orchestration to build a seemingly viable prototype.
• Cognitive Trait: Begins to realize the importance of context management and RAG strategies.
• Pain Points: Encounters "irrelevant answers," "memory corruption," and "tasks failing to complete reliably."
• Misconception: Tries to use prompt hacking to solve all problems, ignoring underlying information management and system design.

Level 2: The System Design Layer

• Typical Behavior: Treats the Agent as a microservices system, needing to consider architecture, observability, and state management.
• Cognitive Trait: Understands that memory is essentially a database/knowledge-base problem, and orchestration is more like workflow scheduling than a chat.
• Pain Points: Debugging costs are extremely high; requires tracing, logging, and metrics monitoring.
• Key Challenge: How to ensure the Agent is robust, controllable, and reproducible.

Level 3: The Engineering Landing Layer

• Typical Behavior: Deploys the Agent into a production business environment.
• Cognitive Trait: Treats Agent development as an engineering discipline, just like SRE / Security / Distributed Systems.
• Pain Points:
  • Testability: The non-determinism of LLMs makes it impossible to guarantee stability with traditional unit tests.
  • Security: Permission management, privilege escalation, prompt injection protection.
  • Monitoring & SLOs: The Agent must be observable and recoverable, just like a service.
• Key Challenge: How to make the Agent reliable enough to carry critical business functions.

Level 4: The Intelligent Evolution Layer (Frontier Exploration)

• Typical Behavior: Attempting to build an Agent system with long-term memory, autonomous learning, and evolvability.
• Cognitive Trait: No longer sees the Agent as an LLM wrapper, but as a new type of distributed intelligent system.
• Challenges:
  • Memory becomes a knowledge graph + adaptive learning problem.
  • Orchestration involves game theory, collaboration, and even emergent behavior.
  • Security requires "AI sandboxes" to prevent loss of control.
• Status: Most are not at this stage; it is primarily research and experimentation.

Based on my current understanding of Agents, I now position them as system components rather than intelligent robots. My goal is not "occasional brilliance" but "sustained reliability."

Basic Principles:

1. Principles:
   • Stable first, smart second.
   • Observable first, optimized second.
2. Functionality:
   • Establish a replayable mechanism for state and logs.
   • Implement version tracking for Prompts / Memory / RAG.
   • Introduce observability metrics (success rate, drift rate, redundant calls).
   • Clearly define the boundaries and permission scope for each Agent.
   • Designate "error recovery" pathways in the architecture.
3. Boundaries:
   • If the Agent is only for one-off tasks or exploratory experiments, complexity control can be relaxed.
   • If used for production tasks (monitoring, automated operations), stability and security boundaries take precedence.
   • The deeper the framework's encapsulation, the more an external explainability layer is needed.

The Path to Agent Intelligence

Someone said 2025 might be the "Year of the Agent." After nearly a year of technical iteration, Agents have also seen considerable development from an engineering perspective. LangChain has essentially become the preferred backend option for Agent systems, and Agent R&D has evolved from prompt engineering → context engineering (as shown in the figure below).

1. Agent Development Philosophy

Agents are not a panacea. The key is to choose the appropriate automation stage for tasks of different complexities. I believe we can see from the five evolutionary stages of Agents:

1. Complex ≠ Better
   • Don't blindly chase the "strongest Agent architecture"; suitability is key.
   • Using a complex system for a simple task only increases cost and risk.
2. The Real Challenge is "Human"
   • Many failed cases stem from the designer choosing the wrong architecture or lacking phased thinking.
   • The model and workflow are not the problem; the human is.
3. The Importance of Design Thinking
   • First, assess the task's complexity and automation potential.
   • Then, decide the required level of intelligence (Script → LLM → RPA → Agent → Multi-Agent).
   • Finally, match the appropriate tool, don't use a "one-size-fits-all" approach.

2. Agent Design Patterns

• 1️⃣ ReAct Pattern (Reasoning + Acting)
  • Structure: Divided into Reasoning and Acting phases.
  • Mechanism:
    • LLM1: Understands context, plans which tool/API to call.
    • LLM2: Executes the action, returns the result.
  • Pros: Decouples reasoning and action, clear structure.
  • Applications: Q&A, multi-step tasks, tool-driven workflows.
• 2️⃣ CodeAct Pattern
  • Flow:
    • User → Plan: User gives a task, Agent plans the steps.
    • Code → Feedback: Generates and executes code, corrects based on results.
  • Feature: Introduces a feedback loop (code execution → result → reflection).
  • Applications: Verifiable tasks (data processing, analysis, API calls).
  • Represents: AI acting through code.
• 3️⃣ Tool Use Pattern
  • Core Concept: Upgrades from single API calls to a unified protocol (MCP) for managing tools.
  • Features:
    • Tool abstraction and standardization.
    • Supports multi-modal, multi-source tool access.
  • Significance: Greatly improves the Agent's ecosystem compatibility and extensibility.
• 4️⃣ Self-Reflection / Reflexion Pattern
  • Architecture:
    • Main LLM: Executes the main task.
    • Critique LLM(s): Criticizes/reviews the main model's output.
    • Generator: Combines feedback to produce the final answer.
  • Advantages:
    • Introduces a "self-reflection" mechanism.
    • Reduces hallucination rates, improves logic and quality consistency.
  • Applications: Scientific research, content generation, high-risk decision scenarios.
• 5️⃣ Multi-Agent Workflow
  • Structure:
    • Core Agent: Coordinates task allocation.
    • Sub-Agents: Each focuses on a specific function/domain.
    • Aggregator: Integrates outputs from sub-agents.
  • Features:
    • Simulates real team collaboration.
    • Supports complex, cross-functional tasks.
  • Applications: Enterprise-level systems, automated programming, cross-departmental processes.
• 6️⃣ Agentic RAG Pattern
  • Flow:
    • Agent uses tools to perform Web / Vector retrieval.
    • Main Agent fuses retrieval results with its own reasoning.
    • Generator produces the final answer.
  • Features:
    • Dynamic retrieval + reasoning.
    • Agent can autonomously decide "if, when, and how" to retrieve.
  • Significance: From static RAG → intelligent, decision-making Agentic RAG.

3. Latest Agent Progress

Finally, I want to summarize the latest engineering progress in Agents and the most recent engineering experiences worth learning from:

• Agentic Design Pattern (by Google's Antonio Gulli), PDF
• Build agentic AI systems (by Andrew Ng), Course

Below are some takeaways from Agent development. Those interested can look up how various Agent players are planning their strategies.

Perhaps future frameworks will absorb even more of this complexity. But the role of the engineer will not disappear. What we must do is to re-establish order in the places where complexity has been hidden—to make intelligence not just callable, but tamable.

2025-10-11 16:04:20

引子：一种“简单”的错觉

团队内部最近常出现一种论调：“现在做 Agent 很简单，用 LangChain、百炼、Flowise 搭一搭就能跑。”

这句话乍一听确实无法反驳 —— 框架确实降低了门槛。但那种“简单”，更像是复杂性暂时被平台吸收后的假象。从技术层面看，Agent 开发涉及：

• 编排与任务规划；
• Context 与 Memory 管理；
• 领域知识融合（RAG）；
• 以及业务逻辑的 agent 化。

这些环节并不是写几个 prompt 就能搞定的。 当开发者觉得“简单”其实是因为——复杂性被平台吸收了。 Agent 之难，不在跑通 Demo，而在让它长期、稳定、可控地运行。

Agent 开发为何被误以为“简单”？

从表面看，我们站在了一个 AI 爆炸的年代，各种平台与工具层出不穷。确实写几个 prompt、拼几层链路，一个“能动”的 Agent 就诞生了。但这并不是复杂性消失的标志，而是——复杂性被转移了位置。

我把这层“简单”拆成三种幻觉：

1. 被封装的复杂性

框架帮你拼接 prompt、裁剪 context，让开发者远离细节，但调试、trace、状态恢复这些底层骨架，仍无人替你承担。

以 LangChain 为例，只需几行代码即可创建一个 “能回答问题” 的 Agent：

from langchain.agents import initialize_agent, load_tools
from langchain.llms import OpenAI

llm = OpenAI(temperature=0)
tools = load_tools(["serpapi", "llm-math"], llm=llm)
agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description")

agent.run("给我查一下新加坡现在的天气，并换算成摄氏度")

这段代码几乎隐藏了所有复杂性：

• prompt 拼装、调用链、上下文管理都在内部封装；
• 但若任务出错（如 API 限流、工具失败），Agent 默认并不会重试或记录 trace。

看似“简单运行”，实则丧失了可观测与调试的接口。

2. 被外包的复杂性

Memory、RAG、Embedding 全交由平台托管，代价是失去了干预与解释的能力。在 LangChain 中，你可以快速添加“记忆”：

from langchain.memory import ConversationBufferMemory
memory = ConversationBufferMemory(memory_key="chat_history")

但这只是短期记忆缓冲，它不会处理：

• 旧信息冲突；
• 多轮状态漂移；
• 以及上下文过长导致的剪裁问题。

当 Agent 规模扩大，内存一致性与状态清理反而成了新的系统复杂度。

3. 被推迟的复杂性

它不会消失，只会在运行阶段重新显现：

• 输出漂移
• 无法复现
• 正确性与稳定性塌陷

能跑起来并不等于能长期跑得对。所谓简单，其实是我们暂时不用面对复杂。

Agent 系统的三层复杂度

1. Agent复杂度

Agent 系统的复杂性体现在可运行、可复现、可进化。当下的 Agent 框架大多解决了「可运行性」，但「可复现性」与「可进化性」仍是系统工程难题。

在“可运行性”层面，以LangChain为代表的框架的抽象设计确实高效。但若要让 Agent 行为稳定、可解释、可持续优化，仍需额外引入日志系统、prompt 版本管理、feedback loop 等基础设施。

从系统工程角度看，Agent 的难点并非在“生成”而在“执行”。所有平台最终都会在这两条生命线上暴露代价。

在落地阶段，稳定性往往比正确性更关键。只有稳定性存在，正确性才有被验证和优化的可能性。

智能的不确定性必须以工程的确定性为支撑。稳定与可观测，是 Agent 真正可演化的前提。

2. Agent放大效应

如上图所示，同样的模型(qwen-max)，同样的时间、同样的prompt，产生的结果缺不一样，这就是LLM的不确定性带给Agent的放大效应。相对于开发者最熟悉的传统软件系统的开发，Agent带来的复杂和难点就源于它被 LLM 的不确定性和语义层次的逐级放大了。假设一次LLM交互正确率为90%，一个Agent系统需要10次LLM的交互，那么这个Agent系统的正确率就只有35%，一个Agent系统需要20次LLM的交互，那么这个Agent系统的正确率只有12%。

Memory 的不确定性放大

相比传统软件的状态管理来说（是确定性的，例如数据库里有啥就是啥），Agent 的memory依赖 LLM 的解析、embedding、检索，结果高度不确定，所以memory不是存取问题而是语义一致性问题，这是 Agent 特有的。

编排的动态性放大

传统系统里编排（workflow/orchestration）是固定的流程，预定义好。Agent 里编排常常是 LLM 动态决定下一步调用哪个工具、如何调用。这意味着编排问题不仅是“顺序/并发”的问题，而是决策空间爆炸，导致测试、监控、优化都更复杂。

测试性的不可预测性放大

传统软件可预测：给定输入 → 预期输出。Agent 的输出是概率分布（LLM 输出 token 流），没有严格确定性。所以测试不能只用单元测试，而要引入 回放测试、对比基线测试、模拟环境测试，这就远超普通应用测试的难度。

3. Agent从“能跑”到“能用”

又不是不能跑，要什么自行车？

有人说，Agent开发的时候我修改修改提示词也能达到目标，是否是我自己放大了问题并不是Agent放大了上面提到的不确定性。

“改改提示词就能跑通”，本质上其实在说：短期目标 + 容忍度高 = 足够好，而Agent系统的目标是：长期目标 + 工程级可靠性 = 难度激增。

先看看为什么改改prompt就能跑通，很多 Agent Demo 或 POC（Proof of Concept）目标是 一次性任务，比如“帮我写个总结”“调用下 API”，在这种低要求场景里，LLM 本身的强大能力掩盖了很多问题：

• Memory 可以只靠上下文传递（没真正测试过长时效）；
• 编排可以写死流程或靠提示词 hint；
• 测试性无所谓，跑一次能对上答案就算赢；

是我放大了问题还是Agent系统放大了问题，其实需要从需求出发，因为当需求从 “Demo” → “持续可用系统” 时，问题会迅速被放大：

• Prompt 修改 ≠ 可靠性保证，改提示词可能解决眼前 bug，但没有保证同类问题不会在别的 case 再次出现。你其实没有建立可复现、可维护的决策逻辑，只是调参式“玄学优化”。
• Prompt 修改 ≠ 可扩展性，在单任务 Agent 下，prompt hack 有效。但在多工具、多场景 Agent 里，prompt 的复杂度指数级增长，最终失控。
• Prompt 修改 ≠ 工程可控性，传统软件能写测试 case 保证逻辑覆盖，但是 prompt 只能部分缓解 LLM 的概率波动，没法做强保证。

所以最终需要更结构化的 memory、编排和测试手段 —— Agent系统化。

Agent框架的局限

以Langchain框架为例，看看框架是否能够解决Agent三层复杂度的问题。LangChain 提供了基础的 CallbackManager 与 LangSmith（或Lanfuse） 集成，用于追踪 Agent 的执行过程。这部分功能通常被忽略，却是理解「可复现性」与「可观测性」的关键。

from langchain.callbacks import StdOutCallbackHandler, CallbackManager
from langchain.llms import OpenAI
from langchain.agents import initialize_agent, load_tools

# 创建一个简单的回调管理器
handler = StdOutCallbackHandler()
manager = CallbackManager([handler])

llm = OpenAI(temperature=0, callback_manager=manager)
tools = load_tools(["llm-math"], llm=llm)

agent = initialize_agent(tools, llm, agent_type="zero-shot-react-description")

agent.run("计算一下 (15 + 9) * 2 是多少？")

执行时，LangChain 会在终端输出每一次 思考（Thought） 与 动作（Action）：

Thought: 我需要使用计算工具。
Action: Calculator
Action Input: (15 + 9) * 2
Observation: 48
Thought: 我现在知道最终答案了。
Final Answer: 48

看似简单的输出，其实揭示了三个重要事实：

1. Agent 内部决策过程可追踪（这是复现性的前提）；
2. CallbackManager 需要工程师主动启用（默认不会记录）；
3. 观测粒度受限（无法直接追踪上下文裁剪、记忆覆盖等细节）。

LangSmith 提供了更完善的可视化 trace，但依然属于外部观测工具，Agent 框架本身仍未内建可验证机制。也就是说，框架给你“看”的能力，却不会替你“控”的问题。

虽然Langchain这样的框架已经有意思的在解决Agent系统中的复杂问题，但是不得不承认当前大部分工程维度仍然是未解决的（简言之，框架解决了“调用 LLM 做事”的问题，但没有解决“让 LLM 做事像系统那样可控、可持续、可扩展”的问题）：

• ✅ 可运行性：普遍支持良好（开发门槛低）
• ⚙️ 可复现性：仅局部支持（需自建状态与观测层）
• ❌ 可进化性：仍靠人工与系统设计

LangChain 让 Agent “能搭”，却让系统失去了“能解释”的能力。复杂性并未消失，只是从代码层迁移到了运行时。

我们再来深入的分析一下运行时的复杂度，即Agent系统带来的新问题——它不仅要运行，还要「持续思考」，而思考的副作用就是不稳定性。这些复杂性不是「传统的代码复杂度」，而是「智能行为带来的系统不确定性」。它们让 Agent 工程更像在管理一个复杂适应系统 ，而非线性可控的软件。

Agent唯一解是系统化

1. 问题规模放大后 Prompt Hack 失效，单一问题场景，改 prompt 就能跑通，但是当任务复杂度、场景数量增加，prompt 就会变得臃肿不可控（比如一个 prompt 里要塞几十条规则），就像写 SQL 时拼接字符串，开始能跑，最后一定注入 + 维护灾难。系统化帮助Agent结构化约束 + 自动化编排，而不是人肉调 prompt
2. 不确定性需要可控性，一次性跑出来成功就算赢，但是在生产环境必须 99% 正确（甚至100%），哪怕 1% 幻觉就会积累成灾难，例如像日志分析 Agent，错报/漏报一次可能导致线上事故没被发现。系统化通过测试、监控、回放验证，确保可控，而不是每次都赌运气
3. 知识沉淀 vs 重复踩坑，Agent今天改 prompt 能解决 bug，明天来了新需求又重新摸索。知识没有沉淀，Agent 不能记忆/复用，最终不断重复劳动。同事抱怨过一个业务系统的开发中prompt修改的commit占所有代码提交的三分之一以上，但是另一同事遇到同类问题想复用这个prompt发现完全无法迁移还要重新 hack。系统化就是通过Memory + 知识库保证 Agent 能学到、积累下来，不是每次都重造轮子。

Prompt Hack/Demo Agent 能解决的是“小问题”，系统化 Agent 才能解决“扩展性、可靠性、沉淀”的问题。这些问题现在可能不明显，但随着使用时间和范围扩大，必然会爆发。

Demo Agent 确实能解决问题，但只能解决今天的问题，系统化 Agent 才能解决明天和后天的问题。

Agent从“聪明”到“可靠”

一些真实Agent案例

以史为镜，可以知兴替；以人为镜，可以明得失，我在Agent系统开发过程中碰到的问题一定不止我一个人，我让ChatGPT帮我搜索了Reddit、GitHub、Blog中关于Agent开发的案例，想借助别人的案例来验证我自己的思考和反思是否一致：

1. 玩具级 Agent 的典型失败

• Auto-GPT 社区多次反馈：循环、卡死、无法完结任务（早期最典型的“能跑但不可靠”），Auto-GPT seems nearly unusable
• 开发者质疑“代理能否上生产”，实际尝试后指出多步任务中跳步/幻觉严重（仅靠系统 prompt+函数调用不行），Seriously, can LLM agents REALLY work in production?
• OpenAI Realtime Agents 官方示例库 issue：即便是“简单 demo”，使用者也反馈幻觉过多，不具备非 demo 可用性，Lots of hallucinations?

2. 上生产后暴露的工程问题（不是改 Prompt 能解决）

• LangGraph 生产部署并发压力下“can't start a new thread”（Celery 内多节点并行触发的资源/并发问题），Handling "RuntimeError: can't start a new thread" error at production.
• LangChain 版本升级导致生产多代理应用直接崩（__aenter__）：显示依赖/版本锁定与回归测试的必要性，AgentExecutor ainvoke stopped working after version upgrade

3. 行业/大厂公开复盘：为什么需要“系统化能力”

• Anthropic：有效的代理来自“可组合的简单模式+工程化实践”，而非堆框架（从大量客户项目中总结），Building Effective AI Agents
• OpenAI：发布 Agents SDK + 内置可观测性，明确指出“把能力变成生产级代理很难，需要可视化/追踪/编排工具”，New tools for building agents
• AWS Strands Agents SDK：官方强调生产级可观测性是关键设计点，内建遥测/日志/指标钩子，Strands Agents SDK: A technical deep dive into agent architectures and observability
• Salesforce（Agentforce）博客：总结生产失败 5 大原因（检索静默失败、缺乏容错、把 ReAct 当编排等），主张工程化 RAG/容错/评估，5 Reasons Why AI Agents and RAG Pipelines Fail in Production (And How to Fix It)
• LangChain 团队：为什么要做 LangGraph/平台——为控制、耐久性、长运行/突发流量、检查点、重试、记忆而生，并称其已被LinkedIn/Uber/Klarna用于生产代理（厂商口径，但点出“系统化要素”），Building LangGraph: Designing an Agent Runtime from first principles

4. 正向案例：当你用“分布式系统心态”做编排/容错

• 社区经验：把 LLM 编排当分布式系统来做，通过重试/退避/幂等/断路器/持久化队列等模式把多步工作流完成率拉到 99.5%（工程实战帖，强调“系统化”方法论），Production LLM reliability: How I achieved 99.5% job completion despite constant 429 errors

5. 社区实况：有人在生产用，但都在谈“去复杂化 + 有限代理”

• LangGraph 在产线可用的开发者反馈：从 LangChain 的 Agent Executor 迁移；原型→精简→保留必要能力的路线更稳健（去幻觉/去花哨，保留可控），Anyone Using Langchai Agents in production?

Agent开发的四个阶段

一年多的Agent开发，我经历Agent很简单到Agent真复杂的认知变化，最开始把框架当黑盒，写 prompt 拼拼凑凑，就能跑个 demo，随着场景复杂性提升需要往Agent系统研发的深处走时，难点就逐步暴露出来。我尝试把这个“简单 → 真难”的过程拆了一下：

第一阶段：Hello World 阶段（看起来很简单）

用 LangChain / CrewAI 之类的框架，几行代码就能跑起来，大多数停在“能对话”、“能调用工具”这层，所以觉得“AI Agent 开发不过如此”。

第二阶段：场景适配阶段（开始遇到坑）

随着Agent解决问题的复杂度提升，慢慢会碰到LLM context窗口装不下，需要裁剪、压缩、选择（即Context 管理问题），然后又发现向量检索、数据获取的结果经常无关、答非所问，需要优化预处理、query 重写（RAG知识管理），渐渐地我认识到简单场景能跑，但是稍微复杂点就掉坑。

第三阶段：系统化阶段（复杂性爆炸）

再进一步，Agent随着工具调用、上下文管理增加（例如复杂安全威胁建模过程），需要保证跨会话、跨任务一致性，必须考虑持久化、版本控制、冲突解决。单个Agent无法适应复杂任务（例如复杂的漏洞风险评估任务），需要多 Agent 协同，此时就必须解决 deadlock、任务冲突、状态回滚。任务的复杂性上来了Agent 流程调试就不是改改 prompt 能解决的，要加 tracing、可观测性工具。

第四阶段：工程落地阶段（真正的硬骨头）

• 业务逻辑 Agent 化：业务workflow开发完成了，但是如何测试？如何保证可控性和稳定性？还没有任何最佳实践和答案。
• 安全与合规：权限、越权调用、数据泄露，必须引入严格的安全边界，当前这方面完全没有涉及，这对一个生产使用的系统会有非常大的隐患。
• 监控与 SLO：像运维微服务一样，需要监控、报警、故障恢复。

Langchain框架、百炼平台等确实让Agent“起步门槛”变低，但没有降低“落地门槛”。第三阶段、第四阶段很多问题，我也是摸着石头过河，当下还总结不出任何经验和结论。

我对Agent开发认知的演化

我一直围绕自己工作中涉及到的漏洞安全评估开发Agent系统，在经历上面提到的四个Agent开发的时候，我对Agent的思考和理解也在变化：

第一层：框架幻觉层

• 典型行为 ：装个 LangChain / AutoGen / CrewAI，跑个官方 demo，改一改 prompt。
• 认知特征 ：觉得“Agent 开发=写 Prompt”，门槛极低，和写脚本差不多。
• 误区 ：以为框架解决了一切复杂性，忽略了 memory、编排、测试、安全。

第二层：场景拼接层

• 典型行为 ：能把 RAG、工具调用、简单多 Agent 编排拼接在一起，做一个看似可用的原型。
• 认知特征 ：开始意识到 context 管理、RAG 策略的重要性。
• 痛点 ：遇到“答非所问”“记忆错乱”“任务无法稳定完成”。
• 误区 ：尝试用 prompt hack 解决所有问题，忽略了底层信息管理和系统设计。

第三层：系统设计层

• 典型行为 ：将 Agent 当成微服务系统，需要考虑架构、可观测性、状态管理。
• 认知特征 ：理解 memory 本质上是数据库/知识库问题，编排更像工作流调度而非聊天。
• 痛点 ：debug 成本极高；需要 tracing、日志、指标监控。
• 关键挑战 ：如何确保 Agent 鲁棒性、可控性、可复现性 。

第四层：工程落地层

• 典型行为 ：将 Agent 投入业务生产环境。
• 认知特征 ：把 Agent 开发当成 SRE/安全/分布式系统 一样的工程学科。
• 痛点 ：
  • 测试性 ：LLM 的非确定性导致无法用传统单测保证稳定。
  • 安全性 ：权限管理、越权调用、prompt 注入防护。
  • 监控与SLO ：Agent 必须像服务一样可观测、可恢复。
• 关键挑战 ： 如何让 Agent 可靠到能承载关键业务。

第五层：智能演化层（前沿探索）

• 典型行为 ：尝试构建有长期记忆、自主学习、可进化的 Agent 体系。
• 认知特征 ：不再把 Agent 当 LLM wrapper，而是当 新型分布式智能系统 。
• 挑战 ：
  • memory 变成知识图谱 + 自适应学习问题
  • 编排涉及博弈、协作甚至涌现行为
  • 安全需要“AI sandboxes”，避免失控
• 现状 ：大多数人还没到这个阶段，研究和实验为主。

结合当下对Agent的理解，当前我对Agent的定位是将其视作一个系统组件而非智能机器人，我的目标不是“偶尔惊艳”而是“持续可靠”。基本原则：

1. 原则：
   • 先稳定，后聪明
   • 先可观测，后优化
2. 功能：
   • 建立状态与日志的可回放机制
   • 对 Prompt / Memory / RAG 做版本追踪
   • 引入观测指标（成功率、漂移率、冗余调用）
   • 明确每个 Agent 的边界与权限范围
   • 在设计上预留“错误恢复”通道
3. 边界：
   • 若 Agent 仅用于一次性任务或探索性实验，复杂度控制可以放宽。
   • 若用于生产任务（监控、自动化操作），稳定性与安全边界优先。
   • 框架封装越深，越需要额外的可解释层。

Agent智能化之路（最新进展）

好像有人说过2025是Agent元年，经过将近一年的Agent技术迭代，Agent也从工程角度有了比较长足的发展，Langchain基本上已经成为Agent system后端的优先选项，Agent研发也经历 prompt engineering → context engineering的演变（如下图所示）。

最后，我想分享一下当下Agent工程上最新进展以及Agent system最新的工程经验值得借鉴与学习：

• Agentic Design Pattern(by Google Antonio Gulli)，PDF
• Build agentic AI systems(by Adrew Ng)，Course

最后，也许未来的框架能进一步吸收这些复杂性。但工程师的角色不会因此消失。我们要做的，是在复杂性被隐藏的地方，重新建立秩序 —— 让智能不只是可调用，更是可驯服。

2025-10-03 19:50:24

E41 孟岩对话阿娇：我的另一面，也想被注视和欣赏

Listen

播客对谈刚开始（22:42）的一段对话，跟去年的付航给我的感受很相似：

孟岩：我还是会好奇那些，为什么一个人可以变成这样的，可以去解决任何问题的人
阿娇：我没有，我没有

阿娇说「我没有」的时候，喉咙是略带干涩的，一段明显的停顿之后再次强调了一下「我没有」。第一次听这一段的时候，我正好在开车通勤，当时鼻子一酸，到现在我还是不知道用什么语言描述我当时内心的感受。

这期播客中有非常多的停顿，孟岩的、阿娇的，有各自一度语塞的、有阿娇身体不适的杂音、有喝水的咕噜声等等，在追求严谨、品质、精致的播客里这无疑是惨不忍睹的。但是我很珍惜这一期播客，小宇宙里唯一收藏的就是它了，相比当下社交媒体为大众营造的美好、精致、暖心、振奋，它足够真实，还原了这个世界本来的样子，可以有口癖、有粗口、有空白。

理解阿娇

这期播客我听了很多遍，因为心境不同，其实前几遍的时候，我并不太理解阿娇和孟岩对谈的一些话。

「这几个月，我反反复复在想，也反反复复有人在聊的东西——为什么死亡已经迫在眉睫，看起来这世间一切都即将与我无关，可欲望没有退潮？为什么我对自己的诸多想象，我的诸多理想主义，我的追求，我的欲念，它未曾消退？我以为会一切返璞归真，去伪存真，最后只剩一两件要紧的事，一两个要紧的人，但是偏偏不，我还是有那么多想做的事情。」

「真正的外部评价无法刺穿的屏障，是只有我自己能刺穿的。」

「正是因为我有很多想说的，那不说也好，不说也好。把那些话留着，让我自己去消化，然后把那些表达欲留着，让我自己去消化，我们之间留一些无人知晓的留白。
可能在你以后几十年的生命里，我不知道你会不会再想起我，（可能）某一次晚霞，或是某一次海口的落日，会让你再想起我这个人，然后你再回味时，你回味起的，也许就是我想跟你说的话。」

阿娇期待别人的注视，特别是与高手的对谈，但是她不喜欢别人用标签的滤镜来关注她，阿娇的心境与我过往写的一篇博文不谋而合（如何减少标签对自己分享带来的压力）。作为一个被医生预测只能活到今年八月份的晚期病人，她自己都没法预测下一周能否「完美交付」，所以她更加希望珍惜自己每次的「在场」，我想当下对阿娇而言Everything matters，她渴望的是被看见和尊重的专业能力、平等的智识交流、完整且立体的女性。

所以孟岩提到的「你要是能够有钱做投资，一定会是一个很好的投资人」，其实说明他是没有真正理解傲娇，还是带着「柱子哥」的标签来看待阿娇。我也能理解孟岩在问阿娇「我们交流了之后还觉得我是高手吗？」，阿娇没有正面的回答，但我觉得已经给出答案了，一个被阿娇认为非常charming、智慧的孟岩也并没有真正的看到懂得如何注视阿娇。阿娇追求的是在命运的巨大不确定性面前，夺回对自己生命叙事的定义权，其实在跟孟岩的交流中就已经给出答案了：「我，阿娇，首先是一个有能力的专业人士，一个热爱生活的独立女性，其次，才是一个病人。」

理解孟岩

这期播客里孟岩像是一个客人，言语之间充满了谨慎，他的语调与提问，随时在自我提醒：这一步会不会冒犯到的。那份小心并不傲慢冷漠，反而带着温度——一种想要守护的敬意。

我能理解，孟岩的谨慎来自悲悯以及对话题重量的清醒认知，更是来自健康者难以跨越的距离感。阿娇的坦然，并不是无能为力的自我安慰，而是带着遗憾地一次次与死亡的直面、与痛苦的缠斗。她已把死亡当作生活里不可回避的「考题」，用一种近乎平常心的姿态谈论它。

我能理解也更感谢孟岩，在这期的对谈没有运用任何技巧和引导（这是孟岩擅长的，却是对阿娇的误解和亵渎），孟岩没有让他们的对话陷入对苦难的消费，也没有流于空洞的正能量，他守住了边界与尊严，坦然赋予了厚度与真实。那些停顿、噪点与呼吸，比流畅的表达更有力量——它们让人听见了生命最真实的质感。

理解自己

• 不能在场 vs. 不能上场，哪个更让你痛苦？不能上场是命运的安排，不能在场是心的背叛。人在却心不在，比缺席更残酷。
• 没有过去 vs. 没有未来，哪个更让你不能接受？失去过去是失忆，失去未来是虚无。我更怕门被锁死而不是记忆被抹去。
• 从未在一起 vs. 最终没在一起，哪个更让你遗憾？最终没在一起至少有过印证，从未在一起只剩无尽的“假如”。空白比断裂更让人困在迷宫。

我重复听了很多遍这期播客，阿娇让我想到了自己的一位远赴异国的老友阿楠，她们两个给我的感受很像，聪明能干、倔强要强、直面挑战和对抗。也不知道经历了生活的磨砺之后，现在的老友有没有改变，不过我知道她现在很开心很幸福，这是让我觉得好的地方。至少，在生命体验的角度阿娇跟阿楠是不一样的，我的朋友是无比幸运且幸福的。

2025-09-14 14:57:24

最近在复盘松烟阁管理的时候，我用朱雀检测测试了一下最近的两篇博文，结果还挺精确：

两篇文档都是出自我手，我非常清楚其中的细节以及写作的过程，第一篇是我纯手写，第二篇表格部分是我用Gemini生成的，由此可以见检测结果与事实完全正确。

自从AI能够生成高质量内容就是，创作者群里就一种声音表达自己对内容的洁癖，比较激进的甚至会表达类似「只要是AI生成的内容就不愿意付出精力和时间去阅读」。我一直努力在克制自己创作内容中掺入AI生成的部分，不过确实要承认在结构化思考和表达上AI更优秀，起码比我自己的表现是要好的，慢慢地我可以接受自己为文章内容提供灵魂，而AI为我的文章内容提供装饰品。

AI正在深刻的改变我们生活的方方面面，我想写作上就是这样的，而怎么控制好以及怎么区分是否来自AI，这就是我今后要逐步积累和锻炼的能力。

换个视角，其实这两篇检测报告也从另一个方面证实了一个AI和人是有区别的。

AIGC的本质就是将人类语言通过分词进行向量化，通过神经网络将文本、语言问题转换成了矩阵运算的问题，无论是余弦相似度或者是欧几里得距离表示生成内容与输入内容的相关性，这些向量都是人类语言在高维空间的映射表示。

而朱雀检测能够通过大模型区分出人写的和AI生成的，其实意味着人自己写的东西在高维空间是有非常显著特征的，只是生活中三维空间的人普遍没办法感知到而已。朱雀检测其实就量化的证明了，在某个未知的高维空间里面可以非常清晰地区分人写的内容与AI生成的内容的。

从这个角度来看，我一直输出写作是有意义的，因为数学说明了在这个时空的某个维度我的内容具备了AI没法取代我的特征（至少目前为止AI做不到取代我），这样的经历让重新对人的创作有了信心。做一个坚定的人类相信者，拥抱和享受AI给我们带来的变化吧。

最后，致敬那些一直在坚持自己博客的朋友，以此共勉！

2025-09-07 17:26:45

背景

最近职场槽点真的有点多，这周开会的时候大老板在质疑AI投入的必要性问题，其中有一句我个人觉得可以列入年度金句了：“没有用AI之前，xxx问题有什么影响？我看大家都觉得没什么问题都能扛得住，我承认它是「屎」，但是不是大家也能忍着，也没出什么事......”

说这句话是基于大老板对于当前AI的认识：

• 直接让大模型分析一些业务问题，它给出的回答看上去像模像样，将来80%的Agent会被大模型内化掉；
• 现在Agent的构建很方便也很廉价，甚至外包都能做；
• 目前Agent在内部的应用碰到了非常强烈的幻觉问题，没法立竿见影地产生业务价值；
• 面对技术趋势，一群程序员是为了做AI而做AI；

在大厂环境中，上面提到的大老板的这些潜台词无可厚非，我不打算做更多的吐槽，我打算思考一个问题：怎么判断一段内容是AI生成的，它的特点和根因是什么。

只有了解通用大模型生成内容的原理以及特点，才能继续评价Agent的价值和发展，这个问题留待下一篇职场生存实录文章探讨吧。

内容的「AI味」

读一段文字，你有没有过那种感觉？哪儿都对，就是心里不得劲，通顺有逻辑，但就是没人味儿。当时我还纳闷，后来才反应过来，这就是所谓的“AI味”。

一开始我也觉得，是AI还不够牛，等它再进化几代就好了。利用周末的时间我研究了一下这个问题，我感觉这根本不是技术问题，换言之模型进化未必能解。AI的本质是个超级厉害的统计学模型能算出哪个词后面跟哪个词的概率最高——它知道“心碎”这个词旁边经常出现“眼泪”和“夜晚”——但它跟人不一样没有自己的「心」，所以它根本不知道心碎是种什么感觉，这些具身数据的缺失注定它没办法真正“体验”，就像一个人照着菜谱念菜名，词儿都对但没有锅气。

“AI味”的特点

为了可以识别“AI味”，我觉得可以从结构、语言、语调和内容深度四个维度来分析“AI”内容的特点：

“AI味”的原理

生成式大模型的核心运作机制是基于统计概率预测下一个最可能出现的词或短语，而非真正的理解。这个过程天然地导向一种“向平均值回归”（regression to the mean）的趋势。因为模型旨在生成最“安全”、最“普遍”的输出，所以它会频繁地使用那些在训练语料库中统计上最常见的通用短语和陈词滥调 。它擅长的是复制，而非真正的原创 。

同时，因为缺乏人生活中接触的超越文本数据之外的共享语境数据，大模型的具身认知（embodied cognition）是缺失的，AI无法捕捉情感的细腻纹理和道德的复杂性，无法理解讽刺、反语或微妙的文化隐喻的原因就在于此。

大模型的架构和训练机制引发的“浅输入，浅输出”即奖励机制导致大模型追求平均和正确，也就是正确的废话，这也侧面说明了AI输出的质量与输入的质量、上下文深度直接相关 。一个笼统的提示词，如“写一篇关于人工智能的博客”，没有提供任何具体背景，迫使AI只能从其训练数据中最通用、最宽泛的部分提取信息 。

这样“AI味”的原理就清晰了：浅层输入导致AI调用通用模式，表现为刻板结构和通用短语，最终产出固定模式的文本也就是“AI味”。

如何用prompt去“AI”味

宝玉老师推荐的怎么用大模型去掉“AI”味，本质上就是“让大模型主动露拙，模仿人的随机性”，具体prompt如下：

1. 用词与句式
- 70% 句子长度 < 18 词；偶尔插入 < 6 词的独立短句。
- 使用常见口语连接：and, but, so, anyway, you know.
- 每段至少包含一个具象细节（气味、手感、具体对象）。

2. 叙事与结构
- 采用第一人称或“我/我们”叙述，加入个人小片段（真实或拟真）。
- 不做完整封闭结论，最后一段留一点未决疑问。

3. 语用特征
- 保留一两处自我否定或转折（“其实…但回头想想…”）。
- 允许一两个轻微重复或改写，而不影响理解。

1. 技术采样参数（如需）
- temperature 0.9–1.1；top_p 0.9；top_k 40–60。
- frequency_penalty 0.3；presence_penalty 0.6。
  
以下是一些范文参考：
{text}

最后我把上面的思考内容喂给NotebookLM，让它给我一个关于“AI味”的Overview：