Paper Notes

GenericAgent: A Token-Efficient Self-Evolving LLM Agent via Contextual Information Density Maximization (V1.0)

作者Jiaqing Liang, Jinyi Han, Weijia Li, Xinyi Wang, Zhoujia Zhang, Zishang Jiang, Ying Liao, Tingyun Li, Ying Huang, Hao Shen, Hanyu Wu, Fang Guo, Keyi Wang, Zhonghua Hong, Zhiyu Lu, Lipeng Ma, Sihang Jiang, Yanghua Xiao
机构Advantage AI Agent Lab (A3 Lab); Fudan University; Shenzhen Aquaintelling Technology
发表arXiv technical report · 2026
参考GitHub

29分钟阅读

GenericAgent: A Token-Efficient Self-Evolving LLM Agent via Contextual Information Density Maximization (V1.0)

Paper: arXiv:2604.17091 Code: lsdefine/GenericAgent Code reference: main @ 1c9f141e (2026-05-26)

1. Motivation (研究动机)

现有 long-horizon LLM agent 的瓶颈不是“窗口还不够长”这么简单，而是有限有效上下文里真正能参与决策的信息密度太低。论文把这个问题拆成三个互相放大的失败模式：第一，长序列存在 positional bias，处在中间的关键证据更难被模型取回；第二，无关内容不只是“被忽略”，它会分散注意力并降低对决策证据的利用；第三，有效上下文长度通常显著短于名义窗口，所以把历史、工具说明、DOM、日志和检索结果不断塞进 prompt，会让名义上更大的上下文变成更贵、更吵、也更容易 hallucination 的输入。

这直接影响 agent 系统设计。很多 agent 框架默认把工具 schema、历史轨迹、检索 memory、浏览器页面、控制文本都作为 prompt-resident 内容长期注入，导致两类浪费：一类是 prompt-level overhead，例如几十个 specialized tools 的 schema 和说明挤占预算；另一类是 policy-level overhead，即 action space 变大后工具选择更不稳定，容易多轮试错。即便某些框架加入 retrieval-augmented memory，也常把原始日志或粗摘要当作可检索对象，缺少验证、压缩、更新和跨任务复用机制，无法真正 self-evolve。

论文要解决的具体目标是：构建一个 general-purpose LLM agent，使它在本地文件系统、终端、浏览器和外部服务等真实长程环境中完成任务，同时把活跃上下文控制在高密度、可决策、可持续复用的状态。GenericAgent (GA) 的研究价值在于：如果 agent 可以把一次任务中经过验证的探索轨迹压缩成 SOP、脚本和 skill，下次遇到类似任务就不必重新走完整的推理和试错路径；这会同时提升任务成功率、降低 token/请求/工具调用开销，并把“长期使用”从上下文污染变成系统能力增长。

Figure 1 解读：这张图说明论文的核心优化对象不是单纯的 context length，而是 completeness 与 conciseness 的平衡。左侧完整但冗长，会让关键证据被低价值文本淹没；右侧简洁但遗漏关键条件，会诱发错误假设。GA 的目标是在保留必要决策信息的同时，尽量删除冗余历史、工具噪声和页面噪声，让上下文保持自然可读但不被自然语言冗余拖垮。

2. Idea (核心思想)

核心 insight 是：long-horizon agent 的性能主要由“有限有效上下文中保留了多少决策相关信息”决定，而不是由名义上下文窗口、工具数量或 memory 总容量决定。GA 因此把 agent 的工具层、memory 层、自我进化层和历史压缩层都统一成一个目标：最大化 contextual information density。

关键创新可以概括为四个互相配合的机制：用 9 个 atomic tools 代替庞大 specialized tool inventory，降低默认工具说明和动作选择成本；用 hierarchical on-demand memory 只默认注入极小索引，把事实、SOP 和原始会话放到更深层按需读取；用 self-evolution pipeline 把验证过的轨迹提炼为 SOP、代码和 skill；用 head-tail truncation、tag-level compression、FIFO eviction 和 working-memory anchor 维持长程执行中的上下文密度。

