Agentic Search 系统构建记：我们为重新定义内部搜索环境所选择的东西
I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line and all formatting exactly as you specify.
引言：Agentic Search 系统构建记
公司内部产生的信息比想象中以更为多样的形式分散。某些数据已在数据库中整理，某些数据以文档形式保存，还有一些数据以图像或附件等难以搜索的形式存在。
问题在于，尽管数据种类繁多，寻找数据的方式仍停留在过去的方式上。
- 数据库必须逐一组合列条件进行检索。
- 文档搜索依赖关键词基础或缺乏上下文的嵌入搜索。
- 公司内部知识由多模态构成，搜索难度在感受上呈指数级增长。
随着大语言模型（LLM）的出现，搜索环境整体发生了巨大变化。基于 RAG 的方法迅速扩散，对公司内部知识的 AI 搜索需求也自然增长。
我们的团队也尝试了 RAG、GraphRAG、Pipeline RAG 等多种方式，最终得出一个结论。
要将多样的领域、多种模态、多个资源稳定地串联成一个流程进行搜索与组合，最终需要 Agentic Search 结构。
本文将分享在设计与构建 Agentic Search 系统时特别重要的要点。
Agent Flow: 将 Chat 视为 DAG
Agent 通常被描述为类似 ReAct 模式的结构，即 LLM 调用工具（Tool）来解决问题。将其扩展为系统层面后，视角会发生变化。此时不再是单纯的顺序 LLM 调用，而是把整体执行流程解释为 DAG（有向无环图） 更为自然，并且在同一个 DAG 中如何管理和精炼 Agent 的 Context 成为关键要素。
在设计 Agent Flow 时可以按以下步骤进行：
- 将需要解决的 Task 拆分为 Sub Task。
- 决定每个 Sub Task 在哪个 Node 上处理。
- 设计 Node 之间的连接顺序和条件。
Node 的粒度（granularity）决定整体性能。过度细分会导致 Node 之间的跳转（Hop）和 LLM 调用次数增加，从而提升成本和 Latency。相反，如果 Node 承担过多职责，则内部逻辑控制、调试以及质量管理都会变得困难。
例如，如 Figure 1 所示，将用户问题分析细分为多个阶段性 Node，虽然在功能上更为明确，但政策决策和控制流的管理点会分散到多个位置，导致代码复杂度提升，并且每个阶段的 LLM 调用都会增加 Latency 和成本。
因此，我们审视了是否可以将这些部分整合为基于 CoT（Chain‑of‑Thought） 的单一推理流程，结果认为“拆分本身不是答案，而是将拆分后的部分 Sub Task 通过提示（prompt）合并以提升效率”，于是得出了需要类似 Figure 2 的设计方案。
Figure 1. High Granularity Node Design
(暂无图片 – 用于说明的占位符)
Figure 2. CoT Based Low Granularity Node Design
(暂无图片 – 用于说明的占位符)
Tool 设计：Agentic 系统的核心
在 Flow 设计之后，对性能影响巨大的因素是 Tool 设计。从检索系统的角度来看，Tool 通常分为以下三类。
- Context Handling Tool
- User Interaction Tool
- Resource Tool
在 Agent 系统中，Tool 不只是简单的函数调用，而是执行检索策略的单元，甚至决定用户体验的关键要素。
1. Context Handling Tool
良好的 Context 构建是 Agent 制定检索策略并理解文档的核心。我们在初始 Context 中加入了用户的元信息、检索策略以及检索目标 Space 的信息。
Figure 3. 初始 Context 组成
(图片占位 – 说明用)
Agent 运行期间，需要将 Tool 的结果结构化后传递，并且当 Context 超过 LLM 的 Context Size 时必须进行压缩。尤其是文档检索 Agent，Context 中可能会包含不必要的部分，导致 LLM 的 Context 不必要地膨胀。为防止这种情况，我们新增了分析检索到的文档的 Tool，并在预处理阶段对文档 Chunking 进行优化，使得基于已有 Context 的 SLM 能够对文档进行分析。
Figure 4. Context Handling
(图片占位 – 说明用)
2. User Interaction Tool
传统的 AI 系统大多停留在基于文本的问答上。然而在 Agentic Search 中，Interaction Tool 的意义完全不同。Agent 可以直接调用 UI 元素，引导用户行为、提供或强制选择，并对输入进行验证。
例如，假设 Agent 通过 Tool Calling 向前端（FE）发送如下 Custom HTML。
Figure 5. Custom HTML Tag
(图片占位 – 说明用)
前端会把该 Custom Tag 替换为预先定义好的组件并展示在 UI 上。这样，Agent 不再是单纯的文本生成器，而是能够控制包括用户交互在内的完整决策流程的执行主体。
3. Resource Tool
检索系统需要访问各种资源。许多系统以 MCP 形式提供资源访问。我们在内部实现了针对核心资源的检索 Tool，接口采用 MCP 架构。这样，即使新增其他 MCP 服务器，Agent 仍能顺畅调用 Resource Tool。
Tool 是影响系统 Context 管理、UX 关联、检索资源访问等性能的直接因素，即使 backbone LLM 模型更换，也能保持 Agent System 的稳健性。
Agent Runtime: LangGraph 基于实现的原因
Tool을 정의하고 Flow를 설계하면 이를 구현해 서버에서 동작하도록 해야 합니다. 실제 Agent 실행 방식은 Chat보다 DAG 형태에 가깝기 때문에 서버도 State Machine 형태의 프레임워크를 기반으로 구현되어야 합니다. Agent Runtime은 일반적으로 다음과 같은 특성을 가집니다.
- 여러 비동기 작업이 순차 또는 병렬로 실행됩니다。
- 각 Step의 상태가 누적되며 수렴합니다。
- Node 단위 실행이라는 점에서 Event‑Driven DAG 실행 모델과 유사합니다。
이러한 구조를 안정적으로 운영하기 위해 저희는 LangGraph를 선택했습니다。
LangGraph를 선택한 주요 이유
- Pregel 기반 Graph Runtime이라 recursive 작업이나 multi‑turn 확장이 용이합니다。
- Worker 기반 실행으로 scale‑out 가능한 배치 시스템 구축이 가능합니다。
- Node의 Callback 함수를 활용해 Node 단위 로깅 및 Traceability를 위한 Langfuse 연계가 쉽습니다。
결론적으로 LangGraph는 저희가 구축하고자 했던 Agent Runtime의 성격과 가장 잘 부합했으며, 운영에 필수적인 모니터링 연계가 용이했기에 선택하게 되었습니다。
结语
我们决定在公司内部搜索系统中引入 Agentic Search，并不是单纯因为“LLM 正流行”。
三星电子内部的知识是在各种职能、业务部门以及复杂的商业情境中产生的。因此，内部搜索引擎必须能够灵活应对各种情境，同时专注于员工的工作需求。要同时满足这两点，单靠基于 RDB 的搜索或简单的 Naïve RAG 显然存在明显的局限。
为了处理多模态、各种资源以及复杂的搜索场景，需要基于 Document Understanding（文档理解）和 Context Engineering（上下文工程）的 Agentic Search System（代理搜索系统）。
本次建设经验让我们重新夯实了 Agent 系统设计的基础，并计划持续提升搜索 Agent，以便能够应对更多公司内部的领域。
公司内部的知识极其复杂且相互交织。破解这一难题的关键在于 基于业务领域的 Context Engineering，以及能够体现这一点的 Agentic Search System。