(2605) (IBM) Learning and Reusing Policy Decompositions for Hierarchical Generalized Planning with LLM Agents

🌺 论文摘要

HCL-GP 论文摘要

参考链接

• paper

核心方法 (HCL-GP, Hierarchical Component Learning for Generalized Policies)

• 核心想法：不是每个Task都从零写代码，而是先学习一个能解决同类任务的参数化Policy。
• Scenario-level Generalized Policy：
  • 将AppWorld一个Scenario看成一个Domain。
  • 同Scenario的多个任务共享Workflow，只把人物、金额、日期等差异变成参数。
• Hierarchical Component Learning：成功Policy再拆成登录、分页、数据Join、交易等可复用Component。
• 复用闭环：生成Policy -> 提取Component -> 聚类泛化 -> 环境验证 -> 新Scenario检索复用。

模型效果 (AppWorld)

• Claude Sonnet 4.6 + HCL-GP：Normal TGC/SGC 98.2/98.2，Challenge 98.3/97.8。
• 不复用Component的Claude GP基线：Normal 96.4/96.4，Challenge 83.2/82.0；Challenge SGC提升15.8点。
• GPT-OSS-120B + HCL-GP：Normal 62.5/62.5，Challenge 41.0/41.0；不复用的GP基线接近0。

重要结论

• AppWorld天然适合做Generalized Planning：同Scenario的任务通常是流程相同、参数不同。
• 强模型：本身已经能生成较好Policy，Component主要减少Debug和Token；Challenge上准确率仍明显提升。
• 弱模型：Component不是锦上添花，而是把Policy Synthesis从几乎0分拉到可用。
• Component可以跨App迁移：训练阶段没有Gmail/Amazon，Challenge仍能受益。
• 注意比较口径：该方法一次观察同Scenario多个Task，不能把98%直接和逐Task Agent排行榜做公平比较。

关键贡献

• 将Classical Generalized Planning与HTN式分解引入Model-free LLM Agent，无需手工Symbolic Domain Model。
• 提出“Policy生成 -> Component提取 -> Component泛化 -> 后续组合复用”的执行闭环。
• 从最终成功率、Debug Iteration和Inference Cost三方面评估复用收益。

问题背景(每个任务都从零生成Policy)

❓问题背景

Task-level Agent没有积累程序性结构

重复求解

• Task-level Agent把每个任务当成独立问题，登录、分页、Join、Filter、写入等操作需要反复探索。
• 同一Scenario的三个任务往往只是参数不同，但Agent仍要分别推理和Debug，历史代码没有真正沉淀下来。

Classical Planning启发

• Generalized Planning学习一个能解决一类问题的Parameterized Policy。
• HTN将复杂任务分解为可复用Sub-task。
• 传统方法依赖Symbolic State、Action Model和人工分解；AppWorld只提供自然语言任务、API和执行验证。

研究问题

• 能否仅凭成功执行代码与环境反馈，自动发现Hierarchical Component，并组合解决新Scenario？

核心架构(Policy Generation-Learning-Generalization)

📕核心方法

1. Scenario-level Policy Generation

Task Abstraction & Parameterization Agent

• 同时观察一个Scenario中的多个Task，抽取共享Workflow。
• 生成高层Steps、Policy Signature $\sigma (\pi )$ 和每个任务的参数绑定 ${\theta }_j$。

本质上是把3份具体程序压缩成1份带参数的通用程序。

Component Search Agent

• 根据Domain Abstraction从Validated Repository检索Top-20 Component。
• 同时从AppWorld API文档检索Top-20相关API。

Policy Generator Agent

• 综合Steps、Signature、Task Bindings、相关Component与API，生成一个Parameterized Python Policy。
• 在所有Scenario Task上实例化并执行；失败时利用Error Message、API Response和Partial Result最多Debug 3轮。

2. Learning Components

