企业官网建设流程全解析

最近百度智能云的一次组织调整，在技术圈里引发了不小的讨论：平台产品事业部被分拆，MaaS 被划入基础设施，Agent 独立成军。很多开发者关心的是：这次调整到底意味着什么？MaaS 和 Agent 的发展方向会有什么变化？咱们做应用开发的，又该怎么跟上这波节奏？

这篇文章不打算做新闻复述，而是把这次调整背后的技术逻辑拆开，结合 MaaS 平台的使用方式和 Agent 开发的核心思路，整理出一份能落地、可参考的实战内容。无论你是在做 AI 应用集成，还是准备入坑 Agent 开发，这篇文章都值得收藏。

1. 先看事件：百度智能云的组织调整说了什么

1.1 组织调整的核心信息

根据公开信息，百度智能云近日完成了一轮产研组织调整，平台产品事业部被分拆。调整的核心动作有两个：

• MaaS（Model as a Service，模型即服务）相关业务被划入基础设施体系；
• Agent 相关业务独立成军，形成单独的组织单元。

通俗点说，就是把“大模型能力”往底层基础设施方向收拢，同时把“智能体应用”这个更贴近业务和场景的方向独立出来重点投入。

这件事表面上是组织架构变化，实际上反映出云厂商对大模型产业分工的一次重新定位。对开发者来说，它传递的信号很清楚：MaaS 会越来越像云服务器、对象存储一样成为基础资源，而 Agent 会从“实验性功能”变成“正式产品方向”。

1.2 为什么这次调整值得开发者关注

过去一年，很多团队做 AI 应用时都会遇到类似的困惑：大模型 API 到底应该由谁提供？Agent 应用应该自己搭还是用平台？模型能力、应用框架、业务系统之间的边界在哪里？

这次调整实际上给了我们一个观察窗口：云厂商正在把大模型能力沉淀为更标准化的基础设施，同时把 Agent 相关的开发工具、运行时、编排能力产品化。

对开发者而言，这意味着两件事：

• 未来接入大模型能力的门槛会更低，API 的标准化程度会更高；
• Agent 开发会逐渐从“自己拼装”走向“平台化 + 组件化”，但核心原理和架构设计能力仍然是开发者自己的竞争力。

所以，与其纠结组织架构的细节，不如把注意力放在 MaaS 和 Agent 这两个技术方向上。下面我们先把这两个概念彻底厘清。

2. MaaS 与 Agent：先厘清两个基础概念

2.1 什么是 MaaS

MaaS，全称 Model as a Service，即模型即服务。它把大语言模型、多模态模型等 AI 能力封装成可直接调用的服务，开发者通过 API 或 SDK 就能使用，不需要自己训练模型，也不需要维护推理服务器。

你可以把 MaaS 理解成“AI 时代的数据库”：

• 以前做业务系统，要自己部署数据库、写 SQL；
• 现在做 AI 应用，直接调用模型 API，传入提示词就能获得生成结果。

MaaS 平台通常提供以下几类能力：

对于大多数应用开发者来说，日常接触最多的就是模型推理 API。这也是本文后面实战部分要重点演示的内容。

2.2 什么是 Agent

Agent，中文常翻译为“智能体”。它不是一个单一模型，而是一个以大模型为“大脑”、能够自主完成任务的系统。

一个完整的 Agent 通常包含四个核心组件：

• 大模型（规划与决策）：负责理解任务、拆解步骤、决定下一步动作；
• 工具（执行能力）：例如搜索引擎、代码执行器、数据库查询接口、HTTP API 等；
• 记忆（短期 + 长期）：保存当前任务的上下文，以及历史交互信息；
• 编排逻辑（控制流）：决定模型在什么条件下调用哪个工具、如何终止循环。

Agent 和普通 ChatBot 最大的区别在于：ChatBot 只是“你说一句、我回一句”，而 Agent 会为了实现一个目标，主动规划多步操作，并在执行过程中根据反馈调整策略。

举个例子：

