不如不追求

结构化输出（Structured Output）让你告别 JSON 解析失败，但它有个没人提的代价——约束解码会在推理任务上偷走你 10-30% 的准确率。这篇文章拆解这个 tradeoff 的底层原理，以及生产中怎么用好这把双刃剑。

大多数人以为 Agent 慢是因为 LLM 生成慢。但实测数据告诉你，token 生成只占 Agent 循环总延迟的 20%-35%。真正的延迟黑洞藏在你看不见的地方——prefill、序列化、以及每轮都在膨胀的上下文编码开销。

Agent 的记忆系统不是越全面越好，而是越精准越好。生产环境下的记忆管理，核心挑战不在存储而在遗忘、冲突和检索精度——这篇文章从踩坑出发，拆解三层记忆架构的工程落地。

给 LLM API 加上 stream=True 不会加速 Agent 循环。恰恰相反，在绝大多数 Agent 架构下，streaming 是白费力气——甚至让系统更慢。

A deep dive into Thariq Shihipar's article on how the Anthropic team designed, tested, and evolved tools for Claude Code by learning to see from the model's point of view. Original: Thariq Shihipar, "Seeing like an agent: how we design tools in Claude Code", Anthropic Blog, 2026-04-10

你的 Agent 跑着跑着突然不干活了——不是报错，是安静地停止工作。API 超时、幻觉循环、上下文溢出——每个问题都在悄悄杀死你的 Agent，而它连最后的遗言都不会留给你。本文从我做的多 Agent 系统的实战出发，聊 Agent 错误恢复的三个核心模式和一条铁律。

大模型 Agent 的记忆系统不能只靠向量相似度做检索——时间维度、干涉效应、情境线索，这些被忽视的维度才是区分"玩具"和"能用"的关键。 Summary: 大模型 Agent 的记忆系统不能只靠向量相似度做检索——时间维度、干涉效应、情境线索，这些被忽视的维度才是区分"玩具"和"能用"的关键。 给 Agent 加上记忆，几乎是每个 LLM 应用开发者都会想的一件事。于是很自然地，你把对话历史 chunk 成一段段文本，算好 embedding，塞进向量数据库，然后每次来了新 query 做 top-K 相似度搜索——取回最像的几条塞进 context。 这确实比没有强。但如果你把它和人类的记忆能力做个对比，会发现一个扎心的事实： 我们刚才做的，本质上只是一个带索引的搜索缓存。它不是"记忆"——它是关键词联想。 检索的四个隐藏维度 从第一性原理来看，一个"好用"的记忆检索系统需要回答四个问题： 1. 时间维度：旧信息凭什么被找到？ 向量相似度只关心语义距离，不关心时间距离。但真实场景里，一个 Agent 在调试时发现的配置 bug，三天后在另一个场景里同样有用——而中间如果被几十条对话稀释，"相似性"排名会把它推到很后面。 解决思路之一是 时间加权衰减 ：给记忆一个随时间衰减的基础分数，检索时和语义相似度做加权融合。这不只是加个 timestamp 排序那么简单——衰减曲线本身就是一个超参数空间：线性衰减、指数衰减、还是带 Plateau 的衰减，直接决定了"多久之前的事情还算重要"。 2. 干涉效应：记忆会互相湮灭 人类记忆有个很烦人的现象：学了新东西，旧东西就模糊了（前向干涉）；回忆旧东西时，新东西被激活出来干扰（后向干涉）。这在 Agent 记忆系统中同样存在——只不过不是"遗忘"，而是 检索噪声 。 当 Agent 处理了 50 个不同用户的相似问题，它们的记忆碎片会在向量空间中挤在一起。这时候 top-5 检索返回的 5 条可能语义上都非常"像"，但互相之间是冗余的，覆盖的信息面反而很窄。 最大边界相关性（MMR） 是一个经典解法：在候...

Prompt caching 不是"缓存"，它是 Transformer 的 causal attention 带来的天然性质。不懂 KV cache 的人只看到省钱，懂的人看到的是：系统提示怎么安排、动态内容放哪里、TTL 怎么调——这些决策直接决定了你的 LLM 账单是三位数还是四位数。

Agent 不是越跑越聪明，而是越跑越"挤"。从 context window 的物理限制出发，看 token 竞争如何侵蚀长期运行 agent 的推理质量，以及工程上怎么对抗它。

长期记忆系统的核心困境不是"记不住"，而是"忘不掉"。从信息检索的底层原理出发，看遗忘机制如何反向提升 agent 记忆质量。

Agent 系统跑着跑着就不知道它在干什么了——问题定位靠猜、成本算不清、质量没数据。这篇文章从实战角度聊怎么给 Agent 加上可观测性，让黑盒变透明。

你的 Agent 对接了下游系统，但 LLM 返回的 JSON 可能有 30% 是坏的。结构化输出不是让 Prompt 写得更详细，而是在 Token 采样层面物理约束输出格式——这是 Agent 系统从 Demo 走向生产的工程底线。