• Policy通过全部Task验证后，Decomposition Agent分析其Python代码。
• 提取实现完整Sub-task的函数，例如Authentication、Data Retrieval或Transaction Sequence。
• 同时重写原Policy，使其调用新Component。
• 重写Policy必须在原Scenario所有任务上再次通过，才把Component加入Learned Repository。

3. Generalizing Components

• 使用BAAI/bge-large-en-v1.5对Executable Code做Embedding。
• 以Cosine Similarity阈值0.85聚类相似Component。
• Generalize & Deduplicate Agent把窄函数合并为参数化抽象，例如：
  • login_to_phone + login_to_venmo -> login_to_app。
• 泛化Component及所有被重写Policy都必须重新执行验证。
• 验证通过后进入Validated Repository，供后续Scenario检索。

实验设置

✍️实验设置

实验设置

模型

• Claude Sonnet 4.6：强代码生成模型。
• GPT-OSS-120B：能力较弱的开源模型。

Component Seed构建

• 从AppWorld 30个Training Scenario开始，初始Repository为空。
• 使用Claude完成全部Training Scenario并提取Component。
• 第一轮得到101个Component，第二轮泛化后得到159个Validated Component。
• 同一个Claude构建的Seed Repository也用于GPT-OSS测试。

因此GPT-OSS结果属于开源执行模型 + Claude构建经验库，不是完全不依赖闭源模型。

评测

• AppWorld Test-Normal与Test-Challenge。
• Challenge包含训练未见的Gmail和Amazon。
• 报告TGC、SGC、累计Debug Iteration和Claude Token Cost。

基线

• GP：仍做Scenario-level Generalized Policy，但没有Component检索、学习与复用。
• 与AgentRL、CUGA、LOOP和Claude Task-level Agent结果并列比较。

关键结果

🍑关键结果

模型效果

方法	Normal TGC / SGC	Challenge TGC / SGC
GPT-OSS GP	0.0 / 0.0	0.7 / 0.7
GPT-OSS HCL-GP	62.5 / 62.5	41.0 / 41.0
Claude GP	96.4 / 96.4	83.2 / 82.0
Claude HCL-GP	98.2 / 98.2	98.3 / 97.8

Reuse最有价值的场景

• Claude + Normal：本来已经接近饱和，Reuse只提升1.8 SGC。
• Claude + Challenge：涉及未见App和复杂流程，Reuse提升15.8 SGC。
• GPT-OSS：没有Component时几乎无法合成Policy；复用后Normal达到62.5 SGC。

效率与成本

• HCL-GP在相同成功率下需要更少Debug Iteration。
• Dynamic Reuse把Cost-Accuracy Curve整体向左上移动，尤其在Challenge明显。

Component使用分析

• Learned Component利用率Normal约75%、Challenge约60%，高于Seed Component的26%-29%。
• Challenge平均每个Scenario使用6.4个Learned Component，Normal为3.8，反映难任务需要更强组合。
• 少数泛化Seed Component复用率很高，但大量在线Learned Component仍偏Task-specific。

比较时的重要口径

• HCL-GP同时接收一个Scenario中的多个相关任务来抽象Policy，而Leaderboard方法通常逐Task独立求解。
• 因此98%不能简单解释为同一Agent协议下直接超过所有Task-level方法；它同时利用了Scenario结构和额外的跨任务输入。
• GPT-OSS实验也复用了Claude构建的159个Component，不能视为完全不依赖闭源模型的纯开源结果。

未来方向

⛳未来方向

未来展望

• 目前Component是Flat Library，可进一步学习Dependency Graph与多层Hierarchy。
• Generalization和Deduplication在一次LLM调用中完成，Repository扩大后容易超过Context Limit，应拆成多阶段增量流程。
• AppWorld提供干净的Scenario边界；真实环境需要先自动发现哪些任务共享程序结构。
• 方法依赖固定Action Space、Deterministic Execution和Validator，开放环境中的Action Discovery与不完备验证仍困难。
• 需要在Scenario信息不可同时获得的Streaming Setting中评测，确认动态复用对真实逐任务到达流程的价值。

