Agent 到底是什么？ 在不同的语境里，它可能是一个简单的自动化脚本，也可能是一个能和人对话、用工具、自己规划任务的复杂系统。名字千变万化，但如果把外壳和工程细节全部剥掉，会发现它们的底层形态惊人地相似。
智能体的本质
从最抽象的层面看，Agent 就是一个持续运行的循环：感知 → 决策 → 行动 → 更新状态。
它有四个稳定的特征：
状态：保存自己的内部情况。
感知：接收并理解外部输入。
决策：根据当前状态和感知选择下一步。
行动：执行动作并影响环境。
如果要用一句公式表达，可以写成：
$$Action = \pi(State, Perception)$$
也就是：行动由当前状态与感知共同决定。
无论是几十年前的有限状态机，还是今天的多智能体架构、LLM Agent，本质上都在用同一个循环回答同一个问题：在当前状态和上下文下，下一步做什么？
FSM：最小化智能体
有限状态机（Finite-State Machine, FSM）是智能体最简单的实现方式。
它把系统的可能情况列成有限个状态，用固定的条件定义它们之间的转移。比如一个简单的游戏角色 AI：巡逻 → 发现敌人 → 追击 → 回到巡逻。
FSM 的好处是简单、可预测、容易验证。但它的局限同样明显：
状态一多，复杂度就会爆炸；它不擅长处理不完全可观测的环境，也缺乏长期记忆和动态目标。
现实世界比一个小游戏复杂得多，于是人们在工程实践中引入了工作流和扩展状态机，来应对更丰富的情境。
工作流与 EFSM：复杂环境的应对
工作流（Workflow）在本质上还是“状态 + 转移”的模型，只是把状态换成了任务节点，并让转移可以由任务完成、数据条件等触发。它扩展了 FSM 的能力：
支持多个任务并行进行。
可以长时间等待外部事件。
转移条件可以依赖上下文数据。
执行过程可以持久化，中断后恢复。
能跨系统编排动作。
扩展有限状态机（EFSM）在理论上走得更远——它不仅有状态，还在状态上挂载了数据上下文。状态转移不再只依赖事件，还可以依赖数据值；动作不仅改变状态，也可以修改数据。
在智能体的语境下，工作流和 EFSM 让系统不仅能“根据环境反应”，还能“带着记忆和条件推理”去行动。
LLM Agent：以 LLM 驱动的可重构状态机
LLM Agent 以大语言模型（Large Language Model, LLM）为核心，通常包含五个模块：感知（perception）、记忆（memory）、决策（decision）、行动（action）、反思（reflection）。与传统 FSM（Finite-State Machine，有限状态机）不同，它并非“修改自己”（不在线更新模型权重 weights），而是用 LLM 来做状态转移决策（state transition decision），并把新产生的状态/转移写入外部可编辑的记忆或流程图（working memory / workflow graph）。
当接到任务时，Agent 会先规划步骤（在外部记忆里生成新的“状态”与“边”），执行后依据结果调整顺序（修改转移规则），必要时插入子任务（扩展状态空间）。这些“自我改造”发生在系统层——对外部状态图/任务板的增删改，并非对 LLM 本身的参数动刀。换句话说，它不只是运行状态机，更是在运行中重写自己的外部状态机。
更有意思的是，外部的 FSM/EFSM（Extended FSM，扩展状态机）也能增强 LLM。在多轮推理或长任务里，单靠自然语言上下文容易松散；若用 FSM/EFSM 显式维护场景结构（任务阶段、关键变量、已执行步骤等），LLM 每次推理都会带着“状态 + 数据”的清晰坐标系，决策更稳定（stability），场景更分明（context disambiguation）。
从 FSM→工作流→EFSM，控制逻辑复杂度逐级上升；LLM Agent 把这条路再向前推了一步：让 LLM 充当转移策略（policy）来驱动状态机的演化，同时用状态机反向为 LLM 提供结构化的环境模型。外形再前沿，核心循环未变：在当前状态与上下文下，决定下一步。
收束
技术演化的轨迹清晰可见：FSM → 工作流 → EFSM → LLM Agent。
形式在变，抽象的内核未变——所有智能体都在围绕状态、感知和决策运转。
真正值得思考的，也许是另一个问题：
当智能体能够自己设计和修改状态机时，它还是“我们编写的系统”，还是已经开始“编写自己”了？