多智能体对局模拟实战：复现LLM角色情绪化输出

1杀5死，评分倒数第一，然后原地开喷队友全是低分——这段对话不是某位玩家打游戏上头的记录，而是这次要看的这个项目里，一个名为“诸葛亮”的大模型智能体自动生成的输出。

这次我们来看一个特殊的大模型项目：《神人对决》系列。它不生成图片、不做语音合成，而是把多个大语言模型智能体放进同一场对战对局里，让它们带着各自的角色人设做决策、打配合、说垃圾话。系列第一集也就是本文要演示的实验，标题就叫《神人对决1》：1/5诸葛亮怒喷队友全是低分。“1/5”指的是对局战绩，1次击杀、5次阵亡，评分列表垫底。最值得玩味的是，这个劣势数据并没有让诸葛亮沉默，反而让它生成了一连串嘲讽和甩锅内容。

一眼看上去像游戏吐槽，实际上是一段可以复现的 LLM 生成结果。诸葛亮智能体在拿到“1杀5死”的战绩、队友的低分评分，再配合“毒舌军师”这类角色设定后，输出的就是这段“怒喷队友全是低分”的内容。这种现象背后是角色一致性、上下文注入、采样温度和系统提示词等多个因素的叠加。

这个项目真正值得关注的点有三个：

• 多个 LLM 智能体可以在同一场景里做实时对话和决策；
• 战绩、评分、人设这些结构化数据可以作为上下文直接控制输出风格；
• 可以批量运行模拟实验，把完整对话日志导出成 JSON 或 Markdown，方便做 Prompt 消融和多智能体行为分析。

本文会带大家完成一条完整的本地部署与验证流程：准备环境、拿到代码、配置角色、运行《神人对决1》这个实验、复现“诸葛亮怒喷队友”的输出，再通过 API 和批量任务把模拟跑成可观测的数据集。

适合的读者有两类：一类是研究大模型角色扮演是否稳定、多智能体协作会不会穿帮的技术用户；另一类是做大模型 Prompt 工程、上下文工程，想找一个可量化的实验场景的开发者。

1. 核心能力速览

建议先看下表，确认这个项目是否符合你的需求。

从标题来看，多数人第一反应是问“这是不是一个真能玩游戏的项目”。更准确的判断是：它不直接操作游戏客户端，它模拟的是游戏场景里“角色说什么、角色怎么决策”这件事。输入是角色设定和游戏状态，输出是对话与决策记录。

2. 这个项目到底在复现什么现象

先拆标题。《神人对决1》是系列实验编号，1/5 是诸葛亮智能体的战绩，也就是 1 次击杀、5 次阵亡。“怒喷队友全是低分”是模型在这个战绩和队友评分数据下生成的对话结果。

2.1 为什么模型会输出“怒喷队友”

这类输出并不是随机出现的。在生成这条内容时，上下文里包含了几类关键信息：

• 角色人设：诸葛亮，毒舌军师，语言犀利；
• 对局状态：己方处于劣势，诸葛亮个人战绩 1/5；
• 队友数据：队友评分整体偏低；
• 情绪引导：提示词中要求“表达不满情绪”。

当这四类信息同时存在，模型很容易生成类似玩家情绪发泄的内容。只要保留相同的人设描述和战绩数据，再控制好随机采样，这条输出基本可以稳定复现。这说明大模型的“情绪化”输出很大程度是提示词和上下文工程的结果，而不是模型真的生气了。

如果去掉“毒舌”人设，或者把战绩改成 5/1，同一套系统下生成的语气会明显不同。做这个实验的目的，就是观察这种改变是如何影响输出的。

2.2 这个项目解决什么问题

它解决的是多智能体场景下的两个问题：

第一，角色一致性。多个智能体同时在线对话时，人设会不会漂移。很多人在单轮对话里觉得模型扮演角色没问题，一旦放到多人连续对话里，角色就慢慢“出戏”。《神人对决》用强结构化的角色卡和状态卡来约束这种漂移。

