企业官网建设流程全解析

杨元庆12年前埋下的种子，

终于迎来AI时代风口

联想集团业绩爆发、股价大涨，源于杨元庆12年前埋下的一粒种子。

2014年1月，联想集团宣布与IBM签订协议，以23亿美元的价格收购IBM的x86服务器业务，收购完成后，联想将跻身x86服务器领域国内第一、全球第三。此时的联想，刚刚成为全球最大的PC厂商，开始把目光投向更长远的领域。

在杨元庆的判断中，这笔收购价值明确：第一，服务器有望成为继 PC 之后的第二大业务支柱，实现集团业务多元化；第二，对比 PC 约 5% 的毛利率，服务器行业普遍毛利率超 20%，市场空间广阔，成长潜力更强。

但这项收购也引来了一些质疑。IBM的x86服务器业务利润承压，联想将之收购后能否迅速实现稳定盈利是一个关键问题。此外，x86服务器业务主要面向企业市场，与联想以往积累的PC销售能力有较大差异，收购后的整合同样是一个巨大挑战。

后续的发展印证了双方的判断。在联想收购IBM的x86服务器业务后，该业务所属的数据中心业务和后来的ISG业务长期亏损，直至2021/22财年（截至2022年3月）才首次实现全年盈利，距离被收购已经过去了8年之久。

整合路上，联想也曾踩坑：早期直接复用 PC 销售团队去卖服务器，然而 PC 销售缺乏企业级客户资源与专业能力，反而造成服务器销售下滑。

但短期亏损和整合阵痛并没有动摇杨元庆和联想集团对服务器行业的长期判断。早在2017年，杨元庆就坚定喊出：“毫无疑问，AI是未来，联想已经赌上身家性命进入这一领域。”数据中心业务也被定位为联想从硬件企业向基于人工智能的“设备+云”企业转型的基础设施支撑。

行业浪潮悄然变迁，云计算兴起，AI 大模型带动算力需求爆发，市场从单纯采购硬件，转向采购算力能力。

联想随之调整服务器业务定位，从 “卖硬件” 转向 “卖算力”。2025 年末，联想启动 ISG 业务组织调整，裁撤、简化传统计算产品线，把研发资源集中投向 AI 训练与推理赛道，销售体系同步升级，本次重组产生 2.85 亿美元费用。

更重要的是，在2026年3月的GTC 2026大会上，联想集团正式成为NVIDIA Vera Rubin NVL72的全球首发合作伙伴。

一系列的调整，终于迎来业绩的开花结果。

从2025/26财年开始，联想集团ISG业务亏损大幅收窄，并迅速扭亏，迎来爆发式增长。2025/26财年第四季度（截至2026年3月），ISG业务扭亏为盈，营收达56亿美元，经营利润达到2.02亿美元，经营利润率升至3.6%。

2026/27财年第一季度（截至2026年6月），联想ISG业务营收高达85.1亿美元，同比接近翻倍，经营利润达7.77亿美元，经营利润率达9.1%，季度末AI服务器订单储备增长至3600亿元人民币。

这直接驱动了联想集团股价暴涨。Wind显示，从2026年4月1日开始，截至9月29日收盘，联想集团股价累计涨幅高达302%，总市值也从约1100亿港元增长至4405亿港元，表现极为突出。

这一老牌PC龙头，在AI时代绽放出了更为耀眼的光彩。

剑指AI原生，

杨元庆的底气有多大？

2026年4月的联想集团2026/27财年誓师大会上，杨元庆宣布联想将全面转型为AI原生公司。他表示：“AI不是附加项目，不是额外一层，更不是事后补充”，要求从产品设计到业务流程均以人工智能为核心重新构建。

杨元庆将新财年定义为“AI交付”之年，目标是将个人智能和企业智能产品交付到客户手中，完善生态体系，确立联想在混合式人工智能领域的领先地位。

