从支持到自主化，人与 Agents 共存的 AI 社会

导读 随着人工智能技术的飞速发展，Agent 作为实现智能决策与自主交互的核心载体，正逐步占据越来越重要的地位。然而，如何构建具备高度灵活性和扩展性的智能体系统，并探索其规模化应用的潜在规律，已成为当前 AI 领域的重要研究方向。本次分享将重点依据 CAMEL 框架在这一领域的创新实践与开源生态建设，围绕 Agent 技术的演进路径、多智能体协同机制及其规模化扩展展开探讨。

今天的介绍会围绕下面六点展开：

1. Agent 溯源

2. Agent 从专用到通用（From Specific to General）

3. Agent 的下一代扩展法则（The Next Scaling Laws）

4. 多智能体协同的优势（More Agents better than one？）

5. Agent 演进（Evolution）

6. Q&A

分享嘉宾｜范文栋 Eigent AI Founding Engineer & Tech Lead

编辑整理｜孟立诗

内容校对｜郭慧敏

出品社区｜DataFun

01

Agent 溯源

Agent 并非新兴的技术概念。早在 1986 年出版的《Society of Mind》一书中，Agent 被定义为不具备思想、仅能执行简单任务的进程。通过将这些简单的 Agent 组合到一起，就能够产生真正的智慧。

在书中有一句话这样表述：“What magical trick makes us intelligent？The trick is that there is no trick. The power of intelligence stems from our vast diversity，not from any single，perfect principle”（即，人类智慧是通过群体的智慧、大量的多样性而产生的，并不是通过单一的、完美的准则形成的。）

这一观点与人类社会的发展历程是非常契合的，无论是从原始社会到现代社会，人类始终通过群体的分工协作，逐步的实现进化与发展。

在这之后，我们所探讨的 Agent 主要聚焦在强化学习（Agent in Reinforcement Learning，RL）领域，即强化学习中的智能体。在此领域中，一个具备学习和决策能力的实体被定义为 Agent。Agent 通过其自身的行为（action）和当前环境（environment）进行交互，环境会根据 Agent 的行为向其反馈新的状态及奖励（reward）给到 Agent。通过这种迭代过程， 实现了 Agent 不断的进化和学习。

下面是一些知名的基于 RL（强化学习）的应用案例：

• Go Game（AlphaGo）：阿尔法狗成功打败了围棋世界冠军李世石。
• Automated Vehicles（自动驾驶）：自动驾驶技术能够在无需人类干预的情况下，实现平稳、安全的行驶。
• Game Agent（游戏智能体）：部分游戏智能体的能力非强强，甚至在某些方面超越了人类玩家的水平。

这些应用均是基于 RL 技术，但是 RL 有一定的局限性。具体而言，RL 的环境和行为是被定义好的。例如，AlphaGo 在围棋领域表现出色，但是若将其应用于象棋，则无法胜任该任务。

02

From Specific to General

我们有没有办法构建一种更加通用的 Agent 呢？随着 2023 年生成式 AI 领域的兴起，为我们指出了一个新的探索方向。

1. Language Models as Agents

在 2023 年，OpenAI 的安全系统负责人 LilianWeng 撰写了一篇博客，其中定义了 Agent 的若干技术模块：

• Tools（工具模块）：进行互联网信息检索、计算等功能。
• Memory（记忆模块）：Agent 本身有长期短期的记忆。
• Planning（计划模块）：反思、critics、thoughts 等能力。

Agent 的显著特点在于，它以自然语言作为输入和输出，其状态（state）与行为（action）均可通过自然语言进行描述。这赋予了 Agent 强大的泛化能力，以自然语言作为主要媒介。

CAMEL 框架中是如何定义 Agent：

• 系统消息定义：在 CAMEL 中，可以定义一个 system_message，这与使用大模型定义 message 的方法一致。
• 模型支持：CAMEL 框架本身可以支持很多种不同的模型，为用户提供了灵活性。
• 记忆模块：在 CAMEL 中的 memory 模块也支持长期的记忆和短期的记忆。对于短期记忆，能够管理 manage 记忆的上下文窗口。

