企业官网建设流程全解析

百度智能云把 MaaS 划入基础设施、把 Agent 独立成军，这个消息在云厂商圈子里讨论度很高。很多开发者第一反应是：这跟我有什么关系？其实关系很大。组织调整背后往往预示着产品投入方向的变化，而 MaaS 和 Agent 恰恰是当前大模型应用落地最核心的两块拼图。本文不聊内部八卦，只从技术视角拆解这次调整释放出的信号，重点讲清楚 MaaS 平台到底在解决什么问题、Agent 开发为什么要单独成体系，并给出一套完整的 MaaS API 调用示例和 Agent 开发入门实战。无论你是后端工程师、算法工程师，还是正在选型大模型平台的技术负责人，这篇文章都能帮你把思路理清楚。

1. 背景与核心概念

1.1 这次组织调整透露了什么信号

据公开信息，百度智能云近日完成了一轮产研组织调整，核心变化是：分拆平台产品事业部，MaaS（Model as a Service，模型即服务）相关能力并入基础设施体系，Agent 相关产品独立成军。

用大白话翻译一下：大模型底座被当成“水电煤”一样的基础设施来建设，而智能体（Agent）被当成一个独立的产品方向去投入。这个信号非常明确——云厂商已经过了“我有一个大模型”的阶段，开始进入“模型要变成稳定基础设施，智能体要变成能交付的业务产品”的阶段。

对开发者来说，这意味着两件事：

1. 以后调用大模型能力会越来越像调用云服务器、OSS 存储一样标准化，平台层会帮你解决弹性、限流、成本、安全等问题。
2. Agent 不再是某个模型 API 的附属功能，而是一个独立的工程领域，有自己的一套开发框架、编排规范、调试工具和运维体系。

具体调整细节以百度智能云官方发布为准，但技术趋势是确定的：MaaS 下沉，Agent 上浮。

1.2 MaaS 到底是什么

MaaS，全称 Model as a Service，即“模型即服务”。它的核心思想是：把大模型封装成可直接通过 API 调用的服务，开发者不需要关心模型怎么训练、怎么部署、GPU 怎么管理，只需要按调用量付费。

一个典型的 MaaS 平台通常包含以下能力：

MaaS 存在的意义，是让企业不用从零建设大模型基础设施，就能在业务中接入模型能力。

1.3 Agent 是什么

Agent（智能体）是一个能感知环境、进行决策并执行动作的 AI 程序。它和大模型 API 的“一问一答”模式不同：Agent 可以拆解复杂任务、调用外部工具、访问知识库、执行多步操作，最终完成一个完整的目标。

举个例子：

• 只调大模型 API：用户问“今天上海天气怎么样”，模型回答“我无法获取实时天气数据，请查询天气应用”。
• 用 Agent 实现：用户问同样的问题，Agent 识别出需要调用天气查询工具，自动调用“天气 API”，拿到数据后组织语言回答用户。

更复杂的场景包括：自动处理工单、自动编写并执行代码、多轮对话中持续记忆上下文、连接企业内部 CRM/ERP 系统完成业务操作。

Agent 和普通对话机器人的核心区别在于：它具备“行动能力”。

2. MaaS 平台的基础能力拆解

2.1 为什么 MaaS 要划入基础设施

过去很多团队使用大模型时，是直接在模型 API 外面套一层业务逻辑，缺少统一的网关、鉴权、限流、成本核算能力。当业务量上来之后，问题会集中爆发：

• 多个业务共用一套模型账号，成本无法拆分到部门。
• 某个业务突发流量，把整批模型调用拖垮。
• Prompt 散落在各个服务代码里，改一个提示词要重新发版。
• 模型输出没有质量评估，线上效果出了问题很难定位是模型问题还是业务问题。

MaaS 划入基础设施，本质上就是把这些“平台级问题”交给基础设施团队统一解决。开发者的视角也会随之改变：使用 MaaS 就像使用数据库、缓存、消息队列一样，有明确的 SLA、有监控告警、有成本账单。

2.2 MaaS 平台调用模型的标准姿势

目前主流 MaaS 平台普遍兼容 OpenAI 风格的接口协议，也就是/v1/chat/completions这一套。这样做的好处是：开发者的代码可以在不同平台之间低成本迁移。