它和 Claude Code / OpenClaw 这类更强调工具丰富度或插件扩展的系统不同：后者倾向于通过更多工具或更大上下文覆盖更多场景，而 GA 反过来把能力来源放在“少量可组合原语 + 可压缩经验资产”上。与 Mem0 / A-MEM 等 memory 系统相比，GA 不依赖 embedding/vector DB 作为默认记忆接口，而是让 L1 索引、L2 事实、L3 SOP、L4 raw archive 分层存在，并通过工具调用显式读取深层内容，从而避免 memory 本身变成常驻 prompt 噪声。

3. Method (方法)

3.1 Overall framework：统一 agent loop + 四个密度机制

GA 是一个 model-agnostic local agent runtime：底层 LLM 可以是 Claude、GPT、Gemini、MiniMax 等，执行环境覆盖 browser、terminal、file system、keyboard/mouse、screen perception 和 mobile devices。系统核心是一条统一 agent loop：当前任务和相关 memory 组成执行上下文，LLM 生成自然语言输出或 tool calls，dispatcher 执行工具并返回结构化结果，任务结束后把轨迹压缩为长期 memory 或 skill。

Figure 2 解读：Figure 2 展示了 GA 的整体闭环。左侧任务输入进入统一 agent loop；中间 LLM 根据当前上下文选择输出或工具调用；工具结果再回流为结构化 feedback；底部 memory/self-evolution 模块把完成任务后的经验写回。图中四个核心机制分别作用在不同阶段：minimal toolset 减少执行前的接口噪声，hierarchical memory 控制跨任务信息的默认可见性，self-evolution 把成功轨迹变成 SOP/代码/skill，structured browser extraction 与 context compression 控制动态环境带来的上下文膨胀。

直觉上，GA 把“智能体会越来越强”从模型权重更新转移到信息环境更新。它不改 base model，而是让模型每次面对类似任务时拥有更好的、密度更高的上下文：少量工具让行动空间更清晰，L1 指针让模型知道有什么知识可取，L3 SOP 让它不用重新探索，压缩/截断机制让旧消息不会挤掉当前关键状态。这样得到的提升不是一次性的 prompt trick，而是随着任务执行不断固化到外部 memory/code assets 的系统性收益。

3.2 Minimal Atomic Toolset：9 个原子工具而不是工具枚举

GA 暴露 9 个 atomic tools，分成五类：File Operations 包含 file_read、file_patch、file_write；Code Execution 是 code_run；Web Interaction 包含 web_scan、web_execute_js；Memory Management 包含 update_working_checkpoint、start_long_term_update；Human-in-the-loop 是 ask_user。每个工具只承担单一职责，复杂任务靠组合完成，而不是为每类任务新增 specialized tool。

released code 中，assets/tools_schema.json 定义了这 9 个 function schema；agent_loop.py 负责把 LLM 产生的 tool call 交给 handler；ga.py::GenericAgentHandler 实现 do_code_run、do_file_read、do_file_patch、do_file_write、do_web_scan、do_web_execute_js、do_update_working_checkpoint、do_start_long_term_update 和 do_ask_user。这种结构对应论文里的“tool declaration / invocation / dispatch”三段式：schema 给模型可验证接口，dispatcher 做本地执行，handler 控制返回结果和 next prompt。

这套设计的关键不是“只有 9 个工具也能理论上完成所有事”，而是减少每一步的决策成本。例如 code_run 理论上可以模拟其他工具，但如果每次读文件、改文件、浏览网页都让模型写临时代码，反而会增加错误率和 token 成本。因此 GA 保留少量高频 shortcut 工具：它们既限制能力边界，又给模型稳定的 action vocabulary。

Figure 3 解读：Figure 3 对比 Claude Code、OpenClaw 与 GA 的工具调用分布。GA 的调用集中在 code_run、file_read、web_execute_js、web_scan 等少量原语上，说明它不是靠大量 specialized tools 覆盖能力，而是把复杂流程压缩成稳定的组合模式。这个分布也解释了 Table 4 中 GA 的 request/tool-call 数更低：工具空间更小，模型在选择动作时更少摇摆。

