TMIC AI小新 DeepAgent架构演进¶

Ch04.223 TMIC AI小新 DeepAgent架构演进¶

📊 Level ⭐⭐ | 10.4KB | entities/tmic-ai-xiaoxin-deepagent-architecture-evolution.md

核心洞察¶

TMIC AI小新从定制化workflow演进到DeepAgent模式，核心转变是：从预设流程控制转向AI自主决策 + 配套的上下文工程。不是简单地把决策权交给LLM，而是设计完整的加载上下文模块来解决上下文工程问题。

产品背景¶

AI小新是TMIC平台的核心AI问答产品，通过问答方式让商家利用平台数据快速进行数据洞察，降低使用门槛。

复杂问题示例：

"我想研发美容护肤类的新品，请帮我分析适合研发哪类新品（选10个竞争强度最低的叶子类目），并分析竞品特点"

执行复杂度：上百次工具调用 → 跨多个业务模块协作 → 参数动态下钻获取

三大痛点 → 对应解法¶

痛点	表现	解法
不能跨模块	workflow只能选一个业务模块，无法跨模块协作	多业务模块识别（前置），支持跨模块回答
回答思路过定制	参数识别预设，AI边界被预设划分	AI自主规划 + Skills/RAG引导分析思路
上下文信息有限	总结时只有最终数据，无过程感知	完整执行历史传给分析环节，FileSystem管理大结果

痛点详解¶

痛点一：不能跨产品模块回答 业务模块选择定位单一业务模块，无法跨模块协作。复杂问题需要同时使用业务模块1（获取类目数据）和业务模块2（获取竞品数据），但定制化workflow只能选一个。

痛点二：回答思路过于定制 - 功能模块拆分定制：各子Agent并行执行互不感知，仅依赖总结Agent汇总，分析深度不足；提前为AI划分边界，限制自主发挥空间 - 参数识别定制：无法处理需要动态获取参数的问题（如类目层层下钻才能确定）

痛点三：总结时上下文信息有限 总结时只能获取有限数据字段（功能模块、单模块数据、数据描述、用户问题），取数过程及中间上下文未传递，无法感知全局思考过程。

加载上下文模块设计¶

前置模块在DeepAgent执行前准备上下文，包含5个核心功能：

功能	作用	设计原则
业务模块识别	多模块识别，不是单一选择	提前决策（准确率高、效果稳定、可观测可评测）优于让Planning自动决策
工具加载	按业务模块筛选工具，屏蔽无关工具	减少上下文成本和决策难度
Skills加载	提供业务模块特定的分析思路和默认选择逻辑	如"获取不到类目时用主营类目"
RAG加载	相似问题的历史案例	为Planning提供方向指导
上下文参数获取	提前获取系统参数，并行获取业务模块参数	如用户ID、主营类目等

设计原则¶

提前决策优于Planning自动决策：业务模块识别准确率高，效果稳定，更适合生产环境。

工具箱三层树状结构¶

第一层：业务模块（如"新品管理"、"AI行业趋势报告"）
第二层：功能模块（如"人群分析"、"竞争分析"、"经营分析"）
第三层：工具（如"queryNewItemCrowdInfo"获取类目下的人群信息）

DeepAgent核心组件¶

四大核心组件¶

组件	职责	解决的问题
TodoList	任务规划与进度跟踪	解决"迷失方向"问题，让Agent具备主动规划能力
SubAgent	任务分解和上下文隔离	支持并行执行独立任务，避免相互干扰
Summary	上下文压缩	自动监控并压缩历史消息，保留关键信息，解决窗口溢出
FileSystem	大型结果管理	自动将大型工具结果保存到文件系统，按需分页读取

业务场景特定优化¶

Tree Action模式：按依赖关系执行Action Tree，减少Planning次数，提升执行效率
SubAgent优化：简化SubAgent职责，聚焦核心任务执行，提升执行速度
异步Summary：从串行改为异步执行，缩短整体响应时间

Planning职责¶

任务规划：产生TodoList，动态跟踪任务进度
工具调用：直接调用工具（取数工具、参数识别工具）
子代理委托：将复杂任务委托给SubAgent执行
数据分析：对获取的数据进行深度分析