下面我们以 Python 为例，演示一个标准的 MaaS 模型调用流程。注意，以下代码是示例写法，具体 endpoint、模型名称、鉴权方式要按你实际使用的平台文档为准。

import requests import json # 配置信息，建议通过环境变量读取，不要硬编码在代码里 API_KEY = "your-api-key" BASE_URL = "https://your-maas-endpoint.example.com/v1" def chat_with_model(messages, model="ernie-4.0-turbo"): """ 调用 MaaS 平台对话接口 :param messages: 消息列表，格式为 [{"role": "user", "content": "你好"}] :param model: 模型名称，按实际平台命名填写 :return: 模型回复文本 """ url = f"{BASE_URL}/chat/completions" headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" } payload = { "model": model, "messages": messages, "temperature": 0.7, "max_tokens": 1024 } try: response = requests.post(url, headers=headers, json=payload, timeout=30) response.raise_for_status() data = response.json() # 解析模型回复内容 content = data["choices"][0]["message"]["content"] return content except requests.exceptions.Timeout: return "请求超时，请稍后重试" except requests.exceptions.HTTPError as e: return f"HTTP 错误: {e.response.status_code} {e.response.text}" except Exception as e: return f"调用失败: {str(e)}" if __name__ == "__main__": messages = [ {"role": "system", "content": "你是一个专业的技术助手，回答要简洁准确。"}, {"role": "user", "content": "请解释一下 MaaS 和 PaaS 的区别。"} ] result = chat_with_model(messages) print("模型回复：", result)

这段代码做了几件基础但规范的事：

• 使用requests库发送 POST 请求，这是最通用的方式。
• 设置了超时时间，避免模型响应慢导致业务线程阻塞。
• 对常见异常做了处理，把错误信息返回给调用方。
• 把 API Key 通过变量传入，方便后续改造为环境变量读取。

更推荐的做法是使用环境变量管理密钥：

export BAIDU_CLOUD_API_KEY="your-secret-key" export BAIDU_CLOUD_MODEL_ENDPOINT="https://your-maas-endpoint.example.com/v1"

然后修改 Python 代码，从环境变量读取配置：

import os API_KEY = os.getenv("BAIDU_CLOUD_API_KEY", "") BASE_URL = os.getenv("BAIDU_CLOUD_MODEL_ENDPOINT", "")

如果你使用的是百度智能云千帆 ModelBuilder 这样的 MaaS 平台，API Key 通常可以在控制台的“安全认证”或“API Key 管理”页面创建。不同云厂商的入口名称可能不一样，以控制台实际显示为准。

2.3 MaaS 调用中的关键参数

使用 MaaS 平台时，以下几个参数直接影响效果和成本，值得单独说明。

model

模型名称是平台方定义的，通常每个平台有多个模型可选：通用对话模型、长文本模型、代码模型、向量模型等。生产环境建议把模型名称写在配置中心或环境变量里，方便灰度切换。

temperature

temperature 控制输出的随机性，取值范围一般是 0 到 1。值越低，输出越稳定、确定性越强；值越高，输出越多样、越有创造性。

• 写代码、做分类、抽取结构化信息：建议 0.1 到 0.3。
• 写文案、头脑风暴：建议 0.7 到 0.9。
• 通用场景：0.5 左右。

max_tokens

限制模型最大输出长度。注意它只限制输出，不限制输入长度。输入超长时平台通常会有单独的请求失败提示。

messages

聊天消息列表，每条消息包含role和content字段。role有三种：

• system：系统指令，设定模型的身份和行为。
• user：用户输入。
• assistant：模型历史回复。

多轮对话要把历史消息一起传给模型，否则模型会“失忆”。但历史消息越多，消耗的 token 也越多，成本就越高。工程上通常需要做“上下文裁剪”或“摘要压缩”。

2.4 MaaS 与 API Gateway 的关系

这里有必要区分两个容易混淆的概念。

MaaS 平台的核心价值是“模型即服务”，它把模型推理能力封装成 API。而 API Gateway（API 网关）是通用的流量入口，负责路由、鉴权、限流、日志等。

实际架构中，MaaS 平台往往内置了 API 网关能力，但企业自己也可以在最外层再加一层网关。典型调用链路如下：