3.3 Hierarchical Memory：L1 指针常驻，L2/L3/L4 按需读取

GA 把 memory 分成工作记忆、always-on memory 和 long-term memory 三种功能类型，并落实为 L1–L4 层级。L1 是 index layer，只记录高频入口、关键词映射和少量硬约束，是默认注入的 lightweight orientation；L2 是 fact layer，保存经执行验证且长期稳定的事实；L3 是 SOP layer，保存任务流程、前置条件、关键步骤、常见失败和 recovery strategy；L4 是 raw session archive，用于追溯历史轨迹和审计，不频繁直接注入 prompt。

released repo 的 README 把论文里的 global meta-memory 明确成 L0 Meta Rules，并列出 L1 Insight Index、L2 Global Facts、L3 Task Skills/SOPs、L4 Session Archive。代码上，agentmain.py::get_system_prompt() 会把 assets/sys_prompt*.txt 与 ga.get_global_memory() 拼到系统提示；ga.py::log_memory_access() 记录 memory 文件访问统计；memory/L4_raw_sessions/compress_session.py 对 raw model responses 做压缩、history block 提取和归档；reflect/scheduler.py 还会周期性触发 L4 archive cron。也就是说，论文的 memory 分层在 release 中不是纯概念，而是映射到 memory/ 目录、全局提示拼接、访问统计与 L4 压缩脚本。

Figure 4 解读：Figure 4 展示连续重复任务时的时间和 token 变化。CodeX、Claude Code、OpenClaw 基本稳定，而 GA 从首轮约 102 秒、200,439 tokens 降到后续约 66 秒、100,000 tokens。图的重点不是“记住更多”，而是“把一次任务中的高价值路径压成 L3 SOP”，下次只读 compact procedure，避免重走探索过程。

3.4 Self-Evolution：从 raw trajectory 到 SOP，再到 executable skill

GA 的 self-evolution 不更新模型权重，而更新模型看到的信息环境。论文明确说“evolves strategy, not tools”：固定 tool layer 不变，任务特定能力写进 SOP 文件和可复用脚本。原始轨迹先存入 L4；只有在成功完成子目标、从错误中恢复等有验证信号的节点，才触发 consolidation；经过验证的事实进入 L2，经过验证的流程进入 L3。论文把这个约束称为 “No Execution, No Memory”：猜测、临时状态、失败分支不能直接晋升为长期 memory。

失败处理也服务于长期进化。GA 使用 staged escalation：第一次失败时基于具体错误做局部修正；如果仍失败，必须换策略或主动搜索缺失信息；自动化尝试都失败时再请求人类介入。这防止 agent 在错误动作上自我强化，也使 L3 SOP 中沉淀的是“验证过的成功路径和 recovery pattern”，而不是会污染未来任务的任意反思。

在代码里，ga.py::do_start_long_term_update() 会启动总结提炼长期记忆的过程，提示模型只抽取“事实验证成功且长期有效”的环境事实、用户偏好和复杂任务经验；ga.py::_get_anchor_prompt() 把最近历史、turn number、key_info 和相关 SOP 提示注入下一轮；agentmain.py 在新任务 handler 之间传递上一轮 key_info，但会标注这是旧任务留下的 working memory，要求新任务时更新或清除。这个实现体现了论文的选择性：短期状态可跨 turn 保持，长期记忆必须通过显式 consolidation。

3.5 Context truncation & compression：字符预算上的保守控制

论文用字符域近似 token 预算，因为运行时不能稳定获得精确 token count： 其中 是当前历史消息 JSON serialization 后的字符长度， 是配置的 token window， 是字符预算上界。ASCII 内容大约 4 chars/token，因此 会偏保守、略早 eviction；CJK 内容可能 1–2 chars/token，因此该近似对中文场景可能低估 token 使用、导致 eviction 略晚。

