国科大 2026 年春季 AI Agent 实践课题

本文档提供了一系列精心设计的 AI Agent 实践课题，涵盖从简单到困难的三个难度层次。这些课题旨在帮助学生深入理解 AI Agent 的核心技术和设计模式，包括工具使用、多 Agent 协作、长期记忆管理、外部化学习等前沿主题。每个课题都包含明确的实验目的、详细的实验内容描述和具体的验收标准，确保学生能够通过实践掌握构建高级 AI Agent 系统的关键技能。

课题按难度分为三个层次。建议学生根据自身基础选择合适的课题，循序渐进地提升能力。

课题索引

难度：简单

  1. 使用代码生成工具提升数学与逻辑推理能力
  2. 自然语言交互的 ERP Agent
  3. 狼人杀 Agent

难度：中等

  1. 个人照片搜索引擎
  2. 智能视频剪辑
  3. PPT 生成 Agent
  4. 书籍翻译 Agent
  5. 同时从多个网站搜集信息的 Agent

难度：困难

  1. 更懂你的用户记忆
  2. 边打电话边用电脑的 Agent
  3. 越用越熟练的电脑操作 Agent
  4. 能创造 Agent 的 Agent

难度：简单

使用代码生成工具提升数学与逻辑推理能力

实验目的

这是一个综合性的实验，旨在验证 Agent 通过代码生成工具（code interpreter）同时处理不同类型推理任务的能力。具体来说，通过 Python 代码生成来弥补大语言模型在两个方面的不足：

  1. 数学计算：解决纯思维链推理在数值计算精度、符号操作复杂性上的局限，利用数学库进行精准求解。
  2. 逻辑谜题：解决复杂逻辑约束（如骑士与无赖问题）中纯文本推理容易遗漏约束或逻辑冲突的问题，利用约束求解器进行穷举搜索。

实验将评估同一 Agent 如何灵活运用不同的代码库（数学库 vs 约束库）来适应不同的任务领域。

背景知识

AIME (American Invitational Mathematics Examination)：美国数学邀请赛，是介于 AMC 和 USAMO 之间的高难度数学竞赛。其题目通常无需复杂的微积分知识，但要求极高的算术准确性、代数技巧和逻辑思维严密性。对于 LLM 而言，AIME 题目是检验其复杂多步推理和精确计算能力的绝佳基准，因为纯文本推理往往容易在中间步骤出现“计算幻觉”。

骑士与无赖问题 (Knights and Knaves)：这是一类经典的逻辑谜题，由逻辑学家 Raymond Smullyan 推广。在这个虚构的岛上，”骑士”永远说真话，”无赖”永远说假话。求解者需要根据岛民的陈述（例如 A 说：”我们中间至少有一个是无赖”）来推断每个人的真实身份。这类问题极其考验逻辑一致性检查能力，纯 LLM 容易陷入逻辑死循环或遗漏隐含约束。

实验内容描述

为 Agent 配备功能完善的 code interpreter 工具，提供包含以下关键库的 Python 沙盒环境：

  • 数学领域：sympy（符号计算）、numpy（矩阵运算）、scipy（数值优化）
  • 逻辑领域：python-constraint（约束满足问题求解）

Agent 需要根据用户输入的题目类型，自动判断并采用相应的解题策略：

  • 遇到数学问题（如 AIME 竞赛题）时，将问题形式化为代数方程或计算过程，调用数学库求出精确解，避免”大约”或”可能”。
  • 遇到逻辑谜题（如骑士与无赖问题）时，将自然语言约束转化为形式化的约束变量和条件，调用 python-constraint 定义问题空间并搜索可行解，避免手动推理中的逻辑漏洞。

评测方法：
实验包含两个独立的测试集，Agent 需要在不需要人工切换提示词的情况下自动适应：

  1. 数学能力：使用 AIME 2025 数据集，对比纯思维链推理与代码辅助推理的准确率。
  2. 逻辑能力：使用 K&K Puzzle 数据集，要求代码辅助模式在不同复杂度的变体上达到 90% 以上准确率。

期望验收结果

  • Agent 能够自动识别题目类型并加载正确的 Python 库进行求解。
  • 在数学任务（AIME 2025）上，代码辅助模式的准确率显著高于纯思维链模式，且无计算精度错误。
  • 在逻辑任务（K&K Puzzle）上，代码辅助模式能够正确建模并求解复杂谜题，准确率 > 90%。
  • 展示 Agent 如何使用同一套 “Thinking -> Coding -> Execution” 的范式通用于两个截然不同的领域。

自然语言交互的 ERP Agent

实验目的

ERP（企业资源规划，Enterprise Resource Planning）软件是企业的关键软件系统，目前一般使用 GUI 界面，复杂的操作需要多次鼠标点击，操作非常麻烦。AI Agent 可以把用户的自然语言查询转换成 SQL 语句，从而实现自动化的查询。

实验内容描述

核心要求：Agent 而非 Workflow

本实验的关键在于构建一个真正的 Agent，而不仅仅是 Text-to-SQL 的线性工作流。在实际应用中，模型一次生成的 SQL 往往可能存在语法错误、字段名幻觉或逻辑漏洞。Agent 的核心价值在于其**自我修正（Self-Correction）**能力。

你需要实现一个具备反思与重试机制的 Agent：

  1. 执行与监控：Agent 生成 SQL 后调用数据库工具执行。
  2. 错误捕获：如果数据库返回错误，Agent 必须捕获该错误信息。
  3. 自主调试：Agent 根据错误信息和当前的表结构定义，分析错误原因（例如”我使用了不存在的列名 salary_date，正确的应该是 pay_date“），并生成修正后的 SQL。
  4. 自动重试：再次执行修正后的 SQL，直到获得成功或达到最大重试次数。

实验模拟环境

要求建立一个 PostgreSQL 数据库，其中包含两个表：

  1. 员工表，包括员工ID、员工姓名、部门名称、当前级别、入职日期、离职日期（空表示在职）。
  2. 工资表，包括员工ID、发薪日期、工资，每个月有一条发薪记录。

要求 Agent 能够自动回答下列问题：

  1. 平均每个员工在公司在职多久？
  2. 公司每个部门有多少在职员工？
  3. 哪个部门的员工平均级别最高？
  4. 每个部门今年和去年各新入职了多少人？
  5. 从前年3月到去年5月，A部门的平均工资是多少？
  6. 去年A部门和B部门的平均工资哪个高？
  7. 今年每个级别的员工平均工资分别是多少？
  8. 入职时间一年内、一年到两年、两年到三年的员工最近一个月的平均工资是多少？
  9. 从去年到今年涨薪幅度最大的10位员工是谁？
  10. 有没有出现过拖欠员工工资的情况，也就是某个月员工在职但是没有发薪？

狼人杀 Agent

实验目的

狼人杀是一个经典的 LARP（Live Action Role-Playing）游戏，考验玩家的推理能力、欺骗技巧和社交策略。本实验旨在构建一个支持真人与 AI 混战的狼人杀系统，重点考察 Agent 在信息不对称环境下的逻辑推理、伪装欺骗和多方博弈能力。

实验内容描述

