文章核心观点 - 华为诺亚方舟实验室与先进计算与存储实验室联合提出AgentInfer，这是一个面向工业Agent的端到端加速框架，其核心在于将推理架构设计与推理服务系统进行协同优化，以解决大模型Agent从Demo走向生产时遇到的真实效率瓶颈[2] - 该框架不是单点技巧，而是一套可拆可合的系统化方案，其四个模块单独启用均有收益，组合后收益可叠加，并且在高并发、多会话、长上下文的真实负载下依然有效[2] - 文章认为，Agent的效率优化不能仅关注单步推理速度，而应着眼于减少无效回合、减少重算、提高跨轮次复用，本质是一个需要从端到端出发的系统性问题[4][8][27] - 实验表明，AgentInfer在工业场景下能显著提升效率，例如将无效token消耗降低50%以上，实现1.8倍至2.5倍的端到端加速，同时保持任务准确率稳定，并在高并发下QPS（每秒查询率）提升可达2.52倍[24][29] 传统Agent加速方法的陷阱 - **量化陷阱**：对模型进行INT8量化后，单步推理速度提升45.0%（吞吐从42.5 Tokens/s提升至61.6 Tokens/s），平均推理时间减少33.3%（从45.0秒降至30.0秒），但由于精度下降导致任务成功率从88.2%降至61.7%，触发大量自我修复回路，使平均恢复时间暴增1000%（从5.0秒增至55.0秒），端到端总时间反而上升[5][6] - **文本总结不靠谱**：通过总结压缩上下文，虽然使单步平均token数从8,500降至2,100（压缩4倍），但导致平均解决问题所需轮次从4.0轮激增至14.0轮（增加3.5倍），总token消耗仅从约34k降至约29.4k（边际收益），并引入高上下文漂移率，认知模糊性增加[6][7] - **记忆持久性瓶颈（KV-cache）**：在高并发下，采用短作业优先（SJF）调度策略时，长上下文（>32K）会话的KV-cache命中率极低（仅15%），导致大量重算，prefill延迟高达3,100毫秒，严重影响系统吞吐和稳定性[7][8] AgentInfer框架的四个核心模块 - **AgentCollab：难度感知的大小模型协作** - 核心思路是将常规工作交给小模型，关键规划与卡住的推理交给大模型，通过一个结构化的Progress Check自评机制动态判断是否取得实质进展，若停滞则升级到大模型救场，从而在多数时间使用便宜模型，仅在困难段落调用昂贵模型，实现质量与成本间的帕累托最优[12][13] - **AgentCompress：语义压缩与异步蒸馏** - 针对深度研究/搜索型Agent上下文易被搜索结果等撑爆的问题，该模块执行两项操作：一是用轻量模型对搜索结果（URL/摘要）进行过滤排序，减少无关内容进入后续流程，降低并行工具调用压力；二是异步压缩工具输出等“环境交互记忆”，但关键保留“推理轨迹”，以维持Agent的认知连续性，避免因“失忆”导致回合数暴涨[14][16][17] - **AgentSched：KV-aware的自适应调度** - 为解决高并发下长短请求混合导致的调度矛盾（纯FCFS被长请求阻塞，纯SJF牺牲长会话KV-cache持久性），该模块引入一个可解释的控制信号（shadow-price），在“优先短请求低延迟”和“优先高KV复用”之间自适应切换，缓存宽松时类似SJF，缓存紧张时更偏KV-aware，从而保护长会话上下文，减少昂贵的prefill重算，确保系统在高压力下不抖动、不崩溃且吞吐能提升[19][20][25] - **AgentSAM：跨会话投机解码** - 利用后缀自动机（SAM）识别并利用Agent推理中出现的高重复模式（如多轮反复提问、相似请求模板、多次引用的检索证据），将当前会话与语义相似的历史会话组合，为投机解码提供更高命中率的草稿，同时通过异步构建避免阻塞首token延迟，并带有自适应开关，在batch太大或投机收益变差时自动回退，避免负优化[21] 框架的性能与工业可用性 - **模块化与增益可叠加**：实验采用逐步叠加方式，在BrowseComp-zh / DeepDiver基准上进行端到端评估，结果显示每个模块的加入都能带来额外增益，组合后收益叠加而非相互抵消[23][26] - **高并发下的稳定性能提升**：在并发会话数（Nparallel）从4提升到16时，系统QPS提升依然稳定 - 仅使用AgentCollab，QPS提升为1.32倍（Nparallel=4）至1.52倍（Nparallel=16） - 叠加AgentCompress后，提升至1.57倍至2.01倍 - 再叠加AgentSched后，提升至1.71倍至2.25倍 - 全部四个模块叠加后，最终提升达到1.97倍至2.52倍，证明优化在资源争用、缓存压力大的真实负载中保持稳定[24] - **端到端效率优化显著**：框架能将无效token消耗降低50%以上，实现1.8倍至2.5倍的端到端加速，同时保持任务准确率稳定，其设计目标是让Agent在长周期任务与高并发环境中保持效率与认知稳定，定位为一套自演进引擎[29]

