【免费下载链接】MemoryBearMemoryBear Equip AI with human-like memory capability项目地址https://gitcode.com/gh_mirrors/me/MemoryBear点击查看免费下载导读本文以 MemoryBear 仓库中 analyze_task_user.md 为核心结合其配套的 analyze_task_system.md 与提示词加载/渲染实现完整拆解这套任务分析Task Analysis提示词的双文档设计与执行逻辑。读完你将掌握输入变量如何注入、任务传递Task Transmission何时输出、LOW / MEDIUM / HIGH 三级复杂度如何划分与限词以及该框架在 MemoryBear 多 Agent 编排体系中的落点与自定义方式。一、提示词在仓库中的位置与设计意图在 MemoryBear 中api/app/core/rag/prompts/目录集中存放 RAG 与多 Agent 场景使用的全部提示词模板其中analyze_task_user.md与analyze_task_system.md是一对用户侧 / 系统侧提示词职责是让 LLM 扮演一个能按任务复杂度自适应调整分析深度的任务分析器。从 generator.py 可以看到二者的加载方式完全对称ANALYZE_TASK_SYSTEM load_prompt(analyze_task_system) ANALYZE_TASK_USER load_prompt(analyze_task_user)加载机制由 template.py 提供load_prompt(name)会在prompts/目录下查找{name}.md首次读取后缓存在_loaded_prompts字典中避免重复读盘。这意味着这两个文件本质上是可被 Jinja2 渲染的模板而非写死的静态文本。二、用户侧提示词四个输入变量 一条输出铁律analyze_task_user.md全文虽短但定义了整套模板的数据契约。它声明了四个输入变量变量含义注入内容{{ task }}待分析的任务/请求当前任务名或用户请求{{ context }}背景、历史、情境上下文会话历史与上下文信息{{ agent_prompt }}特殊指令/角色提示当前 Agent 的角色定义或额外约束{{ tools_desc }}可用的子 Agent 与能力清单由工具 schema 序列化后的能力描述同时声明最终输出规则Final Output RuleReturn the Task Transmission section (if needed) followed by the concrete analysis and planning steps according to LOW / MEDIUM / HIGH complexity. Do not restate the framework, definitions, or rules. Output only the final structured result.翻译过来即先输出如需任务传递小节再按 LOW / MEDIUM / HIGH 复杂度输出具体的分析与规划步骤不得复述框架、定义或规则本身只输出最终结构化结果。这条规则的工程价值在于压缩输出 token、让下游解析器直接消费结构化内容。三、系统侧提示词三级复杂度自适应分析框架配套的 analyze_task_system.md 定义了分析器必须遵循的三步框架用户侧模板中的 LOW / MEDIUM / HIGH 正是由它给出的。Step 1任务传递评估Task Transmission Assessment该小节不受字数限制因为它承担关键交接handoff职责。判定是否需要任务传递信息若是初始步骤→ 跳过本节若没有上游 Agent / 步骤→ 提供最小化传递若有必须保留的关键状态/上下文→ 输出完整传递。需要传递时按六个字段输出Current State Summary当前进度摘要1–2 句Key Data/Results必须携带的关键发现Context Dependencies下游 Agent/步骤必需的上下文Unresolved Items需要延续解决的遗留问题Status for User面向用户的清晰状态更新Technical State面向技术交接的系统状态。这组字段的设计体现了一个多 Agent 编排系统对上下文连续性的硬性要求——交接内容既要让下一个 Agent 接得住也要让用户看得懂。Step 2复杂度分类Complexity ClassificationLOW单步任务、直接查询、闲聊MEDIUM单一领域内的多步任务HIGH跨领域协调或复杂推理。分类的意义不是贴标签而是决定 Step 3 的分析深度预算实现越简单越省越复杂越全的自适应策略。Step 3自适应分析Adaptive Analysis分析深度随复杂度伸缩一旦达成成功标准立即停止Always stop once success criteria are met。各档位的要求如下档位分析字数上限必须包含的内容LOW最多 50 词检测到闲聊时直接输出Small talk — no further analysis needed单句目标1–2 步直接执行方案MEDIUM80–150 词目标意图与范围3–5 步最小计划可标注并行步骤至少一个带明确停止条件的探测Probe成功标准 基础失败检测与回退证据获取/验证的 Source PlanHIGH150–250 词完整目标分析意图与范围5–8 步带依赖/并行关系的计划关键未知项 → 探测 → 停止条件可衡量的成功标准失败检测器与回退证据获取与验证的 Source Plan升降级的反思钩子Reflection Hooks值得注意的细节MEDIUM 的 Uncertainty Probes要求至少一个带停止条件的探测防止模型在不确定性上无限发散HIGH 的 Reflection Hooks允许模型在分析过程中根据实际情况升级/降级复杂度判断这是自适应能力的闭环体现三个档位都要求Source Plan证据如何获取与验证说明该框架为可溯源、可核查的检索增强分析而设计。四、代码落地Jinja2 渲染与工具描述注入analyze_task_user.md中的变量如何变成真实 prompt关键在 generator.py 的analyze_task()函数def analyze_task(chat_mdl, prompt, task_name, tools_description: list[dict], user_defined_prompts: dict{}): tools_desc tool_schema(tools_description) context if user_defined_prompts.get(task_analysis): template PROMPT_JINJA_ENV.from_string(user_defined_prompts[task_analysis]) else: template PROMPT_JINJA_ENV.from_string(ANALYZE_TASK_SYSTEM \n\n ANALYZE_TASK_USER) context template.render(tasktask_name, contextcontext, agent_promptprompt, tools_desctools_desc) kwd chat_mdl.chat(context, [{role: user, content: Please analyze it.}]) if isinstance(kwd, tuple): kwd kwd[0] kwd re.sub(r^.*/think, , kwd, flagsre.DOTALL) if kwd.find(**ERROR**) 0: return return kwd这段实现揭示了几个关键工程细节双文档拼接默认模板是ANALYZE_TASK_SYSTEM \n\n ANALYZE_TASK_USER系统侧定义框架、用户侧声明数据契约两者合二为一后交给 Jinja2 渲染工具描述序列化tools_desc由tool_schema()生成见 generator.py把每个子 Agent/工具按## 1. name JSON Schema的格式编排正好填充{{ tools_desc }}可覆盖性user_defined_prompts.get(task_analysis)允许业务方用自定义 Jinja2 模板整体替换这套默认提示词实现框架固定、模板可插拔输出清洗调用 LLM 后统一用正则re.sub(r^.*/think, , ...)剥掉思考链前缀遇到**ERROR**标记则返回空串避免脏输出污染下游。该 prompt 模块与api/app/core/rag/prompts/下其余模板如next_step.md、reflect.md、summary4memory.md、rank_memory.md共同构成一个分析 → 计划 → 执行 → 反思 → 记忆的完整 Agent 循环提示词体系。在 MemoryBear 的多 Agent 编排侧multi_agent_orchestrator.py 中的_analyze_task()也承担Master Agent 分析任务并做出路由决策的职责会输出sub_agents、routing_decision、routing_tokens等结构化字段——可见先分析、再路由、后执行是该项目的统一范式。五、易踩的坑与实用建议结合模板与源码实际使用这套提示词时有几点值得注意不要违反 Final Output Rule模型若把框架定义复述一遍会显著浪费 token 且破坏输出结构建议在 few-shot 示例中强化只输出结果的行为闲聊短路LOW 档的Small talk — no further analysis needed是硬编码输出下游解析时应做字符串精确匹配命中后直接走轻量回复路径字数预算是分析部分的预算系统侧明确 LOW/MEDIUM/HIGH 的字数上限均指for analysis only且任务传递部分不受限——设计 prompt 变体时不要把交接字段和规划字段混在一处计费探测必须有停止条件MEDIUM/HIGH 的 Probe 若缺少 stop condition模型可能在不确定处反复试探导致分析阶段 token 失控自定义模板的变量契约若通过user_defined_prompts[task_analysis]覆盖务必保留task、context、agent_prompt、tools_desc四个变量或按需提供否则 Jinja2 渲染会因变量缺失而报错。六、相关文件速查用户侧模板analyze_task_user.md系统侧框架analyze_task_system.md加载与渲染入口generator.pyanalyze_task()、tool_schema()模板加载器template.py同目录配套模板next_step.md、reflect.md、summary4memory.md、rank_memory.md、meta_filter.md等见 prompts 目录多 Agent 编排消费侧multi_agent_orchestrator.py、master_agent_router.py小结MemoryBear 的analyze_task_user.md虽只有寥寥数行却是整套任务分析框架的数据契约层它固定了四个输入变量与一条输出铁律配合系统侧的三步分析框架任务传递 → 复杂度分类 → 自适应分析在 generator 中经 Jinja2 渲染后驱动 LLM 产出结构化分析结果。这种系统模板定框架、用户模板定契约、业务方可整体覆盖的三层设计为多 Agent 编排中的任务理解环节提供了清晰、可维护、可扩展的范本。赞分享【免费下载链接】MemoryBearMemoryBear Equip AI with human-like memory capability项目地址https://gitcode.com/gh_mirrors/me/MemoryBear点击查看免费下载相关推荐Sentry JavaScript SDK 框架更新相关性分类指南从源码剖析 high/medium/low 判定规则Sentry JavaScript SDK 框架更新相关性分类指南从源码剖析 high/medium/low 判定规则 导读 本指南源自 Sentry Jav可观测性如何在 5 分钟内集成 human-panic为你的 Rust CLI 应用添加专业级错误处理如何在 5 分钟内集成 human panic为你的 Rust CLI 应用添加专业级错误处理 human panic 是一个专为 Rust CLI 应用设计开发工具MemoryBear 规划 Agent 提示词解析如何用 next_step.md 驱动多步工具调用决策MemoryBear 规划 Agent 提示词解析如何用 next_step.md 驱动多步工具调用决策 导读 在 MemoryBear 的 RAG 与 Ag上一篇WarcraftHelper插件开发教程用IPlugin接口如何快速扩展一个新功能下一篇如何用treg做AI搜索Tavily、Exa等搜索API在Agent中的终极用法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/9 2:42:23 · 阅读 1.2k MemoryBear 任务分析提示词解析：LOW / MEDIUM / HIGH 三级复杂度自适应规划框架
【免费下载链接】MemoryBearMemoryBear Equip AI with human-like memory capability项目地址https://gitcode.com/gh_mirrors/me/MemoryBear点击查看免费下载导读本文以 MemoryBear 仓库中 analyze_task_user.md 为核心结合其配套的 analyze_task_system.md 与提示词加载/渲染实现完整拆解这套任务分析Task Analysis提示词的双文档设计与执行逻辑。读完你将掌握输入变量如何注入、任务传递Task Transmission何时输出、LOW / MEDIUM / HIGH 三级复杂度如何划分与限词以及该框架在 MemoryBear 多 Agent 编排体系中的落点与自定义方式。一、提示词在仓库中的位置与设计意图在 MemoryBear 中api/app/core/rag/prompts/目录集中存放 RAG 与多 Agent 场景使用的全部提示词模板其中analyze_task_user.md与analyze_task_system.md是一对用户侧 / 系统侧提示词职责是让 LLM 扮演一个能按任务复杂度自适应调整分析深度的任务分析器。从 generator.py 可以看到二者的加载方式完全对称ANALYZE_TASK_SYSTEM load_prompt(analyze_task_system) ANALYZE_TASK_USER load_prompt(analyze_task_user)加载机制由 template.py 提供load_prompt(name)会在prompts/目录下查找{name}.md首次读取后缓存在_loaded_prompts字典中避免重复读盘。这意味着这两个文件本质上是可被 Jinja2 渲染的模板而非写死的静态文本。二、用户侧提示词四个输入变量 一条输出铁律analyze_task_user.md全文虽短但定义了整套模板的数据契约。它声明了四个输入变量变量含义注入内容{{ task }}待分析的任务/请求当前任务名或用户请求{{ context }}背景、历史、情境上下文会话历史与上下文信息{{ agent_prompt }}特殊指令/角色提示当前 Agent 的角色定义或额外约束{{ tools_desc }}可用的子 Agent 与能力清单由工具 schema 序列化后的能力描述同时声明最终输出规则Final Output RuleReturn the Task Transmission section (if needed) followed by the concrete analysis and planning steps according to LOW / MEDIUM / HIGH complexity. Do not restate the framework, definitions, or rules. Output only the final structured result.翻译过来即先输出如需任务传递小节再按 LOW / MEDIUM / HIGH 复杂度输出具体的分析与规划步骤不得复述框架、定义或规则本身只输出最终结构化结果。这条规则的工程价值在于压缩输出 token、让下游解析器直接消费结构化内容。三、系统侧提示词三级复杂度自适应分析框架配套的 analyze_task_system.md 定义了分析器必须遵循的三步框架用户侧模板中的 LOW / MEDIUM / HIGH 正是由它给出的。Step 1任务传递评估Task Transmission Assessment该小节不受字数限制因为它承担关键交接handoff职责。判定是否需要任务传递信息若是初始步骤→ 跳过本节若没有上游 Agent / 步骤→ 提供最小化传递若有必须保留的关键状态/上下文→ 输出完整传递。需要传递时按六个字段输出Current State Summary当前进度摘要1–2 句Key Data/Results必须携带的关键发现Context Dependencies下游 Agent/步骤必需的上下文Unresolved Items需要延续解决的遗留问题Status for User面向用户的清晰状态更新Technical State面向技术交接的系统状态。这组字段的设计体现了一个多 Agent 编排系统对上下文连续性的硬性要求——交接内容既要让下一个 Agent 接得住也要让用户看得懂。Step 2复杂度分类Complexity ClassificationLOW单步任务、直接查询、闲聊MEDIUM单一领域内的多步任务HIGH跨领域协调或复杂推理。分类的意义不是贴标签而是决定 Step 3 的分析深度预算实现越简单越省越复杂越全的自适应策略。Step 3自适应分析Adaptive Analysis分析深度随复杂度伸缩一旦达成成功标准立即停止Always stop once success criteria are met。各档位的要求如下档位分析字数上限必须包含的内容LOW最多 50 词检测到闲聊时直接输出Small talk — no further analysis needed单句目标1–2 步直接执行方案MEDIUM80–150 词目标意图与范围3–5 步最小计划可标注并行步骤至少一个带明确停止条件的探测Probe成功标准 基础失败检测与回退证据获取/验证的 Source PlanHIGH150–250 词完整目标分析意图与范围5–8 步带依赖/并行关系的计划关键未知项 → 探测 → 停止条件可衡量的成功标准失败检测器与回退证据获取与验证的 Source Plan升降级的反思钩子Reflection Hooks值得注意的细节MEDIUM 的 Uncertainty Probes要求至少一个带停止条件的探测防止模型在不确定性上无限发散HIGH 的 Reflection Hooks允许模型在分析过程中根据实际情况升级/降级复杂度判断这是自适应能力的闭环体现三个档位都要求Source Plan证据如何获取与验证说明该框架为可溯源、可核查的检索增强分析而设计。四、代码落地Jinja2 渲染与工具描述注入analyze_task_user.md中的变量如何变成真实 prompt关键在 generator.py 的analyze_task()函数def analyze_task(chat_mdl, prompt, task_name, tools_description: list[dict], user_defined_prompts: dict{}): tools_desc tool_schema(tools_description) context if user_defined_prompts.get(task_analysis): template PROMPT_JINJA_ENV.from_string(user_defined_prompts[task_analysis]) else: template PROMPT_JINJA_ENV.from_string(ANALYZE_TASK_SYSTEM \n\n ANALYZE_TASK_USER) context template.render(tasktask_name, contextcontext, agent_promptprompt, tools_desctools_desc) kwd chat_mdl.chat(context, [{role: user, content: Please analyze it.}]) if isinstance(kwd, tuple): kwd kwd[0] kwd re.sub(r^.*/think, , kwd, flagsre.DOTALL) if kwd.find(**ERROR**) 0: return return kwd这段实现揭示了几个关键工程细节双文档拼接默认模板是ANALYZE_TASK_SYSTEM \n\n ANALYZE_TASK_USER系统侧定义框架、用户侧声明数据契约两者合二为一后交给 Jinja2 渲染工具描述序列化tools_desc由tool_schema()生成见 generator.py把每个子 Agent/工具按## 1. name JSON Schema的格式编排正好填充{{ tools_desc }}可覆盖性user_defined_prompts.get(task_analysis)允许业务方用自定义 Jinja2 模板整体替换这套默认提示词实现框架固定、模板可插拔输出清洗调用 LLM 后统一用正则re.sub(r^.*/think, , ...)剥掉思考链前缀遇到**ERROR**标记则返回空串避免脏输出污染下游。该 prompt 模块与api/app/core/rag/prompts/下其余模板如next_step.md、reflect.md、summary4memory.md、rank_memory.md共同构成一个分析 → 计划 → 执行 → 反思 → 记忆的完整 Agent 循环提示词体系。在 MemoryBear 的多 Agent 编排侧multi_agent_orchestrator.py 中的_analyze_task()也承担Master Agent 分析任务并做出路由决策的职责会输出sub_agents、routing_decision、routing_tokens等结构化字段——可见先分析、再路由、后执行是该项目的统一范式。五、易踩的坑与实用建议结合模板与源码实际使用这套提示词时有几点值得注意不要违反 Final Output Rule模型若把框架定义复述一遍会显著浪费 token 且破坏输出结构建议在 few-shot 示例中强化只输出结果的行为闲聊短路LOW 档的Small talk — no further analysis needed是硬编码输出下游解析时应做字符串精确匹配命中后直接走轻量回复路径字数预算是分析部分的预算系统侧明确 LOW/MEDIUM/HIGH 的字数上限均指for analysis only且任务传递部分不受限——设计 prompt 变体时不要把交接字段和规划字段混在一处计费探测必须有停止条件MEDIUM/HIGH 的 Probe 若缺少 stop condition模型可能在不确定处反复试探导致分析阶段 token 失控自定义模板的变量契约若通过user_defined_prompts[task_analysis]覆盖务必保留task、context、agent_prompt、tools_desc四个变量或按需提供否则 Jinja2 渲染会因变量缺失而报错。六、相关文件速查用户侧模板analyze_task_user.md系统侧框架analyze_task_system.md加载与渲染入口generator.pyanalyze_task()、tool_schema()模板加载器template.py同目录配套模板next_step.md、reflect.md、summary4memory.md、rank_memory.md、meta_filter.md等见 prompts 目录多 Agent 编排消费侧multi_agent_orchestrator.py、master_agent_router.py小结MemoryBear 的analyze_task_user.md虽只有寥寥数行却是整套任务分析框架的数据契约层它固定了四个输入变量与一条输出铁律配合系统侧的三步分析框架任务传递 → 复杂度分类 → 自适应分析在 generator 中经 Jinja2 渲染后驱动 LLM 产出结构化分析结果。这种系统模板定框架、用户模板定契约、业务方可整体覆盖的三层设计为多 Agent 编排中的任务理解环节提供了清晰、可维护、可扩展的范本。赞分享【免费下载链接】MemoryBearMemoryBear Equip AI with human-like memory capability项目地址https://gitcode.com/gh_mirrors/me/MemoryBear点击查看免费下载相关推荐Sentry JavaScript SDK 框架更新相关性分类指南从源码剖析 high/medium/low 判定规则Sentry JavaScript SDK 框架更新相关性分类指南从源码剖析 high/medium/low 判定规则 导读 本指南源自 Sentry Jav可观测性如何在 5 分钟内集成 human-panic为你的 Rust CLI 应用添加专业级错误处理如何在 5 分钟内集成 human panic为你的 Rust CLI 应用添加专业级错误处理 human panic 是一个专为 Rust CLI 应用设计开发工具MemoryBear 规划 Agent 提示词解析如何用 next_step.md 驱动多步工具调用决策MemoryBear 规划 Agent 提示词解析如何用 next_step.md 驱动多步工具调用决策 导读 在 MemoryBear 的 RAG 与 Ag上一篇WarcraftHelper插件开发教程用IPlugin接口如何快速扩展一个新功能下一篇如何用treg做AI搜索Tavily、Exa等搜索API在Agent中的终极用法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考