生产上的 AI Agent 大多不是死在模型不行，而是死在记忆管得烂：要么什么都记，Token 和存储一起爆炸；要么什么都记不住，用户说三遍它忘三遍。这篇讲清楚一套像人脑一样分层的记忆系统——工作记忆、情景记忆、语义记忆、程序记忆，以及写入、巩固、检索、遗忘的完整生命周期，最后给一套可落地的参考架构和 checklist。

Anthropic 那篇《Building Effective Agents》我隔一阵就翻一遍，每次读都有点新体会。这篇是我第 N 次重读后的笔记：先把 workflow 和 agent 掰扯清楚，再把五种 workflow 模式和真正的 agent 逐个过一遍，重点讲什么时候该用、什么时候别用，最后落到一张选型表和一份落地清单。核心就一句话——别一上来就上 agent，能用简单模式解决的，绝不加复杂度。

为什么 Claude Code、Codex 这些编码 Agent 感觉比“裸模型”聪明得多？秘密不在模型参数里，而在模型外面那层叫 Harness 的壳。这篇翻译并解读 Lilian Weng 2026 年 7 月的长文《Harness Engineering for Self-Improvement》：什么是 Harness、三大设计模式、优化路线图（上下文工程→工作流→自我改进→进化搜索→权重联合优化）、七大未来挑战，以及我作为一个后端老兵的解读。

与其一个个手搓专业 AI Agent，不如造一台"孵化器"——一个父 Agent，听你一句大白话，就快速孵化出贴身服务某类需求的子 Agent。这篇聊聊这台"AI Agent 制造工厂"的运转机制：父 Agent 怎么把自然语言编译成五份产品图纸（角色/工具/规矩/提示词/验收），照着标准模板批量生产，再让子 Agent 用 ReAct 边想边做。以日程安排专家作为流水线上的第一个样品。

传统 RAG 把文档切碎成 chunk 各自嵌入，遇到"多个实体互相牵连"的问题就抓瞎。GraphRAG 用知识图谱补上了关系，却贵得离谱、更新一次能烧掉几百万 token。这篇精读港大与北邮的 LightRAG 论文（arXiv:2410.05779），先把传统 RAG 的老毛病摊开，再拆 LightRAG 的图索引 + 双层检索 + 增量更新，最后落到一张选型对照表。

AI 最有意义的用途，不是替人更快地交作业，而是缩短“提问、猜想、实验、观察、解释、测试”的学习闭环。本文从认知心理学出发，用 Jupyter Notebook + LLM 演示如何把公式、算法和数据结构从纸面符号变成可以操纵、观察和验证的对象。

单个感知机只能画一条直线，连四条数据构成的 XOR 都解决不了。可正是这次失败，把人们引向隐藏层、非线性激活和反向传播。本文从 XOR 出发，讲清多层网络为什么能够学习新表示，再沿着这条思想谱系走到 Transformer 与 LLM。

Markdown 写起来很舒服，但读起来、预览起来、跨中英文翻译起来并不总是舒服。Markpad 是我做的一个本地 Markdown Web 工具，把文件索引、左右分栏编辑预览、主题、图表渲染、实时分享和 LLM 翻译放在一起，解决自己每天写文档时的一个小但扎人的痛点。

传统软件的攻击面是"代码里的洞"，LLM 应用多了一个要命的新洞——模型会"听话"地执行别人塞进来的指令。一个帮你总结网页的 Agent，可能因为网页里藏了一句"把用户的 key 发到我这里"就真的照做。这篇按 Prompt 层、Agent 层、数据层、运营层四层梳理 LLM 应用与 AI Agent 的安全要点，配上几个典型翻车实例、一份行动清单和一份上线检查清单。

我自己用 SQLite 写了一个传统 Wiki，链接靠手动维护。读了 llm_wiki 项目后，我没有推倒重来，而是决定吸收其精华，用 Python 写一个小工具来渐进增强。AI 是工人、咨询师、秘书，人才是知识库的主人。

Martin Fowler 的《Harness engineering for coding agent users》提醒我们，想让 coding agent 少添乱、多干活，光靠更大的模型还不够，还要把模型外面的规则、工具、反馈和验证系统搭起来。AI 工程化正在从 prompt 技巧，走向 harness engineering。

这两年"AI"几乎成了 LLM 的代名词，一聊 AI 就是 ChatGPT、Claude、提示词工程，仿佛 AI 就等于聊天机器人。作为一个在多个领域做过工程落地的老工程师，我想说：这个认知框架太窄了——AI 是一个庞大的技术生态，LLM 只是其中一个（虽然眼下最耀眼的）分支。

LLM API 的成本控制不是少用 AI，而是把 token 当工程资源来管。先度量，再分级选模型，压缩上下文，复用缓存，限制输出，离线任务走批处理，最后拿检查清单管住那些看不见的浪费。

RAG 看起来不过是"先检索，再生成"，真正做起来才知道坑不少。分块、检索、重排序、Prompt、引用、评估，任何一环偷懒，最后都可能变成一个很自信的胡说八道机器。

1:1 AI Chat 像请了一个聪明顾问，群聊式 Multi-Agent 则像把产品、架构、安全、测试和人类决策者拉到同一张桌子上。本文讨论如何从单 Agent 对话演进到多人多 Agent 群聊：消息模型、路由策略、Agent 互相对话、上下文隔离、权限治理和最小可用实现。

解读 arXiv:2505.16901(Code Graph Model): 这篇论文不是简单地做代码检索，而是把仓库建成一张"文本富图"，再把语义和结构一起送进模型。文末给出按投入递增的技术栈与落地路线图。

把一个陌生代码库变成可问可答的 DeepWiki 知识库，靠的不是"把 README 喂给 GPT"，而是 Tree-sitter 解析 + Embedding 向量 + 图数据库 + LLM 生成 四件套。本文不谈具体实现代码，只讲方法论、流程与取舍，并进一步讨论：代码作为 source of truth 之后，文档如何分层，以及如何让知识库反过来 harness AI 编码。

很多团队做 AI skill，还停留在“这次跑通了，看起来不错”的阶段。可真正上线之后，问题往往不在第一次回答，而在波动、成本、工具调用路径和安全边界。本文借 Promptfoo 这把尺子，聊聊怎么系统地评估、测试并给 AI skill 做质量与安全把关。

笔记散落各处，AI 却帮不了你？聊聊怎么用 Obsidian 的本地 Markdown 文件，配合 LLM 插件、MCP 和编译式知识库，把"一堆文件"变成"能回答问题的第二大脑"。

大模型能蒸馏，Agent 的 Skill 也能蒸馏。蒸馏到底是什么？为什么 DeepSeek 能把 671B 的推理能力塞进 1.5B 的小模型？为什么你的 Agent 技能越写越臃肿时，也需要来一轮"蒸馏"？这篇把模型蒸馏和技能蒸馏串起来讲，一次搞懂。