从定制Workflow到AI自主决策：TMIC小新架构演进解析

这篇文章，聊聊TMIC AI小新技术架构的一次核心升级——从定制化workflow到DeepAgent模式的转变。业务中经常会遇到需要跨模块协作、多步骤推理和动态参数识别的复杂问题，旧架构处理起来束手束脚。团队借鉴了DeepAgent的核心设计思路——TodoList、SubAgent、Summary、FileSystem这四板斧，实现了从“预设流程”到“AI自主决策”的跨越。更关键的是，在DeepAgent的基础上，针对实际业务场景做了一些创新性的优化，比如Tree Action模式、SubAgent提速和异步Summary，效果拔群。

AI行业趋势报告：

......省略

......省略

面临的挑战

随着产品不断迭代，系统在处理那些确定性较高的问题时表现尚可，但面对复杂和开放性问题时，灵活性不足的短板就暴露出来了。问题的核心，其实是从简单问题到复杂问题的一次跨越。

在实际业务中，商家提出的问题呈现明显的两极分化。一边是大量简单问题，比如“某类目某时间段的销售额是多少”，这类问题参数明确、意图单一，预设的workflow就能稳定处理。另一边，越来越多像“帮我分析适合研发哪类新品并分析竞品特点”这样的复杂问题冒了出来，它们需要跨模块协作、多步骤推理，参数还得动态识别，老架构根本搞不定。

这种限制，不仅让产品的应用场景变窄，也制约了AI能力的充分发挥。怎么才能让系统既能把简单问题处理得稳稳当当，又能灵活应对复杂问题？这就是这次架构改版最终要啃下的硬骨头。

简单问题：当前可较好处理

简单问题的特征很明显：有明确的取数意图和分析意图，能直接对应到产品上的特定数据集合。像“2025年12月女装连衣裙类目下销售额为多少？”或者“2025年12月女装连衣裙类目的不同价格带表现如何？”这类问题，参数明确、意图单一、数据来源固定，预设的workflow走一遍就搞定了。

复杂问题：当前处理困难

复杂问题的画风就完全不同了，它们是开放创造性的，需要跨模块协作、多步骤推理、动态参数识别。比如这个例子：“我想研发美容护肤类的新品，请帮我分析一下我适合研发哪类新品（选10个竞争强度最低的叶子类目），并帮我分析一下我可能对标的竞品（这些机会类目对应的Top20竞品）有什么特点？”

这类问题的理想分析路径通常包含多个阶段，核心特征就是层层下钻：

阶段一：类目层层下钻与机会筛选

1. 在类目趋势报告中获取美容护肤/美体/精油(1801)类目下的子类目
2. 从一级类目开始，逐层下钻到二级、三级...直到拿到所有叶子类目（数量可能几百个，参数得动态获取）
3. 从众多叶子类目中，基于竞争强度等指标，筛选出竞争强度最低的10个作为机会类目

阶段二：价格带下钻与商品下钻

4. 下钻到价格带维度：在新品管理模块，针对那10个机会类目，分别获取每个类目对应的价格带信息
5. 下钻到商品维度：对于每个“叶子类目×价格带”组合，进一步获取该组合下的Top20商品数据（10个类目 × 多个价格带 × Top20商品，涉及上百次工具调用）

阶段三：综合分析

6. 对所有Top20商品做综合分析，提炼竞品特点、定价策略、产品利益点等共性特征，给出新品研发建议

执行复杂度摆在那儿：上百次工具调用，跨多个业务模块，参数还得动态下钻获取，根本无法提前确定。

理想分析路径 vs 实际处理能力的差距

理想情况下，系统面对复杂问题应该能自主规划执行步骤、动态识别和获取参数、跨模块协作获取数据，并基于全局上下文做深度分析。但现实是，定制化workflow架构有明显的局限性：自主规划能力有限，只能按预设流程走；参数识别缺乏灵活性；业务模块选择固定单一，没法跨模块协作；上下文信息缺失，最后生成结论时感知不到全局思考过程，结果自然缺乏深度和全局视角。

Ai小新的演进之路：从定制化Workflow到AI自主决策（DeepAgent）

定制化workflow的解决方案与痛点

定制化workflow如何解决问题

核心流程是这样的：

1. 会话理解：结合当前对话和历史对话，把用户的问题改写成能完整表达意图的语句
2. 业务识别：根据问题定位到由哪个业务模块来承接
3. 意图识别：判断问题可能命中哪些取数/分析意图（可能同时命中多个）
4. 意图执行：真正取数/分析的地方。每个意图背后通常是一个Multi-Agent workflow，可以根据意图特点选不同的workflow模版，也能直接接第三方外部服务。为了提升速度，多个意图并行执行
5. 总结：对多个意图的执行结果进行整合、总结，生成最终回答
6. 排版：对结果进行排版，适配前端展示