• 普通 ChatBot：用户问“帮我查一下明天的天气”，模型直接回答“我无法访问实时数据”；
• Agent：模型发现需要天气数据，调用天气 API，拿到结果后整理成自然语言回复用户。

这就是 Agent 的价值所在——把大模型从“会聊天”变成“会办事”。

2.3 MaaS 和 Agent 的关系

MaaS 和 Agent 是不同层次的东西，但二者紧密相关：

• MaaS 提供的是模型能力，相当于 Agent 的“大脑”；
• Agent 是建立在模型能力之上的应用形态，相当于“完整的人”。

打个比方：MaaS 是发动机，Agent 是整车。发动机决定了动力上限，但整车好不好开，还取决于底盘调校、转向系统、安全配置——对应到 Agent 上就是提示词设计、工具调用、记忆管理和安全控制。

所以，当云厂商把 MaaS 划入基础设施、把 Agent 独立成军时，本质上是在做“分层建设”：

• 底层把模型能力做厚、做稳、做便宜；
• 上层把 Agent 开发做简单、做标准、做安全。

这对开发者的启示是：既要学会调用 MaaS API，也要掌握 Agent 的核心架构能力。下面我们逐一展开。

3. 组织调整背后的技术趋势解读

3.1 MaaS 进入基础设施层，意味着什么

“MaaS 划入基础设施”这个动作，在技术层面有几个值得关注的点。

第一，模型的接入方式会更趋于标准化。就像云主机有统一的启动方式、对象存储有统一的读写接口一样，MaaS 也会逐渐收敛出事实标准。目前主流云厂商已经提供了大量 OpenAI 兼容接口，这大大降低了应用层的迁移成本。

第二，模型推理成本会进一步下降。当模型能力被当作基础设施运营，规模化效应会带动单位成本下降。对开发者来说，这意味着可以更大胆地在业务中使用模型能力，而不是把每次 API 调用都当作“昂贵操作”。

第三，模型能力会与云计算的其他基础设施深度绑定。例如模型服务与向量数据库、对象存储、消息队列、函数计算等服务的打通。未来的 AI 应用，可能不只是“调用一个模型 API”，而是“在云上编排一组服务”。

这也是为什么我们看到很多 MaaS 平台开始提供模型服务之外的能力：知识库托管、Prompt 缓存、模型网关、可观测性等。MaaS 正在从“模型 API”走向“完整的模型基础设施”。

3.2 Agent 独立成军，开发者生态会有哪些变化

Agent 独立成军，意味着云厂商会把更多资源投入到 Agent 开发平台、运行时和工具链上。对开发者来说，以下几个方向的变化会比较明显。

一是 Agent 开发框架会逐渐走向标准化。过去做 Agent 大多数是“自己拼”：自己写 ReAct 循环、自己管理上下文、自己处理工具调用。未来会有更多平台提供开箱即用的编排能力，开发者只需要关注业务逻辑和工具定义。

二是 Agent 的可观测性和调试能力会增强。Agent 和多步工具调用天然具有不确定性，调试往往比传统程序困难。平台化之后，链路追踪、逐步回放、中间状态查看等能力会成为标配。

三是 Agent 的安全与治理会被前置到架构阶段。Agent 一旦具备工具调用能力，就意味着它能影响真实世界——发邮件、删文件、提订单。如何做权限隔离、操作审批、行为审计，会成为企业落地 Agent 时最关心的部分。

从开发者的角度看，这是一个“门槛降低、天花板升高”的行业阶段：入门做 Agent 更容易了，但做出稳定、安全、可维护的 Agent，仍然需要扎实的工程能力。

4. 面向开发者的三个直接变化

4.1 API 与平台的接入方式更统一

如果你之前接触过百度智能云千帆或其他 MaaS 平台，会发现大模型的接入方式越来越接近：创建应用 → 获取 API Key → 调用接口。这和调用传统云服务的流程几乎一致。

对于已经在做 AI 应用的团队，建议尽早把“模型调用层”抽象出来，避免和具体厂商的 SDK 强绑定。这样即使未来切换模型服务商，业务代码也不会有太大改动。