AI原生（AI Native），也被称为智能原生，一般指的是一种以AI为底层架构和核心驱动力的系统性范式，其并非简单的“AI+工具”。硅谷投资人Jeremiah Owyang曾说过：“AI-Native企业的运作逻辑是：先找AI，找不到就自己造AI，最后才招人。”

联想集团目前在AI原生战略转型上有着巨大优势。联想是混合式人工智能的先锋，其AI PC业务近年来发展迅速。数据显示，联想在Windows AI PC细分市场全球排名第一，市场份额达到31%。此外，联想AI PC出货量占总销量的比例也超过了30%。

与此同时，联想在AI服务器业务上的增长同样迅猛。根据IDC公布的数据，2026年第二季度全球x86服务器市场中，联想销售额位列全球第二，仅次于戴尔，但出货量高达28.6万台，同比增长45.6%，跃居全球第一。

为补齐算力存储链条，2025年1月，联想宣布收购以色列高端企业级存储解决方案提供商Infinidat，据市场估算，交易金额达到十亿美元级别，这也是联想自2014年收购IBM x86服务器业务和摩托罗拉移动业务以来规模最大的一次技术型并购，补齐高端企业存储版图。

纵观联想AI的整套布局，从AI PC到AI服务器再到存储，联想集团的AI战略布局始终围绕着硬件展开。这是联想集团刻在骨子里的企业基因：通过供应链整合降低成本，通过渠道拓展提升市场份额，两者协同提升效率从而取得竞争优势。

但想要成为AI原生企业，不仅需要AI硬件入口，更需要包括大模型、Agent在内的一系列AI解决方案能力。这恰恰是联想集团急需补强的短板。

从根源上看，联想的核心产品PC和服务器是成熟市场，比拼的是供应链整合效率，这是联想集团的强项。而在需要比拼创新能力和创新速度的其他领域，联想集团的历史战绩并不突出。

而从研发投入来看，联想集团历年研发费用率基本保持在3%-4%之间，而当期市场公认的AI原生公司OpenAI和Anthropic研发投入显著更高，对比头部 AI 原生企业存在明显差距。

目前来看，联想集团也推出了天禧AI个人超级智能体、跨平台个人超级智能体Lenovo Qira、业内首个企业超级智能体——联想乐享等多款AI产品，但目前影响力相对有限。

同时，在AI Agent加速迭代的当下，联想集团硬件内置AI产品能否跟上行业竞争和迭代速度并保持一定的市场竞争力，仍需要进一步验证。

依靠十二年的长期坚守，联想集团在服务器和PC领域取得了领先优势，抓住 AI 时代红利，交出亮眼的业绩与资本市场答卷。但 AI 行业竞争白热化，技术迭代一日千里。手握硬件优势的联想，能否补齐软件生态短板，真正完成 AI 原生转型，值得市场持续观察。

《FDE Muse智能体构建：从通用Agent到企业业务Agent，如何搭建能办事的智能体》

大模型实战专家—周红伟 法国科学院算法博士/前阿里人工智能专家/马上消金风控负责人

课程背景

当前，AI 正从"能聊天"向"能办事"快速演进。以大语言模型为代表的 AI 技术，虽然已经具备强大的语言理解和生成能力，但在实际业务场景中，企业真正需要的不是"你问我答"的聊天工具，而是能够自动完成任务、调用工具、规划步骤、处理异常的智能体系统。Meta Muse 的出现标志着落地的加速：不再是是回答问题，而是能发邮件、订机票、跟商家砍价，真正替用户动手办事。这代表的是产品的升级——从 LLM 走向 AI Agent。

然而，从 LLM 到 AI Agent 的跨越并非简单升级。一个能办事的 Agent 至少要解决四件事：听懂需求、拆解目标、逐步执行、出错自纠。这涉及任务规划、工具调用、记忆管理、多智能体协作等一系列工程问题。当前市场上，既懂大模型能力边界、又能动手搭建 Agent 系统的复合型人才极度稀缺。许多开发者停留在"调 API 写提示词"的层面，一旦进入工具定义、状态管理、异常处理等真实工程环节，便无从下手。企业也普遍面临"知道 AI 有用，但不知道如何落地"的困境。