第二，上下文对生成的影响。模型生成“怒喷”还是“安慰队友”，不完全取决于模型能力，更多取决于你往上下文里塞了什么数据。这个项目把战绩、评分、人设做成标准字段，方便反复替换变量做实验。

3. 适用场景与使用边界

这类 LLM 多智能体模拟最危险的点在于：生成内容非常像真人。必须先说清楚边界。

3.1 适合的用途

• 大模型角色扮演稳定性测试；
• 多智能体协作与对话行为分析；
• Prompt 中“情绪引导”“性格限定”的消融实验；
• 做 AI 内容创作的素材实验，比如小说对白、游戏 NPC 对话文案。

3.2 不建议的用途

• 不允许用于游戏代打，或在真实玩家对局中伪装人类身份；
• 不允许生成包含辱骂、人身攻击、歧视内容的输出后直接对外发布；
• 不允许把智能体生成的内容冒充为真人聊天记录；
• 不允许用真实玩家 ID、真实战绩数据做未脱敏的模拟实验。

3.3 合规提醒

在使用战绩、评分、玩家昵称等数据时，应当先做脱敏处理。如果这个项目后续要接入语音合成、数字人展示，还必须确认角色形象与声音的授权。涉及商业发布的内容，要先做人工审核，确认不会对他人造成误导或名誉影响。

4. 环境准备与前置条件

这一部分给出通用部署流程，具体路径和版本以实际项目文档为准。

4.1 基础环境清单

4.2 模型方案选择

如果使用云端 API，只需要一个 API Key 和接口地址。这个项目走 OpenAI 兼容协议，所以很多模型服务都能接。

如果使用本地模型，推荐先跑 7B 量化模型，比如 Qwen2.5-7B-Instruct 的 int4 版本。CPU 推理也能跑，但速度慢，适合测试用；GPU 推理可以明显降延迟。13B 模型对显存要求更高，建议先 7B 验证流程，再换大模型看效果。

注意：不要一开始就追求大模型。这个项目的重点是模拟和多智能体行为观察，模型参数量不是决定实验成败的第一因素。

5. 安装部署与启动方式

假设项目代码已经下载到本地，目录结构类似下面这样：

shenrenduel/ ├── configs/ │ └── duel_1.yaml ├── src/ │ ├── agent.py │ ├── game_state.py │ └── runner.py ├── logs/ ├── requirements.txt └── main.py

如果没有下载地址，就按你手里的代码包路径替换。下面以命令行启动方式为例。

5.1 安装依赖

cd shenrenduel python -m venv .venv source .venv/bin/activate # Windows 下使用 .venv\\Scripts\\activate pip install -r requirements.txt

注意，如果本地网络源较慢，可以使用国内镜像安装依赖：

pip install -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

5.2 配置角色与模型参数

实验配置写在configs/duel_1.yaml中。第一次跑《神人对决1》实验，配置大致如下：

experiment: name: shenren_duel_1 seed: 42 episodes: 10 model: provider: openai base_url: "http://127.0.0.1:8000/v1" api_key: "sk-local-test" model_name: "qwen2.5-7b-instruct" temperature: 1.2 max_tokens: 512 agents: - name: 诸葛亮 identity: "毒舌军师，说话犀利，喜欢挖苦队友" role: "中路法师" state: kill: 1 death: 5 assist: 2 score: 40 - name: 队友A identity: "老实本分的打野，话少" role: "打野" state: kill: 3 death: 3 assist: 1 score: 52 - name: 队友B identity: "乐观但嘴笨的射手" role: "射手" state: kill: 0 death: 6 assist: 0 score: 35 system_prompt: "你是诸葛亮，正在一局势均力敌的对战里打中路。现在对局进入中期，战绩与队友评分已经给出。请根据当前局势发表一句吐槽或指挥，要符合毒舌军师的人设。"

关键参数说明：