在 CAMEL 框架中比较有意思的机制：while loop Step。该机制允许 Agent 进行多次 API 请求，从而可以应对复杂的任务。

例如可以先让 Agent 进行互联网检索，然后再根据检索到的信息调用生成文档的工具创建报告。在此过程中，Agent 可能会多次调用大模型，若不采用这种循环机制，则需要进行多次请求（multiple request）。而采用循环机制后，面对复杂任务，Agent 能够通过单一步骤直接完成。

2. Agents

前面已提到 Agent 中的 Planning 模块，同样地，在 CAMEL 框架中，也对应有两个与之相关的模块实现类似的功能，即 Task Decomposition 模块和 Self-Reflection 模块。

Task Decomposition 模块：该模块中定义了一系列具体的任务相关 Agent。这些 Agent 包括但不限于：用于任务规划的 Agent、负责任务生成的 Agent，以及执行任务优先级排序的 Agent 等。

Self-Reflection 模块：该模块包含一个 critique Agent，它能够基于另一 Agent 所提供的信息，生成批判性内容，并将相关反馈（feedback）回传至信息提供方。通过这一机制，可帮助前一个 Agent 实现迭代优化。

03

The Next Scaling Laws

上面我们介绍了如何去构建一个 Agent，那么当我们把这些能够自定义化、有非常强灵活性的 Agent 组合在一起，就能够形成 Agent 社区，进而构建群体智能体系统。

1. The next scaling laws？

在我们社区中，有个假说 next scaling laws for Agent，其核心对应关系如下：

• 在模型中的 Parameters（参数）：对应 Agent 的数量；
• 在模型中的 Data（数据）：对应 Agent 的本身的 Environments（环境）；
• 在模型中的 Training（训练）：对应 Agent 领域的 Memory 和 Interaction。

2. Multi-Agent Framework

近年，大家也会看到非常多的多智能体框架的兴起，出现了很多具有创新性的研究成果。其中，CAMEL 框架在 2023 年 3 月底推出，并成为世界上第一个开源多智能体框架。在此之后，该领域又相继涌现出 MetaGPT、CrewAI 等一批优秀框架，持续推动着多智能体系统技术的演进。

3. CAMEL

在 CAMEL 框架中，我们早期实现了一个 Role-Playing 角色扮演机制的多智能体系统，它要求用户提供一个基础性任务构想（idea），系统通过任务分解与智能体协作完成具体目标。以下通过典型案例说明其运行逻辑：

用户需求：开发一个交易软件的任务。

实现方案：

用户提出“开发一个交易软件”的构想后，基于 CAMEL 框架将该任务分配至 Task Agent 进行具体化处理。经分解后的子任务将同步至 AI User 与 AI Assistant 两个智能体角色，分步执行：

• 任务初始化阶段：AI User 根据任务发送指令，让 AI Assistant 智能体安装 Python 包；
• 协作执行阶段：AI Assistant 基于需求自动生成代码实现方案，并与 AI User 进行多轮迭代交互；
• 任务闭环结果：通过 AI User 和 AI Assistant 智能体之间的交流迭代，最终完成符合用户需求的交易软件开发这个任务。

用户需求：开发一个寻宝游戏开发的任务。

实现方案：

基于 CAMEL 框架 Role-Playing 模块实现协作交互，开发流程分为三阶段：

• 环境初始化：AI User 发起初始指令（如安装 Python 包），AI Assistant 执行任务；
• 代码生成：AI User 后续指令触发代码生成，AI Assistant 通过多轮交互逐步生成、优化代码直至任务达成；
• 任务闭环：任务完成后 AI User 发送"CAMEL_TASK_DONE"指令，系统收集代码执行以完成游戏开发。

2024 年，CAMEL 推出了第二个多智能体系统——Workforce，该系统是更加强大的动态系统。

Workforce 系统具备以下核心机制：

• 接入机制
  支持任意数量 Agent 以工作节点形式接入系统，完成配置的 Agent 可作为独立工作单元加入 Workforce 架构。
• 嵌套机制
  允许将已编排的智能体系统或 Workforce 实例作为独立工作节点嵌入系统，支持将处理特定任务的智能体系统层级化嵌套，通过多层架构扩展实现复杂任务场景的处理能力。