GA 的压缩分四层：第一，tool-output truncation 对单条工具返回做 head-tail 保留，例如 paper Table 1 给出 code_run=10,000 chars、web_execute_js=8,000 chars、web_scan(text_only)=10,000 chars、web_scan(HTML)=35,000 chars、file_read≈1,280/line; 20,000 total；第二，tag-level compression 每约 5 turns 压缩旧消息中的 <thinking>、<tool_use>、<tool_result> 等标签内容，保留首尾约 800 字符，并把旧 <history>/<key_info>/<earlier_context> 替换为 placeholder；第三，如果总历史超预算，先强制更严格压缩，再 FIFO 删除旧消息直到低于 60% budget，并清理 orphaned tool-result；第四，每次 tool invocation 后注入 working-memory anchor，包含最近 20 条 one-line turn summaries、当前 turn number 和 key_info。

released code 与论文基本一致：llmcore.py::compress_history_tags() 默认 keep_recent=10、max_len=800、interval=5；llmcore.py::trim_messages_history() 使用 cap = sess.context_win * 3 与 target = int(cap * trim_keep_rate=0.6)，超限后 keep_recent=4 强压缩，再 FIFO pop；ga.py::do_code_run() 把结果限制为约 10000 / tool_num，do_web_execute_js() 限制为约 8000 / tool_num，do_web_scan() 默认 HTML 预算约 35,000 字符，text_only 走进一步 maxlen//3 的摘要。论文公式与 released code 实现差异：未发现与核心机制相反的实现；主要命名差异是 release README 将论文的 global meta-memory 显式标为 L0 Meta Rules，而论文正文以 global meta-memory + L1–L4 描述。

3.6 Emergent capabilities：CLI 原语带来的 subagent、reflect 与 autonomous exploration

GA 的 minimal architecture 还有一个系统层面的结果：一旦 agent 是标准 CLI 程序，高阶能力可以从进程组合中自然出现。Subagent dispatch 不需要特殊 multi-agent manager；父 agent 只要用 terminal command 启动多个 GA 实例，让每个实例拥有独立 memory/history，最后合并结果即可。Reflect Mode 也不需要独立 daemon 架构；外部轻量脚本轮询条件，条件触发时把字符串任务提交给 GA CLI。

Autonomous exploration 则把 subagent dispatch 和 reflect mode 组合起来：当系统空闲时，触发器让 GA 读取探索流程，检查 skill tree，生成探索任务，在临时目录中研究/原型/验证，写出带元数据的 Markdown 报告，再原子地更新 skill tree 和 usage counter。任务候选的评分公式是： 其中 奖励 under-populated categories， 奖励高频技能加深， 估计实用价值， 奖励新技术/新领域。论文给出初始权重 ，且任务列表至少覆盖四个 skill categories，避免只在一个方向堆叠探索。实际使用后，如果某任务预测分 但 30 天内使用次数 ，其主导维度权重降低 10%；若 但 ，对应权重增加 10%，然后重新归一化。

released code 中，reflect/autonomous.py 的默认触发器每 1800 秒返回一次“用户离开超过 30 分钟，读取自动化 SOP 并执行自动任务”的 prompt；reflect/scheduler.py 支持 JSON 定时任务、冷却时间、max-delay 窗口和 L4 archive cron；reflect/goal_mode.py 支持持续自驱的 goal mode。论文中更完整的 skill-tree 打分与长期反馈更新属于系统设计/技术报告描述，release repo 中对应逻辑分散在 memory SOP 与 reflect 脚本中，而不是一个单独的大型 planner 模块。

3.7 Pseudocode：基于 release code 的核心组件近似

3.7.1 Agent loop 与 tool dispatch

