Agent 状态机与护栏模式：构建可控、可观测、可恢复的智能体系统

Agent 状态机与护栏模式是构建可控、可观测、可恢复的智能体系统的核心设计范式。随着 AI Agent 从简单的单步问答进化为多步自主执行的复杂系统，状态管理和行为约束成为决定系统能否投入生产环境的关键因素。

1.1 Agent 系统的核心挑战

大语言模型本质上是一个无状态的概率生成器——给定输入，生成输出，不保留任何内部状态。但一个真正的 AI Agent 需要在多个步骤之间维持上下文、目标、计划和执行状态。如果状态管理不当，Agent 会出现以下问题：

状态丢失：Agent 在执行多步任务时忘记自己已经做了什么、接下来要做什么，导致重复执行或遗漏关键步骤。

无限循环：Agent 在两个状态之间反复切换，无法推进任务进度——这正是2026 年 AI 工程领域最常见的 Agent 故障模式之一。

行为越界：Agent 执行了预期之外的操作，例如调用了不该调用的工具、访问了不该访问的数据，或者进入了不可恢复的错误状态。

不可观测：开发者和运维人员无法看到 Agent 当前处于什么状态、为什么会做出某个决策、从哪个状态转换到哪个状态。

1.2 状态机：Agent 的结构化骨架

有限状态机（Finite State Machine, FSM）为 Agent 提供了一个结构化的执行骨架。它定义了 Agent 可以处于的所有合法状态、状态之间的允许转换路径、以及每个状态下 Agent 的允许行为。

引入状态机的核心收益：

确定性：在任何时刻，Agent 只能处于预定义的状态之一，而不是任意的、不可预测的中间态。

可验证性：所有的状态转换都经过明确的规则检查，可以验证 Agent 是否按照预期的流程执行。

可恢复性：当 Agent 进入错误状态时，状态机可以定义明确的恢复路径，而不是让 Agent 陷入不可知的故障态。

可观测性：状态机天然提供了状态追踪的能力——每一次状态转换都是一个可记录的事件。

1.3 护栏模式：Agent 的安全边界

如果说状态机定义了 Agent 的正常行为路径，那么护栏模式（Guardrail Pattern）则定义了 Agent 的安全边界。护栏模式的核心思想是：在 Agent 的每个关键决策点和每个状态转换之前，插入安全检查层，确保 Agent 的行为始终在可控范围内。

护栏模式解决的核心问题：

工具调用权限：Agent 是否可以调用某个特定的工具？这个工具是否需要额外的权限验证？

数据访问边界：Agent 是否可以访问特定范围的数据？是否触发了敏感数据保护规则？

输出内容过滤：Agent 生成的输出是否包含不安全的内容？是否符合预定义的输出格式？

资源消耗限制：Agent 的执行是否超过了预定的资源预算（如 API 调用次数、计算时间、Token 消耗）？

有限状态机（FSM）是 Agent 状态管理的理论基础。理解 FSM 的核心概念，是设计高质量 Agent 状态机的前提。

2.1 FSM 的五元组定义

一个有限状态机可以形式化地定义为一个五元组 (Q, Σ, δ, q₀, F)：

Q（状态集合）：Agent 可以处于的所有合法状态的有限集合。例如：{空闲, 规划中, 执行中, 等待工具响应, 错误, 已完成}。

Σ（输入字母表）：Agent 可以接收的所有输入事件的集合。例如：{用户请求, 工具返回结果, 工具调用超时, 用户取消, 内部定时器触发}。

δ（状态转换函数）：从 Q × Σ → Q 的映射函数。给定当前状态和输入事件，确定下一个状态。这是状态机的核心逻辑。

q₀（初始状态）：Agent 启动时处于的初始状态。通常是空闲或等待指令状态。

F（终止状态集合）：Agent 可以正常结束的状态集合。例如：{已完成, 已取消, 失败}。

2.2 Moore 机 vs Mealy 机

在 FSM 理论中，有两种经典的状态机模型：

Moore 机：输出仅取决于当前状态。进入某个状态后，Agent 执行该状态对应的动作。Moore 机的优势在于行为可预测——只要知道当前状态，就知道 Agent 在做什么。

