精缩版：

1. 场景抽象：日常工作内容的80%可以抽象为几类高频场景，针对每类场景的目标、挑战，可以形成有效的解决方案。详见：第一章。

2. Prompt插拔架构：Prompt是给LLM运行的“代码”，Prompt设计就是“架构设计”。详见：第三章。

3. 平台实践：基于“解决方案模板+Prompt框架+业务定制扩展”的技术方案，我们打造了“一键式”创建AI助手的平台：智空间。详见：第四章。

引言：重复“造轮子”的困境？

当每个业务场景都需要一个AI助手时，我们似乎陷入了一个熟悉的循环：接到需求、从零开始、打造助手、交付上线。从金融答疑到系统排查，从联调造数到VIP演练，每个团队都在各自的业务场景中重复着相似的开发流程，这种模式看似务实，实则暗藏巨大的效率陷阱。

开发一个中等复杂度的AI助手，动辄需要几周，其中超过60%的工时消耗在流程编排、Prompt调优、工具集成和效果验证等高度重复的工作上。

更可怕的是，这些倾注心血打造的助手，绝大部分如同“高级定制款”，从需求对接到Prompt调优，从工具集成到效果验证，每个都是信息孤岛，彼此之间几乎无复用性可言。这像是AI界的“作坊式”生产模式——看似“遍地开花”，但大部分精力消耗在了低水平重复上。

破局之道：以上困境的根因，在于我们每一次都聚焦于具体的、差异化的场景本身。唯有通过深入分析，归纳出场景的共性与差异性，并沉淀为技术化的解决方案，我们才能从“AI作坊”迈向“智能工厂”。

第一部分：场景抽象——四大高频场景类型

按照第一性原理，我们对日常工作进行了“贴身观察”和行为分析，发现虽然工作内容五花八门，但近80%的任务可被归为四大类：复杂指令执行、知识问答、问题排查、常规碎片化场景（coding作为单独课题，不在此列）。

1.1 四大高频场景的本质分析

复杂指令

本质：不是简单聊天，而是“工具海选 + 链路规划 + 安全执行”的复杂决策过程。

案例：用户一句“给我弄张优惠券”，AI需自动完成“身份验证→查询用户状态→寻找可用券模板→调用发券接口→返回结果”等一系列精密操作。

技术挑战：指令的精准拆解、海量工具的智能召回、工具链的合理推导，以及复杂场景的理解和安全边界控制。

知识问答

本质：不止是关键词匹配，而是“图文召回 + 多语义理解 + 知识保鲜”的综合能力。

案例：用户可能文绉绉地问“如何创建迭代”，也可能直接甩一张报错截图问“这啥意思？”。

技术挑战：实现文本生成和图片召回的协同，以及在多轮对话中保持知识的鲜活性，避免“鱼的记忆”。

问题排查

本质：从“表象”到“根因”的RCA过程，是“工具调用与人工经验融合”的层层推理。

案例：用户说“优惠券用不了”，AI需像侦探一样追问、查证：“什么时候用的？什么错误提示？我查一下你的账号状态...哦，发现是账号被风控了”。

技术挑战：准确理解问题本质，通过试错（排除法）定位问题——精确使用工具并根据结果决策下一步，最后把系统异常转译成人类语言。

常规场景

本质：“极简接入 + 能力复用”。一些简单场景没必要复杂流程，直接复用平台的基础能力最快最经济。

技术挑战：场景简单但多样，关键在于精准的问题定义、Prompt调优和快速试错，并极致降低接入与运维成本。

1.2 跨越场景的共性挑战

在深入这些场景时，我们发现了一些共性的难题：

• Query表达多样化：用户的问题从来都不标准，同一个意思有N种说法，还经常信息不全。
• Query多模态化：现在用户越来越喜欢图文混问，一张截图配几句话成了标配。
• 工具描述不清晰：各个工具的描述质量参差不齐，功能还有重合，让AI很难选择。
• 安全与权限问题：AI不能瞎操作，特别是涉及数据修改时，权限控制是生命线。

1.3 场景归类&方案：

基于上述分析，我们为每一类场景设定了明确的目标，并设计了针对性的解决方案。

至此，我们完成了从“具体场景”到“抽象类型”的理论跨越。接下来，是如何将这些抽象方案，转化为稳定、高效、可复用的系统。

第二部分：技术破局——四套解决方案

整体架构：一个分层解耦的架构设计。

