State machines in 2 minutes

📝 摘要

David K. Piano（XState 作者）在这篇短文中指出，业界反复"重新发现"几十年来已有的软件工程模式（actor model、state machines），却把它们包装成创新。他用两分钟讲清状态机的本质：它就是一个回答"给定当前状态、事件发生时下一状态是什么"的函数 (state, event) → nextState，这是所有程序、应用、算法底层都遵循的"物理学"。有限状态机可可视化为图（状态=节点、转移=边），显式建模带来两大保证：任何时刻恰好处于一个状态（无不可能状态）、只能沿定义的边转移（无未定义行为）。作者进一步把 loop、agent graph 统一到状态机模型——loop 不过是最简单的双状态机（looping/done），复杂 agent 逻辑（retry、backtrack、等待人类、循环验证）本质上就是带环的状态机/图。结论：构建复杂 agent 逻辑与多智能体架构真正值得学的是 state machines 和 actor model，无需库（switch/对象即可），复杂场景可借助 XState。

核心概念： 状态机 = (state, event) → nextState 函数，是所有代码的底层模型；loops、graphs、agent 流程本质上都是状态机/图，没有什么是新发明。

关键技术栈 / 关键要点：

状态机的本质 — (state, event) → nextState，描述一切程序、应用、算法的状态转移
图即状态机 — 有限状态机可视化为图：状态是节点、转移是边；loops 是有向有环图
两大保证 — 恰好处于一个状态（无不可能状态）；只能沿定义边转移（无未定义行为）
Agent 图 = 状态机 — 复杂 agent 的 retry/backtrack/等待人类/循环验证逻辑本质上是带环状态机
无需库 — switch 或对象/dict 即可实现；复杂场景可用 XState；statecharts 是其进阶形态
Actor model + 状态机 — 构建复杂 agent 逻辑与多智能体架构真正值得学的两个概念

关键结论 / 实践建议： 不要被 loop、graph 等"新"概念炒作迷惑，它们都是状态机的变体；构建复杂 agent 与多智能体系统时，应直接应用成熟的 state machines + actor model 模式，而非反复重新发明轮子。

First it was loops. Now it's graphs. Next month it'll be something else.

Here's the thing: we're constantly rediscovering decades-old software engineering patterns and repackaging them as innovations or whatever, instead of just applying what we've already known for a long time. Two patterns I keep seeing rediscovered over and over are the actor model and state machines. I already wrote a 2-minute explanation of the actor model (https://x.com/DavidKPiano/status/2033132659795194367), so now take 2 minutes to understand state machines, because that's really all you need (and what I've been talking about incessantly for 10+ years).

A state machine is very simple. It's a thing that answers one question:

Given the current state, when an event occurs, what is the next state?

Or as a function:

(state, event) → nextState

That's it. And that function describes every program, application, and algorithm ever written, because it's a fundamental truth of computer science: given some state, something happens that transitions it to the next state. We don't usually *write* our programs this way, but it's the underlying "physics" of how all code works, whether we realize it or not.

One thing I love about state machines is that you can visualize them. A finite state machine has a finite set of states and a finite set of events that cause transitions between those states. It's basically the same (state, event) → nextState function, just visualized as a graph: states are nodes, transitions are edges.

A simple state machine; if you can read words and follow arrows, you already know how to read it

Making this explicit gives you two guarantees for free:

You will always be in exactly one state* (no more impossible states)
You can never transition anywhere except along a defined edge (no undefined behavior, by construction)

Ok, but what about loops and graphs?

Surprise... loops are graphs: directed, cyclic ones. A loop is also just about the most basic state machine there is: two states, "looping" and "done":

This is the silly thing you all hyped for weeks

And when we talk about "agent graphs," we're really describing how an agent moves through different "steps" to accomplish some task. But those steps aren't always sequential, and they aren't always acyclic either (sorry, DAG lovers): agents retry, backtrack, wait for humans, loop until verified. Map out an agent with realistically complex logic and it looks like this:

Contrived example, but you get the idea

That's a state machine. That's also a graph. State machines are graphs. The nodes and edges have precise meaning: which states exist (nodes), which events matter (edge labels), and where they lead (edges).

So loops, graphs, whatever comes next month: it's all the same underlying model. State machines and the actor model are the two concepts actually worth learning for building complex agent logic and multi-agent architectures. Nothing is new; don't fall for the hype. We're just reapplying well-known software patterns (and that's a very good thing IMO), just repackaged for whatever reason.

Also you don't need a library for this. A simple `switch` statement or an object/dict works in every programming language. But if you want to build more complex state machines and statecharts*, I created XState to help you: https://github.com/statelyai/xstate

Happy graphing! 🟡→🟢 *I'll talk about statecharts in the next article. They bring state machines to the next level and make them much more useful to work with for complex logic, but are still technically state machines.

📝 摘要 #

📝 摘要