DEV Community: KIM · 风雷益 FENGLEI YI

Your Next Meeting Can Run Itself. This Free AI Debates Every Angle for You

KIM · 风雷益 FENGLEI YI — Sat, 15 Aug 2026 16:26:58 +0000

Meetings are the biggest time sink in modern work. You sit in a room, listen to one person talk for an hour, and leave with nothing decided. Every meeting is a single story, told from a single angle.

What if a meeting could argue with itself?

Meet Multi-Perspective Meeting, a free open-source tool that turns one topic into a full multi-sided debate. You type a subject. Five AI agents with five different viewpoints analyze it. Each one challenges the others. Then everything is merged into a complete meeting report, with decisions, risks, and next steps.

This is not academic theory. This is a tool you can try right now in your browser. No install. No signup. No credit card.

What can you use it for?

Product decisions. Before you ship a feature, let the product, engineering, design, marketing, and support perspectives tear it apart. You will see the risks before your users do.

Research and study. Test a hypothesis from five angles. Find the holes in your own logic before a reviewer does.

Debate practice. The system argues both sides. Watch it defend a position, then destroy it. You learn faster than any single reading.

Brainstorming. Five agents, five directions, one merged result. Your next idea is already in the output.

Here is how it works. You give it a topic. It assigns multiple roles to multiple perspectives. Each agent presents its view, responds to the others, and the final report combines everything into a structured meeting note with key points, disagreements, decisions, and action items.

Try it now.

Live demo: https://kim-fenglei.github.io/multi-perspective-meeting/run.html

Watch it run: https://kim-fenglei.github.io/multi-perspective-meeting/demo.gif

The code is open source, free, and MIT licensed.

GitHub: https://github.com/Kim-FengLei/multi-perspective-meeting

Stop preparing meetings. Let the AI debate it. You just show up and decide.

More from FENGLEI YI: https://xuanyuange.club:8443/fenglei/

I Migrated to Godot 4 and Hit These GDScript Traps. Here Is What Fixed Them

KIM · 风雷益 FENGLEI YI — Fri, 14 Aug 2026 16:07:31 +0000

Godot 4 is a great engine. The migration from Godot 3 is not. When I moved a real project from Godot 3 to Godot 4, I did not hit one or two problems. I hit a wall of them. Constants renamed, APIs moved, methods removed, types that stopped existing, parser errors that made no sense, and a few hours lost to each. Every pitfall in this article is one I actually hit. Every fix is one I actually shipped. No theory, no speculation, only the traps that cost time and the corrections that worked.

If you are migrating to Godot 4, or if you have already migrated and some error message keeps showing up, this article will save you hours. And at the end I share the full open source guide I distilled from all of this, so the lessons never get lost again.

Trap One, Custom Classes Cannot Be Const Types

In Godot 3 I used to write things like this without thinking.

const _instance: GameServiceManager = null

In Godot 4 this is a compile error. A const declaration cannot use a custom class as its type annotation. The fix is simple, use a plain var instead.

var _instance = null

This one cost me maybe ten minutes. The next one cost more.

Trap Two, Abstract Classes Cannot Be Instantiated

I tried to create an audio generator directly.

var silence = AudioStreamGeneratorPlayback.new()

That is a compile error too, because AudioStreamGeneratorPlayback is abstract. Godot 4 refuses to construct it. You have to obtain it through an AudioStreamPlayer or another valid path. Common abstract classes in Godot 4 include AudioStreamGeneratorPlayback and XRInterface. If you see an error saying a native class cannot be constructed as it is abstract, do not fight it. Find the factory method that gives you the instance.

Trap Three, Types That Do Not Exist

This one is sneaky because the type name looks perfectly reasonable.

var _recorder: AudioStreamRecorder = null

AudioStreamRecorder does not exist in Godot 4. It existed in Godot 3. The migration renamed or removed it, and the compiler simply tells you the type cannot be found. When you see could not find type in the current scope, the first thing to check is whether the type still exists in Godot 4 at all. Sometimes the right answer is to use Variant, or to use the replacement class. In this case AudioEffectRecord is the closest living relative.

