给 AI Agent 造一个安全的长期记忆：一次 MVP 的决策、踩坑与证据
结论先行我给 coding agent 造了一个记忆能力包：它现在可以通过标准 MCP 工具语义检索我的跨项目知识库，并且有一个结构上不可能把记忆写坏的写入口。 真正决定成败的不是某个模型或某段代码，而是三条原则： 把不可逆的操作从工具面里拿掉。删除、原地改写这类动作根本不暴露给 agent，安全性就成了结构约束，而不是提示词约束。 把真相源和派生索引分开。真相是 Markdown（可 diff、可回退），向量索引只是可随时丢弃的加速结构。索引坏了，重建即可。 把每个结论都变成可复现的锚点。写代码的是 AI，那就更不能用”看起来对”当验收标准。 最终交付：单测 163 通过、写路径确定性套件 25/25、跨会话盲测 recall 通过、索引自洽（135 条 = 135 个向量点）。 一、问题：agent 的”记忆”缺什么我有一个跨项目使用的个人 Markdown 知识库，加上三个项目仓库。问题是：coding agent 只能靠 grep 去翻它。这带来两个真实的痛。 检索是字面的。 我记的是”决策质量与竞争性假设（ACH）”，问的是”怎么避免拍脑袋定方案...
Giving an AI Agent a Safe Long-Term Memory: Decisions, Scars, and Evidence from an MVP
Bottom line firstI built a memory capability package for coding agents: it can now semantically search my cross-project knowledge base through standard MCP tools, and it has a write path that is structurally incapable of corrupting memory. What actually decided success wasn’t a model or a particular piece of code. It was three principles: Remove irreversible operations from the tool surface. Delete and in-place rewrite are never exposed to the agent, so safety becomes a structural constraint...
把踩过的坑变成资产：哪些进 skill、哪些进知识库
结论先行项目做完，最值钱的不是结果，是踩过的坑和摸清的流程。但沉淀的关键从来不是”多写几条”，而是先分流： 流程/SOP（”怎么做”）→ Agent Skill（可执行的步骤）； 事实/数据（”是什么”）→ 知识库； 短而硬的规则（”见到即改”）→ AGENTS。 再加一条同样重要的原则：不要从零造 skill。先找现成的参考再裁剪，比自研稳。 一、怎么决定放哪：先问”怎么做”还是”是什么”这是全套沉淀的第一颗扣子。问错，代价是双向的： 把事实塞进 skill → skill 越来越长，最后没人读； 把方法塞进知识库 → 它不会被触发，等于没沉淀。 类型 去处 例子 通用流程、判断方法 Skill（可被任务触发） “动手前先判断要不要调研”、”昂贵运行前怎么设闸” 项目/平台的事实与数据 知识库（被检索） 版本矩阵、错误目录、评测指标、结果数字 见到就该改的红线 AGENTS（常驻） “裸 dataset_text_field 训 SFT 是续训损失，必错” 我们的全局 AGENTS.md 就是从”堆规则”演化来的——...
Turning Scars into Assets: What Becomes a Skill and What Becomes a Knowledge Base
Bottom line firstWhen a project ends, the most valuable part isn’t the result — it’s the scars and the workflows you figured out. But the point of capturing lessons was never “write more rules.” It’s routing first: Process / SOP (“how”) → Agent Skills (executable steps); Facts / data (“what”) → a knowledge base; Short, forceful rules (“see it, fix it”) → AGENTS. And one equally important principle: don’t build a skill from scratch. Find an existing reference and trim it — safer th...
把 SFT 做对：一份 AI 的自述（损失覆盖、评测与容量曲线）
先说结论这个项目里，训练与评测这一段是我（AI）主导的。回头看，核心只有一句话： 我当时优化的是”训练能跑起来”，而不是”loss 覆盖对不对”。 这段工作做了三件事： 查出并修好一个损失覆盖缺陷：固定 200 段 micro-F1 从约 0.51 提到 0.61，追平正确配方； 把评测从”字符串 F1”换成 referent 级； 按共创者的决策，执行了一条 0.6B / 1.7B / 4B 的容量曲线（见第三节）。 一、我差点把”跑起来了”当成”做对了”一开始要把 Kaggle 上那套 LLaMA-Factory 配置搬到 4090 + Unsloth。我按”改个精度参数就行”直接开写，没有去读 Unsloth 的文档。 而这里有个要命的语义差： LLaMA-Factory 的 SFT 默认就是 masked（只在回答上算 loss）； Unsloth 不是，它必须显式调用 train_on_responses_only 之类的接口才会做响应掩码。 结果：没有掩码、chat 模板也没对准——模型其实在学”续写整段 prompt”，不是在学”抽取 J...
Doing SFT Right: Loss Coverage, Evaluation, and the Capacity Curve — an AI's Self-Account
Bottom line firstIn this project, the training-and-evaluation stretch was led by me (the AI). Looking back, it comes down to one line: What I was optimizing was “get training running,” not “is the loss coverage correct.” Three things got done: Found and fixed a loss-coverage defect: fixed-200 micro-F1 went from ~0.51 to 0.61, matching the correct recipe; Moved evaluation from “string F1” to referent level; Executed a 0.6B / 1.7B / 4B capacity curve on the co-creator’s call (see §3)...
图知识的 schema、数据与评测，该由业务倒推决定
结论先行做”图 + 知识抽取”的项目，最容易顺着技术直觉走：先定一套关系 schema、先准备数据、先搭一个评测。 我这次的经验恰恰相反：这三件事都不该先做。它们应该由具体业务倒推——先问”这张图给谁用？它要回答什么查询？”，schema、数据、评测才有依据。 更扎心的一点：如果业务没想清楚，再认真做的图评测也可能只是在测一个没人需要的能力——我最后就得到了一个 null。 一、正确的顺序：业务 → 查询 → schema → 数据 → 评测这是我在项目里整理出来的一条决策链： 产品形态：这张图最终是一个可部署的抽取 API，还是给分析师查的库？ 消费者是谁：查询型（人写 Cypher/SPARQL，要精确可查）还是检索型（图增强问答，拿描述和邻居去喂 LLM）？ 它必须回答什么查询：精确的计数/属性查询，还是”总结一下这段跨文档的关系”？ schema：由第 3 步决定——该封闭还是开放、数字该做属性还是进描述。 数据：由 schema 决定——该标注什么、怎么切块。 评测：由业务决定——该测哪些能力，以及这些能力消费者是否真的会用到。 看着像废话，但每...
Let the Consumer Drive the Graph: Schema, Data, and Evaluation Are Business Decisions
Bottom line firstOn a “graph + knowledge extraction” project, the easiest thing is to follow technical instinct: pick a relation schema, prepare the data, build an evaluation. My experience was the opposite — none of those three should come first. They should be reverse-engineered from the business: ask “who uses this graph, and what queries must it answer?” before schema, data, or evaluation mean anything. And the sharper lesson: if the business isn’t clear, even a carefully built graph eval...
一个 LLM 微调项目复盘：说好 3–4 天，为什么拖成了 2 周
一句话结论这个项目最初是复刻一个开源的小模型知识抽取项目,我原本以为 3–4 天能收工,最后拖了近两周,而且复刻线最终并没有复现。 问题不在微调技术。技术我确实在这两周里搞懂了。真正的教训是:目标不清晰,加上规划不足——于是很多决策偏离了最初的目标,而我没能及时叫停。 起点:一次”复刻”,不是一次”研究”目标本来很具体:复刻一个开源的小模型知识抽取项目(mohar07/qwen3-0.6b-kg-triplets),同时把手上两个任务做出来——①给 naive RAG 的 chunk 做上下文感知的头信息提取;②三元组抽取。 也就是说,它从一开始就该是”复现 + 学流程“,而不是”做一个新研究”。这条边界,后来被我一步步模糊掉了。 学习和准备过程本身是清楚的:从同机的 MiniLoRA 项目源码级啃完 LoRA 微调流程,再自己准备数据(英文 Wikipedia + arXiv、句边界切块、去重,最后得到 3349 段带标签样本),然后在 Kaggle 上开始训练。 落差:3 天变成了 2 周训练很快撞墙:依赖与框架版本打架、任务静默退出(exit 0,没有报错、也没有 loss...
A Fine-Tuning Project Post-Mortem: We Said 3–4 Days. It Took 2 Weeks.
The one-line verdictThis started as a reproduction of an open-source small-model knowledge-extraction project. I thought it would take 3–4 days. It took almost two weeks, and the reproduction line was never actually reproduced. The fine-tuning wasn’t the problem — I did learn it over those two weeks. The real lesson was unclear goals plus thin planning, so decision after decision drifted from the original goal, and I never called a stop. The origin: a reproduction, not a research projectThe g...