同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

Tue, 05 May 2026 00:00:00 +0000

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

一句话开场

我手头有两个 AI Agent，核心代码量几乎一样：3110 行 vs 3084 行。但跑同一个任务——「给笔记画张架构图」——一个 8 秒搞定且越跑越准，另一个一分钟出来还经常翻车。差在哪？

主角登场

先认识下这俩。

O-easy Agent：我们自己用 Rust 写的小工具，专门干一件事——在 Obsidian 里读写笔记。5 个工具，3110 行代码。

GenericAgent：lsdefine 在 GitHub 开源的通用 AI Agent 框架（lsdefine/GenericAgent），口号是「不预装能力，让 Agent 自己长出来」。9 个工具，3084 行代码。

记住这两个数字：3110 和 3084。

它们差不多，但下文你会看到，能力差出一个数量级。这就是今天要说的事。

第一眼看不出门道，第二眼吓一跳

先把两边架构画出来。

flowchart TB
 subgraph OE["O-easy Agent (Rust · 3110 行)"]
 direction TB
 OE_main["ACP 入口"]
 OE_loop["Prompt Loop
max_turns = 10"]
 OE_tools["5 个笔记专用工具"]
 OE_mem["单层 history
(进程内)"]
 OE_main --> OE_loop --> OE_tools
 OE_loop --> OE_mem
 end

 subgraph GA["GenericAgent (Python · 3084 行)"]
 direction TB
 GA_main["Agent 主循环"]
 GA_loop["Agent Loop
~100 行 / max_turns = 70"]
 GA_tools["9 个原子工具
含 code_run"]
 GA_mem["5 层记忆
L0 → L4"]
 GA_evo["Self-Evolving SOP
(任务自动结晶)"]
 GA_main --> GA_loop --> GA_tools
 GA_loop --> GA_mem
 GA_mem -.写入.-> GA_evo
 GA_evo -.读出.-> GA_loop
 end

 style OE fill:#fef3c7,stroke:#92400e,color:#000
 style GA fill:#dbeafe,stroke:#1e3a8a,color:#000
 style GA_evo fill:#fbcfe8,stroke:#9d174d,color:#000

注意右下那块粉色的 Self-Evolving SOP。

这是 GenericAgent 的灵魂。它让 Agent「今天学会的事，明天直接做」。O-easy 完全没有这块。

下面拆开讲，差异在哪。

差异 1：5 个专用工具 vs 9 个万能工具

flowchart LR
 subgraph A["O-easy: 任务专用"]
 T1[read_note]
 T2[write_note]
 T3[edit_note]
 T4[search_vault]
 T5[list_notes]
 end
 subgraph B["GenericAgent: 原子万能"]
 U1[file_read]
 U2[file_write]
 U3[file_patch]
 U4["code_run ★"]
 U5[web_scan]
 U6[web_execute_js]
 U7[ask_user]
 U8[update_working_checkpoint]
 U9[start_long_term_update]
 end

 style U4 fill:#fde68a,stroke:#b45309,color:#000

O-easy 的 5 个工具都长一个样：xxx_note。它的能力天花板就是这 5 个事，写死了。

想画图？没工具。想跑统计？没工具。想抓网页？没工具。

GenericAgent 这边有个杀手锏叫 code_run。

这个工具的本质是「图灵完备的钥匙」。你想干啥它都能干——只要那件事能用代码表达。

💡 举例：让 Agent 给你画一张 mermaid 架构图

O-easy 怎么做：让大模型脑补输出 mermaid 字符串，写进笔记。没人验证语法对不对。

GenericAgent 怎么做：先 code_run 跑一段 Python 提取笔记结构 → 让大模型基于结构出 mermaid → 再 code_run 调 mermaid-cli 真的渲染一遍 → 错了重画。

多了一层验证。质量差距就这么来的。

差异 2：思考 10 步 vs 思考 70 步

O-easy ███████████ (10 turns)
GenericAgent ███████████████████████████████████████████████████████████████████████ (70 turns)
 0 10 20 30 40 50 60 70

复杂任务的天然节奏：读 → 想 → 试 → 错 → 改 → 再试 → 验证 → 写。

10 步通常不够。70 步才有「自我纠错」的空间。

这就像考试：限时 10 分钟你只能写完，限时 70 分钟你能写完还能检查三遍。

差异 3：单层记忆 vs 5 层记忆（业界最大短板）

绝大多数 Agent 框架的记忆都很简单：要么没有，要么就一层「对话历史」。

GenericAgent 不一样。它有 5 层。

flowchart TD
 subgraph OE["O-easy 的记忆"]
 H1["对话 history
(进程内, max 20 轮)"]
 H1 -.进程死.-> X1["全部清零"]
 end

 subgraph GA["GenericAgent 的 5 层记忆"]
 L0["L0 · Meta Rules
行为底线"]
 L1["L1 · Insight Index
能力索引"]
 L2["L2 · Global Facts
长期事实"]
 L3["L3 · Task SOPs ★
会做的剧本"]
 L4["L4 · Session Archive
历史归档"]
 L0 --- L1 --- L2 --- L3 --- L4
 end

 style H1 fill:#fee2e2,stroke:#991b1b,color:#000
 style X1 fill:#fee2e2,stroke:#991b1b,color:#000
 style L0 fill:#e0e7ff,stroke:#3730a3,color:#000
 style L1 fill:#c7d2fe,stroke:#3730a3,color:#000
 style L2 fill:#a5b4fc,stroke:#3730a3,color:#000
 style L3 fill:#fbcfe8,stroke:#9d174d,color:#000
 style L4 fill:#818cf8,stroke:#312e81,color:#fff

层	作用	一句话说人话
L0	行为约束	「什么不能做」（比如不能删 vault 文件）
L1	能力索引	「我知道我能干哪些事」（轻量目录）
L2	长期事实	「这个用户喜欢用 mermaid 画图」
L3	任务剧本	「画 RAG 架构图的标准流程」 ← 关键
L4	历史档案	「上周做过的任务都在这」

⚠️ L3 是真正的杀手锏

LangChain 没有这层，AutoGPT 没有这层，Claude Code 也没有这层。L3 不是简单的「对话历史」，而是结构化的「做事剧本」。Agent 干完一件事会自动总结成 SOP 写进来，下次类似任务直接照着剧本演。

打个比方：

L4 是档案室（散乱的过去记录）
L2 是公司维基（稳定的事实库）
L3 是部门 SOP 手册（让新人快速上手的关键资料）

绝大多数 Agent 框架只有档案室和维基，没有 SOP 手册。GenericAgent 把这一层做出来了。

差异 4：能力增长方式（这是最大的范式跃迁）

我把这条放最重要的位置。

传统 Agent 框架的能力公式：

能力 = Σ(预装的工具)

要新能力 = 写新代码 + 改框架 + 发新版 + 用户更新。一条龙重资产。

GenericAgent 的能力公式：

能力 = Σ(L3 里积累的 SOP)

要新能力 = Agent 自己摸索 + 跑通 + 结晶成 SOP + 写入 L3。完全不用碰代码。

flowchart LR
 subgraph TRAD["传统模式"]
 direction TB
 A1[新需求] --> B1[人写新工具]
 B1 --> C1[改框架代码]
 C1 --> D1[发新版本]
 D1 --> E1[用户更新]
 E1 -.重复.-> A1
 end

 subgraph GA["GenericAgent 模式"]
 direction TB
 A2[新需求] --> B2[Agent 自己探索]
 B2 --> C2[跑通 → 结晶为 SOP]
 C2 --> D2[写入 L3 记忆]
 D2 --> E2[下次秒级复用]
 E2 -.->|越用越快| A2
 end

 style TRAD fill:#fef3c7,stroke:#92400e,color:#000
 style GA fill:#dbeafe,stroke:#1e3a8a,color:#000

类比一下：

传统模式 = 建工厂。要新能力等于加新车间，重资产，慢。
GenericAgent = 学徒工。每做一件事，工艺手册就厚一页。自己越来越熟练。

教程里给的数据：同一类任务从「自然语言描述 → SOP → 直接 code 调用」三阶段进化，token 消耗下降 89.6%。

关键差距

传统 Agent 上线第一天和第一年表现一样。GenericAgent 用了一年的能力是用了一天的 N 倍。

差异 5：上下文管理——反潮流的反向操作

业界都在卷长上下文。Claude 卷到 200K，Gemini 卷到 1M，Qwen 也跟上来了。

GenericAgent 反着来：死磕 30K。

项	O-easy	GenericAgent
策略	按消息轮数粗略剪	4 阶段压缩管道
目标	保最近 N 轮	维持 30K token 高密度
长任务表现	容易塞满重复 read 结果	自动压缩、提取要点、丢冗余
方向	跟随业界	反向操作

为什么反潮流？

📝 业界都在装着不知道的事实

LLM 的 attention 机制在 30K 之后衰减明显，长上下文是「花更多钱、办更少事」。

GenericAgent 把这个问题反过来——不堆长度，堆密度。同样 30K 的窗口，塞最有用的东西，劣质信息及时压缩或丢掉。

教程里说，这个策略让 GenericAgent 比 Claude Code 节省 65% token（消耗约 35%）。

实战对比：让 Agent 给笔记画一张架构图

干了这么多铺垫，看看真打起来什么样。

任务：「把这篇 RAG 技术笔记总结一下，给我画张架构图」。

O-easy 怎么做

sequenceDiagram
 autonumber
 participant U as 用户
 participant O as O-easy
 participant L as LLM (Qwen)
 participant V as Vault

 U->>O: 给 RAG 笔记画架构图
 O->>V: read_note("RAG技术.md")
 V-->>O: 全文内容
 O->>L: 帮我画架构图
 L-->>O: mermaid 字符串
(可能语法错)
 O->>V: write_note(追加 mermaid)
 V-->>O: 写入完成
 O-->>U: 完成
 Note over U,V: 没有验证 · 错了用户才发现

5 步搞定，但没有验证。LLM 输出语法错你也不知道，要等用户在 Obsidian 里渲染失败才回头看。

GenericAgent 怎么做

sequenceDiagram
 autonumber
 participant U as 用户
 participant G as GenericAgent
 participant L as LLM
 participant C as code_run
 participant F as 文件系统

 U->>G: 给 RAG 笔记画架构图
 G->>L: 检查 L3 SOP "画架构图"
 L-->>G: 找到上次的 SOP

 G->>F: file_read("RAG技术.md")
 F-->>G: 全文

 G->>C: 跑 Python 提取章节结构
 C-->>G: 结构化 JSON

 G->>L: 基于结构生成 mermaid
 L-->>G: mermaid 代码

 G->>C: mermaid-cli 渲染验证
 C-->>G: 语法正确

 G->>F: file_patch(追加到笔记末尾)
 F-->>G: 完成

 G->>G: update_working_checkpoint
(优化 L3 SOP)
 G-->>U: 完成 + 已自我改进
 Note over U,F: 有验证 · 有改进 · 下次更快

10 步，多了 3 件事：

先查 L3 有没有现成 SOP
用 code_run 真的跑一遍验证 mermaid
完事更新 SOP，下次更快

质量和效率全在这 3 步上拉开。

代码量真相：3000 行 vs 3000 行，谁花得更聪明

项目	核心源码	工具数	记忆层数	自演化	测试
O-easy	3,110 行	5 个专用	1 层	否	0
GenericAgent 核心	3,084 行	9 个原子	5 层	是	未统计

两边代码行数几乎一样，能力密度天差地别。

差在哪？看 GenericAgent 的 3000 行花在哪：

pie title GenericAgent 3084 行核心代码分布
 "agent_loop.py (核心循环)" : 118
 "agentmain.py (入口与模式)" : 266
 "ga.py (9 个工具实现)" : 558
 "llmcore.py (多 LLM 抽象)" : 988
 "simphtml.py (HTML 瘦身)" : 870
 "TMWebDriver.py (浏览器)" : 284

注意 agent_loop.py 才 118 行——作者宣传的「100 行核心循环」是真的，不是营销话术。整个 Agent 大脑就这 118 行。

而 O-easy 的 3110 行：

pie title O-easy 3110 行代码分布
 "tools/* (5 个笔记工具)" : 1026
 "protocol/* (ACP 协议)" : 522
 "llm/* (LLM 客户端)" : 292
 "vault/path_guard.rs (安全)" : 194
 "config.rs" : 140
 "其他" : 936

1026 行花在 5 个工具——平均每个工具 200 行。每个工具都在做差不多的事：path 校验、permission 流程、转 JSON。重复造轮子的味道很浓。

同样 3000 行

GenericAgent 把每行都用在让 Agent 能自我成长的脚手架上。O-easy 的每行都被锁死在「这 5 件事」里。

GenericAgent 的真正创新（一句话每条）

业界对比下，能拍着胸脯说「这是我的原创」的，就这 5 条：

1. 能力 = 记忆，不是代码 —— Agent 框架从「工具盒」变成「学习者」。这是范式跃迁，不是迭代。

2. 5 层记忆 + L3 SOP 这一层 —— LangChain 没有，AutoGPT 没有，Claude Code 也没有。第一次有框架认真做「Agent 自己的 SOP 手册」。

3. 9 个原子工具 + code_run 元工具 —— 用 9 个原语组合出无限能力，而不是堆一百个专用工具。

4. 信息密度优先（反 1M context 潮流） —— 业界都在卷长度，它在卷密度。结果 token 消耗只有 Claude Code 的 35%。

5. 真实浏览器注入（不开 headless） —— 直接操作用户已登录的 Chrome，不用绕验证码、不用模拟登录。RPA 圈子有人做，Agent 圈子做的没几家。

给读者的两条启示

如果你将来想自己设计一个 Agent，记住这两条：

启示 1：选「原子工具 + 代码执行」，不要堆专用工具

反例（O-easy 走的路）	正解（GenericAgent 走的路）
加 send_email 工具	加 code_run，让 Agent 写 smtplib
加 query_db 工具	加 code_run，让 Agent 写 SQL
加 generate_chart 工具	加 code_run，让 Agent 用 matplotlib
工具数量爆炸 → 维护噩梦	9 个原子工具搞定一切

工具集合是 Agent 的天花板。专用工具 = 低天花板 + 高维护成本。原子工具 + code_run = 天花板由 LLM 能力决定，不由你预设。

启示 2：把能力增长留给「运行时」，不要全压在「开发时」

flowchart LR
 A[开发时
写脚手架] --> B[运行时
积累 SOP]
 B --> C[使用时间越长
越聪明]

 style A fill:#dbeafe
 style B fill:#fbcfe8
 style C fill:#bbf7d0

长期复利。这是 GenericAgent 真正甩开同行的一招。

你该用哪个

flowchart TD
 Q{你的需求}
 Q -->|做单一类型任务
如笔记 CRUD| A[O-easy 类
专用 Agent]
 Q -->|做开放式任务
每天都不同| B[GenericAgent 类
通用 Agent]
 Q -->|想理解 Agent 架构
做研究| C[直接读 GenericAgent 源码
3000 行 一周看完]

 style A fill:#fef3c7,stroke:#92400e,color:#000
 style B fill:#dbeafe,stroke:#1e3a8a,color:#000
 style C fill:#dcfce7,stroke:#166534,color:#000

场景	推荐
我只想给 Obsidian 加个写笔记 AI	O-easy Agent（轻、快、专）
我想要一个能干所有杂活的 AI 助手	GenericAgent
我想学 Agent 架构内功	读 GenericAgent 源码

结尾一句话

代码量决定下限，记忆密度决定上限。

GenericAgent 的真正创新，不在于「少」，而在于把少省下来的精力，全部投在了让 Agent 能自我成长上。

3000 行不是它的天花板。它的天花板是用户每多用一次，就被推高一点。

这才是 Agent 框架的未来。

主题/Agent架构 on Albert Intelligence

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

同样 3000 行代码，为什么有的 AI Agent 越用越聪明，有的早早封顶

主角登场

第一眼看不出门道，第二眼吓一跳

差异 1：5 个专用工具 vs 9 个万能工具

差异 2：思考 10 步 vs 思考 70 步

差异 3：单层记忆 vs 5 层记忆（业界最大短板）

差异 4：能力增长方式（这是最大的范式跃迁）

差异 5：上下文管理——反潮流的反向操作

实战对比：让 Agent 给笔记画一张架构图

O-easy 怎么做

GenericAgent 怎么做

代码量真相：3000 行 vs 3000 行，谁花得更聪明

GenericAgent 的真正创新（一句话每条）

给读者的两条启示

启示 1：选「原子工具 + 代码执行」，不要堆专用工具

启示 2：把能力增长留给「运行时」，不要全压在「开发时」

你该用哪个

结尾一句话

延伸阅读