豆包和千问的消费端智能体入口出现下线或收起信号，但公开渠道未见完整停服公告。更确定的变化是：长尾智能体广场从前台分发位退后，模型、插件、工作流和企业应用构建继续留在后台。
这次变化最容易被误读成“Agent 赛道退潮”。更准确的说法是：下线发生在消费端入口，不是底层 Agent 能力。
截至 2026 年 7 月 4 日，公开页面仍把豆包、千问呈现为通用 AI 助手，而不是面向开发者的智能体构建平台。另一侧，开发者和企业产品线仍保留智能体应用、工作流、插件、MCP、模型调用等能力。两条线分开看，信号就清楚了：消费端不再强调“逛智能体”，平台侧还在继续把 Agent 当成应用构建能力。
这不是小差别。对普通用户来说，智能体入口消失等于少了一个可见功能；对开发者和企业来说，真正要看的不是 App 里有没有广场，而是 API、工作流、插件和已发布应用还能不能稳定运行。
智能体广场不是好分发
消费级智能体广场的问题不是概念不成立，而是供给质量和用户需求对不上。
豆包过去的打法把自定义智能体当成内容分发的一部分：用户可以为特定场景做智能体，再放到平台里给别人用。这个模式适合冷启动，能快速制造“很多东西可玩”的感觉。但长尾智能体很快会变成另一个内容库：标题相似、能力重复、效果不稳定，还需要持续治理。
当通用助手已经能直接处理搜索、写作、图片、视频、表格、语音和文件任务，单独让用户先挑一个智能体，反而增加了路径。大多数任务不需要一个独立角色，需要的是模型理解意图后自动调用工具。
阿里和字节都在把 Agent 后台化
字节的强项是流量分发和场景包装。豆包更适合把 Agent 能力拆进搜索、创作、语音通话、视频生成、手机助手和设备入口。用户看到的是一个按钮、一段对话、一次生成，不一定需要知道背后是不是智能体链路。
阿里的落点更偏模型和云平台。千问是助手和模型品牌，企业侧应用构建则放在云平台里，智能体、工作流、插件、知识库和模型 API 被组合成可部署能力。它更像把 Agent 从消费 App 的前台入口，移到业务系统里的后台组件。
这条路更冷，但商业逻辑更直接。企业愿意为稳定调用、权限、数据隔离、日志、评测和工作流付费；消费端用户很难长期为“某个智能体角色”单独付费。