你有没有见过这样的 Agent？Demo 演示时上天入地无所不能，调工具、做推理、答问题一气呵成；可一旦塞进千万级并发的企业级生产流水线，立刻原形毕露 —— 延迟飙高、状态混乱、加个新业务就得在 DAG 里堆满 If-Else 补丁。

当 Agent 彻底跨过玩具阶段，挺进工业级深水区，曾经被奉为圭臬的标准 ReAct 架构，正在暴露它与生俱来的工程缺陷。

最近火山引擎 AI 搜索团队放出的这篇架构演进干货，直接戳中了无数一线研发的痛点：他们把经典的 ReAct 三节点架构彻底重构，推出Workflow + Unified Policy Agent（UP-ReAct）新架构，在效果全面提升的前提下，把首字返回时间（TTFT）硬生生砍了 30%。

这不是一次简单的代码重构，而是对工业级 Agent 设计哲学的底层重塑。今天我们就来拆解这套能扛住千万级并发的 Agent 架构，看看它到底解决了哪些顽疾。

一、别再神化 ReAct 了，工业级场景它真的扛不住

在聊新架构之前，我们得先搞懂一个问题：为什么 AI 搜索的 Agent 天生就比普通聊天助手难几个量级？

火山引擎 AI 搜索不是一个简单的问答框，而是面向 ToB 企业的「搜、推、问一体化」智能引擎 —— 既要处理文本、图像、视频的多模态混合召回，又要结合用户画像做个性化排序，还要在电商导购、企业知识库、内容社区等几十种场景里维持连贯的业务逻辑。

ToB 客户不会为「看起来很聪明但经常超时」的系统买单，他们要的是极致的确定性、极低的响应延迟、可扩展的架构边界。而标准 ReAct 架构，恰恰在这三点上先天不足。

标准 ReAct 的思路非常优雅：先思考（Thought）、再行动（Action）、最后判断是否继续（Iteration）。但把这套三节点 DAG 生搬硬套进复杂生产链路，三大「工程原罪」会被无限放大：

1. 极高的时间复杂度，延迟灾难的根源

每完成一次有效工具调用，都要经历三次独立的模型决策流转。我们可以简单算一笔账：假设单次模型推理耗时 T_model，工具执行耗时 T_tool，网络与节点流转耗时 T_io，旧架构下一次工具调用的全链路成本是：T_old = 3 × T_model + T_tool + 3 × T_io

原本一次推理能做完的事，被强行拆成了三轮。这直接导致 TTFT 急剧恶化，Token 无谓消耗和并发压力激增，在算力成本面前极其奢侈。

2. 上下文震荡，注意力被稀释到失效

三节点拆分带来了一个致命隐患：状态的重复搬运。 Thought 节点要读历史对话，Action 节点要读 Thought 输出，Iteration 节点又要重新理解前两者的状态来决定是否终止。同一份业务状态在节点间反复序列化、反序列化，Prompt 长度指数级膨胀。

后果就是显存占用飙升，更严重的是模型注意力严重稀释—— 在浩如烟海的中间推理步骤里，模型很容易就忘了用户最开始的真实意图。

3. 控制流破碎，架构最终沦为补丁屎山

生产级系统永远在变：今天要加企微画像补全，明天要接实时库存查询。 在 ReAct 架构里，纯信息补充类工具调用完根本不需要判断是否退出，但你绕不开 Iteration 节点。工程师只能在 DAG 里硬编码各种特判逻辑，久而久之，「优雅的智能架构」就退化成了布满补丁的屎山。

Thought 在规划，Action 在翻译，代码逻辑在强行路由 —— 系统的控制权被彻底撕裂。当业务规模突破阈值，再在 ReAct 的尸体上打补丁，已经是徒劳。

二、业界共识：Agent 的下半场，拼的是 System Engineering

时间走到 2025-2026 年，OpenAI、Anthropic 这些顶级团队在生产级 Agent 的设计上已经达成了惊人的共识：少谈奇技淫巧的 Prompt，多讲扎实的 System Engineering。

共识一共四条，每一条都精准命中旧架构的痛点：