• 动态机制
  系统具备自动化任务拆解能力，由协调 Agent（Coordinator Agent）统一管理。当任务执行受阻时，可自动触发任务二次拆解并动态生成新 Agent 以继续任务执行，实现系统的自适应扩展。

4. More Agents Between than one？

面对同一个任务，多智能系统效果一定会比单个的智能体的效果好么？

CAMEL 曾在早期发表的 Paper 中做过一些相应实验，当时使用的模型是 gpt-3.5-turbo。该实验是测试了在 200 多种不同的任务，在 70%+ 的场景之下，使用 Multi-Agent 的方式是要比使用单一模型的效果更好。

5. OWL：Optimized Workforce Learning

在今年 3 月 CAMEL 团队推出了新的开源框架叫 OWL，基于 CAMEL 团队在多智能体系统领域已经做了两年，有非常多的积累，所以才能够在短时间内快速的实现了 Menus 复现版本的 OWL。OWL 框架首版在 GAIA 综合评分达到 58.18 分，是当时开源的所有的 Agent 框架里面最高的分数。

在 OWL 系统中用的还是上面提到的 Role-Playing 机制 ，即 CAMEL 中的 AI User Agent 和 Assistant Agent，在 Assistant 的背后由一些额外的 Agents 支持。

例如：浏览器交互智能体（Web Agent）后面会有一些其他 Agent，以及 Browser 工具、多模态工具、文档处理工具等辅助 WebAgent 智能体把任务完成的更好。

• Browser 工具：帮助我们做浏览器执行的工具；
• 多模态工具：帮助我们读取视频、音频、图片等资料的工具；
• 文档处理工具：帮助我们写文档，生成 Markdown、生成 PDF 等文档文件的工具；

浏览器交互智能体（Web Agent）可协同其他 Agent 及辅助工具优化任务执行，相关工具包括：

• Browser 工具：用于执行浏览器操作；
• 多模态工具：支持处理视频、音频、图片等多媒体资料；
• 文档处理工具：用于编写文档及生成 Markdown、PDF 等格式文件。

案例：基于 OWL 框架的自动化任务执行流程

任务描述：

用户通过自然语言指令，要求智能体打开浏览器，搜索 CAMEL-AI，查看当前 CAMEL AI 的框架的数据。然后再写出 Python 代码，最后需要生成统计图，并将生成的图片以及代码都保存在本地。

系统执行流程：

• Agent 启动后自主完成浏览器初始化，自动输入检索关键词"CAMEL AI"并访问首个 GitHub 搜索结果链接。系统通过全屏截图结合多模态分析模型，解析项目描述、仓库结构及开发者活跃度等核心信息。
• Agent 自动生成包含 GitHub 项目星标数、提交频率等数据的统计图表，代码执行过程中采用角色扮演机制：Assistant Agent 负责内容监控与推理，User Agent 提供指令交互。当前 Workforce 在 OWL 系统中 GAIA 评估分数已达 69.7 分，超越 OpenAI Deepresearch。
• 任务执行后，终端输出 Agent 自主生成的统计图像文件及对应源代码，验证任务完成度。

6. CRAB：Cross-environment Agent Benchmark For Multimodal Language Model Agents

其实在更早之前 CAMEL 团队也做过一些多模态的尝试，推出了叫做 CRAB 的 benchmark，这是世界上第一个跨端的 benchmark，能够把电脑、手机打通做一些 Agent 的交互。

7. CRAB Agents and Environments

案例：基于智能体的 Slack 消息处理流程

任务描述：

Agent 自动完成整个过程，首先打开 Slack APP（Slack 是一款专为团队协作设计的云端沟通与协作平台），然后导航到某一个频道，将该频道的最后两条信息进行总结，总结后以短信的方式发送给手机中第一个联系人。

系统执行流程：

CRAB Agent 很快速的按照上面的流程执行，打开手机上对应 APP，寻找第一个联系人，将 Agent 整理后的信息发送给了此人。

我们目前还在做一个事情，把 OWL 和 Crab 这两个框架融合在一起，这样的话我们就能够让 Agent 去做更加复杂的、跨平台的多模态任务。