当前LLM智能体的核心痛点 - 任务成功率低，复杂任务时Agent容易卡在某个步骤不知所措 [1] - 任务执行效率差，完成简单任务需进行几十轮交互，耗时漫长 [1] 图形用户界面（GUI）的设计缺陷 - GUI为人类设计，其命令式交互模式与LLM能力模型背道而驰 [3] - GUI功能访问依赖导航和交互，控件隐藏在层层菜单后，需高频"观察-操作"循环 [3] - GUI基于人类四大关键假设：精于视觉识别、操作循环快、记忆容量小、擅长做选择题，这些与LLM能力完全错配 [3][5] 声明式接口（GOI）的解决方案 - 核心思路是将接口从"命令式"转换为"声明式"，实现策略与机制分离 [4][7] - GOI接管繁琐的底层机制操作，为LLM提供三个声明式原语：访问、状态和观察 [9] - LLM只需下达高层指令，GOI自动完成所有中间GUI导航和交互，无需修改应用程序源代码 [9][14] GOI的技术实现路径 - 实现分为离线建模和在线执行两个阶段 [10] - 离线阶段自动探索应用控件，构建UI导航图，并通过算法转换为路径清晰的森林结构 [12] - 在线阶段LLM调用声明式接口，直接访问目标功能、设置控件状态或获取结构化信息 [12][13] GOI的性能提升效果 - 在OSWorld-W基准测试中，使用GPT-5模型时成功率从44%提升至74% [15] - 超过61%的成功任务仅用一次LLM调用即完成 [16] - 失败原因从53.3%的机制性错误转变为81%的策略性错误，GOI有效降低了机制层面的失败可能 [18]

文章核心观点 - 当前大模型智能体（LLM Agent）在自动操作电脑时面临成功率低和效率差的核心瓶颈，并非模型能力不足，而是源于为人类设计的图形用户界面（GUI）的命令式交互范式与LLM的能力模型不匹配 [2][4][7] - 中国科学院软件研究所团队提出全新解决方案：声明式接口（GOI），通过“策略-机制分离”原则，将繁琐的底层GUI导航和交互自动化，使LLM能专注于其擅长的语义理解和任务规划 [10][12][15] - 实验证明GOI能显著提升性能，在OSWorld-W基准测试中，任务成功率从44%提升至74%，并将失败原因从机制性错误主导转变为策略性错误主导 [21][24][25] GUI的固有瓶颈与LLM能力错配 - GUI是为人类量身定制的命令式设计，其核心问题在于应用程序的功能无法被直接访问，必须依赖导航和交互，例如控件隐藏在层层菜单后，使用需要高频的“观察-操作”循环 [5] - GUI设计基于对人类用户的四个关键假设：精于视觉识别、操作反应快、临时记忆容量小、擅长做选择题而非回忆具体规则 [8] - LLM的能力与GUI假设完全错配：视觉识别能力有限、单次推理反应慢、拥有巨大上下文窗口不怕信息量大、输出精确结构化指令是强项 [8] - 这种错配导致LLM在操作GUI时需同时承担“大脑”（策略规划）和“双手”（底层操作）的角色，认知负担过重，极易出错 [6] 声明式接口（GOI）的解决方案 - GOI的核心思想是将交互方式从“命令式”转换为“声明式”，实现“策略-机制分离”，LLM只需下达高层指令，GOI自动完成所有中间GUI操作 [10][12][14] - GOI为LLM提供三个声明式原语接口：访问（直接声明目标功能控件ID）、状态（直接声明控件的最终状态）、观察（直接获取控件结构化信息） [12][22] - 该方案无需修改应用程序源代码，也不依赖应用程序对外提供API，而是基于GUI和操作系统的通用可访问性实现 [15][19] GOI的实现机制与性能提升 - GOI实现分为离线建模和在线执行两阶段：离线阶段自动探索应用并构建无歧义的“UI导航图”（森林结构）；在线阶段LLM使用压缩后的文本化“地图”和声明式接口下达指令 [16][18][19] - 在包含Word、Excel、PowerPoint的OSWorld-W基准测试中，使用GPT-4推理模型，GOI将任务成功率从44%大幅提升至74% [21] - 失败分析显示，使用传统GUI时，53.3%的失败源于机制层面错误（如控件定位、导航、交互错误）；引入GOI后，81%的失败集中于策略层面（如语义理解错误），成功降低了机制性错误 [24][25] 行业影响与未来方向 - GOI的提出为设计更适合大模型的交互范式指明了清晰方向，启发行业思考未来的操作系统和应用程序是否应原生提供“LLM友好”的声明式接口 [27][28] - 该工作为提升现有AI Agent的性能提供了切实可行的解决思路，有望推动更强大、更通用AI Agent的发展 [27][28]