整体架构设计图

架构解读：

• 解决方案层：固化了四大场景的差异化流程，包含多个Agent和工程化节点。
• 核心能力层：包含了推理、执行、知识、工具、安全五大能力域，每个域拆分为多个组件化的功能模块（如工具推理、反思推理）。
• 设计精髓：解决方案可以像搭积木一样，自由选用核心层的功能模块。例如，复杂指令方案使用工具推理，问题排查方案则使用反思推理。

下面，我们重点介绍解决方案层的设计。

1. 复杂指令场景方案

目标：根据用户指令，在海量工具中找到并规划工具链，达成任务。

1.1 方案：

核心流程：

1. 预处理

2. 意图识别

3. 意图处理

4. 工具召回（过滤引擎）

5. 推理执行

6. 总结&返回

复杂指令执行架构设计：

复杂指令架构图

预处理模负责块识别和处理多模态、快速响应内嵌式命令（能不用LLM就不用LLM）；意图处理，负责了意图路由、定制化意图处理、定制化流量处理等功能；总结&召回模块负责分析结果、组装语言返回用户。

意图识别、工具召回、推理执行三个节点，顾名思义，其功能一目了然，但实现方案确颇具挑战，其背后是面向用户语言和诉求的多样化、工具描述和功能的多样化，以及诉求粒度和功能粒度的断层。

1.2. 意图识别——把“人话”翻译成标准模型

我们设计了 IntentResult模型，这是一个结构化的意图理解框架。它把用户的一句“人话”翻译成机器能精准执行的标准模型。

以“给用户1234发放一张满50减20的优惠券，预发环境”为例，我们的模型会解析出：

• 谁：一般是我，不用解析
• 什么地点：预发环境
• 什么条件：未提供
• 关联方是谁：用户1234
• 做什么：发放
• 对象是什么：满50减20的优惠券
• 什么时间：现在

这个模型的优点在于，它不仅能理解单一意图，还能处理复杂的多意图指令，甚至能识别出用户的“负向约束”（即用户不希望发生的事情）、背景说明等辅助信息。

1.3. 工具召回——从“海选”到“精准匹配”

如何在调用大模型前，精准的从海量工具中筛选出少量的候选工具？这是一个业界的痛点。我们自主研发了 FSWW算法（Fused Subspace with Word Weights），通过工程化计算的方式，有效的解决了海量工具预选的难题。

FSWW算法是使用IntentResult模型（用户意图）匹配工具池中的ToolEssentialModel（自定义统一工具模型），获取最佳匹配的候选工具。算法的核心思想是：在保留用户原始意图语义的基础上，为关键动作和对象赋予更高的权重。比如对于“发放优惠券”这个指令，算法会让“发放”和“优惠券”这两个关键词在语义匹配中占据主导地位，同时又不完全忽略其他词语的语义信息。

原创论文：https://arxiv.org/abs/2511.19483

1.4. 推理执行——逆向思维

核心功能：详细制定“逆向推理、正向执行”的算法描述，给到LLM，生成可行的工具链条，并通过MCP协议调用工具，拿到结果。

具体流程如下：

1. 目标工具筛选：从发券这个目标出发，找到能完成发券的工具A

2. 依赖分析：发现工具A需要用户ID作为输入，但当前指令没提供

3. 上游追溯：找到能查询用户ID的工具B

4. 形成工具链：工具B（查询用户ID）→ 工具A（发放优惠券）

除此之外，这个过程中内置了四重安全校验：

• 环境校验：确保工具在当前环境（预发/线上）可用
• 读写类型校验：严格控制影响面，查询类意图绝不用写类工具
• 功能匹配校验：确保工具能力与目标一致
• 权限与影响面校验：验证用户权限，防止越权操作

2. 知识问答场景方案

目标：根据用户问题，在海量信息中，找到图文信息，生成知识，解决问题。

核心痛点：生成文本知识的同时，召回相关图片（无臆造）。

2.1 方案：

方案主要包括了两部分：推理流程和知识构建流程。方案的核心，解决两个问题：第一、是回答用户问题时，采用文生成+图召回的模式；第二、是在问答场景中，精准应对用户的多轮对话。

推理流程：

1. 预处理

2. query改写

3. 知识汰换

4. 上下文生成

5. 答案生成

6. 图片填充

知识问答架构设计：

知识问答架构图

知识构建流程

知识构建架构图