8. OASIS：Simulate Social Media with 1 million Agents

在此之前，CAMEL 开展了一项名为 OASIS 的研究项目。在该项目中，团队实施了一场大规模社会模拟实验，成功支持 100 万个 Agent 参与模拟，以重现 X 平台和 Reddit 平台上用户的行为模式。通过运用如此大规模的 Agent 进行模拟研究，探究是否会存在从众效应？

04

Evolution

1. Agents with GraphRAG

前面主要是介绍在 CAMEL 中如何构建单个智能体（Agent）以及多个智能体。我们也希望自己的 Agent 能变得更加强大，那么要推动这个系统的进化和迭代，有哪些可行的方法呢？

第一种方法就是大家比较熟知的 RAG。RAG 本质在于通过外挂额外信息，为大模型提供训练过程中未获取到的信息源，以辅助模型学习。这是一种极为有效的方法，此前在非常多的业界场景中使用的一种工程化手段。

在 CAMEL 系统中，支持基础的 RAG Pipeline，而 CAMEL 所特有的 Graph RAG 实际上是一个具备特征设置的系统。该系统包含上下两个 Pipeline：

• 在上面图中上方的 Pipeline 依托 CAMEL 中的一个专门用于知识图谱（Knowledge Graph）信息抽取的 Agent。该 Agent 负责抽取实体信息与关系信息，并将这些信息存储至图数据库内。
• 在上面图中下方的 Pipeline 单纯的基于 embedding。具体而言，将相关内容进行 Embed 处理，转化为向量形式，之后将其存储至图数据库中。

当用户提出相应问题时，系统会借助这两种处理流程进行信息检索，最终将检索结果进行合并，作为上下文信息提供给模型，以辅助模型更准确地回答问题。

案例需求：

在 2024 年奥运会期间，土耳其有一位射手（Turkish shooter）表现极为出色。当时，我们戏称其为“杀手”，因为他在赛场上表现出潇洒自如的状态，并取得了非常好的分数。我们团队对这位射手极为关注，希望 Agent 自动在互联网上检索有关此人的信息，并生成一份 Markdown 格式的报告，同时构建相应的知识图谱。

实现方案：

基于 CAMEL 模型，我们让 Agent 调用多种不同类型的工具，包括搜索工具、RAG 工具、Retrieve 工具以及 Knowledge Graph building 工具。然后执行上述任务。

实现过程：

• 为任务设定目标，即针对土耳其射手（Turkish shooter）开展一项全面的研究（comprehensive study）。明确任务后，由 AI User 给出相应的指令。
• AI Assistant 开始执行任务。与常规操作不同的是，AI Assistant 会调用多种工具。具体来说，它先借助 search_duckduckgo 搜索引擎检索有关土耳其射手 Turkish shooter 的信息，获取到对应的标题、网页链接等内容。检索完成后，Agent 会对整体信息进行总结与梳理，并将其作为解决方案。
• 在获取网页标题与链接后，进一步深入这些链接中读取其中更为详细的信息。然后，AI User 发出指令，要求从这些 URL 链接列表中召回相关信息，并调用名为 retrieve_information_from_urls 的工具，将所有链接输入该工具。通过更深层次的信息检索，获取更为具体的信息。
• 基于上面检索到的具体信息后，Agent 撰写关于该土耳其这名射手的报告文件。报告内容涵盖该射手概况、所取得的成就以及获得的奖牌等信息。
• Agent 着手构建知识库。为构建基础图层，调用 knowledge_graph_builder 工具。CAMEL 系统对工具的支持具有高度灵活性，用户既可使用 CAMEL 内置的工具，也可在企业应用或个人项目中，将功能封装成为函数，作为工具提供给 Agent。通过知识提取，Agent 从相关信息中抽取实体节点（entity node）以及关系三元组（relationship triple）等信息，进而构建出知识图谱。

运行结果：

上述流程整体运行完毕后，Agent 生成了一份 Markdown 格式的报告文件。同时，通过自动抽取信息，构建了图数据库。该图数据库的数据源不仅涵盖与土耳其射手本人相关的信息，如其参与过的奥运会赛事等，还包含他在 2024 年奥运会上的相关信息，其中还包括他其他竞争对手的信息、金牌得主以及铜牌得主的具体情况。

