SwarmWorld解析:基于Stigmergy的多智能体技术演化模拟

📅 发布时间:2026/10/9 2:46:22
SwarmWorld解析:基于Stigmergy的多智能体技术演化模拟
各位开发者朋友大家好。今天想和大家聊一个很有意思的方向多智能体社会模拟以及标题中提到的SwarmWorldStigmergic Technological Evolution in Societies of Language-Model Agents。第一次看到这个标题很多人会被两个词劝退Stigmergic和Language-Model Agents。翻译过来大致是“基于环境协作痕迹的语言模型智能体社会中的技术演化”听起来很学术但它背后其实是一个非常工程化的问题如果我们让一群大模型智能体生活在一个共享环境中它们不直接“开会”也不直接“对话”而是通过留下工件、修改公共空间、继承前人成果来协作那么这群智能体能不能像人类社会一样自发性地演化出工具、方法和分工这就是 SwarmWorld 的核心思想。本文不是什么论文复现指南而是一篇偏向架构拆解 原型实现的技术文章。我会先解释 Stigmergy 到底是什么意思然后给出一个可以扩展的 Python 原型框架把“环境痕迹”、“智能体观察”、“技术积累”这三个关键环节落到代码上。文章不依赖特定大模型厂商只要你手头有任意 OpenAI 兼容接口或者干脆没有 API Key也能跑通一套玩具版本。适合的读者对 LLM Agent 感兴趣的后端开发、算法工程师、AI 应用研究者以及想了解“多智能体协作建模”底层思路的同学。1. 背景与核心概念1.1 什么是 StigmergyStigmergy 这个词最早来源于生物学。它描述的是个体之间不直接通信而是通过修改环境来影响其他个体行为的协作机制。最经典的例子是白蚁和蚂蚁蚂蚁在觅食过程中释放信息素后续蚂蚁根据信息素浓度选择路径。各只蚂蚁之间并没有直接交流但整个蚁群却能呈现出高度有序的觅食网络。白蚁筑巢时每只白蚁只是对泥团做局部操作但泥土结构会反过来决定下一只白蚁应该怎么继续堆叠最终形成复杂的巢穴。这种机制有个非常大的优势群体不需要中央调度也不需要全局记忆只要环境本身具备“记录”能力协作就能在时间和空间上被拉开。1.2 从生物群体到语言模型智能体社会如果把 Stigmergy 迁移到 LLM Agent 场景那么每个 Agent 相当于一只“蚂蚁”。Agent 的上下文窗口相当于它的“短时记忆”。共享环境中的工件artifact相当于蚁群的“信息素”和“巢穴结构”。Agent 通过观察环境、修改环境把局部经验沉淀为群体共享的“技术遗产”。与传统 Multi-Agent 方案相比这种模式最大的不同是传统多智能体 Agent A - 直接发送消息 - Agent B SwarmWorld 风格 Agent A - 修改共享环境发布代码/文档/工具 Agent B - 在未来某个时间观察共享环境的变化 Agent C - 基于之前所有痕迹继续修改环境这样智能体之间的协作不再是一对一的瞬时通信而是变成基于环境状态传递的异步协作。1.3 为什么适合研究“技术演化”人类社会的技术演化有一个明显特征每一代人都站在前人的肩膀上。工具一旦被发明就会被保留下来供后来者使用。语言模型智能体天然擅长生成文本、代码、结构化的方案但它们大多缺少“跨代积累”的能力。你让一个 Agent 写代码它可以写但下一个 Agent 重新开始任务时往往不会参考前一个 Agent 写的工具函数。SwarmWorld 想解决的就是这个问题。它把 Agent 的输出当作“工件”写回环境环境把这些工件组织成一种可以被后续 Agent 加载和引用的“历史技术栈”。随着群体迭代次数增加积累的工件越来越复杂后出现的 Agent 只需要在此基础上做增量改进就可能产生类似“技术演化”的现象。1.4 SwarmWorld 在实践中的定位从工程角度看SwarmWorld 既是一个模拟实验框架也是一套环境设计思想。它不需要特别复杂的分布式架构最核心的部分是三个模块环境库存储所有历史工件。观察接口Agent 只能通过该接口查看环境状态。提交接口Agent 必须通过该接口把新成果写回环境。理解了这三个模块你就抓住了这篇文章后面全部代码的主线。2. 环境准备与版本说明为了让文章里的代码可以实际跑起来我先说明一套比较稳妥的本地实验环境。2.1 运行环境本文示例以常见的 Python 环境为主具体版本需要根据你的项目实际情况调整这里以我实际测试时的环境为参考组件说明操作系统Windows 10 / Ubuntu 20.04 均可Python3.10 或更高版本openai 库只需要 OpenAI 兼容接口版本按官方最新稳定版即可其他依赖no 默认不需要额外框架全部用标准库实现核心逻辑如果你没有 API Key也不用担心。本文的核心原型会提供一个EchoAgent玩具模式。在这种模式下Agent 不调用大模型而是根据已有工件模板生成“看似有进展”的返回结果。这样你可以先把流程跑通再替换成真正的大模型调用。2.2 需要安装的依赖建议先创建一个干净的虚拟环境python -m venv swarmworld_venv source swarmworld_venv/bin/activate # Windows 下为 swarmworld_venv\Scripts\activate如果你希望后面接入真实大模型再安装 openaipip install openai如果没有网络条件或者不想调用外部 API核心代码只依赖标准库直接运行即可。2.3 项目结构我建议把原型代码拆成下面几个模块。swarmworld_proto/ ├── main.py # 仿真主入口 ├── stigmergy_env.py # 环境库与 Stigmergy 管理器 ├── agent.py # 智能体抽象与 LLM 调用 ├── prompts.py # 提示词模板 ├── artifacts.py # 工件数据模型 ├── metrics.py # 技术演化指标统计 └── results/ ├── timeline.json # 演化时间线 └── artifacts_repo/ # 工件快照真实项目中建议还是按这样的结构拆开。如果只是跑通一个极简 Demo也可以把所有逻辑写进一个文件我会在后面的代码里先给极简版再讲拆模块的设计。3. 核心机制拆解Stigmergy 如何驱动技术演化3.1 工件Artifact是状态的载体在 SwarmWorld 里Agent 与 Agent 之间不直接对话。它们交互的唯一媒介是工件。一个工件可以是一段代码一个 API 接口规范一篇技术方案一个测试用例一个 bug 修复记录一个“工具定义”元数据。工件必须具有以下属性artifact_id # 全局唯一 creator_agent # 创建者 content # 主体内容 artifact_type # 类型code, doc, tool, test parent_ids # 依赖的前序工件 created_round # 创建轮次其中parent_ids至关重要。它记录了“这个工件是基于哪些历史工件生成的”。有了这个字段我们就可以画出一条技术继承链并统计某项功能在群体中经过了几次迭代。3.2 环境库群体的“集体记忆”环境库是一个持久化存储。在极简原型中我们可以用一个字典加一个列表表示self.artifacts {} self.timeline []每次 Agent 提交新工件时环境库需要执行两步操作把工件放入artifacts字典把该工件追加到timeline记录时间线。3.3 观察接口Agent 看到什么决定 Agent 想到什么在真实 SwarmWorld 实验中Agent 不可能把环境中的所有内容都塞进上下文。那样既浪费 token也会让 Agent 失去重点。所以观察接口要设计成“有选择的重建”。常见的策略有三种策略说明适用场景最近 N 个工件只看最近 N 条记录快速迭代、短周期任务关键路径工件根据目标关键词检索相关工件复杂任务、阶段性演化父链完整回溯从当前最尖端工件逐级向上回溯技术深度继承实验我个人推荐第三种。因为 Stigmergy 的核心并不是“看到很多人做了什么”而是“看到之前和你同一条技术脉络的人做了什么”。在极简原型中我会把观察接口设计为接收一个query返回按时间排序的最近 K 条相关工件摘要。3.4 提交接口产生新成果并写回环境Agent 完成一次思考之后会产生两类输出显式任务输出比如一段新代码元信息比如这段代码解决的问题、依赖的前序工件编号。提交接口会把这些信息合并成一个新的 Artifact。同时为了让群体能逐渐形成“工具演化”我建议每轮提交都让 Agent 显式声明自己是否创造了“可复用工具”或者“技术分支”。3.5 技术演化信号是什么在写代码之前需要先明确怎么判断“技术演化发生了”。如果一个群体只是每次生成一堆无关文档那只能叫“内容堆积”不是“演化”。演化应该具有以下信号工具复用率上升后出现的 Agent 倾向于直接调用历史工具而不是重新实现工件链变深新工件的parent_ids数量逐渐增多技术分层出现“基础工具层”和“应用层”两类工件发展阶段跃迁群体从“认识阶段”进入“工具制造阶段”再进入“抽象抽象阶段”。这些信号会在第 6 节转化为可计算的指标。4. 完整实战案例SwarmWorld 原型实现接下来我们进入代码环节。我会先给出一个极简但可运行的版本然后说明如何接入真实 LLM。4.1 创建项目结构我们先使用命令行创建代码目录mkdir swarmworld_proto cd swarmworld_proto touch main.py如果你更习惯直接在 IDE 里创建也没有问题。下面所有代码都以swarmworld_proto/main.py为路径。4.2 核心数据模型在main.py里先定义 Artifact 数据模型。为了让新手更容易理解这里不去引入 Pydantic直接用 dataclass。# 文件路径swarmworld_proto/main.py from dataclasses import dataclass, field from typing import List, Dict, Optional dataclass class Artifact: artifact_id: str creator_agent: str content: str artifact_type: str # code / doc / tool / test parent_ids: List[str] field(default_factorylist) created_round: int 0 def to_summary(self) - str: return ( f[{self.artifact_type}] {self.artifact_id} fby {self.creator_agent} | {self.content[:120]} )这个数据结构是整个环境库的基础。to_summary()方法用于生成观察摘要控制发送给 LLM 的 token 长度。4.3 Stigmergy 环境管理器接下来实现环境库这个类负责存储工件、观察、提交。# 继续写在 main.py class StigmergyEnv: Stigmergy 环境管理器。 环境就是群体的集体记忆。 Agent 之间不直接通信所有协作都通过环境基成的工件完成。 def __init__(self) - None: self.artifacts: Dict[str, Artifact] {} self.timeline: List[str] [] self.round_counter: int 0 def submit_artifact( self, creator_agent: str, content: str, artifact_type: str, parent_ids: Optional[List[str]] None, ) - Artifact: self.round_counter 1 artifact_id fart_{self.round_counter:04d} artifact Artifact( artifact_idartifact_id, creator_agentcreator_agent, contentcontent, artifact_typeartifact_type, parent_idsparent_ids or [], created_roundself.round_counter, ) self.artifacts[artifact_id] artifact self.timeline.append(artifact_id) return artifact def observe_recent(self, k: int 5) - str: 直接返回最近 k 个工件的合并摘要。 recent_ids self.timeline[-k:] parts [self.artifacts[a].to_summary() for a in recent_ids] return \n.join(parts) def trace_parents(self, artifact_id: str) - List[Artifact]: 深度优先回溯一个工件的父链。 这是判断技术继承深度的核心方法。 chain [] visited set() def dfs(cur_id: str) - None: if cur_id in visited or cur_id not in self.artifacts: return visited.add(cur_id) cur self.artifacts[cur_id] chain.append(cur) for pid in cur.parent_ids: dfs(pid) dfs(artifact_id) return chain这里我做了几个关键设计observe_recent()是简化版观察接口适合数据量小的试验trace_parents()是技术继承链追溯接口可以用于分析“群体是否在已有成果上继续生长”。4.4 Agent 抽象层Agent 是仿真中的行动主体。为了后续扩展我把它设计成一个类。# 继续写在 main.py class BaseAgent: 所有 Agent 的基类。 子类需要实现 think_and_act() 方法。 该方法接收环境观察结果返回一个新工件元组 (content, artifact_type, parent_ids) def __init__(self, agent_id: str, system_prompt: str) - None: self.agent_id agent_id self.system_prompt system_prompt def think_and_act( self, env: StigmergyEnv, observation: str, recent_works: List[Artifact], ) - tuple: raise NotImplementedError在这个基类中recent_works是可选参数方便后续实现更复杂的检索逻辑。4.5 玩具模式EchoAgent很多读者可能没有配置大模型 API 的环境。为了让大家能先跑通流程我实现一个EchoAgent。它在收到环境观察后会从recent_works中抽取最后一个代码类工件并产生一个“新版本”的代码片段。# 继续写在 main.py class EchoAgent(BaseAgent): 玩具 Agent不调用任何大模型。 它的行为是如果环境里有代码类工件就基于最新的代码做一次“假装升级” 如果环境里没有代码就输入一段最基础的工具函数。 def think_and_act( self, env: StigmergyEnv, observation: str, recent_works: List[Artifact], ) - tuple: code_works [a for a in recent_works if a.artifact_type in (code, tool)] if code_works: base code_works[-1] parent_ids [base.artifact_id] content ( f# 基于 {base.artifact_id} 的增强版本\n f# 新增功能输入校验与容错处理\n fdef enhanced_util(data):\n f if not data:\n f return []\n f return [x * 2 for x in data if isinstance(x, int)]\n ) return content, code, parent_ids else: content ( # 基础工具函数\n def base_util(data):\n return list(data)\n ) return content, tool, []注意EchoAgent不是一个“智能” Agent它只是用来验证环境机制本身的流程是否正确。真实实验中应替换为真实的 LLM Agent。4.6 真实 LLM Agent 接入思路如果你有 OpenAI或任意兼容接口的 API Key可以这样写一个真实 Agent。# 继续写在 main.py接入时去掉注释即可 class LLMAgent(BaseAgent): 真实 LLM Agent。 使用 OpenAI 兼容接口。 你可以把 base_url 换成任意兼容网关。 def __init__( self, agent_id: str, system_prompt: str, model: str, api_key: str, base_url: Optional[str] None, ) - None: super().__init__(agent_id, system_prompt) self.model model from openai import OpenAI kwargs {api_key: api_key} if base_url: kwargs[base_url] base_url self.client OpenAI(**kwargs) def think_and_act( self, env: StigmergyEnv, observation: str, recent_works: List[Artifact], ) - tuple: history [a.to_summary() for a in recent_works] history_text \n.join(history) if history else 暂无历史成果 user_prompt f当前环境中已有的相关工件如下 {history_text} 请基于这些已有成果继续推进技术演化。你需要返回以下内容 1. 新成果的内容 2. 成果类型code / doc / tool / test 3. 依赖的工件 ID 列表 4. 一段简短说明。 请严格按照 JSON 格式输出。 resp self.client.chat.completions.create( modelself.model, messages[ {role: system, content: self.system_prompt}, {role: user, content: user_prompt}, ], temperature0.7, ) raw resp.choices[0].message.content # 这里建议用 json.loads 解析并做异常处理。 # 为了保持示例简洁先返回一个默认结构。 import json try: parsed json.loads(raw.replace(json, ).replace(, ).strip()) content parsed[content] artifact_type parsed[artifact_type] parent_ids parsed[parent_ids] except Exception: content raw artifact_type doc parent_ids [] return content, artifact_type, parent_ids真实项目中你需要做几个额外处理把所有 输出强制为合法 JSON对parent_ids做存在性检查防止 Agent 引用不存在的工件对超长输出做截断记录 token 消耗避免成本失控。4.7 仿真主循环现在把环境、Agent、观察、提交串起来。# 继续写在 main.py def run_swarmworld( agent: BaseAgent, num_rounds: int 10, observe_k: int 3, ): env StigmergyEnv() for round_idx in range(1, num_rounds 1): # 1. Agent 观察环境 observation env.observe_recent(kobserve_k) # 2. 获取候选历史成果 recent_works [] for aid in env.timeline[-observe_k:]: recent_works.append(env.artifacts[aid]) # 3. Agent 根据观察产生新工件 content, artifact_type, parent_ids agent.think_and_act( env, observation, recent_works, ) # 4. 写回环境形成新的群体记忆 artifact env.submit_artifact( creator_agentagent.agent_id, contentcontent, artifact_typeartifact_type, parent_idsparent_ids, ) # 5. 简单控制台输出 print(fRound {round_idx:02d} | {artifact.artifact_id} f| {artifact_type} | parent{parent_ids}) return env这个循环非常简单但它已经具备了 SwarmWorld 最基本的三个环节观察环境 - 决策生成 - 提交环境4.8 运行与验证在main.py末尾添加运行入口if __name__ __main__: echo_agent EchoAgent( agent_idecho_agent_01, system_prompt你是群体中的技术贡献者。, ) env run_swarmworld( agentecho_agent, num_rounds8, observe_k3, ) print(\n 时间线摘要 ) for aid in env.timeline: a env.artifacts[aid] print(f{a.artifact_id} | 类型{a.artifact_type} | f创建者{a.creator_agent} | 内容长度{len(a.content)})直接运行python main.py预期输出大致如下Round 01 | art_0001 | tool | parent[] Round 02 | art_0002 | code | parent[art_0001] Round 03 | art_0003 | code | parent[art_0002] ...你会发现parent链从空逐步变成单元素这说明环境在“记住”前序成果后续 Agent 真的在继承前序代码。4.9 多 Agent 环境下的 Stigmergy上面的极简版只有一个 Agent虽然能验证继承机制但还谈不上“社会”。我们把它扩展成多个 Agent 轮流行动。# 继续写在 main.py def run_swarmworld_multi_agents( agents: List[BaseAgent], num_rounds: int 12, observe_k: int 4, ): env StigmergyEnv() for round_idx in range(1, num_rounds 1): agent agents[round_idx % len(agents)] recent_works [] for aid in env.timeline[-observe_k:]: recent_works.append(env.artifacts[aid]) observation env.observe_recent(kobserve_k) content, artifact_type, parent_ids agent.think_and_act( env, observation, recent_works, ) artifact env.submit_artifact( creator_agentagent.agent_id, contentcontent, artifact_typeartifact_type, parent_idsparent_ids, ) print(fRound {round_idx:02d} | {agent.agent_id} f| {artifact.artifact_id} | parent{parent_ids}) return env运行多 Agent 版if __name__ __main__: agents [ EchoAgent(alice, 你擅长基础函数设计。), EchoAgent(bob, 你擅长功能增强。), ] env run_swarmworld_multi_agents(agents, num_rounds10)这里虽然EchoAgent本身只会做简单的“基于最新代码复制增强”但配合多个 Agent 轮流提交已经可以看出来“之前 Agent 的工作会影响当前 Agent 的输入”。这就已经是 Stigmergy 的最简实现。5. 技术演化指标与观察方法跑通模拟之后我们需要回答一个问题这种群体协作是否真的产生了技术演化下面是四个可落地的指标。5.1 继承深度对于每个工件计算出它的父链长度。# 新增 metrics.py 或直接写在 main.py def compute_inheritance_depth(env: StigmergyEnv, artifact_id: str) - int: chain env.trace_parents(artifact_id) return len(chain) def avg_inheritance_depth(env: StigmergyEnv, limit: int 20) - float: aids env.timeline[-limit:] if not aids: return 0.0 depths [len(env.trace_parents(aid)) for aid in aids] return sum(depths) / len(depths)继承深度越大说明后出现的 Agent 越是在前人成果上继续迭代。5.2 工具复用率统计一段时间内新提交的工件中直接以历史工具为父节点的比例。def compute_tool_reuse_rate(env: StigmergyEnv, recent_n: int 20) - float: aids env.timeline[-recent_n:] if not aids: return 0.0 reused 0 for aid in aids: art env.artifacts[aid] parents art.parent_ids if not parents: continue # 只要有一个父节点是工具就认为发生了复用 if any(env.artifacts[p].artifact_type tool for p in parents): reused 1 return reused / len(aids)5.3 工件类型复杂度统计不同类型的工件分布。通常一个健康的演化群里会出现从doc到tool到code再到test的类型扩展。from collections import Counter def artifact_type_distribution(env: StigmergyEnv) - Dict[str, int]: return Counter(a.artifact_type for a in env.artifacts.values())5.4 阶段性跃迁检测更复杂的实验会定义“技术阶段”。简单来说阶段 1只有文档没有可执行工具阶段 2出现工具阶段 3出现基于工具复合而成的更复杂 code阶段 4出现测试与其他辅助结构。检测方式可以是def detect_technology_stage(env: StigmergyEnv) - int: types set(a.artifact_type for a in env.artifacts.values()) if test in types: return 4 if code in types and tool in types: return 3 if tool in types: return 2 if doc in types: return 1 return 0这个函数虽然简单但足够作为原型试验里的“阶段信号”。6. 常见问题与排查思路在多智能体模拟项目中最常见的问题往往不是模型能力不足而是环境设计不完整。下面我整理了一张排查清单。问题现象常见原因解决思路Agent 每轮输出完全独立和环境历史无关观察接口没有把历史工件传给提示词检查observe_recent返回内容是否被拼接到 user prompt生成结果存在大量重复上下文只看到相似类型的工件没有新信息增加父链回溯或增加工件多样性上下文长度快速超限观察接口直接追加大量完整内容改用to_summary()摘要并限制数量Agent 在 JSON 输出时不合法大模型返回了 Markdown 代码块增加json.loads容错处理成本失控每轮都调用长上下文模型引入 token 统计和最大调用次数限制工件父链出现断裂Agent 引用了不存在的 artifact_id在submit_artifact里做存在性校验群体表现停滞不演化所有 Agent 共享同一个强身份缺少多样性给不同 Agent 不同角色定位其中父链断裂是我在实际模拟中最常遇到的问题。大模型会非常自然地“幻想”出一些不存在的工件编号比如art_0001实际不存在但它依然引用。这会导致后续分析全部失真。解决方法其实很简单在提交时做一次校验def _validate_parent_ids(self, parent_ids: List[str]) - List[str]: valid [] for pid in parent_ids: if pid in self.artifacts: valid.append(pid) return valid然后在submit_artifact中调用这个方法忽略无效父节点。7. 最佳实践与工程建议7.1 环境记忆必须做版本快照Stigmergy 机制的最大优势是“环境即记忆”但这也带来一个风险环境状态被修改后旧状态丢失。在真实项目中不要直接覆盖content。应该为每个工件保留历史版本列表artifact.versions.append(artifact.content)这样你可以事后回放群体的技术演化轨迹而不是只看最后一个状态。7.2 观察与行动分离Agent 的“观察”和“行动”应该完全分离。不要让 Agent 直接读写字典而是通过接口调用。这样做的好处是可以统计每次观察消耗了多少 token可以在观察时做干预可以审计 Agent 到底看到了什么。7.3 给 Agent 分工研究技术演化Agent 如果同质化太严重群体很难出现多样性和分工。建议至少区分三类 Agent基础工具型 Agent负责开发通用函数、算法工具应用型 Agent负责把工具组合成完整业务逻辑质量型 Agent负责测试、审查、文档化。这样更接近人类社会“发明家 工程师 质量保障”的分工结构。7.4 安全与成本边界多智能体社会模拟有两大现实风险。成本风险每一次 Agent 决策都可能消耗大量 token。建议在仿真循环里加入 token 统计。used_tokens resp.usage.total_tokens不可控输出风险多个 Agent 共享环境后恶意或错误的输出可能被后续 Agent 当作“正确经验”继续复用。因此对提交内容做敏感信息过滤对代码类工件做静态语法检查对“执行类”Agent 做到最小权限不给真实系统操作权限在涉及生产环境或真实数据时先通过测试环境验证再考虑放到模拟实验之外使用。这一点很重要。模拟环境里的“演化成果”不等于真实可靠代码任何对外使用都必须经过人工审查和测试。7.5 记录每一次决策建议在环境库中增加一个decision_log结构self.decision_log [] # 每条记录包含 # agent_id, observation_summary_id, chosen_parents, final_artifact_id有了决策日志你才能事后分析某个 Agent 到底参考了哪些历史成果这也是判断 Stigmergy 机制是否真正生效的关键证据。8. 总结与下一步学习方向本文从一个偏学术的标题出发拆解了 SwarmWorld 背后的核心机制Stigmergy 是一种通过环境状态间接协作的机制语言模型智能体可以通过“观察 - 提交工件 - 修改环境 - 被后续者观察”的方式形成群体技术积累技术演化可以用继承深度、工具复用率、工件类型分布和阶段跃迁来量化。在代码层面我们实现了一个极简的 Python 原型包括环境库StigmergyEnvAgent 抽象层玩具模式和真实 LLM 模式多 Agent 轮流协作的仿真循环技术演化指标计算函数。如果你对这个方向感兴趣下一步可以尝试这几个方向引入检索增强让 Agent 不只看到最近 K 个工件而是按任务目标检索历史工具引入环境干预比如人工“淘汰”某些技术路线观察群体是否转向新路线接入更多真实任务比如让 Agent 群体共同解决 LeetCode 风格题目或者设计小型网页应用以此验证“群体技术演化能否提升任务完成质量”可视化分析把 artifact 的父链关系画成树状图你能直观看到技术分支如何形成。这个方向的最大魅力在于它把“大模型能力”和“社会协作机制”结合在了一起。单个 Agent 的能力上限也许不会改变但当它们通过环境痕迹相互连接时群体表现是否会产生超线性增长这是一个非常值得实验的问题。如果本文对你有帮助可以收藏备用也欢迎在评论区分享你的实验结果。下一篇可以继续聊“如何把 SwarmWorld 接入真实代码仓库环境”或者在本地搭建一套可视化实验台。我们下期见。