定制化workflow的设计思路和好处：

1. 意图识别定位业务模块：通过业务识别、功能识别，快速准确定位到业务模块。好处是提升稳定性，缩短响应时间，识别不到关键参数能快速退出。
2. 前置参数识别：通过workflow对某些参数做前置识别，支持业务逻辑定制。好处是保证后续执行的稳定性，避免执行过程中间出现参数错误。
3. 定制Agent和定制分析思路：每个子意图由单独的子Agent负责，可以定制特定的分析思路和取数逻辑，子Agent内是ReAct模式，并行执行。好处是能针对性地优化每个子任务的执行效果。
4. 汇总生成报告：汇总各个定制子Agent的输出，生成结构化的最终报告。

定制化workflow的核心痛点

虽然定制化workflow带来了确定性和稳定性，但也严重限制了AI的自主发挥空间，存在三大核心痛点：

痛点1：不能跨产品模块回答

这个架构里，业务模块选择只能定位一个确定的模块，后续链路也就只能基于这一个模块来回答，一旦跨模块就没法处理。比如那个复杂问题“我想研发美容护肤类的新品”，需要同时用到类目趋势报告模块和新品管理模块，但定制化workflow只能选一个，跨模块协作根本做不到。

痛点2：回答思路过于定制

定制workflow虽然带来了确定性，但严重限制了AI的自主发挥空间。主要体现在两方面：一是功能模块拆分定制，每个业务模块下预设功能模块作为独立子Agent，并行执行、互不感知，最后靠总结Agent汇总。这等于提前给AI划了边界，各子Agent没法联合分析或下钻分析，深度不足，遇到超出预设的问题就抓瞎。二是参数识别定制，在业务模块识别后走定制的参数识别workflow，必须从问题中定位到确定的参数。这就缺乏灵活性了，比如类目得层层下钻才能确定，不可能直接在问题里识别出来。

痛点3：总结时上下文信息有限，思考过程感知不全面

最终生成报告时，系统依赖的上下文信息非常有限。总结时只能获取到有限的数据字段，取数过程和中间产生的上下文信息都传不到总结环节，没法感知全局思考过程，只能基于最终取数结果做总结。同时，总结环节嵌在每个子Agent内部，各子Agent执行过程相互独立，没法同时对多个模块的数据做综合分析，跨模块洞察的生成自然受限。

DeepAgent模式的解决方案

基于上面这些分析，新版架构的目标很清晰：在保持稳定性的同时，大幅提升系统的灵活性和AI的自主能力。

设计目标

目标1：支持跨模块回答。支持在单次对话中调用多个业务模块的工具，实现跨模块数据获取和综合分析，解决业务模块选择固定单一的问题。

目标2：支持更灵活的取数方式。把预设workflow转交给AI自主决策，充分发挥大模型的规划和分析能力。支持动态参数识别、多参数组合、多报告对比等灵活场景。

目标3：丰富分析上下文信息。把完整的执行历史、取数过程、中间上下文信息都传递给分析环节，支持基于全局思考过程的深度分析和跨模块综合分析。

核心设计思路：相信AI能力，解决上下文工程问题

随着大模型基座能力不断提升，理论上讲，只要上下文信息足够丰富、准确，AI就能把大部分工作干好。所以核心思路很明确：相信AI能力，把大量的工具调用、定制逻辑交给AI去自主完成，充分发挥大模型的规划、分析和决策能力。同时，把工作重点转向解决AI在实际应用中面临的上下文工程问题，确保AI能获得足够丰富、准确的上下文信息。

解决上下文工程问题

理论上，只要喂给大模型一堆工具，让它自己去解决就行。但实际上，标准ReAct模式会遇到三大问题：

1. 缺乏规划能力：Agent无法提前规划任务步骤、跟踪任务进度，面对复杂任务容易迷失方向
2. 上下文窗口溢出：大量工具调用结果累积在上下文中，长对话历史会占满token预算
3. 无法处理任务分解：所有任务都在同一个上下文中执行，复杂任务会导致上下文混乱，无法并行执行独立任务

参考DeepAgent的设计思路，通过以下核心组件来解决这些问题：

• TodoList：任务规划与进度跟踪，让Agent具备主动规划能力
• SubAgent：任务分解和上下文隔离，支持并行执行独立任务
• Summary：上下文压缩机制，自动监控并压缩历史消息，保留关键信息
• FileSystem：上下文管理机制，自动将大型工具结果保存到文件系统，不在上下文中保留，支持分页读取，避免一次性加载大文件

