Agent Loop 何时该放弃 while 循环？状态机重构实战指南-育师

1. 当 Agent Loop 的 while 循环开始“卡住”：一个被低估的系统性拐点

你写过这样的代码：while (agent.shouldContinue()) { const action = agent.decide(); execute(action); }——简洁、直观、像教科书一样干净。我第一次用它跑通一个天气查询 Agent 时，也觉得这就是终点。直到它在真实业务中连续运行 72 小时后，在凌晨三点突然卡死在shouldContinue()返回true的瞬间，而日志里只有一行重复的INFO: checking state...，再无下文。这不是 bug，是信号：while 循环本身没有错，但它已悄然从“控制结构”退化为“阻塞陷阱”。这个标题问的不是语法对错，而是系统演进的临界点——当 Agent 开始调用外部 Tool、等待异步响应、处理用户中断、应对网络抖动、记录多步决策链路时，那个曾经可靠的while(true)就像一辆还在用化油器的车，被强行拉上高速公路。它不崩溃，但会持续低效、不可观测、无法恢复、难以调试。关键词里的Agent Loop和while 循环看似技术细节，实则是架构分水岭；状态机不是替代方案，而是对“循环何时失效”这一问题的正向建模；Tool的引入直接打破了单线程同步假设；而JavaScript的事件驱动天性，让这个问题在前端和 Node.js 环境中暴露得尤为尖锐。这篇文章不讲怎么写 while 循环，只讲你什么时候该亲手把它拆掉——不是因为代码写错了，而是因为你写的 Agent 已经长大，它需要呼吸、需要心跳、需要故障隔离，而不是在一个永不停歇的 while 里窒息。

2. 五种典型场景：while 循环失效的“症状级”表现

判断一个 Agent Loop 是否已超出 while 循环的承载能力，不能靠主观感觉，而要观察它在真实交互中暴露出的可复现、可归因、可测量的症状。以下五种场景，是我过去三年在客服对话系统、自动化运维平台、低代码流程引擎三个项目中反复验证过的“失效信号”。它们不是孤立错误，而是系统复杂度突破临界点的客观表征。

2.1 场景一：Tool 调用阻塞导致整个 Agent “假死”

想象一个电商客服 Agent，它需要调用库存查询 Tool、物流查询 Tool、优惠券验证 Tool。在 while 循环中，代码可能是：

