多智能体 LLM 交互过程中智能体之间会不会自发形成只有自己人才听得懂的“暗号”GlossoGen 这个研究方向讨论的正是这种涌现语言问题。它不是某个能直接下载的一键包而是一个偏学术、偏实验的项目方向在多智能体协作任务中LLM 是否会自动发明术语、缩写、特殊表达用来代替完整自然语言从而提升通信效率。本文会把这个方向的背景、核心机制、实验设计思路讲清楚并给出一套可运行的最小复现框架。如果你关注 LLM Agent、多智能体协同、涌现行为分析这篇文章可以当作一个实验起点。先说重点。GlossoGen 这个项目方向包含三个核心词Glosso与语言相关、Gen生成、Emergent Language涌现语言。它研究的是多个 LLM 在复杂交互中如何从自然语言对话演进出一种更高效、更结构化的通信协议。对于普通开发者来说最直接的价值是理解多 Agent 系统中的通信冗余问题并学会用实验手段观察 token 消耗变化、协作成功率、特殊术语出现频率等指标。本文会从环境准备、最小实验系统搭建、效果验证、性能观察、常见排错等几个维度展开帮助你把“涌现语言”从一个抽象概念变成可量化的实验项目。1. 核心能力速览GlossoGen 并不是一个可以直接安装的软件包更像是一个研究课题或技术框架的名称。从公开资料看它围绕多智能体 LLM 交互中的语言涌现现象提供了一套分析和实验思路。下面的表格基于行业通用认知整理实际参数需要根据你所用的 LLM 模型和实验代码来确认。能力项说明项目类型学术研究方向 / 实验框架核心对象多智能体 LLM 交互中的涌现语言主要功能观察、度量和分析多个 LLM Agent 间产生的专用术语、缩写、结构化通信方式依赖基础任意可调用的 LLM API 或本地推理引擎需要支持多轮对话推荐硬件CPU 可跑通小规模实验大规模批量化建议使用带 GPU 的推理服务或云端 API显存需求取决于选用模型的规模7B 以下模型显存占用约 6-10 GB需以实际模型为准支持平台Windows / Linux / macOS只要能运行 Python 环境即可启动方式脚本启动通过调用 LLM 接口发起多 Agent 对话接口能力取决于底层 LLM 服务常见为 OpenAI 兼容接口或本地推理服务批量任务支持通过循环、异步队列等方式批量跑实验需自行编写调度逻辑适合人群对 LLM Agent、多智能体协作、涌现行为感兴趣的开发者与研究者这张表里列出的“显存占用”“启动方式”等都强调“需以实际模型为准”。原因是 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在准备环境前先把三个基础概念串一遍。LLMLarge 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。下面是一份通用清单不绑定具体版本。项目建议操作系统Windows 10/11、Ubuntu 20.04、macOS 12Python3.9 以上推荐 3.10 / 3.11依赖库openai、anthropic、requests、PyYAML、pandas、matplotlibLLM 访问方式OpenAI 兼容 API、Anthropic API、本地 vLLM / Ollama 服务网络能访问到模型 API 服务或本机已启动推理服务磁盘空间至少 500 MB 以上日志和结果文件如果使用本地模型按模型体积另行准备端口如果需要启动本地 API 服务注意不要和其他服务冲突在安装依赖时建议用虚拟环境隔离避免把系统环境搞乱。# 创建虚拟环境假设你在项目目录下 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_keyyour-api-key, base_urlhttps://api.example.com/v1 # 如果使用兼容接口替换为实际地址 ) def call_llm(messages, temperature0.0): 调用 LLM返回回复内容和 token 使用情况 resp client.chat.completions.create( modelyour-model-name, # 替换为实际模型名 messagesmessages, temperaturetemperature, ) content resp.choices[0].message.content usage resp.usage return content, usage def run_cooperation_round(task_description, historyNone): 运行一轮 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轮次 {i1}: 摘要长度 {len(summary)} 字符SQL长度 {len(sql)} 字符总token数 {total_tokens})这个模板会让人直观看到随着任务越来越复杂摘要长度和 SQL 长度反而可能趋于稳定因为 Agent A 会不断调整自己的“摘要风格”逐渐形成一套更精炼的表述。如果出现固定的短语如“A30 注册后 订单超千”那就是涌现语言的雏形。注意上面的openai库版本和 API 参数需要根据实际接口调整。如果你使用的是 Anthropic API则用对应 SDK。6. 实验设计与效果验证只跑一轮没有意义要通过多轮、多组、多指标的实验来验证涌现语言是否存在。建议按照下面的流程设计。6.1 定义观测指标至少记录四类指标。指标含义数值方向平均消息长度Agent 交互中每条消息的 token 或字符数如果出现涌现语言可能先下降后稳定特殊术语出现频率某些固定缩写或短语的出现次数上升说明有语言进化协作成功率最终输出是否能正确完成目标任务稳定或上升才说明涌现有价值语义相似度摘要是否仍然很好地覆盖原任务意图应该保持在较高水平6.2 多组对照实验至少设置三组。组1两个 Agent 使用系统提示词明确要求“表达尽量简洁”观察是否快速形成协议。组2两个 Agent 没有简洁要求按默认方式工作观察是否自然涌现。组3使用不同 LLM 模型如一个强模型、一个弱模型观察语言涌现差异。每组固定相同任务集跑 30 到 50 轮记录指标最后画折线图。6.3 判断涌现语言的标准符合下面任意两条就可以说观测到了涌现语言在任务语义不变或变化较小的前提下Agent 间的消息长度随时间显著下降。出现了不在系统提示词中定义的新词、缩写、编码方式且被另一个 Agent 正确理解并使用。去掉这些新词后协作成功率明显下降说明它们承载了信息。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, encodingutf-8) as f: return yaml.safe_load(f) def run_batch(cfg): os.makedirs(cfg[experiment][output_dir], exist_okTrue) with open(cfg[experiment][tasks_file], r, encodingutf-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, encodingutf-8) as f: f.write(json.dumps(data, ensure_asciiFalse) \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_retries3, delay2): 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(fRequest failed: {e}, retry {attempt1}/{max_retries}) if attempt max_retries - 1: raise time.sleep(delay * (attempt 1)) return wrapper return decorator retry() def call_llm_safe(messages): # 实际调用代码 pass7.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. 常见问题与排查方法问题现象可能原因排查方式解决方案API 返回 AuthenticationErrorAPI key 无效或权限不足检查 key 是否正确确认拥有模型访问权限重新生成 key或在环境变量中正确配置请求超时API 服务繁忙或网络延迟高查看日志中的 timeout 时间用 curl 测试连通性增加超时时间加入重试机制或更换网络环境上下文长度超出限制历史消息累积过多检查 total_tokens 与模型 context_window 对比裁剪历史只保留最近几轮或把历史压缩成摘要两个 Agent 无法互相理解双方没有共享上下文或各自使用了不同 prompt 前缀检查输出日志看 Agent B 是否在 Agent A 的消息前加了无关内容统一上下文在 system prompt 中约定通信格式没有出现涌现语言任务过于简单Agent 不需要压缩表达增加任务复杂度或让任务序列具有重复模式使用更复杂的连续任务观察更长轮次显存不足本地模型过大或 batch 过大用 nvidia-smi 查看显存使用换量化模型降低 context length减小 batch输出质量不稳定temperature 过高或模型随机性大记录多个 run 的成功率降低 temperature 到 0或用稳定版本模型批量实验卡住某个 API 请求被限流没有重试查看日志是否有 429 状态码加入随机退避重试或降低并发数出现问题时先不要改代码把日志多打几行。建议记录每轮调用的请求体、响应体、消耗 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 就能完成。整套代码控制在两百行左右非常适合周末实验。建议收藏备用后续有新的观测指标或复现结果可以继续迭代完善。