阿里云智空间团队分享如何通过场景抽象、Prompt架构和平台实践，打造可复用的AI助手工厂，将日常工作中的80%抽象为四大类高频场景，告别重复“造轮子”。
原文标题：拒绝重复造轮子！抽象 80% 工作场景，打造可复用的"AI 助手工厂”
原文作者：阿里云开发者
冷月清谈：
怜星夜思：
2、文章强调了“专家经验沉淀是关键”，但实际操作中，如何有效地将专家的隐性知识转化为AI可以理解和使用的形式？
3、文章提到了AI助手需要具备安全与权限控制，你认为在AI助手的开发和应用中，如何平衡安全与效率？
原文内容
阿里妹导读
当每个业务场景都需要一个AI助手时，我们是在埋头苦干、重复造轮子，还是选择打造一条“AI助手生产线”？本文深入探讨智空间团队如何将执行、答疑、排查、极简场景四大高频需求抽象为可复用的技术方案，最终实现让业务方“配”助手而不是“开发”一个助手。
精缩版：
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 场景归类&方案：
基于上述分析，我们为每一类场景设定了明确的目标，并设计了针对性的解决方案。
|
|
复杂指令 |
知识问答 |
问题排查 |
常规（极简） |
|
场景案例 |
智造 演练助手 |
VIP答疑 |
金融答疑助手 |
系分分析助手 |
|
目标（本质） |
根据用户指令、专家经验， 在海量工具中找到并规划工具链，达成任务。 |
根据用户问题， 在海量信息中，找到图文信息，生成知识，解决问题。 |
从表象（问题描述）到根因的RCA过程：
表象 --> 可能原因 --> 根因。 |
常规的借助LLM完成特定任务。 |
|
挑战 |
|
|
|
|
|
方案 |
|
|
|
|
|
共性问题 |
|
|||
|
共性问题应对 |
|
|||
至此，我们完成了从“具体场景”到“抽象类型”的理论跨越。接下来，是如何将这些抽象方案，转化为稳定、高效、可复用的系统。
第二部分：技术破局——四套解决方案
整体架构：一个分层解耦的架构设计。
整体架构设计图
架构解读：
-
解决方案层：固化了四大场景的差异化流程，包含多个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）
-
优点：职责清晰，可解决复杂处理逻辑、任务规划协调重试
-
不足：耗时较长
场景适配
|
场景类型 |
推荐引擎 |
原因 |
|
简单排查（答疑） |
ReActExecutor |
快速响应（少一步LLM调用），无需复杂评估。 |
|
多步骤业务流程 |
ReActObversationExecutor |
需动态评估每一步结果，确保流程正确性。 |
|
需要错误恢复 |
ReActObversationExecutor |
观察者可触发重试或回退策略。 |
2.4 常规（极简）场景方案：
流程设计相对简单，核心的目标有两个：1. 降低接入的门槛；2. “复用”工具库和RAG库，统一接入和运维、多方使用。
方案：
极简定制架构图
复用能力：
-
复用预处理模块的多模态支持能力
-
复用公域的工具池资源
-
复用统一的RAG知识库
-
复用标准的安全权限体系
这确保了简单场景的助手，能够“站在巨人的肩膀上”快速诞生。
第三部分：prompt插拔式架构 —— 框架prompt + 业务定制
prompt 形式上是文本，本质上是给LLM执行的“代码”。因此，prompt也需要进行功能抽象、模块设计、架构设计，而其文本特性给了我们很便捷的操作方式。
在日常工作中，我们尝尝会把实现某一类（某一个）功能点的prompt沉淀下来，方便下一次复用（黏贴）。如果我们再往前走一步，以架构设计的视角来看待prompt，自然而然的，就会想要抽象场景 --> 规划出核心功能 --> 沉淀专有的prompt --> 开放出业务定制部分。最终达成框架prompt的统一运维、高度复用，业务定制部分贴合具体场景，极度灵活。
在沉淀解决方案的过程中，我们已经抽象出了核心功能节点（agent）：意图识别、工具推理、反思推理、交互反馈等，在不断迭代的过程中，也沉淀出了多套框架prompt和业务定制prompt模版。
我们以意图识别这个核心Agent为例展开介绍。
意图识别：
目标：
-
理解用户语义，确保语义完整
-
解析指令，规范输出
-
意图分类（可选）
|
|
框架 prompt |
业务定制 |
|
功能抽象 |
|
|
|
prompt结构 |
|
|
框架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 助手时遇到的最大痛点是什么？欢迎评论区留言。