企业官网建设流程全解析

各位开发者朋友，大家好。

今天想和大家聊一个很有意思的方向：多智能体社会模拟，以及标题中提到的SwarmWorld：Stigmergic Technological Evolution in Societies of Language-Model Agents。

第一次看到这个标题，很多人会被两个词劝退：Stigmergic和Language-Model Agents。翻译过来大致是“基于环境协作痕迹的语言模型智能体社会中的技术演化”，听起来很学术，但它背后其实是一个非常工程化的问题：

如果我们让一群大模型智能体生活在一个共享环境中，它们不直接“开会”，也不直接“对话”，而是通过留下工件、修改公共空间、继承前人成果来协作，那么这群智能体能不能像人类社会一样自发性地演化出工具、方法和分工？

这就是 SwarmWorld 的核心思想。

本文不是什么论文复现指南，而是一篇偏向架构拆解 + 原型实现的技术文章。我会先解释 Stigmergy 到底是什么意思，然后给出一个可以扩展的 Python 原型框架，把“环境痕迹”、“智能体观察”、“技术积累”这三个关键环节落到代码上。文章不依赖特定大模型厂商，只要你手头有任意 OpenAI 兼容接口，或者干脆没有 API Key，也能跑通一套玩具版本。

适合的读者：对 LLM Agent 感兴趣的后端开发、算法工程师、AI 应用研究者，以及想了解“多智能体协作建模”底层思路的同学。

1. 背景与核心概念

1.1 什么是 Stigmergy

Stigmergy 这个词最早来源于生物学。它描述的是个体之间不直接通信，而是通过修改环境来影响其他个体行为的协作机制。

最经典的例子是白蚁和蚂蚁：

• 蚂蚁在觅食过程中释放信息素，后续蚂蚁根据信息素浓度选择路径。
• 各只蚂蚁之间并没有直接交流，但整个蚁群却能呈现出高度有序的觅食网络。
• 白蚁筑巢时，每只白蚁只是对泥团做局部操作，但泥土结构会反过来决定下一只白蚁应该怎么继续堆叠，最终形成复杂的巢穴。

这种机制有个非常大的优势：群体不需要中央调度，也不需要全局记忆，只要环境本身具备“记录”能力，协作就能在时间和空间上被拉开。

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 既是一个模拟实验框架，也是一套环境设计思想。它不需要特别复杂的分布式架构，最核心的部分是三个模块：

1. 环境库：存储所有历史工件。
2. 观察接口：Agent 只能通过该接口查看环境状态。
3. 提交接口：Agent 必须通过该接口把新成果写回环境。

理解了这三个模块，你就抓住了这篇文章后面全部代码的主线。

2. 环境准备与版本说明

为了让文章里的代码可以实际跑起来，我先说明一套比较稳妥的本地实验环境。

2.1 运行环境

本文示例以常见的 Python 环境为主，具体版本需要根据你的项目实际情况调整，这里以我实际测试时的环境为参考：

如果你没有 API Key，也不用担心。本文的核心原型会提供一个EchoAgent玩具模式。在这种模式下，Agent 不调用大模型，而是根据已有工件模板生成“看似有进展”的返回结果。这样你可以先把流程跑通，再替换成真正的大模型调用。

2.2 需要安装的依赖

建议先创建一个干净的虚拟环境：

python -m venv swarmworld_venv source swarmworld_venv/bin/activate # Windows 下为 swarmworld_venv\Scripts\activate

如果你希望后面接入真实大模型，再安装 openai：

pip 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 提交新工件时，环境库需要执行两步操作：

1. 把工件放入artifacts字典；
2. 把该工件追加到timeline，记录时间线。

3.3 观察接口：Agent 看到什么决定 Agent 想到什么

在真实 SwarmWorld 实验中，Agent 不可能把环境中的所有内容都塞进上下文。那样既浪费 token，也会让 Agent 失去重点。

所以观察接口要设计成“有选择的重建”。常见的策略有三种：

我个人推荐第三种。因为 Stigmergy 的核心并不是“看到很多人做了什么”，而是“看到之前和你同一条技术脉络的人做了什么”。

在极简原型中，我会把观察接口设计为接收一个query，返回按时间排序的最近 K 条相关工件摘要。

3.4 提交接口：产生新成果并写回环境

Agent 完成一次思考之后，会产生两类输出：

1. 显式任务输出，比如一段新代码；
2. 元信息，比如这段代码解决的问题、依赖的前序工件编号。

提交接口会把这些信息合并成一个新的 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_factory=list) created_round: int = 0 def to_summary(self) -> str: return ( f"[{self.artifact_type}] {self.artifact_id} " f"by {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 = f"art_{self.round_counter:04d}" artifact = Artifact( artifact_id=artifact_id, creator_agent=creator_agent, content=content, artifact_type=artifact_type, parent_ids=parent_ids or [], created_round=self.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

这里我做了几个关键设计：

1. observe_recent()是简化版观察接口，适合数据量小的试验；
2. 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" f"def 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( model=self.model, messages=[ {"role": "system", "content": self.system_prompt}, {"role": "user", "content": user_prompt}, ], temperature=0.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

真实项目中，你需要做几个额外处理：

1. 把所有 输出强制为合法 JSON；
2. 对parent_ids做存在性检查，防止 Agent 引用不存在的工件；
3. 对超长输出做截断；
4. 记录 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(k=observe_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_agent=agent.agent_id, content=content, artifact_type=artifact_type, parent_ids=parent_ids, ) # 5. 简单控制台输出 print(f"Round {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_id="echo_agent_01", system_prompt="你是群体中的技术贡献者。", ) env = run_swarmworld( agent=echo_agent, num_rounds=8, observe_k=3, ) 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(k=observe_k) content, artifact_type, parent_ids = agent.think_and_act( env, observation, recent_works, ) artifact = env.submit_artifact( creator_agent=agent.agent_id, content=content, artifact_type=artifact_type, parent_ids=parent_ids, ) print(f"Round {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_rounds=10)

这里虽然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. 常见问题与排查思路

在多智能体模拟项目中，最常见的问题往往不是模型能力不足，而是环境设计不完整。下面我整理了一张排查清单。

其中，父链断裂是我在实际模拟中最常遇到的问题。大模型会非常自然地“幻想”出一些不存在的工件编号，比如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 原型，包括：

• 环境库StigmergyEnv；
• Agent 抽象层；
• 玩具模式和真实 LLM 模式；
• 多 Agent 轮流协作的仿真循环；
• 技术演化指标计算函数。

如果你对这个方向感兴趣，下一步可以尝试这几个方向：

1. 引入检索增强，让 Agent 不只看到最近 K 个工件，而是按任务目标检索历史工具；
2. 引入环境干预，比如人工“淘汰”某些技术路线，观察群体是否转向新路线；
3. 接入更多真实任务，比如让 Agent 群体共同解决 LeetCode 风格题目，或者设计小型网页应用，以此验证“群体技术演化能否提升任务完成质量”；
4. 可视化分析，把 artifact 的父链关系画成树状图，你能直观看到技术分支如何形成。

这个方向的最大魅力在于，它把“大模型能力”和“社会协作机制”结合在了一起。单个 Agent 的能力上限也许不会改变，但当它们通过环境痕迹相互连接时，群体表现是否会产生超线性增长，这是一个非常值得实验的问题。

如果本文对你有帮助，可以收藏备用，也欢迎在评论区分享你的实验结果。下一篇可以继续聊“如何把 SwarmWorld 接入真实代码仓库环境”，或者在本地搭建一套可视化实验台。我们下期见。