Trap Four, Label Autowrap Constants Moved and Changed

I set label text wrapping the way I always had.

label.autowrap_mode = Label.AUTOWRAP_WORD_SMART

Godot 4 moved these constants from TextServer to Label, and the values changed. The safest path is to use the integer values directly.

const AUTOWRAP_OFF = 0
const AUTOWRAP_ARBITRARY = 1
const AUTOWRAP_WORD = 2
const AUTOWRAP_WORD_SMART = 3

label.autowrap_mode = 2

The lesson is general. When you migrate, do not trust that a constant name survived. Check where it moved and whether its value changed. The same applied to my BoxContainer alignment code.

bubble.alignment = BoxContainer.ALIGNMENT_START

That constant is gone. In Godot 4 the alignment values are integers, and the mapping is not what you expect. ALIGNMENT_BEGIN is negative one, ALIGNMENT_CENTER is zero, ALIGNMENT_END is one. So the correct code uses raw numbers, and you have to be careful which one means which.

Trap Five, PhysicsRayQueryParameters3D Flags

I was doing a raycast and setting flags the old way.

query.flags = PhysicsRayQueryParameters3D.FILTER_MASK_ALL

FILTER_MASK_ALL does not exist in Godot 4. The replacement is two boolean properties.

query.collide_with_areas = true
query.collide_with_bodies = true

This pattern of a flag constant becoming two booleans shows up across the engine. When a constant disappears, look for the new property style instead of hunting for the same constant under a new name.

Trap Six, get_world_3d Moved to Node3D

In Godot 3 I could call get_world_3d from almost anywhere. In Godot 4, if your class extends Node and not Node3D, this call fails.

var space_state = get_world_3d().direct_space_state

The fix is to obtain the world through the active camera.

var cam = get_viewport().get_camera_3d()
var space_state = cam.get_world_3d().direct_space_state

The general rule for Godot 4 migration, if a method is suddenly unavailable, check which class it moved to. Godot 4 tightened the class hierarchy, and methods that used to live high up now live closer to where they belong.

Trap Seven, Array.pop_front Was Removed

This one broke a lot of my queue code.

var item = array.pop_front()

pop_front no longer exists in Godot 4. The replacement is pop_at with an index of zero.

var item = array.pop_at(0)

Same behavior, different name. This is the kind of rename that search and replace will not catch, because you have to know the new name exists.

Trap Eight, GDScript Uses Tab Indentation, Not Spaces

I had a method body that was not indented after its signature.

func _process(delta: float) with a void return type:
_process_wake_word(delta)

Godot 4 treats this as a parse error. GDScript requires Tab indentation. Mixing tabs and spaces causes mysterious parser failures that look like the parser is broken. It is not. It is the indentation. Use tabs consistently, and if you are coming from Python or JavaScript, unlearn spaces for this language.

Trap Nine, Complex List Comprehensions Can Break the Parser

GDScript supports list comprehensions, but the parser is not as forgiving as Python.

var story_text = "\n".join(spot.get("stories", Array.new()))

This can fail with confusing errors. The safe approach is to simplify, or use a traditional loop.

var story_text = "\n".join(spot.get("stories", Array.new()))

When a comprehension is doing too much, the parser chokes. Simplify it. Your future self will thank you.

Trap Ten, Autoload Singletons Do Not Need Class Name

I added class_name to an autoload singleton.

class_name GameServiceManager
extends Node

In Godot 4 this can cause circular reference errors, because the autoload is already registered globally. The fix is to remove class_name entirely. The singleton is managed through autoload, it does not need a global class name.

But removing class_name breaks type checks that referenced the class.

if child is GameServiceManager:
return child

With no class_name, that check fails to compile. The alternative is to check by node name.

if child.name == "GameServiceManager":
return child