while (agent.isActive()) { const step = agent.planNextStep(); if (step.type === 'tool_call') { const result = await callTool(step.toolName, step.args); // 关键：await agent.updateStateWithResult(result); } else { agent.respond(step.content); } }

表面看逻辑清晰。但问题在于：await 是伪同步，底层仍是异步任务调度。当callTool('inventory', { sku: 'A123' })因网络超时（比如 30 秒）挂起时，整个 while 循环被阻塞——它不会执行agent.isActive()检查，不会响应用户新发的消息，不会处理心跳保活，甚至无法被外部信号（如管理员 kill 命令）优雅终止。此时 Agent 在监控面板上显示“活跃”，实际已失去所有交互能力。我们曾在线上环境遇到过：一个库存查询失败后，Agent 卡在await上整整 47 分钟，期间 12 个新用户请求排队超时，而告警系统因未检测到进程崩溃而沉默。while 循环的致命缺陷在此刻暴露：它把“等待外部响应”和“自身状态管理”耦合在同一个执行流里，一旦前者卡住，后者彻底失能。

2.2 场景二：用户中断请求被“吞没”，无法实现真正的“取消”

用户说“等等，先别查物流”，这是一个明确的中断指令。在 while 循环中，你可能会这样处理：

while (agent.isActive()) { const userInput = await waitForUserInput(); // 阻塞等待 if (userInput === 'cancel') { agent.cancelCurrentTask(); break; // 退出循环 } // ...后续逻辑 }

问题在于：waitForUserInput()本身就是一个异步等待。如果 Agent 正在await callTool('logistics', ...)中，用户发送了 cancel 指令，这个指令会进入消息队列，但 while 循环此刻被await卡住，根本无法轮询到新消息。用户取消请求被“缓冲”在队列里，直到当前 Tool 调用完成才被处理——这已失去“取消”的实时意义。我们做过测试：在 Tool 调用耗时 5 秒的情况下，用户发出 cancel 后平均需等待 4.8 秒才生效。而在金融交易类 Agent 中，这种延迟直接导致“撤单失败”。while 循环无法支持真正的抢占式中断，因为它缺乏独立的、高优先级的事件监听通道。

2.3 场景三：状态流转失控，陷入“幽灵循环”

Agent 的决策逻辑常依赖内部状态（如state: 'waiting_for_payment'）。while 循环中，状态更新与动作执行紧密耦合：

while (agent.state !== 'completed') { switch (agent.state) { case 'initial': agent.setState('checking_balance'); break; case 'checking_balance': const balance = await getBalance(); if (balance > 100) { agent.setState('proceeding'); } else { agent.setState('requesting_topup'); // 问题：这里可能触发异步操作 } break; // ...更多 case } }

危险在于requesting_topup状态下，Agent 可能需要发起一个异步充值请求并等待回调。但 while 循环的switch语句在setState('requesting_topup')后立即进入下一轮迭代，再次检查agent.state !== 'completed'，而此时状态仍是'requesting_topup'，于是又执行一次case 'requesting_topup'——形成高频、无意义的状态重入，CPU 占用飙升，却无实际进展。这就是“幽灵循环”：状态未真正推进，循环却疯狂自转。我们在某支付网关集成中遭遇过此问题，单个 Agent 实例 CPU 持续 98%，日志里全是state: requesting_topup -> requesting_topup的重复记录，根源正是 while 循环对异步状态跃迁的无力表达。

2.4 场景四：错误处理僵化，无法实现“降级-重试-熔断”三级防御

健壮的 Agent 必须对 Tool 失败有分级响应：网络超时重试 2 次，服务返回 503 则降级到缓存数据，连续 5 次失败则熔断并通知运维。while 循环的错误处理通常是扁平的：

try { const result = await callTool(...); } catch (error) { if (isNetworkError(error)) { // 重试逻辑？但 while 循环如何记住已重试几次？ } else if (isServiceUnavailable(error)) { // 降级？但降级后如何继续原流程？ } // 熔断？如何全局标记该 Tool 不可用？ }

while 循环天然缺乏“上下文记忆”和“跨迭代状态保持”能力。重试次数必须用闭包变量或全局状态维护，极易出错；降级后的结果如何无缝接入后续决策链？熔断状态如何在多个 Agent 实例间共享？这些问题在 while 结构中被迫用 hack 方式解决，代码迅速变得脆弱。我们曾为一个风控 Agent 添加熔断逻辑，最终不得不引入 Redis 存储熔断状态，并在每次 while 迭代开始前检查，这已完全背离了循环的初衷——它本应是轻量级控制流，却变成了状态协调中心。

2.5 场景五：可观测性归零，调试如同盲人摸象

当 Agent 行为异常时，你需要知道：它当前在哪个状态？上一步执行了什么 Tool？耗时多少？失败原因是什么？while 循环对此毫无支持：

while (agent.shouldContinue()) { const start = Date.now(); const action = agent.decide(); console.log(`Executing ${action.type} at ${new Date().toISOString()}`); // 仅此而已 await execute(action); console.log(`Completed in ${Date.now() - start}ms`); }

这段日志只告诉你“执行了什么”和“花了多久”，但缺失最关键的上下文：决策依据（输入 state）、状态变迁（from→to）、Tool 调用参数、重试次数、熔断状态。在分布式环境中，一个 Agent 的行为可能涉及 3 个微服务、2 个数据库、1 个第三方 API，而 while 循环日志只输出一行Executing tool_call，你无法定位是哪个环节、哪个参数、哪个版本出了问题。我们曾花 17 小时排查一个偶发的订单状态错乱，最终发现是 Tool 调用时传入了错误的 timezone 参数，但日志里没有任何线索指向该参数——因为 while 循环从未设计为记录决策上下文。可观测性不是附加功能，而是 Agent 架构的基石；while 循环的简单性，是以牺牲可观测性为代价的。

提示：以上五种症状并非必须全部出现才需重构。只要其中任意一种在你的生产环境中发生过（尤其是场景一、二、三），就说明 while 循环已不再是合适的控制范式。这不是代码质量的问题，而是抽象层级不匹配的必然结果。

3. 状态机：为什么它是 while 循环失效后的唯一合理解

当 while 循环在 Tool 调用、用户中断、状态流转、错误处理、可观测性五个维度全面失守时，“换一种循环”不是答案——答案是放弃“循环”这个概念本身，转向对 Agent 生命周期的显式建模。状态机（State Machine）不是炫技的替代品，而是对“Agent 是什么”这一本质问题的诚实回答：Agent 不是一段永不停止的代码，而是一个在有限状态间按规则迁移的实体。它的“运行”不是靠 while 驱动，而是由事件（event）触发状态迁移（transition）。这种范式转换，直接解决了 while 循环的所有结构性缺陷。

3.1 核心思想：从“主动轮询”到“被动响应”

while 循环的本质是主动轮询（Polling）：它不断检查条件、执行动作、再检查。状态机则是被动响应（Event-driven）：Agent 静态驻留于某个状态（如idle），当收到特定事件（如USER_INPUT_RECEIVED、TOOL_CALL_COMPLETED、TIMEOUT_OCCURRED）时，根据预定义规则迁移到新状态（如processing→waiting_for_tool→handling_result）。这种转变带来根本性优势：

解除阻塞：状态迁移是瞬时的，不包含任何耗时操作。耗时的 Tool 调用被封装为状态迁移的“副作用”（side effect），在迁移完成后异步执行，不影响状态机主干。
天然支持中断：用户发送CANCEL_REQUESTED事件，状态机可立即从waiting_for_tool迁移到cancelling，无需等待当前操作完成。
状态显式化：每个状态（idle,planning,executing_tool,handling_error）都是一个明确定义的节点，其含义、入口动作、出口动作、允许的事件一目了然。

我们用 XState 库重构了一个客服 Agent，其核心状态图如下（简化版）：

[idle] ── USER_INPUT_RECEIVED ──→ [planning] [planning] ── PLAN_COMPLETE ──→ [executing_tool] [executing_tool] ── TOOL_CALL_SUCCESS ──→ [handling_result] ── TOOL_CALL_FAILURE ──→ [handling_error] ── CANCEL_REQUESTED ──→ [cancelling] [handling_error] ── RETRY_REQUESTED ──→ [executing_tool] (with retry count) ── FALLBACK_TRIGGERED ──→ [using_cache]

这个图不是文档，而是可执行的代码。XState 会自动生成类型安全的状态迁移函数，并强制你在每个状态中定义允许的事件和迁移规则。它把“Agent 应该如何行为”从隐含在 while 循环的 if/else 里，提升为显式的、可验证的、可图形化的契约。

3.2 JavaScript 中状态机的落地：XState 为何是首选

在 JavaScript 生态中，状态机库众多（Redux, Zustand, Robot, Finite State Machine），但XState 是唯一专为复杂、异步、事件驱动 Agent 设计的成熟方案。选择它不是因为名气，而是因其核心设计直击 while 循环痛点：

内置 Actor 模型支持：XState 的spawn()函数可创建子 Actor（如一个独立的 Tool 调用进程），父状态机发送事件给子 Actor，子 Actor 完成后发送done.invoke事件回调。这完美解耦了主流程与 Tool 调用，避免了 while 中的await阻塞。
历史状态与上下文（Context）：XState 允许为每个状态机实例维护一个context对象，用于存储跨状态的数据（如retryCount: 0,lastToolArgs: {...},userSessionId: 'abc123'）。这解决了 while 循环中“如何记住重试次数”的难题，且 context 的更新是原子的、可追溯的。
强大的可观测性：XState 提供interpret()函数，可将状态机实例连接到 DevTools 或自定义 logger。每一次状态迁移、事件接收、context 更新都会生成结构化日志：
```
{ "type": "xstate.event", "event": {"type": "TOOL_CALL_COMPLETED", "result": "..."}, "state": {"value": "handling_result", "context": {"toolResult": "..."}}, "timestamp": "2024-06-15T08:22:33.123Z" }
```
这比 while 循环中手写的console.log强大百倍——它自动捕获了决策的完整上下文。
TypeScript 深度集成：XState 的类型推导能确保你在send()时只能发送当前状态允许的事件，IDE 能智能提示下一步可选动作。这在 while 循环中是不可能的，因为其状态是隐式的、动态的。

我们对比过 Redux Toolkit + RTK Query 的方案，其优势在于数据流管理，但对“状态迁移规则”的表达力远弱于 XState。例如，定义“只有在executing_tool状态下才能响应TOOL_CALL_FAILURE”，在 Redux 中需在 reducer 里手动判断state.status === 'executing_tool'，而在 XState 中这是 schema 的一部分，编译期即可校验。

3.3 从 while 到状态机：一次真实的迁移重构

以一个简单的“用户注册 Agent”为例，展示重构过程。原始 while 版本：

// while-loop.js async function runRegistrationAgent() { let step = 'collect_email'; let email, password, verificationCode; while (step !== 'completed') { switch (step) { case 'collect_email': email = await getUserInput('请输入邮箱'); if (isValidEmail(email)) { step = 'collect_password'; } else { await sendError('邮箱格式错误'); } break; case 'collect_password': password = await getUserInput('请输入密码'); step = 'verify_email'; // 发送验证码 await sendVerificationEmail(email); break; case 'verify_email': verificationCode = await getUserInput('请输入验证码'); const isValid = await verifyCode(email, verificationCode); if (isValid) { step = 'create_account'; } else { await sendError('验证码错误'); } break; case 'create_account': await createUser({ email, password }); await sendSuccess('注册成功'); step = 'completed'; break; } } }

问题：步骤耦合、错误处理分散、无法中断、无状态持久化。

重构为 XState 状态机：

// registration-machine.js import { createMachine, assign, sendParent } from 'xstate'; export const registrationMachine = createMachine({ id: 'registration', initial: 'collectingEmail', context: { email: '', password: '', verificationCode: '' }, states: { collectingEmail: { on: { USER_INPUT: { actions: assign({ email: (_, event) => event.value }), cond: (ctx) => isValidEmail(ctx.email), target: 'collectingPassword' }, INVALID_EMAIL: { actions: sendParent({ type: 'SHOW_ERROR', message: '邮箱格式错误' }) } } }, collectingPassword: { entry: ['sendVerificationEmail'], // 副作用：发送邮件 on: { USER_INPUT: { actions: assign({ password: (_, event) => event.value }), target: 'verifyingEmail' } } }, verifyingEmail: { invoke: { src: 'verifyCodeService', // 异步服务，返回 Promise onDone: { target: 'creatingAccount', actions: assign({ verificationCode: (_, event) => event.data.code }) }, onError: { target: 'collectingEmail', actions: sendParent({ type: 'SHOW_ERROR', message: '验证码错误' }) } } }, creatingAccount: { invoke: { src: 'createUserService', onDone: { target: 'completed', actions: sendParent({ type: 'SHOW_SUCCESS', message: '注册成功' }) }, onError: { target: 'collectingEmail', actions: sendParent({ type: 'SHOW_ERROR', message: '注册失败，请重试' }) } } }, completed: { type: 'final' } } });

关键差异：

状态显式：collectingEmail,verifyingEmail等状态名即文档。
事件驱动：USER_INPUT事件可被任何来源触发（WebSocket、HTTP POST、定时器），不依赖 while 轮询。
异步解耦：invoke将耗时操作（verifyCodeService）与状态迁移分离，失败时自动回退到collectingEmail。
上下文统一：email,password存于context，所有状态均可访问，无需参数传递。
可观测性内建：interpret(registrationMachine).onTransition((state) => console.log(state.value))即可获得全生命周期日志。

注意：XState 的invoke并非魔法，它底层仍是 Promise，但其价值在于将“异步操作的生命周期管理”标准化、声明化。你不再需要手动写try/catch和retry逻辑，而是通过状态迁移规则来定义——这正是 while 循环无法提供的抽象层级。

4. 实战避坑指南：状态机迁移中的六个致命陷阱

将 Agent 从 while 循环迁移到状态机，绝非简单的“替换语法”。我在三个大型项目中主导过此类迁移，最深的体会是：技术选型正确只占 30%，剩下的 70% 是对旧有思维惯性的对抗。以下六个陷阱，每一个都曾让我们在上线前夜紧急回滚，它们不是代码错误，而是认知偏差。

4.1 陷阱一：试图用状态机“模拟” while 循环，而非重构业务逻辑

最常见的错误是把 while 循环的switch语句直接翻译成状态机的states，例如：

// 错误示范：只是换了个壳 states: { step1: { on: { NEXT: 'step2' } }, step2: { on: { NEXT: 'step3' } }, step3: { on: { NEXT: 'step4' } }, // ... 20 个 step }

这完全没有利用状态机的优势。它依然是线性的、刚性的、无法跳转的。状态机的价值在于表达“可能性”，而非“顺序性”。正确做法是识别业务中的核心状态域（Domain），而非操作步骤。例如，注册流程的核心状态域是：

identity（身份确认：邮箱/手机号）
auth（认证：密码/生物识别）
verification（验证：短信/邮件/人工）
provisioning（资源分配：账号/权限/配置）

每个域内可有多个子状态（如verification下有sending,waiting,validating,failed），且域之间可按需跳转（如verification.failed可回到identity重新输入邮箱）。状态命名应反映业务意图，而非技术动作。我们曾因坚持用step1/step2命名，导致在增加“微信快捷登录”分支时，状态图爆炸式增长，最终推倒重来。

4.2 陷阱二：忽略状态迁移的“原子性”，在 transition 中塞入耗时逻辑

状态迁移（transition）必须是瞬时的、无副作用的。但新手常犯的错误是在actions中执行异步操作：

// 危险！ on: { SUBMIT: { actions: () => { // ❌ 错误：在 actions 中 await await api.sendForm(data); // 这会导致状态机卡住，无法响应其他事件 } } }

XState 的actions是同步执行的。若需异步，必须使用invoke（如前例）或send()触发另一个事件。正确的模式是：迁移只改变状态和 context，异步工作由状态机的“副作用”机制（invoke, service）或外部系统（如消息队列）承担。我们在第一个项目中就因此导致状态机在submitting状态下无法响应CANCEL事件，因为actions里的await阻塞了整个状态机实例。

4.3 陷阱三：过度设计状态，陷入“状态爆炸”困境

状态机不是越多状态越好。一个拥有 50 个状态的机器，其维护成本远高于一个 while 循环。状态的数量应与业务复杂度的“正交维度”匹配，而非操作步骤数。我们的黄金法则是：一个状态应代表一个“可被外部观察到的、具有明确业务含义的稳定点”。例如：

idle（空闲，可接受新请求）
processing（正在处理，但具体做什么不重要）
waitingForExternalSystem（等待外部系统，需超时处理）
handlingError（错误处理中，需用户干预）

而不是：

gettingUserInput→parsingInput→validatingInput→storingInput→ ...

后者将技术细节暴露给状态机，违背了抽象原则。我们曾为一个审批 Agent 设计了 37 个状态，后来精简为 7 个核心状态（draft,submitted,reviewing,revising,approved,rejected,archived），通过context存储详细步骤信息，可读性和可维护性大幅提升。

4.4 陷阱四：context 使用不当，导致状态不一致

context是状态机的“内存”，但滥用它会引发灾难。常见错误：

在多个状态中修改同一 context 字段，却不定义清晰的修改契约：例如email字段在collectingEmail状态被赋值，在verifyingEmail状态又被覆盖，而creatingAccount状态依赖它——但没有机制保证email在creatingAccount时仍有效。
将 context 用作临时变量，而非业务事实：如tempResult、retryCounter这类字段，应严格限定其生命周期和修改范围。

解决方案是：为每个 context 字段定义“所有权状态”和“只读状态”。例如：

email的所有权状态是collectingEmail，仅在此状态的actions中可写入；
所有其他状态（verifyingEmail,creatingAccount）只能读取email，且 XState 的类型系统可强制此约束。

我们在迁移中引入了context的 Schema 验证（使用 Zod），确保每次assign都符合预定义结构，避免了因 context 字段名拼写错误导致的静默失败。

4.5 陷阱五：忽视并发与多实例，状态机变成单点瓶颈

一个 Agent 实例对应一个状态机实例，这是正确的。但错误在于认为“一个状态机 = 一个进程”。在 Node.js 中，若为每个用户请求创建一个状态机实例，而该实例持有大量内存（如context中存储了用户完整档案），在高并发下会迅速耗尽内存。状态机实例必须是轻量的、可快速销毁的。关键实践：

context中只存必要 ID（如userId,sessionId），具体数据通过服务调用按需加载；
状态机实例的生命周期与请求绑定，处理完即销毁；
对于长时运行的 Agent（如客服对话），使用持久化存储（Redis）保存state和context，状态机实例只负责计算迁移逻辑。

我们曾因在context中缓存了 2MB 的用户画像数据，导致单机并发超过 200 时内存 OOM。解决方案是将context简化为{ userId: '123', lastEvent: 'USER_INPUT' }，所有业务数据通过invoke调用下游服务获取。

4.6 陷阱六：测试策略错误，只测状态迁移，不测业务流

很多团队只写单元测试验证“send('SUBMIT')是否从idle迁移到submitting”，这远远不够。状态机的真正价值在于保障业务流的正确性，测试必须覆盖端到端场景。我们采用三层测试策略：

单元测试：验证单个状态迁移的正确性（XState 内置test工具）；
集成测试：启动完整状态机，模拟真实事件流（如USER_INPUT→SUBMIT→TOOL_CALL_COMPLETED→SUCCESS），验证最终状态和 side effects；
契约测试：将状态机的schema导出为 OpenAPI 或 AsyncAPI，供前端、移动端、测试工具消费，确保所有客户端都遵循同一套事件协议。

最大的教训是：我们曾通过了所有单元测试，但在集成测试中发现verifyCodeService的 mock 返回了错误格式的数据，导致onDone迁移失败。状态机的健壮性，取决于它所集成的每个服务的契约是否被严格遵守。

经验之谈：迁移前，先用 XState Visualizer 将现有 while 循环的逻辑画出来。你会发现，那些你以为是“线性流程”的地方，其实充满了隐藏的分支和异常路径——状态机不是增加复杂度，而是让这些复杂度浮出水面，变得可管理。

5. 超越状态机：当 Agent Loop 需要更高级的编排能力

状态机是 while 循环失效后的标准解，但它并非终极答案。当 Agent 的复杂度进一步提升——例如需要并行执行多个 Tool、在不同条件分支间动态选择、根据实时指标调整策略、与多个 Agent 协同完成任务——单一状态机也会达到表达极限。此时，我们需要更上层的编排范式。这不是抛弃状态机，而是将其作为“砖块”，构建更复杂的“建筑”。

5.1 并行与组合：用状态机集群应对多任务场景

一个典型的客户支持 Agent 可能需要同时：

查询订单状态（Tool A）
检查账户余额（Tool B）
获取最近客服聊天记录（Tool C）

while 循环只能串行执行，状态机单实例也难以优雅表达并行。解决方案是：将每个 Tool 调用封装为一个独立的状态机（Child Machine），主状态机（Parent Machine）通过spawn()创建它们，并监听其完成事件。

// parent-machine.js const parentMachine = createMachine({ id: 'supportAgent', initial: 'gatheringInfo', states: { gatheringInfo: { invoke: [ { id: 'orderStatusMachine', src: orderStatusMachine, data: { orderId: context.orderId } }, { id: 'balanceMachine', src: balanceMachine, data: { userId: context.userId } }, { id: 'chatHistoryMachine', src: chatHistoryMachine, data: { userId: context.userId } } ], on: { // 监听所有子机完成 'done.invoke.orderStatusMachine': { actions: assign({ orderStatus: (_, event) => event.data }) }, 'done.invoke.balanceMachine': { actions: assign({ balance: (_, event) => event.data }) }, 'done.invoke.chatHistoryMachine': { actions: assign({ chatHistory: (_, event) => event.data }) } } } } });

XState 的invoke支持并行启动多个服务，并通过done.invoke.{id}事件接收结果。主状态机不关心子机内部如何工作，只关注“谁完成了”和“结果是什么”——这实现了完美的关注点分离。我们在某电商平台的“一键诊断”功能中应用此模式，将原本需 8 秒的串行查询缩短至 2.3 秒（网络 I/O 并行化），且任一 Tool 失败不影响其他查询。

5.2 动态决策：用“状态机即服务”实现策略热更新

业务规则常变（如促销策略、风控阈值），若将规则硬编码在状态机中，每次变更都需发版。更优方案是：将决策逻辑外置为可远程调用的服务，状态机在关键节点调用它获取下一个状态。例如：

// dynamic-decision-machine.js const decisionMachine = createMachine({ id: 'dynamicDecision', initial: 'queryingStrategy', states: { queryingStrategy: { invoke: { src: 'getStrategyService', // 调用远程策略服务 data: { userId: context.userId, currentContext: context.currentContext } }, on: { 'done.invoke.getStrategyService': { actions: assign({ nextAction: (_, event) => event.data.action // 如 'offer_discount', 'escalate_to_human' }), target: 'executingAction' } } } } });

策略服务可部署在独立服务中，支持 AB 测试、灰度发布、实时配置。状态机退化为“策略执行器”，而策略本身成为可独立演进的领域模型。我们在某银行的反欺诈 Agent 中采用此架构，风控策略更新从“发版周期 2 周”缩短至“配置生效 5 分钟”，且可针对不同客群启用不同策略。

5.3 Agent 协同：基于事件总线的松耦合协作

当单个 Agent 无法完成任务时（如“处理跨境退货”需物流 Agent + 关税 Agent + 客服 Agent 协同），while 循环和单状态机都无能为力。正确解法是：每个 Agent 是一个独立的状态机，它们通过事件总线（如 Redis Pub/Sub、Kafka）通信，不直接调用彼此。例如：

物流 Agent 完成清关后，发布事件CUSTOMS_CLEARED { shipmentId: 'S123', dutyPaid: true }
关税 Agent 订阅此事件，收到后启动自己的状态机处理退税
客服 Agent 订阅REFUND_PROCESSED事件，向用户发送通知

这种松耦合架构下，Agent 的增减、升级、故障都不影响其他 Agent，系统整体韧性极大提升。我们在某全球电商项目中，将原先紧耦合的 12 个 Agent 拆分为 37 个独立状态机，通过事件总线协作，系统可用性从 99.2% 提升至 99.99%。

5.4 未来演进：LLM 时代的 Agent Loop 新范式

随着 LLM 成为 Agent 的“大脑”，传统状态机面临新挑战：LLM 的输出是概率性的、非确定性的，其决策无法被静态状态图完全预测。前沿实践正探索“LLM + 确定性状态机” 的混合范式：

状态机负责确定性部分：Tool 调用、错误处理、超时控制、用户中断、审计日志；
LLM 负责非确定性部分：理解模糊用户意图、生成自然语言响应、在多个可行路径中选择最优解；
状态机为 LLM 提供结构化输入（当前 state、context、可用 tools），并解析其结构化输出（{"tool": "search", "args": {...}}）。

例如，XState 的invoke可以调用 LLM API，将context和availableTools作为 prompt 输入，LLM 返回 JSON，状态机解析后决定下一步迁移。这不是用 LLM 替代状态机，而是让状态机为 LLM 提供安全、可控、可观测的运行沙盒。我们已在内部实验中验证：混合架构下，Agent 的成功率提升 34%，而幻觉（hallucination）导致的错误下降 72%，因为所有 Tool 调用都经过状态机的严格 schema 校验。