本课题的主要开发工作分为两个独立的部分：

  1. 狼人杀对战平台（Game Platform）：
    这是一个标准的 Web 应用，不包含任何 LLM 逻辑。你需要开发独立的后端服务（Game Server）和前端 Web 界面。后端负责维护游戏状态机（发牌、状态流转、结算），前端提供图形化界面供真人玩家参与游戏（查看身份、输入文本发言、点击投票）。

  2. 狼人杀 Agent（AI Player）：
    这是本实验的核心。你需要构建能够调用平台 API 参与游戏的 AI Agent。每个 Agent 扮演一个游戏角色，具备独立的观察、推理和决策能力。

实验架构设计

1. 游戏状态管理：平台后端维护中心化的游戏状态，包括玩家存活状态、当前阶段、历史事件等。

2. 信息权限控制：平台应严格控制信息流。Agent 通过 API 获取当前游戏状态时，只能获得其角色视角应知的信息（例如：狼人能看到狼队友，预言家能看到验人结果，村民只能看到公开信息）。

3. 交互机制：

  • 发言：真人玩家通过 Web 界面输入文字；Agent 生成文本发言并通过 API 发送。
  • 投票：真人玩家在界面点击投票；Agent 根据推理结果调用 API 投票。

4. Agent 的推理与策略：每个 Agent 的智能体现在其推理和决策能力上。以下是几个关键的设计要点：

狼人的伪装策略：狼人 Agent 的提示词中应该包含常见的狼人话术和策略，例如：”你应该像一个普通村民一样发言，表达对某些玩家的怀疑，但不要过于激进以免引起注意。如果有预言家跳出来并验你是狼人，你可以反咬对方是悍跳的假预言家。在投票时，尽量跟票（投大多数人投的目标），避免成为异类。”

预言家的身份证明：当有多个玩家声称自己是预言家时（真预言家和悍跳的狼人），真预言家需要通过逻辑证明自己。提示词可以指导：”如果有人悍跳预言家，你需要对比你和对方的验人信息，指出对方信息中的矛盾或不合理之处。例如，如果对方验的某个玩家在后续行为中明显不符合其声称的身份，这就是破绽。你还可以请求女巫或猎人配合验证你的真实性。”

村民的逻辑推理：村民 Agent 需要具备基本的狼人杀推理技巧，提示词可以包含：”分析每个玩家的发言是否自洽，注意那些急于带节奏、模糊身份、频繁改变立场的玩家。关注投票行为——狼人往往会集中投票给对他们威胁最大的好人。如果某个声称预言家的人验人信息与后续死亡情况不匹配，很可能是悍跳的狼人。不要随机怀疑，你的每个推理都应该基于具体的事实和逻辑。”

验收标准：

  • 设置一个 6-8 人的游戏局（1 名真人玩家 + 5-7 个 AI Agent）
  • 配置角色：2 只狼人、1 个预言家、1 个女巫、其余为村民，真人玩家随机分配角色
  • 游戏能够正常进行至少 3 个完整的回合（夜晚-白天-投票循环）
  • AI Agent 的发言和行为符合其角色身份和游戏策略
  • 狼人 Agent 能够有效隐藏身份
  • 预言家 Agent 能够在合适的时机跳出并公布验人信息
  • 村民 Agent 的推理不是随机的，而是基于发言和行为的逻辑分析
  • 游戏结束时能够正确判断胜负

难度：中等

个人照片搜索引擎

实验目的

构建一个基于多模态 embedding 和 Vision LLM 的个人照片搜索引擎，验证跨模态检索技术在实际应用场景中的有效性，以及 Vision LLM 在图像理解和自然语言描述生成方面的能力。

实验内容描述

本实验分为索引阶段和查询阶段两个部分。

索引阶段（离线处理）：

  1. 照片扫描：遍历用户指定的文件夹，识别所有图片文件
  2. 图像描述生成：对每张照片调用 Vision LLM API，生成自然语言描述
  3. 嵌入向量生成：使用嵌入模型为每张照片的描述文本生成嵌入向量
  4. 索引构建：将照片路径、描述文本、嵌入向量存储到向量数据库中

查询阶段（在线交互）：

  1. 用户输入：接收用户的自然语言查询，如”去年夏天在海边的照片”、”我和朋友的合影”、”圣诞节的装饰”
  2. 查询嵌入：将用户查询转换为嵌入向量
  3. 相似度检索：在向量数据库中执行相似度搜索（如余弦相似度、点积），检索 Top-K 个最匹配的照片
  4. 结果展示：以网格或列表形式展示检索到的照片，每张照片附带其自动生成的描述和相似度分数

期望验收结果

  • 成功索引至少 100 张个人照片，生成的描述准确反映照片内容
  • 支持多样化的自然语言查询，包括：
    • 场景查询（如”山上的照片”、”城市夜景”）
    • 人物查询（如”有人物的照片”、”集体合影”）
    • 活动查询（如”聚餐”、”运动”、”旅行”）
    • 时间查询（结合元数据，如”去年的照片”、”冬天的照片”）
    • 情感查询（如”欢乐的场景”、”宁静的风景”）

智能视频剪辑

背景知识

Render-Critique 机制：这是一种质量保证范式，特别适用于生成视觉内容（如视频、PPT、图像）的场景。其核心思想是：Agent 生成代码或配置后，无法直接判断最终渲染效果是否符合预期，必须通过实际渲染并使用 Vision LLM 检查视觉输出。工作流程包括：Editor Agent 生成代码 → 渲染执行 → Critic Agent 使用 Vision LLM 分析渲染结果 → 提出改进建议 → Editor Agent 调整代码 → 重新渲染，如此迭代直到质量达标。

这种机制解决了代码生成与视觉效果之间的”语义鸿沟”——即使代码语法正确且逻辑合理，最终的视觉呈现仍可能存在问题（如视频剪辑起始点不准确、PPT 字体过小、图像元素重叠等）。只有通过实际渲染并以视觉方式检查，才能发现这类问题。

实验内容描述

实验目标

验证 Agent 通过生成 Blender Python API 代码实现视频编辑的能力，评估基于视觉反馈的 Render-Critique 机制在多媒体内容处理质量控制中的作用。

核心挑战

理解用户的自然语言编辑需求并将其转化为精确的 API 调用序列，处理多种编辑操作（剪辑、合并、添加字幕、音轨混合、视觉效果）的代码实现，确保生成的 Blender Python 脚本语法正确且能正确执行。关键在于：Editor Agent 编写代码后无法直接判断视频效果是否符合预期，必须通过实际渲染并利用 Vision LLM 检查关键帧画面。

技术方案

用户提供一段运动或旅行视频（如包含冲浪、徒步、滑雪等场景的原始素材），以自然语言描述剪辑需求，例如”把冲浪部分剪出来”、”提取前10分钟的徒步片段并加入背景音乐”、”剪辑出滑雪跳跃的精彩瞬间，添加慢动作效果”。

Editor Agent 通过调用一个专门的视频分析 Sub-Agent 来识别场景，采用两步定位策略：

第一步，粗粒度定位：主 Agent 调用视频分析 Sub-Agent，传入参数：视频文件路径、时间范围、截图间隔（每10秒）、以及要回答的问题（”视频中哪些时间段出现了冲浪场景?”）。Sub-Agent 是一个简单的基于工作流的 agent，执行固定流程：先使用 ffmpeg 工具按指定间隔截取关键帧，然后将所有关键帧连同问题一起输入 Vision LLM，获得场景识别结果。Sub-Agent 将结果返回给主 Agent （如”冲浪场景出现在第40秒到第110秒之间”）。