Mealy 机：输出取决于当前状态和输入事件。同一个状态下，不同的输入事件可能触发不同的输出行为。Mealy 机更灵活，但也更难以调试。

在 Agent 系统中的选择：大多数 Agent 状态机采用 Moore 机的变体——每个状态定义了 Agent 在该状态下的行为集合，状态转换由外部事件或内部条件触发。这种设计兼顾了可预测性和灵活性。

2.3 层次状态机（HSM）

当 Agent 的逻辑变得足够复杂时，简单的 FSM 会导致状态爆炸——状态数量呈指数级增长。层次状态机（Hierarchical State Machine, HSM）通过状态的嵌套来解决这个问题。

层次状态机的核心思想：子状态继承父状态的行为和转换规则。例如，一个**「执行中」的父状态下，可以有「数据获取中」、「数据处理中」、「结果生成中」三个子状态。所有子状态共享父状态的超时处理规则和错误恢复逻辑**。

层次状态机的优势：

减少重复：公共的转换逻辑和错误处理只需要在父状态中定义一次。

清晰的层次结构：Agent 的行为可以按照功能模块或任务阶段进行层次化组织。

局部修改不影响全局：修改某个子状态的行为，不会影响其他子状态或父状态的逻辑。

// 有限状态机的 TypeScript 实现
type State = 'idle' | 'planning' | 'executing' | 'waiting' | 'error' | 'completed' | 'cancelled';
type Event = 'START' | 'PLAN_DONE' | 'EXECUTE_DONE' | 'TOOL_RESPONSE' | 'TIMEOUT' | 'CANCEL' | 'RECOVER';

interface Transition {
  from: State;
  event: Event;
  to: State;
  guard?: () => boolean;  // 护栏条件
  action?: () => void;     // 状态转换时的副作用
}

class AgentStateMachine {
  private currentState: State = 'idle';
  private transitions: Transition[] = [];
  private history: Array<{ from: State; event: Event; to: State; timestamp: number }> = [];

  addTransition(t: Transition) {
    this.transitions.push(t);
  }

  dispatch(event: Event): boolean {
    const transition = this.transitions.find(
      t => t.from === this.currentState && t.event === event
    );

    if (!transition) {
      console.warn(`Invalid transition: ${this.currentState} --[${event}]--> ??`);
      return false;
    }

    // 护栏检查
    if (transition.guard && !transition.guard()) {
      console.warn(`Guardrail blocked: ${this.currentState} --[${event}]`);
      return false;
    }

    const previous = this.currentState;
    this.currentState = transition.to;
    transition.action?.();

    this.history.push({
      from: previous,
      event,
      to: this.currentState,
      timestamp: Date.now()
    });

    return true;
  }

  getState(): State { return this.currentState; }
  getHistory() { return [...this.history]; }
}

护栏模式是 Agent 系统中不可或缺的安全层。它确保 Agent 在复杂的多步执行过程中，始终不越界、不失控、不造成不可逆的损害。

3.1 护栏的分类

在 Agent 系统中，护栏可以分为四个层级：

输入护栏（Input Guardrails）：在 Agent 接收到用户输入或外部事件时执行。检查输入是否符合预期格式、是否包含恶意内容、是否超出处理范围。例如：检测用户的 Prompt 是否包含越权指令、是否尝试注入攻击。

决策护栏（Decision Guardrails）：在 Agent 做出关键决策时执行。检查决策是否符合预设的策略、是否超出了 Agent 的权限范围。例如：Agent 决定是否调用某个外部 API，护栏检查该 API 是否在白名单中。

执行护栏（Execution Guardrails）：在 Agent 执行具体操作时监控。检查操作是否超出资源限制、是否触发了安全策略。例如：Agent 正在循环调用搜索 API，护栏检测到调用频率异常，自动熔断。

输出护栏（Output Guardrails）：在 Agent 生成最终输出之前执行。检查输出是否包含敏感信息、是否符合格式要求、是否满足质量标准。例如：Agent 生成了一段代码，护栏检查代码中是否包含硬编码的密钥。

3.2 护栏的设计原则