我们知道产技类文档中，纯文本基本不存在，大量的知识是以架构图、流程图、时序图等形式存在。

图文RAG创新：让AI“看懂”图片，我们的解决方案是图文嵌入模式。在知识构建阶段，当系统解析文档时：

• 文本内容被拆分成逻辑连贯的文本块；
• 图片则通过专门的图像解析Agent进行理解，生成结构化的语义摘要；
• 关键的一步：把图片摘要回填到对应的文本上下文中，形成图文关联的知识块；
• 最后，文本和图片分别进行向量化，但在语义层面保持关联。

这样，当用户提问时，系统不仅能召回相关的文本知识，还能同步召回相关的配图。比如用户问“如何配置网关路由”，AI在给出文字说明的同时，还能把配置页面的截图一并返回。

2.2. 答疑效果（文生成、图召回）：

2.3. 多轮对话应对 -- 知识块选择和汰换

在知识问答的场景中，用户往往存在多轮交互，而在此多轮交互中往往存在意图延续、意图跳转、意图回跳（意图跳转后，又会跳回到原始问题）等情况，需要做出不同的应对：

• 话题延续时，必须保留历史轮次中的关键信息；
• 话题切换时，需要快速引入新知识，避免历史信息干扰当前判断。

多轮对话流程图

我们的解决方案是动态知识筛选机制。在每一轮对话中，系统会智能决策：

• 话题延续时：保留历史轮次中的关键信息，保证对话连贯性
• 话题切换时：快速引入新知识，避免历史信息干扰

决策基于三个关键信号：

• topicSwitch：是否发生话题切换
• dialogAct：当前轮的对话行为类型
• infoNovelty：当前轮引入的信息新鲜度

通过这些信号调节新旧知识的权重，AI就能在不同对话场景下智能切换策略，真正做到“该记得的记得，该忘掉的忘掉”。

2.3. 问题排查场景方案：

目标：从表象（问题描述）到根因的RCA过程

表象 --> 可能原因 --> 根因。

1. 方案：

问题排查架构图

2. 意图路由：

排查问题一般分为两类：

1. 业务咨询类，面向静态知识的问答。例如：如何创建绑定账号？如何查看优惠券等？

2. 查询和排查类，面向特定账号、数据的咨询和排查。

通用意图识别模块，区分出问题类型，然后路由到不同的处理流程：业务咨询类，走知识问答流程；查询排查类走ReAct推理流程。

3. ReAct 推理：

ReAct推理模块：

定位：智能决策代理（Agent），采用 ReAct（Reason + Act）模式进行多轮推理与工具协调。核心职责是：基于用户目标、上下文信息和可用工具能力，规划并输出下一步行动，但绝不自行执行任何工具调用。

组装并给到大模型的输入：

• IntentResult：来自意图识别 Agent
• 原始query：用户的原始输入请求（需作为最终结果校验的基准）
• tool_results：本轮已执行的工具调用结果
• 历史对话：用户与平台的过往交互记录
• mcp工具池：平台注册的工具信息

执行约束：

1. 输出结构化模型 ToolExecutionChain；

2. 只思考，不执行；

3. 多轮迭代，基于历史推理；

4. 保持严谨、安全性。

4. 执行引擎：

反思执行组件提供两套实现方案：

ReActExecutor：简化版（Thought→Action）。

• 优点：响应速度快
• 不足：复杂处理逻辑可能效果不好

ReActObversationExecutor：完整版（Thought→Action→Observation）

• 优点：职责清晰，可解决复杂处理逻辑、任务规划协调重试
• 不足：耗时较长

场景适配

2.4 常规（极简）场景方案：

流程设计相对简单，核心的目标有两个：1. 降低接入的门槛；2. “复用”工具库和RAG库，统一接入和运维、多方使用。

方案：

极简定制架构图

复用能力：

• 复用预处理模块的多模态支持能力
• 复用公域的工具池资源
• 复用统一的RAG知识库
• 复用标准的安全权限体系

这确保了简单场景的助手，能够“站在巨人的肩膀上”快速诞生。

第三部分：prompt插拔式架构 —— 框架prompt + 业务定制

prompt 形式上是文本，本质上是给LLM执行的“代码”。因此，prompt也需要进行功能抽象、模块设计、架构设计，而其文本特性给了我们很便捷的操作方式。

