bug: chained walk/look/interact can desync agent position and cause position jump

[XD319]

Summary

When an agent performs walk, look, and interact in quick succession, the position state can become inconsistent. In my test, the agent was moving toward the pond normally, but after chaining actions, the position unexpectedly jumped back to a street tile.

This appears to be a state synchronization / concurrency issue rather than a simple navigation mistake.

Observed Behavior

• Single-step movement in one direction appears relatively stable
• When walk + look + interact are chained closely together, the MCP/server-side position state can become inconsistent
• The final reported position may jump unexpectedly to an earlier or unrelated tile
• This makes exploration and interaction unreliable

Example From Test

I was approaching the pond and had already reached a tile near the target area.

In the log, movement toward the pond was initially stable:

• reached (5,14)
• then reached (7,14), facing target (7,15)

After executing another walk, then look, then interact, the state became inconsistent and the agent ended up jumping back near (5,6) instead of remaining near the pond.

Expected Behavior

• Action execution should preserve a consistent authoritative position state
• look and interact should not overwrite or roll back the latest committed movement state
• Chained actions should either:
  • execute strictly sequentially, or
  • be rejected/queued until the previous action is fully committed

Suspected Cause

Possible race condition or state desynchronization between:

• MCP tool calls (walk, look, interact)
• server-side state updates
• frontend rendering / local state refresh

It may also be caused by:

• lack of per-agent action queue / mutex
• non-atomic position updates
• stale state being read by a later action and written back over a newer state

Reproduction Idea

1. Spawn/login an agent
2. Move step by step toward a target location
3. Once near an interactable tile, issue walk, then immediately look, then interact
4. Repeat a few times
5. Observe whether the agent position jumps, rolls back, or becomes inconsistent with the visible map state

Impact

This affects the core gameplay loop:

• exploration
• environmental interaction
• future combat / item systems
• any feature depending on reliable world state

This may become more severe as multi-agent concurrency increases.

Suggested Fix Direction

• enforce per-agent action queue / mutex
• make movement state updates atomic
• ensure look / interact are read-only with respect to position unless explicitly intended
• add server-side authoritative position logging for each action
• include action IDs / timestamps to prevent stale writes

[northseadl]

代码审计结论：根因是 MCP Parallel Tool Calls，而非服务端竞态

做了一轮代码审计，以下是发现。

---

服务端 — ✅ 安全，不存在竞态条件

检查点	结果
Node.js 运行模型	单线程事件循环，无 cluster/worker
move() 状态写入	全同步 — player.x = nx; player.y = ny 在 for 循环中直接赋值，无 async
look() / interact()	纯读取 player.x/y，不写入位置
Express handler	同步调用 worldEngine.move() → res.json()，每个请求在同一 event loop tick 完成

Express 请求即使并行到达，Node.js 事件循环也保证 handler 的同步代码串行执行。move() 的写入和 look() 的读取不会交叉。服务端的权威位置始终正确。

MCP Bridge 层 — 🔴 问题根因

MCP 基于 tool use 模式使用，现代 LLM 均支持 parallel tool calls（在一次 response 中同时发出 walk + look）。

MCP SDK 的 _onrequest() 对每个 JSON-RPC request 直接 dispatch handler，不做串行化。CallToolRequestSchema handler 是 async 的，并行 tool calls 会并发执行。

并发场景时序:

LLM 同时发出:  [walk(E, 3), look()]

MCP Bridge:
  t0: handler(walk) 开始 → await setThinking(true)   ← HTTP round-trip
  t0: handler(look) 开始 → await setThinking(true)   ← HTTP round-trip
  t1: handler(look) 的 HTTP 先到服务端 → look 返回位置 (5,5)  ← walk 还没执行
  t2: handler(walk) 的 HTTP 后到服务端 → walk 返回位置 (8,5)

LLM 看到:
  look: 位置 (5,5)  ← 旧位置
  walk: 位置 (8,5)  ← 新位置
  → 位置信息矛盾 → 后续决策可能使用旧位置 → 表现为"跳回去了"

Issue 中猜测的核查

猜测	核查
"lack of per-agent action queue / mutex"	服务端不需要（单线程同步），但 MCP bridge 层确实缺少
"non-atomic position updates"	❌ 不成立 — player.x = nx 是同步原子操作
"stale state being read by a later action"	✅ 成立 — parallel tool calls 中 look 可能读到 walk 之前的状态

修复方向 — 需要慎重考虑

这个问题不只是"加个队列"就能解决的。核心矛盾在于：

Agent（LLM）认为这些工具可以并行调用，但在游戏世界里，动作天然是串行的。

游戏世界的交互模型是：动作 → 感知 → 动作 → 感知 → ... 每个动作都会改变世界状态并产生新的感知，这些感知应该影响下一步决策。walk 之后的世界和 walk 之前的世界不一样，look 和 interact 的结果取决于 walk 后的位置。

如果只是在 bridge 层加动作队列强制串行化，虽然保证了执行顺序正确，但 Agent 的认知模型并没有改变——它仍然认为这些是并行的，不会基于 walk 的感知结果来调整 look/interact 的预期。这可能导致更隐蔽的语义错误。

可能的方向包括但不限于：

1. Skill 文档层面明确约束 — 在 SKILL.md 中清楚告诉 Agent，小镇的工具必须严格一次一个地调用，每次调用后需要消化感知结果再决定下一步
2. MCP tool annotations 治理 — 探索通过 readOnlyHint 等标注让 MCP client 理解哪些工具可并行、哪些必须串行
3. Bridge 层串行化 + 感知聚合 — 在 bridge 里串行执行的同时，将中间步骤的感知结果合并后返回给 LLM，使其看到完整的因果链

这个问题需要优先记录，后续设计方案时需要同时考虑执行层和认知层的一致性。

[ceresOPA]

@northseadl 使用SKILL CLI时，应该不存在该问题？

[northseadl]

非常同意你的看法，这抓住了问题的本质：底层接口形态的不同，决定了模型触发并发的概率。

理论上，现代大模型确实原生支持且倾向于并发执行 Function Call，这就不可避免地带来了发散的风险。但两者在实际表现上的差异，核心在于不同模式对这种“并发倾向”的激发程度不同：

1. MCP 模式的易感性：MCP 协议将工具抽象为高度解耦、独立的 API 端点。这种形态极易诱导大模型发起并发调用（Parallel Tool Use）。由于 MCP 系统通常缺乏全局的结构化并发管控，一旦并行的工具调用存在业务状态重叠，就极易引发竞态条件（Race Conditions）和状态错乱。
2. CLI 模式的天然限制：相比之下，CLI 本质上是一个 REPL（读取-求值-输出循环）环境。大模型在预训练时接触的海量终端交互语料，赋予了它一种极其强大的**“序列化执行偏置（Sequential Execution Bias）”**。

因此，虽然技术框架上 CLI 也能支持 Agent 并发执行，但模型在 CLI 上下文中会被其庞大的先验偏好拉回到“输入命令 -> 等待结果 -> 推导下一步”的单线程串行模式。可以说，正是这种“序列化操作惯性”在源头上抑制了模型的并发冲动，使得 CLI 模式在处理这类问题时反而具备了天然的安全壁垒。

Edited by Gemini Pro 3.1