1. Workflow 与 Agent 必须严格分层：预定义路径、硬规则、权限控制留在传统代码里；Agent 只负责动态策略决策。别用 LLM 去做普通的 switch-case。
2. 万物皆 Tool（强契约）：工具不只是 API 调用，更是 Agent 与外部世界的强契约。工具的输入输出 Schema、容错能力，比 Agent 自身的推理能力更决定系统的下限。
3. 上下文管理独立化：面对成百上千个工具，全量加载既贵又低效。按需加载、状态压缩，是长程任务的生命线。
4. 生产级工程评测体系：只靠「回答好不好」衡量不了系统质量。工具调用准确率、中间态阻断率、代码判分，才是多维度 Eval 的核心。

火山引擎 AI 搜索团队完全践行了这套思路，最终交出的答案，就是Workflow + Unified Policy Agent架构。

三、破局重构：把确定性与动态决策彻底切开

新架构的核心思路非常朴素，也非常有效：把整个 AI 搜索链路一分为二 —— 确定性归 Workflow，动态决策归 Agent。

第一层：楚河汉界，各司其职

Workflow 层，是坚如磐石的确定性骨架。 所有不需要 LLM 决策的前置工作，全部由 Workflow 接管：风控校验、意图路由分类、用户画像预加载、基础倒排召回、本地配置读取……

举个最直观的例子：电商搜索里「必须先过滤无库存商品」，这是绝对的业务规则。把它硬编码在 Workflow 中，远比指望 Agent 每次都「想起」调用过滤工具要可靠一万倍。

Agent 层，是纯粹的动态决策中枢。 当复杂请求穿透 Workflow 进入 Agent 后，它不再承担任何「干脏活」的静态任务。它只做一件事：基于当前收敛后的上下文，决定下一步做什么 —— 是检索、计算、推荐，还是直接总结答案。

这一刀切下去，直接解决了「上下文工程失控」的根源：该硬编码的绝不浪费 Token，该模型决策的绝不掺杂冗余逻辑。

第二层：Unified Policy，把破碎的控制权攥成拳头

如果说内外分层解决了「谁干什么」，那 Unified Policy 就解决了 Agent 内部「怎么控制」的问题。

火山引擎团队直接砍掉了 Thought、Action、Iteration 三个散装节点，把它们统一收敛成单一的 Policy 节点。单次模型前向传递，同时完成三件事：

• 全局规划：分析当前还缺什么信息
• 动作选择：直接输出结构化 JSON 决策指令，不用先输出自然语言再正则提取
• 终止判定：判断目标是否满足，满足则生成最终输出

带来的收益是立竿见影的：时间复杂度直接从 O (3T_model + ...) 降维到 O (T_model + ...)，系统不仅少跑了冗余节点，更从语义层面明确了「大脑」的唯一性，彻底消灭了多个 Prompt 之间控制逻辑打架的乱象。

四、深度解剖：支撑千万级调用的「三个统一」

表面看是合并了几个节点，本质上，这套架构完成了对 Agent 三大核心要素 —— 控制、行为、状态 —— 的完美收敛，也就是所谓的「三个统一」。

1. 统一控制：Policy 独裁中心，告别甩锅

松散的三节点议会制，变成了单一 Policy 的决策中心。 带来的工程红利非常现实：链路监控变得极度清晰。如果 Agent 出了问题，不用再排查是理解错了还是翻译错了，直接 Dump 当前 Policy 的状态日志就能定责。二次开发的认知负担也大幅降低，新人不用再去梳理盘根错节的 DAG 分支。

2. 统一行为：万物皆 Tool，动作空间全标准化

旧系统里，行为是割裂的：查天气是 Tool 调用，退出思考是特殊字符串标记，深度总结是 DAG 隐式分支。动作空间无法穷举，也就无法系统性优化。

在 Unified Policy 中，有一条铁律：所有系统级主动行为，必须抽象封装为标准 Tool。

• 查数据：search_database_tool
• 终止回答：exit_and_reply_tool，携带最终返回给用户的 Payload
• 复杂推理：deep_think_tool，主动调用高级推理算力
• 加载配置：load_tenant_config_tool，按需拉取租户业务文档

当「退出」和「思考」都变成了标准 API，大模型的动作空间就变得完全可枚举、可校验。接入新能力再也不用修改核心 DAG 代码，注册一个新 Tool 就完事了 —— 这才是可扩展的工业级设计。

3. 统一状态：Context Manager 捍卫内存与注意力防线

这是本次演进中最硬核、收益也最大的模块。历史状态从业务代码中剥离，交由独立的 Context Manager 统一接管。

大模型的上下文窗口，本质上是极其昂贵的 L1 Cache。Context Manager 执行了极其严苛的内存管理策略：