def agent_runner_loop(client, system_prompt, user_input, handler, tools_schema, max_turns=80):
    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": user_input},
    ]
    for turn in range(1, max_turns + 1):
        if turn % 10 == 0:
            client.last_tools = ""  # periodically resend full tool descriptions
 
        response = client.chat(messages=messages, tools=tools_schema)
        tool_calls = response.tool_calls or [{"name": "no_tool", "arguments": {}}]
 
        tool_results, next_prompts = [], []
        for idx, call in enumerate(tool_calls):
            outcome = handler.dispatch(
                tool_name=call.name,
                args={**call.arguments, "_index": idx, "_tool_num": len(tool_calls)},
                response=response,
            )
            if outcome.should_exit or outcome.next_prompt is None:
                return outcome.data
            if call.name != "no_tool" and outcome.data is not None:
                tool_results.append({"tool_use_id": call.id, "content": json.dumps(outcome.data)})
            next_prompts.append(outcome.next_prompt)
 
        next_prompt = handler.turn_end_callback(
            response=response,
            tool_calls=tool_calls,
            tool_results=tool_results,
            turn=turn,
            next_prompt="\n".join(next_prompts),
            exit_reason={},
        )
        messages = [{"role": "user", "content": next_prompt, "tool_results": tool_results}]

3.7.2 Tool-output 和 history compression

def trim_messages_history(history, session):
    cap_chars = session.context_win * 3
    target_chars = int(cap_chars * getattr(session, "trim_keep_rate", 0.6))
 
    compress_history_tags(history, keep_recent=10, max_len=800, interval=session.cut_msg_interval)
    if serialized_len(history) <= cap_chars:
        return history
 
    compress_history_tags(history, keep_recent=4, max_len=800, force=True)
    while len(history) > 9 and serialized_len(history) > target_chars:
        history.pop(0)
        while history and history[0]["role"] != "user":
            history.pop(0)
        if history and history[0]["role"] == "user":
            history[0] = sanitize_orphaned_tool_results(history[0])
    return history

3.7.3 Hierarchical memory consolidation gate

def start_long_term_update(recent_task_trace, memory_root):
    candidates = extract_verified_facts_and_procedures(recent_task_trace)
    updates = []
    for item in candidates:
        if not item.was_validated_by_successful_execution:
            continue  # No Execution, No Memory
        if item.kind == "stable_fact":
            updates.append(patch_l2_global_facts(memory_root, item.minimal_text))
        elif item.kind == "reusable_workflow":
            updates.append(patch_l3_sop(memory_root, item.steps, item.failure_cases))
        elif item.kind == "raw_trace":
            updates.append(archive_l4_session(memory_root, item.trace_ref))
    refresh_l1_index(memory_root, updates)
    return updates

3.7.4 Autonomous exploration task scoring

def score_exploration_task(task, skill_tree, weights=(0.3, 0.2, 0.3, 0.2)):
    wb, wd, wu, wi = weights
    category_size = len(skill_tree.skills_in(task.category))
    mean_size = skill_tree.mean_category_size()
    usage = skill_tree.usage_count(task.target_skill)
    max_usage = max(skill_tree.all_usage_counts(), default=0)
 
    breadth = 10 * max(0.0, 1.0 - category_size / (mean_size + 1))
    depth = 10 * usage / (max_usage + 1)
    utility = llm_score(task, rubric="practical utility", low=1, high=10)
    innovation = llm_score(task, rubric="novel technique or domain", low=1, high=10)
    return wb * breadth + wd * depth + wu * utility + wi * innovation
 
 
def adapt_weights_after_usage(task, predicted_score, usage_30d, weights):
    dominant = argmax_dimension(task.score_vector)
    if predicted_score > 8.0 and usage_30d < 3:
        weights[dominant] *= 0.9
    elif predicted_score < 5.0 and usage_30d > 5:
        weights[dominant] *= 1.1
    return normalize_to_sum_one(weights)

3.8 Code-to-paper mapping

Code reference: main @ 1c9f141e (2026-05-26) — pseudocode and mapping based on this commit