(2510) IBM CUGA) From Benchmarks to Business Impact: Deploying IBM Generalist Agent in Enterprise Production

🌺 论文摘要

CUGA: Enterprise Generalist Agent 摘要

参考链接

• paper

核心方法

• CUGA架构 (Computer Using Generalist Agent)
  • 分层规划-执行器架构
    • Chat层(预处理) -> 外循环(任务规划/账本) -> 内循环(API/Web/Code子Agent执行)
  • 可靠性机制
    • 基于Schema的Prompting、变量追踪、反思性重试(Reflective Retries)。
• 企业级适配
  • API/Tool Hub：集中化管理API，简化OpenAPI Spec。
  • 治理与安全：来源日志(Provenance Logging)、沙箱代码执行、Human-in-the-Loop。

模型效果

• 学术榜单：WebArena (61.7% SOTA) 和 AppWorld (48.2% SOTA)。
• 企业试点(BPO-TA)：
  • 准确率达87%，复现性高。
  • 相比手写专用Agent，开发时间减少90%，成本降低50%。
  • 单个任务耗时从人工20分钟降至2-5分钟。

重要结论

• 通用Agent架构(Generalist)比专用Agent(Specialized)更具成本效益和扩展性。
• 企业部署的关键不在于模型能力，而在于治理、可审计性和无幻觉的拒绝能力。

关键贡献

• 提出了BPO-TA Benchmark (业务流程外包-人才招聘基准)，包含26个真实分析任务。
• 验证了通用Agent在企业生产环境的可行性与经济效益。

问题背景

❓问题背景

原型demo到生产应用存在挑战

企业需求与现状的错位

• 企业面临巨大的自动化压力，但从Research到Deployment极其困难。
• 原型陷阱：ReAct等简单架构在Demo时表现良好，但在处理复杂流程、多工具时极其脆弱。
• 缺乏标准：学术界关注Benchmarks，企业关注SLA、审计合规和ROI，两者缺乏桥梁。

专用Agent的局限

• 传统做法是为每个任务手写Specialized Agent。
• 缺点：开发周期长 (3-9个月)、维护成本高、难以跨领域复用。

通用Agent 优势

核心假设

• 通用Agent (如CUGA) 经过复杂Benchmark训练，具备强规划和工具使用能力。
• 企业只需进行配置和领域适配，无需从头开发。
• 目标：将开发模式从“从零构建”转变为“配置与基准测试”。

📕核心方法

架构设计 (Layered Planner-Executor)

架构详解

三层控制结构

1. Chat Layer：输入预处理、上下文管理。
2. Outer Loop (规划层)：
   • Task Analyzer：分析任务意图。
   • Plan Controller：维护持久化账本 (Ledger)，记录步骤、变量和状态，确保可追溯。
3. Inner Loop (执行层)：
   • API Sub-Agent：通过API Planner和Shortlister选择工具，支持代码沙箱执行。
   • Browser Sub-Agent：支持基于Playwright的网页操作 (本次试点因合规暂时禁用)。

可靠性增强

• Reflective Retries：当工具调用失败或参数错误时，触发反思修正，而非直接报错。
• Interrupt Nodes：显式的逻辑检查节点，防止执行偏航。
• API/Tool Hub：对原始OpenAPI Spec进行最小化和标准化处理，降低LLM理解难度。

企业级治理适配

安全与合规

审计与透明度

• Provenance Logging：所有回答必须附带“来源面板”，列出调用的API路径、参数和计算日志。
• Read-Only 模式：在BPO试点中仅开放读权限，确保数据安全。
• PII 过滤：自动脱敏个人隐私信息。

Human-in-the-Loop (HITL)

• 可配置的自主权：业务方可定义哪些步骤Agent可自动执行，哪些必须人工确认。

实验设置(GPT4.1)

✍️实验设置

实验设置

基准测试

• 学术基准：
  • WebArena (网页浏览/操作)
  • AppWorld (多API编排/代码生成)
