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

你有没有见过这样的 AgentDemo 演示时上天入地无所不能调工具、做推理、答问题一气呵成可一旦塞进千万级并发的企业级生产流水线立刻原形毕露 —— 延迟飙高、状态混乱、加个新业务就得在 DAG 里堆满 If-Else 补丁。当 Agent 彻底跨过玩具阶段挺进工业级深水区曾经被奉为圭臬的标准 ReAct 架构正在暴露它与生俱来的工程缺陷。最近火山引擎 AI 搜索团队放出的这篇架构演进干货直接戳中了无数一线研发的痛点他们把经典的 ReAct 三节点架构彻底重构推出Workflow Unified Policy AgentUP-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。共识一共四条每一条都精准命中旧架构的痛点Workflow 与 Agent 必须严格分层预定义路径、硬规则、权限控制留在传统代码里Agent 只负责动态策略决策。别用 LLM 去做普通的 switch-case。万物皆 Tool强契约工具不只是 API 调用更是 Agent 与外部世界的强契约。工具的输入输出 Schema、容错能力比 Agent 自身的推理能力更决定系统的下限。上下文管理独立化面对成百上千个工具全量加载既贵又低效。按需加载、状态压缩是长程任务的生命线。生产级工程评测体系只靠「回答好不好」衡量不了系统质量。工具调用准确率、中间态阻断率、代码判分才是多维度 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 的同等条件下新旧架构在真实电商评测大盘中的对比数据非常亮眼指标旧架构新架构提升幅度首字返回时间TTFT14.045s9.8s下降 30.22%推荐准确性评分3.263.38提升 3.76%对话综合体感打分3.764.32提升 14.78%全局综合得分--提升约 9.1%速度与质量互斥几乎是行业默认的常识。而这套架构打破了这个定律 —— 核心原因就是Context Manager 的状态降噪与节点合并的延迟优化形成了正向合力。七、写在最后好的架构是把复杂性放对地方回顾从标准 ReAct 到 Workflow Unified Policy Agent 的演进火山引擎团队其实只做对了一件事敬畏工程规律做好复杂性治理。真正顶尖的架构从来不是把一堆时髦的 AI 概念塞进模型指望它神一样解决一切而是通过极其克制的边界划分把复杂性安放到系统中最适合它的位置绝对确定的硬逻辑锁死在 Workflow千变万化的动态抉择赋能给 Policy向外探索的能力延展封装进 Tool庞杂凌乱的历史记忆镇压在 Context Manager这套架构不一定最花哨但一定最有生命力。它不仅解决了当下的性能焦渴更为后续接入强化学习、探索成本建模、完善 Agent Eval 体系铺平了道路。千模大战步入下半场大模型应用早已越过了拼跑分的蛮荒时代。让大模型走下神坛钻进流水线变成坚固、稳定、疾速的工业级生产力引擎 —— 这才是接下来真正的战场。互动话题你认为 Unified Policy 统一工具化架构会成为企业级 Agent 主流方案吗我是阿宇期待你的交流讨论^-^本文参考火山引擎 Viking AI 搜索千万级 Agent 架构演进与实践从 ReAct 三节点到 Unified Policy