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

一、工业级大考：为什么企业级 AI 搜索必须重构 Agent？

过去一年，大模型应用赛道的竞争逻辑已经发生了根本性转移。评判一个 Agent 是否优秀的标准，不再是“它能不能通过复杂的 Prompt 调用外部工具”，而是“它能不能在真实、高并发的业务流水线里，以低延迟、高稳定、低成本的方式持续运转”。

随着模型在规划（Planning）、工具使用（Tool Use）和长上下文（Long Context）上的能力跃升，业界开始将越来越长的业务链路委托给 Agent 处理。然而，对火山引擎 AI 搜索而言，我们面临的工程挑战天然比单点聊天助手（Chatbot）高出几个数量级。

火山引擎 AI 搜索并不是一个简单的问答框，而是一套面向 ToB 企业的“搜、推、问一体化”智能引擎。它需要同时满足：

• 多模态检索： 处理文本、图像、视频素材的混合召回。

• 个性化推荐： 结合用户画像与实时偏好进行深度排序。

• 多轮对话交互： 在电商导购、内容社区、企业知识库等数十种迥异的行业场景中，维持连贯的业务逻辑。

在这种极端复杂的场景下，ToB 用户不会为“看起来很聪明但经常超时”的系统买单。他们最在意的是：系统的确定性够不够高？首字响应是不是极致的快？接入新业务线时架构会不会无限膨胀？

这也引出了当前企业级 AI 搜索 Agent 最大的痛点：上下文工程（Context Engineering）的失控。上下文并不是越多越好的“垃圾桶”，而是一种极其昂贵且有限的计算资源。企业级系统真正的难点在于：谁来负责确定性流程？谁来负责开放式决策？哪些信息必须进入 Prompt？哪些信息应该被无情压缩或驱逐？

如果我们继续试图将所有的业务复杂性都揉进一个“无所不能”的 Agent 中，系统最终会被不可控的幻觉、高昂的 Token 成本和灾难性的延迟所拖垮。我们需要的是一套能剥离确定性与不确定性、分离策略决策与上下文管理的现代 Agent 架构。

二、旧日支配者：标准 ReAct 架构在深水区的工程原罪

在技术探索早期，ReAct（Reason + Act）提供了一种极其优雅且符合直觉的范式：先思考（Thought），再行动（Action），最后根据观察结果判断是否继续（Iteration）。对于简单任务，这套逻辑无可挑剔。但当它被生搬硬套进包含搜推问多链路的千万级并发系统时，三大“工程原罪”开始显现。

在标准的三节点 ReAct DAG（有向无环图）中，模型每执行一次有效动作，都必须经历三次独立的决策流转。

我们可以用公式量化这种延迟代价。假设单次模型推理的平均耗时为 ，工具执行耗时为 ，网络 IO 与节点流转耗时为 。在旧架构下，完成一次工具调用的全链路时间成本  为：

在真实生产环境中，这不仅意味着原本  的任务被强行拆成了 ，更导致了首字返回时间（TTFT）的急剧恶化。Token 的无谓消耗和并发压力的激增，使得这种架构在算力成本面前显得极为奢侈。

在真实生产环境中，这不仅意味着原本  的任务被强行拆成了 ，更导致了首字返回时间（TTFT）的急剧恶化。Token 的无谓消耗和并发压力的激增，使得这种架构在算力成本面前显得极为奢侈。

三节点拆分导致了一个致命隐患：状态的重复搬运。Thought 节点需要读取历史对话，Action 节点需要读取 Thought 的输出，Iteration 节点又要重新理解前两者的状态以决定是否终止。

同一份业务状态在节点间反复序列化与反序列化，导致 Prompt 长度呈指数级膨胀。这不仅推高了显存占用，更引发了模型注意力的严重稀释（Attention Dilution）。模型在浩如烟海的中间推理步骤中，极易遗忘最初的用户真实意图。

在生产级 AI 搜索中，Agent 从来不是静态的。业务方今天要求接入“企微画像补全”，明天要求接入“实时库存查询”。

在 ReAct 架构下，这些新工具很难自然融入 Thought-Action 循环。例如，一个纯信息补充类的工具调用完毕后，并不需要 Iteration 节点去判断“是否退出”（因为它一定不退出）。为了绕开无效的 Iteration，工程师只能在 DAG 中硬编码各种 If-Else特判逻辑。久而久之，“优雅的智能架构”退化成了一座布满补丁的屎山代码。系统的控制权被撕裂：Thought 在规划，Action 在翻译，代码逻辑在强行路由。

本质上，当业务规模突破阈值，继续在 ReAct 的尸体上打补丁是徒劳的。我们需要重新定义控制流。

三、行业演进与共识：从 Prompt Engineering 到 System Engineering