最小权限原则：每个护栏只检查它职责范围内的事项。不要把所有安全检查都塞进一个万能护栏函数。

快速失败原则：护栏检查应该尽早失败。如果一个请求注定会被拒绝，不要在消耗了大量计算资源之后才拒绝它。

可解释原则：当护栏阻止了一个操作时，必须清晰地记录原因。这不仅有助于调试，也有助于持续改进护栏规则。

可配置原则：护栏的规则应该是可配置的，而不是硬编码的。不同的部署环境（开发、测试、生产）可能需要不同的护栏严格度。

3.3 护栏与状态机的集成

护栏模式与状态机的最佳集成方式是在状态转换函数中嵌入护栏检查。每个转换规则可以关联一个或多个护栏条件，只有当所有护栏条件都满足时，转换才被允许。

集成模式的关键设计：

转换级护栏：每个状态转换都有自己的护栏条件。例如，从**「执行中」转换到「已完成」，护栏检查所有子任务是否都已完成**。

状态级护栏：每个状态有自己的持续护栏——只要 Agent 处于这个状态，护栏就持续监控。例如，Agent 在**「执行中」状态时，护栏持续检查资源消耗是否超标**。

全局护栏：独立于状态机的全局安全检查层，对所有输入和输出进行检查。例如，输入内容过滤和输出去敏感化。

// 护栏模式的实现示例
interface GuardrailResult {
  allowed: boolean;
  reason?: string;
  severity: 'info' | 'warning' | 'critical';
}

type Guardrail = (context: AgentContext) => GuardrailResult;

class GuardrailEngine {
  private guardrails: Map<string, Guardrail[]> = new Map();

  register(state: string, guardrail: Guardrail) {
    if (!this.guardrails.has(state)) {
      this.guardrails.set(state, []);
    }
    this.guardrails.get(state)!.push(guardrail);
  }

  // 在状态转换前执行所有相关护栏
  evaluateTransition(from: string, to: string, context: AgentContext): GuardrailResult {
    const relevant = [
      ...(this.guardrails.get('global') || []),
      ...(this.guardrails.get(from) || []),
      ...(this.guardrails.get(`${from}->${to}`) || [])
    ];

    for (const guardrail of relevant) {
      const result = guardrail(context);
      if (!result.allowed) {
        return result;  // 快速失败
      }
    }

    return { allowed: true, severity: 'info' };
  }

  // 示例护栏：防止 Agent 进入无限循环
  static loopDetectionGuard(maxSteps: number): Guardrail {
    return (ctx) => {
      const stepsInState = ctx.history.filter(
        h => h.to === ctx.currentState
      ).length;
      if (stepsInState > maxSteps) {
        return {
          allowed: false,
          reason: `Detected potential infinite loop: ${stepsInState} steps in state ${ctx.currentState}`,
          severity: 'critical'
        };
      }
      return { allowed: true, severity: 'info' };
    };
  }

  // 示例护栏：资源消耗限制
  static resourceBudgetGuard(maxTokens: number, maxApiCalls: number): Guardrail {
    return (ctx) => {
      if (ctx.metrics.tokensUsed > maxTokens) {
        return {
          allowed: false,
          reason: `Token budget exceeded: ${ctx.metrics.tokensUsed}/${maxTokens}`,
          severity: 'critical'
        };
      }
      if (ctx.metrics.apiCalls > maxApiCalls) {
        return {
          allowed: false,
          reason: `API call budget exceeded: ${ctx.metrics.apiCalls}/${maxApiCalls}`,
          severity: 'warning'
        };
      }
      return { allowed: true, severity: 'info' };
    };
  }
}

状态机提供了结构化的执行框架，但状态转换本身也需要安全约束。一个设计良好的状态转换约束系统，可以防止 Agent 进入非法状态、执行危险操作，以及丢失关键上下文。

4.1 转换前置条件（Preconditions）

每个状态转换都应该有明确的前置条件——在转换发生之前必须满足的条件。前置条件不同于护栏：护栏是安全检查，而前置条件是业务逻辑检查。

前置条件的典型类型：

数据完整性检查：Agent 在执行转换之前，是否已经收集了所有必要的数据？例如，从**「规划中」转换到「执行中」，前置条件检查规划结果是否已经生成且有效**。

