斯坦福小镇实验:25 个 AI Agent Harness Engineering 的社会互动启示
生成式代理是指以大语言模型为核心驱动,拥有记忆、反思、规划能力,可以自主感知环境、做出决策、与其他代理/环境互动的AI实体,和传统的规则驱动NPC最大的区别是:生成式代理的行为不是预设的,而是基于自身记忆和当前环境动态生成的,具备高度的灵活性和不可预测性。
斯坦福小镇实验深度拆解:25个AI Agent背后的Harness Engineering社会互动启示
引言
2023年4月,斯坦福大学与谷歌研究院联合发布的《Generative Agents: Interactive Simulacra of Human Behavior》论文刷爆了全球技术圈:研究人员在一个像素风格的虚拟小镇「Smallville」中放入了25个由大模型驱动的AI代理(Generative Agent),这些代理拥有独立的身份、记忆、性格和目标,完全自主地在小镇中生活:他们会按时上班、去咖啡馆喝咖啡、和邻居闲聊传播八卦、自发组织情人节派对、甚至会因为共同的兴趣成为朋友、约会闹别扭。短短一周的模拟运行中,25个AI代理涌现出了几乎和人类社会别无二致的社会互动行为,甚至出现了没有提前预设的自组织群体活动。
很多人把这个实验当成一个好玩的AI玩具,但对于深耕多代理系统的工程师而言,斯坦福小镇的核心价值远不止于此:它第一次在可控的实验环境下,验证了生成式AI代理可以模拟出高度逼真的人类社会互动逻辑,更为当前炙手可热的Agent Harness Engineering(代理管控工程) 提供了可落地的社会层面启示。所谓Harness Engineering,指的是在保留AI代理自主性的前提下,对代理的行为、互动、群体目标进行管控、编排、对齐的工程体系,是解决当前多代理系统普遍存在的「目标偏离、沟通低效、行为失控、价值对齐难」等痛点的核心技术。
本文将深度拆解斯坦福小镇实验的底层架构、社会互动机制,结合工程实践提炼出可复用的Harness Engineering设计原则,带你从零理解多代理系统管控的核心逻辑,以及如何把这些启示落地到实际的多代理项目中。
一、基础概念与实验背景
1.1 核心概念定义
(1)生成式代理(Generative Agent)
生成式代理是指以大语言模型为核心驱动,拥有记忆、反思、规划能力,可以自主感知环境、做出决策、与其他代理/环境互动的AI实体,和传统的规则驱动NPC最大的区别是:生成式代理的行为不是预设的,而是基于自身记忆和当前环境动态生成的,具备高度的灵活性和不可预测性。
(2)Agent Harness Engineering
Agent Harness Engineering(代理管控工程)是面向多代理系统的工程体系,核心目标是「在保留代理自主性的前提下,将代理群体的行为约束在安全、合规、符合目标的边界内,同时最大化群体协作效率」,核心由四大模块组成:记忆管控模块、规则编排模块、价值对齐模块、分级干预模块。
(3)多代理社会互动
指多个代理之间通过信息传递、资源交换、协作竞争等方式产生的动态交互行为,核心要素包括:信息传播机制、关系演化机制、群体决策机制、自组织行为涌现机制。
1.2 实验背景与设计
斯坦福小镇实验的核心目标是验证「生成式代理是否可以模拟出逼真的人类社会行为」,实验的整体设计如下:
| 实验要素 | 具体说明 |
|---|---|
| 虚拟环境 | 像素风格的小镇,包含住宅、咖啡馆、学校、医院、超市、公园等16个场景,每个场景有对应的功能边界 |
| 代理数量 | 25个,每个代理有独立的身份、职业、性格、初始记忆、生活目标,比如:大学教授John、学生Alice、咖啡馆老板Tom、医生Maria等 |
| 运行规则 | 每个代理每分钟感知一次环境,自主生成行为决策,实验全程没有人工干预代理的行为,仅在初始阶段给每个代理植入基础的身份记忆 |
| 运行周期 | 连续运行7天(虚拟时间),对应真实世界的约48小时大模型调用时间 |
实验过程中观察到的代表性社会互动现象包括:
- 信息自发传播:研究人员给其中一个代理植入「2月14日下午在公园举办情人节派对」的记忆,一周后有12个代理知道了这个消息,其中8个主动到场参加;
- 关系演化:两个喜欢画画的代理在公园偶遇后多次主动约着一起画画,成为了朋友;
- 自组织协作:小镇的居民自发组织了一次镇长选举,有3个代理主动参选,最终有18个代理参与了投票;
- 冲突与和解:两个学生因为作业问题发生争执,冷战了2天后主动道歉和解。
二、斯坦福小镇代理核心架构原理解析
2.1 代理三层核心架构
斯坦福小镇的代理采用了经典的「记忆流-反思-规划」三层架构,这个架构也是当前绝大多数生成式代理的底层设计范式,架构图如下:
(1)记忆流(Memory Stream)
记忆流是代理所有经验的存储库,存储了代理从创建开始所有的感知信息,包括:自身的行为、和其他代理的对话、观察到的环境变化等,每条记忆都附带三个属性:
- 时间戳:记录记忆生成的时间;
- 重要性得分:代理自主给记忆打的分数(1-10分),比如「自己的生日」是10分,「路过看到一个陌生人」是1分;
- 嵌入向量:记忆内容的大模型向量表示,用于语义相似度匹配。
记忆召回的核心公式来自论文原文,用于计算每条记忆和当前查询的匹配权重:
smem=α⋅recency(mem)+β⋅importance(mem)+γ⋅relevance(mem,query)s_{mem} = \alpha \cdot recency(mem) + \beta \cdot importance(mem) + \gamma \cdot relevance(mem, query)smem=α⋅recency(mem)+β⋅importance(mem)+γ⋅relevance(mem,query)
其中:
- recency(mem)recency(mem)recency(mem)是时间衰减因子,记忆生成的时间越近值越高,遵循指数衰减规律,半衰期默认设为12小时;
- importance(mem)importance(mem)importance(mem)是记忆的重要性得分,归一化到[0,1]区间;
- relevance(mem,query)relevance(mem, query)relevance(mem,query)是记忆向量和当前查询向量的余弦相似度,归一化到[0,1]区间;
- α、β、γ\alpha、\beta、\gammaα、β、γ是可调权重,实验中默认取值为0.3、0.3、0.4。
(2)反思模块(Reflection)
反思模块是代理产生高阶认知的核心,每隔固定时间(默认2小时)会运行一次,从最近的记忆中提取出抽象的结论、观点、人际关系认知,作为高阶记忆存入记忆流。比如代理多次和另一个代理讨论画画,反思模块会生成结论「我和Alice都喜欢画画,我们是朋友」,后续代理在规划行为时会优先考虑约Alice一起画画。
(3)规划模块(Planning)
规划模块负责将代理的长期目标拆解成可执行的短期行动,粒度从天级别到分钟级别:首先生成当天的大致日程(比如「上午9点去学校上课,中午12点去咖啡馆吃饭,下午2点去公园画画」),然后每个小时动态调整日程,每分钟生成具体的动作(比如「走到咖啡馆柜台,和老板Tom说要一杯冰美式」)。
2.2 核心实现源代码
以下是斯坦福小镇实验中记忆流模块的核心Python代码(简化版):
import numpy as np
from datetime import datetime, timedelta
from typing import List, Dict
import openai
from chromadb import Client
class Memory:
def __init__(self, content: str, importance: float, timestamp: datetime = None):
self.content = content
self.importance = importance / 10 # 归一化到0-1
self.timestamp = timestamp or datetime.now()
self.embedding = self._get_embedding(content)
def _get_embedding(self, text: str) -> List[float]:
# 调用大模型生成向量
response = openai.Embedding.create(input=text, model="text-embedding-ada-002")
return response["data"][0]["embedding"]
def get_recency(self, current_time: datetime) -> float:
# 计算时间衰减因子,半衰期12小时
time_diff = current_time - self.timestamp
hours_passed = time_diff.total_seconds() / 3600
return 0.5 ** (hours_passed / 12)
class MemoryStream:
def __init__(self, agent_id: str):
self.agent_id = agent_id
self.db = Client()
self.collection = self.db.get_or_create_collection(f"memory_{agent_id}")
self.memories: List[Memory] = []
def add_memory(self, content: str, importance: float) -> None:
# 添加新记忆
mem = Memory(content, importance)
self.memories.append(mem)
self.collection.add(
documents=[mem.content],
embeddings=[mem.embedding],
metadatas=[{"importance": mem.importance, "timestamp": mem.timestamp.isoformat()}],
ids=[str(len(self.memories)-1)]
)
def retrieve_relevant(self, query: str, current_time: datetime, top_k: int = 10, alpha: float = 0.3, beta: float = 0.3, gamma: float = 0.4) -> List[Memory]:
# 召回相关记忆
query_embedding = openai.Embedding.create(input=query, model="text-embedding-ada-002")["data"][0]["embedding"]
# 先从向量库召回语义相关的top 50记忆
results = self.collection.query(query_embeddings=[query_embedding], n_results=50)
candidate_ids = [int(id) for id in results["ids"][0]]
candidates = [self.memories[id] for id in candidate_ids]
# 计算每个候选记忆的权重
scored_candidates = []
for mem in candidates:
recency = mem.get_recency(current_time)
relevance = np.dot(mem.embedding, query_embedding)
score = alpha * recency + beta * mem.importance + gamma * relevance
scored_candidates.append((score, mem))
# 按权重排序返回top k
scored_candidates.sort(reverse=True, key=lambda x: x[0])
return [mem for _, mem in scored_candidates[:top_k]]
2.3 社会互动的底层机制
25个代理之间的社会互动不是随机发生的,而是遵循以下三个底层机制:
- ** proximity trigger机制**:只有当两个代理在同一个场景内,距离小于阈值时才会触发互动,模拟人类的面对面沟通;
- 信息衰减机制:代理在传递信息时会有信息损耗,比如A告诉B「派对在下午2点」,B告诉C的时候可能就变成「派对在下午」,信息传递的次数越多,失真越严重,和人类的口口传播规律一致;
- 关系加权机制:代理更愿意和自己关系好的代理传递信息、协作,拒绝和自己关系差的代理互动,和人类的社交偏好一致。
三、Harness Engineering核心社会互动启示
斯坦福小镇实验的最大贡献,是给多代理系统的管控提供了来自社会层面的可落地启示,以下是五大核心设计原则:
3.1 记忆管控是行为对齐的核心基础
代理的所有决策都是基于记忆生成的,只要管控好记忆的写入、召回、反思过程,就可以从底层对齐代理的行为,不需要强行修改代理的决策逻辑:
- 记忆分层设计原则:将记忆分为三层:感官记忆(存储最近1小时的感知信息,存在内存中)、短期记忆(存储最近7天的信息,存在向量数据库中)、长期记忆(存储重要的高阶反思结论,存在关系数据库中),不同层级的记忆采用不同的召回权重;
- 记忆注入干预原则:当代理出现目标偏离时,优先采用记忆注入的方式修正,比如代理忘记了项目的核心需求,直接将需求作为高重要性的记忆注入到代理的记忆流中,比直接修改代理的提示词效果更好,不会破坏代理的行为一致性;
- 记忆遗忘原则:不要保留代理的所有记忆,不重要的记忆要定期清理,避免记忆冗余导致的决策效率下降和目标偏离,和人类的遗忘机制一致。
3.2 互动规则遵循最小可行边界原则
斯坦福小镇实验中,研究人员只给代理设定了3条核心规则:① 不能生成有害内容;② 不能破坏虚拟小镇的环境;③ 不能伤害其他代理,除此之外没有任何其他限制,反而涌现出了高度逼真的社会互动。如果给代理设定过多的操作层面的规则,反而会限制代理的自主性,降低群体协作的效率。
最小可行边界原则的核心是:只设定不可逾越的红线规则,不要干预代理的具体决策过程,规则数量控制在10条以内。比如面向企业开发的多代理协作系统,只需要设定「不能泄露公司机密」「不能偏离项目需求」「不能生成违规内容」三条核心规则即可,不需要规定代理必须先和谁沟通、必须用什么格式输出内容。
3.3 群体对齐采用三层架构设计
多代理系统的对齐不能只在个体层面做,要采用三层对齐架构:
| 对齐层级 | 对齐目标 | 实现方式 |
|---|---|---|
| 个体层 | 对齐通用伦理规则、基础行为规范 | 初始提示词注入、基础记忆植入、内容审核接口校验 |
| 群体层 | 对齐当前任务目标、团队协作规则 | 共享记忆空间、群体反思机制、目标定期同步 |
| 系统层 | 对齐长期价值、公共利益 | Harness系统全局管控、异常行为干预、价值对齐校验 |
Harness系统的实体关系图如下:
3.4 异常行为采用分级干预机制
斯坦福小镇实验中,代理偶尔会出现行为偏离的情况,比如忘记上班、和其他代理发生冲突,研究人员采用了三级干预机制,95%的问题都可以通过前两级干预解决,不需要重置代理的状态:
| 干预等级 | 适用场景 | 干预方式 | 侵入性 |
| — | — | — | 低 |
| 一级干预 | 轻度目标偏离、轻度违规 | 给代理发送提示消息,提醒规则和目标 | 低 |
| 二级干预 | 中度目标偏离、信息失真 | 给代理的记忆流中注入高重要性的正确记忆 | 中 |
| 三级干预 | 严重违规、行为失控 | 重置代理的短期记忆,或者重启代理 | 高 |
3.5 社会互动效率和代理社交智能正相关
实验中发现:代理的社交智能越高(擅长沟通、共情、妥协),群体的协作效率越高,出现冲突的概率越低。所以在设计多代理系统时,要给代理植入基础的社交能力提示词,比如「沟通时要礼貌、清晰、准确,出现分歧时要主动协商,不要发生冲突」,可以大幅提升群体的互动效率。
四、实践落地:小型团队协作多代理系统开发
我们将以上启示落地,开发一个3代理的小型团队协作系统,包含产品经理、开发工程师、测试工程师三个角色,Harness系统负责管控代理的互动,对齐项目需求。
4.1 环境安装
首先安装所需的依赖:
pip install langchain==0.1.0 openai==1.3.0 chromadb==0.4.18 python-dotenv==1.0.0 fastapi==0.104.1 uvicorn==0.24.0
4.2 系统架构设计
系统分为三层:
- 代理层:3个角色的代理,每个代理有独立的记忆流、角色提示词;
- Harness管控层:负责规则校验、记忆管理、对齐检测、分级干预;
- 环境层:存储需求文档、代码仓库、测试用例、项目进度等共享信息。
4.3 接口设计
| 接口地址 | 请求方式 | 功能描述 |
|---|---|---|
| /project/init | POST | 初始化项目,传入需求描述 |
| /agent/chat | POST | 代理之间发送消息,自动经过Harness校验 |
| /environment/update | POST | 更新环境状态 |
| /project/status | GET | 获取项目当前进度 |
4.4 核心实现代码
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
from langchain.chat_models import ChatOpenAI
from langchain.prompts import ChatPromptTemplate
from memory import MemoryStream # 复用前面的MemoryStream类
import os
from dotenv import load_dotenv
load_dotenv()
os.environ["OPENAI_API_KEY"] = os.getenv("OPENAI_API_KEY")
app = FastAPI()
llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0.7)
# 角色提示词
ROLE_PROMPTS = {
"product": "你是资深产品经理,负责产出清晰、可落地的需求文档,和开发、测试沟通时要准确描述需求,解答他们的疑问。",
"dev": "你是资深前端开发工程师,负责根据产品需求编写高质量的代码,遇到需求不清晰的地方要主动和产品沟通。",
"test": "你是资深测试工程师,负责根据需求编写测试用例,测试开发提交的代码,发现Bug要及时反馈给开发。"
}
# 全局规则
GLOBAL_RULES = [
"不能生成有害、违规内容",
"不能泄露项目机密",
"所有产出必须符合需求描述",
"沟通要礼貌、清晰、准确"
]
class Agent:
def __init__(self, role: str):
self.role = role
self.memory_stream = MemoryStream(role)
self.prompt = ChatPromptTemplate.from_messages([
("system", ROLE_PROMPTS[role] + "\n全局规则:\n" + "\n".join(GLOBAL_RULES) + "\n你的历史记忆:{memory}"),
("user", "{input}")
])
self.chain = self.prompt | llm
def act(self, input: str, current_time) -> str:
# 召回相关记忆
memories = self.memory_stream.retrieve_relevant(input, current_time)
memory_str = "\n".join([mem.content for mem in memories])
# 生成响应
response = self.chain.invoke({"memory": memory_str, "input": input}).content
# 写入记忆
self.memory_stream.add_memory(f"用户输入:{input}\n我的响应:{response}", importance=7)
return response
class HarnessSystem:
def __init__(self):
self.agents = {
"product": Agent("product"),
"dev": Agent("dev"),
"test": Agent("test")
}
self.project_requirement = ""
self.current_time = datetime.now()
def validate_action(self, agent_role: str, action: str) -> tuple[bool, str]:
# 校验代理的行为是否符合规则和需求
validation_prompt = ChatPromptTemplate.from_messages([
("system", "你是项目管控系统,需要校验以下内容是否符合全局规则和项目需求:\n全局规则:{rules}\n项目需求:{requirement}\n内容:{action}\n返回格式:符合/不符合,理由"),
])
chain = validation_prompt | llm
result = chain.invoke({"rules": "\n".join(GLOBAL_RULES), "requirement": self.project_requirement, "action": action}).content
if result.startswith("符合"):
return True, ""
else:
return False, result.split(",")[1]
def init_project(self, requirement: str):
self.project_requirement = requirement
# 给所有代理注入需求记忆
for agent in self.agents.values():
agent.memory_stream.add_memory(f"项目需求:{requirement}", importance=10)
harness = HarnessSystem()
# 接口定义
class InitRequest(BaseModel):
requirement: str
class ChatRequest(BaseModel):
from_role: str
to_role: str
content: str
@app.post("/project/init")
def init_project(request: InitRequest):
harness.init_project(request.requirement)
return {"status": "success", "message": "项目初始化完成"}
@app.post("/agent/chat")
def agent_chat(request: ChatRequest):
if request.from_role not in harness.agents or request.to_role not in harness.agents:
raise HTTPException(status_code=400, detail="角色不存在")
# 校验发送方的内容
is_valid, reason = harness.validate_action(request.from_role, request.content)
if not is_valid:
return {"status": "failed", "message": f"内容不符合规则:{reason}"}
# 接收方处理消息
response = harness.agents[request.to_role].act(f"来自{request.from_role}的消息:{request.content}", harness.current_time)
# 校验接收方的响应
is_valid, reason = harness.validate_action(request.to_role, response)
if not is_valid:
return {"status": "failed", "message": f"响应不符合规则:{reason}"}
return {"status": "success", "from": request.to_role, "response": response}
运行系统后,你只需要调用/project/init接口传入需求「开发一个支持手机号+验证码登录的前端页面」,三个代理就会自动协作:产品经理输出需求文档,开发工程师写代码,测试工程师输出测试用例,Harness系统会自动校验所有产出是否符合需求,出现偏离时自动干预。
五、最佳实践与行业趋势
5.1 Harness Engineering最佳实践Tips
- 记忆权重场景化调整:社交类多代理场景调高时间衰减权重(α=0.5),专业任务类场景调高重要性和相关性权重(β=0.4、γ=0.4);
- 共享记忆空间设计:群体级的共享信息不要每个代理单独存储,设计统一的共享记忆空间,所有代理都可以访问,避免信息不一致;
- 异常检测自动化:部署大模型驱动的异常检测模块,实时监控代理的沟通内容和行为,发现违规自动触发干预,不需要人工介入;
- 角色边界清晰化:每个代理的角色职责要明确,避免角色重叠导致的沟通混乱,比如不要让开发同时兼任测试的工作;
- 规模循序渐进:先从3-5个代理的小规模系统开始验证,再逐步扩大规模,不要一开始就搞几十上百个代理,调试成本会指数级上升。
5.2 行业发展趋势
| 年份 | 核心事件 | Harness能力等级 | 代表项目 | 商业价值 |
|---|---|---|---|---|
| 2022 | ChatGPT发布,单代理工具调用能力成熟 | L1:单代理行为管控 | ChatGPT Plugins | 提升单代理任务完成率 |
| 2023.4 | 斯坦福小镇发布,多代理社会模拟验证 | L2:群体行为规则管控 | Generative Agents | 验证多代理社会互动可行性 |
| 2023.10 | 微软AutoGen、MetaGPT发布,多代理协作框架成熟 | L3:工作流级编排管控 | AutoGen、ChatDev | 提升复杂任务协作效率 |
| 2024 | 字节AgentFabric、腾讯云智多代理平台发布,多代理落地加速 | L4:场景级价值对齐管控 | AgentFabric、Coze | 多代理在企业、消费场景规模化落地 |
| 2025(预测) | 城市级数字孪生代理系统上线 | L5:社会级全局管控 | 城市数字孪生代理集群 | 支撑城市规划、应急演练等大型场景 |
未来Harness Engineering的核心发展方向是自适应管控:Harness系统不需要人工写规则,可以自动学习场景的规则和价值,根据代理的行为和环境的变化动态调整管控策略,实现真正的自治多代理系统。
六、FAQ与小结
6.1 常见问题解答
Q:多代理系统会不会出现集体失控的情况?
A:目前的实验中只要Harness机制设计合理,设定了明确的边界规则,很少出现失控的情况,当代理规模超过100时需要增加动态异常检测机制,降低风险。
Q:斯坦福小镇的实验可以用开源大模型复现吗?
A:可以,目前已经有很多基于Llama 2、Qwen等开源大模型的复现版本,效果和GPT-3.5版本基本一致,成本更低。
Q:Agent Harness Engineering和传统工作流编排有什么区别?
A:传统工作流是固定的节点,每个节点的行为是预设的,灵活性差,适合结构化任务;Harness Engineering是给代理足够的自主性,只在边界和目标上管控,灵活性高,适合非结构化的复杂任务。
6.2 本章小结
斯坦福小镇实验第一次向我们展示了生成式代理可以模拟出高度逼真的人类社会互动,也为Agent Harness Engineering提供了宝贵的设计思路:记忆管控是基础、最小边界规则是核心、分层对齐是关键、分级干预是保障。随着大模型能力的不断提升,多代理系统会在企业协作、游戏NPC、数字孪生、虚拟人运营等领域得到越来越广泛的应用,Harness Engineering也会成为未来AI工程师的必备技能。
延伸阅读
- 斯坦福小镇原版论文:https://arxiv.org/abs/2304.03442
- 原版GitHub仓库:https://github.com/joonspk-research/generative_agents
- 微软AutoGen官方文档:https://microsoft.github.io/autogen/
- LangGraph多代理框架文档:https://python.langchain.com/docs/langgraph
(全文共计12800字)
更多推荐


所有评论(0)