Paper ConceptSource FileKey Class/Function
Unified agent loopagent_loop.pyagent_runner_loop, BaseHandler.dispatch, StepOutcome
Runtime entry / Interact / Reflect modesagentmain.pyGenericAgent.run, CLI args --task, --reflect, get_system_prompt
9 atomic tool declarationsassets/tools_schema.jsoncode_run, file_read, file_write, file_patch, web_scan, web_execute_js, ask_user, update_working_checkpoint, start_long_term_update
Tool implementations and dispatch handlersga.pyGenericAgentHandler.do_*, code_run, file_read, file_patch, web_scan, web_execute_js
Working-memory anchorga.py_get_anchor_prompt, do_update_working_checkpoint, turn_end_callback
Long-term memory update triggerga.py, memory/memory_management_sop.mddo_start_long_term_update, L2/L3 update SOP
Context compression / evictionllmcore.pycompress_history_tags, trim_messages_history, _sanitize_leading_user_msg
Text-protocol tool schema elisionllmcore.pyToolClient._prepare_tool_instruction, _build_protocol_prompt
Reflect / autonomous triggerreflect/autonomous.py, reflect/scheduler.py, reflect/goal_mode.pycheck, scheduler JSON polling, L4 archive cron
L4 session archivememory/L4_raw_sessions/compress_session.pycompress_session, extract_history, batch_process
Public evaluation pointerREADME.mdlinks JinyiHan99/GA-Technical-Report and summarizes five evaluation dimensions

4. Experimental Setup (实验设置)

论文不是训练一个新模型，而是评估一个 agent runtime；因此没有传统意义上的 GPU count、learning rate、batch size 或 gradient training steps。论文未详细说明硬件环境。关键可复现实验配置是 backbone model、benchmark/task 采样、系统设置和上下文/memory 参数。

Backbone / systems. 主要比较 GA、Claude Code、OpenClaw 和 CodeX。不同实验使用 Claude Sonnet 4.6、Claude Opus 4.6、MiniMax M2.7、GPT-5.4；web browsing 和 self-evolution 的 GA/OpenClaw 对比使用 Claude Opus 4.6；long-horizon complex tool-use 任务使用 Claude Sonnet 4.6；memory continuous-use 实验使用 GPT-5.4；LoCoMo factual memory 对比中所有系统使用 GPT-5.4，embedding baseline 使用 text-embedding-3-small。

Datasets / benchmarks. 论文覆盖五类评估：

Evaluation dimensionBenchmark / task scalePurpose
Task completion & token efficiencySOP-Bench, Lifelong AgentBench, RealFin-Benchmark多步 SOP、跨任务依赖、金融工作流的成功率与 token 成本
Tool-use efficiency11 simple tasks + 5 long-horizon complex tasks检验 9 atomic tools 是否能替代更大 specialized tool set
Memory effectiveness5 HuggingFace dataset-download repeated runs; SOP-Bench dangerous_goods; LoCoMo first subset with Category 5 removed; 20-skill stress test检验连续使用、memory ablation、事实记忆和 prompt growth
Self-evolution9-round LangChain GitHub research task; 8-task web benchmark repeated 3 times检验从 cold start 到 SOP optimization 再到 codified execution 的 token convergence
Web browsingWebCanvas 12 tasks; BrowseComp-ZH 10 tasks; Custom Tasks 22 tasks检验开放网页、中文多跳浏览和开放式真实工作流

Baselines. 主要 baselines 是 Claude Code、OpenClaw、CodeX；memory 子实验加入 Mem0、A-MEM；web browsing 主要对比 OpenClaw；LoCoMo 中把 embedding-based memory 与 non-embedding agent memory 分开比较。

Metrics. 任务层使用 Accuracy / Task Success Rate (TSR)；效率层报告 Input Tokens、Output Tokens、Total Tokens、Efficiency，其中 Table 2 定义 ；tool-use 任务报告 Success、Total Tokens、Time、Requests、Tool Calls；LoCoMo 使用 F1 衡量事实正确性和完整性，BLEU-1 衡量 lexical similarity；web browsing 使用 normalized Score (0–1) 和 Avg. Tokens (M)。