依赖满足检查：Agent 的前置依赖是否已经就绪？例如，Agent 需要先获取用户授权，才能从**「等待授权」转换到「执行中」**。

时间约束检查：转换是否在允许的时间窗口内？例如，某些敏感操作只能在工作时间执行。

4.2 转换后置条件（Postconditions）

状态转换完成后，系统必须满足的后置条件。后置条件确保转换的结果是正确的和一致的。

后置条件的典型类型：

状态一致性：转换后，Agent 的内部状态是否与新状态的定义一致？例如，进入**「执行中」状态后，Agent 的当前任务指针必须不为空**。

副作用验证：转换产生的副作用是否符合预期？例如，Agent 调用了外部 API，需要验证API 返回的结果格式正确。

日志记录：转换事件是否被正确记录到审计日志中？这对于事后分析和合规要求至关重要。

4.3 不可逆转换与回滚机制

某些状态转换是不可逆的——一旦执行，就无法回到之前的状态。例如，Agent 执行了数据删除操作，或者向用户发送了最终响应。

不可逆转换的安全机制：

确认状态：在执行不可逆转换之前，Agent 进入一个**「待确认」的中间状态。在这个状态下，可以执行额外的验证**，或者等待人类的确认。

事务性执行：将不可逆操作包装在事务中。如果操作失败，整个事务回滚，Agent 回到转换前的状态。

补偿操作：如果不可逆操作已经执行但结果不符合预期，执行补偿操作来抵消其影响。例如，如果 Agent 错误地发送了邮件，补偿操作是发送更正邮件并标记原邮件为错误。

即使设计了完善的状态机和护栏系统，Agent 仍然会遇到不可预见的错误。错误恢复策略决定了 Agent 在遇到故障时的行为——是优雅地恢复，还是崩溃后重启，或者进入不可知的故障态。

5.1 错误分类与处理策略

不是所有错误都需要相同的处理方式。根据错误的性质和影响范围，可以分为以下几类：

瞬时错误（Transient Errors）：暂时性的失败，重试后可能成功。例如：网络超时、API 限流、临时服务不可用。处理策略：指数退避重试（Exponential Backoff Retry）。

可恢复错误（Recoverable Errors）：需要特定的恢复操作才能继续。例如：工具调用返回了错误格式的数据、Agent 的规划不完整。处理策略：进入错误状态，执行预定义的恢复流程。

不可恢复错误（Non-recoverable Errors）：无法在当前上下文中恢复的错误。例如：核心依赖服务永久不可用、Agent 的配置数据损坏。处理策略：终止当前任务，通知用户，保存现场信息供后续分析。

安全错误（Security Errors）：触发了安全护栏的错误。例如：Agent 尝试访问未授权的资源、输出内容包含敏感信息。处理策略：立即阻止操作，记录安全事件，根据策略决定是否终止任务。

5.2 状态机中的错误恢复模式

在状态机框架中，错误恢复可以通过预定义的错误状态和恢复转换来实现：

错误状态集中化：所有类型的错误都先转换到一个统一的错误状态，然后由错误处理器根据错误类型决定后续动作。

错误状态分级：根据错误的严重程度，定义多个错误状态。例如：「警告」（可忽略，继续执行）、「可恢复错误」（需要恢复操作）、「致命错误」（终止任务）。

自动恢复循环：对于瞬时错误，状态机可以定义自动重试循环——进入错误状态 → 等待退避时间 → 尝试恢复 → 成功则回到正常状态，失败则升级错误级别。

人工介入点：当 Agent 无法自动恢复时，状态机可以将控制权转移给人工操作员。这需要 Agent 系统提供一个人工审核界面，允许操作员查看 Agent 的当前状态、历史执行记录，以及决定下一步操作。

5.3 状态快照与恢复

对于长时间运行的 Agent 任务，状态快照（State Checkpointing）是关键的容错机制。通过定期保存 Agent 的完整状态，可以在系统崩溃后从最近的快照恢复，而不是从头开始。

状态快照的设计要点：

