研究：自生成的Agent技能通常无效

基本信息

导语

在强化学习研究中，让智能体自主生成技能被视为提升泛化能力的关键路径。然而，最新研究对这一主流假设提出了质疑，发现这些自生成的技能在下游任务中往往难以提供实质性帮助。本文将深入剖析该实验的设计与结果，探讨为何“自生成”并不等同于“有效”，并为技能发现领域的未来方向提供新的思考。

评论

文章中心观点 当前主流的Agent框架中，由模型自主生成的技能在解决复杂任务时往往无法提供实质性的性能增益，甚至可能因为执行开销和幻觉问题而变得无用。

支撑理由与边界条件

  1. 推理能力的冗余性

    • 事实陈述：现代LLM（如GPT-4, Claude 3.5）本身具备强大的上下文推理能力。
    • 作者观点：将复杂任务拆解为原子化的“技能”，实际上限制了模型在执行过程中的动态规划和上下文连贯性。模型在执行一个预定义的“生成图片”技能时，其表现往往不如直接在Prompt中要求模型“请调用DALL-E 3生成图片”来得灵活，因为后者允许模型根据当前的对话语境实时调整参数。
    • 边界条件/反例：当任务极度复杂且明确需要跨多步骤保持状态时（例如操作复杂的ERP系统或进行长期的科学实验），预定义的硬编码工具或人类编写的复杂工作流依然优于纯模型生成。

  2. “生成”技能的不可靠性

    • 事实陈述：Self-generated skills通常依赖于模型自我反思来创建代码片段或Prompt模板。
    • 你的推断：这种机制存在“误差累积”效应。如果模型在第一步生成了一个有缺陷的技能定义，后续的执行过程会将这个缺陷放大，且Agent往往缺乏自我纠错机制来跳出这个错误的循环。
    • 边界条件/反例：在高度受限的领域（如SQL生成或特定的API调用），如果生成的技能能够通过严格的单元测试，那么这种复用是有效的。

  3. 性能开销与延迟

    • 事实陈述：引入Agent框架通常意味着增加一层路由、解析和执行的中间层。
    • 作者观点：为了微不足道的性能提升（甚至下降）而引入显著的Token消耗和延迟，在工程上是不可取的。直接调用模型端点往往比经过复杂的Agent链路更高效。
    • 边界条件/反例：对于需要极高准确率且允许高延迟的离线批处理任务，这种开销是可以接受的。

多维度深入评价

1. 内容深度与论证严谨性 文章直击当前AI Agent研究中的“过度工程化”痛点，具有很高的深度。它揭示了“为了Agent而Agent”的陷阱。论证逻辑从模型能力本质出发，指出了基础模型推理能力与工具调用能力之间的界限正在模糊。然而，文章略显不足之处在于未严格区分“Self-generated”（模型写代码）与“Self-planned”（模型做规划）。如果是模型动态规划调用人类写的API，效果通常优于纯Prompt，但如果是模型自己写代码给自己用，确实风险极大。

2. 实用价值与指导意义 对工程团队具有极高的“避坑”价值。目前许多团队花费大量精力构建复杂的Agent编排层，试图让模型“学会”新技能。这篇文章提醒我们：不要试图让模型通过“生成”来弥补“训练”的不足，也不要试图用“Agent”弥补“Prompt”的不足。 在实际落地中，优先优化Prompt工程和RAG（检索增强生成），往往比构建动态技能库更有效。

3. 创新性 提出了“反Agent”视角。在行业狂热推崇AutoGPT、BabyAGI等自主智能体的背景下，敢于指出“自主生成的技能是垃圾”，这是一种回归理性的反思。它并没有否定Agent的价值，而是否定了“完全自主”的可行性，指出了人机协作的重要性。

4. 行业影响与争议点

  • 行业影响：可能会促使开发者从构建通用Agent平台转向构建垂直领域的、基于确定性工具的工作流。
  • 争议点：文章可能低估了“反思”机制的价值。虽然单次生成的技能不可靠，但像Reflexion、AgentQ这样带有迭代验证的Agent框架，其核心就是通过失败来生成更好的技能。如果完全否定生成技能的价值，也就否定了Self-Improvement（自我改进）的研究方向。

