在大模型赋能政务领域的过程中，“选择 MaaS 平台还是自研” 成为不少团队的核心困惑 ——MaaS 能快速启动验证场景，却存在业务适配与功能拓展的局限；自研虽能深度融合政务流程，却面临周期长、门槛高的挑战。文章结合实战经验，拆解从 MaaS 验证到自研深耕的落地路径，为政务 AI 项目提供清晰方向。做AI项目的同行，尤其是在政务领域，最近一定纠结过一个问题：我们要不要搞自己的AI Agent系统？还是接一个豆包、混元、通义这种MaaS平台就行？自研太慢，平台又不稳，到底怎么选？很多人觉得这是“技术路线选择”，但在我看来，更像是一个阶段选择问题。你到底是为了验证可能性，还是为了长期落地？是要快速跑通场景？还是让Agent成为业务的一部分？我在“边聊边办”“智能派单”等政务项目中，对这个问题踩过不少坑，也总结出一条清晰的路径—— 先用MaaS快跑，验证方向；后期自研深耕，构建能力。这不是一句模糊的“两者结合”，而是一套清晰的实践框架。01 MaaS平台：快速验证、低门槛启动，但有“天花板”先说说为什么要用MaaS平台。主流的MaaS（Model-as-a-Service）平台，如豆包、混元、通义、文心一言、DeepSeek等，基本都封装了大模型能力和推理服务，并提供了以下能力接口： 通用问答（基于提示词） 知识检索（RAG增强） 对话记忆（上下文管理） 插件调用（多工具协同）对于政务产品经理来说，它们的最大价值是可以非常快地跑出一个“Agent Demo”。 比如：智能问政策：AI自动从政策库生成通俗解释；多轮导办：用户提多个问题，AI保持语境连贯；材料解析：上传图片后自动识别问题；政策翻译：将条文转化为用户能理解的语言。我们在初期探索“边聊边办”的过程中，也用豆包搭过原型。1周内就能跑通一个对话体验demo，帮业务部门看到可能性。 对于早期验证和快速出样，MaaS是当前最省力的解法。但问题在于——你一旦想往深了做，MaaS就开始“卡你”。02 MaaS的“天花板”在哪里？MaaS平台的核心是模型服务，但它并不懂你的业务流程。你可能会遇到： 无法接入本地业务系统想让Agent读取办件记录、调用内部接口，做不到，平台无法访问。 话术难以控制政务表达必须规范、准确，但MaaS生成的内容有时风格随机，风险难控。 无法闭环落地Agent可能能答，但不能办；没有流程执行能力，也缺乏调度机制。更严重的是，一旦政策变更或业务升级，平台不一定能配合你同步迭代。结果就是，AI成了前台花瓶，而不是政务系统的一部分。03 自研价值：能力长期沉淀，融合业务流程为了解决这些问题，我规划搭建一套自研智能体运行框架，主要包括： 意图识别 + 动作映射自建意图识别模型 + 规则引擎，精准匹配事项每个意图绑定一个动作，落地为接口调用或对话流程启动 流程执行中台用流程图方式管理事项逻辑，按条件节点触发对话或动作真正实现“导办 → 办理 → 回执”的闭环 可控知识系统知识入库有版本、有校验、可定时失效可复用给不同Agent，支持不同渠道输出策略 插件化大模型服务平台模型不再是主系统，而是“调用插件”所有调用由本地系统调度，能换能切，避免绑定这套框架的核心，是让AI Agent变成“你业务系统的一部分”，不是一个外置小程序。04 实战建议：从MaaS走向自研的三步路径我总结了一条适合政务项目团队落地的实践路径： 阶段一：MaaS验证期（1~2个月）用MaaS搭建智能问答、政策解释原型重点是打通场景，拉住业务需求方形成共识 阶段二：轻量自研过渡（2~4个月）封装少量事项，构建对话式流程本地引入流程引擎，逐步剥离MaaS依赖开始掌握“流程+对话”的节奏控制权 阶段三：Agent体系建设（4个月+）建立可管可控的知识体系接入后台系统，完成业务融合MaaS服务只作推理插件，轻装调用最后的话AI Agent落地，不是问“选哪家平台”这么简单。而是要选一条从验证走向能力沉淀的演进路线。如果只是做个演示，MaaS最快；如果想打造“能干活”的智能体，那必须掌握流程和业务的主导权。不是不要平台，而是不能依赖平台。Agent的能力，最终应该是你的，而不是“接来的”。希望带给你一些启发，加油！本文由人人都是产品经理作者【柳星聊产品】，微信公众号：【柳星聊产品】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。题图来自Unsplash，基于 CC0 协议。