快照粒度：每次状态转换后都应该保存快照？还是每隔固定时间间隔？还是在关键操作之前？不同的错误恢复需求决定了不同的快照策略。

快照内容：需要保存哪些信息？当前状态、历史转换记录、工具调用结果、用户的中间反馈、Agent 的上下文数据。快照越大，恢复越完整，但存储和恢复成本也越高。

快照存储：快照应该存储在持久化的、高可用的存储中。如果快照存储在本地内存中，系统崩溃后快照也会丢失，失去其意义。

以下是 Agent 错误恢复的完整状态流转图，展示了从错误检测到恢复决策再到恢复执行的全流程。

5.4 错误恢复状态机

错误恢复流程本质上是一个嵌套的状态机——当 Agent 进入错误状态时，触发恢复子状态机。

恢复子状态机的关键状态：

检测（Detect）：识别错误类型和严重程度。

分类（Classify）：根据错误类型选择恢复策略。

执行恢复（Recover）：执行预定义的恢复操作。

验证恢复（Verify）：检查恢复是否成功。

升级或终止（Escalate/Terminate）：如果恢复失败，升级到更高级别的处理或直接终止任务。

可观测性是运行时治理的基础。如果看不到 Agent 在做什么，就无法治理它。状态机为 Agent 的可观测性提供了天然的结构化基础——每个状态、每个转换、每个护栏检查结果，都是可观测的事件。

6.1 可观测性的三个维度

日志（Logging）：记录 Agent 的状态转换历史、护栏检查结果、错误事件。日志应该是结构化的（JSON 格式），包含时间戳、状态名、触发事件、转换结果、护栏状态。

指标（Metrics）：聚合 Agent 的运行统计数据。例如：每个状态的平均停留时间、状态转换的成功率、护栏触发频率、错误恢复的平均时间。

追踪（Tracing）：对于多 Agent 系统或跨服务的 Agent 调用，需要分布式追踪来追踪一个请求在多个 Agent 之间的流转路径。

6.2 状态机驱动的可观测性设计

状态机天然适合事件驱动的可观测性架构。每次状态转换都是一个事件，可以被发布到事件总线，供监控系统、告警系统、和分析系统消费。

关键的可观测性事件：

状态转换事件：记录 from_state → to_state 的转换，包含触发事件和转换耗时。这是最基础的可观测性数据。

护栏触发事件：记录哪个护栏被触发、触发原因、处理结果（阻止或放行）。这些事件对于安全审计至关重要。

错误事件：记录错误的类型、严重程度、恢复策略、恢复结果。这些事件是改进错误处理逻辑的主要数据源。

资源使用事件：记录 Agent 在每个状态下的资源消耗（Token 数、API 调用次数、执行时间）。这些数据用于成本分析和性能优化。

6.3 实时仪表盘与告警

基于状态机的可观测性数据，可以构建实时的 Agent 运行仪表盘：

Agent 状态分布图：显示当前所有 Agent 实例分别处于什么状态。如果大量 Agent 都卡在同一个状态，说明系统可能存在瓶颈。

状态转换率热力图：显示每个小时的状态转换频率。异常低的转换率可能表示 Agent 卡住了，异常高的转换率可能表示 Agent 在循环。

护栏触发告警：当某个护栏的触发频率超过阈值时，触发告警。例如，如果循环检测护栏在一小时内触发了 100 次，说明 Agent 系统可能存在设计缺陷。

statewright 是一个专注于 AI Agent 状态机护栏的开源项目，它提供了一套声明式的状态机定义语言和内建的护栏机制，使开发者能够快速构建可控的 Agent 系统。

7.1 statewright 的核心理念

statewright 的设计哲学可以用一句话概括：状态即安全（State is Security）。它的核心假设是：如果你能精确地定义 Agent 的所有合法状态和状态之间的转换规则，那么你就已经构建了第一道安全防线。

statewright 的三个核心抽象：

状态定义（State Definition）：使用声明式语法定义 Agent 的所有合法状态。每个状态可以指定允许的工具、允许的操作、超时限制，以及子状态结构。

转换规则（Transition Rules）：定义状态之间的允许转换路径。每条转换规则可以附加条件表达式和护栏函数。