This also means static methods cannot use the custom class as a return type.

static func get_instance() with GameServiceManager return type:

Without class_name, this does not compile. Use a base type instead.

static func get_instance() with Node return type:

The whole cluster of class name, type check, and static return type is a single design decision in Godot 4. Remove the class_name, and adjust all three places together.

Trap Eleven, Do Not Edit Files While the Editor Is Running

This one cost me a file. When the Godot editor is running, directly editing GDScript files can truncate them. The editor holds a lock on the project. The right workflow is to quit the editor, edit the files, then reopen the editor. I know it feels slower. It is faster than recovering a truncated file.

Trap Twelve, Unexplained Parse Errors, Clear the Cache

Godot 4 keeps a cache in the .godot folder of your project. When you see parse errors that should not exist, clear it.

rm -rf /path/to/project/.godot

This has fixed problems that made no sense at the code level. Do it before you go down a debugging rabbit hole.

Trap Thirteen, Check Your Brackets with a Script

A lot of mysterious Godot 4 errors trace back to unbalanced brackets in a file. Before opening the editor, run a quick bracket count.

with open('script.gd', 'r') as f:
content = f.read()

pairs = {40: 41, 91: 93, 123: 125}
for open_code, close_code in pairs.items():
print(chr(open_code), content.count(chr(open_code)), chr(close_code), content.count(chr(close_code)))

If any pair does not match, that file has the problem. This simple check has saved me more times than I can count.

The Error Message Quick Reference

After all this pain, I compiled a quick reference that maps the error message to the cause and the fix. It lives in the open source guide, but here are the highlights.

Cannot find member in base, means a constant or method does not exist in Godot 4. Check the API migration.

Function has the same name as a previously declared function, means you have a duplicate definition. Check the inheritance chain.

Expected closing bracket after array elements, means an unclosed array. Check multiline arrays.

Native class cannot be constructed as it is abstract, means you instantiated an abstract class. Use a factory method or subclass.

Could not find type in the current scope, means the type does not exist. Check the name, or use Variant.

Static function called from an instance, means you called a static function through an instance. Call it through the class name instead.

The Pre-Commit Checklist

Before committing Godot code, I now run this checklist every time. All brackets are balanced. All constants use correct values. All types exist and are correct. No abstract classes are instantiated. Tab indentation is used consistently. The Godot editor is closed before batch editing files. The cache is cleared before testing.

This checklist is boring. That is the point. Every item on it is a mistake I actually made, and the checklist exists so I never make it twice.

Why This Matters

Godot 4 is a better engine than Godot 3. The migration pain is real, but it is not random. Almost every trap follows one of four patterns. A constant moved to a new class. A method was renamed or removed. A type stopped existing. A syntax rule got stricter. Once you see the four patterns, you stop being surprised, and you start checking the right place first.

That is why I wrote everything down. Not to complain, but to turn pain into a reference. Every wrong example in the guide is a real compile error I hit. Every right example is the fix I shipped. No theory, no speculation. Just the traps that cost time and the corrections that worked.

Get the Full Guide

The complete collection is open source and free, with all thirteen traps in full detail, the error message quick reference, and the pre-commit checklist, formatted so you can install it as an agent skill for your Godot development workflow.

https://github.com/Kim-FengLei/godot4-gdscript-pitfalls

MIT licensed. Star it if it saves you time, fork it if you want to extend it, and share it with anyone who is migrating to Godot 4 right now.

Your engine got better. Your code can too.

Built by KIM, Founder of FENGLEI YI, 风雷益, 天施地生，其益无方. Technical exchange, kimsunjian@vip.qq.com.

Your AI Agent Has No Memory. Here Is a Memory System That Actually Learns

KIM · 风雷益 FENGLEI YI — Fri, 14 Aug 2026 16:02:30 +0000

Every AI agent I have built has the same disease. It remembers everything and learns nothing. The chat history grows, the context window overflows, the vector database fills up, and yet on the next task it starts from zero again, asking the same questions, making the same mistakes. If that sounds familiar, this article is for you.