ReAct模式¶

Thought → Action → Observation

每一轮决定下一步做什么。

与定制化Workflow的本质区别¶

维度	定制化	DeepAgent
流程控制	预设workflow，AI按图执行	AI自主规划，workflow作为上下文资源
参数识别	前置识别，依赖预设逻辑	动态识别，AI在执行中决定
上下文范围	各子Agent独立，最终汇总	完整执行历史+中间上下文
业务模块	单一选择	多模块识别+跨模块协作

深度分析¶

1. 上下文工程的本质：从"交给AI"到"为AI准备"¶

DeepAgent模式的核心不是简单地信任LLM能力，而是意识到LLM的决策质量高度依赖输入上下文的质量。加载上下文模块的五个功能（业务模块识别、工具加载、Skills加载、RAG加载、上下文参数获取）本质上是在解决一个根本问题：如何让LLM在执行复杂任务时获得足够的业务背景知识。

这意味着"相信AI能力"需要配套的工程投入——没有提前加载业务模块信息，AI无法准确判断该使用哪些工具；没有Skills和RAG的引导，AI的分析思路可能偏离业务预期。

2. 前置决策 vs 动态规划：准确率驱动的架构选择¶

文章强调"提前决策优于Planning自动决策"，这一原则背后反映的是生产环境对稳定性的要求高于灵活性。业务模块识别的准确率高、效果稳定、可观测可评测，因此适合前置解决；而让Planning在运行时自动判断模块归属，虽然更灵活，但增加了不可预测性。

这是一个典型的准确率优先 vs 灵活性优先的架构权衡。在TMIC这样的电商平台场景中，用户问答的准确率直接影响商家对平台的信任，因此宁可牺牲一定的灵活性，也要确保模块识别的高准确率。

3. 上下文窗口溢出的工程解法：压缩与卸载并行¶

FileSystem组件的设计揭示了一个关键问题：LLM的上下文窗口是有限的，但业务场景需要处理的数据可能是海量的。上百次工具调用产生的数据量远超上下文窗口容量。

DeepAgent采用"压缩+卸载"的双重策略：Summary组件自动压缩历史消息保留关键信息，FileSystem组件将大型结果保存到文件系统按需读取。这不是单一技术的突破，而是工程层面多种手段的组合应用，针对不同类型的数据采用不同的处理策略。

4. Tree Action模式：依赖关系驱动的执行优化¶

Tree Action模式的核心洞察是：工具调用之间存在依赖关系，这种依赖关系是可以被显式建模和优化的。当一个工具的执行需要另一个工具的结果作为输入时，按依赖顺序执行比让LLM在每轮ReAct循环中自己判断更高效。

这一设计与LangChain的Chain、LlamaIndex的Query Pipeline在思想上是一致的——将复杂的工具调用流程建模为有向无环图（DAG），而非扁平的函数列表。

实践启示¶

上下文工程先行：在将任务交给LLM之前，先确保它拥有足够的背景信息。业务模块识别、工具筛选、Skills/RAG加载应该作为标准流程前置执行，而非依赖LLM的"自我探索"。
模块识别的准确率是关键瓶颈：在复杂Agent系统中，如果业务模块识别出错，后续的工具选择和数据分析都会偏离目标。应该投入资源优化模块识别的准确率，并通过A/B测试持续监控。
并行执行需要显式上下文隔离：SubAgent支持并行执行，但并行不代表可以忽视上下文管理。每个SubAgent应该有明确的上下文边界，避免相互干扰；同时需要一个全局协调机制（如Summary组件）来汇总各SubAgent的结果。
异步Summary是降低响应时间的有效手段：将耗时的上下文压缩操作从主流程中剥离出来，改为异步执行，可以显著缩短用户的等待时间。这一优化思路适用于任何涉及复杂文本处理的生产系统。
工具箱需要分层设计：三层树状结构（业务模块→功能模块→工具）为工具管理提供了清晰的分层抽象，便于按业务场景动态组合。这种设计使得添加新业务模块或新工具时不需要修改核心Agent逻辑，具备良好的可扩展性。