跳过正文
Liu ZhuoQi

Liu ZhuoQi

AI 应用开发工程师(Agent 方向)

最近的文章

Agent 如何记住你:人脑记忆史与六大开源系统代码审计

几乎每个 Agent 项目都说自己有「长期记忆」。 有的意思是把聊天记录做 embedding,有的意思是维护一份用户画像,有的意思是让模型自己修改 Markdown,还有的已经做到了双时序知识图谱。它们都叫 memory,却不是同一种东西,也不该放在一张跑分榜上直接比较。 要判断一个系统是不是真的「会记」,我更愿意问三个问题: 一次经历之后,系统里的什么状态发生了变化? 这个状态存在哪里,谁能修改,什么时候失效? 下一次行动前,它如何被准确、合规地带回来? 这篇文章从这三个问题出发。前半段把人类记忆科学与 Agent 记忆技术放在同一条历史轴上;后半段直接读代码,对照 Mem0、Letta、Graphiti、LangMem、Cognee 与 MemoryOS 的宣传卖点、实际数据流、系统边界和对应的记忆范式。 先给结论: 今天主流的 Agent 并没有获得一种像人脑那样的统一「记忆器官」。工程上真正有效的是一条闭环:经历 → 写入门控 → 表征 → 存储 → 检索 → 上下文组装 → 行动反馈 → 巩固 / 修订 / 遗忘。不同开源项目,只是选择接管这条闭环的不同部分。 下面这张图不是某个产品的组件架构,而是全文共用的判断坐标系。它要回答的不是「数据放在哪」,而是「一次过去的经历如何真正影响下一次行动」。阅读时先沿中间的七步主环看信息如何从经历变成行动;再看左侧三种载体,区分当前任务、跨会话记忆与真实世界状态;右侧说明每一步完成的变换,底部则展示长期运行后必须发生的巩固、修订与遗忘。这样能避免把数据库、Context、缓存和真实状态都笼统地叫作“记忆”。

LLM 推理引擎怎么选——2026 年从本地单机到 PD 分离的全景选型地图

阿里云 CAP 有一篇讲推理引擎选型的文章,把候选收敛到四个:Ollama、vLLM、SGLang、Hugging Face Pipeline。这个划分在 2024 年是够用的。 但到 2026 年,它至少漏掉了半张地图——NVIDIA 的 TensorRT-LLM 完成了「PyTorch 化」转身、SGLang 因为首个开源复现 DeepSeek 大规模部署而封神、Hugging Face 自己给 TGI 挂上了「维护模式」横幅并劝你改用 vLLM,而整个 2025 年推理引擎领域真正的主线,其实是一个字:拆。 这篇文章把这张地图更新到 2026 年年中。它不替你拍板选哪个产品——它给你一套分层框架、一张决策矩阵和一棵决策树,让你自己把候选收敛到 1–2 个。 第一张图先解决最常见的比较错误:Ollama、KTransformers 和 vLLM 并不在解决同一层问题。先按本地运行、异构卸载与高性能服务划层,再在层内比较吞吐、格式和硬件支持,才有意义。 三层推理地图:L1 追求跑得起与安装简单,L1.5 用内存换显存,L2 追求并发、吞吐和多 GPU 服务。它是分类框架,不是综合排名。 为什么 2026 年「选推理引擎」才是个真问题 # 三年前不需要纠结这个。那时候能把一个 7B 模型在 GPU 上跑起来、返回还算流畅的 token 流,就已经过关。

Claude 工具调用范式转移:Programmatic Tool Calling 与 Dynamic Filter 深度解读

真正的变化不是“又多了两个工具功能”,而是 Agent 开始把多步工具编排移入代码执行环境,并只把压缩后的结果带回模型上下文。 背景:Agent 工具调用的成本困境 # 在传统 Agent 工具调用模型中,每调用一个工具都需要完成一次"模型推理 → 工具执行 → 结果返回 → 模型再推理"的完整回合。这个看似自然的循环,在工具调用变多时会暴露出三个致命问题: 上下文污染:每个工具的结果都被原封不动地注入上下文窗口。查 20 个员工的报销记录,2000+ 条费用明细全部进入 context,即使你只需要知道"哪 3 个人超预算了"。 推理开销:每个工具调用都需要一次完整的模型推理。5 个工具调用 = 5 次推理 pass,每次几百毫秒到几秒不等。 噪声导致准确率下降:当上下文窗口塞满了中间结果,模型不得不在大量噪声中寻找信号。Context Rot 研究 表明,LLM 在复杂任务上的性能会随上下文增长而下降 50-70%。 正如 Bruno 在 Claude Code Architecture Guide 中所指出的:“Outer Loop(模型外的一切:上下文管理、工具调用、验证、记忆巩固)开始比模型推理本身更决定系统质量。” Anthropic 在 2025 年 11 月到 2026 年 2 月间陆续推出的一系列工具使用增强功能,本质上都是为了解决 Outer Loop 的效率问题。其中 Programmatic Tool Calling (PTC) 和 Dynamic Filtering 是最具范式转移意义的两项。