这一过程充分体现了在使用 GraphRAG 时，其对关系型信息的强大拓展能力。

2. Agentic Data Generation

另一个演进方向聚焦于数据（data）。众所周知，整体的多智能体系统是基于一个 Agent 为基础构建。一个 Agent 背后其实是依托于模型，模型在系统中处于核心地位，模型的运行又离不开数据支撑。基于此，我们可以利用 Agent 系统生成合成数据，以此迭代提升整个框架的能力。

在 CAMEL 框架中，已支持多种合成数据生成 Pipeline。以上图中的示例为例，我们借助 CAMEL 框架中的 Role - Playing 功能生成一些 SFT Data，可运用信息抓取工具，如 Firecrawl，从互联网上抓取相关信息，进而生成对应的数据。随后，使用 Unsloth 等工具对模型进行训练（Training）与微调（Fine - tune）模型。

DeepSeek - R1 作为一款开源且推理能力强大的模型，我们能够从该模型中进行数据蒸馏。此前，CAMEL 也开展了相关研究工作。在 CAMEL 的自优化数据蒸馏流程（Self - improving Data Distillation Pipeline）中，可迭代提升蒸馏所得数据的质量。在完成数据蒸馏并抽取部分数据后，会借助 Evaluation 模块完成对数据进行评估。评估方式具有多样性，既可以使用 Reward model（奖励模型），也可借助另一个 Agent，还可采用 rule based（基于规则）的方式对信息的整体质量进行把控。随后，将评估反馈提供给此前生成数据的智能体，促使其迭代优化，提升自身生成的推理能力。

我们曾开展数学数据蒸馏工作，并将相关数学数据集（dataset）上传至 Hugging Face 平台。若大家感兴趣，可直接在该平台使用 GSM8K 等数据。

接下来，介绍当时在 CAMEL 中生成数据的格式。

在 CAMEL 框架中，所呈现的 Role-Playing 形式，使用 AI User 和 AI Assistant 的之间自主自动进行多轮对话，实际上，这种形式天然地构成了对话数据（Conversation Data）。在早期阶段，我们曾就针对 10 种不同的 task，构建了 50 种不同的 User roles，并据此发布了诸多数据集。

团队对部分数据开展了一些验证工作。在 CAMEL 先前发表的论文中，针对基于 GPT 生成的模型以及 Llama 模型进行了微调。

上面图中是我们使用数学领域的数据进行微调的验证：

• 微调前，可以看到模型一和模型二，它在数学上面的表现能力是 8:7（上图中红框标出的部分），是非常相近的。
• 微调后，模型二在数学方面的能力显著超越模型一，比分变为 16:3。

CAMEL 框架的数据集此前已被非常多的不同模型厂商使用。例如，在 Huggingface 平台上，有 180 余种不同模型使用 CAMEL 的数据集进行模型微调。需说明的是，上述数据为半年前的统计结果，如今采用该数据集的模型数量可能更多。此外，一些知名模型也使用了 CAMEL 的数据集，如 Huggingface 自身便运用了该数据集。还有 MosaicML，这是一家被 Databricks 收购的公司，其当时推出的模型同样采用了 CAMEL 的数据集。

最近，我们开展了一项重要工作，推出了名为“Loong”的项目。这个项目旨在能够通过 Verifier 生成更多合成数据，并能够通过可验证的方式加入 RL 机制，进而迭代提升数据质量，最终增强大型模型及 Agent 的能力。

在 Loong 项目中，我们设置了生成器（Generator），它能够从 Seed Datasets 中获取数据，生成合成的问题与答案。

同时，这个项目配备了 Verifier，能够去验证生成数据的质量是否可靠。在完成验证后，Agent 可在这些已验证的数据集上进行训练。

我们诚挚欢迎对合成数据生成以及 Agent 构建感兴趣的小伙伴加入，共同参与此研究项目。

3. The Next Scaling Laws？

总结而言， CAMEL 所定义的 Agent Scaling Laws 内容如下：