I spent months fighting this problem in production. I tried bigger context windows, better embedding models, more sophisticated retrieval pipelines. None of it worked, because I was solving the wrong problem. The problem is not storage. The problem is learning. This article explains the mental shift that finally fixed it, and the complete four layer memory methodology I now use with every agent I build. It is open source, zero dependency, and you can apply it today.

The Warehouse Problem

Most agent memory systems work like a warehouse. One event happens, you record one entry. One conversation ends, you save one snippet. One bug is fixed, you drop one log. Over time the warehouse gets fuller, and the useful things get buried deeper.

Here is what actually happens after six months of this pattern. Your agent has ten thousand memory entries. Retrieval becomes fishing with a needle. You know the answer is in there somewhere, but the search returns noise. The agent ends up redoing work it already did, because the record of how it solved the problem last time is buried under nine thousand nine hundred entries about nothing.

I call this hoarding, not memory. A warehouse of facts is not the same as a learned skill. You can store a thousand deployment logs and still deploy wrong the next time, because none of those logs taught the agent a rule. Stored a lot, never really learned.

Why Vector Databases Do Not Fix This

Let me be direct. Vector databases, embeddings, RAG pipelines, these are retrieval infrastructure, not learning systems. They answer the question of how to find something. They do not answer the question of what deserves to be kept, or how raw facts become reusable judgment.

I built a system with a vector store, semantic search, everything shiny. It was fast and it was useless. Why. Because I was still recording everything, so retrieval was still noisy. Because I was still treating each record as a standalone fact, so no patterns ever emerged. Because nothing in the pipeline ever promoted a repeated lesson into a rule.

The infrastructure was excellent. The methodology was missing. That is the gap this article is about.

The Shift: Memory Is Training Data, Not Inventory

Here is the one sentence that changed everything for me.

A piece of information that cannot improve future judgment does not deserve long term retention.

Think of it that way and the whole design changes. Memory is not a place to keep things. Memory is training data. Its only job is to make the next decision better. If a record does not make the agent faster, more accurate, or more careful next time, it should not be in long term memory.

This leads to a second principle that matters just as much.

What can be promoted into a skill should not stay at log level.

Logs are raw ore. Skills are the refined weapon. The goal of a memory system is not to accumulate ore. The goal is to keep refining ore into weapons. When you see it this way, the entire architecture of your agent memory changes, and the four layer design below is the result.

The Four Layer Architecture

I organize long term memory into four layers. The higher the layer, the closer to learned. The whole job of the system is to keep pushing facts upward.

Layer one, world facts. These are the stable background facts of the collaboration. Who the user is and how they prefer to work. Where the project directory lives. What the deployment conventions are. What the current product direction is. This layer does not change often, but every task needs it. It lives in a single file called MEMORY.md.

Layer two, experience facts. These are traces of real actions. What changed in this round. How a problem was located. Which version was synced where. Which pipeline was verified working. This layer lives in daily logs named by date, for example 2026-08-14.md, and it is the raw material for everything above it.

Layer three, observations. These are patterns distilled from repeated facts. Why a certain type of problem keeps recurring. Where a certain testing convention tends to misjudge. How a certain type of requirement converges most reliably. This layer is where memory starts to become intelligence, because it is no longer about one event, it is about the rule behind many events.

Layer four, skills and mental models. This is the highest value layer. When a pattern is stable enough and will be used repeatedly, it stops being a memory and becomes a skill. It gets condensed into a skill pack, a standard operating procedure, a checklist, a judgment standard. From now on the agent calls the skill instead of searching the archives.

A real example makes this concrete. Early in my work I hit a frontend bug where several buttons on a page all stopped responding at the same time. I recorded it as an experience fact. A few weeks later it happened again, same symptom, different page. Now I had two facts, so I could form an observation. When multiple touchpoints fail at once on the frontend, check for a JavaScript syntax error first, because one broken script can take down every handler on the page. That observation became a layer four skill. Today my agent checks JavaScript syntax first whenever multiple UI elements fail together. It never has to rediscover that lesson again.