4.2 Agent 开发会从手写走向平台化

过去要搭建一个 Agent，需要自己处理模型 API、工具注册、上下文管理、循环控制、错误重试等一堆问题。随着平台化发展，很多底层能力会被封装起来。

但这里想提醒一点：平台化可以降低开发工作量，却不应该替代架构理解。如果你不理解 Agent 的核心运行机制，遇到问题时会非常被动——不知道是模型的问题、工具的问题，还是编排逻辑的问题。

4.3 安全与治理被提前到架构设计阶段

Agent 独立成军之后，企业级应用对 Agent 的要求不再只是“能不能完成任务”，还包括“任务执行是否可控、可审计、可回滚”。

这就要求开发者在设计 Agent 时，把以下问题提前想清楚：

• Agent 可以调用哪些工具，不可以调用哪些工具？
• Agent 执行高风险操作时，是否需要人工审批？
• Agent 的完整执行链路是否可追踪？
• Agent 使用的外部数据是否合规？

这些问题的答案，会直接影响系统架构设计，而不是上线前的补丁。

5. 环境准备与基础工具链

在进入实战之前，先把开发和实验环境准备好。下面的内容以通用流程为主，具体版本和参数请根据你实际使用的平台调整。

5.1 开发环境

本文的示例代码使用 Python 编写，建议环境如下：

• 操作系统：Windows 10/11、macOS、Linux 均可；
• Python 版本：3.9 及以上；
• 开发工具：VS Code 或 PyCharm；
• 依赖库：requests、openai（如果平台提供 OpenAI 兼容接口）。

可以先创建虚拟环境并安装依赖：

mkdir ai-agent-demo cd ai-agent-demo python -m venv venv # Windows venv\Scripts\activate # macOS / Linux source venv/bin/activate pip install requests openai python-dotenv

5.2 获取大模型 API 密钥的通用流程

很多新手在做 MaaS 或 Agent 实验时，卡在了密钥获取这一步。虽然不同平台的页面会有差异，但整体流程通常是：

1. 注册并登录云厂商账号；
2. 在控制台找到“模型服务”或“千帆大模型平台”这类入口；
3. 开通模型服务权限；
4. 创建应用或 API Key；
5. 将 Secret Key 保存到本地环境变量。

在实际操作中，不同平台对密钥的称呼不太一样，有的叫 API Key，有的分 Access Key 和 Secret Key。建议将密钥保存在项目根目录的.env文件中，避免硬编码到代码里：

# .env API_KEY=your_api_key_here BASE_URL=https://your-maas-platform-endpoint MODEL_NAME=your-model-name

然后通过python-dotenv加载：

import os from dotenv import load_dotenv load_dotenv() API_KEY = os.getenv("API_KEY") BASE_URL = os.getenv("BASE_URL") MODEL_NAME = os.getenv("MODEL_NAME")

这样配置的好处是：代码仓库中可以安全提交.env.example，而真实的.env文件加入.gitignore。

需要注意，密钥属于敏感信息。如果是在企业项目中，建议使用专门的密钥管理服务或云厂商的凭据管理功能，不要直接写在代码或配置文件里。

6. 实战一：基于 MaaS API 完成一次模型调用

这一节我们来完成第一个实际任务：通过 MaaS 平台的 API 调用大模型，实现一个简单的文本生成功能。

6.1 创建项目结构

在ai-agent-demo目录下创建以下结构：

ai-agent-demo/ ├── .env ├── .env.example ├── .gitignore ├── maas_demo.py └── agent_demo.py

6.2 编写核心调用代码

如果你的 MaaS 平台提供 OpenAI 兼容接口，可以直接使用openaiSDK。示例代码如下：

# 文件路径：maas_demo.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI( api_key=os.getenv("API_KEY"), base_url=os.getenv("BASE_URL"), ) def chat_with_model(prompt: str) -> str: response = client.chat.completions.create( model=os.getenv("MODEL_NAME"), messages=[ {"role": "system", "content": "你是一个专业的技术助手，回答要简洁、准确。"}, {"role": "user", "content": prompt}, ], temperature=0.7, max_tokens=1024, ) return response.choices[0].message.content if __name__ == "__main__": result = chat_with_model("请用一句话解释什么是 MaaS？") print(result)

