OpenRouter上Personal Agent排行榜链接：
https://openrouter.ai/apps/category/productivity/personal-agent
就在这个节骨眼上，一个叫 GenericAgent（GA） 的国产项目，把自进化 Agent 的实现成本直接打到了地板价。
它的核心代码只有3300 行，OpenClaw 是它的 160 倍（约 53 万行，整整两个数量级），Agent Loop 仅 92 行，它的上下文窗口始终控制在 <30K tokens。
目前，该项目在github上已收获10.2k stars。
项目链接：
https://github.com/lsdefine/GenericAgent
论文链接：
https://arxiv.org/pdf/2604.17091
01
Hermes 点燃自进化 Agent，
GA 则把战场拉到上下文信息密度
大部分人看 Agent，看的是参数规模和工具数量——好像买显卡，越大越强。
GA 的作者盯着另一件事看——上下文信息密度（Context Information Density）：
Agent 真正的性能，不取决于上下文能塞多少字，而取决于在有限 Token 预算里，能装进多少真正有用的信息。
简单说就是，塞得多 ≠ 干得好。就像行李箱塞满不代表你旅行装备齐了，可能只是你没学会打包。
这是 GA 论文的第一性原理，也是整套系统的出发点。
（1）长上下文的三重套娃陷阱
LLM 在长上下文里，会同时踩三个坑，而且这三个坑还会互相叠buff：
陷阱 1：Lost-in-the-Middle（关键证据迷失在中间）
模型就像看小说——开头和结尾记得特别牢，中间那一大段，基本当空气处理。
陷阱 2：注意力稀释（Attention Dilution）
上下文里无关内容越多，注意力被摊得越稀。无关信息不是"中性"的——它会主动抢戏，把模型的注意力从关键证据上撕走。
陷阱 3：名义窗口 ≫ 有效窗口
一个标称 128K 的模型，实际能稳定推理的有效窗口可能只有几万 token。剩下的，全是"我可以，但我不想"的区域。
三者一叠加，死循环就来了——上下文越长，推理越差；为了补偿推理差，又塞更多上下文。这大概就是 Agent 界的"越努力越焦虑"。
（2）把信息密度当成唯一 KPI
GA 不做"更大"，它做"更干净"。围绕上下文信息密度最大化，GA 设置了四道闸口，每一道都是拦噪音的安检员：
这四道闸口合起来，就是 GA 的全部秘密武器。
02
不要堆工具，要会组合：
GA用9个原子工具撑起完整Agent能力
Claude Code 有 53 个工具，OpenClaw 有 18 个工具，GA 只有 9 个工具。
看起来是不是 GA 特别不够用？
再来看真实的调用分布，画风立马不对了：
Claude Code 的 53 个工具，80% 以上的调用只落在 3 个工具上——剩下 47 个工具常年摸鱼，但每一轮推理都要占据上下文。
所以 GA 敢只留 9 个，不是因为它勇，是因为它看透了。
它用两把尺子来筛选工具：
原子性（Atomicity）：每个工具都是不可再分的原始能力，职责单一，工具之间零重叠——没有"都能干但都不专精"的万金油。
组合泛化（Compositional Generalization）：复杂行为通过原子工具的组合产生，而不是靠新增专用工具。
这 9 个工具覆盖了 Agent 的完整能力环：状态观测 → 动作执行 → 上下文保持 → 干预请求。
注意一个反常识的细节：GA 没有专门的"搜索"工具、没有"浏览器截图"工具、没有"HTTP 请求"工具。
因为这些能力全部由 code_run + Python 生态兜底——Python 本身就是最庞大、最活跃的工具集合，pip 一下啥都有。
03
分层记忆：别人还在用 22,821 token
打招呼，GA 只用了 2,298
场景设想一下：装好 20 个 Skill 之后，你对四个 Agent 说一句 Hello，它们各自的完整提示词长度是多少？
论文里给了一张让人当场破防的图：
GA 的提示词长度，是 Claude Code 的 10%，OpenClaw 的 5%。OpenClaw 打一句招呼的 token 量，够 GA 跑完一小段实际任务了。
做到这件事的，是 GA 的四层分层记忆架构（L0 → L4）：
每一轮对话，GA 只默认加载 L0（最小 Meta 规则）+ L1（目录级索引），其它层级按需用 file_read 拉进来。相当于进图书馆不是把所有书搬回家，而是先看目录——需要哪本再抽哪本。
路由不是硬编码的流水线，而是模型根据任务自主选择要不要读。不相关的知识永远不进入活跃上下文。
光分层还不够。如果任何东西都能进长期记忆，错经验、过期配置、一次性调试信息迟早把记忆搞成一锅大杂烩。
所以 GA 给 L2 / L3 加了一条准入铁律：
No Execution, No Memory ——不是应该这样做，而是这样做了，而且成功了，才配进记忆。
瞬态状态、一次性事件、未验证假设，一律被门卫拦在外面。
GA 论文在 SOP-Bench 的 dangerous goods 子集上跑了一组记忆消融实验（Memory Ablation），直接拷问记忆密度到底重不重要。
165 token 达到了 575 token 的 1.27 倍成功率。
让我们算一下反差：用三分之一的"墨水"，干出一倍多的活。这就是整个 Agent 设计哲学的硬核注脚——浓缩、行动导向的记忆，比更多的记忆有效得多。
少即是多，在 Agent 这里是实打实的数据，不是玄学。
04
约束，才是Agent能力涌现
的真正源泉
GA 最让人拍案叫绝的，不是上面那些"设计得很巧妙"的机制，而是下面这种"根本就没设计"的能力：
GA 没有子 Agent 管理器、没有调度守护进程、没有事件总线、没有编排层——这些听起来很高大上的词，在 GA 里全部不存在。
那这些"高级功能"从哪冒出来的？它们从两个基础原语里直接涌现出来：
可调用 CLI 入口点：Agent 就是一个命令行程序，父 GA 通过
code_run启动子 GA——自己调自己，亲爹当亲儿子使文件协议：跨进程通信只靠目录约定——
input.txt送任务、output.txt收结果、reply.txt续对话、inject_message.txt运行时干预。比 RPC 简单，比 MQ 靠谱，还没有中间商赚差价。
这种涌现不是物理意义上的涌现，而是工程意义上的涌现——当基础组件足够通用、组合成本足够廉价时，设计者没预先规划的功能，能在需要的时候被轻松实现出来。
给 Agent 的选项越少，它反而越能长出花来。
05
使用方法
环境要求：Python 3.10+
（1）下载并安装GenericAgent项目
git clone https://github.com/lsdefine/GenericAgent.gitcd GenericAgent
（2）配置 API Key
把项目文件中的 mykey_template.py 重命名为 mykey.py。进入 mykey.py 配置 API Key。
oai_config = {'apikey':'Your-API-Key', # 此处填写API Key'apibase':'http://api.example.com:3001', # 此处填写 base url，openai的base url后自动接"/v1/completion"'model':"openai/gpt-5.1" # 此处填写模型名称，注意名称要与供应商提供的名称完全一致（大小写等）}
（3）自动配置其他依赖
cd GenericAgentpython3 agentmain.py
在命令行输入：“请查看你的代码，安装所有用的上的python依赖”请复制这句话到终端，GenericAgent会自动安装剩下的相关依赖。
（4）启动
python launch.pyw #一键启动 【或 python3 launch.pyw】完整步骤请参考：
https://my.feishu.cn/wiki/CGrDw0T76iNFuskmwxdcWrpinPb
系统学习请参考：
https://datawhalechina.github.io/hello-generic-agent/
06
Hermes 之后，
Agent 的分水岭到底在哪
Hermes 点燃了自进化 Agent 的热度，但它留下一个问题——怎么把这件事做便宜、做稳定、做本地可部署？
当其他框架在功能内置、模块堆叠上继续加码时，GenericAgent 押注了另外一条路径 ——用最小原语 + 最大组合空间，让能力从约束中涌现。
两条路谁赢，现在下结论还太早。但如果你正在做 Agent、被 Token 账单炸过钱包、被长上下文的三重陷阱毒打过心态，那 GA 这套范式真的值得抄进下一版架构——或者至少可以重新思考一遍"是不是工具堆太多了"。