GenericAgent 的设计哲学独树一帜:不预设技能,靠进化获得能力。它用约 3K 行核心代码和 9 个原子工具,赋予任意 LLM 对本地计算机的系统级控制能力,覆盖浏览器、终端、文件系统、键鼠输入、屏幕视觉及移动设备。更关键的是,它在不到 30K 的上下文窗口内完成了其他 Agent 需要 200K–1M token 才能实现的任务,token 消耗减少约 6 倍。这种效率差异源于其自举式技能树生长机制与上下文信息密度最大化策略,而非简单的 prompt 压缩。
自举式技能树生长机制
GenericAgent 区别于其他 Agent 框架的根本在于其自我进化能力。传统 Agent 依赖预先编写的技能库或插件生态,而 GenericAgent 每解决一个新任务,就会自动将执行路径固化为 Skill,写入分层记忆系统,供后续直接调用。这个过程无需人工干预,完全由 Agent 自主完成。
分层记忆系统架构
GenericAgent 采用五层记忆架构,每一层承担不同的功能,共同支撑技能树的生长:
| 层级 | 名称 | 功能 | 典型内容 |
|---|---|---|---|
| L0 | 元规则 | 基础行为规则和系统约束 | 工具调用规范、容错策略 |
| L1 | 记忆索引 | 快速路由与召回 | 任务类型映射、关键模式 |
| L2 | 全局事实 | 长期积累的稳定知识 | 开发者偏好、系统环境 |
| L3 | 任务 Skills/SOPs | 可复用的工作流程 | 外卖下单流程、选股逻辑 |
| L4 | 会话归档 | 长程召回的归档记录 | 历史任务经验总结 |
这个分层设计的核心优势在于信息密度控制:L0 元规则始终在场,提供稳定的行为边界;L1 索引层极简设计,确保快速定位;L3 Skills 作为可执行的工作单元,在需要时被精准召回。这种设计避免了将所有历史经验一股脑塞入上下文造成的噪声累积。
从任务到技能的完整生命周期
当用户首次提出一个任务时,GenericAgent 的执行流程是:感知环境状态 → 自主探索(安装依赖、编写脚本、调试验证)→ 将执行路径固化为 Skill → 写入记忆层 → 下次同类任务直接调用。以 "监控股票并提醒我" 为例,首次执行时 Agent 需要安装 mootdx 库、构建选股流程、配置定时任务,这些探索成本在首次完成后被固化为 Skill;此后用户只需说一句话,Agent 即可启动监控。这种机制使得 GenericAgent 的能力随使用时间持续增长,形成一棵完全属于用户、独一无二且持续生长的技能树。
动态工具创建机制
GenericAgent 的 code_run 工具赋予 Agent 在运行时动态创建新工具的能力。通过这个原子工具,Agent 可以安装 Python 包、编写新脚本、调用外部 API 或控制硬件。关键在于,这些临时能力在任务完成后可以被固化为永久 Skill。换言之,Agent 不仅能够使用预设工具,还能自主扩展工具集,并将扩展结果持久化存储。这种机制从根本上区别于依赖固定工具列表的传统 Agent 实现。
Token 效率优化的工程原理
GenericAgent 官方技术报告(arXiv:2604.17091)明确指出,其核心优化方向是上下文信息密度最大化(Contextual Information Density Maximization)。这一策略使得系统在不到 30K 的上下文窗口内实现了与其他 Agent 200K–1M 上下文相当甚至更好的任务完成率。
上下文窗口压缩的核心数据
对比同类 Agent 产品,GenericAgent 的 token 消耗优势显著:
| Agent | 上下文窗口 | 核心机制 |
|---|---|---|
| GenericAgent | <30K | 分层记忆 + 精准召回 |
| Claude Code | ~200K+ | 工具集扩展 |
| OpenClaw | ~1M | 多 Agent 编排 |
6 倍 token 消耗减少并非来自单一优化,而是多个工程决策的叠加结果。首先是分层召回策略:Agent 不将全部历史经验塞入每次请求的上下文中,而是通过 L1 索引层快速判断需要调用哪个 L3 Skill,Skill 内容按需加载。其次是信息密度最大化原则:L0 元规则仅保留最核心的行为约束,每个 Skill 的描述也经过精简,聚焦于可执行的操作步骤而非冗长的解释说明。最后是精准路由:用户输入首先经过 L1 索引层匹配,确定任务类型后再激活对应的 L3 Skill,这种路由机制避免了错误地加载不相关记忆。
分层记忆的上下文在场策略
理解分层记忆如何降低 token 消耗,需要理解 "上下文在场" 的概念。传统 Agent 将所有记忆作为系统 prompt 的一部分持续加载,导致 token 消耗随使用时间线性增长。GenericAgent 的分层设计将记忆分为两类:常驻层(L0、L1)和按需加载层(L2、L3、L4)。常驻层体积小,始终在场;按需加载层体积大但仅在匹配到相关任务时才激活。这意味着每次请求的实际 token 消耗取决于当前任务的复杂度,而非累积的经验总量。
实际工程中,L0 元规则的配置需要权衡约束强度与灵活性。过于严格的行为规则会限制 Agent 的探索能力,过于宽松则无法发挥分层架构的优势。建议将 L0 控制在 500–800 token 以内,仅包含工具调用规范、容错策略和核心安全边界。L1 索引层应保持精简,每条索引记录尽量控制在 50 token 以内。L3 Skill 的设计则应遵循 "单一职责" 原则,每个 Skill 聚焦于一个特定任务类型,避免将多个不相关的工作流程混合写入同一个 Skill。
极简架构实现全系统控制
GenericAgent 的核心代码约 3K 行,Agent Loop 仅约百行(agent_loop.py),却实现了对本地计算机的系统级控制。这一能力源于其极简工具集设计与真实环境注入策略的结合。
9 个原子工具的能力组合
GenericAgent 仅提供 9 个原子工具:
| 工具 | 功能 | 系统控制维度 |
|---|---|---|
| code_run | 执行任意代码 | 通用计算能力 |
| file_read | 读取文件 | 文件系统读取 |
| file_write | 写入文件 | 文件系统写入 |
| file_patch | 修改文件 | 文件系统增量修改 |
| web_scan | 感知网页内容 | 网络信息获取 |
| web_execute_js | 控制浏览器行为 | 浏览器自动化 |
| ask_user | 人机协作确认 | 交互控制 |
加上 2 个记忆管理工具(update_working_checkpoint、start_long_term_update),共 11 个工具。这些工具的组合能力覆盖了操作系统的主要交互维度:通过 code_run 执行 Shell 命令控制终端、通过文件操作工具管理本地资源、通过浏览器工具操作 Web 应用、通过 ADB 控制移动设备。关键在于,这些工具不是孤立存在,而是通过 Agent Loop 的自主执行循环有机组合,Agent 感知环境状态后推理任务、调用工具执行、写入经验记忆,形成完整的控制闭环。
真实浏览器注入与登录态保持
GenericAgent 采用真实浏览器注入而非无头浏览器或沙箱环境。这意味着 Agent 操作的是用户日常使用的浏览器,登录态、Cookie、Session 等信息完全保留。对于需要登录验证的自动化任务,这种设计显著降低了实现难度。Agent 通过 web_execute_js 直接控制浏览器的 DOM 操作和网络请求,可以完成外卖下单、股票筛选等复杂的多步骤 Web 操作。代价是架构复杂度增加,但换来的是任务成功率的本质提升。
工程化落地参数与实践建议
基于 GenericAgent 的设计原理,以下是在实际项目中部署和优化时需要关注的关键参数。
记忆层级配置建议
L0 元规则配置:建议控制在 500–800 token 以内,聚焦于三类约束 —— 工具调用规范(哪些工具可用、调用频率限制)、容错策略(重试次数、超时阈值)、安全边界(禁止执行的操作类型)。避免在此层级写入过于具体的工作流程描述。
L3 Skill 设计原则:每个 Skill 应遵循 "单一职责" 原则,聚焦于一个可完整描述的任务类型。以 "外卖下单" 为例,不应将 "查找商家→选择商品→确认订单→支付" 全部写入同一个 Skill,而应拆分为 "商家检索"、"商品选择"、"支付确认" 等多个 Skill。这种设计使得 Skill 的复用粒度更细,Agent 在不同任务中可以灵活组合使用。
Skill 结晶时机:建议在任务首次完成并通过验证后触发 Skill 结晶。过早结晶可能导致 Skill 包含错误步骤,过晚结晶则失去积累经验的价值。实践中的判断标准是:任务能够稳定复现时,将其固化为 Skill。
Token 预算分配策略
在 30K 上下文的约束下,每个 token 的使用都需要精打细算。建议的预算分配:
- L0 元规则:500–800 token(2–3%)
- L1 索引层:300–500 token(1–2%)
- 当前会话上下文:1K–3K token(5–10%)
- L3 Skill 内容(按需加载):10K–20K token(40–60%)
- 模型输出预留:5K–10K token(20–30%)
这个分配比例意味着 Skill 是上下文的主体,而非背景信息。L0 和 L1 作为 "索引目录" 存在,真正的执行依据来自按需加载的 Skill 内容。
监控指标
部署 GenericAgent 时应关注以下指标:
Token 消耗监控:每次会话的平均 token 消耗量、Skill 调用频率分布。若平均 token 消耗接近 30K 上限,说明记忆层级设计存在问题,需要优化 L0 或 L1 的精简程度。
Skill 命中率:新任务中有多少比例可以直接通过 Skill 解决。新用户初始化时命中率接近零,随着使用时间增长,命中率应持续提升。若增长缓慢,可能是因为 Skill 设计粒度不合理或结晶时机把握不当。
任务完成率:区分首次执行(探索模式)和 Skill 调用(复用模式)的完成率。探索模式的成功率应作为核心优化目标,因为它决定了 Skill 结晶的质量。
记忆膨胀率:L3 Skill 总量的增长速度。过快增长可能导致维护困难,建议定期对 Skill 进行审查和合并,保持 Skill 树的结构清晰。
技术选型考量
GenericAgent 适合追求极致效率和自主进化的场景。对于 Token 成本敏感、需要长期运行并持续积累经验的个人用户或小团队尤为适用。其 3K 行的极简架构降低了部署和理解的门槛,无需复杂的多服务编排,一个 API Key 即可启动。
但也需要认识到局限性:由于采用真实浏览器注入,环境配置相对复杂;在某些需要严格隔离的场景下可能不适用;分层记忆系统的设计需要一定的调优经验。对于追求开箱即用的团队,agent-skills 提供了更结构化的技能定义和工作流程规范,两者可以互补使用。
GenericAgent 的出现揭示了一个重要趋势:Agent 的能力边界不一定与预置功能成正比。通过极简架构与自举机制的结合,小体量系统同样可以实现全系统控制能力,而 token 效率的优势在规模化部署中将持续放大。
资料来源
- GenericAgent GitHub 仓库:https://github.com/lsdefine/GenericAgent
- 技术报告 arXiv:2604.17091:GenericAgent: A Token-Efficient Self-Evolving LLM Agent via Contextual Information Density Maximization
内容声明:本文无广告投放、无付费植入。
如有事实性问题,欢迎发送勘误至 i@hotdrydog.com。