在此基础上，针对业务场景还做了大量速度优化和特定设计：Tree Action模式让Action按依赖关系执行，减少Planning次数；优化SubAgent职责，聚焦核心任务，提升执行速度；将Summary从串行改为异步执行，缩短整体响应时间。

核心思路总结下来就是：相信AI能力 + 解决上下文工程问题 + 性能优化。

DeepAgent模式技术架构详解

整体架构设计

DeepAgent模式整体架构由两个核心模块组成：加载上下文模块和DeepAgent模块。这种设计把上下文准备与核心推理分离开来，既减轻了Planning阶段的压力，又确保了AI能获得足够丰富、准确的上下文信息。

加载上下文模块负责在DeepAgent执行前，提前识别业务范围、加载相关资源。具体包括：业务模块识别（从单一模块升级为多模块）、工具加载、Skills加载、RAG加载、上下文参数获取。

DeepAgent模块基于DeepAgent设计思路，包含Planning、Execute、Summary、Analysis等核心组件，负责任务规划、工具执行、上下文管理和最终分析。

加载上下文模块

这是DeepAgent模式的前置模块，负责在DeepAgent执行前，提前识别业务范围、加载相关资源，为后续的Planning和执行阶段做好准备。设计目标是减轻Planning压力，提升执行效率，确保AI能获得足够丰富、准确的上下文信息。

核心功能包含五个部分：

• 业务模块识别：根据用户问题判断涉及哪些业务模块，为后续加载工具、Skills、RAG提供基础
• 加载工具：从工具库中筛选并加载相关工具，避免把所有工具都塞进上下文，减少占用和决策成本
• 加载Skills：加载业务模块特定的分析思路和最佳实践，指导AI按业务规范进行分析
• 加载上下文参数：提前获取系统参数和业务模块参数，对数据量大的采用智能截断策略
• 加载RAG：加载相似问题的历史案例和分析思路，为Planning提供方向指导

遇到的问题及解决方案

问题1：工具过多导致上下文混乱和决策困难

平均每个业务模块有10-20个工具，业务模块一多，工具数量巨大。如果把所有工具都喂给Planning，会导致上下文混乱，影响决策效率和准确性，成本也会急剧上升。

方案1：提前决策（当前采用）

通过提前判断用户问题的业务范围，缩小工具选择范围。在DeepAgent执行前，通过业务模块识别机制，智能识别可能涉及的业务模块，然后筛选并加载可能用到的工具，屏蔽不会用到的。优点在于减少Planning需要处理的工具数量，降低上下文成本和决策难度，提前划分了业务模块范围，可以尽量少加载其他信息。但关键在于必须保证业务模块识别的准确性，一旦识别错误，后续全错。

方案2：Planning阶段自动加载（未采用）

让大模型在Planning阶段自动加载工具，给它一个获取工具列表的工具，让它可以自己决定什么时候用哪些工具。优点灵活性高，不需要提前做模块识别。但效果不稳定，Planning可能选错工具或选择范围过大，速度也会变慢，上下文成本高。

综合考虑，采用了方案1（提前决策），因为它在效果和效率上更可控。

问题2：如何保证AI按照理想方式执行并兼顾业务定制分析思路

把大量决策任务交给AI后，怎么保证它能按我们期望的方式去做，同时兼顾业务定制分析思路？如果没有明确指引，AI可能按自己的理解去规划任务，导致分析思路跑偏。

解决方案是通过RAG和Skills机制。Skills提供业务模块特定的分析思路和最佳实践，包含一些业务定制逻辑，比如当获取不到类目时可以用主营类目，当获取多个价格带时使用GMV占比最高的。RAG通过检索相似问题的历史案例，提供具体的案例和参考，确保AI按业务定制的分析思路进行规划。两者相互配合，共同确保AI的分析路径与业务预期保持一致。

问题3：上下文参数获取时机和策略

实际分析过程中会依赖很多系统参数、公共参数，比如用户id、主营类目等。什么时候加载这些参数？如果都放在Planning阶段，会导致它多次调用接口获取参数，影响执行效率。

解决方案是采用前置分析思路，把这些信息提前准备好，让Planning可以直接使用。但并非所有上下文信息都适用，有些返回数据太多，就只进行截断，抽象出公共接口让Planning按需调用。比如商家的新品列表通常涉及分页，只提前加载前5条（命中率最高的），剩下的由Planning后续决定是否需要。这样既减少了Planning的接口调用次数，又避免了上下文成本过高。

