近年来，利用 AI 代理在复杂模拟环境（如《模拟城市》（SimCity））中进行自动化决策与策略探索，已成为研究多智能体系统与通用人工智能（AGI）的重要试验场。一个城市模拟涉及经济、交通、规划、灾害响应等数十个相互关联的子系统，单一代理难以全面掌控。自然的思路是引入多个各司其职的 AI 代理（例如，经济代理、交通代理、规划代理），让它们并行观察、决策并行动。然而，并行化带来了核心挑战：如何协调这些代理的决策，确保它们行动一致，避免因同时修改同一游戏状态而产生冲突，并高效同步全局视图？

本文提出一种工程化解决方案：构建一个基于 REST API 网关的状态机，作为协调多代理并行决策的中心枢纽。该设计将游戏模拟器视为一个状态源，将各个 AI 代理视为可执行特定任务的服务，通过定义明确的状态转换工作流来管理整个决策周期。

架构蓝图：网关作为协调中心

整个系统的核心是一个强化版的 API 网关。它不仅仅是请求的路由器，更内嵌了一个状态机引擎，负责驱动多代理协同工作流。架构主要包含以下组件：

  1. REST API 网关：提供统一的 HTTP 入口。接收来自外部的控制指令（如开始新一轮模拟），更重要的是，它接收来自各个 AI 代理的 “决策就绪” 信号和决策结果。网关根据当前状态机的状态，决定将请求路由至何处（例如，转发给游戏模拟器 API 执行操作，或通知其他代理更新本地状态）。
  2. 状态机引擎：定义并执行协调逻辑。我们将其建模为一个有限状态机，关键状态包括：
    • IDLE：初始状态，等待模拟开始。
    • COLLECTING_STATE：网关从游戏模拟器拉取最新的全局状态快照。
    • AGENT_DECIDING：已将状态分发给相关代理，等待它们并行计算决策。
    • EXECUTING_ACTION：按序或按优先级执行代理提交的、已通过冲突检查的操作。
    • SYNCING：将执行结果同步回所有代理，更新其本地上下文。
    • ERROR：处理超时、冲突无法解决或游戏 API 错误。 状态转换由事件触发，如 game_tick_advanced（进入收集状态）、all_agents_ready（进入执行状态）、action_executed（进入同步状态）。
  3. AI 代理客户端：每个代理作为一个独立服务，通过轻量级 SDK 与网关通信。SDK 封装了状态获取、决策提交、心跳保活等功能。代理在 AGENT_DECIDING 状态期间，从网关获取状态快照，在本地运行模型（如 RL 策略、LLM 规划器），并在超时前将决策（例如，“在坐标 (X,Y) 修建一条道路”）提交回网关。
  4. 游戏模拟器适配器：封装与 SimCity 游戏引擎或模拟器 API 的交互。由于游戏可能仅提供原生协议（如内存读写、特定 SDK），适配器将其转换为 RESTful 接口，供网关调用以获取状态和执行操作。
  5. 持久化存储：用于保存状态机当前状态、历史决策日志、代理性能指标等，便于故障恢复和监控分析。

实现细节与可落地参数

1. 网关与路由设计

网关采用异步、非阻塞架构（如基于 Node.js、Go 或 Java NIO），以应对大量代理的并发心跳和决策提交。为不同代理类型定义清晰的路由前缀，例如 POST /api/v1/agent/traffic/decision 提交交通代理决策。网关需要实现请求队列和优先级管理，确保关键代理（如灾害响应）的决策能被优先处理。

2. 状态机定义与持久化

状态机定义建议使用成熟的 DSL（如 Amazon States Language）或直接在代码中定义枚举和转换表。每次状态转换都应持久化到数据库（如 Redis 或 PostgreSQL），并附带上下文（如触发事件、涉及代理 ID）。这确保了网关实例重启后能从最近的一致状态恢复。例如，在 AGENT_DECIDING 状态，需要记录哪些代理已提交、哪些超时，以便决定是进入执行状态还是错误状态。

3. 冲突检测与解决机制