The Four Elements Every Memory Needs

Once you accept that memory is training data, the next question is what a well formed memory looks like. I require four elements in every effective memory entry, and I reject entries that lack them.

Time. When it happened. A date, a version, a milestone. Without time you cannot tell old facts from new facts, and stale information quietly poisons decisions.

Context. In what task or environment it happened. Deployment stage, testing phase, which project. Without context a fact is a floating island that nothing can connect to.

Conclusion. What the fact is and how it was solved. This is the part that actually carries value. If an entry only describes a symptom without a solution, it is not a memory, it is a complaint.

Next step. How to reuse it and what to watch out for later. This is the element that most people skip, and it is the one that turns a record into training. A deployment entry that ends with the rule, all long running processes must be started in background mode with nohup so they survive the session, is worth ten entries that just say, deployment failed today.

The Five Quality Gates

Before writing anything to long term memory, I run it through five gates. All five must pass, or the entry does not get written.

Reusable. Will this be needed again. If it is a one off fact with no future use, it does not belong in long term memory.

Has a conclusion. Is there a clear conclusion or solution. An entry that only describes what happened, with no lesson, fails this gate.

Has boundaries. Are the applicable conditions and risks stated. Mindless rules like always do this are dangerous. The rule needs to say when it holds and when it does not.

Retrievable. Can it be found later. If the entry has no context and no keywords, it will never be retrieved, so it might as well not exist.

Timely. Is the time or version marked. Old and new information mixed together creates false confidence.

The five gates have a beautiful side effect. They force the agent to think before writing. Most bad memory systems fail not because retrieval is bad, but because the writing gate is wide open and everything floods in. Close the gate and the whole system gets cleaner.

The Lifecycle: Write, Retrieve, Reflect, Promote, Clean

Memory is not write once and keep forever. It has a full lifecycle with five stages.

Write. Record per the four element rules, through the five quality gates.

Retrieve. Actually use it in later tasks. A memory that is never retrieved is decoration.

Reflect. After multiple uses, distill the stable pattern underneath.

Promote. When the pattern is stable, upgrade it into a skill or an SOP.

Clean. Expired, merged, or skill covered records get archived or deleted.

I run this on a cadence. Daily, at the end of the day, scan today's log and mark items that can be promoted. Weekly, summarize observation type memories and merge duplicates. Monthly, formally promote the stable patterns into skill packs. The cadence matters because promotion is not automatic, it is a discipline.

Three Layer Retrieval

Retrieval follows a strict order, and the order is the point.

Layer one, call the corresponding skill first if one exists. Skills are refined weapons. If a skill covers this type of task, use it. Do not go digging through raw history first.

Layer two, search recent memory, the MEMORY.md file and recent logs.

Layer three, only as a last resort, read raw logs and historical conversations.

The order must not be reversed. Most agents search raw history first, which is exactly why they drown in noise. The skill layer exists so the agent does not have to re derive the lesson every single time. And when retrieval fails, the system does not give up. It searches with synonyms, it expands from daily log to weekly log to special report, and if it still finds nothing, that is a signal the memory was poorly recorded, and it writes an observation about the retrieval blind spot so the system improves itself.

Four Common Mistakes

After using this system for months, I have a list of the mistakes that kill agent memory, and every one of them is a behavior, not a technical problem.

Mistake one, record everything. The belief that more records mean better memory. The result is bloat, slow retrieval, and useful information drowned in noise. The fix is the five quality gates.

Mistake two, record but never act. Entries are written and never reviewed, never promoted, so memory stays loose logs forever. The fix is the daily, weekly, monthly cadence.

Mistake three, record but never retrieve. The next task starts from zero anyway, so the memory is a museum. The fix is making retrieval a default action, check skills and memory first every time a task starts.