• 模型参数与智能体数量：如前文所述，涉及模型 Parameter 数量以及 Agent 数量，其中 CAMEL 本身作为 Agent 框架的基底，发挥着关键作用。此外，还有 OASIS 项目，它能够支持 100 万个 Agent 同时进行社会模拟。
• 模型数据与智能体环境：与模型 Data 相对应的是 Agent Environment，在这方面，我们拥有 CRAB 项目，它支持本地电脑、手机等设备的跨端操作。同时，Loong 项目致力于构建 Agent 领域的 Environment。另外，OWL 项目具备浏览器执行功能，能够写入本地文件，实现更高级的工具调用。
• 模型训练与智能体进化：在模型训练层面，对应于 Agent Evolution，存在非常多的合成数据生成 pipeline 以及 RAG 数据 Pipeline。

05

CAMEL-AI

上面呈现的是完整的 System Stack。实际上，CAMEL 在 Agent 领域已积累了超过两年的经验与成果，涵盖了众多模块。从 Agent 本身的构建到 Agent Societies 的搭建、合成数据的生成、模型的支持、工具的调用、模型上下文记忆与存储、数据库，以及代码执行的解释器（Interpreters）、数据加载器（Data Loaders）、数据读取模块，还有 AI 方面的 Retrievers、Run Time 等，这些模块在 CAMEL 中均得到了支持。

目前，CAMEL 社区已有 115 位贡献者参与其中并作出贡献。在此，我们诚挚欢迎对 Agent 领域，尤其是对构建下一代 Market Agent 系统感兴趣的小伙伴加入！

06

Q&A

Q1：CAMEL 框架是主要侧重于通过智能体（Agent）技术实现数据的生成与合成，还是其数据合成的核心目的是为了优化智能体训练过程，从而让基础模型更好地适配实际的智能体应用场景？

A1：在 CAMEL 两方面均有所涉及。首先，我们使用 Agent 生成数据，会使用一些与 Agent 相关的组件，例如 tool call 等，以生成更优质的数据。其次，生成这些数据，核心目的在于赋能模型，提升模型能力最终是为了提升整个框架的能力。

Q2：CAMEL 有没有针对 Agent 场景，在数据生成过程中会进行一些特殊处理？这些处理是为了 Agent，还是为了模型呢？

A2：在对模型进行微调时，我们通常会设定一些具体的针对性目标。通常来说，可能会引入某些特定领域的数据，或者使用某些特定领域的工具，正如提到的模型微调，我们确实开展了一些针对工具（tool）优化或相关改进的项目，希望模型本身能够更好地适配业务领域的 Tools。

Q3：我司专注 AI 智能体前端定制开发，多行业覆盖但存在边界认知模糊问题，导致客户期望过高（如元宇宙级设想）。当前办公、营销场景中，智能体在联动及多模态协同技术上存在局限，部分功能难以实现，需明确可落地与现阶段技术瓶颈的边界，如何解决客户预期与实际落地的差距的问题？

A3：在面对用户需求时，用户可能对 Agent 的能力边界缺乏清晰认知，但作为开发人员，我们必须深入理解大型模型当前的局限性。众所周知，大型模型本身一定会有“幻觉”的问题，这是大模型本身的架构存在的不足。

• 在针对特定业务领域的场景，例如，若用户期望 Agent 完成财务精准计算任务，此类场景可能并不适宜。因为很难有效控制模型产生的“幻觉”，而一旦出现此类问题，可能会带来巨大损失。
• 在有些业务场景中，例如文案撰写等，业务本身对错误的容忍度较高。也就是说，即便出了一点问题，如使用表述方式 A 或 B，对最终结果影响不大。在这种情况下，便可以运用大型模型。

因此，开发人员必须充分了解大型模型的局限性，并结合具体业务场景，判断哪些业务环节适合采用大型模型实现自动化，哪些业务环节则必须使用基于规则（rule-based）的系统进行严格可控的实施。

Q4：在当前应用大爆发的市场背景下，CAMEL 公司在其中扮演着怎样的角色？例如，在算力、算法、数据等方面，部分前端客户若需要进行定制开发，以我司为例，通常会先协助客户构建其专属数据库，再选取合适的工具链与通用模型。在此情境下，CAMEL 社区的定位是什么？我们应如何与 CAMEL 开展合作？