详细设计

业务模块识别

区别于定制化workflow的单一业务模块定位，DeepAgent模式支持多业务模块识别。基于用户问题、业务模块列表和RAG，智能识别可能涉及的业务模块；结合用户当前所处的页面和系统参数，更准确地识别；如果涉及多个业务模块，可以返回多个模块名称，支持跨模块协作。

Prompt设计要点

业务模块识别的Prompt需要明确：角色定位是业务模块识别专家；核心目标是精准识别、意图理解、上下文感知、多模块支持；识别原则包括精准匹配、上下文参考、多模块支持、避免误判。

工具加载

根据业务模块识别结果，筛选并加载可能用到的工具。采用树状结构设计，第一层是业务模块，第二层是功能模块，第三层是具体工具。除了各业务模块的专用工具，还设计了公共工具模块，包含跨业务模块的通用工具，比如类目识别工具，避免在每个业务模块中重复定义。

Skills加载

Skills包含业务模块特定的分析思路、最佳实践和业务定制逻辑。比如在新品管理模块，会明确新品的默认选择逻辑：如果用户没有明确指出新品范围，就优先新品列表中的第一个品；如果什么都没提到，就看用户是否处于某份报告/商品的页面；如果都没有，就默认第一个商品/报告。价格带的选择逻辑也一样：用户明确说了就按用户要求做，没说就默认选择GMV占比最高的价格带。

RAG加载

加载分析思路RAG和业务模块RAG，提供相似问题的分析思路和参考案例。根据业务模块识别结果进行过滤，只保留匹配的RAG。通过RAG和Skills的相互配合，确保AI按照业务定制的分析思路进行规划。

上下文参数获取

提前获取业务模块所需的通用上下文参数，包括系统参数（用户Id、用户来源、用户当前所处页面、主营类目、提问时间等）和业务模块参数（如类目趋势报告模块的主营类目、报告支持的时间范围，新品管理模块的用户最近的新品列表等）。采用并行获取、智能截断的策略，提升效率，避免上下文成本过高。

DeepAgent核心模块

Planning（规划器）

Planning是DeepAgent模式的核心组件，负责在每一轮按照ReAct模式决定“下一步做什么”。它不直接执行工具，而是产生标准化的动作意图，可以选择直接调用工具、委托给子Agent、请求人为介入补充信息，或返回最终答案。

Planning的核心能力包括：任务规划、工具调用、数据分析、子Agent委托、并行执行、智能决策。

遇到的问题及解决方案

问题1：如何设计上下文信息

Planning需要哪些上下文信息？如果信息不足，AI可能无法做出正确决策；如果信息过多，可能导致上下文混乱和成本过高。

解决方案是通过加载上下文模块提前准备。Planning的上下文信息包含8个部分：用户原始问题、上下文参数信息、业务模块对应的特定分析思路（Skills）、工具列表、执行历史、上一轮的执行计划（TodoList）、参考的分析思路（RAG）、对话历史。每一部分都有其特定的作用和引入原因，共同确保Planning能获得充足且精准的信息。

问题2：如何确保每一轮Planning不会偏离主线

在多轮Planning过程中，如果没有一个明确的中心来约束和引导，AI可能会在每一轮中做出不同的决策，导致任务执行偏离原始目标。

解决方案是通过TodoList机制。TodoList作为Planning的中心和主线，在任务开始时生成完整的执行计划。在每一轮Planning中，TodoList都会被传递给Planning，作为当前任务的整体规划参考。Planning可以基于TodoList了解任务分解情况，更新任务状态，识别已完成和待完成的任务，确保每一轮的决策都围绕TodoList这个中心展开，不会偏离主线。

问题3：执行动作设计

Planning需要决定“下一步做什么”，那么应该设计哪些执行动作来覆盖所有可能的场景？

设计了三种执行动作：call_actions（执行操作），包括直接调用工具和委托给SubAgent执行，支持并行和串并行混合执行；call_human（人为介入），当Planning需要额外的信息或确认时使用；final_analysis（返回最终分析），当数据获取和分析都已完成时使用，一旦进入这个动作，流程将不会再回到Planning继续执行，直接交给Analysis进行最终输出。通过这三种动作，Planning可以覆盖所有可能的场景。

问题4：错误处理机制的设计

执行过程中会遇到各种异常情况，比如数据查询为空、工具执行错误、参数识别错误、SubAgent执行失败等。如果没有完善的错误处理机制，可能导致Planning陷入死循环。