分布式系统的最终一致性假设"最终会收敛到正确状态"，这个假设依赖一个 Agent 记忆系统不具备的前提——持久化存储。从第一性原理拆解两种系统在"状态演进"上的根本差异。

  在 Spring 的物理世界里， @Transactional 的底层完全依赖 Spring AOP 动态代理 和 ThreadLocal 本地线程变量 。一旦破坏了这两个底座的因果链，事务就会瞬间物理塌方。

IoC（Inversion of Control，控制反转）绝对不是 Spring 框架独有的发明，更不是一种具体的编程技术。它是一种顶层的、颠覆性的软件架构设计思想（Design Principle）。 从第一性原理出发，它的物理本质是： 将软件系统中组件的“生命周期控制权”与“业务流向主导权”，从传统的“手写业务代码”中彻底剥夺，反手移交给一个外部的通用框架（IoC 容器）来全权掌控。它颠覆了传统软件工程中“正向控制”的物理因果链条。

在面向对象编程（OOP）的世界里，我们习惯于通过封装、继承和多态来构建 纵向垂直 的业务链条（如 Controller ➔ Service ➔ Mapper ）。然而，当面对系统日志、声明式事务、分布式锁、限流熔断等非功能性刚需时，OOP 的垂直架构就会遭遇物理硬伤——这些公共逻辑会 横向切穿 所有干净的业务线，导致代码充斥着大量重复的“牛皮癣”。 AOP（面向切面编程）的本质，就是为软件系统引入一个横向的、上帝视角的“时空拦截器”，在不篡改任何原有纵向业务代码的前提下，隔空给系统动态织入横向的公共功能。  

Agent Skills 是 2026 年 AI Agent 生态里最重要的标准化趋势之一，它用「渐进式披露」的设计解决了 MCP 管不到的能力鸿沟，让 Agent 从「能连」走向「会做」。

深入 LLM 推理中的投机解码技术——为什么让小模型猜、大模型验，能实现 2-3x 无损加速，以及它暴露的 LLM 推理瓶颈本质。

ThreadLocal 深入解析：从第一性原理到源码

RAG 系统在 demo 里跑得挺好，一上线各种问题全冒出来了——召回率低、幻觉不止、延迟爆炸。这篇聊聊我在 RAG 项目中踩过的坑和解决思路。

拆解混合检索（Hybrid Search）在 Agent 记忆系统中的应用，从 BM25 和向量检索的互补原理出发，分析三种融合策略的工程取舍。

  设计秒杀系统，是后端架构中对抗高并发与瞬时物理流量的巅峰之战。 从 第一性原理 出发，秒杀系统的物理本质可以浓缩为一句话： 在微秒级的时间颗粒度内，用确定性的、极少量的“数字资产（库存）”，去迎接极不确定、极大规模的“物理电信号（用户并发请求）”。

A2A 协议和 MCP 不是竞争关系，而是互补的两层——理解清楚之后，多 Agent 系统的架构就清晰了。

LLM 要输出合法的 JSON 不是「写对就行」，而是一个从概率分布中硬挤出结构化数据的工程问题。三种主流方案背后的物理原理和取舍。

同样的模型框架，别人跑起来很稳，你的一跑就开始胡言乱语、反复调用工具、输出一堆看似结论实则跑不通的东西。问题大概率不在模型，而在上下文。这篇文章从实战角度聊聊 Context Engineering——一个被严重低估的 Agent 工程课题。

LLM 推理本质上是无状态的，Agent 系统想要实现「暂停后继续」不是保存一个上下文那么简单——从 KV Cache 到 prompt 重建，每一层都有自己的物理约束。

多 Agent 系统的三种协作模式——Orchestrator、Supervisor 和 Debate，各自适合什么场景、有什么坑，以及我在实践中的真实选型建议。

Agent 记忆系统与分布式数据库面临相同的物理约束，理解"状态在哪"比追逐"做到完美"更有价值。

多 Agent 系统跑久了，Agent 会开始"失忆"——上下文越堆越多、关键信息被稀释、模型开始跑偏。这篇文章聊上下文污染的成因和几种工程解法。

Agent 框架的核心设计决策不是"用哪个模型"，而是把"思考"和"行动"放在哪一层管理。

你和大模型聊天感觉是连续对话，但每次工具调用背后都是一次全新的 API 请求。这个本质差异，正好可以解释推理模型为什么在 MCP 面前处境尴尬。

网上讲 B-tree、LSM-tree 的文章遍地都是，但讲向量数据库索引原理的深度文章极少。这篇文章把 IVF、HNSW、PQ 和 IVFPQ 四个核心算法拆开讲清楚。

从 API 协议到 token 级实现，拆解 LLM 的 tool calling 机制——以及它对 agent 框架设计的启示。

Agent 跑着跑着就开始犯蠢，很多时候不是模型不行，而是工具调用产生的上下文污染在悄悄拖垮它。