• 企业基准 (新提出)：
  • BPO-TA (Business Process Outsourcing - Talent Acquisition)
  • 包含13个分析API (如SLA分析、漏斗转化率等) 和 26个典型任务。
  • 任务类型涵盖：简单查找、跨API Join、循环推理、溯源解释、不支持功能的优雅拒绝。

评估指标

• Task Accuracy (任务准确率)
• Valid First-Try Rate (一次通过率)
• Reproducibility (结果复现性)
• Time-to-Answer (回答耗时)
• Provenance Coverage (来源日志覆盖率)

关键结果

🍑关键结果

实验结果

学术SOTA表现

• WebArena：总准确率 61.7% (Reddit任务达75.5%)，超越现有开源Agent。
• AppWorld：Test-Challenge场景完成率 48.2%，Level 1任务达87.5%。

企业试点收益 (BPO-TA)

• 准确率：达到 87%，且在不支持的查询上实现了无幻觉拒绝。
• 效率提升：
  • 人工分析需 20分钟 -> CUGA仅需 2-5分钟 (效率提升~90%)。
  • 开发成本相比专用Agent降低 50%。
• 可审计性：95% 的回答包含了完整的来源日志 (Provenance Logs)。

重要结论

• 反思机制至关重要：去掉Reflective Retries后，性能下降11个点。
• 变量追踪影响复现：去掉显式变量追踪，复现性评分大幅下降。
• 通用架构可行：证明了“通用架构 + 领域配置”可以替代昂贵的定制开发。

未来方向

⛳ 未来方向

后续计划

技术演进

• 自适应短路：利用记忆或缓存跳过重复规划步骤，降低延迟和成本。
• 轨迹复用：将成功的执行轨迹转化为新的“工具”，供后续调用。
• 小模型蒸馏：针对高频简单任务，使用更小的模型以降低成本。

组织与治理

• 更细粒度的HITL：不仅是开关，而是基于策略的动态人工介入。
• 写操作上线：从Read-Only逐步过渡到受控的Create/Update操作。
• 扩展领域：将架构推广到财务、采购、法务等其他企业部门。

(2503) (IBM CUGA)Towards Enterprise-Ready Computer Using Generalist Agent

🌺 论文摘要

论文摘要

参考链接

• paper

核心方法

• CUGA (Computer Using Generalist Agent)
  • 针对企业级需求设计的通用计算机操作智能体。
  • 分层多agent架构：Plan Controller (高层规划) + Sub-task Agents (Web/API 子任务执行)。
• 迭代式演进方法
  • 提出Evaluate-Analyze-Enhance Loop。
  • 使用Smart Sampling策略：从小样本开始快速迭代，逐步扩大测试范围。
• 工具链支持
  • 开发了性能仪表盘、轨迹可视化工具和并行执行框架以加速开发。

模型效果

• WebArena: 达到 61.7% 的任务成功率 (SOTA)。
• AppWorld: 达到 48.2% 的场景完成率 (SOTA)，在多步骤API交互上表现出色。

重要结论

• 简单的Plan-Act-Observe循环无法处理长程任务，需拆分为规划器和执行器。
• Web与API需采用不同的感知和交互策略（如Web用截图+无障碍树，API用MCP+注册表）。
• Smart Sampling（智能采样）显著降低了评估成本并加快了开发速度。

关键贡献

• 公开了实现WebArena和AppWorld 双榜SOTA的架构演进路线。
• 分享了企业级Agent开发的方法论和工具链经验。

问题背景

❓问题背景

问题背景

企业级Agent的挑战

• 现有Agent研究主要在刷榜，但企业级应用更关注隐私、安全、可信度和成本。
• 简单Agent架构在处理长程任务、多应用切换和复杂逻辑时表现不佳。

现有基准测试的局限

• 学术界Benchmark（如WebArena）通常基于静态环境或单一模态。
• 缺乏对API交互、变量管理及动态策略调整的综合评估。
• 即使OpenAI Operator或Anthropic Computer Use，在落地企业复杂工作流时仍有挑战。