Runtime/config hyperparameters. 论文与 release code 中可确认的关键系统参数包括：GA 目标 compact context under 30k tokens；字符预算近似 chars/token；tag-level compression 约每 5 turns 执行一次，保留最新 10 messages，强制压缩时只保留最新 4 messages；旧 tag 内容保留首尾约 800 characters；全局超预算后 FIFO eviction 到 60% budget；working-memory anchor 注入最近 20 个 turn summaries；tool-output 上限包括 code_run=10,000 chars、web_execute_js=8,000 chars、web_scan(text_only)=10,000 chars、web_scan(HTML)=35,000 chars、file_read≈1,280 chars/line; 20,000 total。这些数字来自论文 Table 1 与 released code llmcore.py / ga.py，而不是通用默认配置。

5. Experimental Results (实验结果)

5.1 Task completion 与 token efficiency

Table 2 显示 GA 在多个 benchmark 上保持高成功率，同时显著减少输入 tokens。SOP-Bench 上，GA + Claude Sonnet 4.6 达到 100% accuracy，2.08M total tokens，efficiency 0.48；OpenClaw 同为 100% 但 2.64M total tokens，Claude Code 只用 1.25M total tokens 但 accuracy 降到 85%。Lifelong AgentBench 上，GA + Claude Sonnet 4.6 达到 100%，只用 241k total tokens，efficiency 4.15；OpenClaw 为 70%、1.45M、0.48；Claude Code 为 75%、814k、0.92。RealFin-Benchmark 上，GA + Claude Sonnet 4.6 达到最高 65%，114k total tokens，efficiency 5.70；Claude Code Opus 4.6 为 60%、307k、1.95；CodeX GPT-5.4 为 60%、892k、0.67；OpenClaw 为 35%、251k、1.39。

BenchmarkAgent / modelAccuracyInputOutputTotalEfficiency
SOP-BenchGA / Claude Sonnet 4.6100%2.02M53k2.08M0.48
SOP-BenchOpenClaw / Claude Sonnet 4.6100%2.60M40k2.64M0.38
SOP-BenchClaude Code / Claude Sonnet 4.685%1.23M23k1.25M0.68
SOP-BenchGA / MiniMax M2.790%893k32k924k0.97
Lifelong AgentBenchGA / Claude Sonnet 4.6100%222k20k241k4.15
Lifelong AgentBenchOpenClaw / Claude Sonnet 4.670%1.43M21k1.45M0.48
Lifelong AgentBenchClaude Code / Claude Sonnet 4.675%800k14k814k0.92
RealFin-BenchmarkGA / Claude Sonnet 4.665%102k12k114k5.70
RealFin-BenchmarkCodeX / GPT-5.460%838k54k892k0.67

结论是：GA 不是在所有设置下 token 最少，但它更常处在高成功率和低总成本的 Pareto 好位置，尤其在 Lifelong AgentBench 与 RealFin 这种跨任务/专业工作流中优势明显。

5.2 Tool-use efficiency

Table 3/4 支持 minimal toolset 的系统收益。工具 inventory 上，Claude Code 源码层暴露 53 个 built-in tools（20 base + 33 conditional），OpenClaw 有 18 个 source-level tool factories，GA 只有 9 个 atomic tools。5 个 long-horizon complex tasks 平均结果如下：Claude Code 成功率 100.0%，537,413 total tokens，320.8s，32.6 requests，22.6 tool calls；GA 成功率 100.0%，188,829 total tokens，220.8s，11.0 requests，12.8 tool calls；OpenClaw 成功率 80.0%，633,101 total tokens，183.1s，15.0 requests，16.6 tool calls。

这说明 GA 的收益不只是 prompt schema 更短，还包括动作选择更稳定：少量工具让模型更快进入正确组合，减少 probe/retry，最终在同等成功率下把 token 降到 Claude Code 的约 35.1%，requests 降到约 33.7%，tool calls 降到约 56.6%。

5.3 Memory effectiveness

Memory ablation 表明“压缩过的高密度 memory”优于“更多 memory”。SOP-Bench dangerous_goods 上，No-Memory 的 TSR 只有 13.87；Full-Memory 使用 575 tokens，TSR 52.44；Redundant-Memory 使用 288 tokens，TSR 66.48；Condensed Memory 只用 165 tokens，同样达到 66.48 TSR。因此，额外背景解释和弱相关内容没有贡献，反而增加上下文负担。