客户端 -> 企业内部 API 网关 -> MaaS 平台 -> 模型服务

这样做的好处是：企业可以在自己的网关上做更细粒度的权限控制、业务日志、成本分账，不依赖云厂商的控制台。

3. Agent 独立成军：技术趋势与能力拆解

3.1 为什么 Agent 值得单独拉一条产品线

“Agent 独立成军”这个动作，说明云厂商判断 Agent 不是一个小功能，而是一条完整的产品线。从技术视角看，Agent 确实具备产品化的条件：

1. 场景成熟：客服助手、知识问答、代码辅助、数据分析、自动化测试，这些场景都有明确的业务价值和付费意愿。
2. 技术闭环：模型调用、工具调用、记忆管理、编排引擎、可观测性，这些技术模块已经形成相对稳定的组合模式。
3. 商业模式清晰：Agent 可以按“工作流执行次数”“Agent 实例数”“效果订阅”等方式计费，比单纯卖 API 有更大的想象空间。

3.2 Agent 的核心组成模块

一个生产级的 Agent 系统，通常包含以下几个核心模块：

其中，工具调用是 Agent 区别于普通对话的关键。没有工具调用能力，Agent 就只能“嘴上说”，不能“动手做”。

3.3 Agent 开发框架的两种路线

当前市面上 Agent 开发框架很多，但核心路线基本分两种。

路线一：声明式编排

通过 YAML/JSON 定义 Agent 的工作流：先做什么、再做什么、什么条件下调用哪个工具。代表思路是低代码平台常见的“节点编排”。适合业务流程相对固定、需要严格可控的场景。

workflow: - node: intent_recognition type: llm prompt: "判断用户意图：查天气 or 查航班" - node: get_weather type: tool tool: weather_api condition: "${intent_recognition.result} == 'weather'" - node: get_flight type: tool tool: flight_api condition: "${intent_recognition.result} == 'flight'"

路线二：代码式函数调用

通过代码编写 Agent 的逻辑，模型只负责“决定调用哪个函数”，具体的函数执行、流程控制、异常处理全部由代码完成。这种方式更灵活，适合复杂业务。后面第 4 节的实战案例就是这种路线。

两种路线不是对立的，生产系统里经常混用：简单任务用声明式编排保证稳定，复杂任务用代码式函数调用保证灵活。

4. 从零构建一个最小可用的 Agent 实战

这一节我们动手写一个最小可用的 Agent。它的功能是：用户提问时，Agent 能判断是否需要调用外部工具，如果需要就自动调用，最后把结果组织成自然语言回复给用户。

为了演示核心原理，我们不依赖重量级框架，只用 Python 语言实现一个简化版的“函数调用 Agent”。完整理解这个例子后，你再迁移到 LangChain、千帆 AgentBuilder 等平台上会非常快。

4.1 创建项目结构

建议按下面的结构组织代码：

agent-demo/ ├── .env # 环境变量配置 ├── requirements.txt # 依赖声明 ├── agent.py # Agent 核心逻辑 ├── tools.py # 工具函数定义 ├── config.py # 配置读取 └── demo.py # 入口演示

4.2 安装依赖与环境配置

pip install python-dotenv requests

创建.env文件：

API_KEY=your-maas-api-key MODEL_NAME=your-model-name BASE_URL=https://your-maas-endpoint.example.com/v1

创建config.py：

import os from dotenv import load_dotenv load_dotenv() API_KEY = os.getenv("API_KEY", "") MODEL_NAME = os.getenv("MODEL_NAME", "") BASE_URL = os.getenv("BASE_URL", "") if not API_KEY: raise ValueError("请在 .env 文件中配置 API_KEY")

4.3 定义工具函数

Agent 要能调用工具，第一步是定义好工具函数。我们定义两个最简单的工具：一个计算器，一个获取当前时间。真实项目中，你会把“查询订单”“获取库存”“发短信”等业务操作定义成工具。

创建tools.py：

