简介这份资源面向希望入门或进阶代理建模Agent-Based Modeling的学习者围绕开源仿真框架 Repast 提供从零搭建项目到案例实践的完整素材适合课程实验、科研建模与自学练手。压缩包共 30 个文件约 26.88MB以 24 个 jar 库文件为主涵盖 Repast 核心类库、图表绘制、地理信息与数学计算等依赖另有 4 个 java 源文件、1 份通俗入门说明和 1 个示例压缩包兼顾环境搭建与代码研读。资源中既有循序渐进的入门指引也包含生命游戏等经典代理模型案例可帮助读者理解代理定义、空间交互、参数设置与结果可视化的完整流程并借助源码体会建模逻辑的组织方式。目前已有 626 人学习适合作为 Repast 仿真教程的配套练习材料。1. 拿到一个 Repast 示例包先别急着双击运行很多人第一次接触 Repast 仿真卡住的地方不是建模思路而是环境。压缩包解压出来一堆.java、.xml、.properties双击没反应命令行跑又报找不到类最后只能放弃。这份 Repast 使用示例包的价值就在这儿它把「一个能跑起来的仿真工程长什么样」直接摆在你面前省掉从零搭骨架的时间。它适合两类人——一类是要交课程设计、需要快速理解 agent 建模流程的学生另一类是已经会写 Java、但没碰过仿真框架的工程师。你要做的不是读它而是把它跑通、改一个参数、看结果怎么变。下面按「环境怎么配、工程怎么读、参数怎么调、坑在哪」的顺序拆。2. 环境与工程结构把示例跑起来的第一步Repast 是 Java 生态里的 agent-based modeling 框架示例包本质是一个 Eclipse/IDEA 能导入的 Java 工程。跑不起来的原因九成在 JDK 版本和依赖路径而不是代码本身。2.1 JDK 与构建工具的选择Repast 的不同分支对 JDK 要求不一样老版本示例常见是 JDK 8 编译的用 JDK 17 直接跑大概率报UnsupportedClassVersionError。我的习惯是先看工程根目录有没有pom.xml或.classpath有 pom 就走 Maven没有就按 Eclipse 工程导入。# 先确认本机 JDK 版本示例包多数按 8 或 11 编译 java -version javac -version # 如果工程带 pom.xml先进目录看依赖能不能拉下来 mvn -q dependency:resolvejava -version输出里的主版本号要和工程编译版本对齐mvn dependency:resolve只做依赖解析不编译能提前暴露仓库地址失效的问题。如果输出里出现Could not resolve dependencies先别改代码去pom.xml里看repositories指向的地址是否还能访问很多老示例的仓库地址已经下线需要换成公共仓库或本地已有 jar。没有 pom 的工程导入后要手动确认 Build Path 里有没有 Repast 的运行时 jar。常见做法是把lib/目录下的 jar 全部 Add to Build Path缺一个都会在启动时抛NoClassDefFoundError。2.2 目录结构与入口类定位一个典型的 Repast 示例工程目录大致是这样组织的路径作用先看什么src/Java 源码agent、context、model 类都在这里找带main方法的类lib/框架与第三方 jar确认 jar 是否齐全params/或*.xml仿真参数配置文件看初始 agent 数量、步数output/运行结果、日志、图表数据跑完先看这里scenario/场景描述文件部分版本决定 agent 初始布局入口类通常名字里带Model或Main里面会有public static void main(String[] args)并且调用RunEnvironment.getInstance().startAt(...)之类的方法。找到它右键 Run As Java Application这是验证工程完整性的最快方式。如果报错指向某个 context 或 projection 类找不到说明依赖没配全回到 2.1 补 jar。提示不要一上来就改源码。先原样跑通一次确认输出目录里有结果文件再动手改参数否则出了问题分不清是环境还是改动导致的。2.3 第一次运行要看的三样东西跑通之后别急着关按顺序看三处控制台最后几行有没有异常堆栈、output/下有没有生成 csv 或日志、参数文件里定义的步数是否真的执行完了。常见情况是程序「看起来跑完了」但实际在第一步就抛了异常被 catch 住控制台只留一行 warning。我的做法是在入口类main末尾加一句打印当前 tick 数确认仿真确实推进到了设定步数。// 在 main 方法启动仿真后打印最终步数确认没有提前退出 RunState rs RunEnvironment.getInstance().getCurrentRun(); System.out.println(final tick rs.getTickCount());getTickCount()返回的是当前仿真时钟和参数文件里的总步数对比差值大就说明中途有 agent 抛异常导致调度中断。这一步花两分钟能省掉后面半小时的排查。3. 读懂示例里的 agent 与调度从代码到可改的参数示例包真正有价值的部分不是「能跑」而是它展示了一个最小可用的 agent 建模闭环agent 怎么定义、context 怎么组织、调度器怎么驱动。看懂这三层你才能把它改成自己的题。3.1 agent 类的三个必备要素Repast 里的 agent 一般继承DefaultAgent或实现Agent接口核心是三样状态字段、step()行为方法、以及注册到 context 的方式。示例里常见一个Agent类带x、y坐标和一个state枚举step()里根据邻居情况改状态。public class MyAgent extends DefaultAgent { private int x, y; private int state 0; Override public void step() { // 每 tick 执行一次这里放状态转移逻辑 if (state 0 countNeighbors() 2) { state 1; } } private int countNeighbors() { // 邻居统计依赖 context 的 projection示例里通常已封装 return 0; } }step()是调度器每个 tick 回调的入口所有行为逻辑都挂在这里或它调用的方法上。state字段是你要改的第一目标——把阈值2改成别的值重跑看结果分布怎么变这是理解模型最直接的方式。countNeighbors()在示例里往往依赖某个 projection比如 grid 或 network改它之前先确认 context 里注册了对应 projection否则返回恒为 0模型等于没跑。3.2 context 与 projectionagent 住在哪、怎么找邻居context 是 agent 的容器projection 决定 agent 之间的空间或网络关系。示例里最常见的组合是ContextGrid网格或ContextNetwork网络。初始化代码通常长这样ContextMyAgent context new DefaultContext(); for (int i 0; i agentCount; i) { context.add(new MyAgent()); } // 注册网格投影宽高来自参数文件 GridMyAgent grid new Grid(context, gridWidth, gridHeight, true, true, true);agentCount、gridWidth、gridHeight这三个值一般从参数文件读改它们比改代码安全。Grid构造里那几个布尔参数分别控制是否周期性边界、是否支持对角邻居等示例注释里通常有说明改之前先读注释别凭感觉传。周期性边界打开意味着 agent 走到边缘会从对面回来关掉则边缘 agent 邻居数偏少这两种设定对结果影响很大属于典型的「参数一改结论就变」的点。3.3 调度器谁在驱动 stepRepast 的调度靠RunEnvironment和Schedule。示例里常见两种写法一种用ScheduleParameters声明每 tick 执行的动作另一种直接在 context 上挂Action。前者更可控推荐优先看这种。// 声明每 tick 对所有 agent 执行 step ScheduleParameters params ScheduleParameters.createRepeating(1, 1); context.addAction(params, (ctx) - { for (MyAgent a : ctx.getObjects(MyAgent.class)) { a.step(); } });createRepeating(1, 1)两个参数分别是起始 tick 和间隔改成(1, 2)就是每两 tick 执行一次用来观察「行为频率」对结果的影响。getObjects(MyAgent.class)拿到的是当前 context 里所有该类型 agent遍历顺序不保证稳定如果你的模型对执行顺序敏感需要自己排序或改用随机化调度这一点示例里往往不写但实际做对比实验时必须注意。4. 参数调优与结果验证让示例变成你自己的实验跑通、读懂之后示例包才真正开始有用——它是你调参和验证的基线。这一章讲怎么系统地改参数、怎么看结果是否可信。4.1 参数文件的组织与批量实验示例的参数文件通常是 xml 或 properties关键参数包括 agent 数量、网格尺寸、总步数、随机种子。做对比实验时一次只改一个参数其余固定并且固定随机种子否则两次运行的差异分不清是参数还是随机性。# 用脚本批量跑不同 agent 数量每次覆盖参数文件后启动 for n in 100 200 400; do sed -i s/agentCount.*\/agentCount/agentCount$n\/agentCount/ params.xml java -cp lib/*:bin MyModel run_$n.log 21 donesed那行只替换 agent 数量字段java -cp里lib/*是通配所有 jarbin是编译输出目录按你工程实际路径改。每次输出单独日志方便事后对比。注意sed -i会直接改原文件跑之前先备份一份params.xml.bak这是血泪经验——批量脚本改坏参数文件、原始配置找不回来的情况太常见了。4.2 结果怎么算「可信」单次运行的结果不能直接下结论。agent-based 模型有随机性正确做法是同一组参数跑多次常见 10 到 30 次看结果的均值和波动范围。示例输出如果是 csv用一段小脚本聚合import pandas as pd # 读取多次运行的结果按参数分组统计均值和标准差 df pd.read_csv(results.csv) summary df.groupby(agent_count)[final_state_ratio].agg([mean, std]) print(summary)groupby的键要和参数文件里的字段对应agg里mean看趋势、std看稳定性。标准差过大说明随机性主导这时候增加运行次数或固定更多随机源否则你看到的「差异」可能只是噪声。这一步是区分「随便跑跑」和「能写进报告」的分水岭。4.3 用输出反推模型是否按预期工作结果文件除了看最终值还要看中间过程。示例如果输出了每 tick 的状态分布画一条时间序列能发现很多逻辑错误比如状态比例在第一步就跳到稳态往往意味着step()被重复调用或阈值设错比如曲线周期性震荡可能是调度间隔和状态转移周期撞上了。我的习惯是先看前 10 个 tick 的原始输出确认每一步的变化符合代码逻辑再去看整体趋势。5. 避坑与常见问题这些错我基本都犯过5.1 启动报 NoClassDefFoundError现象右键运行入口类控制台抛NoClassDefFoundError指向某个 Repast 内部类。原因lib/下 jar 没全部加入 Build Path或 Maven 依赖被标记为 provided 但运行时没提供。解决检查 Build Path 的 Libraries 列表把lib/下所有 jar 加进去Maven 工程确认mvn dependency:tree里该依赖不是 provided 作用域。5.2 仿真跑完但输出目录是空的现象程序正常结束output/下没有结果文件。原因输出路径写的是相对路径而运行工作目录不是工程根目录或输出逻辑挂在某个从未触发的分支上。解决在写文件的地方打印new File(.).getAbsolutePath()确认实际工作目录把输出路径改成绝对路径或基于工程根目录拼接。5.3 改了参数但结果完全没变现象修改参数文件后重跑结果和之前一模一样。原因代码里参数是硬编码的参数文件根本没被读取或读取了但被后面的默认值覆盖。解决在参数加载处加打印确认读到的值搜索代码里是否有同名字段的直接赋值优先级高于配置文件。5.4 邻居统计恒为 0现象agent 行为逻辑不触发排查发现邻居数一直是 0。原因context 里没有注册对应的 projection或 projection 的尺寸参数为 0。解决确认new Grid(...)那行确实执行了且宽高来自有效参数在countNeighbors()里打印 projection 对象是否为 null。5.5 多次运行结果差异巨大现象同一组参数跑两次结果差一倍以上。原因随机种子未固定或遍历 agent 的顺序不稳定放大了随机性。解决在初始化处显式设置随机种子对顺序敏感的模型在调度前对 agent 列表排序或使用固定随机序列。6. 把示例改造成自己的模型一个可复用的改造顺序示例包最大的用处是当模板。我的改造顺序固定为四步每步都能独立验证避免一次性改太多导致问题定位不了。第一步换 agent 的状态字段和step()逻辑其他不动跑通确认调度还在工作。第二步改 context 的 projection 类型比如从 grid 换成 network这一步最容易出问题改完先只跑 10 个 tick 看邻居统计是否合理。第三步调参数文件把 agent 数量、步数、种子做成可配置用 4.1 的批量脚本跑小规模实验。第四步加输出把你要分析的指标按 tick 写进 csv再套 4.2 的聚合脚本。改造过程中有一个检查表值得固定下来检查项通过标准不通过先查入口类能启动控制台无异常堆栈Build Path、JDK 版本仿真推进到设定步数最终 tick 等于参数值调度间隔、异常吞没邻居统计非零抽样 agent 邻居数大于 0projection 注册、尺寸参数输出文件生成output/下有本次运行文件工作目录、写文件分支多次运行有分布同参数结果有均值有波动随机种子、遍历顺序这张表我每次改完模型都过一遍比事后翻日志快得多。Repast 这类框架的坑大多不在算法而在「配置和代码对不上」——参数文件说一套、代码里默认值另一套、运行目录又是第三套。把这三者对齐示例包就从「别人的代码」变成了「你的基线」。从那以后我每次拿到一个仿真示例包都强制先原样跑通、打印最终 tick、确认输出目录再动第一行代码。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/26 2:09:23 · 阅读 1.2k Repast 仿真示例包实战：从环境配置到参数调优的完整指南
简介这份资源面向希望入门或进阶代理建模Agent-Based Modeling的学习者围绕开源仿真框架 Repast 提供从零搭建项目到案例实践的完整素材适合课程实验、科研建模与自学练手。压缩包共 30 个文件约 26.88MB以 24 个 jar 库文件为主涵盖 Repast 核心类库、图表绘制、地理信息与数学计算等依赖另有 4 个 java 源文件、1 份通俗入门说明和 1 个示例压缩包兼顾环境搭建与代码研读。资源中既有循序渐进的入门指引也包含生命游戏等经典代理模型案例可帮助读者理解代理定义、空间交互、参数设置与结果可视化的完整流程并借助源码体会建模逻辑的组织方式。目前已有 626 人学习适合作为 Repast 仿真教程的配套练习材料。1. 拿到一个 Repast 示例包先别急着双击运行很多人第一次接触 Repast 仿真卡住的地方不是建模思路而是环境。压缩包解压出来一堆.java、.xml、.properties双击没反应命令行跑又报找不到类最后只能放弃。这份 Repast 使用示例包的价值就在这儿它把「一个能跑起来的仿真工程长什么样」直接摆在你面前省掉从零搭骨架的时间。它适合两类人——一类是要交课程设计、需要快速理解 agent 建模流程的学生另一类是已经会写 Java、但没碰过仿真框架的工程师。你要做的不是读它而是把它跑通、改一个参数、看结果怎么变。下面按「环境怎么配、工程怎么读、参数怎么调、坑在哪」的顺序拆。2. 环境与工程结构把示例跑起来的第一步Repast 是 Java 生态里的 agent-based modeling 框架示例包本质是一个 Eclipse/IDEA 能导入的 Java 工程。跑不起来的原因九成在 JDK 版本和依赖路径而不是代码本身。2.1 JDK 与构建工具的选择Repast 的不同分支对 JDK 要求不一样老版本示例常见是 JDK 8 编译的用 JDK 17 直接跑大概率报UnsupportedClassVersionError。我的习惯是先看工程根目录有没有pom.xml或.classpath有 pom 就走 Maven没有就按 Eclipse 工程导入。# 先确认本机 JDK 版本示例包多数按 8 或 11 编译 java -version javac -version # 如果工程带 pom.xml先进目录看依赖能不能拉下来 mvn -q dependency:resolvejava -version输出里的主版本号要和工程编译版本对齐mvn dependency:resolve只做依赖解析不编译能提前暴露仓库地址失效的问题。如果输出里出现Could not resolve dependencies先别改代码去pom.xml里看repositories指向的地址是否还能访问很多老示例的仓库地址已经下线需要换成公共仓库或本地已有 jar。没有 pom 的工程导入后要手动确认 Build Path 里有没有 Repast 的运行时 jar。常见做法是把lib/目录下的 jar 全部 Add to Build Path缺一个都会在启动时抛NoClassDefFoundError。2.2 目录结构与入口类定位一个典型的 Repast 示例工程目录大致是这样组织的路径作用先看什么src/Java 源码agent、context、model 类都在这里找带main方法的类lib/框架与第三方 jar确认 jar 是否齐全params/或*.xml仿真参数配置文件看初始 agent 数量、步数output/运行结果、日志、图表数据跑完先看这里scenario/场景描述文件部分版本决定 agent 初始布局入口类通常名字里带Model或Main里面会有public static void main(String[] args)并且调用RunEnvironment.getInstance().startAt(...)之类的方法。找到它右键 Run As Java Application这是验证工程完整性的最快方式。如果报错指向某个 context 或 projection 类找不到说明依赖没配全回到 2.1 补 jar。提示不要一上来就改源码。先原样跑通一次确认输出目录里有结果文件再动手改参数否则出了问题分不清是环境还是改动导致的。2.3 第一次运行要看的三样东西跑通之后别急着关按顺序看三处控制台最后几行有没有异常堆栈、output/下有没有生成 csv 或日志、参数文件里定义的步数是否真的执行完了。常见情况是程序「看起来跑完了」但实际在第一步就抛了异常被 catch 住控制台只留一行 warning。我的做法是在入口类main末尾加一句打印当前 tick 数确认仿真确实推进到了设定步数。// 在 main 方法启动仿真后打印最终步数确认没有提前退出 RunState rs RunEnvironment.getInstance().getCurrentRun(); System.out.println(final tick rs.getTickCount());getTickCount()返回的是当前仿真时钟和参数文件里的总步数对比差值大就说明中途有 agent 抛异常导致调度中断。这一步花两分钟能省掉后面半小时的排查。3. 读懂示例里的 agent 与调度从代码到可改的参数示例包真正有价值的部分不是「能跑」而是它展示了一个最小可用的 agent 建模闭环agent 怎么定义、context 怎么组织、调度器怎么驱动。看懂这三层你才能把它改成自己的题。3.1 agent 类的三个必备要素Repast 里的 agent 一般继承DefaultAgent或实现Agent接口核心是三样状态字段、step()行为方法、以及注册到 context 的方式。示例里常见一个Agent类带x、y坐标和一个state枚举step()里根据邻居情况改状态。public class MyAgent extends DefaultAgent { private int x, y; private int state 0; Override public void step() { // 每 tick 执行一次这里放状态转移逻辑 if (state 0 countNeighbors() 2) { state 1; } } private int countNeighbors() { // 邻居统计依赖 context 的 projection示例里通常已封装 return 0; } }step()是调度器每个 tick 回调的入口所有行为逻辑都挂在这里或它调用的方法上。state字段是你要改的第一目标——把阈值2改成别的值重跑看结果分布怎么变这是理解模型最直接的方式。countNeighbors()在示例里往往依赖某个 projection比如 grid 或 network改它之前先确认 context 里注册了对应 projection否则返回恒为 0模型等于没跑。3.2 context 与 projectionagent 住在哪、怎么找邻居context 是 agent 的容器projection 决定 agent 之间的空间或网络关系。示例里最常见的组合是ContextGrid网格或ContextNetwork网络。初始化代码通常长这样ContextMyAgent context new DefaultContext(); for (int i 0; i agentCount; i) { context.add(new MyAgent()); } // 注册网格投影宽高来自参数文件 GridMyAgent grid new Grid(context, gridWidth, gridHeight, true, true, true);agentCount、gridWidth、gridHeight这三个值一般从参数文件读改它们比改代码安全。Grid构造里那几个布尔参数分别控制是否周期性边界、是否支持对角邻居等示例注释里通常有说明改之前先读注释别凭感觉传。周期性边界打开意味着 agent 走到边缘会从对面回来关掉则边缘 agent 邻居数偏少这两种设定对结果影响很大属于典型的「参数一改结论就变」的点。3.3 调度器谁在驱动 stepRepast 的调度靠RunEnvironment和Schedule。示例里常见两种写法一种用ScheduleParameters声明每 tick 执行的动作另一种直接在 context 上挂Action。前者更可控推荐优先看这种。// 声明每 tick 对所有 agent 执行 step ScheduleParameters params ScheduleParameters.createRepeating(1, 1); context.addAction(params, (ctx) - { for (MyAgent a : ctx.getObjects(MyAgent.class)) { a.step(); } });createRepeating(1, 1)两个参数分别是起始 tick 和间隔改成(1, 2)就是每两 tick 执行一次用来观察「行为频率」对结果的影响。getObjects(MyAgent.class)拿到的是当前 context 里所有该类型 agent遍历顺序不保证稳定如果你的模型对执行顺序敏感需要自己排序或改用随机化调度这一点示例里往往不写但实际做对比实验时必须注意。4. 参数调优与结果验证让示例变成你自己的实验跑通、读懂之后示例包才真正开始有用——它是你调参和验证的基线。这一章讲怎么系统地改参数、怎么看结果是否可信。4.1 参数文件的组织与批量实验示例的参数文件通常是 xml 或 properties关键参数包括 agent 数量、网格尺寸、总步数、随机种子。做对比实验时一次只改一个参数其余固定并且固定随机种子否则两次运行的差异分不清是参数还是随机性。# 用脚本批量跑不同 agent 数量每次覆盖参数文件后启动 for n in 100 200 400; do sed -i s/agentCount.*\/agentCount/agentCount$n\/agentCount/ params.xml java -cp lib/*:bin MyModel run_$n.log 21 donesed那行只替换 agent 数量字段java -cp里lib/*是通配所有 jarbin是编译输出目录按你工程实际路径改。每次输出单独日志方便事后对比。注意sed -i会直接改原文件跑之前先备份一份params.xml.bak这是血泪经验——批量脚本改坏参数文件、原始配置找不回来的情况太常见了。4.2 结果怎么算「可信」单次运行的结果不能直接下结论。agent-based 模型有随机性正确做法是同一组参数跑多次常见 10 到 30 次看结果的均值和波动范围。示例输出如果是 csv用一段小脚本聚合import pandas as pd # 读取多次运行的结果按参数分组统计均值和标准差 df pd.read_csv(results.csv) summary df.groupby(agent_count)[final_state_ratio].agg([mean, std]) print(summary)groupby的键要和参数文件里的字段对应agg里mean看趋势、std看稳定性。标准差过大说明随机性主导这时候增加运行次数或固定更多随机源否则你看到的「差异」可能只是噪声。这一步是区分「随便跑跑」和「能写进报告」的分水岭。4.3 用输出反推模型是否按预期工作结果文件除了看最终值还要看中间过程。示例如果输出了每 tick 的状态分布画一条时间序列能发现很多逻辑错误比如状态比例在第一步就跳到稳态往往意味着step()被重复调用或阈值设错比如曲线周期性震荡可能是调度间隔和状态转移周期撞上了。我的习惯是先看前 10 个 tick 的原始输出确认每一步的变化符合代码逻辑再去看整体趋势。5. 避坑与常见问题这些错我基本都犯过5.1 启动报 NoClassDefFoundError现象右键运行入口类控制台抛NoClassDefFoundError指向某个 Repast 内部类。原因lib/下 jar 没全部加入 Build Path或 Maven 依赖被标记为 provided 但运行时没提供。解决检查 Build Path 的 Libraries 列表把lib/下所有 jar 加进去Maven 工程确认mvn dependency:tree里该依赖不是 provided 作用域。5.2 仿真跑完但输出目录是空的现象程序正常结束output/下没有结果文件。原因输出路径写的是相对路径而运行工作目录不是工程根目录或输出逻辑挂在某个从未触发的分支上。解决在写文件的地方打印new File(.).getAbsolutePath()确认实际工作目录把输出路径改成绝对路径或基于工程根目录拼接。5.3 改了参数但结果完全没变现象修改参数文件后重跑结果和之前一模一样。原因代码里参数是硬编码的参数文件根本没被读取或读取了但被后面的默认值覆盖。解决在参数加载处加打印确认读到的值搜索代码里是否有同名字段的直接赋值优先级高于配置文件。5.4 邻居统计恒为 0现象agent 行为逻辑不触发排查发现邻居数一直是 0。原因context 里没有注册对应的 projection或 projection 的尺寸参数为 0。解决确认new Grid(...)那行确实执行了且宽高来自有效参数在countNeighbors()里打印 projection 对象是否为 null。5.5 多次运行结果差异巨大现象同一组参数跑两次结果差一倍以上。原因随机种子未固定或遍历 agent 的顺序不稳定放大了随机性。解决在初始化处显式设置随机种子对顺序敏感的模型在调度前对 agent 列表排序或使用固定随机序列。6. 把示例改造成自己的模型一个可复用的改造顺序示例包最大的用处是当模板。我的改造顺序固定为四步每步都能独立验证避免一次性改太多导致问题定位不了。第一步换 agent 的状态字段和step()逻辑其他不动跑通确认调度还在工作。第二步改 context 的 projection 类型比如从 grid 换成 network这一步最容易出问题改完先只跑 10 个 tick 看邻居统计是否合理。第三步调参数文件把 agent 数量、步数、种子做成可配置用 4.1 的批量脚本跑小规模实验。第四步加输出把你要分析的指标按 tick 写进 csv再套 4.2 的聚合脚本。改造过程中有一个检查表值得固定下来检查项通过标准不通过先查入口类能启动控制台无异常堆栈Build Path、JDK 版本仿真推进到设定步数最终 tick 等于参数值调度间隔、异常吞没邻居统计非零抽样 agent 邻居数大于 0projection 注册、尺寸参数输出文件生成output/下有本次运行文件工作目录、写文件分支多次运行有分布同参数结果有均值有波动随机种子、遍历顺序这张表我每次改完模型都过一遍比事后翻日志快得多。Repast 这类框架的坑大多不在算法而在「配置和代码对不上」——参数文件说一套、代码里默认值另一套、运行目录又是第三套。把这三者对齐示例包就从「别人的代码」变成了「你的基线」。从那以后我每次拿到一个仿真示例包都强制先原样跑通、打印最终 tick、确认输出目录再动第一行代码。希望帮到你。本文还有配套的精品资源点击获取