时间推移至 2025-2026 年，业界顶级 AI 团队（如 OpenAI、Anthropic）在生产级 Agent 的设计思路上达成了惊人的共识：少谈些奇技淫巧的 Prompt，多讲点扎实的 System Engineering。

• 共识一：Workflow 与 Agent 必须严格分层。 预定义路径、硬规则校验、权限控制必须留在传统 Workflow 代码中执行；Agent 只负责在环境反馈中做动态策略决策。不要用 LLM 去做普通的 switch-case。

• 共识二：万物皆 Tool（Contract）。 工具不再仅仅是 API 调用，而是 Agent 与外部世界的“强契约（Contract）”。工具的输入 Schema、输出质量、容错能力，比 Agent 自身的推理能力更决定系统的下限。

• 共识三：上下文管理的独立化。 面对动辄千百个工具库，全量加载不仅昂贵且极其低效。按需加载（Progressive Exposure）和状态压缩（Compaction）成为长程任务的生命线。

• 共识四：生产级工程评测（Eval）。 仅靠“回答得好不好”已经无法衡量系统质量。代码判分、中间态阻断率、工具调用准确率构成了多维度的 Eval 体系。

火山引擎 AI 搜索团队高度认同并践行了这些共识。我们将系统彻底解耦，推出了全新的 Workflow + Unified Policy Agent 架构。

四、火山引擎的破局重构：Workflow + Unified Policy Agent

为了彻底解决“既要大模型聪明，又要系统轻快”的矛盾，我们将整个 AI 搜索链路一分为二：确定性归 Workflow，动态决策归 Agent。

• Workflow 层（坚如磐石的确定性骨架）：

• 负责接管所有无需 LLM 决策的前置工作。包括：风控校验、意图路由分类、用户画像预加载、基础倒排索引召回、本地配置读取等。例如，在电商搜索中，“必须先过滤无库存商品”这是一个绝对的业务红利规则，将它硬编码在 Workflow 中，远比指望 Agent 每次都“想起”调用过滤工具要可靠得多。

• Agent 层（纯粹的动态决策中枢）：

• 当复杂请求穿透 Workflow 进入 Agent 后，它不再承担任何“干脏活”的静态任务。此时的 Agent 被剥离得极其纯粹——它只基于当前收敛后的上下文，决定下一步采取什么动作（检索、计算、推荐、总结或直接抛出答案）。

如果说内外分层解决了“谁干什么”的问题，那么 Unified Policy 则解决了 Agent 内部“如何控制”的问题。

我们无情地砍掉了 Thought、Action、Iteration 三个散装节点，将其统一收敛为单一的 Policy 节点。这个全能中枢单次前向传递即可完成三件事：

1. 全局规划（Planning）： 基于目标分析当前缺失的信息。

2. 动作选择（Action Selection）：直接输出结构化（JSON Schema）的决策指令，而非先输出自然语言再由正则提取。

3. 终止判定（Termination）： 判断目标是否满足，满足则生成最终态输出。

通过这种架构，我们将前文提到的时间复杂度由  降维打击至 ：

系统不仅少跑了冗余节点，更在语义层面明确了“大脑”的唯一性，彻底消灭了控制逻辑在多个 Prompt 中打架的乱象。

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

表面看，合并节点只是工程重构；但在系统抽象层面，火山引擎 AI 搜索完成了一次哲学级别的重塑。我们将 Agent 内部运转的三大核心要素——控制、行为、状态——完美收敛为“三个统一”。

如前所述，Policy 取代了松散的议会制，成为了独裁的决策中心。它使得链路监控变得极度清晰：如果 Agent 抽风了，不用再排查是翻译错了还是理解错了，直接 Dump 当前的 Policy 状态日志即可定责。它大幅降低了二次开发的认知负担。

在旧系统中，系统的“行为”是割裂的：查天气是 Tool 调用，退出思考是特殊的字符串标记，进行深度总结是 DAG 分支里的隐式流转。这种设定让系统的动作空间（Action Space）难以被穷举和优化。

在 Unified Policy 中，我们强制规定：所有系统级别的主动行为，必须被抽象封装为标准的 Tool。

• search_database_tool：常规的外部数据获取。

• exit_and_reply_tool：显式的终止动作，携带最终要发给用户的 Payload。

• deep_think_tool：当面临财报分析等需要复杂推理的节点时，主动调用自身的高级推理算力。

• load_tenant_config_tool：按需拉取特定租户的业务说明文档。

架构红利： 当“退出”和“思考”都变成了标准 API，大模型的动作空间变得完全可枚举且可校验。接入新能力再也不用修改任何核心 DAG 代码，只需注册一个新 Tool 即可。

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

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

1. 基于预算的滑动窗口（Budget-based Window）： 严控 Policy 单次看到的 Token 上限。