分层多Agent+Smart Sampling

📕核心方法

架构演进：分层多智能体

整体架构

• Plan Controller Agent (高层规划)
  • 负责任务分解、子任务排序、循环/条件逻辑处理。
  • 核心能力：跨任务变量传递（Variable Passing），维护全局上下文。
• Sub-task Plan-Execute Agents (子任务执行)
  • 专注于局部执行，分为Browser Agent和API Agent。

Browser Sub-agent (Web端)

• 感知：结合截图 (Screenshots) 和 无障碍树 (Accessibility Tree)。
• 操作：使用 Playwright 进行浏览器控制。
• 改进：
  • 引入专用信息提取Agent，将交互与提取解耦。
  • 增加反馈循环，处理弹窗遮挡和动态UI变化。

API Sub-agent (服务端)

• 感知：利用 API Registry 管理OpenAPI Schema，通过 MCP (Model Context Protocol) 动态加载工具。
• 操作：支持复杂API调用、结果解析和变量管理。
• 改进：
  • OpenAPI精简：压缩Schema以减少Token消耗。
  • 反射机制：处理API报错和非预期输出。

AppWorld：

开发方法论：Smart Sampling

迭代策略

• 摒弃每次都跑全量测试的低效做法。
• 采样阶段：
  • Nano (44样本) -> Micro (90样本) -> Mini (190样本) -> Full (812样本)。
  • 在小样本上快速验证假设，修复Fail case，逐步扩大规模以测试泛化性。

配套工具

• 轨迹可视化：直观展示Agent的感知（截图/Dom树）、思考和动作，便于归因分析。
• 并行执行：将评估时间从“天”级缩短至“分钟”级。

实验设置

✍️实验设置

实验设置

基础模型

• 使用 Frontier LLMs (如 GPT-4.1 等，通过 LangChain 统一接口调用)。

评测数据

• WebArena: 包含电子商务、论坛、CMS等Web任务。
• AppWorld: 包含代码执行、多API调用、数据库查询等复杂任务。

评测指标

• WebArena：Success Rate (成功率)，
• AppWorld：Scenario Completion Rate (场景完成率，要求完成同一场景下的所有任务)

算法/策略

• ReAct 范式基础上的分层规划。
• LangGraph 用于状态管理和多Agent编排。
• Reflection (反思) 机制用于错误恢复。

关键结果(GPT4.1)

🍑关键结果

关键结果

WebArena 表现

• CUGA 实现了 61.7% 的成功率，刷新了 SOTA。
• 相比初始的简单Agent架构（15%），通过架构拆分和针对性优化提升了4倍以上。

AppWorld 表现

• 总榜 SOTA：TGC-Normal-Challenge 73.2%、57.6%，其中SGC-Challenge是48.2%
• 分级表现：
  • Level 1 (简单API): 任务完成率 >91%。
  • Level 3 (复杂逻辑): 场景完成率降至 ~38%，表明复杂推理仍是难点。
• 行为分析：随任务难度增加，平均交互次数显著上升，表明Agent具备动态调整策略的能力。

重要结论

• 分离关注点是关键：高层关注流程，底层关注操作，能显著提升长程任务稳定性。
• 环境感知增强（如Web端的截图+Dom树结合，API端的Schema精简）对减少幻觉至关重要。

未来方向

⛳ 未来方向

未来方向

企业级安全与合规

• 目前主要关注任务完成率，未来将重点评估安全性（Safety）和策略依从性（Policy Adherence）。
• 探索在API调用中加入安全验证层，防止Agent进行危险操作。

降低成本

• 目前依赖前沿大模型（Frontier Models）。
• 计划蒸馏或迁移至更小的开源模型，以降低企业部署成本。

自动化进化

• 目前的错误分析仍需人工介入。
• 计划开发Agentic Analysis，让Agent自动分析失败轨迹并提出改进建议，实现系统的自我进化。