多智能体LLM交互中的涌现语言：GlossoGen实验与复现指南

多智能体 LLM 交互过程中，智能体之间会不会自发形成只有自己人才听得懂的“暗号”？GlossoGen 这个研究方向，讨论的正是这种涌现语言问题。它不是某个能直接下载的一键包，而是一个偏学术、偏实验的项目方向：在多智能体协作任务中，LLM 是否会自动发明术语、缩写、特殊表达，用来代替完整自然语言，从而提升通信效率。本文会把这个方向的背景、核心机制、实验设计思路讲清楚，并给出一套可运行的最小复现框架。如果你关注 LLM Agent、多智能体协同、涌现行为分析，这篇文章可以当作一个实验起点。

先说重点。GlossoGen 这个项目方向包含三个核心词：Glosso（与语言相关）、Gen（生成）、Emergent Language（涌现语言）。它研究的是多个 LLM 在复杂交互中，如何从自然语言对话演进出一种更高效、更结构化的通信协议。对于普通开发者来说，最直接的价值是：理解多 Agent 系统中的通信冗余问题，并学会用实验手段观察 token 消耗变化、协作成功率、特殊术语出现频率等指标。本文会从环境准备、最小实验系统搭建、效果验证、性能观察、常见排错等几个维度展开，帮助你把“涌现语言”从一个抽象概念变成可量化的实验项目。

1. 核心能力速览

GlossoGen 并不是一个可以直接安装的软件包，更像是一个研究课题或技术框架的名称。从公开资料看，它围绕多智能体 LLM 交互中的语言涌现现象，提供了一套分析和实验思路。下面的表格基于行业通用认知整理，实际参数需要根据你所用的 LLM 模型和实验代码来确认。

这张表里列出的“显存占用”“启动方式”等，都强调“需以实际模型为准”。原因是 GlossoGen 本身不绑定具体 LLM，你可以在 GPT-4o、Claude、DeepSeek 或本地开源模型上跑。实验目标不是训练新模型，而是分析已有 LLM 在多智能体对话中的行为模式。

2. 适用场景与使用边界

这套实验体系适合三类人。第一类是做 LLM Agent 开发的工程师。当你的系统里有多个 Agent 协作，互相传递 prompt 和 response 时，你会发现 token 消耗非常大，通信过程经常包含大量重复描述。通过分析涌现语言，可以设计更紧凑的通信协议，降低 token 开销。第二类是做基础研究的学生或研究员。你需要探索 LLM 的涌现能力，比如它们会不会自主发明术语、会不会把长句子压缩成短语。第三类是对自动化和协作效率感兴趣的开发者。你可以将“涌现语言”的观察机制集成到自己的 Agent 日志分析工具中，用它发现协作瓶颈。

但要泼一盆冷水：GlossoGen 这个方向目前还不是工业级解决方案。如果你期望开箱即用，直接得到一个“暗号翻译器”或者“自动协议生成器”，现在还做不到。它的价值更多在于实验观察和启发。另外，运行实验时要注意合规边界：你通过 API 发送给模型的所有 prompt 和返回的 response 都可能被模型提供方的服务记录，所以不要在其中包含真实用户隐私、企业机密或未授权的第三方数据。如果要在生产环境使用类似逻辑，必须加上脱敏、审计和授权确认环节。

还有一个现实边界：多智能体 LLM 交互容易出现“聊偏了”的情况，Agent 之间可能绕来绕去，甚至为了“协作成功”而开始编造一些不存在的术语，导致可读性变差。这就是涌现语言的负面效应。所以实验不只是观察，还要设定评价规则，区分“有效压缩”和“无效漂移”。

3. 前置概念：LLM、Multi-Agent 与 Emergent Language

在准备环境前，先把三个基础概念串一遍。

LLM（Large Language Model）是语言模型，它根据输入的 token 预测下一个 token。多轮对话中，模型状态由上下文决定，没有显式记忆，所有历史交互都靠 token 拼接。

Multi-Agent（多智能体）是指一个系统包含多个独立的 Agent，每个 Agent 有自己的角色、目标和上下文。常见架构有：两个 Agent 互相辩论、一个规划者配多个执行者、或者多个 Agent 共享一个黑色板。不同架构会产生不同的通信模式。

Emergent Language（涌现语言）是本文重点。在 Multi-Agent LLM 交互中，Agent 如果频繁面临长上下文和重复目标，可能会逐渐缩短表达，例如把"请你根据任务描述生成 SQL 查询语句"简化为"SQL gen"，再把"SQL gen"进一步简化为"SQLG"。这种简化的表达方式不是开发者预设的，而是 Agent 在交互中自发形成的，就叫涌现语言。