2. 语义去重与折叠（Semantic Compaction）： 当检测到连续多次搜索返回高度同质化的摘要时，Context Manager 会在底层静默启动一个小参数量模型，将冗长的信息压缩为高密度的核心特征，再喂给 Policy。

3. 记忆分级驱逐（Hierarchical Eviction）： 强迫症般地清理无用状态。中间工具调用的长 JSON 报错栈？立刻提取核心错误码后丢弃原始文本；用户的长期偏好？驻留在高优常驻区区（System Prompt 段）。

现在的 Policy，每一轮看到的不再是凌乱的历史流水账，而是一份被精心“洗”过的、只包含高价值浓缩信息的当前状态切片（State View）。

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

这套架构如果只做个问天气的小助手，堪称杀鸡用牛刀。但放在火山引擎 AI 搜索这类面向企业级“搜推问一体化”的复杂怪兽身上，却是完美的解药

在电商、内容社区等场景中，搜索、推荐和问答原本是三套极其割裂的算法链路。

通过 Workflow + UP-ReAct：

• Workflow 层承担了各自差异化的召回、粗排粗筛。

• Policy 层则作为统一的“意图重写与后置组装中心”。

• 对于不同业务线，只需更换挂载的 Tool 集合（如：电商团队挂载 coupon_check_tool，社区团队挂载 hot_topic_tool），底层智能骨架完全复用。这彻底杜绝了“每接一个大客户，就重写一套 Agent”的研发惨剧。

SaaS 产品的核心痛点是租户隔离。Tenant A 需要内网数据库权限，Tenant B 只需要外部开源数据。

在统一 Tool 与按需加载的体系下，不同租户的配置本质上只是 Context Manager 初始化的一个映射表。系统无需在启动时把上千个工具描述全量塞入 Prompt 导致灾难性的耗时，而是依据租户身份进行精确的工具切面加载。

企业客户既要马儿跑（回答质量极高），又要马儿不吃草（低成本、低延迟）。

旧架构下优化毫无抓手，按下葫芦浮起瓢。新架构下：

• 提速： 优化 Workflow 并行执行效率，精简 Context Manager 的 Token 输出。

• 提质： 专项对 Policy 进行强化学习（RL）微调。

• 降本： 优化 Tool 的内部实现逻辑，避免大量无效请求头透传。

优化目标被彻底解耦，系统真正进入了可量化、可持续的工业级迭代周期。

七、数据见证：效果与时延的双轨狂飙

任何不谈落地数据的架构重构都是耍流氓。在未进行专属 Prompt 调优、未引入 RLHF 的同等起跑线下，我们将新旧架构放入真实的电商评测大盘，拿到了令人振奋的结果。

核心指标提升对比：

• 首字返回时间（TTFT）： 从 14.045s 骤降至 9.8s，大幅下降 30.22%。

• 推荐准确性评分： 从 3.26 提升至 3.38，提升 3.76%。

• 对话综合体感打分： 从 3.76 飙升至 4.32，跃升 14.78%。

• 全局综合得分： 提升约 9.1%。

深度归因分析：

1. 为什么快了 30%？ 答案就在  到  的缩减中。我们彻底干掉了无价值的多轮节点空转和巨大的 Token IO 耗时。

2. 为什么变快了反而更准了？ 这打破了常规认知中“速度与质量互斥”的定律。原因在于 Context Manager 的洗流与状态降噪。由于排除了大量的中间思考冗余文本干扰，模型有限的注意力机制被完美聚焦在最核心的业务目标与干净的工具返回数据上，决策的失真率大幅下降。模型本身并没有变聪明，是我们不再用垃圾信息干扰它了。

八、总结与展望：让复杂性回到它该去的地方

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

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

• 绝对确定的硬逻辑，锁死在 Workflow。

• 千变万化的动态抉择，赋能给 Policy。

• 向外探索的能力延展，封装进 Tool。

• 庞杂凌乱的历史记忆，镇压在 Context Manager。

这套架构不一定是最花哨的，但它一定是最具备生命力的。它不仅解决了当前的性能焦渴，更为未来接入强化学习（RL）、探索成本建模（Cost Modeling）以及打造更完善的 Agent Eval 体系铺平了道路。

在千模大战步入下半场的今天，大模型应用已经越过了拼跑分的蛮荒时代。对于火山引擎 AI 搜索而言，我们的目标从未改变：让大模型走下神坛，钻进流水线，变成极其坚固、稳定、疾速的工业级生产力引擎。

如果你也想进一步了解搜索 Agent 能力在真实场景中的落地方式，并查看具体安装与使用说明，可以点击阅读原文，前往 SearchCLI。

点击阅读原文，获取 Github cli 安装包