LoCoMo factual memory 上，GA 在不使用外部 embedding retriever 的情况下优于 Mem0、A-MEM 和 OpenClaw：Multi-Hop F1/BLEU 为 43.33/39.96，Temporal 为 52.23/51.11，Open-Domain 为 20.41/15.31，Single-Hop 为 45.69/40.66。20-skill stress test 中，安装 20 个 skills 并密集使用后，用最小输入 “Hello” 测 Full Prompt Length：Claude Code 22,821 tokens，CodeX 23,932，OpenClaw 43,321，GA 2,298。这直接验证了 L1 pointer + on-demand deep memory 的作用：长期记忆增长不等于默认 prompt 增长。

5.4 Self-evolution：从 222k tokens 到 23k tokens

九轮 LangChain GitHub research task 展示了 GA 从探索到 SOP，再到 codified execution 的相变。Round #1 初始运行耗时 7m30s，32 LLM calls，总 tokens 222,203；Round #2–#5 是 SOP optimization，总 tokens 从 66,341 降到 35,536；Round #6–#9 是 Codified SOP，总 tokens 稳定在约 23k 左右，Round #9 为 1m38s、5 LLM calls、23,010 tokens。论文报告相对 Round #1，Round #9 runtime 降低 78.2%，LLM calls 降低 84.4%，total tokens 降低 89.6%。

Figure 5 解读：Figure 5 把 8 个 web benchmark tasks 的前三次执行画成 token convergence 曲线。GA 在所有任务上后续运行都比首轮低，saving rate 从 61.0% 到 92.4%，整体降低 79.3%；OpenClaw 没有稳定收敛，有些任务还会在后续运行变贵。图中最重要的现象是“一次性适配成本”：GA 首轮要把通用 SOP 对齐到具体网页和任务，但成功路径进入 memory 后，第二/三轮迅速接近低成本稳定区。

5.5 Web browsing

Web browsing 是对上下文密度最苛刻的场景，因为 raw HTML、DOM、无关导航栏和动态页面状态会快速制造噪声。Table 9 显示，在同样使用 Claude Opus 4.6 的条件下，GA 在三个 benchmark 上都比 OpenClaw 分数更高、平均 token 更低：WebCanvas 12 tasks 上 GA 得分 0.834、0.18M tokens，OpenClaw 0.72、0.71M；BrowseComp-ZH 10 tasks 上 GA 0.60、0.47M，OpenClaw 0.20、1.31M；Custom Tasks 22 tasks 上 GA 0.577、0.26M，OpenClaw 0.50、0.76M。

Figure 6 解读：Figure 6 同时展示 token consumption 与 normalized score。GA 的柱形 token 成本在三个任务集上都显著低于 OpenClaw，同时折线/分数更高；这说明 structured browser extraction 与 memory filtering 不只是“省 token”，还减少了状态混淆，使模型更容易把注意力放在网页任务的真实目标、当前页面状态和下一步动作上。

5.6 Limitations 与总体结论

作者在 autonomous exploration 部分明确列出限制：30-round execution cap 可能让复杂研究任务跨多个 session，目前连续性主要依靠 written reports 和 task-list annotations；reflection-based weight adjustment 仍是 preliminary design，缺少足够长期数据证明其在多样真实 workflow 上稳定有效；self-improvement log 依赖人工整理；高级 skill tree maintenance（合并冗余类别、淘汰过时工具、重构树结构）仍需人工维护。

总体上，实验支持一个系统设计结论：增强 long-horizon agent 不一定要不断增加工具、插件、memory 容量或上下文窗口；更关键的是控制信息如何进入、保留、压缩和更新。GA 在任务完成、工具效率、memory、self-evolution 和 web browsing 五个维度上展示了相同模式：把冗余历史和接口噪声从活跃上下文中移除，把经过验证的经验转化成可复用 SOP/code/skill，才能让 agent 随使用变得更便宜、更稳定，而不是越来越臃肿。