GlossoGen 这个名称可能暗示两个过程：Glosso（词汇层面）的生成（Gen），即系统生成了一套新的词汇表，用来在多个 Agent 间高效传递信息。实际验证时，可以算一算不同轮次的 token 数、新词比例、语义相似度等指标，来判断是否出现了“语言压缩”。

4. 环境准备与前置条件

实验需要 Python 环境和可调用的 LLM。下面是一份通用清单，不绑定具体版本。

在安装依赖时，建议用虚拟环境隔离，避免把系统环境搞乱。

# 创建虚拟环境（假设你在项目目录下） python -m venv venv # Linux / macOS 激活 source venv/bin/activate # Windows 激活 venv\Scripts\activate # 升级 pip 并安装依赖 pip install --upgrade pip pip install openai anthropic requests PyYAML pandas matplotlib

如果是本地模型推理，你还需要安装对应框架，例如 vLLM 或 Ollama。这里不展开细节，因为具体命令取决于你选用的推理服务。关键是让 Python 代码可以通过 HTTP 接口访问到模型。

5. 搭建最小多智能体实验系统

GlossoGen 的实验核心是让多个 Agent 反复协作完成同一类任务，然后观察通信语言的变化。这里给出一个最小可运行的模板，使用 OpenAI 兼容接口模拟两个 Agent 的对话。

假设场景是两个 Agent 合作完成一个自然语言到 SQL 转换任务。Agent A 负责将用户需求转成“结构化任务摘要”，Agent B 负责根据摘要生成 SQL 查询。我们先让它们用完整自然语言沟通，运行若干轮后，再观察它们之间的 prompt 是否变短、是否有固定术语出现。

下面用 Python 模拟多轮协作，每次记录 token 数和消息内容。

import time import json from openai import OpenAI # 这里请替换成你自己的 API key 和 base_url client = OpenAI( api_key="your-api-key", base_url="https://api.example.com/v1" # 如果使用兼容接口，替换为实际地址 ) def call_llm(messages, temperature=0.0): """调用 LLM，返回回复内容和 token 使用情况""" resp = client.chat.completions.create( model="your-model-name", # 替换为实际模型名 messages=messages, temperature=temperature, ) content = resp.choices[0].message.content usage = resp.usage return content, usage def run_cooperation_round(task_description, history=None): """运行一轮 Agent A 和 Agent B 的协作""" if history is None: history = [] # Agent A: 将自然语言任务转换成结构化摘要 agent_a_messages = [ {"role": "system", "content": "你是 Agent A，负责将用自然语言描述的任务转换成简洁的结构化摘要。"}, ] + history + [ {"role": "user", "content": f"任务：{task_description}\n请输出结构化摘要。"} ] summary, usage_a = call_llm(agent_a_messages) # Agent B: 根据摘要生成 SQL agent_b_messages = [ {"role": "system", "content": "你是 Agent B，只根据摘要生成 SQL。如果摘要不清清，请要求补充。"}, {"role": "user", "content": f"摘要：{summary}\n请生成 SQL。"} ] sql, usage_b = call_llm(agent_b_messages) # 更新对话历史 history.append({"role": "user", "content": f"任务：{task_description}"}) history.append({"role": "assistant", "content": f"摘要：{summary}"}) history.append({"role": "user", "content": f"生成 SQL：{sql}"}) return summary, sql, usage_a, usage_b, history # 运行连续任务，观察通信长度变化 tasks = [ "查询所有年龄大于30岁的用户", "查询所有年龄大于30岁且注册时间在2023年之后的用户", "查询所有年龄大于30岁且注册时间在2023年之后且订单总额超过1000的用户", "查询所有年龄大于30岁、注册时间在2023年之后、订单总额超过1000且最近一次登录在7天内的用户", ] history = [] for i, task in enumerate(tasks): summary, sql, usage_a, usage_b, history = run_cooperation_round(task, history) total_tokens = usage_a.total_tokens + usage_b.total_tokens print(f"轮次 {i+1}: 摘要长度 {len(summary)} 字符，SQL长度 {len(sql)} 字符，总token数 {total_tokens}")

这个模板会让人直观看到：随着任务越来越复杂，摘要长度和 SQL 长度反而可能趋于稳定，因为 Agent A 会不断调整自己的“摘要风格”，逐渐形成一套更精炼的表述。如果出现固定的短语如“A30 + 注册后 + 订单超千”，那就是涌现语言的雏形。

注意，上面的openai库版本和 API 参数需要根据实际接口调整。如果你使用的是 Anthropic API，则用对应 SDK。