在日常工作中，我们尝尝会把实现某一类（某一个）功能点的prompt沉淀下来，方便下一次复用（黏贴）。如果我们再往前走一步，以架构设计的视角来看待prompt，自然而然的，就会想要抽象场景 --> 规划出核心功能 --> 沉淀专有的prompt --> 开放出业务定制部分。最终达成框架prompt的统一运维、高度复用，业务定制部分贴合具体场景，极度灵活。

在沉淀解决方案的过程中，我们已经抽象出了核心功能节点（agent）：意图识别、工具推理、反思推理、交互反馈等，在不断迭代的过程中，也沉淀出了多套框架prompt和业务定制prompt模版。

我们以意图识别这个核心Agent为例展开介绍。

意图识别：

目标：

• 理解用户语义，确保语义完整
• 解析指令，规范输出
• 意图分类（可选）

框架prompt--插桩：

业务定制模版：

业务定制模版，结合前端产品设计，开放出：业务说明、意图定义、归一化词表等模块，又助手创建者填写。

案例：VIP演练执行助手

案例：金融答疑助手

第四部分：平台落地——从技术方案到“助手工厂”

我们将以上的四套解决方案沉淀为了四套模版，核心agent节点（意图识别、工具推理、ReAct推理、总结交互等）均内置了框架prompt + 开放业务定制的架构设计，并以此创建了智空间的助手市场产品能力。

产品设计的核心思路：让用户通过“选择模板 -> 配置 -> 生效”的三步法，像配置工作流一样“配”出AI助手。

4.1 一键三连，创建第一个AI助手（极简定制）

1. 一键选择模版

2. “三联”配置助手：

3. 一秒生效：保存即生效，点击即使用。

4.2 定制一个排查助手

首先，我们要明确一点，AI需要借助“专家经验”、底层工具、知识库，才能解决复杂问题。而助手工厂所有的努力，都是让专家集中精力去沉淀“专家经验”，无需关注多agent如何设计、prompt如何配置、工具如何召回等耗时、耗力的事项。

因此，在创建一个AI助手时，必然要理清楚：

• 要解决的问题是什么？明确场景和边界；
• 复杂场景分类，采用MECE（不重不漏）原则拆分为子类型（也叫意图类型）；简单场景可以跳过；
• 每一类型，如何排查？注意：不是结论，是过程！！！

创建排查助手：

查看排查流程：

意图识别定制（资深编辑模式）：

排查策略定制（资深编辑模式）：

第五部分：总结展望

5.1 核心沉淀：

方法论层面，我们总结出了场景抽象→解法沉淀→产品化落地的三步法，此方法也将继续驱动AI平台智空间的演进。

技术层面，我们沉淀了四大模板+Prompt框架+业务定制架构的技术体系，这得益于我们作为业务平台团队对于能力抽象、解决方案沉淀的执着。该架构体系很好的平衡了标准化和灵活性——既保证了基础能力的统一和高质量，又支持不同业务的个性化需求。

产品层面，我们初步实现了配置化、模板化、极简化的设计目标，有效的降低了创建智能助手的门槛。

5.2 未来规划：

场景拓展，除了文中提及的四大场景以外，做决策和做数据分析，也是日常工作内容的重要组成部分，后续也将纳入到解决方案中。

能力升级，从配置化到自动化。当前依赖人工分析案例、划分意图（令人头疼的MECE原则）、配置录入（一键三连也很麻烦）、调试发布，在运维期间还要分析真实用户的query、场景等。在此过程中，唯一不能被AI代替的是：具体案例沉淀（问题描述、解决过程、决策分析等），其它的全部可以由后台agent来完成。此处的各种后台agent，就是我们的下一步。

5.3 一点思考：

智能化与基建并行，AI平台的终极目标，始终是让“专家”聚焦于沉淀“专家经验”，是让AI技术对助手创作者透明化，所以平台本身必然走向智能化。与此同时，恰如大树生长，除了智能化的向上生长，底层的知识库构建（文档信息、知识生成等）、工具能力建设（面向AI友好的工具&工具集合）都是决定平台是否能用、好用的关键。

专家经验沉淀是关键，专家经验沉淀的深度和厚度，是决定AI应用的落地和推广的关键。平台是骨架，专家经验才是灵魂。也许这将是未来几年对“专家”最大的挑战和机遇。

5.4 AI 共创：

你在开发 AI 助手时遇到的最大痛点是什么？欢迎评论区留言。

来源  |  阿里云开发者公众号

作者  |  雨清