解决方案是设计完善的错误处理机制，针对不同类型的错误采用不同的处理策略：数据查询为空时直接告知用户，不硬分析；工具执行错误时禁止原参数重试，改用替代方案；参数识别错误时先用上下文参数信息验证，再调用参数识别工具；SubAgent执行失败时评估是否可以重试或使用替代方案。通过完善的错误处理机制，Planning能优雅地处理各种异常情况。

Tree Action（混合执行模式）

Tree Action是一种混合执行模式，支持在单轮Planning中进行并行以及串并行混合执行，所有操作都在单次Execute中完成。它既支持无依赖关系的并行执行，也支持有依赖关系的串行执行，实现了真正的混合执行。

执行模式经历了三个阶段：传统ReAct模式每次Planning只输出一个action，串行执行，效率低；DeepAgent并行执行模式每次输出一个无依赖关系的action list，支持并行执行，但仍无法处理有依赖关系的情况；Tree Action模式每次输出一个具有依赖关系的Action Tree，按照依赖关系顺序执行，支持在单轮中进行并行以及串并行混合执行。

Tree Action模式的核心价值在于解决了工具之间存在依赖关系时的执行效率问题。比如“获取类目、获取最高的价格带、获取最高价格带下的Top20商品”这个需求，三个操作本质上是串行的：工具2的输入依赖工具1的输出，工具3的输入依赖工具2的输出。传统ReAct模式下需要三次Planning往返，效率很低。Tree Action模式通过依赖关系标记，让AI在单次输出中生成完整的Action Tree，系统自动按依赖顺序执行，同时用一个小模型负责工具之间的串联和参数传递，灵活又高效。

测试结论：在我们测试集上，Tree Action模式将Planning次数从3.20次优化到了2.44次，效果非常明显。

SubAgent（子Agent）

SubAgent是DeepAgent实现任务分解和上下文隔离的核心组件。它的核心机制包括：上下文隔离（拥有独立的上下文窗口，不污染主Agent的上下文）、任务分解（将复杂多步骤任务分解为独立的子任务）、并行执行（支持同时启动多个子Agent并行工作）、简洁结果（返回简洁的执行结果，而非完整执行历史）。

SubAgent的架构和主Agent一模一样，核心是DeepAgent模块，但不需要进行上下文加载，这些由主Agent完成。SubAgent所需的相关上下文信息都由主Agent通过subAgentDescription明确传递给它，它在独立的上下文窗口中执行，但不能再调用SubAgent和Human。

SubAgent在执行时类似于实例的概念，主Agent可以根据任务需求创建多个SubAgent实例，每个实例在独立的上下文窗口中执行，互不干扰，最大化执行效率。

目前支持两种SubAgent类型：通用SubAgent（已引入），等同于主DeepAgent，区别在于不能再调用SubAgent和Human；定制SubAgent（未引入），用于解决特定场景下的问题，目前还没有这种场景需求。

遇到的问题及解决方案

问题1：SubAgent执行效率优化

SubAgent处理的任务多半为子任务，不会过于复杂。如果使用完整的DeepAgent能力，包括完整的TodoList规划和详细的分析过程，会导致执行效率低，增加不必要的开销。

解决方案是针对业务场景对SubAgent进行优化：简化Planning职责，删除TodoList，减少Planning节点的输出内容；简化Analysis职责，只输出结论，不需要过程和建议。优化效果非常显著，SubAgent的平均执行时间从103秒缩短到了20秒。

问题2：SubAgent上下文设计

SubAgent的上下文完全由主Agent决定。主Agent通过subAgentDescription明确传递给SubAgent所需的上下文信息，包括已识别的参数、业务模块信息、工具信息等。SubAgent可以直接使用这些信息，无需重新识别，专注于执行分析任务。

问题3：并行设计

对于相互独立的子任务，主Agent可以创建多个SubAgent实例并行执行。比如需要“分别获取类目A、类目B、类目C的最有潜力价格带下的典型商品”，每个类目都需要多步下钻。主Agent可以创建3个SubAgent实例，每个实例负责一个类目的完整下钻链路，并行执行，大幅缩短整体响应时间。

TodoList（任务列表）

TodoList是DeepAgent的核心规划组件，为Agent提供任务规划与进度跟踪能力。它允许Agent在执行复杂任务前创建任务列表，并在执行过程中动态更新任务状态。

核心价值包括：让Agent具备主动规划能力，而不是被动响应；提供清晰的进度可视化和状态跟踪，实时反映每个步骤的执行状态；帮助Agent在面对复杂多步骤任务时保持方向感；支持任务依赖分析和智能执行顺序决策。

