这次我们看一个标题很特别的项目Show HN: I built an economy designed to crash。直译过来就是作者公开分享了一个“设计为崩溃的经济模拟系统”。它不是经济学论文而是一个可以运行、可以观察、可以反复把参数调崩的仿真沙盒。这类项目在程序员的实验仓库里并不少见核心价值不是“预测现实经济”而是把崩溃当成系统的一种状态去研究它是怎么出现、怎么传播、怎么被放大的。我拿到这个标题的第一反应是先别管经济学概念先把技术链路拆出来。它至少包含四件事一是多主体建模二是一套必然产生正反馈的规则三是崩溃信号的可视化四是批量参数实验。本文会按这个思路给出一个最小可复现模型从环境准备、核心代码、指标观察、批量扫描到可选的 API 封装全部走一遍。需要先说清楚我手上没有这个项目的完整源码所以下面给出的实现是“同思路最小复现”代码和参数都是演示性质。实际项目用什么语言、什么框架要以你找到的仓库为准。本文重点解决三件事这类模拟怎么落地、怎么观察崩溃过程、遇到问题怎么排查。1. 核心能力速览从“设计为崩溃”这个目标出发一个完整的模拟项目通常包含这几个能力能力项说明项目类型多主体经济仿真沙盒 / 复杂系统实验核心设计目标通过规则设定让虚拟经济在特定条件下进入崩溃螺旋硬件门槛以 CPU 和内存为主常规开发机可运行不强制依赖 GPU启动方式命令行脚本运行可扩展 Web API 服务主要功能多主体初始化、交易与债务规则、破产清算、崩溃指标统计、可视化批量任务通过参数扫描批量运行寻找崩溃临界点接口 API原项目是否自带不确定本文会给出 FastAPI 封装示例适用场景游戏经济、教学实验、复杂系统研究、压力测试设计现实用途边界仅限虚拟仿真不用于现实经济预测或投资决策从设计思路看这个项目真正值得关注的不是模型复杂度而是“如何稳定地制造崩溃”这件事本身。所以后续所有实现都要围绕“正反馈机制”来设计。2. 适用场景与使用边界这类模拟最适合三类人第一类是算法工程师和复杂系统研究者。他们需要对“债务—资产价格—破产”之间的传导路径做实验看参数在什么位置会突然产生系统性风险。第二类是游戏经济策划。很多游戏内经济系统的核心问题就是“某些规则会导致货币膨胀或玩家挤兑”一个能主动崩溃的沙盒模型比靠感觉设计要直观得多。第三类是教学场景。用 50 行代码展示金融加速器、挤兑传染、流动性枯竭比纯 PPT 讲解更容易让学生理解。但这个项目也有明确的使用边界。首先虚拟模型不等于现实经济运行规律任何参数都不能直接迁移到现实预测上。其次如果模型中用到真实统计数据、历史价格、人口分布等素材必须确认数据授权并且做脱敏处理。最后不要把这个项目包装成“预测崩盘”的工具更不要用它输出投资建议。一句话它适合做技术研究和实验设计不适合做现实决策依据。3. 环境准备与前置条件这里按“纯 Python 环境 演示代码”来准备依赖不多系统上只要能装 Python 就能跑。推荐环境操作系统Windows 10/11、Ubuntu 20.04、macOS 12Python 版本3.10 或更高后面示例代码用到了int | None这类类型注解CPU2 核以上即可核心越多批量扫描越舒服内存8GB 以上更稳演示规模用不到太多GPU可选不是必需磁盘空间代码和结果文件都很小预留 1GB 足够依赖安装建议使用虚拟环境避免污染全局 Python。python -m venv .venv # Windows .venv\Scripts\activate # Linux / macOS source .venv/bin/activate pip install numpy pandas matplotlib fastapi uvicorn如果你在国内网络环境pip 下载慢可以直接换镜像源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple numpy pandas matplotlib fastapi uvicorn到这里环境就准备好了。下面开始写核心模型。4. 最小实现一个会崩溃的多主体经济模型为了让“崩溃”不是随机事故而是系统设计的结果我们需要至少三个要素每个主体都有自己的资产负债表包含现金、债务和资产。债务成本每轮都在消耗现金。当主体资不抵债时会被强制清算而清算会压低市场价格让更多同类主体陷入账面亏损。这就是一个标准的“债务通缩螺旋”。把它写成代码后只要参数设定合理系统会先出现一段稳定期然后在外生冲击后迅速崩盘。先定义主体和数据模型。from dataclasses import dataclass import random dataclass class Agent: cash: float 100.0 debt: float 0.0 assets: float 0.0 bankrupt: bool False property def net_worth(self) - float: return self.cash self.assets - self.debt然后实现经济模拟器。为了让过程可控我加了一个shock_round参数前 50 轮市场小幅波动从第 50 轮开始施加外生冲击。这样更容易看到“稳定到崩溃”的完整过程。class CrashEconomy: def __init__( self, n_agents: int 300, leverage: float 2.5, liquidity: float 0.2, shock_round: int 50, seed: int 42, ): self.n_agents n_agents self.leverage leverage self.liquidity liquidity self.shock_round shock_round self.random random.Random(seed) self.price_index 100.0 self.agents [self._create_agent() for _ in range(n_agents)] self.history [] def _create_agent(self) - Agent: cash 100.0 # 杠杆倍数越高初始债务越多 debt cash * self.leverage * self.random.uniform(0.8, 1.2) assets cash debt return Agent(cashcash, debtdebt, assetsassets) def step(self, round_idx: int): # 稳定期小幅上涨冲击后进入下跌阶段 if round_idx self.shock_round: market_return self.random.uniform(-0.04, -0.01) else: market_return self.random.uniform(0.005, 0.02) for a in self.agents: if a.bankrupt: continue a.assets * 1.0 market_return # 每轮支付利息相当于现金被持续消耗 a.cash - a.debt * 0.01 # 破产清算资不抵债的主体强制退出并压低市场价格 for a in self.agents: if not a.bankrupt and a.net_worth 0: a.bankrupt True self.price_index * 0.90 self.liquidity * 0.10 def run(self, n_rounds: int 150): for r in range(n_rounds): self.step(r) bankrupt_ratio sum(1 for a in self.agents if a.bankrupt) / self.n_agents total_debt sum(a.debt for a in self.agents if not a.bankrupt) self.history.append( { round: r, price_index: round(self.price_index, 4), bankrupt_ratio: round(bankrupt_ratio, 4), total_debt: round(total_debt, 4), } ) return self.history if __name__ __main__: economy CrashEconomy(n_agents300, leverage2.5, liquidity0.2, seed7) history economy.run(150) print(history[-5:])这段代码的逻辑很直接每个主体初始持有现金和债务资产价格受到市场收益影响一旦净资产为负主体破产卖出资产导致价格指数下降价格指数下降又让其他主体账上资产缩水最终形成连锁反应。跑一次后最后几条结果会显示破产比例大幅上升、价格指数大幅下跌。你能清晰看到“设计为崩溃”的路径。5. 观察“设计为崩溃”的过程指标与可视化运行模型不是终点重点是要能观察崩溃是怎么演进的。建议至少保留这四个指标价格指数反映系统整体资产价格水平。破产比例反映系统受损范围。总债务反映杠杆压力是否在累积。现金—债务比反映流动性是否充足。下面用 matplotlib 画一张价格指数和破产比率的双轴图。import matplotlib.pyplot as plt from simple_economy import CrashEconomy economy CrashEconomy(n_agents500, leverage2.8, liquidity0.15, seed11) history economy.run(200) fig, ax1 plt.subplots(figsize(10, 4)) ax1.plot( [h[round] for h in history], [h[price_index] for h in history], labelprice index, colortab:red, ) ax1.set_xlabel(round) ax1.set_ylabel(price index, colortab:red) ax2 ax1.twinx() ax2.plot( [h[round] for h in history], [h[bankrupt_ratio] for h in history], labelbankrupt ratio, colortab:blue, linestyle--, ) ax2.set_ylabel(bankrupt ratio, colortab:blue) ax2.set_ylim(0, 1) fig.tight_layout() plt.savefig(crash_result.png, dpi120) print(figure saved: crash_result.png)从模型设定看预期结果是前 50 轮价格指数平稳甚至小幅上升破产比例接近 0外生冲击出现后价格指数连续下跌破产比例在某一轮之后加速抬升。如果你的图没有这个特征大概率是杠杆太低、冲击太小或运行轮数太短。判断模型是否有效的标准很简单破产比例曲线是否存在斜率骤增的“拐点”。这个拐点就是系统被触发崩溃的临界区域也是后续批量参数实验要寻找的对象。6. 参数实验与批量任务单次运行只能看一条路径价值有限。这个项目真正有价值的操作是批量扫描参数找崩溃临界点。先建一个配置文件batch_config.json{ n_agents: 300, rounds: 100, seed_count: 5, workers: 4, leverage_grid: [1.5, 2.0, 2.5, 3.0], liquidity_grid: [0.1, 0.2, 0.3] }然后写批量运行脚本用concurrent.futures.ProcessPoolExecutor做多进程并行。import json from concurrent.futures import ProcessPoolExecutor from simple_economy import CrashEconomy def run_one(config): economy CrashEconomy( n_agentsconfig[n_agents], leverageconfig[leverage], liquidityconfig[liquidity], seedconfig[seed], ) history economy.run(config[rounds]) crash_round next( (h[round] for h in history if h[bankrupt_ratio] 0.5), None, ) return { **config, crash_round: crash_round, final_price_index: round(economy.price_index, 4), } if __name__ __main__: with open(batch_config.json, r, encodingutf-8) as f: data json.load(f) configs [] for leverage in data[leverage_grid]: for liquidity in data[liquidity_grid]: for seed in range(data[seed_count]): configs.append( { n_agents: data[n_agents], rounds: data[rounds], leverage: leverage, liquidity: liquidity, seed: seed, } ) with ProcessPoolExecutor(max_workersdata[workers]) as pool: results list(pool.map(run_one, configs)) with open(batch_results.json, w, encodingutf-8) as f: json.dump(results, f, indent2) for r in results: print( fleverage{r[leverage]}, liquidity{r[liquidity]}, fseed{r[seed]}, crash_round{r[crash_round]} )运行之后你会得到一张参数和崩溃时点的对照表。从材料推断杠杆越高、流动性越低崩溃出现得越早。如果某个参数组合下始终没有出现破产比例超过 50% 的轮次说明系统还处在“稳定区”需要继续提高杠杆或降低流动性。批量任务设计时要注意一点每个 worker 都是独立进程随机种子必须固定否则结果不可复现。实践中建议每次运行后把配置和结果一起保存形成实验留档。7. 扩展为接口 API如果你不想每次都在命令行里改参数可以给模拟器加一个 HTTP 接口。这里用 FastAPI 封装作为可选扩展原项目是否自带 API 不确定。from fastapi import FastAPI from pydantic import BaseModel, Field from simple_economy import CrashEconomy app FastAPI() class SimRequest(BaseModel): n_agents: int Field(200, ge50, le5000) leverage: float Field(2.5, ge1.0, le5.0) liquidity: float Field(0.2, ge0.05, le1.0) rounds: int Field(100, ge10, le1000) seed: int 42 class SimResponse(BaseModel): crash_round: int | None final_price_index: float final_bankrupt_ratio: float history: list[dict] app.post(/simulate, response_modelSimResponse) def simulate(req: SimRequest): economy CrashEconomy( n_agentsreq.n_agents, leveragereq.leverage, liquidityreq.liquidity, seedreq.seed, ) history economy.run(req.rounds) crash_round next( (h[round] for h in history if h[bankrupt_ratio] 0.5), None, ) return SimResponse( crash_roundcrash_round, final_price_indexround(economy.price_index, 4), final_bankrupt_ratioround( sum(a.bankrupt for a in economy.agents) / req.n_agents, 4 ), historyhistory, )启动服务uvicorn main:app --host 127.0.0.1 --port 8080如果8080端口被占用换一个端口uvicorn main:app --host 127.0.0.1 --port 8081用curl做一次请求curl -X POST http://127.0.0.1:8080/simulate \ -H Content-Type: application/json \ -d {n_agents:300,leverage:3.0,liquidity:0.2,rounds:150,seed:7}返回值是一个 JSON包含crash_round、最终价格指数、最终破产比例和完整历史。接口能跑通之后你就可以把它接到自己的模拟编排工具、指标监控面板或者自动化测试链路里。8. 资源占用与性能观察这个项目不是深度学习任务不必过多关注显存。它更吃 CPU 和内存。如果你运行的是上面 300 个主体、150 轮的小规模模拟整个进程占用很低开发机完全跑得动。重点观察的是批量扫描阶段单进程运行 10 组参数耗时会线性增加。多进程并行时内存占用会随 worker 数量上升。如果主体数量提到 5000每轮遍历的时间和内存都会明显上涨。如果单轮内所有主体都要两两配对复杂度会接近 O(n²)建议减少交互密度。观察资源占用Linux 下可以用htopWindows 下打开任务管理器。不需要 GPU所以不看显存。如果批量任务跑得很慢可以按优先级优化先减小n_agents或rounds。再限制workers数量。最后再考虑用 NumPy 向量化替代纯 Python 循环。如果对性能要求更高可以尝试 Numba JIT 编译核心step函数。端口方面FastAPI 服务如果挂掉后残留进程端口会被占用。排查时可以看进程列表然后结束对应进程或者直接换端口。9. 常见问题与排查方法问题现象可能原因排查方式解决方案依赖安装失败网络原因或 Python 版本过低查看 pip 报错信息切换镜像源升级到 Python 3.10模拟结果每次都不一样没有固定随机种子检查random.Random(seed)在所有入口显式传入 seed一启动就全崩没有稳定期杠杆过高或外生冲击太早调低 leverage调高 liquidity推迟 shock_round先跑小规模参数扫描找稳定窗口运行结束却没有任何崩溃冲击不足或杠杆太低查看价格指数是否始终平稳提高 leverage降低 liquidity延长 rounds批量任务卡住不动worker 数过多或单任务耗时过长查看 CPU 和内存占用减小 workers给任务加日志FastAPI 启动报端口占用上一个服务进程未退出netstat -anofindstr 8080绘图输出空白matplotlib 后端或保存路径问题检查控制台报错改用plt.savefig指定绝对路径接口返回失败请求 JSON 参数越界检查Field的范围配置按约束传参或放宽数值范围在这些问题里最常踩的是“结果不可复现”。尤其是批量任务只要有一个子进程没固定随机种子整个扫描结果就乱了。建议把seed当成标准参数写入配置和结果一起存储。10. 最佳实践与使用建议如果你要复刻这类“设计为崩溃”的模拟项目下面几条经验可以直接用。第一次运行先用最小规模验证流程。比如 100 个主体、50 轮先确认代码能跑通、绘图能保存再开始批量实验。将模型文件、配置文件、输出结果分目录管理避免实验结果混在一起。experiment/ ├── config/ │ └── batch_config.json ├── src/ │ └── simple_economy.py ├── scripts/ │ └── run_batch.py └── results/ ├── crash_result.png └── batch_results.json批量任务一定要加日志和失败重试。即使ProcessPoolExecutor很稳也可能因为内存不足或者进程崩溃导致部分任务丢失。建议每跑完一组就写一小份中间结果而不是等全部结束后统一写。接口服务要限制访问范围。本地实验可以监听127.0.0.1不要直接暴露到公网。如果确实要共享给团队至少加一层简单鉴权或放在内网环境。涉及模型数据时如果使用了外部采集的真实数据必须确认授权并做脱敏。这个项目本身是虚拟沙盒但如果后续接入真实经济数据就涉及到数据合规问题。最后一点也是最重要的一点不要把结果解读为现实经济预测。这个模型的核心是展示“正反馈如何导致崩溃”不是用来预测某个市场或某个国家经济的。公开发布时也要把这个边界写清楚。11. 总结与下一步这个项目最值得尝试的点是把“崩溃”从一个抽象概念变成了可运行、可观察、可调参的系统状态。你不需要很大的投入一份 Python 脚本加几个参数扫描就能看到稳定期、冲击、传染、流动性枯竭的完整路径。如果准备复现建议按这个顺序验证先跑通最小模型确认价格指数和破产比例曲线符合预期。再固定随机种子做批量参数扫描。找到某个参数组合下的“崩溃临界点”。最后再加 API 封装和自动化实验流程。最容易踩的坑是只调了杠杆忽略了流动性只跑了一次忘了固定 seed只存了结果没存配置。把这三件事做好实验可复现性会好很多。后续可以继续扩展的方向很多把单市场模型改成多市场网络、加入主体的异质性策略、接入强化学习 agent或者把崩溃阈值做成自动搜索任务。每一步都比“跑一个 demo”更有工程价值。如果你也搭过类似的仿真沙盒欢迎在评论区聊聊你设定的崩溃触发条件。