你有没有想过，把两个AI放在同一个对话框里，让它们自己讨论一个问题，会发生什么？我最早以为，这跟让两个朋友聊天差不多——聊着聊着就跑题了。但有一篇来自KAIST等机构的论文 《Camel: Communicative Agents for "Mind" Exploration of Large Language Model Society》 真的做了这件事，而且让两个AI聊出了结果。这就是CAMEL项目。
CAMEL的核心不是让AI随便聊天，而是给它们套上“角色扮演”的壳：一个扮演用户，一个扮演助手，再配上精心设计的“初始提示”（Inception Prompt），让它们围绕一个明确任务自主对话，直到任务完成。
为什么需要一个Agent跟另一个Agent说话？
因为很多现实任务不是一句“给我写个方案”就能搞定的。它需要拆解、试错、反馈。比如“写一个Python程序，实现快速排序”，如果用一个AI，它可能写出来一个版本就完事了。但如果你想让它像一个团队一样，先设计、再实现、再测试，那你需要让AI扮演多个角色，互相给指令、互相提意见。
这就是CAMEL的出发点：让AI通过自然语言协作，而不是靠人去一条条地纠正。两个Agent一个出题、一个解题，有点像“结对编程”的翻版。
任务指定：聊之前先对齐目标
CAMEL很聪明的一点是，它不会拿一个模糊的任务直接开聊。它会先用一个“任务指定器”把“开发一个推荐系统”变成“开发一个基于协同过滤的电影推荐系统，使用Python中的surprise库”。这一步叫task specification。它在角色扮演之前完成，作用是让两个Agent在同一个频道上。
你可以把任务指定器理解成“导演”，它负责把一句笼统的话变成一个可演出的剧本。CAMEL论文里展示过，用few-shot prompt就能很好地完成这个转换。有了这个具体任务，后面的角色对话才不会散。
但两个AI聊天，最大的问题是失控
也许你会说：这还不简单，把两个ChatGPT接起来就行。但真让它们自由聊，你很快会发现：它们会互相吹捧（“你说得太对了！”），会重复同样的话，会逐渐偏离任务，甚至自己聊出一个宇宙。我在初次接触这个领域时，看过一些早期demo，两个模型聊着聊着就开始编故事了。
CAMEL的论文里明确提出了这个问题，并且给出了一个解决方案：Inception Prompting。说白了，就是给两个演员各自发一份“剧本”，规定好角色、任务、说话格式和结束条件。取名“Inception”，也有点像《盗梦空间》里植入一个想法——通过一段精心构造的提示，在模型心里“植入”一个行为模式。
Inception Prompting：给Agent发剧本
你可以把它理解为“初始情境提示”。它不是普通的system prompt，而是一段包含了角色身份、对方角色、任务目标、通信协议、终止条件的完整设定。比如，AI用户（user）的prompt是：你是一个AI用户，你的任务是向AI助手下达指令，要求它完成一项具体任务；AI助手的prompt则是：你是一个专业的AI助手，必须听从AI用户的指令，并给出可执行的方案。
为了让对话不跑偏，CAMEL还规定了一种通信格式：AI用户的消息以“Instruction:”开头，AI助手的消息以“Solution:”开头。这样，每一轮对话都有明确的“请求-响应”结构，而不是随意的聊天。
下面是一个简化版的inception prompt示例（来自CAMEL论文）：
user_role_prompt = f'''You are an AI user who will interact with an AI assistant.
Your task is to instruct the assistant to solve a task step by step.
If the assistant answers correctly, reply with "Task completed".
...'''注意这里的关键点：它明确告诉AI用户“你是一个用户”，而不是“你要给出答案”。这种角色分离让两个Agent之间的对话更有方向性。同样，AI助手的prompt也会告诉它“你是一个助手，你要认真执行指令”，并给出具体的输出格式。
两个Agent的对话是怎么运作的？
有了剧本之后，大致流程是这样的：
- AI用户先给AI助手发送第一条指令，描述需要完成的任务。
- AI助手根据指令，返回一个具体的解决方案（比如代码、文字）。
- AI用户检查这个解决方案，如果觉得不满意或需要补充，就继续发送新的指令。
- 循环往复，直到AI用户认为任务完成，发送一个结束标记。
在CAMEL的原始实现中，对话还会受到两个约束：最大轮数限制和结束条件。一旦达到最大轮数，或出现特定字符串（比如“<TASK_DONE>”），对话就会终止。这避免了两个AI无限聊下去。你可以在他们的GitHub上看到具体实现，代码很短，核心逻辑就是while循环。
这个框架好看，但真实效果如何？
我在看了CAMEL的项目主页后，发现它确实能在一些任务上得到有意义的输出。比如让AI用户扮演“股票分析师”，让AI助手扮演“Python程序员”，两个人通过对话生成一份分析代码。这种任务分解能力，是单个Agent很难具备的。CAMEL的作者还专门分析了对话的“多样性”和“可读性”，证明角色扮演让输出更丰富。
但别高兴太早。CAMEL也有明显的短板：因为每个Agent的上下文都是整个对话历史，所以对话越长，token消耗越大，成本高。而且，两个模型本质上还是同一个底模，观点多样性有限。一旦任务超过一定复杂度，对话就会陷入平庸的循环，产出类似“你说得对，我们再优化一下”的废话。
CAMEL跟现在的Agent框架有什么差距？
如果你后来接触过AutoGen、ChatDev或者LangGraph，你可能会觉得CAMEL有点“原始”。确实，它更像一个研究原型，而不是生产级框架。我整理了一张对比表：
| 框架 | 交互模式 | 状态管理 | 工具调用 | 适用场景 |
|---|---|---|---|---|
| CAMEL | 两个角色自由对话 | 无显式状态，全靠prompt | 无原生工具 | 研究、数据生成、任务模拟 |
| AutoGen | 可编程对话，支持多Agent | 有对话流程控制 | 支持函数调用 | 自动化工作流、人机协作 |
| ChatDev | 多Agent模拟软件公司 | 有阶段划分 | 主要通过消息 | 软件生成演示 |
| LangGraph | 图结构状态机 | 显式状态图 | 高度可定制 | 生产级复杂Agent |
从这张表可以看出，CAMEL解决的是“最小可行的Agent协作”问题，而后续框架在可控性和工程化上做了大量加强。但反过来，CAMEL的核心思想——用角色扮演和初始提示来引导对话，直到今天仍被很多框架借鉴。
三个常见的误解
误解一：CAMEL是两个模型在训练新模型
不是。CAMEL只是调用现成的LLM（比如GPT-4），通过设计不同的prompt让它们扮演角色并对话。它不改变模型的权重，也不产生新模型。它生成的是对话数据。
误解二：角色扮演只是为了好玩
不是。角色扮演在这里是一种强大的约束机制。它把“两个模型自由聊天”转化为“一个任务导向的结构化协作”。没有角色约束，两个模型很可能陷入无意义寒暄。
误解三：CAMEL的输出可以直接用作生产结果
不建议。由于是长多轮对话，中间很容易累积误差。CAMEL更适合探索思路、生成训练数据，而不是直接产出可靠代码或文档。如果你需要可靠输出，请加上人工审查或使用更可控的框架。
我的判断
如果你打算了解多Agent协作的本质，从CAMEL入手是个不错的起点。它把问题压缩到最简：两个模型、两个角色、一段提示。你不需要配置复杂的图或状态机，跑一个demo就能看到Agent之间是如何交互、如何收敛到一个答案的。
但如果你想用它搭建真实服务，我建议还是直接上AutoGen或LangGraph这类工具。CAMEL的局限不在于“角色扮演”这个思路，而在于它把一切都押在自然语言对话上。没有显式的任务分解、没有工具调用、没有错误恢复，一旦模型回复略有偏差，整个流程就可能崩掉。它更像一面镜子，让我们看到多Agent协作的潜力，也看到那条路很长。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/322.html