6. 实验设计与效果验证

只跑一轮没有意义，要通过多轮、多组、多指标的实验来验证涌现语言是否存在。建议按照下面的流程设计。

6.1 定义观测指标

至少记录四类指标。

6.2 多组对照实验

至少设置三组。

• 组1：两个 Agent 使用系统提示词，明确要求“表达尽量简洁”，观察是否快速形成协议。
• 组2：两个 Agent 没有简洁要求，按默认方式工作，观察是否自然涌现。
• 组3：使用不同 LLM 模型（如一个强模型、一个弱模型），观察语言涌现差异。

每组固定相同任务集，跑 30 到 50 轮，记录指标，最后画折线图。

6.3 判断涌现语言的标准

符合下面任意两条，就可以说观测到了涌现语言：

1. 在任务语义不变或变化较小的前提下，Agent 间的消息长度随时间显著下降。
2. 出现了不在系统提示词中定义的新词、缩写、编码方式，且被另一个 Agent 正确理解并使用。
3. 去掉这些新词后，协作成功率明显下降，说明它们承载了信息。

6.4 常见失败原因

如果跑完看不到任何涌现信号，先排查三点：

• 任务是否太简单，Agent 不需要压缩就能轻松完成；
• 对话历史太长，模型遗忘或忽略早期约定；
• 两个 Agent 使用的是不同上下文窗口，互相看不到对方的历史结论。

纠正方式：提高任务复杂度，增加上下文窗口长度，或者把前一轮的摘要直接拼到下一轮开头。

7. 接口 API 与批量实验调度

GlossoGen 这类实验往往需要跑大量轮次，手工一轮轮跑根本不现实。因此要会写批量调度脚本，并尽可能让实验过程支持可配置参数。

7.1 配置化实验参数

用 YAML 文件管理实验参数，能避免频繁修改代码。

experiment: name: "glossogen_v1" model: "your-model-name" api_type: "openai" # openai / anthropic / local api_base: "http://127.0.0.1:8000/v1" temperature: 0.0 rounds: 30 tasks_file: "./tasks.txt" output_dir: "./outputs" agents: - role: "planner" system_prompt: "你是规划者，提炼任务要点。" - role: "executor" system_prompt: "你是执行者，将要点转化为结果。"

import yaml import json import os def load_config(path): with open(path, "r", encoding="utf-8") as f: return yaml.safe_load(f) def run_batch(cfg): os.makedirs(cfg["experiment"]["output_dir"], exist_ok=True) with open(cfg["experiment"]["tasks_file"], "r", encoding="utf-8") as f: tasks = [line.strip() for line in f if line.strip()] results = [] for round_idx in range(cfg["experiment"]["rounds"]): for task_idx, task in enumerate(tasks): # 这里调用之前写好的 run_cooperation_round 函数 result = run_single_round(task) result["round"] = round_idx result["task_idx"] = task_idx results.append(result) save_jsonl(result, os.path.join(cfg["experiment"]["output_dir"], "results.jsonl")) def save_jsonl(data, path): with open(path, "a", encoding="utf-8") as f: f.write(json.dumps(data, ensure_ascii=False) + "\n") if __name__ == "__main__": cfg = load_config("./experiment.yaml") run_batch(cfg)

7.2 使用异步并发控制

如果你希望提升实验速度，可以用 Python 的concurrent.futures或asyncio。但要注意模型 API 的 Rate Limit。建议加一个简单的重试装饰器，遇到 429 或超时自动退避。

import time import functools def retry(max_retries=3, delay=2): def decorator(func): @functools.wraps(func) def wrapper(*args, **kwargs): for attempt in range(max_retries): try: return func(*args, **kwargs) except Exception as e: print(f"Request failed: {e}, retry {attempt+1}/{max_retries}") if attempt == max_retries - 1: raise time.sleep(delay * (attempt + 1)) return wrapper return decorator @retry() def call_llm_safe(messages): # 实际调用代码 pass

7.3 通过 curl 测试 Agent 交互

如果你不想写 Python，也可以先用 curl 验证多轮对话是否能跑通。下面是一个通用示例，需要替换实际 API 地址和 key。

curl http://127.0.0.1:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer YOUR_API_KEY" \ -d '{ "model": "your-model-name", "messages": [ {"role": "system", "content": "你是 Agent A，输出任务摘要。"}, {"role": "user", "content": "查询所有年龄大于30岁的用户"} ] }'

返回的 JSON 里会包含message.content和usage.total_tokens，可以据此测量语言长度。

8. 资源占用与性能观察