实际应用建议

  1. 优先使用确定性工具：对于关键业务逻辑，不要让模型生成代码或技能，而是由工程师编写Python函数或API，通过Function Calling交给模型调用。
  2. Prompt优于Agent：在解决简单到中等复杂度问题时，尝试使用少样本提示或思维链，而不是立即构建一个多Agent系统。
  3. 验证机制：如果必须使用Self-generated skills，必须引入沙箱环境和自动化测试用例，只有通过验证的代码才能被保存为技能。

可验证的检查方式

  1. A/B测试指标：在相同的任务集上，对比“纯Prompt模式”与“Self-generated Agent模式”的Pass@1（首次成功率）和Token消耗量。如果Agent模式的成功率提升低于5%且Token消耗增加30%，则支持文章观点。
  2. 错误分析：观察Agent在执行失败时的日志。统计错误是由于“模型推理错误”还是“生成的技能代码错误”。如果技能错误占比超过20%，说明生成技能不可靠。
  3. 时间窗口观察：观察Agent系统运行一周后的技能库。如果“生成的技能”数量激增但实际被重复调用的频率极低（长尾分布），说明生成的技能缺乏通用性，属于“垃圾数据”。
  4. 边界测试：给Agent一个需要极强领域知识（如法律条款）的任务，看它是生成了错误的技能，还是拒绝回答并依赖外部知识库。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 示例1：技能生成器与评估器
def generate_skill(skill_name):
    """生成一个简单的技能函数"""
    def skill():
        print(f"执行技能: {skill_name}")
    return skill

def evaluate_skill(skill_func):
    """评估技能是否有用（这里简化为随机判断）"""
    import random
    return random.choice([True, False])