第二步，精细粒度定位：主 Agent 再次调用视频分析 Sub-Agent，这次传入更窄的时间范围（30秒到40秒）、更密集的截图间隔（每秒）、以及更精确的问题（”冲浪者站上冲浪板的准确时间是?”）。Sub-Agent 同样执行截图-分析流程，返回精确的时间点（如”冲浪开始：第38秒”）。

这种先粗后细的两步定位既保证了效率（避免对整个视频进行密集采样），又确保了精度（在目标区域内精确找到边界）。通过将视频分析封装为 Sub-Agent，主 Agent 可以避免大量截图占用上下文，导致主 Agent 的上下文快速耗尽。完成场景定位后，主 Agent 生成调用 Blender Python API 的脚本实现剪辑操作。

引入 Render-Critique 机制：Critic Agent 执行脚本生成快速预览（而非完整渲染），抽取关键帧画面，使用 Vision LLM 验证剪辑是否准确提取了目标内容，检查视觉效果并提出改进建议（如”裁剪起始点过晚，冲浪已经开始了”）。Editor 调整脚本并重新生成预览，快速迭代直到剪辑效果达标，最后才执行完整的高质量渲染输出最终视频。

验收标准

Agent 能准确识别视频中的不同场景（如冲浪、徒步、滑雪等活动区域），根据自然语言指令正确生成剪辑脚本。生成的视频片段包含用户指定的内容，起始和结束点位置准确（误差不超过3秒）。如果指令包含特效要求（如慢动作、转场、字幕），生成的视频应正确应用这些效果。Render-Critique 机制能检测到明显的剪辑错误（如遗漏关键内容、包含无关片段）并触发修正。最终输出的视频文件格式正确，可正常播放，画质符合预期。

期望验收结果

  • 演示粗粒度和精细粒度两步定位策略，展示系统如何先定位场景大致范围，再精确找到边界时间点
  • 验证 Render-Critique 机制的有效性：展示初始剪辑的问题（如起始点偏差）、Critic Agent 的反馈，以及 Editor Agent 根据反馈调整后的改进效果
  • 对比使用和不使用 Render-Critique 机制的剪辑质量差异，证明视觉反馈对提升最终输出质量的关键作用
  • 记录整个迭代过程，包括每轮预览、发现的问题、做出的调整，直到达到可接受的质量标准

PPT 生成 Agent

实验目的

PPT 创作往往耗时费力。一个典型的学术报告 PPT 可能包含数十页幻灯片，每一页都需要精心设计布局、提炼要点、选配图表。传统的 PPT 制作工具虽然功能强大，但对 AI Agent 而言却是一个挑战——这些图形界面驱动的工具需要复杂的鼠标操作、拖拽定位、样式调整，难以通过程序化的方式精确控制。

背景知识

Proposer-Reviewer 范式：这是一种多 Agent 协作模式，通过分工实现质量提升。Proposer（提议者）负责生成初始方案，Reviewer（审查者）负责评估方案质量并提出改进建议。这种分工带来两个核心优势：一是专业化——Proposer 专注于创造性生成，Reviewer 专注于批判性评估，各司其职;二是上下文隔离——Reviewer 只需分析当前版本，避免在单一上下文中累积所有历史版本导致的上下文膨胀问题。

在 PPT 生成场景中，Editor Agent 扮演 Proposer 角色，Critic Agent 扮演 Reviewer 角色。Critic 通过渲染 PPT 为图片并使用 Vision LLM 进行多维度评估（内容密度、可读性、布局合理性、视觉美感），生成结构化的改进建议。Editor 根据建议调整代码，形成迭代循环。

Slidev 框架：Slidev 是一个专为开发者设计的演示文稿工具，用 Markdown 和 HTML 定义内容，用主题和 CSS 控制样式。这种设计将 PPT 创作转化为代码生成问题，非常适合 Agent 操作——Agent 只需生成 Markdown/HTML 代码，无需理解复杂的 GUI 软件。

实验内容描述

对于 Agent 而言，如果将 PPT 的创作问题重新框定为一个代码生成问题，就能极大简化其复杂度。现代的 PPT 框架（如 Slidev）采用了一种优雅的设计哲学：用 Markdown 和 HTML 来定义演示内容。Slidev 是一个专为开发者设计的演示文稿工具，它将幻灯片的内容与样式分离——内容用简洁的 Markdown 语法编写，样式通过主题和 CSS 控制，交互和动画可以用 Vue 组件实现。

这意味着，创建一页幻灯片只需要编写一段简洁的标记语言——用 Markdown 表达文字内容和结构，用 HTML 嵌入图片和自定义元素，框架会自动处理渲染、布局、动画等细节。对于掌握了代码生成能力的 Agent，这种模式极其友好：它不需要理解复杂的 GUI 软件，只需要理解 Markdown 和 HTML 这两种结构化语言，这正是大语言模型最擅长的任务之一。

然而，仅仅能生成 PPT 代码还不够。Editor Agent 编写完代码后，并不知道代码的实际渲染效果——内容是否太挤、文字是否溢出边界、图片尺寸是否合适、字体大小是否合理、颜色搭配是否协调，这些视觉问题只有通过实际渲染才能发现。这与人类创作 PPT 的过程完全一致：我们通过 GUI 看到操作的实际效果，然后根据视觉反馈进一步调整内容。一个优秀的演示文稿不仅需要内容正确，更需要视觉呈现清晰、专业。

因此，质量保证需要引入 Render-Critique 机制，这正是 Proposer-Reviewer 范式在 PPT 生成场景中的具体应用。系统被设计为两个协作的 Agent：Editor Agent（Proposer） 和 Critic Agent（Reviewer）。Editor Agent 负责根据用户提供的内容（如论文摘要、会议讲稿、产品介绍）生成 Slidev 格式的幻灯片代码。它需要理解内容的逻辑结构，将其分解为合理的页面，为每一页选择合适的布局模式，用 Markdown 语法组织文字，用 HTML 嵌入必要的媒体元素。

Critic Agent 则扮演着视觉质量审查者的角色。它的工作流程包含几个关键步骤。首先是渲染执行：Critic 使用 Slidev 的命令行工具，将 Editor 生成的代码渲染为 PDF 或一系列 PNG 图片。每一页幻灯片都被转换为高分辨率的图像，这些图像成为视觉分析的输入。其次是多维度评估：Critic 利用 Vision LLM 的多模态理解能力，对每一页渲染结果进行分析。评估维度包括：内容密度（页面是否过于拥挤或过于空旷）、可读性（字体大小是否合适，文字与背景对比度是否足够）、布局合理性（元素排列是否整齐，重要信息是否突出）、视觉美感（颜色搭配是否协调，整体风格是否统一）。

基于这些分析，Critic 生成结构化的改进建议。这些建议不是模糊的”这页不好看”，而是具体的、可执行的指导，例如：”第 3 页：内容过多，建议将下半部分的三个要点拆分到新的一页”、”第 7 页：代码块字体过小，建议减少代码行数或增大字体到 14pt”、”第 12 页：图片与文字重叠，建议将图片移动到右侧，文字左对齐”。这些建议被格式化为结构化的反馈对象，包含页码、问题类型、严重程度、具体建议等字段。

Editor Agent 接收到 Critic 的反馈后，并非盲目地应用所有建议，而是理解每条建议的意图，在保持内容完整性的前提下进行调整。如果建议是”内容过多需要拆分”，Editor 需要识别自然的分割点，确保拆分后的逻辑依然连贯；如果建议是”字体过小”，Editor 需要在增大字体的同时调整布局，避免文字溢出。修改完成后，新版本的代码再次提交给 Critic 进行审查，形成迭代循环。

