企业级Agent架构：五组件、ReAct循环与私有可控底座

前阵子和几个朋友聊各自的 Agent 项目发现一个很普遍的现象Demo 阶段的 Agent 都特别能打一进生产环境就露馅。原因不是模型变笨了而是大家把 Agent 当成一个“提示词工程”来做没有把它当成一个可以承载业务状态的系统来设计。今天我想拆一个完整的企业级 Agent 架构标题里的三个关键词——五组件、ReAct 循环、私有可控底座——正好对应了从单体智能走向系统级智能的三层结构。不管你是第一次接触 Agent 架构还是已经踩了几个坑这篇文章都可以帮你把散落的认知串起来。很多人一听到 Agent OS 就觉得是行业黑话但实际拆开看它就是一套能支撑 Agent 长期稳定运行的基础设施。五组件解决“Agent 有什么器官”ReAct 循环解决“器官怎么协调”私有可控底座解决“这套系统能不能被信任”。三层缺一不可本文会逐个展开并把我实践里踩过的坑、选型时的取舍一并写出来。1. Agent OS 与普通 Agent 应用差了一个“运行时”的距离1.1 单体 Agent 是业务逻辑Agent OS 是承载逻辑的容器先说结论Agent OS 不是让模型自己做操作系统而是把 Agent 运行所需要的公共能力抽出来做成类似操作系统的“运行环境”。普通 Agent 应用里感知、记忆、规划、执行、反思这些能力散落在业务代码中每次新场景都要重新写一遍Agent OS 则把这些能力做成通用组件业务只需要注册目标和工具剩下的调度、记忆、权限、审计都由底座承担。我见过不少团队一个场景跑通了第二个场景又从头写一套。同样的对话历史管理逻辑在客服 Agent 里写一遍在数据分析 Agent 里再写一遍这是典型的把“应用”当“系统”堆。一个合格的 Agent OS至少要提供四个公共能力上下文与记忆管理、工具注册与调度、权限与审计、运行时观测。没有这四块Agent 应用再多也只是孤岛无法沉淀成企业资产。1.2 三层结构组件、循环、底座如何拼成一张蓝图把标题拆开看正好是一条企业级落地的路径。五组件是静态解剖告诉你一个完整 Agent 需要哪些器官ReAct 循环是动态机制告诉你这些器官怎么在每一轮任务里协同私有可控底座是环境约束告诉你这套系统在生产环境里能跑多稳、能被信任到什么程度。这三层之间还有一个递进关系没有组件化拆分ReAct 循环就没有可操作的载体因为循环里每一步都要落在一个具体组件上没有循环机制组件再全也只是摆设因为模型生成一次结果并不会自动纠错没有私有可控底座前两层做得再好企业也不敢把真实业务数据灌进去。所以我在落地时总喜欢画一张简单的蓝图底层是存储和模型推理服务中间是五组件运行时上层是业务流程编排而 ReAct 循环像一条总线一样贯穿中间层。想清楚这张图后续选型就不容易被某个框架带偏。2. 五组件拆解感知、记忆、规划、执行、反思各司其职2.1 感知组件不只“听懂人话”更要做输入转译感知组件负责把用户输入、系统状态、外部事件转成 Agent 可处理的结构化信号。很多人以为感知就是 LLM 的对话接口其实企业级场景下感知层要处理的东西多得多工单系统回传的状态字段、传感器上报的数值、定时任务触发的上下文、甚至数据库 schema 变更都需要归一化后送入 Agent。我参与过的一个运维 Agent第一版感知组件只接文本结果工单里一句“内存飙升”模型判断了三次都猜不出是哪个节点。后来我们把监控系统的告警结构体直接接入感知层模型拿到的是{host: node-03, metric: memory_usage, value: 92, threshold: 85}这样的结构化数据准确率立刻上了一个台阶。这里面的教训是感知组件做的不是“理解”而是“转译”把混乱的现实世界转译成模型容易消费的规范输入越早做结构化归一化后面所有环节越省力。2.2 记忆组件短期、长期、业务记忆分开管理记忆组件是五组件里最容易做坏的一个。常见做法是把所有历史消息塞进上下文小规模跑通没问题但一旦上下文超过模型窗口或者多个场景共享一套记忆灾难性的“记忆污染”就来了。我建议至少分三层管理。短期记忆对应当前会话的工作区存的是本轮任务的即时上下文会话结束后做摘要再归档。长期记忆以向量库加摘要文本共同存放适合承载产品知识、历史对话经验这类语义信息。业务记忆则必须用结构化数据跟具体单据绑定比如审批走到哪一步、库存还剩多少、价格审批是否已完成。这里有一个非常关键的原则业务事实不进向量库。向量检索适合找相似语义但订单金额和发货地址必须是字段否则模型会“猜”出一个看似合理但完全错误的值。2.3 规划与执行从任务分解到工具调用的两级协同规划组件负责把目标拆成子任务常见形式有链式、树状和 DAG 三种。链式适合固定流程比如“查库存-算价格-生成报价单”树状适合层层拆解的大任务DAG 适合有依赖关系和并行分支的真实业务。企业级场景里我优先用 DAG 描述任务因为业务很少是严格线性的一个审批流程常常要并行确认法务和财务的意见然后等两边都通过才能继续。执行组件的心脏是工具注册与调用。工具不是简单暴露 API而是要带上鉴权、幂等、超时和错误码。没有为工具设计错误返回的 Agent在工具失败时会反复重试同一个操作既浪费 token又可能给下游系统造成重复写入。我见过一个库存 Agent 因为下单接口没有幂等键失败重试了三回结果生成了两笔重复订单。工具层一定要做一层适配器把外部 API 的异常统一转成 Agent 能理解的错误语义比如TOOL_TIMEOUT、PERMISSION_DENIED、INVALID_PARAM。2.4 反思组件闭环中最容易被砍掉的纠错机制反思组件是最容易被砍掉的一环但它恰恰是 ReAct 循环里让 Agent 拥有纠错能力的关键。反思不只是让模型“再想想”而是一套结构化的自检规则结果是否满足用户约束、是否使用了最新数据、有没有偏离原始目标、中间步骤有没有逻辑断层。反思输出应该是一条可审计的记录而不是一句模糊的“看起来没问题”。落地时我会给反思组件定义三个固定检查项目标一致性、约束满足性、证据充分性。目标一致性看当前结果是否还对得上用户最初的需求约束满足性看有没有突破预算、时间、权限之类硬限制证据充分性看结论是否有足够的事实支撑还是模型在自由发挥。这三个检查项的输出会直接决定循环是终止、重试还是转人工后面讲 ReAct 时会看到它们如何联动。下面这张表是我整理的五组件要点日常评审时可以直接拿来对照。组件核心职责企业级要点缺失后果感知输入转译结构化、归一化模型在错误信息上瞎猜记忆状态存储短期/长期/业务分层上下文爆炸与记忆污染规划任务分解DAG 表达依赖关系复杂任务无法收敛执行工具调度鉴权、幂等、超时重复写入、越权调用反思自检纠错可审计、可干预错误在循环中被不断放大3. ReAct 循环Thought-Action-Observation 的生产级转法3.1 为什么 ReAct 能让 Agent 从“猜答案”变成“找答案”ReAct 的核心是 Reason Act做一个 Thought思考到 Action行动再到 Observation观察的循环。单轮生成的模型面对复杂任务经常在第一步就赌错方向而 ReAct 通过把决策拆成多轮“思考-行动-观察”让模型每走一步都能看到真实世界的反馈再决定下一步怎么走。这个机制特别像人修电器先判断可能是哪里坏了Thought拿万用表去量Action看到读数Observation再判断下一步拆哪里。没有观察的单轮判断等于不允许开盖检查就直接报维修结论。在生产环境里这种“边做边看”的机制能显著降低复杂任务的方差代价是延迟更高、token 消耗更大所以一定要给循环加边界不能让它无限转下去。3.2 一个业务场景的循环推演从退换货处理看状态流转以退换货处理为例走一遍循环。用户说“我买的相机镜头有灰尘想退货”感知组件先把意图转成结构化事件{intent: return_request, item: lens, reason: dust}。第一轮Thought 判断需要核对订单号和是否在退换期内。于是 Action 调用订单查询工具Observation 返回订单状态为“已签收 3 天在退换期内”。第二轮Thought 判断需要确认商品是否影响二次销售。Action 调用售后质检规则工具Observation 返回“镜头进灰属于外观问题需人工质检确认”。第三轮反思组件检查约束满足性后发现无法自动完成质检判断于是把状态标记为置信度不足转入人工审批队列。这短短三轮循环展示了一个生产级 Agent 最重要的能力它不是一次性生成退货结论而是通过真实工具反馈逐步逼近答案并在不确定的地方主动把控制权交还给人。很多团队只关注模型推理得多聪明忽略了这种“关键节点降级到人”的流程设计才导致 Agent 不敢上线。3.3 循环状态机、终止条件与人工审批闸口ReAct 循环在生产环境中不是无限循环而是一个带终止条件的有限状态机。我会在每一轮循环里维护几个关键字段step 计数、当前意图、已用工具列表、观察结果缓冲区、置信度。这些字段的作用是让循环可以被观测、被中断、被打断后恢复。终止条件有四类目标达成、达到最大步数、置信度低于阈值转人工、工具连续报错触发熔断。其中“置信度低于阈值转人工”在企业场景里最重要与其让 Agent 硬着头皮生成一个不确定的结果不如把控制权交还给人类审批节点。审批不是每轮都做而是在关键动作上做比如付款、删除、对外发送消息。非关键动作可以放行关键动作必须留一道闸口这是底线。3.4 一段可复用的 ReAct 引擎伪代码下面这个伪代码是我在实际项目里简化后的框架保留了状态管理关键细节你可以直接抄回去改造成自己的引擎。import json from dataclasses import dataclass dataclass class ReActState: step: int 0 goal: str observations: list None trace: list None done: bool False confidence: float 0.0 def __post_init__(self): self.observations self.observations or [] self.trace self.trace or [] def run_agent_loop(goal, tools, max_steps8): state ReActState(goalgoal) while not state.done and state.step max_steps: state.step 1 # 1. Thought: 结合目标、历史观察和工具列表生成下一步思考 thought planner.generate_next_thought(state) state.trace.append({step: state.step, thought: thought}) # 2. Action: 从思考中选择一个可执行动作 action executor.decide_action(thought, tools) if action.is_human_approval_required(): # 关键动作插入人工审批审批未通过直接终止 approved human_approval_gate.request(action) if not approved: state.done True state.trace.append({step: state.step, action: REJECTED}) break # 3. Observation: 执行动作并带回结构化观察结果 observation executor.run(action) state.observations.append(observation) state.trace.append({ step: state.step, action: action, observation: observation, }) # 4. 反思: 判断目标是否达成、是否需要修正方向 state.done, state.confidence reflector.evaluate(state) return state这段代码没用任何复杂框架核心就是把每一步都记录成 trace。生产排查问题时trace 比最终结果值钱一百倍。我习惯把每个 step 的输入输出作为一条日志写入观测系统这样即使 Agent 答错了也能定位到是感知转译错了、工具返回错了还是反思漏判了。4. 私有可控底座企业级 Agent OS 的信任根基4.1 为什么“数据不出域”会成为底座的第一条军规标题里的“私有可控底座”是很多技术团队最后才补的一课。在 Demo 里Agent 可以连各种公共接口在企业环境里数据安全要求、接口依赖、成本波动每一条都是问题。所谓私有可控底座并不是简单地把模型部署在内网而是让数据、模型、工具调用链路全部处在企业自己的管控范围内。我见过一个很典型的返工案例某零售企业一开始用外部模型 API 做库存分析 Agent指标效果不错但后来采购部门表示商品进价、供应商账期这类敏感数据不能传给外部接口于是整个项目推翻重做。如果一开始把底座设计成可切换的私有部署数据先落在内部向量库和结构化存储里再按安全要求决定调用哪个模型就不会走到返工这一步。所以我把数据不出域当作底座设计的第一条军规模型能力可以逐步升级但数据边界必须先定死。4.2 私有底座的四件套推理、存储、网关、观测一个可落地的私有可控底座至少包含四块模型推理服务、向量与结构化存储、工具与权限网关、审计与观测平台。模型推理服务建议做得可插拔。既可以用开源权重模型在内网跑也可以接入企业内部已经采购的商用模型 API关键是不让业务代码直接绑定某一个模型供应商。存储层负责承载长期记忆向量库管语义偏好关系库管业务事实。工具网关统一做鉴权、限流和幂等控制对外部系统的每一次调用都要经过网关不能绕过。审计平台记录每一次推理输入输出、每一次工具调用和每一次人工审批形成完整链路。这套设计我称为“准入准出”控制数据只允许在约定的存储和推理链路里流动工具只允许白名单内的执行任何越界行为都会被审计系统捕获。与其纠结选哪家模型更强不如先把这套边界建起来模型的迭代反而快得多。4.3 权限收敛与三层干预机制企业级 Agent 的权限设计有一条重要原则模型可以有多大能力但工具必须按最小权限授予。同一个模型在客服场景里只能查订单状态不能改价格在运维场景里只能读取指标不能直接重启节点。权限不是写在提示词里的而是由底座统一控制模型只负责生成意图实际能不能执行由网关裁决。此外一定要有人工干预的口子。我建议至少支持三层干预会话级暂停、动作级审批、状态级回滚。会话级暂停用于发现 Agent 行为异常时立即掐断运行动作级审批对应 ReAct 循环里的关键节点闸口状态级回滚则是给记忆和业务状态做快照出错后恢复到前一个稳定版本。这三层不是可选组件而是企业愿意让 Agent 触碰核心业务的前提。4.4 模型选型与成本控制的实践建议模型选型上我现在的习惯是“核心能力靠模型业务规则靠工程”。不要让模型去死记硬背企业内部流程而要把流程写成可检索的业务记忆或工具约束模型只负责推理和调度。这样做的直接好处是模型换了一个Agent 的核心能力还在因为业务知识不在模型参数里。成本控制方面OpenAI 系的推理费用在企业场景里往往是主要成本项因此我会按任务分层简单查询类任务用轻量模型复杂推理类任务才用大模型记忆压缩类任务单独走低成本链路。一个实用技巧是在 ReAct 循环里做“意图路由”进入循环之前先判断这个任务值不值得启用多轮推理如果只是“查一下余额”这类单轮任务直接走短路径能省不少成本。5. 落地会踩的坑和我现在的选型习惯5.1 五个翻车现场与对应的止损方案第一个坑是工具没有幂等重试导致重复下单。止损方案是每个工具都带 request_id服务端做幂等校验Agent 层面对同一失败动作只允许带同一 request_id 重试。第二个坑是记忆共用多租户的上下文互相污染。止损方案是记忆组件强制按租户和会话两级隔离索引键里至少包含tenant_id session_id。第三个坑是反思组件缺失模型在错误方向上连续迭代。止损方案是把反思提到跟规划同等重要的位置每个循环结尾强制做目标一致性和证据充分性检查。第四个坑是评测只看单轮准确率没有追踪多轮任务成功率。止损方案是建立一条包含 50 到 100 条真实任务的回归集跑完一个闭环统计成功率再拆解每轮 trace 找瓶颈。第五个坑是一上来就追求大而全的编排框架结果被框架束缚改一个业务逻辑都要翻半天文档。止损方案是先写最薄的引擎层只做状态管理和循环控制业务全部通过工具和配置注入。5.2 从零最快上手的落地路线如果你现在要从零搭一个企业级 Agent OS我给的建议不是先写框架而是先跑通一个端到端的最小闭环。选定一个业务场景把感知、记忆、规划、执行、反思五组件以最简形式搭起来从三到五步的 ReAct 循环开始积累 trace 数据再做私有化部署切换。具体步骤我推荐这样走第一确认场景清单和禁区清单明确 Agent 能碰什么、不能碰什么第二设计工具白名单和审批节点把关键动作预先标出来第三搭记忆分层业务事实全部结构化入库第四写循环引擎先不支持并行只做串行 ReAct第五跑真实历史数据建基准评分第六引入私有底座把存储和推理切到可控链路。每一步都有明确产物不会陷入无限架构设计。选型上我现在的习惯是模型提供推理能力但不在模型层塞业务规则工具层把每个 API 都包一层鉴权和幂等适配记忆层坚持业务事实进结构化存储、语义偏好进向量库所有 Agent 运行轨迹统一进观测平台。这些原则听起来简单真正坚持下来的团队系统稳定性和可排查性会明显比“散装 Agent”好一个量级。这篇文章里的内容基本都是我在实际项目里一点一点试出来的。五组件不是新鲜理论它是把 Agent 当成系统来看待时自然会长出的器官ReAct 循环也不是炫技是让模型在真实反馈中逐步逼近正确答案的最朴素手段私有可控底座更不是选择题而是企业愿意把 Agent 放进生产链路的入场券。下次再有人问你 Agent 架构怎么做你可以先反问一句你的 Agent 是跑在一个应用里还是跑在一个系统里想明白这个问题很多架构分歧自然就解开了。