执行计划是一个数组，每个元素包含两个字段：status（状态，有pending、in_progress、completed三种）和content（任务描述，应该清晰、具体、可执行）。执行计划的生成与更新有明确的规则：首次执行时生成初始执行计划；如果有计划，根据执行情况更新任务状态；每次输出都需要包含完整的执行计划（全量更新）；可以根据执行情况动态修改计划。

遇到的问题及解决方案

问题：标准ReAct模式缺乏规划能力

在标准ReAct模式下，Agent是被动响应的，每次只决定下一步做什么，缺乏整体规划能力。在面对复杂多步骤任务时，可能会在执行过程中迷失方向。

通过TodoList机制解决的。TodoList让Agent在执行复杂任务前创建任务列表，提前规划执行步骤，并在执行过程中动态更新任务状态。每一轮Planning中，TodoList都会被传递，作为当前任务的整体规划参考，确保每一轮的决策都围绕TodoList这个中心展开，不会偏离主线。

Summary（总结器）

Summary是DeepAgent的上下文管理组件，负责监控上下文窗口使用情况，当接近上限时自动总结历史消息，保留关键信息并释放token空间。它的核心目标是大幅压缩数据量（通常压缩到原始数据的10%-30%），同时确保压缩后的摘要包含规划器决策所需的所有关键业务数据。

核心优势是自动触发、智能保留、避免溢出、需求驱动。它根据用户原始问题、工具列表、执行计划等信息判断需要保留哪些数据；根据todoList中的任务状态判断哪些数据对下一步决策是关键；对于贯穿性信息必须保留，阶段性信息可以大幅压缩或删除。

遇到的问题及解决方案

问题：Summary执行速度慢，阻塞主流程

当上下文过多时，Summary需要处理大量的历史消息进行压缩，执行时间较长。在串行执行模式下，Summary执行完成后才能继续Planning，单个节点的Summary耗时可能就在60秒，大大拖延了整体时间。

解决方案是采用异步Summary优化。将串行总结优化为异步总结，Summary与Planning并行执行，不阻塞主流程。即使Summary需要60秒执行，也不会影响Planning的继续执行，整体响应时间大幅缩短。

Analysis（分析器）

Analysis是DeepAgent的最终分析组件，负责对已获取的数据进行深度分析，并形成逻辑清晰、有数据支撑的策略报告。它接收到的所有数据和信息都是通过前面多轮执行收集和整理而来的。

Analysis具备数据分析、分析框架、逻辑推理、洞察提炼、策略生成、精准表达等核心能力。对于综合分析类问题，输出内容包含：最终结论（基于已获取的数据进行分析，结论先行）、分析过程（展示完整的分析思路和推理过程）、详细建议（基于分析结果提供具体的行动建议）。

遇到的问题及解决方案

问题1：Planning生成报告时无法支持流式输出，影响用户体验

一开始生成报告的职责放在Planning里，但由于输出内容较多，大模型执行时间受输出Token数影响很大。同时Planning还会输出执行动作、todoList等额外信息，没法做流式。用户需要等待整个报告生成完成后才能看到结果，体验很差。

解决方案是把分析能力单独提出来作为一个节点，通过Analysis组件来解决。这样有两个好处：一是支持流式输出，Analysis只输出分析报告内容，用户可以在生成过程中实时看到内容；二是实现职责分离，Planning专注于任务规划和执行决策，Analysis专注于数据分析和报告生成，可以单独优化。

问题2：需要根据用户问题类型动态调整输出结构

用户的问题类型不同，对输出结构的需求也不同。复杂的分析问题需要完整的分析报告，简单的取数问题只需要直接的数据结果。如果统一采用结构化输出，会导致简单问题的回答过于冗长。

解决方案是让Analysis具备问题类型判断能力，动态调整输出结构：分析类问题按标准结构输出分析类问题按标准结构输出，包含“最终结论、分析过程、详细建议”三个部分；简单取数问题直接返回数据结果。这样既保证了复杂问题的分析深度，又确保了简单问题的回答精炼。

问题3：数据展示方式影响报告可读性和专业性

执行过程中会收集大量数据，如何展示是个挑战。如果所有数据集中放在报告最后，会导致数据与分析过程脱节；如果展示所有数据（包括不相关的和执行失败的），会导致报告冗长；如果表格格式不规范、缺少数据来源信息，会影响报告的专业性和可信度。

解决方案是采用智能数据展示机制：数据穿插展示在分析过程的相应位置；只展示和分析过程相关的数据；自动过滤执行失败的数据；所有数据表格采用Markdown格式，左对齐；每个数据表格后面添加数据来源信息，确保可追溯。

问题4：如何设计上下文信息确保Analysis能生成高质量分析报告