这个循环可能经历多轮，直到 Critic 认为所有页面的视觉效果都达到了可接受的标准，或者达到预设的最大迭代次数（例如 5 轮）。每一轮迭代都使得 PPT 的质量逐步提升，从初始的”功能可用”向”视觉专业”演进。

需要注意的是，也可以使用单个 Agent 反复执行 render-修改循环，每次都将渲染图片输入 Vision LLM 进行自我审查。但这种方式容易导致 context 快速膨胀——一个完整的 PPT 包含数十页，每页图片占用大量 token（一张 1080p 的截图可能消耗数千个 token），多轮迭代会使上下文迅速超出限制。更严重的是，当上下文中累积了大量历史版本的渲染图片时，模型可能会混淆不同版本之间的差异，甚至产生幻觉认为某个已经修复的问题仍然存在。

Editor-Critic 分工模式通过让 Critic 聚焦于当前版本的评审，避免了在单一上下文中累积所有历史渲染图片的问题。每次迭代时，Critic 只需要分析最新版本的渲染结果，它的上下文相对干净。Editor 的上下文中虽然会累积 Critic 的历史反馈，但这些反馈是结构化的文本，比图片占用的 token 少得多，且更易于模型理解和推理。这种设计在保证审查质量的同时，实现了更高效的上下文利用。

实验要求：

  1. 准备一个内容丰富的输入（如一篇学术论文的扩展摘要，包含背景、方法、实验、结论等部分，约 2000-3000 字）
  2. 实现 Editor Agent，使其能够将输入内容转换为 Slidev 格式的幻灯片，包含标题页、目录页、内容页、结论页等
  3. 实现 Critic Agent，使其能够调用 Slidev 的渲染工具，将代码转换为图片，并使用 Vision LLM 进行视觉质量评估
  4. 实现迭代循环机制，让 Editor 根据 Critic 的反馈进行修改，直到质量达标或达到最大迭代次数
  5. 记录每轮迭代的反馈内容和修改动作，展示 PPT 质量的逐步提升过程
  6. 对比单 Agent 自我审查模式和双 Agent 协作模式在上下文消耗、生成质量、迭代效率等方面的差异

期望验收结果

  • 展示完整的迭代过程：记录每轮 Critic Agent 的视觉评估反馈（如”第3页内容过多”、”第7页字体过小”）和 Editor Agent 的相应调整
  • 对比单 Agent 自我审查模式和双 Agent 协作模式：分析两种方式在上下文消耗、生成质量、迭代效率等方面的差异，验证分工模式在避免上下文膨胀方面的优势
  • 演示至少3轮的 Render-Critique 循环，展示 PPT 质量如何从初始的”功能可用”逐步提升到”视觉专业”
  • 最终生成的 PPT 应符合专业标准：内容密度适中、布局合理、字体清晰、视觉协调

书籍翻译 Agent

实验目的

书籍翻译是一个典型的需要多 Agent 协作的复杂任务。一本技术书籍的翻译不仅仅是将文字从一种语言转换为另一种语言，更需要确保专业术语的一致性、语境的准确性、以及整体阅读的流畅性。这种任务的复杂性使其成为验证管理者模式有效性的理想场景。

背景知识

管理者模式（Manager Pattern）：这是一种多 Agent 协作架构，用于解决复杂长任务的上下文管理问题。核心思想是任务分解和责任分离——由一个 Manager Agent 协调多个专门的 Sub-Agent，每个 Sub-Agent 只负责整体任务的一个子阶段或子模块。

这种模式的关键优势：

  1. 上下文隔离——每个 Sub-Agent 在独立的、简化的上下文中工作，只关注自己的子任务，避免被无关信息干扰
  2. 可管理性——Manager 的上下文主要包含任务规划、执行状态和结果索引，而非所有子任务的完整内容，保持在可控范围内
  3. 可扩展性——可以并行执行多个 Sub-Agent，或根据需要动态创建和销毁 Agent 实例

在书籍翻译场景中，Manager Agent 协调三类专门 Agent：Glossary Agent（提取术语并建立对照表）、Translation Agent（翻译单一章节）、Proofreading Agent（全文一致性检查）。各 Agent 通过共享文件系统交换数据，而非在上下文中传递完整内容。

单一 Agent 方案的问题：如果用单一 Agent 处理整本书的翻译，其上下文会不断累积全书内容、术语表、翻译过程思考等，很容易超出上下文窗口。更严重的是，当上下文极长时，Agent 容易”迷失”——可能忘记全书统一的术语约定，或产生幻觉。

实验内容描述

本实验通过书籍翻译任务验证管理者模式在控制上下文膨胀和提升任务完成质量方面的有效性。

考虑翻译一本英文技术书籍到中文（例如 Nathan Lambert 的 RLHF Book）。这本书包含 10 个章节，每章讨论不同的主题——神经网络基础、卷积网络、循环网络、注意力机制等。在翻译过程中，有大量的专业术语会反复出现。某些术语的翻译可能有多种约定俗成的说法，需要在全书范围内做出统一选择。

一种直观的实现方式是使用单一 Agent 处理整个翻译流程。给这个 Agent 一个详尽的提示词，告诉它先浏览全书提取术语，建立对照表，然后逐章翻译，最后审校一致性。提供必要的工具，如文件读写、术语库管理、文本对比等。然后让 Agent 自主执行整个流程。

然而，这种单一 Agent 方案面临严重的上下文管理问题。随着 Agent 处理每一章的内容，它的上下文会不断累积：全书的术语表、已翻译的章节、当前正在处理的段落、翻译过程中的思考、工具调用的结果。一个包含 10 章的技术书籍，每章可能有 5000-10000 字，全部内容很容易超过模型的上下文窗口。更严重的是，当上下文变得极长时，Agent 容易”迷失”——它可能忘记全书统一的术语约定，在翻译第 8 章时使用了与第 2 章不一致的术语；或者在审校阶段重复检查同一个问题，浪费计算资源；甚至可能因为注意力分散而产生幻觉，”记起”一个实际并不存在的术语翻译规则。

管理者模式通过任务分解和责任分离优雅地解决了这些问题。在这种架构下，系统被设计为一个 Manager Agent 协调多个专门 Agent 的协作。

Glossary Agent（术语对照表 Agent）负责第一阶段的工作：它接收全书的内容（或各章标题和关键段落的摘要），识别出所有重复出现的专业术语，为每个术语生成中文翻译建议。这个过程可能需要 Glossary Agent 搜索专业词典、参考已有的翻译规范、或者分析术语的构词方式来推断合理的译法。Glossary Agent 的输出是一个结构化的术语对照表，格式可能是 JSON 或 CSV，包含英文术语、中文翻译、词性、使用语境等信息。完成这个任务后，Glossary Agent 的工作就结束了，它可以被销毁以释放资源。术语对照表被写入共享文件系统，供后续 Agent 使用。

