导读： 企业复杂任务真正耗时的，往往不只是"提问"或者"问答"，而是把目标、上下文、异构数据、执行工具、证据链和交付标准串成一条可持续运行的生产应用链路。Agentic Search 2.0 是面向长时间、跨数据源、跨工具的复杂任务，强调结果可追踪、可复核、可交付的通用搜索Agent。它要解决的不只是让 Agent 更会聊天，而是让搜索、推理、任务执行、权限治理与记忆总结沉淀形成生产级闭环能力。
分享嘉宾
汤祯捷：阿里云智能AI搜索产品负责人
主要内容包括以下几个部分：
- 不只是更会聊天，而是接管完整业务流程
- 双链架构：搜索智能与 Agent 执行形成闭环
- 生产级实施：编排、检索、沙箱与安全不能分开建设
- 从一次任务到持续进化：Memory、Skill 与案例验证
不只是更会聊天，而是接管完整业务流程
对话式问答与普通 RAG 已能完成基本检索，但在企业深度业务流程中，认知负荷仍然落在业务人员身上：人需要先拆解问题，在文档、Elasticsearch、向量数据库、Wiki、网页数据和数据库之间反复切换，再用手工方式比对冲突信息、补齐来源，最后整理成报告、表格或处置建议。任务越长、数据越多，这条链路越容易在中间状态、失败恢复和结果一致性上失控。因此我们做了很多尝试。
以OpenClaw来举例，现有企业Agent往往很难独立承担复杂流程，主要卡在六个方面。
其一，复杂任务缺乏可靠编排，子任务依赖、循环调用、中间状态和失败恢复难以统一管理；
其二，PDF、图片、表格、视频和数据库等非结构化、结构化数据难以统一解析；
其三，长期记忆无法持续沉淀，多来源记忆容易冲突，引用也难以回到原文；
其四，多租户权限、工具权限、Prompt 注入防护和执行审计不完整；
其五，外部 API、数据库、RPA、邮件与即时通信系统的集成缺乏统一抽象，容易中断且难以自愈；
其六，Agent 能回答一般问题，却缺乏对具体业务口径、规则和多目标约束的理解。
这六个典型问题让Agent在企业落地的过程中举步维艰。
如果借用自动驾驶来类比：过去单轮对话式的搜索Agent，更像 L2 级辅助驾驶------每次由人发出指令，系统执行一步后便等待下一步输入；而 Agentic Search 2.0 追求的是 L4 级自动驾驶------人只需设定目标和约束，Agent 自行完成感知、规划、执行和交付的全流程，途中遇到问题也能自主恢复。
Agentic Search 2.0 搜索Agent将目标从"找资料"转向"完成真实任务"：先识别目标、约束、口径和隐含优先级，再并发检索多源知识与实时信息，通过 DAG 调度 SubAgent、Skill、MCP 和 Sandbox，最终输出带证据、可复查的交付物。整个过程不再以单轮回复为终点，而是覆盖理解、拆解、执行、验证、汇总和交付。
双链架构：搜索智能与 Agent 执行形成闭环
整体架构由"搜索智能"和"Agent 执行"两条主链组成，并由统一 Orchestration 串联知识、检索、工具、记忆、安全和交付。搜索侧负责多模态文档解析与结构化切片、存量 ES 向量库只读复用、Memory、PageIndex、Wiki、ES 四层检索、公域联网搜索与企业私域融合，以及 RRF 加权、重排、冲突消解和来源标注。执行侧由 Harness 主 Agent 与垂直 SubAgent 组成，负责 DAG 并发、状态管理、结果聚合、MCP、Skill、Sandbox 安全执行、思考图谱、执行计划、全链路 Trace，以及企业权限注入、多租户隔离和审计治理。
Harness Agent 可分为四层：作为"大脑"的 Orchestration 支持 Plan、ReAct、DAG 等策略；作为"四肢"的 SubAgent Matrix 提供 Code、Browser、Summary、Report 等能力模块；作为"感官"的 Tools & Parse 集成联网搜索、内容解析、数据处理和 MCP 扩展；底座则通过 Sandbox、Trace、Agentic Memory 与多租户安全机制保证长任务稳定运行。搜索不再只是 Agent 生命周期中的一个环节，而是与执行、记忆共同组成"信息检索---任务执行---持续进化"的循环。
这套闭环包含四个连续阶段：理解目标，形成可执行任务定义；融合检索，将 ES、Memory、PageIndex、LLM Wiki 与联网搜索结果统一召回并消解冲突；动态编排执行，由 DAG、多 Agent、Skill、MCP 和 Sandbox 协同完成长任务；沉淀自我进化，把偏好、事实、成功路径和方法抽取为智能 Memory 与可复用 Auto Skill。
生产级实施：编排、检索、沙箱与安全不能分开建设
复杂任务首先需要动态 DAG，而不是完全依赖大模型临场规划。部分步骤适合由模型理解和生成，部分步骤必须交给确定性自动化流程。系统需要判断何时调用模型、何时执行固定工具，并屏蔽无效工具和不必要的模型调用。DAG 按依赖关系组织子任务，支持多分支并行；父任务取消时，子任务与工具调用可快速停止并释放资源，避免任务已结束但算力仍被占用的情况。
在云上，多用户同时发起长任务时，挑战并不是单次查询延迟，而是数百个任务实例的资源调度、执行时长和业务连续性。实践中需要把并发访问、资源管控、弹性扩缩容、状态记录和可观测性放在同一层处理，每一步都保留 History、Memory 与 Trace。SubAgent Matrix 可按需组合多信源联网搜索、企业融合知识库、智能抓取、Skill 和工具管理；复杂任务可并行执行 30---50 个 SubAgent 子任务。
搜索侧的难点从"召回一段文字"转向对超大、多模态文档的结构化理解。处理链路包括扫描件、手写体和复杂表格识别，OCR 精准提取，语义理解、表格结构化和内容重组，再输出 TXT、Markdown、JSON 或表格数据。在《三国演义》级别的巨型 PDF 解析示例中，PyMuPDF 解析耗时控制在 4.8 秒以内；针对极端扫描版和乱码文件，系统采用自动缩放、纠错、孤切（孤立区域裁切）、表切（表格区域识别与提取）和弹窗切（弹窗内容分离提取）等预处理。
大文档不能只做简单切片。文档越长，向量空间中的信息碎片化越严重，模糊问题越难命中。PageIndex 通过目录式、层级化索引保留文档整体结构，能够定位章节、段落和页面，并生成层级路径与摘要。它会增加索引构建时间，但在超长文档检索中，可以避免信息被切碎后失去上下文。
融合检索同时接入知识库、用户文件、数据库和 Web。向量召回与关键词召回进入 Hybrid Recall，经过 Rerank、权限过滤、Citation Validation 后，再生成 Summary、Insights、Citations 和 Next Steps。四层知识检索体系由粗到精：第一层 Memory 记录查询历史和用户偏好；第二层使用 KNN 与 BM25 召回候选；第三层以 PageIndex 做层级定位；第四层通过 ES 或 SQL 对结构化数据进行查询、条件过滤、聚合分析和可视化输出。系统可接入 50+ 类数据源，在内部评测集上的多元搜索召回准确率达到 90% 以上。
对于已有 Elasticsearch 数据，方案采用只读方式复用现有索引和向量库，在其上叠加多模态解析、索引层和编排能力，不要求客户搬迁主数据或重建全部索引。这样既能把日志、搜索、代码等 ES 数据与文档、图片、视频和知识库统一检索，也减少迁移周期、成本和数据风险。
代码执行与资产流转必须置于 Sandbox 内。独立 Python 安全沙箱负责自动拉取依赖、资源隔离、按需分配和受控访问；执行结果生成临时文件后，通过加密链路上传 OSS，再由签名访问完成前端渲染与打包导出。长任务运行过程中产生的缓存和暂存数据需要智能清理，避免本地磁盘被持续占满。权限校验、最小权限访问和操作日志审计贯穿代码执行、结果产出、安全上传和导出访问全过程。
安全底座还覆盖 RASP 反注入防御、Query 与 Chunk 召回双重拦截、用户数据物理与逻辑隔离、主进程沙箱和内存溢出防护，以及系统级安全审计。企业 Agent 的安全不是在结果输出后补一层审核，而是从检索、工具调用、代码执行到资产交付的全链路约束。
从一次任务到持续进化：Memory、Skill 与案例验证
Agentic Memory 负责把一次性执行转化为可复用能力。系统从长期记忆、本地记忆、知识库、用户偏好和外部知识源并行召回 Top K 结果，完成合并去重、语义与权重重排，再把 System Prompt、历史对话、检索记忆片段和用户输入融合为增强上下文，输出高相关、无冗余、可追溯的记忆片段。任务结束后，关键事实和有效路径通过异步写回持续更新。
记忆并非单一存储，而是由会话内短期记忆、跨 Session 长期记忆、设备本地记忆、知识库和用户画像共同组成。多来源记忆发生冲突时，需要通过合并与重排消解；成功的任务路径还可以从历史对话、用户行为、文档知识和 API 调用中自动抽取为 Skill，经过输入输出定义、参数校验、版本管理、权限控制、调度执行和效果评估，形成可重复使用的任务能力。
在结果完整性上，系统把模型能力与确定性执行分开：大模型用于生成代码，代码负责生成数据，再把结构化数据嵌入最终报告，降低直接由模型生成数字带来的波动。端到端报告链路从大型 PDF 文件上传开始，依次完成极速解析、主 Agent 混合召回、结构化报告生成，并通过 OSS 打包下载。跨域分析则将多模态知识库、Web 搜索、智能 Memory 与 DataAgent 四路并行召回，统一完成去重、权重排序、结果融合和溯源。
在消费电子业务洞察案例中，企业的产品覆盖 100+ 国家，智能终端部署于飞书，服务 1,000+ 内部研究员、产品经理和市场团队。知识范围包括约 2GB、3,000 份行业研究文档，约 1.5GB、50 万条 VOC 评论，以及约 1.5GB、2,000 份消费者洞察文档；系统月均调用 10,000 次，并发峰值 50 QPS。
落地前，研究员完成一份深度研究报告通常需要 3---5 个工作日，其中超过 30% 的时间花在跨系统查找和比对信息上，报表生成依赖手动整理。落地后，单份深度研究报告缩短到小时级，信息查找时间占比降至 10% 以下，ChatBI 报表可秒级生成。质量侧采用五通道并行召回、Memory-Aware 过滤和多目标 Reranker；资产侧将 5GB+ 文档、50 万条 VOC 与历史洞察统一沉淀为可检索、可复用、可溯源的研究资产，Citation 可归因到报告页码，并通过跨产品记忆共享减少重复研究。
这套实践最终形成了一条清晰链路：搜索是知识入口，Agent 是执行引擎，Memory 是持续进化机制。企业级搜索 Agent 的关键不在于单次回答是否流畅，而在于它能否在长时间、多数据源、多工具、多用户的环境中稳定完成任务，并留下可验证的结果和可复用的能力。