Analysis需要基于前面多轮执行收集的信息进行综合分析。如果上下文信息不足或不准确，会导致分析结果不完整、逻辑不清晰等问题。

解决方案是通过精心设计8类上下文信息：用户原始问题、上下文参数信息、业务模块对应的特定分析思路、执行计划（todoList）、执行历史、参考的分析思路（RAG）、对话历史、收集到的所有数据。这些信息共同确保Analysis能全面理解任务背景、执行过程、业务逻辑，生成高质量的分析报告。

FileSystem（文件系统）

FileSystem提供了完整的文件系统操作能力和上下文管理策略。它提供文件读写、搜索等基础工具，还实现了自动上下文卸载机制，将大型工具结果保存到文件系统，避免上下文窗口溢出。核心价值包括：提供完整的文件操作工具集、自动管理上下文（大型结果自动卸载到文件系统，仅在上下文中保留预览）、支持分页读取。

遇到的问题及解决方案

问题：为什么在AI小新中没有使用FileSystem

虽然FileSystem是DeepAgent模式的核心组件之一，但在当前AI小新的实现中并没有使用。原因有三：一是工具特性，我们的各个工具都有明确目的，Planning决定调用它，说明返回的内容都是需要的上下文信息，不存在需要卸载的大型结果；二是时间成本，如果使用FileSystem，需要先将结果上传到文件系统，需要时再重新拉取，增加额外的时间成本和系统复杂度；三是风险控制，文件系统的读写操作可能带来额外风险，而直接保留在上下文中更简单可靠。通过Summary组件的自动上下文压缩机制，已经能有效管理上下文窗口，不需要额外的FileSystem机制。

RAG设计

为什么需要RAG

在AI系统中，如何确保AI能按照业务定制的分析思路去分析，而不是依赖AI的自主发挥？RAG的引入主要解决三个核心问题：

1. 用户语言到产品语言的翻译

用户的问题用自然语言表达，系统内部需要使用产品语言。如果没有RAG的参考，Planning可能无法准确理解用户意图。比如用户问“潜力最高的类目”，产品语言翻译过来是“竞争强度最低的类目”；用户问“竞品如何起量”，产品语言是“竞品的成长路径”。RAG通过提供相似问题的历史案例，帮助Planning理解用户语言与产品语言之间的映射关系。

2. 业务定制的分析思路

对于特定的问题，业务需要有定制的分析思路。比如对于问题“我的新品核心流失到哪些产品上，这些产品对比我们的优势在哪？”，业务定制的分析思路有明确的步骤：第一步从流转分析数据中识别核心流失的竞品，第二步提取竞品的竞争力指标，第三步对比竞品与我方新品的差异。RAG通过提供业务定制的分析思路，确保Planning能按业务预期的步骤进行分析。

3. 执行路径不稳定

对于需要多次Planning的复杂问题，如果没有RAG仅靠大模型自己发挥，多次执行通常不能保证稳定。同样的问题，多次询问可能会有不同的结论，降低答案的可信度。RAG通过提供相似问题的历史案例和分析思路，为Planning提供稳定的参考路径，确保每次执行都能按照相似的分析思路进行规划。

RAG对DeepAgent的重要性

在DeepAgent模式下，大多数决策都依赖于大模型自主决策。这带来一个核心挑战：当出现问题时，我们能做的手段有哪些？RAG就是重要且有效的手段。通过RAG，可以在不改变DeepAgent自主决策模式的前提下，为AI提供方向指导和参考示例，确保AI能按照业务预期的方向进行规划。

RAG在DeepAgent模式中发挥的核心价值包括：方向指导、问题纠正、执行稳定性、业务定制。

AI小新RAG设计原则

RAG的设计遵循三个核心原则：相似问题匹配（通过用户问题与RAG库中的历史问题进行相似度匹配，召回最相关的案例）、业务定制（RAG中的分析思路都是按业务定制的）、全流程参考（RAG贯穿整个Agent设计，不同的字段作用在不同的模块上）。

RAG库中的每条记录包含以下字段：用户问题（用于相似度匹配和检索）、业务模块（用于业务模块识别时的参考）、功能模块（用于功能模块识别时的参考）、所需的数据字段、分析思路（核心内容，提供业务定制的分析步骤）。

RAG在系统中主要在三个地方使用：在业务模块识别处提供参考，提高识别准确性；在Planning处提供全流程参考，帮助规划执行路径；在Analysis处提供参考，帮助理解如何组织分析内容和表达分析结果。

效果评估

评估指标

过程指标用于评估DeepAgent执行过程中各个环节的质量，确保每个环节都能正确执行。

