百度智能云近日完成的一轮产研组织调整中MaaS 被划入基础设施Agent 独立成军。表面看这是组织架构变化实际上反映的是云厂商对大模型落地方式的重要判断模型能力不再是一个独立售卖的功能而是像存储、网络、计算一样成为底层基础设施智能体则从众多应用场景中独立出来被当作一个完整的技术赛道专门投入。对于正在做 AI 应用开发的团队来说这个信号值得认真理解因为它直接影响后面要接入的平台、要选型的技术栈以及要建立的应用架构。这篇文章会从这次组织调整入手先拆解调整背后反映的技术逻辑再讲清楚 MaaS 和 Agent 的区别与联系然后给出一个基于百度智能云千帆平台的 MaaS Agent 最小可运行案例最后补充鉴权、上下文、工具调用、Agent 循环等高频问题的排查思路以及学习环境与生产环境的落地建议。1. 这次组织调整到底调整了什么从一条新闻看云厂商的战略重心1.1 三个关键动作拆解根据公开信息这次调整可以拆成三个关键动作第一平台产品事业部被分拆。原来的平台产品事业部横跨了模型、应用、开发者工具等多层能力分拆之后不同能力开始按照基础设施和上层应用两种属性重新归属。第二MaaS 划入基础设施。Model as a Service模型即服务不再被当作一个独立的产品事业部来运作而是下沉到基础设施层。也就是说模型 API 在未来会像对象存储、云服务器一样成为云端的基础资源。第三Agent 独立成军。智能体相关团队从原来的平台产品体系里分离出来形成独立组织。这个动作意味着 Agent 不只是一个功能模块而是被当作一个可以长期演进、需要专门投入的产品方向。这三个动作合在一起基本可以读出一句话云厂商正在把 AI 应用架构重新画成两层。下面一层是模型基础设施解决“模型够不够用、好不好调、贵不贵”上面一层是智能体平台与应用解决“模型怎么被业务真正用起来”。1.2 组织调整背后的技术判断组织架构往往滞后于技术变化但一旦调整说明技术变化已经大到必须用组织去固化。这次调整的背后至少有三个技术判断。第一个判断是大模型正在从“炫技 demo”变成“资源”。三年前调用一个模型还是新鲜事今天模型 API 的调用方式、计量方式、限流方式都越来越接近云原生基础设施。把 MaaS 划入基础设施是承认模型是 AI 应用的公共依赖。第二个判断是Agent 需要一个专门的生命周期管理。普通 API 调用是“请求进来结果返回”就结束了但 Agent 不同它要规划、要调用工具、要维护记忆、要在多轮交互中修正自己。这种应用形态无论是开发方式、测试方式还是监控方式都和传统应用不一样所以需要独立组织来支撑。第三个判断是平台竞争已经进入“Agent 生态”阶段。只提供模型 API 的平台很难解决开发者的真实问题能够帮开发者低成本构建、部署、运营 Agent 的平台才更容易形成粘性。独立成军本质上是把 Agent 平台当作战略级入口。注意组织调整的具体汇报关系、团队规模和产品线划分应以百度智能云官方后续公告为准。技术团队真正值得关注的是 MaaS 与 Agent 分层后带来的接口、产品形态和架构变化。2. 为什么 MaaS 会被划入基础设施模型即服务的平台化逻辑2.1 MaaS 到底做什么MaaS全称 Model as a Service直译是“模型即服务”。它的核心是把大模型的训练、精调、部署、推理、接入能力封装成标准化的服务让上层应用通过 API 就能调用而不需要自己准备显卡、搭建推理服务、处理模型版本。MaaS 平台通常包含几个层次模型接入层提供国内外主流开源和闭源模型的统一接入。推理服务层负责模型部署、弹性扩容、并发调度和响应延迟控制。精调与评估层支持用业务数据对模型进行有监督微调并提供评估集验证效果。工具链层包括 Prompt 模板、知识库、向量数据库、插件编排等辅助能力。运营网关层负责 API Key、配额、限流、计费、日志与审计。在百度智能云的语境下典型入口是千帆大模型平台。开发者通过千帆控制台创建应用后拿到 API Key 与 Secret Key就可以用 HTTP 请求或 SDK 调用文心系列模型以及其他第三方模型。整个过程把“大模型”封装成了一个云上资源。2.2 基础设施化的含义把 MaaS 划入基础设施不是简单的部门归属变化而是产品形态和价值定位的变化。过去MaaS 经常被当作一个“新产品”强调模型有多强、效果有多好。但作为基础设施它更强调稳定、成本、可观测和确定性。当一个能力被当作基础设施时用户对它的预期会改变。调用模型 API 就像使用云硬盘一样开发者不会关心背后是哪台机器只关心三个问题能不能调用调用是否稳定成本是否可控。具体来说MaaS 基础设施化会带来几个直接影响模型 API 的 SLA服务可用性需要达到基础服务标准不能经常超时或频繁限流。计量计费会更加精细按 Token、按请求数、按并发通道分别报价方便上层应用核算成本。模型版本会纳入生命周期管理平台需要提供模型灰度、回滚、切换能力避免模型更新破坏线上应用。权限体系会和企业云账号打通子账号、角色、配额等在同一个云账号体系内统一管理。2.3 对开发者意味着什么对应用开发者而言MaaS 基础设施化降低了模型接入的认知成本。以前选大模型需要先比较各家平台反复申请试用再适配不同接口现在如果平台已经将 MaaS 作为基础设施提供开发者只需要关注应用逻辑本身。同时也要注意基础设施化的另一面是“资源化”。当模型调用变成账号下的资源消耗开发团队就必须像管理服务器费用一样管理模型调用费用。没有成本控制意识的团队上线一个 Agent 后可能因为循环调用、重复调用产生很大的账单。因此接入 MaaS 后第一件事是在代码层加上成本可观测能力统计每次请求的 Token 消耗、模型名称、调用来源、耗时并设置月度预算和告警。这不是可选项而是生产环境的必要条件。3. Agent 独立成军智能体正在成为云平台的一等公民3.1 Agent 与 MaaS 的区别MaaS 和 Agent 经常被放在一起讨论但它们并不在同一层。MaaS 解决的是“模型如何被调用”Agent 解决的是“模型如何被用在真实任务中”。一个 Agent 通常会依赖底层的模型 API但 Agent 的代码本身包含规划、工具调用、记忆管理和结果校验。可以这样看MaaS 是发动机Agent 是整车。发动机解决动力问题但整车还要解决转向、制动、导航、乘坐体验等问题。没有发动机整车跑不起来只有发动机车也无法完成完整出行任务。对比维度MaaSAgent核心定位模型能力的服务化模型能力的应用化交付形态API、SDK、模型部署可交互的智能应用关键问题模型调用、成本、延迟、效果规划、工具、记忆、安全、稳定性生命周期模型版本管理、推理服务扩容会话状态、任务执行、失败恢复开发复杂度相对低接入标准接口即可相对高需要处理多步交互典型的百度云产品入口千帆大模型平台的模型服务Agent 开发平台、AppBuilder 等也就是说MaaS 独立成基础设施Agent 独立成军两者是上下游关系而不是替代关系。Agent 需要依赖 MaaS但 Agent 的复杂度远超单纯调用模型。3.2 智能体开发与普通应用开发的差异传统应用开发的核心是确定性逻辑输入固定参数执行固定代码返回固定结果。Agent 开发则不同它需要处理模型输出的不确定性并把不确定性约束到业务可接受的范围内。差异主要体现在几个方面控制流变了。传统应用由 if/else 和函数调用控制Agent 的控制流可能由模型决策决定代码只负责执行模型选中的工具。结果验证必不可少。模型生成的答案可能是错的Agent 必须增加校验环节比如工具调用前后检查参数格式、数值范围、权限范围。状态管理更复杂。多轮对话中Agent 需要维护用户目标、已执行动作、中间结果和未完成事项。失败处理要设计兜底。模型格式错误、工具超时、上下文超限都可能导致 Agent 中断需要重试、降级或人工介入机制。这也是 Agent 值得独立组织投入的原因。它的开发链路太长如果只是平台里的一个功能模块很难沉淀出专门的开发框架、测试评估体系和运维方案。3.3 独立组织带来的演进方向组织上独立成军通常意味着后续会在几个方向加大投入。第一个方向是 Agent 开发框架。平台会提供更加完整的项目模板帮助开发者快速搭建包含记忆、工具调用、人机协同的 Agent 骨架。第二个方向是 Agent 评估体系。传统应用上线前做功能测试Agent 上线前要做效果评估任务完成率、工具调用准确率、多轮对话一致性、安全合规表现。这个体系需要专门建设。第三个方向是 Agent 可观测性。模型调用只是 Agent 执行链路的一环平台需要把规划步骤、工具调用参数、中间结果、最终输出全部记录下来才能支撑线上问题排查。对开发者来说独立成军意味着 Agent 生态会更加完善。当前阶段可以多关注平台是否提供以下能力可视化的 Agent 编排界面。插件/工具注册与调用标准。知识库和记忆能力。测试集与批量评估工具。线上日志、监控和告警体系。如果这些能力开始以标准产品形式出现说明 Agent 已经从“能跑”走向“能稳定上线”。4. 从平台需求反推 Agent 开发技术栈组织调整映射到工程实践4.1 一个典型 Agent 应用的最小结构不管平台如何调整一个可用的 Agent 应用都包含几个核心模块。理解这些模块是看懂组织调整后技术选型的基础。模块职责常见实现模型层负责理解用户意图并生成决策MaaS 平台提供的模型 API规划层将用户目标拆解为步骤使用模型 Prompt 或明确的流程图工具层执行具体动作如查数据库、调接口Function Calling、插件、API 封装记忆层保存用户偏好、历史消息、中间结果上下文窗口、数据库、向量存储执行层调度各模块并处理异常Python/Java 等业务代码校验层检查模型输出和工具执行结果规则校验、代码校验、人工审核最小 Agent 可以简化成三个步骤接收用户请求模型决定调用哪个工具执行工具并返回结果。下面的章节会用一个实际案例演示这个流程。4.2 工具调用与工作流编排工具调用是 Agent 与普通聊天机器人的分水岭。普通聊天机器人只生成文本Agent 则可以通过调用工具影响外部系统。常见实现方式是 Function Calling。开发者把工具描述成 JSON Schema模型根据用户输入判断“应该调用哪个工具、传什么参数”然后由代码执行真正的工具函数。{ type: function, function: { name: get_weather, description: 获取指定城市的天气信息, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } }这里要特别注意模型只是“决定调用”并不“实际调用”。真正执行工具的是你的代码。这个设计很重要它把安全边界留给了开发者不是模型想执行什么就执行什么而是代码先检查参数、确认权限然后再执行。4.3 记忆、上下文管理与状态Agent 在多轮交互中需要记忆。记忆可以分为短期记忆和长期记忆。短期记忆通常直接使用模型的上下文窗口把最近几轮对话拼进 messages 数组。这种方式简单但会受 Token 上限限制。会话变长后要么截断旧消息要么做摘要压缩。长期记忆则需要把用户身份、偏好、历史结论落到外部存储中。常用方案是向量数据库把语义信息转成向量检索时根据相似度取回相关内容再塞进模型上下文。这样做的目的是控制成本不让所有历史记录都进入每次请求。状态管理是 Agent 工程化常见难点。在一个多步骤任务中Agent 执行到一半可能中断。生产环境中要把“任务状态”持久化到数据库例如{ task_id: task_001, user_id: user_007, goal: 查询上周销售数据并生成摘要, steps: [ { step: query_sales_data, status: completed, result: 汇总记录 128 条 }, { step: generate_summary, status: pending } ] }有了状态记录Agent 才能做到失败恢复、断点续跑和人工介入。4.4 Agent 安全边界Agent 比普通 API 应用更容易出现安全风险原因是它把决策权交给了模型而模型并不天然理解权限边界。开发 Agent 时必须建立以下安全机制工具白名单。只暴露业务允许的工具未注册的工具一律不可调用。参数校验。模型生成的参数必须经过代码校验包括类型、长度、取值范围。权限最小化。Agent 使用的云账号或应用身份只授予完成任务所需的最小权限。敏感操作复核。删除、转账、发布等高风险操作应强制用户确认。内容审核。输入输出两端都要过滤有害内容。安全不是组织架构调整后才有的话题但 Agent 独立成军后平台对安全能力的要求只会更高。5. 在百度智能云上跑通一个 MaaS Agent 的最小案例5.1 前置准备这个案例的目标很简单通过百度智能云千帆平台调用一个大模型并让 Agent 能够调用一个自定义工具完成“查询某个城市的天气”这类任务。学习环境准备如下项目要求Python3.8 或更高版本SDK安装千帆 Python SDK账号一个百度智能云账号并开通千帆大模型平台服务密钥在控制台创建应用获取 API Key 与 Secret Key网络能正常访问百度智能云公共 API安装 SDK 的命令pip install qianfan如果项目已经使用虚拟环境先创建并激活虚拟环境再执行安装。安装后可以通过版本号确认 SDK 是否正常python -c import qianfan; print(qianfan.__version__)不同版本 SDK 的类名和方法可能存在差异运行前先查阅当前 SDK 的官方文档。5.2 获取 API Key 与 Secret Key 的正确路径在调用 MaaS API 之前必须先搞定鉴权。常见路径是登录百度智能云控制台进入千帆大模型平台在“应用接入”或“安全认证”页面创建应用创建后页面会显示 API Key 和 Secret Key。实际控制台界面可能随版本调整但思路一致。获取密钥后不要直接写在代码里。推荐放到环境变量中export QIANFAN_ACCESS_KEYyour_access_key export QIANFAN_SECRET_KEYyour_secret_keyWindows 环境下可以使用set QIANFAN_ACCESS_KEYyour_access_key set QIANFAN_SECRET_KEYyour_secret_key这样写的好处是代码仓库不保存密钥协作时不容易泄露换环境切换凭据也方便。注意密钥泄露后应立即在控制台重置。不要为了省事把密钥提交到 Git 仓库也不要写在日志里。5.3 使用千帆 SDK 调用大模型准备一个 Python 文件chat_demo.py内容如下import os from qianfan import ChatCompletion os.environ[QIANFAN_ACCESS_KEY] your_access_key os.environ[QIANFAN_SECRET_KEY] your_secret_key client ChatCompletion() resp client.do( modelERNIE-4.0-8K, messages[ {role: user, content: 用一句话解释 MaaS 和 Agent 的关系} ] ) print(resp[result])这段代码的作用非常直接创建一个 ChatCompletion 客户端向指定模型发送一轮对话然后打印模型返回的文本。运行命令python chat_demo.py正常情况下控制台会输出一段文字说明 MaaS 是模型服务Agent 是使用模型的应用。如果出现鉴权失败说明环境变量没有配置正确或者账号没有开通对应模型的服务权限。如果 SDK 版本较新可能提供QfClient之类的新客户端类。建议优先阅读安装版本对应的官方示例把客户端初始化方式调整一致。5.4 让 Agent 具备工具调用能力现在把简单的“单轮对话”扩展成“模型决定调用工具”的 Agent 链路。先定义一个天气查询工具。这里用本地函数模拟外部接口def get_weather(city: str) - str: # 实际项目中这里可以调用天气服务 API weather_map { 北京: 晴25 摄氏度, 上海: 多云28 摄氏度, 广州: 雷阵雨30 摄氏度, } return weather_map.get(city, 暂未收录该城市天气)再声明工具 Schema让模型知道存在这个工具以及参数格式tools [ { type: function, function: { name: get_weather, description: 获取指定城市的天气信息, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } } ]接下来实现主循环先让模型判断是否需要调用工具如果需要代码执行工具并把结果回传给模型模型再生成最终回答。from qianfan import ChatCompletion client ChatCompletion() def run_agent(user_input): messages [{role: user, content: user_input}] first_resp client.do( modelERNIE-4.0-8K, messagesmessages, toolstools ) # 如果模型返回了工具调用请求 if first_resp.get(tool_calls): tool_call first_resp[tool_calls][0] function_name tool_call[function][name] arguments tool_call[function][arguments] if function_name get_weather: city arguments.get(city) result get_weather(city) # 将工具调用请求和工具结果都追加进上下文 messages.append({ role: assistant, content: None, tool_calls: [tool_call] }) messages.append({ role: tool, tool_call_id: tool_call.get(id), content: result }) second_resp client.do( modelERNIE-4.0-8K, messagesmessages, toolstools ) return second_resp[result] return first_resp[result] print(run_agent(北京天气怎么样))这段代码的关键逻辑是模型不直接返回天气结果而是先返回调用工具的参数业务代码拿到参数后执行工具把真实结果追加到对话上下文模型看到工具结果后组织成更自然的回答返回给用户。5.5 验证和预期输出执行后预期输出类似北京今天天气晴朗气温 25 摄氏度适合出门活动。如果模型输出了原始 JSON 而没有组织成自然语言说明返回的tool_calls解析逻辑没有覆盖到。此时需要查看 SDK 返回结构确认tool_calls的字段名是否正确。这个最小案例已经具备 Agent 的雏形模型负责理解用户意图和选择工具代码负责实际执行结果再回流给模型生成最终回复。后续要做的扩展包括多轮记忆、多个工具选择、失败重试和权限控制。6. MaaS 和 Agent 的常见工程问题与排查清单6.1 鉴权失败现象调用模型 API 时返回 401、403 或提示 invalid authentication。可能原因API Key 或 Secret Key 配错。密钥被重置代码仍在使用旧值。在子账号下没有授权千帆服务。环境变量优先级低于代码中的写入值。检查方式打印客户端读取到的密钥前缀确认环境变量确实注入到控制台检查应用是否还存在尝试用官方示例配置跑通。处理建议统一把密钥放到环境变量或密钥管理服务中不要散落在多个配置文件里。出错时先确认当前生效的配置来源。6.2 上下文超限现象请求返回类似 context length exceeded 的错误。可能原因传入的 messages 太长超过模型上下文窗口上限多轮对话后没有清理历史工具调用结果过大。检查方式计算 messages 的总 Token 数查看工具返回的 JSON 是否包含大量无关键信息确认会话轮数。处理建议对历史消息做摘要压缩只保留最近 N 轮限制工具返回内容长度必要时使用外部记忆库存储长期信息。6.3 Agent 循环或停在错误分支现象Agent 反复调用同一个工具或迟迟不给出最终回答。可能原因模型没有得到足够明确的“完成后停止”指令工具结果没有进入模型上下文模型生成格式不符合预期重试策略无上限。检查方式打印每次请求的 messages 和模型返回记录工具调用次数观察finish_reason字段。处理建议在 Prompt 中明确限定最大步骤数代码层增加最大循环次数工具执行失败时返回结构化错误信息当模型连续多次调用相同工具时强制中断并转人工。6.4 排查顺序遇到问题不要直接看最终报错建议按以下顺序排查密钥是否有效、是否对当前环境生效。请求参数是否完整模型名称是否支持。messages 结构是否正确是否存在重复或字段缺失。是否是网络或服务限流。是否是上下文超限。是否是工具 Schema 格式错误。是否模型本身不支持 Function Calling 或当前参数。问题现象常见原因检查方式处理建议401 鉴权失败密钥错误或未配置打印环境变量并核对控制台重置密钥统一从环境变量读取提示模型不存在模型名称与账号权限不匹配查看千帆可用模型列表换成账号已开通的模型名称返回内容为空messages 结构错误或引擎过滤打印完整请求与响应检查 role、content 字段工具调用不生效模型不支持 Function Calling查看模型文档换支持工具调用的模型请求超时网络问题或模型负载高观察响应耗时和重试日志增加超时与重试排查出口网络7. 开发者和架构师应该如何看待这次调整最佳实践与落地建议7.1 应用层开发者的调整如果正在做 Agent 开发可以借着这次调整重新审视自己的技术选型。不要把模型调用、工具调用、会话状态全部耦合在一个函数里。建议分层模型接入层统一封装 MaaS 调用屏蔽不同模型接口差异。工具层使用标准 Schema 注册让模型可以理解工具能力。会话层管理短期记忆和长期记忆。应用层负责业务流程、权限控制和用户体验。这样的结构在平台能力变化时可以平滑迁移。今天用的 MaaS 平台接口明天换成另一个平台只需修改接入层业务代码不需要全量重写。7.2 平台架构视角从架构师视角看组织调整意味着平台会更快补齐 Agent 基建。选型时除了看模型效果还要关注平台提供的工程化能力是否支持工具注册与调用审计。是否提供知识库和记忆存储。是否提供 Agent 测试与评估工具。是否有完整的调用链路日志。是否支持多模型路由和灰度切换。这些都是生产环境真正需要的而不仅仅是 demo 阶段的模型效果。7.3 组织调整对技术选型的启发MaaS 划入基础设施之后模型能力会越来越像“水电”。团队选型时可以按基础设施的标准评估稳定性、成本可见性、运维成熟度、生态兼容性。Agent 独立成军之后Agent 开发框架会进入快速演进周期。不要急着自研全套 Agent 框架优先使用平台提供的标准能力同时保留业务层的扩展点。等到评估体系、可观测体系完善后再决定哪些模块需要自建。7.4 后续可以关注的信号判断这次调整是否真正落地可以关注几个信号千帆平台是否推出更完善的 Agent 项目模板和调试工具。平台是否提供细粒度的 Token 成本报表。Agent 的可观测能力是否从“只有模型调用日志”升级到“完整任务链路追踪”。是否出现面向 Agent 的独立计费、配额和安全策略。任何一个信号落地都会直接影响开发者的日常工作方式。这次调整的最大启示不是组织架构本身而是技术分层越来越清晰模型作为基础设施Agent 作为上层应用形态。开发者越早适应这种分层思维越能在接下来的 AI 应用浪潮中减少返工。学习阶段可以用简单的 SDK 调用把 Chat 跑通但真正进入生产环境前至少要把密钥管理、上下文控制、工具权限、循环上限、成本统计这五件事补上Agent 才算具备上线条件。从最小案例开始逐步扩展记忆、工具集和安全校验是一条值得长期走的技术路线。 MaaS与Agent分层：从百度智能云组织调整看AI应用架构演进
百度智能云近日完成的一轮产研组织调整中MaaS 被划入基础设施Agent 独立成军。表面看这是组织架构变化实际上反映的是云厂商对大模型落地方式的重要判断模型能力不再是一个独立售卖的功能而是像存储、网络、计算一样成为底层基础设施智能体则从众多应用场景中独立出来被当作一个完整的技术赛道专门投入。对于正在做 AI 应用开发的团队来说这个信号值得认真理解因为它直接影响后面要接入的平台、要选型的技术栈以及要建立的应用架构。这篇文章会从这次组织调整入手先拆解调整背后反映的技术逻辑再讲清楚 MaaS 和 Agent 的区别与联系然后给出一个基于百度智能云千帆平台的 MaaS Agent 最小可运行案例最后补充鉴权、上下文、工具调用、Agent 循环等高频问题的排查思路以及学习环境与生产环境的落地建议。1. 这次组织调整到底调整了什么从一条新闻看云厂商的战略重心1.1 三个关键动作拆解根据公开信息这次调整可以拆成三个关键动作第一平台产品事业部被分拆。原来的平台产品事业部横跨了模型、应用、开发者工具等多层能力分拆之后不同能力开始按照基础设施和上层应用两种属性重新归属。第二MaaS 划入基础设施。Model as a Service模型即服务不再被当作一个独立的产品事业部来运作而是下沉到基础设施层。也就是说模型 API 在未来会像对象存储、云服务器一样成为云端的基础资源。第三Agent 独立成军。智能体相关团队从原来的平台产品体系里分离出来形成独立组织。这个动作意味着 Agent 不只是一个功能模块而是被当作一个可以长期演进、需要专门投入的产品方向。这三个动作合在一起基本可以读出一句话云厂商正在把 AI 应用架构重新画成两层。下面一层是模型基础设施解决“模型够不够用、好不好调、贵不贵”上面一层是智能体平台与应用解决“模型怎么被业务真正用起来”。1.2 组织调整背后的技术判断组织架构往往滞后于技术变化但一旦调整说明技术变化已经大到必须用组织去固化。这次调整的背后至少有三个技术判断。第一个判断是大模型正在从“炫技 demo”变成“资源”。三年前调用一个模型还是新鲜事今天模型 API 的调用方式、计量方式、限流方式都越来越接近云原生基础设施。把 MaaS 划入基础设施是承认模型是 AI 应用的公共依赖。第二个判断是Agent 需要一个专门的生命周期管理。普通 API 调用是“请求进来结果返回”就结束了但 Agent 不同它要规划、要调用工具、要维护记忆、要在多轮交互中修正自己。这种应用形态无论是开发方式、测试方式还是监控方式都和传统应用不一样所以需要独立组织来支撑。第三个判断是平台竞争已经进入“Agent 生态”阶段。只提供模型 API 的平台很难解决开发者的真实问题能够帮开发者低成本构建、部署、运营 Agent 的平台才更容易形成粘性。独立成军本质上是把 Agent 平台当作战略级入口。注意组织调整的具体汇报关系、团队规模和产品线划分应以百度智能云官方后续公告为准。技术团队真正值得关注的是 MaaS 与 Agent 分层后带来的接口、产品形态和架构变化。2. 为什么 MaaS 会被划入基础设施模型即服务的平台化逻辑2.1 MaaS 到底做什么MaaS全称 Model as a Service直译是“模型即服务”。它的核心是把大模型的训练、精调、部署、推理、接入能力封装成标准化的服务让上层应用通过 API 就能调用而不需要自己准备显卡、搭建推理服务、处理模型版本。MaaS 平台通常包含几个层次模型接入层提供国内外主流开源和闭源模型的统一接入。推理服务层负责模型部署、弹性扩容、并发调度和响应延迟控制。精调与评估层支持用业务数据对模型进行有监督微调并提供评估集验证效果。工具链层包括 Prompt 模板、知识库、向量数据库、插件编排等辅助能力。运营网关层负责 API Key、配额、限流、计费、日志与审计。在百度智能云的语境下典型入口是千帆大模型平台。开发者通过千帆控制台创建应用后拿到 API Key 与 Secret Key就可以用 HTTP 请求或 SDK 调用文心系列模型以及其他第三方模型。整个过程把“大模型”封装成了一个云上资源。2.2 基础设施化的含义把 MaaS 划入基础设施不是简单的部门归属变化而是产品形态和价值定位的变化。过去MaaS 经常被当作一个“新产品”强调模型有多强、效果有多好。但作为基础设施它更强调稳定、成本、可观测和确定性。当一个能力被当作基础设施时用户对它的预期会改变。调用模型 API 就像使用云硬盘一样开发者不会关心背后是哪台机器只关心三个问题能不能调用调用是否稳定成本是否可控。具体来说MaaS 基础设施化会带来几个直接影响模型 API 的 SLA服务可用性需要达到基础服务标准不能经常超时或频繁限流。计量计费会更加精细按 Token、按请求数、按并发通道分别报价方便上层应用核算成本。模型版本会纳入生命周期管理平台需要提供模型灰度、回滚、切换能力避免模型更新破坏线上应用。权限体系会和企业云账号打通子账号、角色、配额等在同一个云账号体系内统一管理。2.3 对开发者意味着什么对应用开发者而言MaaS 基础设施化降低了模型接入的认知成本。以前选大模型需要先比较各家平台反复申请试用再适配不同接口现在如果平台已经将 MaaS 作为基础设施提供开发者只需要关注应用逻辑本身。同时也要注意基础设施化的另一面是“资源化”。当模型调用变成账号下的资源消耗开发团队就必须像管理服务器费用一样管理模型调用费用。没有成本控制意识的团队上线一个 Agent 后可能因为循环调用、重复调用产生很大的账单。因此接入 MaaS 后第一件事是在代码层加上成本可观测能力统计每次请求的 Token 消耗、模型名称、调用来源、耗时并设置月度预算和告警。这不是可选项而是生产环境的必要条件。3. Agent 独立成军智能体正在成为云平台的一等公民3.1 Agent 与 MaaS 的区别MaaS 和 Agent 经常被放在一起讨论但它们并不在同一层。MaaS 解决的是“模型如何被调用”Agent 解决的是“模型如何被用在真实任务中”。一个 Agent 通常会依赖底层的模型 API但 Agent 的代码本身包含规划、工具调用、记忆管理和结果校验。可以这样看MaaS 是发动机Agent 是整车。发动机解决动力问题但整车还要解决转向、制动、导航、乘坐体验等问题。没有发动机整车跑不起来只有发动机车也无法完成完整出行任务。对比维度MaaSAgent核心定位模型能力的服务化模型能力的应用化交付形态API、SDK、模型部署可交互的智能应用关键问题模型调用、成本、延迟、效果规划、工具、记忆、安全、稳定性生命周期模型版本管理、推理服务扩容会话状态、任务执行、失败恢复开发复杂度相对低接入标准接口即可相对高需要处理多步交互典型的百度云产品入口千帆大模型平台的模型服务Agent 开发平台、AppBuilder 等也就是说MaaS 独立成基础设施Agent 独立成军两者是上下游关系而不是替代关系。Agent 需要依赖 MaaS但 Agent 的复杂度远超单纯调用模型。3.2 智能体开发与普通应用开发的差异传统应用开发的核心是确定性逻辑输入固定参数执行固定代码返回固定结果。Agent 开发则不同它需要处理模型输出的不确定性并把不确定性约束到业务可接受的范围内。差异主要体现在几个方面控制流变了。传统应用由 if/else 和函数调用控制Agent 的控制流可能由模型决策决定代码只负责执行模型选中的工具。结果验证必不可少。模型生成的答案可能是错的Agent 必须增加校验环节比如工具调用前后检查参数格式、数值范围、权限范围。状态管理更复杂。多轮对话中Agent 需要维护用户目标、已执行动作、中间结果和未完成事项。失败处理要设计兜底。模型格式错误、工具超时、上下文超限都可能导致 Agent 中断需要重试、降级或人工介入机制。这也是 Agent 值得独立组织投入的原因。它的开发链路太长如果只是平台里的一个功能模块很难沉淀出专门的开发框架、测试评估体系和运维方案。3.3 独立组织带来的演进方向组织上独立成军通常意味着后续会在几个方向加大投入。第一个方向是 Agent 开发框架。平台会提供更加完整的项目模板帮助开发者快速搭建包含记忆、工具调用、人机协同的 Agent 骨架。第二个方向是 Agent 评估体系。传统应用上线前做功能测试Agent 上线前要做效果评估任务完成率、工具调用准确率、多轮对话一致性、安全合规表现。这个体系需要专门建设。第三个方向是 Agent 可观测性。模型调用只是 Agent 执行链路的一环平台需要把规划步骤、工具调用参数、中间结果、最终输出全部记录下来才能支撑线上问题排查。对开发者来说独立成军意味着 Agent 生态会更加完善。当前阶段可以多关注平台是否提供以下能力可视化的 Agent 编排界面。插件/工具注册与调用标准。知识库和记忆能力。测试集与批量评估工具。线上日志、监控和告警体系。如果这些能力开始以标准产品形式出现说明 Agent 已经从“能跑”走向“能稳定上线”。4. 从平台需求反推 Agent 开发技术栈组织调整映射到工程实践4.1 一个典型 Agent 应用的最小结构不管平台如何调整一个可用的 Agent 应用都包含几个核心模块。理解这些模块是看懂组织调整后技术选型的基础。模块职责常见实现模型层负责理解用户意图并生成决策MaaS 平台提供的模型 API规划层将用户目标拆解为步骤使用模型 Prompt 或明确的流程图工具层执行具体动作如查数据库、调接口Function Calling、插件、API 封装记忆层保存用户偏好、历史消息、中间结果上下文窗口、数据库、向量存储执行层调度各模块并处理异常Python/Java 等业务代码校验层检查模型输出和工具执行结果规则校验、代码校验、人工审核最小 Agent 可以简化成三个步骤接收用户请求模型决定调用哪个工具执行工具并返回结果。下面的章节会用一个实际案例演示这个流程。4.2 工具调用与工作流编排工具调用是 Agent 与普通聊天机器人的分水岭。普通聊天机器人只生成文本Agent 则可以通过调用工具影响外部系统。常见实现方式是 Function Calling。开发者把工具描述成 JSON Schema模型根据用户输入判断“应该调用哪个工具、传什么参数”然后由代码执行真正的工具函数。{ type: function, function: { name: get_weather, description: 获取指定城市的天气信息, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } }这里要特别注意模型只是“决定调用”并不“实际调用”。真正执行工具的是你的代码。这个设计很重要它把安全边界留给了开发者不是模型想执行什么就执行什么而是代码先检查参数、确认权限然后再执行。4.3 记忆、上下文管理与状态Agent 在多轮交互中需要记忆。记忆可以分为短期记忆和长期记忆。短期记忆通常直接使用模型的上下文窗口把最近几轮对话拼进 messages 数组。这种方式简单但会受 Token 上限限制。会话变长后要么截断旧消息要么做摘要压缩。长期记忆则需要把用户身份、偏好、历史结论落到外部存储中。常用方案是向量数据库把语义信息转成向量检索时根据相似度取回相关内容再塞进模型上下文。这样做的目的是控制成本不让所有历史记录都进入每次请求。状态管理是 Agent 工程化常见难点。在一个多步骤任务中Agent 执行到一半可能中断。生产环境中要把“任务状态”持久化到数据库例如{ task_id: task_001, user_id: user_007, goal: 查询上周销售数据并生成摘要, steps: [ { step: query_sales_data, status: completed, result: 汇总记录 128 条 }, { step: generate_summary, status: pending } ] }有了状态记录Agent 才能做到失败恢复、断点续跑和人工介入。4.4 Agent 安全边界Agent 比普通 API 应用更容易出现安全风险原因是它把决策权交给了模型而模型并不天然理解权限边界。开发 Agent 时必须建立以下安全机制工具白名单。只暴露业务允许的工具未注册的工具一律不可调用。参数校验。模型生成的参数必须经过代码校验包括类型、长度、取值范围。权限最小化。Agent 使用的云账号或应用身份只授予完成任务所需的最小权限。敏感操作复核。删除、转账、发布等高风险操作应强制用户确认。内容审核。输入输出两端都要过滤有害内容。安全不是组织架构调整后才有的话题但 Agent 独立成军后平台对安全能力的要求只会更高。5. 在百度智能云上跑通一个 MaaS Agent 的最小案例5.1 前置准备这个案例的目标很简单通过百度智能云千帆平台调用一个大模型并让 Agent 能够调用一个自定义工具完成“查询某个城市的天气”这类任务。学习环境准备如下项目要求Python3.8 或更高版本SDK安装千帆 Python SDK账号一个百度智能云账号并开通千帆大模型平台服务密钥在控制台创建应用获取 API Key 与 Secret Key网络能正常访问百度智能云公共 API安装 SDK 的命令pip install qianfan如果项目已经使用虚拟环境先创建并激活虚拟环境再执行安装。安装后可以通过版本号确认 SDK 是否正常python -c import qianfan; print(qianfan.__version__)不同版本 SDK 的类名和方法可能存在差异运行前先查阅当前 SDK 的官方文档。5.2 获取 API Key 与 Secret Key 的正确路径在调用 MaaS API 之前必须先搞定鉴权。常见路径是登录百度智能云控制台进入千帆大模型平台在“应用接入”或“安全认证”页面创建应用创建后页面会显示 API Key 和 Secret Key。实际控制台界面可能随版本调整但思路一致。获取密钥后不要直接写在代码里。推荐放到环境变量中export QIANFAN_ACCESS_KEYyour_access_key export QIANFAN_SECRET_KEYyour_secret_keyWindows 环境下可以使用set QIANFAN_ACCESS_KEYyour_access_key set QIANFAN_SECRET_KEYyour_secret_key这样写的好处是代码仓库不保存密钥协作时不容易泄露换环境切换凭据也方便。注意密钥泄露后应立即在控制台重置。不要为了省事把密钥提交到 Git 仓库也不要写在日志里。5.3 使用千帆 SDK 调用大模型准备一个 Python 文件chat_demo.py内容如下import os from qianfan import ChatCompletion os.environ[QIANFAN_ACCESS_KEY] your_access_key os.environ[QIANFAN_SECRET_KEY] your_secret_key client ChatCompletion() resp client.do( modelERNIE-4.0-8K, messages[ {role: user, content: 用一句话解释 MaaS 和 Agent 的关系} ] ) print(resp[result])这段代码的作用非常直接创建一个 ChatCompletion 客户端向指定模型发送一轮对话然后打印模型返回的文本。运行命令python chat_demo.py正常情况下控制台会输出一段文字说明 MaaS 是模型服务Agent 是使用模型的应用。如果出现鉴权失败说明环境变量没有配置正确或者账号没有开通对应模型的服务权限。如果 SDK 版本较新可能提供QfClient之类的新客户端类。建议优先阅读安装版本对应的官方示例把客户端初始化方式调整一致。5.4 让 Agent 具备工具调用能力现在把简单的“单轮对话”扩展成“模型决定调用工具”的 Agent 链路。先定义一个天气查询工具。这里用本地函数模拟外部接口def get_weather(city: str) - str: # 实际项目中这里可以调用天气服务 API weather_map { 北京: 晴25 摄氏度, 上海: 多云28 摄氏度, 广州: 雷阵雨30 摄氏度, } return weather_map.get(city, 暂未收录该城市天气)再声明工具 Schema让模型知道存在这个工具以及参数格式tools [ { type: function, function: { name: get_weather, description: 获取指定城市的天气信息, parameters: { type: object, properties: { city: { type: string, description: 城市名称例如北京 } }, required: [city] } } } ]接下来实现主循环先让模型判断是否需要调用工具如果需要代码执行工具并把结果回传给模型模型再生成最终回答。from qianfan import ChatCompletion client ChatCompletion() def run_agent(user_input): messages [{role: user, content: user_input}] first_resp client.do( modelERNIE-4.0-8K, messagesmessages, toolstools ) # 如果模型返回了工具调用请求 if first_resp.get(tool_calls): tool_call first_resp[tool_calls][0] function_name tool_call[function][name] arguments tool_call[function][arguments] if function_name get_weather: city arguments.get(city) result get_weather(city) # 将工具调用请求和工具结果都追加进上下文 messages.append({ role: assistant, content: None, tool_calls: [tool_call] }) messages.append({ role: tool, tool_call_id: tool_call.get(id), content: result }) second_resp client.do( modelERNIE-4.0-8K, messagesmessages, toolstools ) return second_resp[result] return first_resp[result] print(run_agent(北京天气怎么样))这段代码的关键逻辑是模型不直接返回天气结果而是先返回调用工具的参数业务代码拿到参数后执行工具把真实结果追加到对话上下文模型看到工具结果后组织成更自然的回答返回给用户。5.5 验证和预期输出执行后预期输出类似北京今天天气晴朗气温 25 摄氏度适合出门活动。如果模型输出了原始 JSON 而没有组织成自然语言说明返回的tool_calls解析逻辑没有覆盖到。此时需要查看 SDK 返回结构确认tool_calls的字段名是否正确。这个最小案例已经具备 Agent 的雏形模型负责理解用户意图和选择工具代码负责实际执行结果再回流给模型生成最终回复。后续要做的扩展包括多轮记忆、多个工具选择、失败重试和权限控制。6. MaaS 和 Agent 的常见工程问题与排查清单6.1 鉴权失败现象调用模型 API 时返回 401、403 或提示 invalid authentication。可能原因API Key 或 Secret Key 配错。密钥被重置代码仍在使用旧值。在子账号下没有授权千帆服务。环境变量优先级低于代码中的写入值。检查方式打印客户端读取到的密钥前缀确认环境变量确实注入到控制台检查应用是否还存在尝试用官方示例配置跑通。处理建议统一把密钥放到环境变量或密钥管理服务中不要散落在多个配置文件里。出错时先确认当前生效的配置来源。6.2 上下文超限现象请求返回类似 context length exceeded 的错误。可能原因传入的 messages 太长超过模型上下文窗口上限多轮对话后没有清理历史工具调用结果过大。检查方式计算 messages 的总 Token 数查看工具返回的 JSON 是否包含大量无关键信息确认会话轮数。处理建议对历史消息做摘要压缩只保留最近 N 轮限制工具返回内容长度必要时使用外部记忆库存储长期信息。6.3 Agent 循环或停在错误分支现象Agent 反复调用同一个工具或迟迟不给出最终回答。可能原因模型没有得到足够明确的“完成后停止”指令工具结果没有进入模型上下文模型生成格式不符合预期重试策略无上限。检查方式打印每次请求的 messages 和模型返回记录工具调用次数观察finish_reason字段。处理建议在 Prompt 中明确限定最大步骤数代码层增加最大循环次数工具执行失败时返回结构化错误信息当模型连续多次调用相同工具时强制中断并转人工。6.4 排查顺序遇到问题不要直接看最终报错建议按以下顺序排查密钥是否有效、是否对当前环境生效。请求参数是否完整模型名称是否支持。messages 结构是否正确是否存在重复或字段缺失。是否是网络或服务限流。是否是上下文超限。是否是工具 Schema 格式错误。是否模型本身不支持 Function Calling 或当前参数。问题现象常见原因检查方式处理建议401 鉴权失败密钥错误或未配置打印环境变量并核对控制台重置密钥统一从环境变量读取提示模型不存在模型名称与账号权限不匹配查看千帆可用模型列表换成账号已开通的模型名称返回内容为空messages 结构错误或引擎过滤打印完整请求与响应检查 role、content 字段工具调用不生效模型不支持 Function Calling查看模型文档换支持工具调用的模型请求超时网络问题或模型负载高观察响应耗时和重试日志增加超时与重试排查出口网络7. 开发者和架构师应该如何看待这次调整最佳实践与落地建议7.1 应用层开发者的调整如果正在做 Agent 开发可以借着这次调整重新审视自己的技术选型。不要把模型调用、工具调用、会话状态全部耦合在一个函数里。建议分层模型接入层统一封装 MaaS 调用屏蔽不同模型接口差异。工具层使用标准 Schema 注册让模型可以理解工具能力。会话层管理短期记忆和长期记忆。应用层负责业务流程、权限控制和用户体验。这样的结构在平台能力变化时可以平滑迁移。今天用的 MaaS 平台接口明天换成另一个平台只需修改接入层业务代码不需要全量重写。7.2 平台架构视角从架构师视角看组织调整意味着平台会更快补齐 Agent 基建。选型时除了看模型效果还要关注平台提供的工程化能力是否支持工具注册与调用审计。是否提供知识库和记忆存储。是否提供 Agent 测试与评估工具。是否有完整的调用链路日志。是否支持多模型路由和灰度切换。这些都是生产环境真正需要的而不仅仅是 demo 阶段的模型效果。7.3 组织调整对技术选型的启发MaaS 划入基础设施之后模型能力会越来越像“水电”。团队选型时可以按基础设施的标准评估稳定性、成本可见性、运维成熟度、生态兼容性。Agent 独立成军之后Agent 开发框架会进入快速演进周期。不要急着自研全套 Agent 框架优先使用平台提供的标准能力同时保留业务层的扩展点。等到评估体系、可观测体系完善后再决定哪些模块需要自建。7.4 后续可以关注的信号判断这次调整是否真正落地可以关注几个信号千帆平台是否推出更完善的 Agent 项目模板和调试工具。平台是否提供细粒度的 Token 成本报表。Agent 的可观测能力是否从“只有模型调用日志”升级到“完整任务链路追踪”。是否出现面向 Agent 的独立计费、配额和安全策略。任何一个信号落地都会直接影响开发者的日常工作方式。这次调整的最大启示不是组织架构本身而是技术分层越来越清晰模型作为基础设施Agent 作为上层应用形态。开发者越早适应这种分层思维越能在接下来的 AI 应用浪潮中减少返工。学习阶段可以用简单的 SDK 调用把 Chat 跑通但真正进入生产环境前至少要把密钥管理、上下文控制、工具权限、循环上限、成本统计这五件事补上Agent 才算具备上线条件。从最小案例开始逐步扩展记忆、工具集和安全校验是一条值得长期走的技术路线。