如果你的平台没有提供 OpenAI 兼容接口，也可以直接用requests发起 HTTP 请求。为了保持通用性，这里再给一个基于requests的示例，实际使用时需要根据平台文档调整请求地址和参数格式：

# 文件路径：maas_demo_requests.py import os import requests from dotenv import load_dotenv load_dotenv() API_KEY = os.getenv("API_KEY") BASE_URL = os.getenv("BASE_URL") MODEL_NAME = os.getenv("MODEL_NAME") def chat_with_model(prompt: str) -> str: url = f"{BASE_URL}/chat/completions" headers = { "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json", } payload = { "model": MODEL_NAME, "messages": [ {"role": "system", "content": "你是一个专业的技术助手，回答要简洁、准确。"}, {"role": "user", "content": prompt}, ], "temperature": 0.7, "max_tokens": 1024, } response = requests.post(url, headers=headers, json=payload, timeout=30) response.raise_for_status() data = response.json() return data["choices"][0]["message"]["content"] if __name__ == "__main__": result = chat_with_model("请用一句话解释什么是 MaaS？") print(result)

这里有几个关键参数需要解释一下：

• temperature：控制输出的随机性。值越低，输出越确定；值越高，越有创造性。需要稳定答案时建议调到 0.2 左右。
• max_tokens：限制生成的最大 token 数量，防止单次返回过长。
• system消息：用于设定模型的角色和行为规范，是提示词工程中最基础的手段。

6.3 运行与验证

在.env文件中填好配置后，运行：

python maas_demo.py

正常输出类似：

MaaS（Model as a Service，模型即服务）是一种将大模型能力封装为可直接调用的云服务的模式，开发者无需训练和部署模型，即可通过 API 使用先进的 AI 能力。

到这里，你已经完成了最简单的 MaaS 平台接入。这是后续所有 Agent 开发的基础——Agent 的“大脑”就是通过这类 API 调用来工作的。

7. 实战二：从零实现一个最小 Agent

理解 MaaS API 调用之后，我们来写一个真正有“智能体”味道的程序。

这个 Agent 不需要任何复杂框架，我们会手动实现一个简化版的 ReAct（Reasoning + Acting）循环，让你彻底理解 Agent 的本质。

7.1 Agent 的核心循环逻辑

ReAct 模式的核心思想是让模型交替进行“思考”和“行动”：

1. 接收用户任务；
2. 模型分析任务，决定是否调用工具；
3. 如果需要工具，输出带有工具名称和参数的结构化内容；
4. 程序执行工具，把结果返回给模型；
5. 模型根据工具结果继续推理或给出最终答案；
6. 重复以上步骤，直到模型认为任务完成。

这个循环看起来简单，但它是所有复杂 Agent 系统的基石。

7.2 代码实现

我们实现一个“能查时间、能做加法”的最小 Agent。为了让代码不依赖于具体的大模型平台，这里做一个简化：用规则模拟模型的工具选择。如果你需要接入真实模型，把decide_action函数替换成一次 MaaS API 调用即可。

