CAMEL 实验中，那些停不下来的对话

CAMEL 记录过一种对话，两位 Agent 反复感谢或告别，已经意识到交流陷入循环，却仍然继续回复。它还记录了角色互换、重复指令和只承诺行动的回复。CAMEL，Challenges 章节

这些失败适合用来理解角色协作。模型能够持续产生符合语境的句子，但句子之间未必有任务进展。要让角色分工成立，需要同时约束任务、交流方式和终止条件。

概念插画，由 imagegen 生成。

三份提示词各自约束什么

CAMEL 的 inception prompting 包括 task specifier prompt、assistant system prompt 和 user system prompt。任务细化者把初步想法展开为具体任务；另两份系统提示分别定义合作双方。Inception Prompting 章节

这里的 AI user 也是模型实例。它提出指令，AI assistant 回应，二者在既定约定下循环。论文借助这种方式探索合作行为并生成对话数据，因此任务细化者可以使用想象展开任务。

这个前提在产品里需要调整。生成研究用任务时，扩展一个想法可以增加任务多样性；处理用户已有需求时，补出的细节可能改变工作范围。将 task specifier 接入实际产品，应区分用户提供的条件与模型补充的假设，并对影响结果的假设取得确认。

角色提示还包含交流格式、结束方式和避免不期望行为的要求。它们的作用是改变后续生成的条件。职位名称只占其中一部分，“测试工程师”这样的名称无法替代检查范围、输入材料和工具能力。

四类失败需要四种观察

CAMEL 的失败分类有价值，因为它没有把停滞都归为回答质量差。

现象	交流中发生了什么	排查时应观察什么
Role flipping	助手开始指挥用户角色，双方职责交换	指令方向是否偏离协议
Repeating instructions	助手复述要求，却没有给出解答	新回复是否增加任务内容
Flake replies	回复承诺接下来行动，没有完成对应工作	承诺后是否产生结果
Infinite loop	感谢、告别等消息反复出现	对话是否缺少有效终止

角色互换属于协议偏离。只承诺行动属于进度缺失。两者需要不同处理，即使一段对话没有互换角色，也可能停留在承诺与确认之间。仅检查回复是否保持职业语气，识别不了这些问题。

论文对角色互换采用了限制助手指挥对方等提示约束。但约束越严格，交互空间也越窄。实际协作中，复核者可能需要向执行者追问依据。照搬不许提问的规则，会阻断必要澄清。可借鉴的是观察协议偏离的方法，具体协议仍应服从任务。

对话结束与任务完成分开记录

论文列出的终止条件包括用户角色连续三轮没有给出指令、助手发出指令导致角色反转、收到 <CAMEL_TASK_DONE>，以及达到 token 限制。它们分别对应协议异常、模型判断和资源耗尽。Termination Conditions

这些原因都能让循环停止，只有结束标记表达了模型认为任务已经完成。即便收到标记，也仍然只是模型的判断。在能核对产物的应用中，还需要检查结果是否满足要求。否则，资源耗尽和正常交付会在统计中被混为一谈。

Nexus 的 SDK 消息流有运行时结果消息，用于结束当前一轮并报告错误。这个运行层信号同样需要与业务验收区别对待。运行时没有报错，并不证明某份报告的事实正确；业务通过验收，也不应只依赖一句结束语。

职责要落到可观察的动作

Nexus 成员可以配置职责、模型与能力，Thread 可以用于检查执行过程。将 CAMEL 的观察用于这里，重点是让职责对应到动作与证据。Agent 配置

复核职责至少应明确检查对象和能否修改。允许成员读取材料并提出问题，与允许它覆盖原文件，是两种工作范围。提示词说明意图，工具权限决定可执行范围。AI user 角色提出的请求不能增加真实用户的授权。

针对 flake replies，执行记录的价值也有范围。存在一次工具调用，可以证明发生过操作；要确认任务有进展，还需检查工具返回值是否支持当前结论。读取一个文件后声称所有文件都已检查，仍然缺少依据。

因此，一个用于产品验证的记录应串起任务要求、实际动作和交付声明。出现“已完成”时能回到对应产物，出现“无法继续”时能找到缺失条件。这个关联比统计成员发言次数更有解释力。

CAMEL 的对话数据与真实工作交付之间仍有距离。其方法可以研究角色行为，不会自动提供文件验收、操作权限或任务恢复。对 Nexus 来说，值得吸收的是这些失败类别及其终止原因，用它们检查一个既有协作流程是否在推进，而非仅仅保持对话。

本文按 CAMEL 原论文的角色协议与失败分析展开，并与 Nexus 当前公开入口对照，未声称完成该论文的训练或复现。关于成员互相影响答案的问题，见多智能体辩论解读。