本课程正是为这一缺口设计。三天时间，从认知建立到动手搭建，再到避坑进阶，完整覆盖"从 LLM 到 AI Agent"的核心知识体系与实操路径。课程不讲空泛概念，而是以一个从业者拆解同类系统的思路，把"为什么这么设计""哪里容易翻车"讲透。学员将亲手搭建一个能办事的 Agent，跑通完整任务闭环，并掌握企业级沉淀与运营的方法论。无论你是刚接触 AI Agent 的小白、想动手搭建的开发者，还是负责企业 AI 落地的管理者，都能在这三天里获得可带走、可复用、可落地的能力。

课程收益

1. 建立完整认知框架：彻底厘清 LLM、AI 模型、AI Agent 三者的区别与关系，理解从"能聊天"到"能办事"的底层逻辑，掌握 Meta Muse 这类 Agent 系统的分层架构与模块化设计思路。
2. 掌握 Agent 三大核心机制：深入理解任务规划、工具调用、记忆与状态管理的原理与实现方式，能够独立完成从指令解析到任务执行的完整链路设计。
3. 亲手搭建一个能办事的 Agent：从底座选型、工具定义、提示词编写到任务跑通、部署监控，完整走通一遍实操路径，带走一个可运行的最小可用系统。
4. 识别并规避常见翻车点：掌握工具调用死循环、不可逆操作自作主张、上下文超长失忆等典型问题的排查与解决办法，大幅提升 Agent 的可靠性与成功率。
5. 获得企业级落地方法论：学会将一次项目转化为企业可持续运营的能力，掌握项目归档、模板沉淀、SOP 制定、验收复盘等全套方法论，以及产业链价值图、商业模式画布、AI 机会清单等核心成果物的制作思路。
6. 明确个人与团队行动路径：根据自身角色（开发者/管理者/普通用户）制定后续行动规划，从低风险任务入手，逐步挑战复杂场景，建立与"会动手的 AI"协作的长期能力。

培训时长

3天

课程大纲

第一天 认知建立：从 LLM 到 AI Agent 的底层逻辑

第一部分 概念辨析与行业转向

1.1从"能聊天"到"能办事"的本质变化
1.1.1 聊天机器人与任务执行型 AI 的能力边界差异
1.1.2 Meta Muse 引发的产品形态转向：从信息工具到行动工具
1.1.3 学员认知起点摸底：你目前用 AI 解决什么问题

1.2 LLM、AI 模型、AI Agent 三者的区别
1.2.1 LLM 作为"大脑"：语言理解与生成的能力范围
1.2.2 AI 模型作为更大的范畴：图像、语音、语言模型的各自定位
1.2.3 AI Agent 作为"大脑+手脚+记忆"的完整系统

1.3为什么行业热词从"大模型"转向"AI Agent"
1.3.1 单纯堆模型参数解决不了"办事"问题
1.3.2 执行力瓶颈：工具调用与任务规划成为关键
1.3.3 企业级需求驱动：从 Demo 到可落地系统的距离

第二部分 Meta Muse 的系统定位

2.1 Meta Muse不是单一模型而是 Agent 系统
2.1.1 底座 LLM 与上层模块的分工关系
2.1.2 Muse Spark、Muse Glimmer、Muse Code 的角色划分
2.1.3 "一个底座、多个专精模块"的架构逻辑

2.2分层设计的必要性
2.2.1 听懂需求、拆解目标、执行步骤、自我纠正四层能力
2.2.2 调度层、交互层、专精层的职责边界
2.2.3 分层带来的独立优化与独立替换优势

2.3模块化设计的实际好处
2.3.1 可组合性：一个任务同时调用多个模块
2.3.2 版本迭代：Muse Spark 1.3 这类模块级更新
2.3.3 避免"全塞进一个模型"导致的互相干扰