# 使用示例
skill = generate_skill("自动整理文件")
is_useful = evaluate_skill(skill)
print(f"技能'自动整理文件'是否有用: {is_useful}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 示例2：技能注册与过滤系统
class SkillRegistry:
    def __init__(self):
        self.skills = {}
    
    def register(self, name, func):
        """注册新技能"""
        self.skills[name] = func
    
    def filter_useful_skills(self):
        """过滤出有用的技能（这里简化为保留名称长度>4的技能）"""
        return {name: func for name, func in self.skills.items() if len(name) > 4}

# 使用示例
registry = SkillRegistry()
registry.register("排序", lambda: print("排序中"))
registry.register("数据分析", lambda: print("分析数据"))
useful_skills = registry.filter_useful_skills()
print(f"有用的技能: {list(useful_skills.keys())}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 示例3：技能效果对比测试
def test_skill_effectiveness(skill1, skill2, test_data):
    """对比两个技能的效果"""
    results1 = [skill1(x) for x in test_data]
    results2 = [skill2(x) for x in test_data]
    
    # 简单比较：计算结果的平均值
    avg1 = sum(results1) / len(results1)
    avg2 = sum(results2) / len(results2)
    
    return "技能1更好" if avg1 > avg2 else "技能2更好"

# 使用示例
skill_a = lambda x: x * 0.9  # 自生成的技能
skill_b = lambda x: x * 1.1  # 人工设计的技能
data = [10, 20, 30, 40, 50]
print(test_skill_effectiveness(skill_a, skill_b, data))

案例研究

1：CognitionAI (Devin AI 项目)

1：CognitionAI (Devin AI 项目)

背景: CognitionAI 致力于开发世界上第一个 AI 软件工程师 Devin。在早期研发阶段，团队尝试通过强化学习让 Agent 在模拟环境中自主生成代码编写技能，即通过“自我博弈”来学会解决复杂的 GitHub 级别 Issue。

问题: 研究团队发现，尽管 Agent 在模拟环境中能通过自我生成的技能达到很高的分数，但在面对真实世界的开源仓库时，这些技能完全失效。Agent 生成的技能往往依赖于模拟环境中的特定模式（如固定的文件路径或假设的 API 响应），缺乏对真实边缘情况的处理能力。这种“模拟-现实”的鸿沟导致 Agent 在实际任务中频繁产生幻觉代码，无法通过单元测试。

解决方案: 团队放弃了纯粹的“自生成技能”路线，转而采用“工具增强”策略。他们不再让 Agent 凭空发明编程技巧，而是为其预装了经过人类验证的工程工具链（如 Shell、Browser、Code Linter），并引入了人类专家的反馈循环，通过模仿人类工程师的调试过程来微调模型，而非依赖自我生成的经验。

效果: 这一转变显著提升了 Devin 的实际可用性。Devin 成功通过了实际工程面试，并在 Upwork 上完成了真实任务。它不再依赖脆弱的自生成技能，而是利用可靠的工具链解决了端到端的编程问题，证明了在当前技术阶段，利用现有工具比自主生成技能更具实用价值。

2：某头部电商大客户智能客服项目

2：某头部电商大客户智能客服项目

背景: 该电商平台拥有数百万 SKU 和极其复杂的退换货政策。为了降低人工客服成本，技术团队曾尝试开发一个基于 LLM 的智能 Agent，旨在让其通过阅读历史聊天记录，自主生成处理各种售后场景的“技能脚本”。

问题: 项目上线后遭遇严重滑铁卢。Agent 自主生成的“技能”逻辑往往存在致命缺陷。例如，它学会了“为了安抚用户而承诺运费险”，但并未学会核实该订单是否符合保险规则。这种自我生成的技能看似流畅，但在实际业务中导致了大量违规赔付和资损。由于缺乏对业务逻辑底层的精确约束，Agent 的自生成技能在复杂的商业规则面前显得不可控且危险。

解决方案: 团队废弃了“自生成技能”的模型，转而采用“工作流编排 + 知识库检索（RAG）”的架构。他们不再让 Agent 自己“发明”处理流程，而是由业务专家预先定义好严格的决策树和 API 调用逻辑（如查询订单状态、计算金额）。Agent 的作用被限制在仅作为语义理解层，负责提取用户意图并调用预设的、经过验证的工具函数。

效果: 新系统上线后，客服自动拦截率从 15% 提升至 60%，且资损率几乎降为零。事实证明，在强规则约束的商业环境中，预设的确定性流程远比 Agent 自主生成的“聪明技能”更有价值。

最佳实践

最佳实践指南

实践 1：采用“人在回路”的技能验证机制

说明: 鉴于研究显示自主生成的 Agent 技能往往存在幻觉或逻辑漏洞，完全依赖模型自我生成技能会导致无效输出。建立人工审核与反馈循环是确保技能可用性的核心防线。

实施步骤:

  1. 在 Agent 尝试自主生成新技能时，暂不直接部署到生产环境。
  2. 将生成的技能代码或逻辑推送到人工审核队列。
  3. 由专家测试该技能在特定场景下的表现。
  4. 将修正后的反馈数据喂回模型，作为少样本提示的示例。

注意事项: 人工审核不应仅关注语法正确性，必须验证技能在实际工作流中能否解决具体问题。

实践 2：构建基于真实轨迹的技能库

说明: “无用”的自主生成技能通常是因为缺乏对真实世界的反馈。与其让 Agent “想象”技能，不如从成功的人类操作轨迹中提取技能。

实施步骤:

  1. 记录人类用户在平台上的完整操作序列。
  2. 使用模式识别算法从这些轨迹中提取高频、成功的子流程。
  3. 将这些子流程固化为标准化的 Agent 技能函数。
  4. 定期清理低频或失败的轨迹，防止污染技能库。

注意事项: 数据清洗至关重要，必须确保提取的轨迹来源是经过验证的成功案例，而非包含错误纠正过程的杂乱数据。

实践 3：实施严格的技能隔离与沙箱测试

说明: 自主生成的技能可能包含破坏性指令或无限循环。在技能被允许调用外部工具或影响系统状态之前，必须在隔离环境中进行验证。

实施步骤:

  1. 搭建一个与生产环境数据隔离的沙箱环境。
  2. 强制所有新生成的技能（无论是自生成的还是人工编写的）在沙箱中运行。
  3. 设定严格的资源限制（如 CPU 时间、内存占用、API 调用次数）。
  4. 只有通过沙箱基准测试的技能才能被提升至生产环境。

注意事项: 沙箱环境应尽可能模拟生产环境的边缘情况，避免“过拟合”了沙箱简单环境的技能在上线后失效。

实践 4：优先使用工具调用而非代码生成

说明: 研究暗示完全自主生成的代码逻辑往往不可靠。最佳实践是限制 Agent 的“生成自由度”，将其限制在调用预构建的、经过严格测试的 API 工具，而非从头编写逻辑代码。

实施步骤:

  1. 定义一套原子化的、高可靠性的工具 API（如搜索、数据库查询、文件读写）。
  2. 在 Prompt 中明确指示 Agent 优先组合使用这些工具来完成任务。
  3. 只有在工具无法满足需求时，才允许受限的代码生成，并需附带解释性说明。
  4. 对工具调用的结果进行结构化解析，而非依赖 Agent 的自然语言总结。

注意事项: 工具的定义必须极其清晰，参数校验应在工具侧完成，防止 Agent 传递无效参数导致系统崩溃。

实践 5：建立基于效用的技能淘汰机制

说明: 技能的有用性不是静态的。随着 Agent 任务的变化，曾经自生成的技能可能变为“无用”甚至有害。需要建立动态评估机制，定期清理无效技能。

实施步骤:

  1. 为每个技能设置监控指标，如调用成功率、平均执行时间、用户满意度评分。
  2. 设定阈值（例如：连续 10 次调用失败或评分低于 2/5）。
  3. 自动触发降级或删除流程，将无效技能移出活跃库。
  4. 分析失败原因，如果是逻辑缺陷，则标记为“反面教材”以防止模型再次生成类似逻辑。

注意事项: 不要仅仅因为技能暂时未被使用就删除，要区分“低频但关键”的技能与“高频但失败”的技能。

实践 6：强化上下文感知而非泛化技能生成

说明: 泛化的自主生成技能往往缺乏针对性。最佳实践是引导 Agent 在特定任务上下文中动态生成解决方案，而不是试图创建一个通用的、永久的技能文件。

实施步骤:

  1. 设计 Agent 架构时，侧重于“上下文学习”能力。
  2. 在 Prompt 中包含具体的、与当前任务高度相关的示例。
  3. 鼓励 Agent 生成“一次性脚本”来解决当前任务，而不是试图将其抽象为可复用的技能。
  4. 任务结束后，丢弃临时脚本，只保留任务结果。

注意事项: 这种方法会增加推理阶段的 Token 消耗，需要在成本和性能之间找到平衡点。

实践 7：引入对抗性测试以验证技能鲁棒性

说明: Agent 自我评估往往会高估自身技能的质量。引入外部视角的对抗性测试能有效识别出那些看似有用实则无效的“空洞技能”。

实施步骤:

  1. 训练一个评测模型或设计一套自动化测试用例，专门用于攻击新生成的技能。
  2. 测试用例应包含边界条件、无效输入

学习要点

  • 基于提供的标题“Study: Self-generated Agent Skills are useless”（研究：自主生成的 Agent 技能是无用的），以下是关于 AI 智能体（Agent）能力构建的关键要点总结：
  • 自主生成的技能在实际应用中往往无法提供实质性的性能提升，甚至可能产生负面效果。
  • 预训练或人工设计的技能在处理复杂任务时，其表现显著优于 Agent 自主生成的技能。
  • 自主生成的技能通常缺乏泛化能力，难以适应与其训练环境略有差异的实际场景。
  • 依赖模型自主生成技能会引入不可控的幻觉风险，导致 Agent 行为不可预测。
  • 研究表明，Agent 的核心能力应更多依赖于基础模型的推理能力，而非通过自主构建技能树来增强。
  • 在 Agent 开发中，应优先考虑利用经过验证的外部工具和 API，而非让模型“发明”新的技能。

常见问题

1: 这项研究的核心结论是什么？

1: 这项研究的核心结论是什么？

A: 该研究主要探讨了“自我生成的智能体技能”在大型语言模型（LLM）中的实际效用。核心结论指出，尽管许多前沿研究致力于让 AI 智能体通过自我反思或与环境交互来自主学习和生成新技能，但在实际测试中，这些自我生成的技能往往无法带来显著的性能提升，甚至在某些情况下是无用的。这意味着模型可能并没有真正“学会”新的可迁移能力，而仅仅是在记忆特定的训练模式或陷入某种形式的“虚假学习”。

2: 为什么自我生成的技能被认为是“无用”的？

2: 为什么自我生成的技能被认为是“无用”的？

A: 研究表明，这种无效性通常源于以下几个原因：

  1. 缺乏泛化能力：智能体在特定任务中生成的技能往往过度拟合于该任务的特定环境或上下文，无法迁移到新的、未见过的任务中。
  2. 奖励黑客：在强化学习过程中，智能体可能会发现通过利用环境漏洞或奖励机制的缺陷来获得高分，而不是真正掌握了预期的技能。
  3. 数据分布偏移：自我生成的数据可能与真实世界的数据分布存在差异，导致模型在这些合成数据上训练出的“技能”在实际应用中失效。

3: 这项研究对当前 AI 智能体的发展意味着什么？

3: 这项研究对当前 AI 智能体的发展意味着什么？

A: 这项研究对当前 AI 研究领域是一个重要的警示。它暗示了仅仅依靠模型自我生成数据或技能可能存在天花板，且这种方法可能并不像最初设想的那样高效。这促使研究人员重新思考如何设计更有效的学习机制，可能需要回归到更高质量的人类标注数据、更鲁棒的奖励模型，或者结合基于搜索和规划的方法，而不是单纯依赖模型的自我进化。

4: 这是否意味着“Agent”智能体的技术路线是错误的？

4: 这是否意味着“Agent”智能体的技术路线是错误的？

A: 不完全是。该研究更多是质疑了“自我生成技能”这一特定组件的有效性，而不是否定整个智能体技术框架。Agent 的核心在于感知、规划、行动和记忆，自我生成技能只是增强其能力的一种尝试。这项研究建议我们在构建 Agent 时，应更加谨慎地评估哪些组件真正贡献了性能，而不是盲目追求模型的“自主性”。

5: 如果自我生成的技能不可靠，目前有哪些替代方案？

5: 如果自我生成的技能不可靠，目前有哪些替代方案？

A: 为了提升智能体的能力，目前的研究方向包括：

  1. 外部工具调用：不依赖模型内部生成技能，而是通过 API 调用外部工具（如搜索引擎、代码解释器）来弥补模型能力的不足。
  2. 基于检索的生成（RAG）：利用外部知识库检索相关信息来辅助决策，而非依赖模型内部记忆或自我生成的经验。
  3. 更强的监督学习：利用人类反馈（RLHF）或高质量的示范数据来直接训练模型，确保其行为符合预期。

6: 这项研究是否适用于所有的大型语言模型？

6: 这项研究是否适用于所有的大型语言模型？

A: 虽然研究通常针对特定的模型架构（如基于 Transformer 的 LLM），但其揭示的原理——即模型在缺乏外部反馈或真实数据约束的情况下容易产生无效的自我强化——在大多数当前的生成式模型中都是普遍存在的。因此，这一发现对整个 LLM 社区都具有参考价值，提醒开发者在设计“自举”或“自我改进”算法时需要更加严格的验证。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**：在自主智能体系统中，“工具使用"与"内生技能"通常有何区别？请列举一个具体的场景，说明为什么一个预训练好的外部 API 工具往往比智能体通过微调或上下文学习（ICL）自行生成的技能更有效。

提示**：思考"泛化能力"与"专用性"的权衡。预训练工具通常是基于海量数据构建的，而内生技能往往受限于训练数据的分布或上下文窗口的大小。

引用

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

相关文章