企业官网建设流程全解析

Muse 智能体摆脱了：只聊天不做事

一、全文速览图

2026 年还剩 100 天不到，AI 圈依然维持着你方唱罢我登场的节奏。最近，一款叫 Muse 的应用又登上了主舞台。

Muse 是 Meta 刚刚推出不久的个人 AI 智能体应用，正式上线 5 天下载量就超过 73 万，两周迅速登顶美国 App Store 和 Google Play 榜首（目前它只在美国可用），连带着 Meta 也一改之前低迷的现状，好评如潮，股价大涨。

它的出现，让我感觉 AI 来临后被反复被提到的 “个人助理” 概念又鲜活了起来，于是从 UX 的角度对它做了些研究。

这个只会做选择题的Jev，却是今年我觉得最特别的AI大模型！

全文速览图 这两天，如果说最火的大模型是什么，那可能只有一个名字。

阅读文章 >

二、产品定位：一个联系人

Muse 最让我觉得有意思的是，它在试图建立一种新的 Agent 协作关系：

1. 可以主动联系用户
2. 用 “目标” 的概念承载工作
3. 拥有持续记忆
4. 判断什么时候值得打扰用户
5. 通过审批和活动记录建立信任

大概因为他的定位是个人生活 Agent，所以整个产品在探索的是一种新的关系型体验，而不是单纯提升办公效率。

它不从 “帮你写一篇文章”“制作一个网页” 开始，而是切入那些最消耗普通人精力、又最容易被拖延的生活细节：邮件、日历、预约、账单、购物、出行、家庭计划、长期习惯。

Muse 的设计师说他们希望创建的是一个主动式、能够理解更多背景信息、功能强大到可以自主生成用户体验的模型。

所以，他们着重设计了：

1. 主聊天室中的长时间对话体验
2. 让一条真正有用的消息，在你未发出指令的情况下发送
3. Muse 的头像和个性

相比起之前那些帮我们完成任务的 Agent：Codex、Claude、豆包工作……Muse 更像一个进入私人生活的数字代理人。

三、UX 机制：一个 “长期关系” 的交互框架

虽然 Muse 的界面结构沿用了聊天框，但围绕 “关系型体验”，它搭建了一套支撑长期关系的结构：

Main Chat：长期主对话 用户可以连续发送多个任务，也可以在 Agent 未完成上一件事时继续补充新要求。聊天不再是回合制问答，而是持续协作的沟通。 就像与一个真正的人交谈。

Goals：可追踪的长期目标 当用户说 “我想开始健身”“帮我准备孩子开学” 时，系统不能只回一张计划表，而要持续管理目标、拆解步骤，并在合适的时机调整计划。

Activity：让后台执行变得可见 Agent 能在后台工作，是便利，也是焦虑来源。Muse 展示了后台任务的工作摘要，并提供完整活动记录，让用户知道它做了什么、接下来准备做什么。

Approval：对不可逆操作使用确定性界面 发送邮件、购买商品、分享信息等动作，不能只靠一句模糊对话完成。Muse 使用清晰的批准 / 拒绝卡片，把风险动作从自然语言里 “拎出来”，要求用户明确决策。

Artifacts：让结果摆脱 “长长的聊天文本” 行程适合用 itinerary，花销适合用 dashboard，计划适合用清单或卡片。AI 的输出没有局限于一段文字，而是最适合任务的界面。

四、设计师的任务：在 AI 发展的过程中，需要我们做什么？

Muse 让我意识到，未来 Agent 产品最难的，可能不是再多接入一个能力、再多完成一项任务，而是一段 “人如何委托、AI 如何执行、风险如何被控制、结果如何被验收” 的关系。

恰好，在研究 Muse 之前，我刚看到马斯克在央视财经专访中谈到对机器人的看法。

他说，未来的丰裕或许会超过人的消费能力，机器人将 “饱和式地” 满足人类需求，甚至能做更多事情。

无论这个预测最终以怎样的速度实现，它都指向一个值得提前思考的问题：

在这个过程中，需要设计师做什么？

我觉得，至少有 5 件事是重要且不可缺失的：

1. 定义真正的问题：不要急着说 “帮我做 PPT”，先说清楚这份 PPT 要帮谁做什么决策。
2. 表达目标与成功标准：什么叫做好？是速度、预算、品质、风险控制，还是情绪体验？
3. 给出边界与约束：哪些事它可以自行决定，哪些必须问我？哪些信息不能碰？
4. 提供必要上下文：用户偏好、已有资料、历史选择、现实限制，决定了答案是否真正 “属于我”。
5. 判断并校正结果：AI 可以提供十种方案，但 “哪一种更对” 仍需要审美、常识、价值判断与责任感。

我们不仅需要理解用户真正想完成什么；哪些环节值得自动化；AI 应该拥有什么权限；在哪一步必须停下来问人；当 AI 失败、误解或过度行动时，用户如何接管、恢复与追责。还要具备能够把这些答案，通过界面、流程、框架，结构组织，翻译成可以供用户使用的产品的能力。

这依旧是设计，只是设计对象从 “一个界面” 扩展成了一段人和 Agent 共同完成事情的关系。

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 协作，是未来核心能力