几乎每个 Agent 项目都说自己有「长期记忆」。
有的意思是把聊天记录做 embedding，有的意思是维护一份用户画像，有的意思是让模型自己修改 Markdown，还有的已经做到了双时序知识图谱。它们都叫 memory，却不是同一种东西，也不该放在一张跑分榜上直接比较。
要判断一个系统是不是真的「会记」，我更愿意问三个问题：
一次经历之后，系统里的什么状态发生了变化？ 这个状态存在哪里，谁能修改，什么时候失效？ 下一次行动前，它如何被准确、合规地带回来？ 这篇文章从这三个问题出发。前半段把人类记忆科学与 Agent 记忆技术放在同一条历史轴上；后半段直接读代码，对照 Mem0、Letta、Graphiti、LangMem、Cognee 与 MemoryOS 的宣传卖点、实际数据流、系统边界和对应的记忆范式。
先给结论： 今天主流的 Agent 并没有获得一种像人脑那样的统一「记忆器官」。工程上真正有效的是一条闭环：经历 → 写入门控 → 表征 → 存储 → 检索 → 上下文组装 → 行动反馈 → 巩固 / 修订 / 遗忘。不同开源项目，只是选择接管这条闭环的不同部分。 下面这张图不是某个产品的组件架构，而是全文共用的判断坐标系。它要回答的不是「数据放在哪」，而是「一次过去的经历如何真正影响下一次行动」。阅读时先沿中间的七步主环看信息如何从经历变成行动；再看左侧三种载体，区分当前任务、跨会话记忆与真实世界状态；右侧说明每一步完成的变换，底部则展示长期运行后必须发生的巩固、修订与遗忘。这样能避免把数据库、Context、缓存和真实状态都笼统地叫作“记忆”。
··1306 字·
7 分钟
阿里云 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 流，就已经过关。
··561 字·
3 分钟
OpenClaw 的 daily-ai-news 定时任务连续超时。根因不是模型不够强——是 SKILL.md 里少写了一行绝对路径，导致 Agent 每次花 15 次 exec 搜索工具位置。消息数 165→54，exec 调用 44→7，一行路径比任何算法调优都管用。
··544 字·
3 分钟
OpenClaw 记忆系统的向量检索默认不可用——但 BM25 文本搜索兜底让系统照常运转了两周。当你发现「不配 embedding 也能跑」，到底要不要修？怎么用 NVIDIA 免费 API 零成本补上？
··1258 字·
6 分钟
真正的变化不是“又多了两个工具功能”，而是 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 是最具范式转移意义的两项。
··1660 字·
8 分钟
从部署到排障，记录 OpenClaw 从启动失败、飞书消息静默吞回复到 production 稳定的全链路实战经验——compaction safeguard、五层排查法、model-harness-fit 与记忆系统对比。
··692 字·
4 分钟
2026 年 4 月，我们把 seo-project 的任务队列从 Celery 全面迁移到了 Temporal。删除的依赖只有一个（celery），新增的核心代码有 11 个文件（src/infrastructure/temporal/），容器从 api/worker/beat 变成了 api/temporal_worker_blue/green（蓝绿部署）。 这件事做完后，最常被问到的问题是：为什么不用 Celery？已经能跑的东西换它干什么？
这篇文章就是答案。它不来自文档对比，来自生产环境跑 Agent 流水线时逐条撞上的坑。
这张图先划清两个工具的问题层级。Celery 负责把任务交给 Worker；Temporal 额外保存事件历史，让多阶段流程能够从故障点恢复。迁移的核心不是换一个更快的队列，而是获得可重放的状态机。
Celery 与 Temporal：前者擅长分发独立异步任务；后者用事件历史、检查点与重放语义支撑长时多阶段流程。C 阶段失败时，关键差异是整批重试还是从 C 恢复。 Celery 能做的事，为什么在 Agent 场景里开始不够用 # 先说清楚一个基本判断：Celery 是好工具。对于"发封邮件、生成一张缩略图、推送一条通知"这类标准异步任务，它完全够用，工业界跑了十几年。
但我们跑的负载和这不一样：
1 2 3 4 5 6 一个 Run 包含 N 条 longtail 每条 longtail 跑 A → B → C → D 四个 Agent 阶段 每个阶段调一次或多次 AI API 总耗时任意一条都在 60-180 秒区间 每一步的中间结果需要持久化 任何一步失败需要知道"停在哪、为什么、能不能只重试这一步" 这是有状态的、长时的、多阶段的业务流程。任务队列和业务流程引擎之间的分界线，就在这里。
··508 字·
3 分钟
更正说明（2026-07-29）
本文初版把“公司名出现在优惠码中”“结账页由 Stripe 承载”和社区里的传播记录拼成了一条过于确定的故事：代码由 Stripe 合作伙伴网络发放，再由合作企业员工泄露。现有证据不足以支持这条因果链。
修订后的结论是：这些活动更可靠的上游是 OpenAI 的合作伙伴/渠道活动；Stripe 是支付与促销码基础设施，而不是已被证实的活动发起方。公开链接、表单审核后邮件发码、合作伙伴自费返利等不同机制同时存在，也没有证据证明 OpenAI 已在全球统一取消公司级 /p/... 链接。
2026 年 5 月，一批带有公司名称的 ChatGPT Business 优惠码在 linux.do 等社区传播。初版文章试图回答“这些码从哪里来”，但把若干合理猜测写成了事实。 这次重查只保留能够由一手页面或可复核时间戳支持的部分，并明确区分：
··443 字·
3 分钟
做 Agent 系统的人迟早会撞上这个选择题：用户的数据往哪放，下次对话怎么记住？ 目前工业界有三条主流路线——RAG（向量检索）、LLM Wiki（结构化知识注入）、纯文本上下文记忆（CLAUDE.md / Cursor Rules 模式）。三条路各有拥趸，但选错的代价很大：RAG 做轻了是噪音生成器，纯文本做重了是 token 焚化炉。
这篇给出一个可以直接用的决策框架。
先看三条路线的系统边界。它们的核心差异不是数据库品牌，而是检索发生在什么时候、多少内容进入 Context、写入和维护由谁负责。
三种记忆路线：RAG 擅长从大规模异构资料中按需召回；LLM Wiki 强调结构与审计；纯文本适合少量高价值、需要确定性注入的规则。没有一条路线在所有维度都占优。 三种方案一句话定义 # 方案 核心机制 代表产品/模式 RAG 向量检索 → top-k 片段 → 拼入 prompt Mem0, Zep, LangChain RAG, Cursor Codebase Index LLM Wiki 结构化文档 → 全量或按需注入 system prompt Claude Projects, GPTs Knowledge, Notion AI 纯文本上下文 Markdown/文本文件 → 直接拼入 system prompt CLAUDE.md, Cursor Rules, AGENTS.md, Devin Knowledge 关键区别不在于"存哪里"，而在于检索方式和注入时机。
··63 字·
1 分钟
Hugo 用 shortcode 可以很优雅地内嵌代码演示。这里展示三种方式： 先用一张图确定边界：原生 shortcode、CodePen iframe 和 CodeSandbox 分别适合不同复杂度，也把代码放在不同的执行与隔离位置。
三条嵌入路径：简单且需要版本控制的效果优先用原生 shortcode；可分享片段适合 CodePen；完整交互应用再使用 CodeSandbox。 1. 内联 CSS demo（无需外部服务） # 直接在文章里跑一个旋转加载动画：
纯 CSS 旋转加载器
一个渐变色文字动画：
