为什么复杂的真实业务不能指望单条 Prompt 一气呵成？本章深入有限状态机 (FSM)、主从 Subagent 派发架构与多智能体拓扑解耦。
在长流程（如全自动编写研报、数据清洗流水线、多步跨系统转账）中，如果仅让大模型在自由对话中“见机行事”，随着轮次增加，模型极易产生指令漂移 (Instruction Drift)、跳过关键校验、甚至反复陷入无意义调用。
用确定性的状态机，包裹非确定性的大模型！
每个状态只允许执行特定动作并拥有独立的提示词与工具集。模型不能随意跳转到未开放的阶段，必须通过条件守卫（Guard Conditions）才能流转到下一状态。
type AgentState = 'IDLE' | 'PLANNING' | 'EXEC_TOOL' | 'VERIFYING' | 'WAITING_HUMAN' | 'DONE';
interface StateContext {
state: AgentState;
userGoal: string;
planSteps: string[];
currentStepIndex: number;
toolResults: Record<string, any>;
retryCount: number;
}
class AgentStateMachine {
private ctx: StateContext;
transition(event: 'START' | 'PLAN_OK' | 'TOOL_SUCCESS' | 'TOOL_FAIL' | 'VERIFY_PASS' | 'VERIFY_FAIL') {
switch (this.ctx.state) {
case 'IDLE':
if (event === 'START') this.ctx.state = 'PLANNING';
break;
case 'PLANNING':
if (event === 'PLAN_OK') this.ctx.state = 'EXEC_TOOL';
break;
case 'EXEC_TOOL':
if (event === 'TOOL_SUCCESS') this.ctx.state = 'VERIFYING';
if (event === 'TOOL_FAIL' && ++this.ctx.retryCount > 3) this.ctx.state = 'WAITING_HUMAN';
break;
case 'VERIFYING':
if (event === 'VERIFY_PASS') this.ctx.state = 'DONE';
if (event === 'VERIFY_FAIL') this.ctx.state = 'PLANNING'; // 自反思回滚重构计划
break;
}
}
}点击下方不同的触发事件，观察状态节点如何被激活、何时触发自反思回滚、何时暂停等待人工介入：
在候选人的专家能力和简历项目中，“多智能体编排与 Subagent 模式”被广泛运用。其核心理念是“分而治之，上下文强隔离”。
一个 Agent 既要负责前端代码，又要负责分析金融时钟，还要撰写营销文案。所有上下文混在一起，Token 飞速爆表，模型注意力严重污染。
主智能体 (Orchestrator) 负责高维拆解任务；派发独立的 子智能体 (Subagent) 专注于单一垂直领域。子智能体拥有纯净独立的上下文，执行完只返回结论，主智能体聚合最终交付！