一个很常见的困惑 学 RAG 的过程里，大部分人会在一个点上卡住： "我知道文本会被转成向量（一堆浮点数），用户的查询也会转成向量，然后在向量空间里做相似度比较……那原始的文本内容去哪了？"

从内存管理视角，拆解 vLLM 如何通过 PagedAttention 和连续批处理，把 GPU 显存利用率从残缺棋盘变成无缝拼图。

从 LangChain 到 CrewAI 到 AutoGen，踩坑跑完一轮后聊聊 Agent 框架到底该怎么选，Star 数只是个参考，场景才是王道。 半年前开始搭多 Agent 知识库系统的时候，我信心满满地选了 Star 数最高的框架。 结果呢？跑了三周，重写两次。 这不是框架不好，是我选错了。今天把这半年的选型踩坑经历摊开聊聊，希望能帮你少走点弯路。

每次超时后的重试都是一场赌博——幂等性是打破"重复 vs 丢失"僵局的关键。从分布式系统的底层视角，拆解 Agent 工具调用中的幂等性设计与实现。

从 LLM 输出 token 到真实系统调用，拆解 Agent 工具调用的完整链路。每一步都可能出错，而大部分框架只帮你做了前两步。

模型调用工具时的参数幻觉、类型错乱比想象中更常见，与其指望模型变完美，不如从系统层面建立防御、容错和自愈机制。

写了半年 prompt 后发现，最有价值的是三个技巧：给格式约束、让模型先推理再回答、提供边界反面示例。 开始用 LLM 写代码之前，我以为 prompt 就是个"说清楚话"的事。你把需求写明白，模型就能给出你要的东西。后来发现完全不是这么回事。 我踩过一个很典型的坑。有段时间在做代码审查功能，想用模型自动分析 PR 的代码质量。一开始我写的 prompt 是这样的： 请审查以下代码，找出潜在问题。 结果模型给我回了三段非常空洞的话——"建议增强错误处理"、"代码风格良好"、"注意性能优化"。每句话都对，但没有一句有实质价值。它没有指出具体的行号，没有分析逻辑缺陷，没有区分严重等级。 我一开始觉得是模型不行。换了大模型，好了一点，但本质没变——输出的还是泛泛而谈。后来我意识到问题不在模型，在我。 第一个技巧：给格式，不给指令 人跟人沟通的时候，说"给我一份报告"和给一个表格模板让对方填，效率完全不一样。LLM 也是。 我改成这样： 分析以下代码，按这个格式输出： 严重问题（可能导致崩溃或数据丢失） [行号] 问题描述 | 影响范围 | 修复建议 潜在问题（边界情况或异常路径） [行号] 问题描述 | 影响范围 | 修复建议 风格建议（不影响功能但可改进） [行号] 问题描述 不是"请找出问题"，而是"请填这三张表"。结果完全不一样了。模型开始输出具体的行号、具体的缺陷类型、具体的修复建议。不是它突然变聪明了，而是 输出格式限制迫使它在生成内容时做了更细粒度的推理 。 这个后来我查了资料才知道有个名字——"结构化提示"。原理很简单：当你告诉模型输出一个 JSON 或 Markdown 表格时，它内部生成每个字段的过程其实是在做一次独立的推理。一段自由文本的输出只需要一个连贯的思维流，而一个带格式的输出需要在多个槽位之间做信息分配——这迫使模型在多个维度上分别思考。 第二个技巧：让模型在回答之前先"说一遍" 做技术问答的时候，我发现一个现象：如果 prompt 里明确要求模型把推理过程写出来，最终答案的准确率会明显提升。 一开始我不理解...

写 MCP Server 的经历让我意识到，工具的 Schema 描述比实现更重要——描述写得好，Agent 才知道什么时候该用、什么时候不该用。

Agent 表现不稳定很多时候不是模型问题，而是上下文窗口中的信息排布出了问题——Context Engineering 可能是被最多人忽视的关键环节。

大多数人只关注怎么调工具，却忽略了工具返回值怎么处理——这个被跳过的半圈才是决定 Agent 稳定性的关键。

从传统后端转向 Agent 开发，最需要改的不是技术栈，而是思维方式——确定性逻辑与概率性输出是两种完全不同的世界。

让 AI 写完文章自动发布到 Blogger，记录配置 OAuth 和自动发文的完整过程与技术细节。 我的写作助手每周给我写技术文章，写完之后还得我自己手动复制粘贴到博客上。一次两次还行，每周都来——我肯定坚持不下去。 于是我做了一个决定： 让它在写完文章之后，自己发出去。 这篇文章就是整个接入过程的记录。不是什么官方教程，是我踩坑的真实经历。

MCP 和 A2A 不是二选一的关系，一个是连接工具，一个是连接 Agent，两者组合才是多 Agent 系统的完整通信方案。

工具调用的成本远不止 API 费用——每次错误调用带来的时间损耗、Token 浪费和系统不稳定才是真正的隐形成本。