• temperature: 1.2会提高输出随机性和情绪化表达，但也会降低稳定性；想稳定复现“怒喷”效果时，可以先保持这个值。
• seed固定随机种子可以让同一条输出更容易复现，但不同模型服务对 seed 的支持程度不一样。
• state里的 kill、death、score 就是接下来会注入到上下文中的战绩与评分。

5.3 启动模拟实验

配置完成之后，命令行启动：

python main.py --config configs/duel_1.yaml

启动后可以看到类似下面的流程输出：

[Episode 1/10] 初始化对局... [Episode 1/10] 诸葛亮 获得上下文: 战绩 1/5, 评分 40 [Episode 1/10] 诸葛亮: 你们这评分也配让我带？我1/5是因为你们全在送！ [Episode 1/10] 队友A: 我的锅，下一波团我先手。 [Episode 1/10] 队友B: 别骂了别骂了，稳住。

出现对话输出就说明流程跑通了。接下来要重点观察的是：诸葛亮的人设是否一致、其他角色是否稳定回应、对话有没有出现上下文丢失。

6. 功能测试与效果验证

项目跑起来只是第一步。下面按功能维度做验证。

6.1 复现“怒喷队友”现象

测试目的：确认《神人对决1》的标题输出能否复现。

操作步骤：

1. 修改duel_1.yaml，设置诸葛亮战绩为 1/5、评分为 40；
2. 保持队友评分低于诸葛亮；
3. 保持“毒舌军师”人设；
4. 运行 5 轮模拟，看是否至少出现一次类似“队友全是低分”的表达。

判断标准：连续 5 轮中至少 3 轮输出出现批评队友、甩锅或贬低队友分数的内容，说明现象可复现。

如果复现不出来，优先检查temperature是否过低，以及system_prompt是否被后续对话覆盖。调整策略是把temperature提到 1.0 以上，或者把“毒舌、犀利、擅长挖苦”这类词直接写进人设。

6.2 角色一致性测试

多个智能体连续对话时，角色是否漂移是核心问题。测试方法是让同一角色配置连续对话 10 轮，然后统计它的语气、常用词、态度是否保持一致。

可以给每个智能体设计一句“标志性口头禅”。例如诸葛亮的标志性输出是“我早说了你们不行”。测试时检查它在第 1 轮和第 10 轮是否仍然使用类似表达。

如果中途出现“人设下线”，比如诸葛亮突然变成“温柔的辅助”，说明上下文管理有问题。排查思路：

• 检查max_tokens是否太短，导致模型只能输出简短内容；
• 检查state数据是否每一轮都在上下文里正确更新；
• 检查历史对话拼接顺序是否正确，最新状态是否在最前面。

6.3 情绪引导可控性测试

这个实验最有价值的部分是：验证“怒喷”是否能被控制开关。

测试方式：

1. 在提示词中加入“你有一次发言机会，请尽量稳定军心，不要说脏话”；
2. 其他参数不变；
3. 观察输出是否从“怒喷”变成“指挥”。

如果加入正向提示后输出明显缓和，说明情绪输出可以被 Prompt 控制。后续做内容安全过滤时，可以采用类似方案：先由模型生成原始内容，再用规则或第二轮模型推理做过滤。

建议在实验配置里增加一个safety_filter选项：

safety_filter: enabled: true blocked_words: - "废物" - "垃圾" - "菜鸡"

6.4 长对话稳定性测试

多智能体最大的坑是上下文一长，模型开始遗忘自己的状态。

测试方法：

1. 把对局轮次从 10 轮增加到 30 轮；
2. 每轮生成后检查“诸葛亮”是否还知道自己是1/5；
3. 在第 15 轮询问诸葛亮“你现在战绩是多少”，看是否答对。

如果模型忘记战绩，说明上下文拼接策略有问题。解决方式是：每一轮对话前都把最新的战绩与评分重新注入到系统提示词中，而不是依赖模型记住之前的对话。

7. 接口 API 与批量任务