import datetime import json def calculator(expression: str) -> str: """ 计算数学表达式 注意：真实的表达式计算不应该直接用 eval，这里仅用于教学演示。 生产环境请使用 ast.literal_eval 或专门的表达式解析库。 """ try: # 什么是安全：只允许数字和基础运算符的表达式 allowed_chars = set("0123456789+-*/(). ") if not set(expression).issubset(allowed_chars): return "只支持数字和基础运算符" result = eval(expression) # 教学用 eval，生产环境请替换 return str(result) except Exception as e: return f"计算失败: {str(e)}" def get_current_time() -> str: """获取当前服务器时间""" now = datetime.datetime.now() return now.strftime("%Y-%m-%d %H:%M:%S") TOOLS = { "calculator": { "function": calculator, "description": "计算数学表达式，例如：1 + 2 * 3", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "要计算的数学表达式" } }, "required": ["expression"] } }, "get_current_time": { "function": get_current_time, "description": "获取当前时间，无需参数", "parameters": { "type": "object", "properties": {} } } }

这段代码里有两个细节值得注意：

1. TOOLS字典统一管理了工具的函数实现、功能描述和参数定义。这些信息会被拼接进 Prompt 中，供模型选择。
2. 模型本身不具备计算能力，通过定义calculator工具，模型可以把表达式“外包”给代码执行。

安全提醒：示例中的eval仅用于教学演示，生产环境绝不能直接对模型输出执行eval。后面第 6 节会专门展开安全边界的话题。

4.4 实现 Agent 核心循环

Agent 的核心是一个循环：模型决定是否需要调用工具，如果需要就执行工具并把结果返回给模型，直到模型认为任务完成。

创建agent.py：