运行多 Agent 实验最敏感的资源是 token 数量和上下文长度。先说 token 消耗：每一轮多 Agent 对话会把之前的历史全部拼进去，如果上下文窗口是 32K，跑到 20 轮后很可能把窗口塞满。这时模型会遗忘早期信息，甚至直接报错。这不是显存问题，而是注意力窗口问题。

如果使用本地模型，显存占用主要取决于模型规模、上下文长度和 batch 大小。一个 7B 模型在 FP16 权重下大约占用 14 GB 显存，但多数情况下会用量化版本，比如 INT4 量化后约 5-6 GB。这些数字不是 GlossoGen 本身的数字，而是模型的数字。实际测试时，可以通过nvidia-smi观察显存变化。

# 每 2 秒刷新一次显存占用 watch -n 2 nvidia-smi

如果显存不够，优先降低上下文长度，也就是限制历史轮数。不要在实验里保存无限长的历史。建议每轮最多保留最近 5 轮对话，并把更早的关键信息压缩成一条“历史摘要”。

另一个观察点是 API 服务的响应延迟。多 Agent 对话是串行调用，A 的输出是 B 的输入，如果 A 返回慢，整个流程就慢。批量实验时，最好并行跑多组实验，而不是把同一个实验内的多轮并行，因为轮次之间往往有依赖。

9. 常见问题与排查方法

出现问题时，先不要改代码，把日志多打几行。建议记录每轮调用的请求体、响应体、消耗 token 数、耗时。这些日志是定位一切问题的最终依据。

10. 最佳实践与使用建议

把这个实验做得更扎实，有几个工程化建议可以现在就用上。

第一，第一次先小规模测试。不要直接跑 50 轮，先用 3 个任务跑 3 轮，确认日志完整、指标能算出来，再扩大规模。多智能体实验一旦跑偏，排查成本会翻倍。

第二，保留一组“标准对话”作为对照组。比如完全不压缩的自然语言对话，作为基线。后面所有涌现语言的判定，都以基线为标准。否则你无法判断消息变短是语言压缩还是单纯丢信息。

第三，把实验配置、模型版本、API 版本全部写进输出文件。涌现语言实验对模型版本非常敏感，同一个实验换成不同模型结果可能完全不一样。建议每次实验都记录model、temperature、max_tokens、system_prompt，并用哈希值标记实验批次。

第四，批量任务要加日志和失败重试。网络抖动非常常见。如果 50 个任务里有一个超时，不重试会让整个数据集缺一块。建议使用 JSONL 逐行追加写入结果，这样中途断了也能接着跑。

第五，接口服务要注意访问控制。如果你把 Agent 服务部署到服务器上跑实验，不要把端口直接暴露在公网。至少加一层访问令牌，或者绑定 127.0.0.1 只允许本机访问。

第六，涉及版权、隐私、肖像的内容要格外小心。虽然 GlossoGen 实验主要处理文本任务，但如果你把真实用户对话、内部文档作为任务输入，就存在数据合规问题。建议用公开数据集或自行构造的任务集，不要拿敏感信息做实验。

第七，发布或商用前要做效果复核。涌现语言可能有趣，但并不总是正确。如果想让 Agent 之间使用简写协议来降低 token 消耗，必须人工检查这些简写是否稳定、有没有歧义、会不会在不同任务里产生误解。最好在每次协议变更后跑一遍回归测试。

11. 总结与下一步

GlossoGen 这个方向的核心吸引力，不在于训练一个新模型，而在于观察和利用多智能体之间的自发语言行为。通过今天这套最小实验流程，你可以在任意 LLM 上复现“两个 Agent 通过缩写和术语协作完成任务”的现象。需要优先验证的功能很简单：跑一组连续任务，看消息长度是否下降、协作成功率是否保持、是否出现特殊词汇。最容易踩的坑是上下文窗口溢出，以及把 token 下降误判为语言涌现而忽略任务完成质量。

下一步如果你想深入，可以做三件事：一是把观测指标扩展到语义向量空间，用 embedding 相似度判断“摘要是否仍然覆盖原意”；二是把两个 Agent 扩展到三个角色，观察语言是否会逐渐演化为“中间层协议”；三是把你自己的工具链加进来，比如让 Agent 在调用外部工具时自动把参数名压缩成短码。这些方向都建立在今天这套日志、指标和批处理之上。

如果你对多智能体协作、LLM 行为分析感兴趣，可以把这个实验框架在本地跑一下。不需要很强的显卡，用云 API 就能完成。整套代码控制在两百行左右，非常适合周末实验。建议收藏备用，后续有新的观测指标或复现结果，可以继续迭代完善。