# 文件路径：agent_demo.py import datetime from typing import Dict, Any # ---------- 工具层 ---------- def get_current_time() -> str: """工具1：获取当前时间""" return datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S") def add_numbers(a: float, b: float) -> float: """工具2：计算两数之和""" return a + b # 工具注册表 TOOLS = { "get_current_time": get_current_time, "add_numbers": add_numbers, } # ---------- 决策层（用规则模拟模型推理） ---------- def decide_action(task: str) -> Dict[str, Any]: """ 真实场景中，这里应该调用大模型 API。 这里用关键词规则模拟模型的“思考”过程。 """ if "时间" in task: return {"action": "get_current_time", "args": {}} if "加" in task or "求和" in task: # 简单解析数字 import re numbers = re.findall(r"\d+\.?\d*", task) if len(numbers) >= 2: return { "action": "add_numbers", "args": {"a": float(numbers[0]), "b": float(numbers[1])}, } return {"action": "error", "args": {"message": "无法从任务中解析两个数字"}} return {"action": "unknown", "args": {}} # ---------- 执行层 ---------- def execute_action(action: str, args: Dict[str, Any]) -> str: if action in TOOLS: result = TOOLS[action](**args) return str(result) if action == "error": return f"错误：{args.get('message')}" return "抱歉，我无法处理这个任务。" # ---------- Agent 主循环 ---------- def run_agent(task: str) -> str: print(f"用户任务：{task}") thought = decide_action(task) print(f"模型思考：需要执行 {thought['action']}") observation = execute_action(thought["action"], thought["args"]) print(f"工具返回：{observation}") # 真实场景中，这里会再调用一次模型，根据观察结果生成最终回复。 final_answer = f"任务完成：{observation}" return final_answer if __name__ == "__main__": print(run_agent("现在几点？")) print() print(run_agent("请计算 12.5 加 8.3 的结果"))

7.3 运行与验证

运行这个程序：

python agent_demo.py

预期输出：

用户任务：现在几点？ 模型思考：需要执行 get_current_time 工具返回：2025-06-01 14:30:22 任务完成：2025-06-01 14:30:22 用户任务：请计算 12.5 加 8.3 的结果 模型思考：需要执行 add_numbers 工具返回：20.8 任务完成：20.8

这个例子虽然简单，但它体现了 Agent 最核心的结构：工具层、决策层、执行层、主循环。在实际项目中，只需要把decide_action换成真正的大模型调用，让模型根据任务的语义来决定调用哪个工具，就是一个可以工作的 ReAct Agent。

7.4 把规则决策替换为模型决策

下面给出一个把决策层替换为大模型调用的思路。这里使用 MaaS API 返回 JSON 形式的工具调用指令。

# 伪代码，演示思路 def decide_action_with_llm(task: str) -> Dict[str, Any]: prompt = f""" 你是一个智能体调度器，请根据用户任务决定调用哪个工具。 可用工具： - get_current_time: 获取当前时间，不需要参数 - add_numbers: 计算两个数字相加，参数为 a 和 b 用户任务：{task} 请只输出 JSON，格式如下： {{"action": "工具名", "args": {{"参数名": 参数值}}}} """ # 调用 MaaS 平台 API（参考 maas_demo.py 中的 chat_with_model） # response = chat_with_model(prompt) # 解析 response 中的 JSON，返回 dict # 为了演示，这里先返回空 return {"action": "unknown", "args": {}}

在实际项目中，建议给模型提供“工具定义”的结构化描述（类似 OpenAI 的 function calling），这样模型能更稳定地输出合法的工具调用请求。

8. 常见问题与排查思路

在 MaaS 接入和 Agent 开发过程中，有几类问题出现的频率非常高。下面整理出来，方便你遇到报错时快速定位。

8.1 密钥或鉴权相关问题

这些问题的排查顺序一般是：先确认网络请求能到达平台，再确认密钥正确，最后确认权限范围。

8.2 Agent 执行报错或异常终止

很多做 Agent 开发的朋友遇到过类似agent execution terminated due to error的报错。这类问题通常和下面几个原因有关：

• 工具调用抛出了未捕获的异常。例如网络超时、JSON 解析失败、参数类型错误。
• Agent 进入了死循环，不断调用同一个工具而没有进展，触发了最大步数限制。
• 模型输出的工具调用格式不符合预期，导致解析失败。

排查思路如下：

1. 为每个工具调用增加 try-except，记录详细的错误日志；
2. 为 Agent 循环设置最大迭代次数，避免无限循环；
3. 对模型的输出做校验，如果 JSON 解析失败，可以提示模型重新输出；
4. 查看完整调用链路的日志，确认是模型的问题、工具的问题还是编排逻辑的问题。

8.3 模型输出不稳定或格式错误

有时模型能回答问题，但输出的 JSON 格式不对，导致程序解析失败。常见的处理方式：