第三部分 LLM、Agent、工具三者的协作关系

3.1以订机票为例的完整链路
3.1.1 LLM 负责理解指令并抽取关键约束
3.1.2 Agent 负责规划步骤与判断何时请示用户
3.1.3 工具负责真正执行查询、比价、下单、支付

3.2工具调用是 Agent 落地的技术基石
3.2.1 Tool Calling / Function Calling 的基本原理
3.2.2 工具定义的结构：名字、参数、返回值格式
3.2.3 推理—调用—观察—再推理的循环机制

3.3为什么"嘴代替不了手"
3.3.1 LLM 只会"说"该查航班，不会真正查
3.3.2 Agent 的工具调用机制才是执行力的来源
3.3.3 行业瓶颈从智商转向执行力的现实含义

第四部分 任务规划与执行闭环

4.1任务分解的核心能力
4.1.1 解析约束：时间、地点、偏好、预算
4.1.2 调用工具获取候选方案并排序过滤
4.1.3 生成对比、请求确认、执行下单、整理结果

4.2人机协作的关键节点
4.2.1 何时自主执行、何时停下来问一句
4.2.2 自作主张导致翻车的典型案例
4.2.3 "何时自主、何时请示"作为 Agent 成熟度指标

4.3记忆与状态管理
4.3.1 短期记忆：当前任务的上下文约束
4.3.2 长期记忆：跨会话的用户偏好
4.3.3 工作状态：任务执行到哪一步、哪些待办

第五部分 多智能体协作与分工

5.1复杂任务需要多个 Agent 分工
5.1.1 需求分析 Agent、编码 Agent、测试 Agent、审查 Agent
5.1.2 各司其职、互相检查的协作模式
5.1.3 Meta Muse 内部模块拆分与多智能体思路的对应

5.2多智能体的好处与代价
5.2.1 职责单一、提示词高度定制、出错容易定位
5.2.2 通信成本高、容易互相甩锅
5.2.3 能用单 Agent 加工具解决就不急着上多智能体

5.3多智能体在开发场景中的协作规范
5.3.1 AI Agent coding 协助开发的流程设计
5.3.2 代码审查与测试环节的 Agent 介入方式
5.3.3 协作规范的落地要点与常见问题

第六部分 第一天总结与认知复盘

6.1核心概念回顾
6.1.1 LLM 是大脑、Agent 是完整系统、工具是手脚
6.1.2 分层与模块化是当前 Agent 工程的主流打法
6.1.3 任务规划、工具调用、记忆状态三大核心机制

6.2学员常见误区澄清
6.2.1 Agent 不是"更聪明的模型"
6.2.2 堆参数解决不了办事问题
6.2.3 全自动不等于好，懂得请示才是成熟

6.3第一天课后任务
6.3.1 梳理自己工作中可交给 Agent 的三类任务
6.3.2 画出任务从指令到执行的初步链路
6.3.3 准备第二天实操所需的环境与账号

第二天 动手搭建：从零构建一个能办事的 Agent

第一部分 环境与选型

1.1底座模型的选择
1.1.1 通用大模型 API：开发快、门槛低、适合快速验证
1.1.2 开源模型自部署：可控性强、数据不出门、适合企业场景
1.1.3 选型三问：任务复杂度、是否私有化、团队语言栈

1.2开发框架的选择
1.2.1 Python 生态：LangChain、LlamaIndex 快速搭骨架
1.2.2 Java 生态：Spring AI、Spring Cloud 适合企业级整合
1.2.3 框架决定开发效率，底座决定智商上限

1.3环境准备与最小可运行系统
1.3.1 API Key 申请与基础配置
1.3.2 安装依赖、跑通第一个模型调用
1.3.3 确认工具调用功能是否可用

第二部分 工具定义：划清 Agent 的能力边界