Translation Agent（章节翻译 Agent）负责实际的翻译工作。Manager 会为每一章创建一个独立的 Translation Agent 实例（或者复用同一个 Agent，每次传递不同的章节内容）。Translation Agent 接收三个输入：当前章节的英文内容（从文件系统读取）、Glossary Agent 生成的术语对照表（从文件系统读取）、以及翻译指南（如目标读者水平、语言风格偏好，通过工具参数传递）。它的任务是将章节内容翻译为流畅的中文，在遇到对照表中的术语时严格使用规定的译法，对于表中没有的新术语则基于上下文推断翻译并标记出来供后续审查。Translation Agent 只关注单一章节，它的上下文不会被其他章节的内容所污染，这使得翻译过程更加专注和准确。翻译完成后，译文被写入共享文件系统（如 chapter1_zh.md），新发现的术语被追加到一个待审查列表中。

Manager 可以并行地为多个章节启动 Translation Agent（如果资源允许），或者串行地逐章处理。无论哪种方式，每个 Translation Agent 都在自己独立的上下文中工作，互不干扰。

Proofreading Agent（全文审校 Agent）在所有章节翻译完成后登场。它接收所有章节的译文（从文件系统读取）和术语对照表，执行一致性检查：扫描全文，验证所有专业术语的翻译是否符合对照表的规定，识别可能的不一致（如同一概念在不同章节使用了不同译法），检查译文的流畅性和可读性（如是否有生硬的直译、前后文是否连贯）。Proofreading Agent 生成一份审校报告，列出发现的所有问题及其位置，并将报告写入文件系统。

Manager 根据这份报告，可能会将特定章节发回给 Translation Agent 进行修订（通过读取报告中的问题描述，提取需要修改的章节，再次调用 Translation Agent 并传递修改要求），或者直接应用小的修正（如果问题很简单，Manager 可以自己修改文件）。

在这个架构中，Manager Agent 扮演着项目经理的角色。它的上下文主要包含：任务的整体描述和目标、各个阶段的执行计划、每个专门 Agent 的调用记录和返回结果、当前的任务进度和状态。Manager 不需要保存每个章节的完整翻译内容，这些内容存储在文件系统中，Manager 只需要维护文件的索引（如 {"chapter1"： "chapter1_zh.md"， "chapter2"： "chapter2_zh.md"， ...}）。这种设计使得 Manager 的上下文保持在可管理的范围内，即使处理一本大型书籍也不会溢出。

更重要的是，专门 Agent 的使用实现了上下文的隔离。Glossary Agent 只看到术语提取所需的内容，Translation Agent 只看到当前章节和术语表，Proofreading Agent 虽然需要访问全文但只关注一致性检查。每个 Agent 都在一个简化的、专注的上下文中工作，这不仅提高了效率，也降低了出错的可能性——Agent 不会因为信息过载而分散注意力。

实验要求：

  1. 选择一本较深的技术书籍作为翻译对象，例如 Nathan Lambert 的 RLHF Book
  2. 实现 Manager Agent，设计清晰的任务分解和 Agent 调度逻辑
  3. 实现 Glossary Agent，使其能够从全书中提取专业术语并生成对照表
  4. 实现 Translation Agent，使其能够根据术语表翻译单一章节，并标记新出现的术语
  5. 实现 Proofreading Agent，使其能够检查全文的术语一致性和翻译质量
  6. 记录每个 Agent 的上下文消耗，验证管理者模式在控制上下文膨胀方面的有效性
  7. 对比单一 Agent 方案（如果可行的话）和管理者模式方案在翻译质量、执行效率、资源消耗等方面的差异

同时从多个网站搜集信息的 Agent

实验目的

本实验探索多 Agent 并行执行在信息收集场景中的应用。

背景知识

多 Agent 并行执行：当任务可以分解为多个相互独立的子任务时，通过并行执行多个 Agent 可以大幅提升效率。关键在于：每个 Agent 在独立的执行环境（进程/线程）中运行，拥有独立的资源（如浏览器会话），互不阻塞。这与管理者模式的串行调度不同——并行模式追求的是时间上的同时执行。

Orchestration Agent（编排 Agent）：负责协调多个并行 Agent 的执行，其核心职责包括：动态启动 Agent 实例并分配任务;实时监控各 Agent 的执行状态;处理 Agent 间的消息传递和协调;在满足条件时触发级联终止（如一个 Agent 成功即终止所有其他 Agent）;聚合所有 Agent 的结果并向用户报告。

级联终止机制：这是并行执行中的关键技术挑战。当某个 Agent 完成目标后，需要立即通知所有其他仍在运行的 Agent 停止执行，避免资源浪费。这要求 Agent 能够在执行过程中响应外部信号，并优雅地清理资源（如关闭浏览器、断开连接），不能留下悬挂进程。同时还需处理竞态条件——如多个 Agent 几乎同时成功的情况。

实验内容描述

本实验通过多网站信息搜集任务验证并行执行相比串行执行在性能上的优势，以及 Orchestration Agent 在协调和控制方面的能力。

问题描述：
给定一所大学的多个学院网站（例如计算机学院、数学学院、物理学院、化学学院、生物学院等，共 10 个学院），要求在这些学院的教师名录页面中查找一个指定名字的老师（如”张伟”），找到后返回该老师所在的学院、职位、研究方向等信息。

这个任务如果串行执行——逐个访问每个学院网站、解析页面、搜索名字——可能需要很长时间（假设每个网站平均需要 30 秒处理，10 个网站就是 5 分钟）。而且，如果目标老师在第一个学院就找到了，后续 9 个学院的访问就完全是浪费。

实验目标：
构建一个 Orchestration Agent，使其能够：

  1. 动态地启动多个并行的 Computer Use Agent，每个负责一个学院网站
  2. 实时监控所有 Agent 的执行状态
  3. 当任何一个 Agent 找到目标信息时，立即通知其他 Agent 停止执行
  4. 聚合成功 Agent 的结果，向用户报告

核心挑战：

1. 并行 Agent 的动态启动

Orchestration Agent 需要根据任务需求（10 个学院网站）动态创建 10 个 Computer Use Agent 实例。每个实例应该是独立的进程或线程，拥有独立的浏览器会话，能够同时执行而不互相阻塞。启动 Agent 时，Orchestration Agent 需要为每个实例传递：目标网站 URL、要搜索的教师姓名、任务标识符（用于后续的消息路由）。

2. 任务进度的实时监控

每个 Computer Use Agent 在执行过程中应该定期发送状态更新消息，如：”正在加载网站”、”正在解析教师名录”、”未找到目标，任务完成”、”找到匹配，详细信息如下：…”。Orchestration Agent 通过消息总线接收这些更新，维护一个任务状态表，实时了解哪些 Agent 还在运行、哪些已完成、哪些遇到了错误。

3. 成功后的级联终止

当某个 Agent（假设是负责计算机学院的 Agent）成功找到目标教师时，它发送一个 {"type"： "target_found"， "agent_id"： "agent_3"， "data"： {...}} 消息到总线。Orchestration Agent 接收到这个消息后，立即执行以下操作：

  • 向所有其他仍在运行的 Agent 发送 {"type"： "terminate"， "reason"： "target_found_by_agent_3"} 消息
  • 每个接收到终止消息的 Agent 应该优雅地停止当前操作，清理资源（关闭浏览器会话），并发送 {"type"： "terminated"} 确认消息
  • Orchestration Agent 等待所有 Agent 的终止确认（或超时），然后汇总结果

这个级联终止机制是实验的关键难点。它要求：

  • Agent 能够在执行过程中随时响应外部的终止信号（类似第四章讨论的中断机制）
  • 终止必须是优雅的，不能留下悬挂的进程或未关闭的资源
  • Orchestration Agent 必须处理可能的竞态条件——如果两个 Agent 几乎同时找到目标怎么办？

