从 ReAct 到生产级智能体运行时：一个大型运营平台的 Agent 框架自研之路Agent 框架教程不少，但能系统讲清楚“范式原理 - 运行时分层 - 工程治理 - 真实项目落地”的中文资料仍然不多。很多文章停留在 Dify 拖拽、LangChain Demo 或单个 Function Calling 示例：接口能调通，页面也能返回结果，但一到真实业务环境，就开始面对循环失控、成本失控、状态丢失、工具越权、并发打爆和故障不可恢复。这篇文章不讨论“怎么快速做一个 Demo Agent”，而是讨论另一个更难、也更有工程价值的问题：当 Agent 真正进入核心业务链路后，我们到底该如何从零构建一个可控、可恢复、可扩展的生产级智能体运行时？全文围绕一个真实且典型的场景展开：大型运营平台中的 AI 运营助手。它需要理解自然语言任务，拆解意图，查询数据，执行工具，必要时调用外部系统，并对写操作做权限控制、幂等保护、补偿和审计。一、业务背景：为什么 Demo Agent 一进生产就失控我们服务的是一个大型电商运营平台。运营同学会提出类似下面的请求：帮我找出最近 7 天退款率超过 5% 且差评数持续上升的商品，先生成风险报告，再把高风险商品切到人工复核池，并给受影响用户发一张补偿券。这类请求有几个明显特征：输入是自然语言，且常常不完整、不规范。中间要经历意图识别、条件补全、知识查询、业务规则校验、工具调用和结果汇总。一部分操作是只读分析，一部分操作是带副作用的写入。任务链路往往跨越多个系统：商品中心、订单中心、营销中心、风控中心、工单系统。同一时段会出现大量并发任务，请求分布不均，晚高峰明显。团队最早的方案很常见：Prompt + ReAct + 几个工具 + 一层记忆检索。原型阶段效果很好，但一旦进入核心链路，问题会集中暴露：ReAct 循环在工具超时和弱错误提示下反复重试，导致一次任务跑出几十轮。模型上下文里同时塞历史对话、工具说明、RAG 结果和错误日志，Token 很快膨胀。Function Calling 和 MCP 工具混用，没有统一抽象层，模型经常把参数格式写错。长任务执行到第六步时如果服务重启，只能从头再来，已经执行过的写操作存在重复风险。所有链路同步阻塞，LLM、向量检索、工具调用串行叠加，吞吐量上不去。系统知道“模型会调用工具”，但不知道“这次为什么调、能不能调、失败后该不该重试、调过之后怎样补偿”。这说明问题已经不再是“模型够不够聪明”，而是：我们缺的不是一个 Agent Prompt，而是一个 Agent Runtime。二、先讲清楚范式：ReAct、Plan-and-Solve、Workflow 到底差在哪很多人知道 ReAct、Plan-and-Solve、Workflow 这些名词，但不知道它们真正的架构差异。生产系统里，范式不是概念问题，而是状态管理、调度方式和失败恢复方式的问题。2.1 ReAct 的本质：增量状态机ReAct 不是“模型边想边做”这么简单，它本质上是一种带反馈回路的增量状态机。否是用户任务ThoughtActionObservation是否完成Final Answer它的核心特点：每一轮决策都依赖上一轮 Observation。状态以 Trace 形式不断追加，而不是一次性规划完。非常适合探索式任务：排障、检索、诊断、多轮试探式决策。风险也非常明显：容易进入局部循环，且上下文会随步数不断增长。工程上，ReAct 要解决的不是“能不能让模型继续思考”，而是：循环最多跑多少步。每一步最长执行多久。哪些错误允许模型自修复，哪些错误必须强制终止。Trace 如何压缩，避免上下文无限膨胀。2.2 Plan-and-Solve 的本质：先计划，再调度Plan-and-Solve 将“推理”拆成两个阶段：规划阶段：生成可执行计划。执行阶段：按照依赖关系调度子任务。用户任务Planner任务 DAGTask 1Task 2Task 3Result StoreFinal Compose它和 ReAct 最大的区别不在于“先想还是边想”，而在于：状态载体从连续 Trace 变成了任务图 + 事实表。执行单元从“一个循环步骤”变成了“一个可独立重试的节点”。可以做并行调度，天然更适合结构化流程。某个节点失败时，不必重放整条链路。2.3 Workflow 的本质：显式流程控制Workflow 不是更高级的 Agent，而是把流程控制权从模型手里拿回来，交给工程系统。它适合：审批流、工单流、订单流这类强规则场景。对一致性、审计和可解释性要求很高的任务。需要人工确认和固定补偿逻辑的操作链路。2.4 三种范式怎么选维度ReActPlan-and-SolveWorkflow核心状态TraceDAG + Facts显式状态机调度方式串行循环拓扑调度引擎编排优势灵活、探索能力强易并行、易重试可控、可审计风险循环失控、成本失控计划失真灵活性不足适用任务搜索、诊断、开放式分析结构化多步骤执行高风险写操作、审批流生产级系统通常不会三选一，而是组合使用：用 ReAct 处理不确定性高的分析与探索。用 Plan-and-Solve 拆解复杂任务。用 Workflow 承接最终写操作和补偿流程。这也是本文后面运行时设计的基础。三、Agent Runtime 的真正职责：不是帮模型“更会答”，而是让系统“不会失控”生产级 Agent Runtime 至少要解决七件事：任务如何被接收、排队、调度。范式如何被选择，是走 ReAct、Plan-and-Solve 还是固定 Workflow。工具如何统一接入，包括本地函数、HTTP API、MCP Server。状态如何持久化，任务中断后如何恢复。记忆如何分层管理，避免“什么都记、什么都检索”。写操作如何做权限控制、幂等、补偿和审计。整条链路如何被观测、限流、隔离和扩展。如果一个系统只能把模型接上工具，那它是工具增强问答系统；只有当它开始承担这些运行控制职责时，它才称得上运行时。四、整体架构：从单个 Agent 进化为生产级运行时4.1 运行时分层我们最终将系统拆成七层：