Mistake four, keep everything forever. The belief that deleting memory is a loss. In reality expired memory only interferes with judgment. The fix is cleaning on schedule and keeping the memory lean.

How to Start Today

You do not need a vector database to start. You need a file and a discipline.

Step one, create a MEMORY.md file with the stable facts about your project and your user. This is your layer one.

Step two, keep a daily log named by date, and write every experience fact with the four elements. Time, context, conclusion, next step.

Step three, at the end of each week, look at the daily logs and ask one question. What pattern showed up more than once. That pattern becomes an observation, and the observation is the seed of a skill.

That is the whole system in its simplest form. The full version in the open source project adds the writing rules, the retrieval techniques, the lifecycle management, the five quality criteria, the memory templates, and the common pitfalls, all formatted so you can install it directly as an agent skill.

Get Fenglei Memory

The methodology is called Fenglei Memory, and its motto is learn, don't store. It is open source, free, and MIT licensed.

https://github.com/Kim-FengLei/fenglei-memory

The repository contains the complete SKILL.md file that you can install directly into your agent, plus a full README with the architecture, the workflow, and the quick start. Star it if it helps you, fork it if you want to adapt it, and share it with anyone whose agent keeps forgetting.

Your agent already stores everything. It is time to teach it to learn.

Built by KIM, Founder of FENGLEI YI, 风雷益, 天施地生，其益无方. Technical exchange, kimsunjian@vip.qq.com.

Godot 4 GDScript Pitfalls: Every Mistake I Made So You Do Not Have To

KIM · 风雷益 FENGLEI YI — Thu, 13 Aug 2026 11:11:18 +0000

I spent months fighting Godot 4. The errors made no sense. The crashes came from nowhere. The worst part? The documentation told me the syntax, but never the traps hiding underneath.

So I wrote down every single mistake I made, and how I fixed each one. Now it is an open source guide called godot4-gdscript-pitfalls, and it is completely free on GitHub.

What is inside:

Signals and Callables. Connecting signals the wrong way, passing arguments that silently fail, and the one pattern that always works.

Nodes and Lifecycle. Why _ready runs before you think it does, and how to stop fighting the scene tree.

Typing and Inference. The type errors that only appear at runtime, and how to let the compiler protect you.

Resource and Memory. The leaks that eat your framerate, and the clean pattern to avoid them.

Every entry has the broken code, the error message, and the proven fix. No theory. Just mistakes that are real and fixes that are tested.

If you build games with Godot 4, this guide will save you the weeks I lost. Star it, share it, and never step on the same trap twice.

Special thanks to Marcus Kim. His feedback made this guide better: use named enums instead of magic numbers, pin your Godot 4 minor version, and run a headless project parse in CI. All three are now in the guide. One good comment can save a hundred developers.

Find it here:
github.com/Kim-FengLei/godot4-gdscript-pitfalls

How to Give Your AI Agent a Memory That Actually Learns

KIM · 风雷益 FENGLEI YI — Thu, 13 Aug 2026 10:16:30 +0000

Fenglei Memory · 风雷记忆 · 学而非存

Your AI agent keeps forgetting. You tell it your preferences, it nods, and next session it asks again. The usual fix is to store more: bigger context, longer logs, a vector database. But storage is not memory. A warehouse is not a brain.

Fenglei Memory is a zero-dependency methodology that teaches agents to learn from collaboration instead of just storing content. Here is how it works, and how to apply it today.

Step One: Record only what has long-term value

Do not dump every chat into memory. Before saving, ask one question: will I need this next week, next month, or in every future session? If yes, record it. If no, let it go. Raw facts are raw material, not the final product.

Step Two: Ask what you learned after every round

At the end of each collaboration, ask: what did I learn here? Extract the pattern, not just the event. A failed deployment is a fact. The reason it failed, and the check that prevents it next time, is the lesson. Store the lesson.

Step Three: Promote on repetition