整体指标用于评估最终输出的整体质量，包括逻辑一致性、相关性、深度、可行性和安全性等方面。

性能指标用于评估系统的响应速度和执行效率，确保系统能及时响应用户请求。

效果对比

为了全面评估DeepAgent模式的执行效果，构建了测试用例集。测试来源包括线上收集、测试构造、RAG库筛选三方面，第一批共收集150个典型问题，涵盖了不同业务模块、不同问题类型、不同复杂度的场景。

定制版Workflow和DeepAgent模式各指标对比：

执行速度对比：

其中DeepAgent模式执行速度的优化主要依赖于Tree Action模式、SubAgent提速、异步Summary。

自动化评估流程

自动化评估流程旨在通过系统化的方式，对DeepAgent模式的执行效果进行全面、客观的评估。该流程包括用例收集、批量执行、模型评测、人工复核和数据回流等环节，形成完整的评估闭环。

1. 用例收集：从线上收集真实用例，自己构造针对性的测试用例，通过大模型扩写生成变体，快速扩充用例集。

2. 批量执行/收集线上数据结果：批量调用DeepAgent模式进行问答，或收集线上实际执行的数据结果，记录执行过程中的关键信息。

3. 评测模型进行评测：基于评测指标，通过规则或模型自动进行过程指标评测、整体指标评测、性能指标评测。

4. 人工复核：对关键用例或异常情况进行人工复核，校准评测模型的准确性，持续优化评测规则。

5. 筛选有价值数据回流到RAG中：从评估结果中筛选高质量的问题案例，经过质量校验后回流到RAG库中，持续丰富RAG库。

自动化评估流程形成一个完整的评估闭环：通过用例收集和批量执行持续积累评估数据，通过模型评测和人工复核确保评估结果的准确性，通过数据回流将评估中发现的高质量数据转化为系统能力提升。

总结与展望

核心成果

借鉴DeepAgent的设计思路

从定制化workflow到DeepAgent模式的架构改版，借鉴了DeepAgent的核心设计思路，采用了TodoList、SubAgent、Summary、FileSystem等关键组件。这些核心组件的引入，使得系统从“预设流程”转变为“AI自主决策”，实现了跨模块协作、灵活参数识别、自主规划等核心能力。

创新性的优化

在借鉴DeepAgent设计思路的基础上，针对业务场景做了创新性的优化：Tree Action模式将Planning次数从3.20次优化到2.44次；SubAgent提速优化将平均执行时间从103秒缩短到20秒；异步Summary优化将汇总与Planning并行执行，避免阻塞主流程。

未来展望

回顾这次架构改版，最大的感受是：大模型基座能力的提升带来的变化，远比想象中更大。从复杂的定制workflow到轻便的DeepAgent模式成为可能，这种转变不仅仅是技术架构的升级，更是设计理念的根本性转变。不再需要为每个业务场景编写大量的定制代码，而是相信AI的能力，将复杂的规划、决策、执行交给AI去完成，只需要专注于解决上下文工程问题。

在这个过程中，很多看似简单的优化手段，却能带来显著的提升。TodoList让AI具备了自主规划能力，SubAgent实现了任务分解和上下文隔离，自动Summary有效解决了上下文窗口溢出问题。这些小优化，每一个都针对性地解决了一个具体问题，组合起来就形成了强大的系统能力。

随着大模型基座能力的持续提升，相信会有更多可能性被解锁。未来，可以进一步简化架构，减少对RAG的依赖，提升工具的泛化性，优化上下文管理机制。同时，也需要持续探索AI能力的边界，识别哪些场景适合AI处理，哪些场景需要人工介入，在确定性和灵活性之间找到最佳平衡点。

致谢

感谢团队每一位成员的辛勤付出与不懈努力。在业务快速迭代和技术持续更新的过程中，我们经历了多次架构重构，一路摸爬滚打，积累了宝贵的实践经验。虽然过程充满挑战，但总体而言，开发AI项目是一件令人快乐的事情——它让我们能够充分发挥创造性和灵感，在探索未知领域的过程中不断突破自我。

团队介绍

本文作者帆华，来自淘天集团-天猫新品营销技术团队。我们致力通过大数据、人工智能打造领先的数字化新品营销平台，服务于天猫新品全链路增长，面向品牌商家构建从新品研发、新品孵化到新品上新的一体化解决方案，负责「天猫小黑盒」/「天猫U先」/「TMIC」（天猫新品创新中心）/「淘系新品运营平台」等淘系核心的新品与新客业务，帮助商家连接淘系站内外流量、营销资源与数据，做规模化新品经营与确定性增长。

来源：互联网