1. 从找到答案到完成任务Agentic Search 到底改了什么1.1 找到答案和完成任务隔着一整段执行链路云栖大会上一场关于AI搜索的讨论核心不是又发布了一个多厉害的模型而是把整个交互逻辑换了个方向从帮你找到答案变成帮你把事情办了。这个转变背后就是 Agentic Search——搜索不再是你敲几个关键词、拿回一串蓝色链接而是你把自己的目标丢给一个智能体它自己去查资料、调接口、做判断、把结果一步步执行出来最后给你一份可用的产出。这篇内容我结合阿里云百炼的实际开发流程把 Agentic Search 是什么、它和传统RAG搜索差在哪、以及自己动手搭一个最小可用的 Agent 搜索服务要踩哪些坑完整梳理一遍。想省事直接照抄代码的重点看第三部分还在纠结要不要接这套方案的先看第一部分。先说我开发中反复遇到的一个典型场景。用户对着传统AI搜索框问帮我查一下这周杭州有什么技术活动。传统做法是模型检索一堆网页然后总结说这周杭州有XX峰会、XX沙龙然后呢然后用户自己去查地铁怎么走、自己对比哪个话题更相关、自己判断要不要买票、自己把活动信息整理进日程。整个链路里AI只贡献了最开始的一句话。而完成任务的意思是用户把同样的问题丢给Agent它自己去筛选活动、查票价、对比话题、参考你的日程安排最后推给你一张本周六下午适合参加、步行15分钟可达、预算80元以内的候选方案附上会场地址和报名链接。这中间靠的不只是搜索能力而是围绕目标的一次完整执行。所以Agentic Search 的核心价值不是搜索得更准而是把搜索终点从信息变成行动。信息是半成品行动才是交付物。这个转变本质上重新定义了搜索产品的边界。1.2 为什么传统RAG和对话式搜索都撑不住这个需求RAG检索增强生成过去两年很火它的本质是检索相关信息 生成回答把知识库或网页里的片段捞出来喂给大模型得到一个有出处的回答。这个流程在小范围问答里很稳但在真实任务里天花板非常明显它没有任务状态用户问一次就结束无法在多轮交互中维护我已经订好了酒店接下来安排路线这种上下文它不操作外部系统模型只能读文本不能帮你查库存、写文件、调API、发通知它缺少验证回答基于检索片段但片段之间可能互相矛盾模型不会主动发现它的终点是一段话不是成果物用户拿到答案之后所有后续动作仍然需要自己做对话式搜索解决了回答更自然的问题但没有解决回答之后怎么办的问题。Agentic Search 加上的正是这后半段规划、工具调用、验证、产出交付。这也是我理解里阿里云在云栖上强调真正的AI搜索应该从答案走向任务的核心逻辑。从产品形态上看三者的差异可以直观对比如下维度传统搜索RAG/对话式搜索Agentic Search用户输入关键词自然语言问题自然语言任务输出链接列表一段回答可执行的成果物是否调用外部工具否否是是否有任务状态跟踪无无有是否有执行验证无弱强典型场景查资料问知识办事情2. Agentic Search 的三板斧拆解、调用、验证2.1 意图理解与任务拆解把一句话变成可执行计划Agent 收到用户一句话之后第一步不是忙着搜索而是先把这句话翻译成一组子目标。比如帮我策划一场部门团建会被拆成确认人数和预算、搜场地、查天气、列备选方案、给出推荐。拆解质量直接决定后面所有步骤的质量这一步做不好后面全是无用功。我在实际开发中会给模型设定固定的拆解输出格式不让它自由发挥。推荐用 JSON Schema 约束比如这样{ task_id: 002, objective: 找到周五下午适合团建的室内场地, sub_tasks: [ {id: a, description: 确认参与人数与预算, tools: [], dependencies: []}, {id: b, description: 搜索室内团建场地, tools: [search_venue], dependencies: [a]}, {id: c, description: 查询周五天气, tools: [get_weather], dependencies: []} ] }有几个拆解时的注意点都是踩过坑换来的强制拆出至少三个子任务。如果系统Prompt不约束模型很容易把任务简单化成搜一下然后总结那又回到了RAG的老路标注依赖关系。没有依赖关系的拆解只是清单有了依赖关系Agent才知道哪个先做、哪个后做拆解结果要过一道校验。检查有没有依赖环、有没有明显缺失的子任务比如组织团建却漏了预算这类问题在早期最容易出现任务拆解的颗粒度也要把握好。太粗子任务本身还是复杂到没法执行太细模型调用次数暴涨成本和延迟都上去了。我的经验是每个子任务应该能被一个工具调用一次模型判断完成如果做不到就继续拆。2.2 工具调用与MCP协议Agent 的手和脚模型自己不会执行操作它只能生成我想调用 get_weather参数是 {city: 杭州, date: 2026-06-20}这样的指令。真正干活的是注册进来的工具函数。工具是Agent的手和脚模型是大脑。这部分在工程上叫 Function Calling 或 Tool Use是Agentic Search和传统搜索最显著的差异点。一个工具的入参定义要写到让模型一看就懂怎么调。下面是一个标准的工具描述{ type: function, function: { name: get_weather, description: 查询指定城市在指定日期的天气情况返回温度、降水概率、风力等级, parameters: { type: object, properties: { city: {type: string, description: 城市名如杭州}, date: {type: string, description: 日期格式YYYY-MM-DD} }, required: [city, date] } } }这里有个容易被忽视的点工具的 description 一定要写清楚什么场景下用、参数格式是什么、返回内容是什么。模型是靠这段描述来决定何时调用工具的描述模糊的后果要么是模型宁可不调用、要么是拿错参数乱调。再聊一下 MCPModel Context Protocol模型上下文协议。以前接一个天气API写一段代码接一个数据库又写一段每个工具的接入协议都不同Agent每接一个新服务都要做一遍适配。MCP的意义在于把工具接入方式标准化了相当于给所有工具统一了一个标准的接口形态。阿里云百炼的 Agent 能力对 MCP 工具市场的支持让开发者可以快速把大量外部服务接进Agent流程不用每个都从头写对接层。这一点在搞实际项目的时候节省的时间非常可观。工具选型我一般遵循三个原则低频工具不着急接。不要一开始就追求万能Agent先把最高频的两三个工具打磨好工具返回要结构化。返回纯文本会让模型的后续判断出错统一返回 JSON并附上一段人类可读的摘要高频场景做缓存。同一个参数的工具调用结果缓存下来能省掉大量重复的模型调用和API费用2.3 执行验证与反馈闭环怎么防止 Agent 跑偏Agent 执行完一轮不是立刻给用户答案而是先自我评估调用的结果是否解决了用户最初的目标有没有信息缺口如果发现矛盾要不要再查一次这个环节很多人忽略但恰恰是决定靠不靠谱的关键。实际开发中我至少会做三件事给每个子任务设完成标准。没达标就继续迭代不许糊弄过去允许Agent对前一步结果提出疑问。比如天气接口返回的是今天有雨但用户问的是明天日期是否传错了这种自我纠错能解决大量低级错误最终输出前审查执行日志。把Agent的执行过程压缩成一两段摘要附在结果里用户能看懂这个东西是怎么一步步得出来的这里特别推荐 ReAct 模式Reasoning Acting Observing 循环。简单说就是让模型想一步、做一步、看结果、再想下一步而不是一次性把所有步骤规划完。一次性规划的方案看起来很完整但中间任何一步出现意外就会全盘崩溃ReAct 模式虽然响应会慢一点但每一步都在根据实际情况调整稳定性高得多。3. 用阿里云百炼把 Agentic Search 跑通最小实现3.1 环境准备开通百炼并拿到 API Key实际操作层面我以阿里云百炼为例跑通一个最小可用的 Agentic Search。这套流程不需要买GPU服务器用平台提供的 Serverless API 就能完成。第一步登录阿里云控制台搜索百炼开通大模型服务平台。在平台的API-KEY管理页面创建一个 Key这个 Key 就是调用模型的凭证。然后在本机装好 Python SDKpip install dashscope设置环境变量export DASHSCOPE_API_KEYsk-你的key如果你更倾向私有化部署开源模型也可以把 vLLM 0.26.0 部署在阿里云 ECS 上通过 OpenAI 兼容接口接入同样的 Agent 流程。vLLM 的安装不复杂下载对应的 wheel 包配合 ECS 上的 Ubuntu 环境跑起来即可。不过初期验证建议直接用百炼的按量付费成本可控省去运维精力。3.2 核心代码一个能规划、能调用工具的搜索 Agent下面这段是完整可运行的逻辑骨架不依赖任何外部服务就能跑通流程。你需要把 get_weather 和 search_hotel 里的实现换成真实API地址。import json import dashscope from dashscope import Generation dashscope.api_key sk-你的key # 1. 定义两个工具天气查询和酒店搜索 TOOLS [ { type: function, function: { name: get_weather, description: 查询指定城市在指定日期的天气情况, parameters: { type: object, properties: { city: {type: string, description: 城市名如杭州}, date: {type: string, description: 日期格式YYYY-MM-DD} }, required: [city, date] } } }, { type: function, function: { name: search_hotel, description: 查询指定城市、日期的酒店推荐及价格, parameters: { type: object, properties: { city: {type: string, description: 城市名}, date: {type: string, description: 入住日期格式YYYY-MM-DD}, budget: {type: number, description: 预算上限单位元} }, required: [city, date, budget] } } } ] def get_weather(city, date): # 这里替换为你实际的天气API调用 return {city: city, date: date, weather: 晴, temperature: 28} def search_hotel(city, date, budget): # 这里替换为你实际的酒店搜索API调用 return { city: city, date: date, budget: budget, options: [酒店A 450元/晚, 酒店B 520元/晚] } def agent_loop(user_task, max_rounds10): messages [ {role: system, content: 你是一个任务规划型搜索助手。当用户提出任务时先拆解子任务逐步调用工具完成最后给出完整结果。重要不确定的信息必须查工具不要编造。}, {role: user, content: user_task} ] for _ in range(max_rounds): resp Generation.call( modelqwen-plus, messagesmessages, toolsTOOLS, result_formatmessage, ) msg resp.output.choices[0].message messages.append(msg) # 保留模型的分析和工具调用记录 # 如果模型要求调用工具 if msg.get(tool_calls): for tool_call in msg[tool_calls]: fn_name tool_call[function][name] fn_args json.loads(tool_call[function][arguments]) result globals()[fn_name](**fn_args) messages.append({ role: tool, tool_call_id: tool_call[id], content: json.dumps(result, ensure_asciiFalse) }) continue # 让模型继续分析工具结果 # 没有tool_calls时说明模型准备输出最终结果 return msg[content] return 已达到最大迭代轮次返回当前结果。 if __name__ __main__: task 帮我规划下周二去成都出差的住宿和天气预算每晚500元 result agent_loop(task) print(result)这段代码里有几个关键细节值得单独说明tools 定义是模型了解工具的唯一渠道。字段名、类型、描述必须写准确一个错误的 schema 可能导致模型永远无法正确调用工具消息上下文必须完整回传。每次把模型返回的 message 追加进 messages 列表再附带工具执行结果模型才能形成调用→观察→下一步的循环记忆。如果漏掉这一步模型会忘记自己刚才准备干什么max_rounds 是保命符。Agent 偶发死循环时这个参数能强制中断不让它在某一轮里无限消耗 token。建议生产环境设成 10 到 15 之间3.3 完整案例从帮我出差到一份可用行程单走一遍完整流程。假设用户输入帮我安排下周三去北京参加一个技术会议出差两天预算3000元。Agent 的执行过程大致如下第一轮模型拆解任务判断需要获取会议信息、查询高铁/机票、查天气、订酒店、生成行程单随后发起第一次工具调用 search_events(city北京, date下周三)。第二轮模型拿到结果——北京国际会议中心举办AI基础设施峰会主题与大模型基础设施相关判断符合用户需求继续调用 search_transport(出发地杭州, 目的地北京, date下周三)。第三轮调用 get_weather(北京, 下周三)获取出差期间的天气情况。第四轮调用 search_hotel(北京, 下周三, budget1000)筛选出预算内的酒店。第五轮模型汇总所有结果生成最终行程文档。输出是一份完整的日程表不再是一堆链接日期上午下午晚间备注周三高铁G20杭州-北京入住酒店、参会签到参加开幕主题演讲天气晴23度周四参加AI基础设施分论坛与参展商交流高铁G33返回杭州建议提前1小时到站这份行程单里的每一个字段都能找到对应的工具调用记录不是模型凭空捏造的。这就是 Agentic Search 和传统搜索最直观的区别——用户拿到的是可以直接照着执行的东西。实际开发中你还可以把 Agent 生成的行程单自动上传到 OSS 存储再用短信服务推送给用户。这些都属于任务完成的交付环节Agentic Search 的价值就在这里它不返回信息它直接操作你的系统。3.4 部署和成本控制别让小实验变成大账单如果要把 Agent 服务部署到线上我建议在阿里云 ECS 上选一台 2核4G 的实例跑服务入口Ubuntu 系统即可按量付费先跑起来。Agent 应用本身是 IO 密集型的对 CPU 要求不高重点是模型调用的费用。成本方面有几个实测下来的控制手段一个复杂任务会触发 5 到 20 次模型调用单次调用的 token 消耗从几百到几千不等。按百炼的按量计费单个任务成本基本控制在几毛到几块钱量级可以接受模型分层路由。简单判断用 qwen-turbo中等推理用 qwen-plus复杂规划用 qwen-max。不要所有请求都用最强模型很多场景大材小用工具结果缓存。同一个城市、同一天的天气查询一小时内的结果基本一样缓存掉能省下大量重复调用给循环设上限。除了 max_rounds还可以在系统提示里要求最多尝试X轮后必须收敛双保险防止失控4. 常见问题与排查技巧实录4.1 模型不调用工具直接编答案这是新手遇到最多的问题明明把 TOOLS 传进去了模型却无视工具直接凭常识回答。原因基本出在系统提示词没有约束模型的行为。解决办法是在 system prompt 里明确加一句凡是涉及实时数据、地理位置、特定日期、价格、库存的信息必须调用工具验证后回答禁止直接给出结论。如果加了仍不调用检查工具描述中是否提供了足够的触发信号比如查询指定城市在指定日期的天气情况这个描述已经足够清晰。另外给工具加一两个 few-shot 示例也有效。在对话历史中放入一段用户提问→模型调用工具→工具返回→模型总结的完整示例模型会照着这个模式走。4.2 工具返回了但模型不会正确使用结果模型调了天气API返回结果是晴天但用户问的是后天Agent 没校验日期直接回答明天适合出行。这是典型的工具结果使用逻辑缺失。我一般从三方面修在工具返回中增加数据有效时间。比如返回里带一个 result_date 字段让模型能看到这组数据的有效日期在系统提示中强调输出前需要把工具返回和用户提问逐项对齐强迫模型做一次字段级核对在代码层对关键参数做兜底校验。用户问后天程序先把后天解析成具体的 YYYY-MM-DD 再传给工具而不是让模型直接传后天两个字4.3 死循环和上下文膨胀Agent 卡在搜索→结果不理想→再搜索的循环里出不来是生产环境常见问题。三个手段配合使用设 max_rounds 强制退出比如10轮后强制收敛记录每轮进度摘要连续三轮没有里程碑进展就切换策略或直接返回当前结果压缩历史上下文。多轮调用后消息列表会很长token 占用暴涨。把旧的工具返回结果用一段 prompt 压缩成300字以内的进度摘要再作为一条消息放回上下文能有效控制长度压缩 prompt 的示例把以下多轮工具返回结果压缩成300字以内的任务进度摘要保留关键数据和未完成任务清单去掉冗余细节。4.4 Agentic Search 落地中的阿里云资源速查表最后整理一份我实际开发中经常搭配使用的阿里云资源清单给想快速落地的朋友做个参考场景阿里云资源用途模型 API百炼平台 / dashscope调用 qwen 系列模型完成规划和推理私有化模型服务ECS vLLM自托管开源模型数据不出内网结果存储OSS存放 Agent 生成的文档、图片、报表业务数据访问RDSAgent 读取数据库执行数据查询和分析任务完成通知短信服务Agent 执行完主动推送结果给用户Java构建加速Maven仓库 阿里云镜像Agent 自动化构建任务时拉取依赖API接入安全SSL证书服务为 Agent 服务接入点启用 HTTPS定时巡检云监控 定时触发定期触发 Agent 执行巡检或日报生成这张表是想说明一个容易被忽略的点Agentic Search 落地从来不是孤立的搜索功能它本质上是和云生态深度绑定的任务执行器。上面这些看似零散的资源在 Agent 的设计里全是任务执行链路上的工具节点。从我个人的实际体会来说从找到答案到完成任务最深刻的变化不是技术上多挂了几个模块而是产品设计的出发点变了。以前做 AI 搜索想的是如何让回答更准确现在做 Agentic Search真正要想的是如何让系统负责到底。如果用户问完帮我安排出差最后只丢出三篇文章这个任务就没有完成。Agentic Search 逼着我们把搜索、业务系统、工具 API 当成一个整体来设计这确实比调优单个模型的 prompt 复杂得多但这也正是它真正有价值的地方。最后再分享一个小建议别一上来就做那种一句话生成五十页报告的宏大 Agent先跑通查天气订酒店生成行程单这种最小闭环把工具调用、上下文管理、错误恢复全捋顺了再往上面加技能。骨架稳了扩展只是体力活骨架不稳功能越多翻车越快。