GenericAgent 实测：Token 少用 89.6%，还能打赢 Claude Code？上下文密度才是关键

做 AI Agent 的人，迟早会撞上同一堵墙：任务越长，越跑越烂。

不是模型变笨了。是上下文被撑爆了。

工具描述、历史对话、检索结果、中间输出……这些东西一条一条堆进去，上下文窗口塞得越来越满，模型的注意力越摊越薄。跑到后期，它根本不知道自己在做什么——不是因为它不会，是因为关键信息已经被淹没在噪声里了。

大多数 Agent 框架的解法是：扩大上下文窗口、用更贵的模型、加更多工具。

GenericAgent 反过来想：与其堆上下文，不如提高上下文的密度。

3300 行代码，打赢了几十万行的对手

GenericAgent（以下简称 GA）是复旦大学 Yanghua Xiao 团队在 2026 年初开源的通用 Agent 框架。核心代码约 3000 行，Agent Loop 只有 100 行。

2026 年 4 月，团队在 arXiv 发布技术报告（论文编号 2604.17091），公布了对比数据：

这不是靠堆资源堆出来的。GA 的整个设计，围绕一个原则：上下文信息密度最大化。

定义很直接：决策相关 Token 数 ÷ 总 Token 数，在固定预算下，这个比值要尽可能高。

换句话说，每一个 Token 都要有用，不能浪费注意力在无关内容上。

为什么传统 Agent 的上下文会「腐烂」

这里有个概念值得先说清楚：Context Rot（上下文腐烂）。

Chroma Research 的研究（Anthropic 也引用过这个结论）发现：上下文窗口越长，模型从中准确召回信息的能力越差。不是悬崖式崩塌，是梯度式退化。

根本原因在 Transformer 架构里。每个 Token 都要和其他所有 Token 计算 attention，n 个 Token 就有 n² 个两两关系。Token 越多，这些关系越复杂，模型的注意力资源被稀释得越厉害。

对于长任务 Agent 来说，这意味着：工具调用记录、失败尝试、检索到的冗余文档……只要还在上下文里，就一直在消耗注意力预算。即使模型支持 100K token 的上下文，真正能被有效利用的，远小于这个数字。

GA 的核心回答就是：不要试图把所有东西都塞进去——只放最有价值的。

GA 怎么做到的：四个机制

最小工具集，从源头控制噪声

GA 只有 9 个原子工具：文件操作、代码执行、网页交互、键鼠控制、屏幕视觉、ADB（手机控制）等。

大多数 Agent 框架喜欢预装几十上百个工具，每个工具都有 description，全挂在 system prompt 里。这本身就是巨大的 Token 浪费——绝大多数工具在当前任务里根本用不到，但它们的描述一直压着注意力预算。

GA 的原子工具足够基础，可以通过组合实现复杂行为，但工具描述占用的 Token 极少。

分层记忆，默认只看顶层

GA 的记忆分四层：

每次推理，默认上下文里只有轻量的索引层。深层记忆按需召回，用完就退出上下文——不会一直占着空间。

这个设计的本质是：把记忆的「全量加载」改成「按需检索」，和数据库的延迟加载是同一个思路。

自进化：把成功路径「结晶」成技能

每次 GA 成功完成一个任务，它会自动把执行轨迹提炼成 SOP（标准操作流程）和可执行代码，存入记忆层。

下次遇到类似任务，不需要重新探索，直接调用 SOP——一行指令，复用完整流程。

这带来两个效果：

官方团队还开放了百万量级的共享技能库（Sophub），相当于 Agent 的「技能 App Store」——你可以直接用别人积累的技能，而不是从零开始。

动态压缩，保持密度不下降

长任务执行过程中，GA 会持续压缩和过滤上下文历史，确保信息密度不随任务长度线性下滑。

论文称之为「次线性 Prompt 增长（sublinear prompt growth）」——任务跑了 100 步，上下文不会涨 100 倍，涨的是信息密度保持稳定所需的精炼摘要。

最有说服力的一个细节

GA 的 GitHub 仓库本身，是 GA 自己建的。

从安装 Git、运行 git init，到每一条 commit message，全部由 GenericAgent 自主完成。作者一次终端都没开过。

这不是噱头，是一个非常扎实的能力验证：GA 能在真实系统环境里完成需要多步骤、多工具协作的复杂任务——而且用的 Token 比你想象的少得多。

跑起来有多简单

git clone https://github.com/lsdefine/GenericAgent.gitcd GenericAgentpip install requests streamlit pywebviewcp mykey_template.py mykey.py# 填入你的 LLM API Key（支持 Claude / Gemini / Kimi / MiniMax）python launch.pyw

支持中文，界面有 GUI 和终端两种模式，也可以用 uv 安装。官方教程在 DataWhale 上有完整中文版：https://datawhalechina.github.io/hello-generic-agent/

和「扩上下文」的路线有什么本质区别

现在主流的方向是：模型能处理越来越长的上下文（128K、1M、甚至更长），配合 RAG 往里塞更多信息。

GA 的方向是反过来的：不是扩容，是提纯。

两者不是对立的，但背后的假设不同：

从 GA 的实测数据看，提纯路线在长任务 Agent 上有明显优势。当然，这两个方向最终会融合——更长的窗口 + 更高的信息密度，才是终局。

值得关注的原因

说实话，3000 行代码打赢几十万行框架，这件事本身就值得认真研究一遍。

不是因为「小就是美」，而是因为：当一个极简方案能打赢复杂方案，说明复杂方案里有大量浪费。

GA 把那个浪费的名字叫做「低上下文密度」。这个概念，对所有在做 AI 工程的人来说，都值得认真思考一遍。

你现在做的 Agent，每次推理时上下文里有多少是真正决策相关的？有多少是历史垃圾？欢迎评论区说说你的经验。

参考来源： 本文核心数据与技术细节来自 GenericAgent 官方技术报告及 GitHub 仓库：