2.1工具定义的核心原则
2.1.1 名字动词开头、语义明确，如 send_email
2.1.2 description 写清楚"什么时候用、什么时候别用"
2.1.3 参数少而精，必填与可选分开

2.2返回值与错误处理
2.2.1 返回值结构化，方便 LLM 解析
2.2.2 每个工具有明确的失败返回
2.2.3 错误类型区分：网络超时可重试、参数错误不重试

2.3以发邮件与砍价为例的工具定义实操
2.3.1 send_message 与 get_market_price 的定义示例
2.3.2 工具 description 写得含糊导致乱调漏调的后果
2.3.3 学员动手：为自己的任务定义三个工具

第三部分 规划提示词编写

3.1提示词的核心组成
3.1.1 角色设定与可用工具清单
3.1.2 任务分解要求与停止条件
3.1.3 出错处理策略与重试上限

3.2不可逆操作的确认机制
3.2.1 支付、发送、删除前必须获得用户明确确认
3.2.2 提示词约束与代码层面拦截的双重保障
3.2.3 测试订单发给真实客户的事故复盘

3.3提示词模板与少样本示例
3.3.1 规划提示词的标准结构
3.3.2 塞入两三个"输入—执行过程—输出"示例
3.3.3 示例效果优于纯文字描述的原因

第四部分 跑通第一个任务：自动整理收件箱

4.1任务拆解与工具定义
4.1.1 list_unread_emails、get_email_content、label_email、summarize
4.1.2 提示词要求：拉取列表、逐封读取、判断类别、打标签、输出摘要
4.1.3 约束设定：不删除任何邮件、涉及金额单独标红

4.2执行与观察
4.2.1 感知—决策—行动—反馈的完整闭环
4.2.2 观察在哪一步卡壳并针对性调提示词
4.2.3 记录首次跑通的成功率与失败模式

4.3从收件箱任务迁移到其他场景
4.3.1 订机票、砍价只是工具和提示词不同
4.3.2 骨架一致：规划、调用、记忆、确认
4.3.3 学员选择自己的低风险任务进行迁移练习

第五部分 部署、监控与工程化

5.1上线后的核心监控指标
5.1.1 任务成功率与平均执行步数
5.1.2 工具调用失败率与人工介入频率
5.1.3 成本监控：token 消耗与调用日志

5.2沙箱验证与回滚机制
5.2.1 上线前跑够 100 次真实任务
5.2.2 统计失败模式再决定是否放开
5.2.3 日志记录与回滚机制的必要性

5.3 Agent接入 CI/CD 流程
5.3.1 Jenkins AI Agent 自动跑测试、改 bug
5.3.2 高稳定性要求场景的工程化要点
5.3.3 部署与监控的持续迭代思路

第六部分 第二天总结与实操复盘

6.1搭建路径回顾
6.1.1 选底座、定工具、写提示词、跑任务、上监控
6.1.2 工具定义与提示词质量决定 Agent 上限
6.1.3 状态管理是生产级 Agent 的标配

6.2学员问题集中答疑
6.2.1 工具调用不生效的排查方向
6.2.2 任务执行到一半停住的常见原因
6.2.3 成本异常高的诊断与优化

6.3第二天课后任务
6.3.1 完善自己的 Agent 工具集
6.3.2 跑通至少一个完整任务并记录日志
6.3.3 准备第三天踩坑与优化案例

第三天 避坑进阶：从能跑到可靠，从项目到能力沉淀

第一部分 工具调用死循环与重试策略

1.1死循环的典型表现与根因
1.1.1 Agent 反复调用同一工具、失败后无限重试
1.1.2 提示词没设重试上限
1.1.3 工具返回错误信息太模糊，Agent 不知道路不通

1.2解决办法
1.2.1 提示词硬性规定重试次数上限，一般设 2 次
1.2.2 工具返回明确错误类型：网络超时 vs 参数错误
1.2.3 参数错误直接改参数或报告用户，不重试