模拟实验不应该只在命令行里跑。把对局逻辑封装成 API 服务之后，可以接入自己的脚本或前端页面。

7.1 启动 API 服务

python app.py --host 127.0.0.1 --port 7860

服务启动后，可以通过 HTTP 接口发起一场模拟对局。

7.2 请求示例

curl -X POST http://127.0.0.1:7860/api/duel \ -H "Content-Type: application/json" \ -d '{ "experiment_name": "shenren_duel_1", "episodes": 5, "temperature": 1.2, "seed": 42 }'

如果服务正常，返回内容会包含多场对局的完整对话记录，结构大致如下：

{ "experiment_name": "shenren_duel_1", "episodes": [ { "episode": 1, "agents": ["诸葛亮", "队友A", "队友B"], "dialogues": [ { "speaker": "诸葛亮", "content": "你们这评分也配让我带？", "turn": 1 } ] } ] }

7.3 Python 调用示例

用 Python 请求接口并保存结果：

import json import requests url = "http://127.0.0.1:7860/api/duel" payload = { "experiment_name": "shenren_duel_1", "episodes": 20, "temperature": 1.2, "seed": 42 } response = requests.post(url, json=payload, timeout=300) if response.status_code == 200: data = response.json() with open("logs/shenren_duel_1.json", "w", encoding="utf-8") as f: json.dump(data, f, ensure_ascii=False, indent=2) print("实验完成，日志已保存") else: print("请求失败:", response.status_code, response.text)

这里注意timeout要给足。一场包含 10 轮对话的模拟，如果模型服务响应较慢，30 秒不一定够用，建议设到 300 秒。

7.4 批量任务设计

批量任务的核心是把“配置”和“运行”分离。推荐采用目录扫描方式：

batch_runs/ ├── run_001/ │ └── config.yaml ├── run_002/ │ └── config.yaml └── run_003/ └── config.yaml

每个子目录放一份独立的实验配置，批量脚本逐个执行：

python batch_run.py --input batch_runs --output logs/batch_results

批量任务建议记录三样东西：

• 每次运行使用的完整配置；
• 模型服务的请求延迟；
• 最终输出的对局日志。

如果中途某一组跑挂了，脚本应当跳过该组并继续执行后续任务，最后生成汇总结果。不要因为一组失败就终止整批实验。

8. 资源占用与性能观察

多智能体实验的资源消耗比单轮对话要复杂。同一个模型实例要处理多个角色的请求，相当于把多份上下文交替喂给模型。

8.1 显存与内存观察方法

运行期间用下面的命令观察资源：

nvidia-smi -l 1

Linux 下也可以用：

watch -n 1 nvidia-smi

CPU 内存观察：

top

重点关注几个指标：

• 模型加载后的基础显存占用；
• 并发请求增多后显存是否继续上涨；
• 上下文长度增长后推理延迟的变化；
• CPU 内存是否持续增长，可能是日志或历史对话缓存导致。

实际占用没有一个统一数值，因为模型版本、量化方式、最大生成长度、并发数都会影响结果。第一次测试时，建议先用最小配置跑通，再逐步加大批量数。

8.2 影响性能的主要因素

对这类模拟器影响最大的不是 GPU 算力，而是上下文长度。多个智能体交替发言，历史对话会快速增长。对话越长，模型的 prefill 阶段耗时越长。

可以通过三个手段降低压力：

• 限制每轮输出长度，例如把max_tokens从 512 降到 256；
• 做历史裁剪，只保留最近 10 轮对话；
• 把战绩和评分从历史对话中抽出来，重新注入到系统提示词，避免模型靠注意力机制从长历史里找信息。

model: max_tokens: 256 history_rounds: 10

8.3 避免端口冲突

如果 API 服务占用端口 7860 被其他服务占用了，启动前先检查端口：

lsof -i :7860

确认没有服务占用后再启动。也可以在命令行指定其他端口：

python app.py --host 127.0.0.1 --port 7861