4. 失败与超时处理

可能存在以下异常情况：

  • 某个学院网站无法访问（网络错误、服务器宕机）
  • 某个网站的结构与预期不符，Agent 无法正确解析
  • 所有 Agent 都搜索完毕，但没有一个找到目标教师

Orchestration Agent 需要为这些情况设计处理策略：

  • 为每个 Agent 设置超时限制，超时后视为失败
  • 当某个 Agent 报告错误时，记录错误但不影响其他 Agent 的执行
  • 当所有 Agent 都完成（无论成功或失败）后，汇总结果：如果有 Agent 成功，返回成功信息；如果全部失败，向用户报告”未找到目标教师”及失败原因统计

实验要求：

  1. 实现能够动态启动多个并行 Agent 的 Orchestration Agent
  2. 实现 Computer Use Agent（或 Web Scraping Agent），使其能够访问大学学院网站，解析教师名录，搜索目标姓名
  3. 实现消息总线或消息传递机制，支持 Orchestration Agent 与多个 Sub-Agent 之间的双向通信
  4. 实现成功后的级联终止机制，确保一旦找到目标，所有其他 Agent 能够快速停止
  5. 处理各种异常情况（网站访问失败、解析错误、全部未找到）
  6. 记录和对比并行执行与串行执行的时间差异，验证并行化带来的性能提升

难度：困难

更懂你的用户记忆

实验目的

将 Agentic RAG 的多轮迭代检索能力应用于用户对话历史，构建一个可检索的长期记忆系统。验证这种方法在用户记忆评估框架三个层次（基础回忆、多会话检索、主动服务）上的能力和局限性。

背景知识

用户记忆评估框架的三个层次：

第一层次是基础回忆，要求 Agent 能够准确回忆单次会话中用户提供的具体信息，如”我的支票账户号码是多少?”这类简单的事实查询。

第二层次是多会话检索，要求 Agent 能够跨越多个不同时间的会话整合信息。这包括两个子挑战：一是整合分散信息（如用户在不同会话中分别谈论了两辆车，Agent 需要综合了解用户的所有车辆）;二是处理事实冲突（如多个家庭成员在不同会话中先后修改同一指令，Agent 需要判断哪个才是最终有效的）。

第三层次是主动服务，要求 Agent 能够主动发现不同信息间的隐藏关联并提供预警建议。例如，用户在几个月前的会话中提到护照即将过期，最近又预订了国际机票，Agent 应该主动关联这两个事实并提醒用户续签护照。

Advanced JSON Cards 记忆模式：这是一种结构化的用户记忆表示方法，将用户的核心事实以 JSON 格式存储。每个 Card 包含多个字段：content（事实内容，如”护照将于2026年2月18日过期”）、backstory（信息来源和上下文）、person（相关人员）、relationship（人员关系）等元数据。这些 JSON Cards 通常作为常驻上下文固定在 Agent 的提示词中，使 Agent 始终掌握用户的核心信息概览。

实验内容描述

核心思想是将用户的完整对话历史视为一个知识库。在索引阶段，系统将对话历史按固定窗口（如每 20 轮对话）分块并索引；在应用阶段，Agent 通过 search_user_memory 工具主动检索这些”记忆”。

上下文感知检索的实现：为每个对话块生成包含时间、人物、意图等背景信息的前缀摘要。例如，孤立的”好的，就订这个吧”变成”[上下文：用户正在确认从上海到西雅图的 500 美元单程机票] 好的，就订这个吧”。这种上下文前缀解决了传统文档分块方法的根本缺陷——将紧密关联的上下文分离导致的语义信息损失。

上下文增强在处理事实冲突时展现决定性优势。在测试用例中，妻子、丈夫、妻子先后三次修改同一转账指令，上下文前缀（”妻子设立初始电汇”、”丈夫修改电汇”、”妻子在丈夫修改后再次修改”）为判断最终有效指令提供了关键线索。

双层记忆架构：实验进一步探索将 Advanced JSON Cards 与上下文感知 RAG 结合的双层架构。Advanced JSON Cards 作为常驻上下文存储结构化核心事实（如”护照将于 2026 年 2 月过期”、”已预订1月15日飞往东京的机票”），而上下文感知 RAG 提供对非结构化对话细节的按需检索。

在第三层次测试中，用户询问”为我一月的东京之行，还有什么要准备的吗？”时，Agent 的工作流程为：首先审视常驻上下文中的 JSON Cards，从中掌握”东京之行（1月15日）”和”护照信息（2月18日过期）”两个核心事实；通过对比发现机票日期与护照过期日期接近，识别出潜在风险；使用 RAG 检索相关对话细节进行确认，找到当初讨论机票和护照的原始片段作为”证据”；最终主动提醒用户”您的护照将在旅行后一个月过期，强烈建议立即加急办理续签”。

期望验收结果

  • 上下文增强后，Agent 能够正确处理事实冲突场景，判断出最终有效的指令。
  • 双层记忆架构成功运行：JSON Cards 提供核心事实概览，RAG 提供对话细节按需检索。
  • 在第三层次测试中，Agent 能够主动发现不同信息间的隐藏关联并提供预警建议。
  • 理解结构化知识管理与非结构化信息检索协同工作的价值。

边打电话边用电脑的 Agent

实验目的

在现实世界的许多场景中，任务的完成需要多个能力同时并行运作，而不是串行执行。想象一个人类助理在帮老板处理紧急事务：他可能一边打电话与客户沟通，一边在电脑上查找相关文档，同时还要记录对话要点。这种”一心多用”的能力对单个 Agent 来说极具挑战性——如果让一个 Agent 既要处理实时的语音对话，又要操作电脑界面，它必然会在两个任务之间反复切换，导致对话出现停顿，或者电脑操作被打断，用户体验极差。

实验内容描述

多 Agent 并行执行的核心思想是：让不同的 Agent 各自专注于实时性要求高的任务，通过异步消息传递进行协调，从而实现真正的并行处理。在”边打电话边用电脑”这个典型场景中，我们需要两个独立的 Agent 同时运行：一个负责电话对话，一个负责电脑操作。这两个 Agent 不是简单的任务分配，而是针对不同交互模态的专门优化——电话 Agent 需要低延迟的语音识别和合成，电脑 Agent 需要强大的视觉理解和操作规划能力。

问题描述：
想象一个场景：AI Agent 需要帮助用户完成一个在线预订任务，例如填写一个复杂的航班预订表单。在这个过程中，Agent 需要一边操作网页，一边通过电话向用户询问并确认个人信息（如姓名、证件号、航班偏好等）。

这个任务对单个 Agent 构成了巨大挑战。因为电话沟通和电脑操作都要求较高的实时性。如果一个 Agent 在集中精力”看”屏幕并点击按钮时，它就无法同时听取用户的讲话并作出回应，反之亦然。这会导致通话卡顿或操作中断，体验很差。

本实验的目标是构建一个由两个 Agent 协同工作的多智能体系统，来解决这个”一心二用”的难题。一个 Agent 负责打电话，另一个 Agent 负责操作电脑，它们之间实时通信，高效地完成任务。

核心挑战与要求：

1. 双 Agent 架构

你需要构建两个独立的 Agent：

Phone Agent：负责与用户进行语音通话。需要基于 ASR（语音识别）+ LLM（大语言模型）+ TTS（语音合成）的 API 来实现。它应该能够理解用户的自然语言回答，将回答中的关键信息提取出来，通过消息框架发送给 Computer Agent。同时，它需要能够接收来自 Computer Agent 的消息（如需要什么信息、遇到了什么问题），并据此生成合适的话术向用户询问或告知。