import json import requests import config from tools import TOOLS def build_system_prompt() -> str: """构建系统提示词，把工具列表告诉模型""" tool_descriptions = [] for name, info in TOOLS.items(): params = json.dumps(info["parameters"], ensure_ascii=False) desc = f"工具名称: {name}\n工具描述: {info['description']}\n参数定义: {params}" tool_descriptions.append(desc) prompt = f"""你是一个智能助手，根据用户问题判断是否需要使用工具。 如果用户的问题需要查询实时数据或进行计算，必须使用合适的工具。 可选工具如下： {chr(10).join(tool_descriptions)} 当需要使用工具时，请严格按以下 JSON 格式回复（不要输出其他内容）： {{"tool": "工具名称", "arguments": {{"参数名": "参数值"}}}} 当不需要使用工具时，请直接自然回复用户。 """ return prompt def call_llm(messages) -> str: """调用 MaaS 平台模型""" url = f"{config.BASE_URL}/chat/completions" headers = { "Content-Type": "application/json", "Authorization": f"Bearer {config.API_KEY}" } payload = { "model": config.MODEL_NAME, "messages": messages, "temperature": 0.2, # 工具调用场景建议低温，提高确定性 "max_tokens": 512 } response = requests.post(url, headers=headers, json=payload, timeout=30) response.raise_for_status() data = response.json() return data["choices"][0]["message"]["content"] def run_agent(user_input: str, max_steps: int = 5) -> str: """ 运行 Agent 主循环 参数: user_input: 用户输入 max_steps: 最大循环步数，防止 Agent 陷入死循环 """ system_prompt = build_system_prompt() messages = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_input} ] for step in range(max_steps): print(f"[step {step + 1}] 正在调用模型...") response_text = call_llm(messages) # 尝试解析模型输出，判断是否为工具调用指令 try: tool_call = json.loads(response_text.strip()) tool_name = tool_call.get("tool") arguments = tool_call.get("arguments", {}) if tool_name and tool_name in TOOLS: # 执行工具 tool_func = TOOLS[tool_name]["function"] print(f"[step {step + 1}] 调用工具: {tool_name}, 参数: {arguments}") result = tool_func(**arguments) print(f"[step {step + 1}] 工具返回: {result}") # 把工具执行结果加入上下文，让模型继续生成 messages.append({"role": "assistant", "content": json.dumps(tool_call, ensure_ascii=False)}) messages.append({"role": "user", "content": f"工具执行结果: {result}"}) continue except json.JSONDecodeError: # 模型输出不是 JSON，说明它直接回复了用户 pass # 模型直接回复 return response_text return "已达到最大执行步数，请优化任务或重新提问。"

这个实现有几个关键设计：

1. 循环上限：max_steps防止 Agent 无限循环，这是生产环境必须考虑的兜底策略。
2. 低温采样：工具调用场景使用temperature=0.2，降低模型输出随机性。
3. 格式抽取：通过json.loads判断模型是否返回了工具调用指令。
4. 上下文累积：每轮工具结果都拼接进messages，模型能看到之前的决策和工具返回，从而做出下一步判断。

4.5 编写入口文件并运行

创建demo.py：

from agent import run_agent if __name__ == "__main__": test_questions = [ "今天服务器时间是多少？", "帮我计算 (98 + 2) * 15 的结果", "你好，请介绍一下自己" ] for question in test_questions: print() print("=" * 50) print(f"用户提问: {question}") print("=" * 50) answer = run_agent(question) print(f"最终回答: {answer}")

运行：

python demo.py

预期输出类似（实际内容取决于模型回复）：

================================================== 用户提问: 今天服务器时间是多少？ ================================================== [step 1] 正在调用模型... [step 1] 调用工具: get_current_time, 参数: {} [step 1] 工具返回: 2025-06-18 15:30:22 [step 2] 正在调用模型... 最终回答: 当前时间是 2025-06-18 15:30:22。

看到你的 Agent 能“自己调用工具并回答用户”的那一刻，核心原理就理解了：模型负责语义理解和决策，代码负责确定性执行，两者通过格式约定完成协作。

5. Agent 开发中的常见问题与排查思路

Agent 开发的上手门槛不高，但要做到稳定可靠，会遇到大量工程问题。下面整理几个高频问题。

5.1 模型不按约定格式返回工具调用指令

这是最常遇到的问题。你要求模型输出 JSON，它偏偏输出了一段解释文字。可能原因：

• 系统提示词不够明确。
• 模型本身指令遵循能力较弱。
• temperature 设置过高，输出发散。

排查建议：

1. 先单独测试一次模型调用，打印原始返回内容，看模型到底输出了什么。
2. 在提示词中给出“必须”和“严禁”类的强约束语句：必须只输出 JSON，严禁输出解释内容。
3. 调低 temperature，建议 0.1 到 0.3。
4. 如果使用的是支持函数调用（function calling）机制的模型平台，优先使用平台原生的函数调用能力，而不是自己在 Prompt 里“手搓”格式。

5.2 Agent 执行到一半报错：execution terminated due to error

很多 Agent 框架在工具调用出错时会直接终止整个流程，错误信息形如 “agent execution terminated due to error.”。根本原因往往是工具函数抛出未捕获的异常。

在tools.py里，我们的工具函数内部已经做了try...except，但真实项目中，工具函数可能是别人写的，不一定有完备的异常处理。

排查思路：

1. 查看日志里具体的异常堆栈，定位是哪个工具抛错。
2. 给每个工具加上统一的异常捕获，工具返回错误信息给模型，而不是让异常直接中断 Agent。
3. 在 Agent 主循环中加入 fallback 逻辑：工具执行失败时，不要终止，而是把错误信息发给模型，让模型换一种方式处理。

伪代码示例：

try: result = tool_func(**arguments) except Exception as e: result = f"工具执行失败: {str(e)}，请尝试其他方式解决用户问题"

5.3 多轮对话中上下文越来越长，成本飙升

Agent 循环会把工具调用结果不断追加到上下文中。如果任务复杂、步数多，token 消耗会快速增长。

解决思路：

• 每轮只保留必要的对话片段，把历史对话做摘要。
• 工具执行结果只保留最终结论，中间过程的详细数据放到外部存储。
• 设置单次任务的 token 预算，超预算就终止。

5.4 常见问题速查表

6. Agent 开发与 MaaS 调用的最佳实践

6.1 密钥管理与权限控制

API Key 是访问 MaaS 平台的凭证，一旦泄露会带来真实的经济损失和安全风险。建议做到以下几点：

• 不要把 API Key 提交到 Git 仓库，使用环境变量或密钥管理服务。
• 遵循最小权限原则：不同环境（开发、测试、生产）使用不同的 Key，分开计量。
• 定期轮换密钥，发现疑似泄露第一时间在控制台重置。
• 如果 MaaS 平台支持子账号和角色权限，尽量使用子账号，而不是共享主账号。

6.2 工具函数的安全边界

这是整个 Agent 工程中最需要警惕的部分。模型输出的内容是“不可信输入”，你让模型决定调用哪些工具、传什么参数，就意味着模型输出直接触达你的业务系统。

下面这些工具尤其要注意：

• 执行 SQL 语句的工具：必须做白名单校验，禁止DROP、DELETE、UPDATE等高危操作。
• 执行 shell 命令的工具：默认禁止，或只在隔离沙箱中开启。
• 发送短信/邮件的工具：必须加最高频次限制和内容审核。
• 修改生产数据的工具：必须人工审批环节，不能完全自动化。

一个实用的做法是给工具划分级别：

6.3 日志、监控与可观测性

Agent 的调试比普通接口难，因为它的执行是循环式、多步的。建议从以下三个维度建立可观测性：

完整链路追踪：记录一次 Agent 任务的完整事件序列，包括每轮模型请求、模型决策、工具调用参数、工具返回结果。

日志示例：

{ "task_id": "task_123456", "step": 1, "action": "call_model", "input_tokens": 1200, "output_tokens": 80, "model_response": "{\"tool\": \"get_current_time\", \"arguments\": {}}" }

指标统计：统计每轮任务的平均步数、工具调用成功率、单任务 token 消耗、最终完成率。

效果评估：对 Agent 的回答做自动或人工评估，包括答案准确性、工具选择合理性、是否有不安全行为。

6.4 Prompt 版本化管理

Agent 的系统提示词是核心资产，改一行字都可能影响整体效果。建议像管理代码一样管理 Prompt：

• 提示词写入 Git，每次修改都有 diff 记录。
• 用配置中心管理不同环境的 Prompt 版本。
• 上线前进行 A/B 对比测试，确认新 Prompt 不劣于旧版本。

6.5 成本控制

Agent 的成本构成比普通 API 调用复杂。普通对话是一问一答，Agent 可能循环调用模型多次，还要加上工具执行成本。控制成本的主要手段：

• 给单次任务设置步数上限，防止死循环。
• 合理设计工具返回信息的长度，避免把大段数据塞进上下文。
• 使用更便宜的轻量模型处理简单决策，让强模型只处理复杂步骤。
• 对非实时场景使用异步任务队列，削峰填谷。

7. 总结与学习路线

百度智能云这次组织调整，本质上是对大模型落地路径的一次重新定位：MaaS 做好底层设施，Agent 做好上层应用。对开发者来说，这两块能力都需要掌握。

本文重点帮你理清了以下几条主线：

1. MaaS 概念：模型即服务，解决大模型接入、运维、成本、安全等基础设施问题。
2. Agent 概念：智能体从“被动回答”走向“主动执行”，工具调用是核心能力。
3. 实际调用：通过标准 HTTP 请求调用 MaaS 模型 API，并完成基本的异常处理。
4. 最小 Agent 实现：用 Python 写了一个具象的 Agent 主循环，理解了模型决策 + 工具执行的协作模式。
5. 工程落地要点：安全边界、日志监控、成本控制、Prompt 管理等生产环境绕不开的话题。

下一步的学习路线，可以按这个顺序推进：

• 熟悉你所在公司或你选型指定的 MaaS 平台控制台，把 API 调用跑通。
• 学习平台自带的 Agent 编排工具，先用低代码方式搭建一个简单的智能体应用。
• 再回到代码层面，选择一个成熟的 Agent 框架（例如 LangChain、LlamaIndex，或国内各家云厂商的 Agent 开发框架），深入理解它对工具调用、记忆、上下文管理的封装方式。
• 读一读框架源码中关于“模型工具调用协议”的实现，会让你对 Agent 的理解上一个台阶。

实际项目中，我建议优先关注“安全”和“成本”这两个风险点。Agent 的魅力在于它能自主行动，风险也恰恰在于自主行动失控。先让 Agent 在只读、低风险的场景里跑通，验证效果后再逐步放开写操作权限，这是比较稳妥的落地路径。

如果你正在做 Agent 相关项目，建议从最小的一个工具、一个场景开始，先跑通端到端链路，再逐步增加复杂度。模型的能力迭代很快，但工程化的稳定性、安全边界和评估体系，才是真正决定一个 Agent 能不能上线的关键。