这是并行决策的核心。当多个代理的决策同时修改游戏的同一实体（如同一块地皮）或存在资源竞争（如预算不足）时，冲突发生。网关在 EXECUTING_ACTION 前需进行冲突检测。

  • 检测：基于决策的 “影响域” 分析。例如，修建道路的决策会影响沿线单元格；调整税率的决策影响全局。网关维护一个简单的资源依赖图进行快速冲突判断。
  • 解决：采用可配置的策略。一种实用策略是基于优先级的排队。为每类代理分配静态优先级（如灾害响应 > 基础设施 > 经济）。当冲突发生时，高优先级代理的决策先执行，低优先级决策被放入队列，等待下一周期基于更新后的状态重新评估或直接驳回。另一种策略是微调和协商，网关将冲突反馈给相关代理，要求它们在限定时间内重新提交调整后的决策，这更适合协作型场景。

4. 关键可配置参数清单

系统的行为由一组关键参数控制，这些参数应暴露为配置项：

# 协调参数
decision_timeout_ms: 5000        # 代理单次决策最大耗时，超时则视为决策失败
state_sync_interval_ms: 1000     # 网关从游戏拉取状态快照的最小间隔
max_parallel_agents: 10          # 允许同时进行决策的代理最大数量
conflict_resolution: "priority_based" # 冲突解决策略，可选 priority_based, negotiate, random

# 容错与重试
max_retry_attempts: 3            # 游戏 API 调用失败重试次数
circuit_breaker_threshold: 5     # 连续失败次数触发熔断
agent_heartbeat_interval_ms: 30000 # 代理心跳间隔，用于存活检测

# 监控采样率
telemetry_sampling_rate: 0.1     # 发送到监控系统的遥测数据采样率

5. 监控与可观测性

为了确保系统稳定运行，必须建立全面的监控仪表板：

  • 延迟指标：网关处理请求的 P95/P99 延迟；游戏状态获取延迟；代理决策计算延迟分布。
  • 成功率指标：状态机各步骤转换成功率；代理决策提交成功率；游戏操作执行成功率。
  • 业务指标：每模拟刻（tick）处理的决策数量；冲突发生频率与类型分布；各代理的平均决策价值（如带来的城市评分提升）。
  • 系统资源：网关 CPU / 内存使用率；数据库连接池状态；消息队列深度。

使用 Grafana 等工具可视化这些指标，并设置告警规则（如连续 5 个周期决策成功率低于 90%）。

总结与展望

本文设计的 REST API 网关状态机，为 SimCity 这类复杂环境下的多 AI 代理并行决策提供了一个结构化的协调框架。它将混乱的并行操作纳入一个可控的状态流程中，通过明确的规则处理冲突和同步，使得多代理系统更易于调试、监控和扩展。

该架构的优势在于其通用性。它不限于 SimCity，可适配其他具有 API 接口的模拟环境（如《城市：天际线》、交通模拟器、经济模拟器）。通过替换游戏适配器和调整代理的决策模型，即可快速搭建新的多代理实验平台。

当然，当前设计也有其局限性。REST API 的请求 - 响应模型在极高频的交互中可能引入开销。对于需要更低延迟、更高吞吐量的场景，未来可考虑将部分通信升级为 WebSocket 或 gRPC 流。此外，状态机的逻辑可能随着代理种类和游戏规则的复杂化而变得臃肿，未来可探索将状态机本身也部分分布式化，引入层次化或联邦式的协调机制。

正如 AWS 在其云设计模式中所强调的，将业务流程编排与业务逻辑分离是构建健壮分布式系统的关键。将这一模式应用于 AI 代理与游戏模拟的交互，正是这一原则的一次生动实践。通过精心设计的网关状态机，我们能够让多个 “AI 市长” 在数字城市中高效、和谐地共治，共同探索更优的城市发展蓝图。

资料来源

  1. Hacker News 讨论：AI agents playing SimCity (作为项目灵感与问题背景参考)。
  2. AWS Prescriptive Guidance: API Gateway and State Machine Integration Pattern (作为网关与状态机集成的技术设计参考)。