When the same action repeats two or more times, or the same pitfall hits two or more times, promote it. Turn it into a rule, a checklist, or a skill pack. This is how raw records become reusable judgment. This is the difference between hoarding and learning.

The four layers

Fenglei Memory organizes everything into four layers. L1 World Facts: stable background like goals and conventions. L2 Experience Facts: traces of real actions and what changed. L3 Observations: patterns distilled from repeated facts. L4 Skills and Mental Models: stable patterns promoted into callable skills. The goal is to keep pushing facts upward, from raw records to reusable skills.

The full lifecycle

Write, Retrieve, Reflect, Promote, Clean. Daily, scan for promotable items. Weekly, merge duplicates. Monthly, formalize stable patterns into skill packs. Memory is not written once and permanent. It is maintained, like a garden.

Why it matters

Most agents today store a lot but never really learn. They can recall yesterday, but they cannot improve. A memory that learns changes that. Every session makes the agent sharper. Every mistake becomes a checklist. Every repeated task becomes a skill.

Get it

Fenglei Memory is open source and free, MIT licensed. Try it and give your agents a memory that actually learns.

https://github.com/Kim-FengLei/fenglei-memory

Built by KIM, Founder of FENGLEI YI, 风雷益, 天施地生，其益无方。

Learn, Don't Store — A Zero-Dependency Memory Methodology for AI Agents

KIM · 风雷益 FENGLEI YI — Thu, 13 Aug 2026 10:13:47 +0000

Fenglei Memory · 风雷记忆 · 学而非存

Most AI agents today treat memory like a warehouse: pile up every chat, every file, every context, and hope retrieval finds what matters. It doesn't work. Information grows, but the truly reusable methods get buried deeper every day.

Fenglei Memory takes the opposite approach. It teaches agents to learn from collaboration instead of just storing content, distilling reusable experience into sharper and sharper forms, until stable, callable judgment standards, operating procedures, and skill packs emerge.

Why It Matters

The old pattern usually looks like this. One event happens, then record one entry. One conversation ends, then save one snippet. One fix is done, then drop one log. The result: memory becomes a warehouse, retrieval becomes fishing with a needle. You have done it before, yet you still have to rethink from scratch. Stored a lot, but never really learned. That is not long-term collaboration. That is hoarding.

The Four Layers of Long-Term Memory

Fenglei Memory organizes memory into four layers, and the higher the layer, the closer to learned.

L1 World Facts: stable background such as leader, conventions and project direction, stored in MEMORY.md.
L2 Experience Facts: traces of a real action, what changed and how it was located, stored in daily logs named YYYY-MM-DD.md.
L3 Observations: patterns distilled from repeated facts, stored in MEMORY.md or spec docs.
L4 Skills and Mental Models: stable patterns promoted into callable skills, stored as skill packs, SOPs and checklists.

The goal is to keep pushing facts upward, from raw records to reusable skills.

Core Workflow

Record facts, only the ones with long-term value. Ask what did I learn in each round. Promote on repetition. Skills take priority over raw records.

Promotion triggers, any one of these. Same action repeated two or more times. Same pitfall hit two or more times. Forgetting once causes significant rework. The pattern holds across multiple tasks.

Memory is not written once and permanent. It has a full lifecycle: Write, Retrieve, Reflect, Promote, Clean.

Review cadence: daily scan for promotable items, weekly merge duplicates, monthly formalize stable patterns into skill packs.

What Makes It Different

Zero dependency: it is a methodology, not infrastructure. No vector database, no heavy framework, works in any agent runtime.
Skills over records: the end goal is forming mental models, not archiving.
Inspired by Hindsight: retain, recall, reflect, with the final destination being learned behavior, not a bigger archive.

Get It

Fenglei Memory is open source and free.

https://github.com/Kim-FengLei/fenglei-memory

MIT licensed. Star it, fork it, and give your agents a memory that actually learns.

Built by KIM, Founder of FENGLEI YI, 风雷益, 天施地生，其益无方。