护栏策略（Guardrail Policies）：预定义的护栏策略集合，包括循环检测、资源限制、权限检查、内容过滤等。开发者可以组合使用这些策略，也可以自定义新的策略。

7.2 statewright 的状态定义语法

statewright 使用一种类似 YAML 的声明式语法来定义状态机：

状态机定义包含状态列表、初始状态、终止状态集合，以及全局护栏策略。

每个状态可以定义进入动作（onEnter）、退出动作（onExit）、允许的工具列表、超时时间，以及子状态。

转换规则定义在状态级别，使用**「事件 → 目标状态」**的映射语法。

7.3 statewright 的护栏机制

statewright 的护栏机制是其最突出的特性。它提供了四层护栏：

结构护栏（Structural Guardrails）：确保状态机的结构完整性。例如：检查是否存在不可达状态、死锁、无出边的非终止状态。

行为护栏（Behavioral Guardrails）：在运行时监控 Agent 的行为。例如：检测循环模式、资源超限、异常状态停留时间。

内容护栏（Content Guardrails）：检查 Agent 的输入和输出内容。例如：敏感词过滤、格式验证、数据脱敏。

策略护栏（Policy Guardrails）：基于预定义的安全策略进行检查。例如：角色权限控制、数据访问限制、审计日志要求。

7.4 statewright 与其他方案的对比

statewright 不是唯一的 Agent 状态机方案。将它与其他方案进行对比，有助于我们做出技术选型：

vs LangGraph：LangGraph 是 LangChain 生态中的图状态机。它更通用，但护栏机制较弱。statewright 更专注于安全，提供了内建的护栏体系。

vs 手写状态机：手写状态机提供了最大的灵活性，但容易出错且难以维护。statewright 提供了标准化的护栏和可观测性，降低了开发成本。

vs 规则引擎：规则引擎（如 Drools）擅长复杂的业务规则，但不适合Agent 的动态决策。statewright 专门为 Agent 的状态管理设计，在灵活性和安全性之间取得了平衡。

// statewright 风格的状态机定义（概念性示例）
import { defineMachine, guardrail, transitions } from 'statewright';

const agentMachine = defineMachine({
  name: 'research-agent',
  
  // 状态定义
  states: {
    idle: {
      description: '等待用户指令',
      allowedTools: [],
      timeout: null,
    },
    planning: {
      description: '生成任务计划',
      allowedTools: ['web_search', 'knowledge_base_query'],
      timeout: '30s',
      onEnter: (ctx) => ctx.log('开始规划任务'),
    },
    executing: {
      description: '执行任务计划',
      allowedTools: ['web_search', 'code_execute', 'file_read', 'api_call'],
      timeout: '120s',
      subStates: ['fetching_data', 'processing', 'generating_result'],
    },
    reviewing: {
      description: '人工审核阶段',
      allowedTools: [],
      timeout: '300s',
    },
    completed: {
      description: '任务完成',
      allowedTools: [],
    },
    error: {
      description: '错误状态',
      allowedTools: ['log_dump', 'state_snapshot'],
      timeout: '10s',
    },
  },

  // 转换规则
  transitions: {
    idle: { START: 'planning' },
    planning: { PLAN_DONE: 'executing', PLAN_FAILED: 'error' },
    executing: { 
      ALL_DONE: 'reviewing',
      PARTIAL_DONE: 'reviewing',
      ERROR: 'error',
      TIMEOUT: 'error',
    },
    reviewing: { APPROVED: 'completed', REJECTED: 'executing' },
    error: { RECOVER: 'planning', ABORT: 'completed' },
  },

  // 全局护栏
  guardrails: [
    guardrail.loopDetection({ maxStepsPerState: 5 }),
    guardrail.resourceBudget({ maxTokens: 50000, maxApiCalls: 20 }),
    guardrail.toolWhitelist({ strict: true }),
    guardrail.outputFilter({ sensitivePatterns: [/password/i, /secret/i] }),
  ],

  initialState: 'idle',
  terminalStates: ['completed', 'error'],
});

// 运行 Agent
const agent = agentMachine.createAgent();
agent.dispatch('START', { task: '研究并总结最新的 AI Agent 安全趋势' });