Computer Agent：负责操作电脑上的浏览器，完成网页表单填写等任务。建议基于现有的浏览器操作框架，例如 Anthropic Computer Use、browser-use 或其他类似框架。它应该能够理解网页的结构，识别需要填写的表单字段，根据收到的信息执行填写操作，并在遇到问题时向 Phone Agent 寻求帮助。

2. Agent 间协同通信

两个 Agent 必须能够高效地双向通信。通信机制的实现可以有两种方式：

方式一（简单方案）：通过工具调用实现点对点通信。Phone Agent 的工具集包含 send_message_to_computer_agent（message），Computer Agent 的工具集包含 send_message_to_phone_agent（message）。当一个 Agent 调用这个工具时，消息会作为一个新的输入事件被加入到目标 Agent 的轨迹中。

方式二（完善方案）：实现一个轻量级的消息总线和 Orchestration Agent。消息总线负责消息的路由和分发，Orchestration Agent 负责任务的整体协调和状态监控。所有 Agent 都通过统一的消息格式进行通信，消息包含发送者、接收者、类型、内容等字段。

3. 并行工作与实时性

关键在于两个 Agent 必须能并行工作。在 Computer Agent 寻找页面元素或输入文本时，Phone Agent 必须保持在线，能够与用户正常对话，例如可以说”好的，正在为您填写姓名… 请问您的证件号码是？”。这要求：

两个 Agent 运行在独立的执行线程或进程中，各自维护独立的 ReAct 循环。Phone Agent 的执行循环包括：接收用户语音 → ASR 转录 → LLM 理解和生成回应 → TTS 合成 → 播放给用户 → 检查是否有来自 Computer Agent 的消息。Computer Agent 的执行循环包括：截取屏幕 → Vision LLM 理解页面 → 规划操作 → 执行操作（点击、输入等）→ 检查是否有来自 Phone Agent 的消息。

两个 Agent 的输入需要包含来自对方的信息。Phone Agent 的 LLM 输入上下文不仅包含用户的语音转录和对话历史，还应包含一个特殊标记的字段，内容是 Computer Agent 发来的最新消息（如 [FROM_COMPUTER_AGENT] 找不到"下一步"按钮，可能需要用户确认是否要继续）。同样，Computer Agent 的多模态模型输入不仅包含浏览器截图和操作历史，也应包含 Phone Agent 的消息（如 [FROM_PHONE_AGENT] 用户说姓名是张三，证件号是 123456）。

期望验收结果

  • 演示双 Agent 真正并行工作：Phone Agent 在与用户对话的同时，Computer Agent 在操作浏览器填写表单，两者互不阻塞
  • 展示 Agent 间的实时通信：Computer Agent 遇到问题时向 Phone Agent 发送消息请求信息，Phone Agent 收到消息后向用户询问并将答案回传
  • 对比单 Agent 串行执行模式（先打完电话收集完所有信息，再操作电脑）和双 Agent 并行模式在总耗时上的差异，验证并行化带来的效率提升
  • 记录完整的任务执行日志，包括两个 Agent 各自的 ReAct 循环、消息传递的时间点和内容、任务完成的总时间
  • 验证实时性：Phone Agent 在 Computer Agent 工作期间能够保持流畅对话，无明显停顿或等待

越用越熟练的电脑操作 Agent

实验目的

本实验将外部化学习方法应用于电脑操作场景，构建一个能够从经验中学习、越用越熟练的浏览器自动化 Agent。这种从”思考执行”到”直接回放”的转变，是外部化学习实现能力固化的典型体现——将重复性流程从模型的临时推理中”解放”出来，转化为独立的、可精确执行的外部程序。

背景知识

外部化学习的核心思想：传统的 Agent 依赖上下文学习（in-context learning）或参数记忆（parametric memory）——通过在提示词中提供示例，或依赖模型训练时学到的知识。但这两种方式都存在局限：上下文学习受限于上下文窗口大小，参数记忆无法动态更新。外部化学习则采用了完全不同的策略——将 Agent 的经验和技能存储在外部的、可编辑的知识库中。

Voyager 的”探索-沉淀-复用”范式：Voyager 是一个在 Minecraft 游戏中自主探索的 Agent 系统，它展示了外部化学习的强大潜力。其工作流程包含三个关键阶段：

  1. 探索阶段：Agent 通过与环境交互完成任务，如”建造一个工作台”。在这个过程中，它通过多轮推理决定执行哪些游戏操作，并最终成功完成任务。

  2. 沉淀阶段：一旦任务成功，Voyager 会将整个操作序列”蒸馏”为一段可执行的 JavaScript 代码，命名为一个技能函数（如 craftWorkbench（））。这段代码包含了完成该任务的所有必要步骤，并存储到外部的技能库中。关键在于，这段代码是独立的、可直接执行的，不需要模型重新推理。

  3. 复用阶段：当面对新任务时（如”建造一个木剑，需要先有工作台”），Voyager 会检索技能库，发现已经有 craftWorkbench（） 这个技能。它可以直接调用这个函数，而不是重新推理如何建造工作台。这种复用大幅提高了效率和稳定性。

这种范式的核心价值在于”能力固化”——将一次性的、临时的推理过程转化为永久的、可复用的能力单元。

实验内容描述

本实验将上述外部化学习方法应用于浏览器自动化场景。当前的电脑操作 Agent 每次执行任务时都需要通过多模态大模型进行完整的视觉推理，即使之前成功完成过完全相同的任务也必须重新推理。本实验的目标是让 Agent 能够从经验中学习，将成功的网页操作流程”沉淀”为可回放的工作流，在后续执行相似任务时直接复用。

问题背景：当前的电脑操作 Agent 每次执行任务（如网页浏览、表单填写）时，都需要通过多模态大模型进行完整的视觉推理——观察屏幕截图、决定点击位置、输入文本。即使之前成功完成过完全相同的任务，Agent 也无法利用这些经验，必须重新推理。这种方式存在三个问题：效率低下（每次都需要多次昂贵的 LLM 调用）、不稳定（LLM 的随机性导致操作路径不一致）、成本高昂（大量视觉理解调用）。本质上，这是因为 Agent 依赖上下文学习或参数记忆，而没有将成功经验外部化为可复用的工具。

实验目标：构建一个具有学习能力的电脑操作 Agent，使其能够：

  • 在首次执行任务时，通过多模态大模型的推理完成操作，同时捕获稳定的操作流程
  • 将成功的操作流程以基于稳定选择器（如 XPath、CSS Selector）的形式存储到知识库
  • 在后续执行相似任务时，能够识别任务的相似性，从知识库中检索匹配的工作流
  • 直接回放工作流中的操作步骤，无需再次调用大模型逐步推理，从而实现快速、稳定的执行

技术方案：实验基于 browser-use 框架进行二次开发。Browser-use 提供了与 Playwright 集成的浏览器自动化能力，并且在与多模态 LLM 交互时，为页面上的可交互元素分配临时编号。当 LLM 输出操作指令（如 click（13）、type（7， "[email protected]"））后，browser-use 会创建 DOMHistoryElement 对象记录该元素的详细信息，包括 XPath、CSS Selector、元素类型、文本内容等。实验的核心任务是利用这些信息实现学习和回放机制。