进程残留也会导致端口冲突。Linux 下如果服务异常退出，端口仍被占用，可以按 PID 结束进程，但不要用pkill -f app.py这种误伤范围过大的命令。

9. 常见问题与排查方法

下面是运行这个项目时最容易遇到的一批问题，按现象整理成表格。

9.1 关于“输出过于恶意”的特殊处理

这个项目最容易出现的问题不是运行不了，而是生成的内容不适合直接对外展示。如果模拟出大量辱骂性词汇，需要在两个层面处理：

• 输入层：收敛人设描述，把“毒舌”改成“说话直接但不说脏话”；
• 输出层：增加关键词过滤，或接入第二层审核模型。

建议所有命令行输出界面也做一层内容过滤，不要直接把模型原始输出打印到终端，避免误操作复制出去使用。

10. 最佳实践与使用建议

项目跑通之后，真正想做多智能体实验的读者，建议遵守下面这些工程习惯。

10.1 第一次实验永远用小参数

第一次不要直接跑 30 轮、20 个智能体的大实验。先用 3 个智能体、5 轮对话、256 token 输出，跑通全流程。确认日志能正常保存后，再逐步扩大规模。这样可以快速定位问题，也不会因为一次参数错误浪费大量模型调用费用。

10.2 配置文件、日志、模型文件分目录管理

建议的工作目录结构：

shenrenduel/ ├── configs/ ├── logs/ │ ├── raw/ │ └── results/ ├── models/ └── scripts/

logs/raw保存模型原始输出，logs/results保存清洗后的实验结果。模型文件单独放，避免和代码混在一起导致后续升级困难。

10.3 批量任务必须加失败重试

批量实验如果跑了一半失败，不要直接重跑全部，而是记录每个子任务的status。推荐每个子任务保存三个文件：

run_001/ ├── config.yaml ├── output.json └── status.json

status.json记录任务是否完成、失败原因、耗时等。后续重试时只处理status.json中标记为failed的任务。

10.4 数据脱敏与授权

如果外部传入真实玩家战绩、昵称，这些属于个人信息，需要做脱敏处理。建议在配置层直接把昵称替换成“玩家A”“玩家B”。如果后续要发布实验截图，还要确认角色名、游戏素材没有侵权风险。

10.5 接口访问范围控制

API 服务默认监听127.0.0.1，按上面的命令启动时不会暴露到公网。如果确实需要远程访问，必须加访问鉴权，不要裸奔到公网。建议加一层简单的令牌校验：

python app.py --host 0.0.0.0 --port 7860 --api-key your-token

没有鉴权机制的项目不要直接绑定0.0.0.0。

11. 总结与下一步

《神人对决1》里最有价值的点不是“诸葛亮骂人”这句话本身，而是它把“角色人设 + 游戏状态 + 上下文注入”这三件事全部变成了可观测、可重复实验的对象。只要战绩、评分、人设描述保持一致，类似输出就能稳定复现。这意味着我们完全可以通过调整上下文来观察生成内容的变化规律。

最先建议验证的功能是“怒喷现象”的复现与消除。先在temperature: 1.2条件下确认可以生成标题里的输出，再在系统提示词中加入“稳定军心”的指令，观察输出是否转向。这两个实验做完，基本就能理解这个项目的核心机制。

这个项目最容易踩的坑有两个：一个是上下文变长后角色开始遗忘战绩，一个是生成内容过于恶意导致无法展示。前者靠每轮重新注入结构化状态解决，后者靠收敛人设和输出过滤解决。

后续可以考虑的扩展方向包括：接入语音合成，把智能体对话转成音频；接入数字人形象，做视频解说；也可以把多智能体模拟扩展到更复杂的多人协作场景，比如团队项目管理、客服协同，而不仅是游戏对局。

建议收藏备用，尤其是做 Prompt 工程和多智能体实验的读者，这套“结构化上下文 + 批量模拟 + 日志导出”的流程可以直接迁移到自己的项目里。