理论已经讲了很多，现在让我们从零开始，构建一个完整的、带护栏的 Agent 状态机系统。这个系统将模拟一个研究助手 Agent——它能够接收研究任务、规划研究步骤、执行搜索和分析、生成研究报告，并在整个过程中接受护栏的监控和约束。

8.1 需求分析

我们的研究助手 Agent需要满足以下需求：

任务接收：Agent 能够接收用户的研究任务，并解析任务的复杂度。

自动规划：Agent 根据任务复杂度，自动生成研究计划，包括搜索关键词、分析维度、输出格式。

分步执行：Agent 按照研究计划逐步执行，每一步都记录进度和中间结果。

质量保证：在生成最终报告之前，Agent 执行自我检查——确保信息准确性、引用完整性、格式规范性。

安全可控：整个过程中，护栏系统持续监控 Agent 的行为，确保不越权、不超时、不产生有害输出。

8.2 系统架构

系统的整体架构分为四层：

状态机层：管理 Agent 的状态转换和执行流程。

护栏层：在关键决策点和状态转换点执行安全检查。

工具层：提供 Agent 可以使用的外部工具（搜索 API、知识库查询、代码执行等）。

可观测性层：记录所有事件、指标和追踪信息，供监控和分析使用。

8.3 实现步骤

第一步：定义状态机。根据需求分析，定义 Agent 的所有状态和转换规则。关键状态包括：idle、analyzing_task、planning、executing、self_review、generating_report、completed、error。

第二步：实现护栏。实现四类护栏：循环检测（防止 Agent 在同一状态停留过久）、资源预算（限制 API 调用次数和 Token 消耗）、工具白名单（确保 Agent 只使用授权的工具）、内容过滤（防止生成不当内容）。

第三步：集成工具层。为每个状态配置允许的工具列表。例如，planning 状态只允许知识库查询，executing 状态允许搜索 API 和代码执行。

第四步：添加可观测性。在每个状态转换时发布事件，在每个护栏检查时记录指标，在每次错误时生成追踪信息。

第五步：测试与调优。使用模拟任务测试整个系统，验证状态转换的正确性、护栏的有效性、以及错误恢复的可靠性。

Agent 状态机与护栏模式是一个跨学科的技术领域，涉及计算机科学、控制理论、软件工程、和AI 安全等多个方向。以下是推荐的进阶学习资源：

9.1 理论基础

有限状态机理论：Hopcroft 的《Introduction to Automata Theory, Languages, and Computation》是自动机理论的经典教材，深入讲解了 FSM、正则语言、和图灵机的数学基础。

层次状态机：David Harel 的 Statecharts 论文（1987）提出了层次状态图的概念，这是现代 HSM 实现的理论基础。

形式化验证：如果你的 Agent 系统对安全性要求极高（如医疗、金融、自动驾驶），建议学习形式化验证技术——使用数学方法证明状态机的正确性。

9.2 工程实践

Actor 模型：Erlang 和 Akka 的 Actor 模型提供了分布式状态管理的思路。虽然 Actor 模型不同于 FSM，但它展示了如何在分布式环境中管理有状态的计算实体。

工作流引擎：Apache Airflow、Temporal、和 Camunda 等工作流引擎展示了大规模状态管理的工程实践。它们的设计思路可以借鉴到 Agent 状态机的设计中。

微服务编排 vs 协同：Agent 状态机的设计模式与微服务架构中的编排（Orchestration）和协同（Choreography）模式有深刻的相似性。理解这两种模式的区别和适用场景，有助于设计更好的 Agent 架构。

9.3 前沿方向

可验证的 Agent：研究界正在探索如何形式化验证 Agent 的行为——证明 Agent 在给定条件下的行为符合预定的安全属性。这是 AI 安全领域的前沿方向。

自适应护栏：传统的护栏是静态的——规则在部署时确定。自适应护栏能够根据 Agent 的行为模式和环境变化，动态调整护栏策略。

多人 Agent 系统的状态协调：当多个 Agent 协同工作时，如何协调它们的状态是一个开放性问题。分布式共识算法（如 Raft、Paxos）的思路可能被借鉴到多 Agent 状态协调中。