• 基于预算的滑动窗口：严格控制 Policy 单次看到的 Token 上限，绝不无限膨胀。
• 语义去重与折叠：检测到连续多次搜索返回同质化内容时，静默调用小模型将冗长信息压缩为高密度核心特征，再喂给 Policy。
• 记忆分级驱逐：中间工具调用的长报错栈，提取核心错误码后立刻丢弃原始文本；用户长期偏好则常驻在 System Prompt 高优区。

最终，Policy 每一轮看到的，不再是凌乱的历史流水账，而是一份被精心「清洗」过、只包含高价值浓缩信息的当前状态切片。

这也是整套架构最反常识的地方：为什么速度变快了，效果反而更好？答案就在这里 —— 不是模型变聪明了，是我们不再用垃圾信息干扰它了。排除了中间思考的冗余文本干扰，模型有限的注意力被完美聚焦在核心业务目标和干净的工具返回数据上，决策失真率大幅下降。

五、ToB 深水区红利：为什么它是企业级搜索的终极解药

如果只是做个问天气的小助手，这套架构堪称杀鸡用牛刀。但放在「搜推问一体化」的企业级复杂场景里，它就是精准的解药。

1. 搜推问三位一体，底座彻底复用

电商、内容社区里，搜索、推荐、问答原本是三套割裂的算法链路。 通过新架构，Workflow 层承担各自差异化的召回、粗排粗筛，Policy 层作为统一的「意图重写与后置组装中心」。不同业务线只需更换挂载的 Tool 集合，底层智能骨架完全复用，彻底杜绝了「每接一个大客户就重写一套 Agent」的研发浪费。

2. 轻松应对工具爆炸与多租户隔离

SaaS 产品的核心痛点是租户隔离：A 客户要内网数据库权限，B 客户只用外部开源数据。 在统一 Tool 与按需加载体系下，不同租户的配置本质上只是 Context Manager 初始化的一张映射表。系统不用启动时就把上千个工具描述全塞进 Prompt，而是根据租户身份精确加载工具切面，从根源上避免灾难性耗时。

3. 优化目标彻底解耦，进入工业级迭代正循环

企业客户永远既要效果好，又要低成本、低延迟。 旧架构下优化毫无抓手，按下葫芦浮起瓢。新架构下目标被彻底解耦：

• 想提速：优化 Workflow 并行效率，精简 Context Manager 的 Token 输出
• 想提质：专项对 Policy 做强化学习微调
• 想降本：优化 Tool 内部实现，减少无效请求透传

系统真正进入了可量化、可持续的工业级迭代周期。

六、真实数据：速度与质量双升的反常识结果

任何不谈落地数据的架构重构都是耍流氓。在未做专属 Prompt 调优、未引入 RLHF 的同等条件下，新旧架构在真实电商评测大盘中的对比数据非常亮眼：

速度与质量互斥，几乎是行业默认的常识。而这套架构打破了这个定律 —— 核心原因就是Context Manager 的状态降噪与节点合并的延迟优化形成了正向合力。

七、写在最后：好的架构，是把复杂性放对地方

回顾从标准 ReAct 到 Workflow + Unified Policy Agent 的演进，火山引擎团队其实只做对了一件事：敬畏工程规律，做好复杂性治理。

真正顶尖的架构，从来不是把一堆时髦的 AI 概念塞进模型，指望它神一样解决一切；而是通过极其克制的边界划分，把复杂性安放到系统中最适合它的位置：

• 绝对确定的硬逻辑，锁死在 Workflow
• 千变万化的动态抉择，赋能给 Policy
• 向外探索的能力延展，封装进 Tool
• 庞杂凌乱的历史记忆，镇压在 Context Manager

这套架构不一定最花哨，但一定最有生命力。它不仅解决了当下的性能焦渴，更为后续接入强化学习、探索成本建模、完善 Agent Eval 体系铺平了道路。

千模大战步入下半场，大模型应用早已越过了拼跑分的蛮荒时代。让大模型走下神坛，钻进流水线，变成坚固、稳定、疾速的工业级生产力引擎 —— 这才是接下来真正的战场。

互动话题：你认为 Unified Policy 统一工具化架构，会成为企业级 Agent 主流方案吗？我是阿宇，期待你的交流讨论^-^

本文参考：火山引擎 Viking AI 搜索千万级 Agent 架构演进与实践：从 ReAct 三节点到 Unified Policy