学习阶段的实现（对应”探索-沉淀”阶段）：当 Agent 首次执行任务时，系统处于”学习模式”。在首次完成网页操作时捕获完整的操作流程：

  • Agent 通过多模态大模型的观察-思考-行动循环完成任务。每次 LLM 决定执行一个操作（点击、输入等），系统从 browser-use 的内部状态中提取被操作元素的稳定标识符（优先使用 XPath，因为它对页面结构微小变化更具鲁棒性）。
  • 将每一步操作记录为一个结构化的步骤，包含：操作类型（click、type、select 等）、目标元素的 XPath、相关参数（如输入的文本内容）、执行后的状态验证信息（如页面 URL 变化、特定元素出现）。这将动作序列转化为可回放的结构化数据。
  • 当任务成功完成后，系统提示 LLM 为这个任务生成一个语义标签和描述。语义标签是任务意图的抽象表达（如”发送电子邮件”），描述则包含任务的关键要素（如”收件人字段、主题字段、内容字段、发送按钮”）。这些信息将用于未来的任务匹配。
  • 将步骤序列、语义标签、描述一起存储到知识库中，形成一个”工作流”（workflow）条目。这个工作流就是外部化的、可复用的操作能力。

应用阶段的实现（对应”检索-复用”阶段）：当 Agent 接收到新任务时，系统首先尝试从知识库中检索匹配的工作流。匹配机制结合语义相似度（比较新任务描述与存储的工作流描述的嵌入向量相似度）和关键要素检查（新任务是否涉及相似的操作对象和目标）。如果找到匹配度超过阈值的工作流，Agent 进入”回放模式”——这正是外部化学习带来的效率飞跃：

  • 按照工作流中记录的步骤顺序，逐步执行操作。由于现代网页是动态加载的，直接连续执行会导致失败（目标元素可能尚未加载）。因此，在执行每一步之前，必须使用 Playwright 的等待机制（如 page.locator（xpath）.wait_for（state='visible'， timeout=15000））确保目标元素已加载且可交互。
  • 对于包含参数的操作（如输入文本），工作流中存储的是参数化的模板（如”在收件人字段输入 {{email}}“）。回放时，需要从当前任务的指令中提取实际参数值（如”[email protected]“），并填充到模板中。这个参数提取可以通过简单的 LLM 调用完成，但不需要完整的视觉推理，从而大幅降低成本。
  • 如果工作流回放过程中某一步失败（如找不到目标元素、等待超时），说明网页结构可能发生了变化，存储的工作流已过时。此时，Agent 应该记录这次失败，将该工作流标记为”可能过时”，并退回到学习模式，重新通过 LLM 推理来完成任务，同时生成新的工作流替换旧的。这体现了持续迭代改进的机制。

验收场景与指标：选择一个具体的网页操作任务进行验收，例如在 Gmail 网页版中发送邮件。

首次执行（学习阶段）：

  • 任务指令：”给 [email protected] 发送一封邮件，主题是’测试邮件’，内容是’这是一封测试邮件，用于验证 Agent 学习功能’”
  • 观察与记录：演示 Agent 如何通过多模态 LLM 观察 Gmail 界面，识别”撰写”按钮并点击，识别收件人输入框并输入邮箱地址，识别主题和内容输入框并填写，识别”发送”按钮并点击。记录整个过程的操作步骤、耗时、LLM 调用次数。
  • 工作流生成：展示生成的工作流，包含每一步的 XPath、操作类型、参数。

重复执行（应用阶段）：

  • 任务指令：”给 [email protected] 发送邮件，主题是’后续测试’，内容是’这是第二封测试邮件’”
  • 工作流匹配：演示系统如何识别新任务与存储的”发送邮件”工作流匹配，提取新的参数值（收件人、主题、内容）。
  • 快速回放：展示 Agent 直接执行工作流中的步骤，无需 LLM 进行视觉推理。每一步只需要等待元素加载、执行操作，整个过程应显著快于首次执行。
  • 性能对比：记录第二次执行的耗时、LLM 调用次数，与首次执行对比。

知识更新：

  • 在重复执行的应用阶段，模拟网页改版场景（如手动修改测试页面的 HTML 结构，使某个按钮的 XPath 发生变化），验证 Agent 能否检测到工作流失效，并回退到学习阶段。
  • 演示 Agent 如何在检测到失效后，重新学习新的工作流，更新知识库，并在下次执行时使用新工作流。

能创造 Agent 的 Agent

实验目的

构建一个具备元编程能力的 Coding Agent，使其能够根据用户需求自动创建新的 Agent 系统。核心挑战是确保生成的 Agent 遵循最佳实践：标准的上下文管理和工具调用格式、最新的 SOTA 模型和 API、以及 Agent 开发的最佳实践。

背景知识

元编程的挑战：让 Agent 直接生成 Agent 代码面临一个根本性问题——大语言模型的训练数据通常滞后于最新技术。如果让 Coding Agent 从零开始编写 Agent 代码，它很可能会使用过时的 API 格式、废弃的模型名称，或者不符合当前最佳实践的架构模式。例如，它可能生成已经废弃的 OpenAI Function Calling 格式，而不是最新的 Tool Calling 协议。

基于范例的代码生成：解决这个问题的有效方法是为 Coding Agent 提供一个高质量的、遵循当前最佳实践的 Agent 实现作为参考范例。这个范例代码应该包含：正确的消息格式（如最新的 OpenAI Chat Completions API 格式）、标准的工具调用协议、推荐的模型选择（如 gpt-5、claude-4）、良好的上下文管理模式（如正确处理多轮对话历史）、错误处理和日志记录等工程实践。

实验内容描述

本实验的技术方案是为 Coding Agent 提供一个高质量的 Agent 实现作为参考范例。当接到创建新 Agent 的需求时，Agent 首先复制这个范例代码作为基础框架，然后基于用户的具体需求进行针对性修改，而不是从零开始生成。这种”复制-修改”的模式确保了生成代码的质量下限。

实验流程：

  1. 准备阶段：创建一个高质量的 Agent 范例代码，包含完整的项目结构（依赖管理、配置文件、主程序、工具定义等）
  2. 输入需求：向 Coding Agent 输入创建新 Agent 的需求（如”创建一个能够搜索网络并总结信息的 Agent”）
  3. 观察生成过程：记录 Agent 如何理解需求、如何基于范例代码进行修改（如添加 web_search 工具、调整提示词、修改主循环逻辑）
  4. 质量检查：检查生成代码的质量——消息格式是否标准、工具调用协议是否正确、模型选择是否合适、代码结构是否清晰
  5. 功能测试：实际运行生成的 Agent，测试其能否成功完成指定任务

对比实验：比较”基于范例修改”和”从零生成”两种模式：

  • 代码质量：检查 API 格式、模型名称、错误处理等方面的正确性
  • 开发效率：记录从需求输入到可运行 Agent 的时间
  • 成功率：统计生成的 Agent 能否一次性通过测试，或需要多少次调试修复

期望验收结果

  • Coding Agent 能够成功创建新的 Agent，生成的代码可以运行并完成基本任务。
  • 生成的 Agent 代码采用标准的消息格式和工具调用协议。
  • 生成的 Agent 使用当前推荐的模型和 API，而非过时技术栈。
  • 生成的 Agent 能够正确管理多轮对话的上下文和状态。
  • 基于范例修改的模式比从零生成的模式代码质量更高、开发效率更高。

Comments

▲