A4：CAMEL 的定位是一个具备进化能力的底层框架，希望能够帮助用户更好地构建契合自身需求的 Agent。我们不会局限于特定垂直领域，而是致力于将该框架打造得更为通用，并集成一些前沿功能，以便用户能够进行迭代升级，结合自身业务构建出更强大、更贴合业务领域的智能体。这正是 CAMEL 目前的工作重点。因此，大家可以看到我们开展了一些合成数据生成相关工作，包括 Loong 项目等模拟研究，这些均是我们为提供底层支持所做的努力。

Q5：上面提到，在手机端或电脑端会涉及跨模态工具的调用。想了解一下，在 Agent 领域，CAMEL AI 是更侧重于 Agent，还是 Tools Call？另外，在 Tools Call 方面，除了 Tool 本身具备多模态处理能力外，我们的 Agent 在多模态应用上还能发挥哪些作用？

A5：在 Tool Call 的过程中本身并不依赖于多模态能力。仅当调用工具获取到图片、视频等数据，且需要对这些数据进行解析时，才需运用多模态能力。

Q6：在应用 RL 生成数据，或进行 Agent 训练数据生成的过程中，是否会特意生成一些图片类数据，以便后续进行更多微调？

A6：确实可以这样做，我们能够生成大量的合成多模态数据。不过，目前CAMEL 的重点并不在于多模态数据的生成，而是专注于文本数据。因为在当前阶段，多模态的大规模应用尚未到来。

Q7：Agent 会调用很多 Tool，如通过 Function Call 来调用 Tool。目前，在 MCP 方面是否有相关考虑？

A7：关于 MCP，CAMEL 已经支持其生态系统。我们可以将任意一个 MCP 服务接入 CAMEL，作为工具让 Agent 调用。这是我们在推出 OWL 之后所做的一项工作。此外，包括 CAMEL 本身的核心组件，如 Agent、Role-playing、Workforce 等模块，我们后续也将支持通过 MCP 的方式进行调用。

Q8：Agent 会生成一些用于RL的数据，这不是模型需要做的事情吗？这与 Agent 的数据有何关联？

A8：从底层来看，数据的生成确实依赖于模型。但如果只是单纯依赖模型，那么我们不能“左脚踩右脚一直踩上天”，无法实现持续优化。因此，必然需要一些外部介入，如 Verifier，我们会使用额外的验证模块来校验生成的数据是否正确。此外，在生成数据时，还可以调用工具，并结合 RAG 技术，获取外部的 knowledge base 等信息，以增加数据的广度。这些方法都是可行的。

Q9：因为 Agent 的概念非常广泛，没有明确的边界。我们也遇到了类似的问题，比如 Agent 和模型的数据。Agent 也会产生一些数据，在上面提到的“Agent 的数据”是指 Agent 平台上生成的 trace 链路数据，还是 Agent 应用反馈的数据？

A9：更多的是指 trace 数据，即 Agent 运行过程中生成的数据，包括自然语言信息等。当然，可能也会包括 Agent 运行过程中消耗的 token 等系统信息，但目前我们并不会特别关注这些。

Q10：合成数据生成的业务价值是什么？我主要从事应用层开发，对于大型模型而言，之前提到的 RAG 可以补充大型模型在特定领域的知识不足。而现在引入了合成数据生成技术，它对数据源有何要求？此外，合成后的数据与通过 RAG 提供给大型模型的上下文内容有何不同？

A10：我们对合成数据的质量要求非常高。在进行合成数据生成时，如果原始 Seed Datasets 质量不佳，无论采用何种生成方法，效果都会很差。那么，为什么我们要进行合成数据生成，而不是直接使用 RAG 呢？这实际上是两套不同的方案：RAG 更像是开卷考试，相当于把一本书交给一个人，让他根据书中的内容回答问题。而我们进行合成数据生成，主要是为了对模型进行微调（Finetune）和训练（Training），这是将知识嵌入模型内部的一种更为原生的方式，旨在提升模型性能或构建更为专业的模型。

以上就是本次分享的内容，谢谢大家。