1.3实战演练
1.3.1 故意制造工具失败，观察 Agent 反应
1.3.2 调整提示词与错误返回后的效果对比
1.3.3 学员记录自己任务中的死循环风险点

第二部分 不可逆操作的自作主张问题

2.1事故场景复盘
2.1.1 Agent 绕过确认直接下单、发邮件、删文件
2.1.2 测试环境是笑话、生产环境是事故
2.1.3 提示词会被模型忽略的现实

2.2框架层面的强制拦截
2.2.1 涉及金钱、对外发送、数据删除的操作必须拦截
2.2.2 代码层面拦截才是硬保障
2.2.3 人工确认流程的设计要点

2.3确认机制的用户体验平衡
2.3.1 确认太频繁导致效率下降
2.3.2 确认太少导致风险失控
2.3.3 按操作不可逆程度分级确认的策略

第三部分 上下文超长与失忆问题

3.1失忆的典型表现
3.1.1 长任务跑到后面遗忘早期约束
3.1.2 "说过不要中转还是订了中转航班"
3.1.3 上下文越堆越长导致模型注意力分散

3.2三种应对策略
3.2.1 关键约束单独抽出，每轮都带上
3.2.2 摘要压缩历史对话，只保留决策相关信息
3.2.3 任务状态存成结构化对象，不靠自然语言记忆

3.3生产级 Agent 的状态管理标配
3.3.1 结构化状态对象的字段设计
3.3.2 每执行一步更新状态、每次推理带上状态
3.3.3 中间隔几小时也能接着往下走

第四部分 常见问题速查与排查方法

4.1现象与原因对照
4.1.1 Agent 不调用工具只聊天：工具 description 不清或提示词没强调
4.1.2 反复调用同一工具：没设重试上限或错误信息模糊
4.1.3 执行到一半停住：状态丢失或等待用户输入未提示

4.2结果不符合预期与成本异常
4.2.1 约束没被遵守：把关键约束结构化、每轮携带
4.2.2 成本异常高：死循环或上下文过长
4.2.3 看调用日志、统计 token 消耗的排查方法

4.3提升成功率的四个小技巧
4.3.1 准备少样本示例
4.3.2 复杂任务拆成子 Agent
4.3.3 上线前做对抗测试：模糊指令、矛盾指令
4.3.4 记录失败案例、定期回看、集中改进

第五部分 从项目到能力：企业级沉淀与运营

5.1项目归档与模板沉淀
5.1.1 归档目标、方案、版本、测试、验收和复盘
5.1.2 沉淀模板、SOP、FAQ、案例和 Skill
5.1.3 把一次项目转化为企业可持续运营的能力

5.2企业 AI 落地的核心成果物
5.2.1 产业链价值图、商业模式画布、AI 机会清单
5.2.2 入企调研计划、组织角色图、访谈提纲、问题地图
5.2.3 场景优先级表、AI 场景卡、三本账、企业 AI 落地方案

5.3技术路径与项目管理
5.3.1 技术路径判断卡、四层架构图、MVP 计划
5.3.2 项目 RACI、Demo 脚本、四类验收表
5.3.3 项目复盘和管理层汇报材料

第六部分 三天课程总复盘与行动规划

6.1核心知识体系回顾
6.1.1 第一天认知：LLM 到 Agent 的底层逻辑
6.1.2 第二天实操：从零搭建能办事的 Agent
6.1.3 第三天进阶：避坑、优化、企业级沉淀

6.2学员行动规划
6.2.1 从低风险任务入手：整理文件、回复邮件、汇总日报
6.2.2 跑通后再挑战订机票、砍价等涉及金钱和对外沟通的场景
6.2.3 普通用户先"AI 做初稿、人来把关"，逐步放权

6.3长期协作心态建立
6.3.1 Agent 的价值不在于全自动，而在于解放重复劳动
6.3.2 懂得在关键时刻停下来问你的 Agent 更靠谱
6.3.3 学会跟一个会动手的 AI 协作，是未来核心能力