• 在提示词中给出明确的输出格式示例；
• 使用平台提供的 function calling / tool calling 能力，而不是让模型“自由发挥”输出 JSON；
• 解析失败时进行重试，并告诉模型“上次输出格式错误，请重新输出”。

8.4 费用超预期

大模型 API 按 token 计费，Agent 的多轮循环会显著增加 token 消耗。建议：

• 对每次 API 调用的输入输出做日志记录；
• 在开发和测试阶段使用较小的模型或较短的max_tokens；
• 为 Agent 的上下文设置长度上限，避免历史消息无限累积。

9. 最佳实践与工程建议

9.1 提示词设计与系统消息

不要把提示词写死在业务代码里。建议单独维护提示词模板文件，并在版本库中管理。对于较复杂的 Agent，每个工具的描述、每个步骤的指令都应该经过反复测试和迭代。

一个比较实用的经验是：在系统消息中明确 Agent 的能力边界。例如“如果你不知道答案，直接说不知道，不要编造”——这可以有效减少模型的幻觉输出。

9.2 工具调用的安全边界

Agent 的能力来自工具，风险也来自工具。给 Agent 接入工具之前，务必评估以下问题：

• 这个工具是否允许被自主调用？
• 工具操作是否有权限校验？
• 工具的调用是否会被审计？

尤其是涉及数据删除、文件写入、对外发送消息等操作时，建议默认加一道人工审批。生产中可以采用“高危操作需二次确认”的模式，避免 Agent 误操作。

9.3 可观测性与日志

Agent 系统的不确定性比传统软件高得多，可观测性不是可选项，而是必备项。

建议至少记录以下信息：

• 每次模型调用的输入 token、输出 token、耗时；
• 每次工具调用的参数和返回结果；
• Agent 的完整思考链（模型中间输出）；
• 异常和重试记录。

有了这些日志，才能定位“Agent 为什么做错了”或者“为什么卡住了”。

9.4 成本控制与性能优化

Agent 的成本主要来自多轮模型调用。优化方向包括：

• 精简上下文：只保留必要的历史信息，而不是把所有对话都传给模型；
• 缓存复用：对于重复的请求，可以缓存模型输出；
• 分级模型：简单任务用小模型，复杂任务用大模型，降低成本。

9.5 从实验到生产的检查清单

如果要把 Agent 从 demo 推向生产，建议对照以下清单逐项确认：

• [ ] 模型调用是否设置了超时和重试？
• [ ] 工具调用是否有异常兜底？
• [ ] Agent 循环是否有最大步数限制？
• [ ] 敏感操作是否有人工审批？
• [ ] 完整链路是否有日志可追溯？
• [ ] 密钥和凭据是否安全托管？
• [ ] 是否有成本监控和告警？

10. 总结与后续学习路线

通过这篇文章，我们完成了三件事：

第一，理解了百度智能云这次组织调整背后的技术逻辑——MaaS 往基础设施走，Agent 往独立产品方向走；

第二，掌握了 MaaS 平台 API 的接入方法，能够通过代码调用大模型能力；

第三，从零实现了一个最小 Agent，理解了工具层、决策层、执行层和主循环的核心结构。

如果你准备在 Agent 方向继续深入，接下来可以重点学习以下内容：

• Function Calling 的标准用法；
• 长短期记忆机制；
• 多 Agent 协作模式；
• Agent 评估与测试方法；
• 企业级 Agent 的安全治理方案。

其中，Agent 的评测是最容易被忽视但实际最关键的环节。因为 Agent 的行为具有不确定性，没有一个固定的“正确输出”，如何设计评测集、如何衡量任务完成率，是值得单独花时间研究的课题。

如果你最近也在做 MaaS 接入或 Agent 开发，建议先把本文的示例代码跑一遍，然后尝试给 Agent 增加一个新的工具，比如查询数据库或调用内部 API。动手改一遍，理解的深度会完全不一样。

后续我还会写关于 Agent 记忆机制、工具调用标准化、以及企业级 Agent 落地的系列文章。可以先关注起来，方便第一时间看到更新。