# -*- coding: utf-8 -*-
from jarvis.jarvis_utils.tag import ct
from jarvis.jarvis_utils.tag import ot

DEFAULT_SUMMARY_PROMPT = """<report>
请生成任务执行的上下文结构化总结报告，作为后续对话的"无关键信息缺失"上下文支撑：

<content>
#### 1. 目标层次结构（必须清晰区分）
- **整体目标**（顶层愿景）：
  - 格式："[目标类型] 实现[具体成果]，达到[量化指标]"
  - 示例："[架构升级] 完成用户认证系统重构，达到QPS≥1000，99.9%可用性"

- **阶段目标**（当前阶段交付）：
  - 格式："阶段[序号]：[具体目标] → [验收标准]"
  - 示例："阶段1：数据库表设计完成 → user/auth表结构定义+索引优化方案"

#### 2. 任务状态矩阵（精确跟踪，严格验证）
**⚠️ 关键原则：必须基于实际执行结果和验证证据，禁止推测或假设任务已完成**

- **已完成**（✅）：**仅包含已通过验证的交付成果**
  - **验证标准**：必须同时满足以下条件才能标记为"已完成"：
    1. 有明确的执行记录（如代码已提交、文件已创建、功能已测试）
    2. 有验证证据（如测试通过、代码审查通过、功能运行正常）
    3. 达到验收标准（如满足性能指标、通过所有测试用例）
    4. **代码开发任务额外要求**：
       - ✅ **编译/构建必须通过**：代码必须能够成功编译/构建，无编译错误、无语法错误、无链接错误
       - ✅ **功能必须验证**：功能必须经过实际运行验证，不能仅凭代码存在就认为完成
       - ✅ **错误必须修复**：如果存在编译错误、运行时错误、测试失败，必须明确标记为"未完成"或"部分完成"
       - ✅ **测试必须通过**：如果有测试用例，必须通过测试；如果没有测试，必须手动验证功能正常
  - 格式："[优先级] [交付物] - [验证方式] - [验证证据] - [编译/构建状态]"
  - 示例："P0 用户表结构设计 - 已通过代码审查 - 审查记录：PR#123已合并，测试用例test_user_table通过 - 编译通过，无错误"
  - **禁止行为**：
    - ❌ 不能仅因为"计划执行"或"开始执行"就标记为已完成
    - ❌ 不能因为"看起来应该完成"就标记为已完成
    - ❌ **不能因为"代码已编写"就标记为已完成**（必须验证编译和功能）
    - ❌ **不能在有编译错误时标记为已完成**（编译错误 = 任务未完成）
    - ❌ **不能在有运行时错误时标记为已完成**（运行时错误 = 任务未完成）
    - ❌ **不能在有测试失败时标记为已完成**（测试失败 = 任务未完成）

- **进行中**（🔄）：已开始但未完成的任务
  - 格式："[优先级] [任务描述] - [当前进度] - [剩余工作]"
  - 示例："P1 实现JWT认证接口 - 已完成接口定义，待实现token生成逻辑"

- **部分完成**（⚠️）：已完成部分但未达到完整验收标准
  - 格式："[优先级] [任务描述] - [已完成部分] - [缺失部分] - [编译/构建状态] - [错误信息]"
  - 示例："P2 用户登录功能 - 已完成前端UI和后端接口 - 待补充错误处理和日志记录 - 编译通过但有运行时错误 - 错误：登录接口返回500错误"
  - **代码开发场景特别注意**：
    - 如果存在编译错误，必须标记为"部分完成"，并明确说明编译错误
    - 如果存在运行时错误，必须标记为"部分完成"，并明确说明运行时错误
    - 如果存在测试失败，必须标记为"部分完成"，并明确说明失败的测试

- **待完成**（📋）：尚未开始或等待前置依赖的任务
  - 格式："[优先级] [任务描述] - [前置依赖]"
  - 示例："P1 实现JWT认证接口 - 依赖：用户表完成"

#### 3. 关键信息导航系统（快速索引）
- **关键信息位置**（📍）：使用记忆标签建立索引
  - 项目长期记忆：关键架构决策、配置方案、业务规则
  - 全局长期记忆：通用解决方案、最佳实践、技术标准
  - 短期记忆：当前任务的临时数据、调试信息、中间结果

- **关键文件路径**（📁）：建立项目核心文件映射
  - 配置文件：`src/jarvis/config/` - 系统配置和参数
  - 核心代码：`src/jarvis/jarvis_agent/` - 代理核心逻辑
  - 工具定义：`src/jarvis/jarvis_tools/` - 可用工具集合
  - 测试文件：`tests/` - 测试用例和验证脚本

#### 4. 执行结果与关键发现（必须经过验证，信息缺失时可标注）
- **执行结果**：成功/失败/部分完成（必须基于实际执行结果，禁止推测；如无法确定可标注"未验证"）
  - **成功**：必须提供验证证据（如测试通过、功能运行正常、错误已修复）
    - **代码开发任务额外要求**：必须明确说明编译/构建状态（通过/失败），功能验证状态（已验证/未验证），测试状态（通过/失败）
  - **失败**：必须说明失败原因和错误信息（包括编译错误、运行时错误、测试失败等）
  - **部分完成**：必须明确说明已完成部分和未完成部分，以及未通过验证的具体项
    - **代码开发任务额外要求**：必须明确说明编译/构建状态（通过/失败/有错误），具体的错误信息（编译错误、运行时错误、测试失败等）
- **关键信息**：执行过程中提取的重要技术/业务信息（必须提供信息来源和验证方式；如信息不可获取可标注"信息缺失"）
- **重要发现**：任何经过验证的发现或意外收获（必须说明验证过程；如无发现可省略）
- **无效方案总结**：如果当前是在修复问题，总结经过验证无效的尝试方案
  - 已验证无效的方法及其具体失败原因
  - 经过验证排除的错误假设
  - 已证实不可行的解决路径（如无验证机会可标注"未验证"）

#### 5. 技术与业务上下文（经过验证，信息缺失时可标注）
- **技术栈与版本**：项目技术栈、关键依赖、版本信息（基于实际检测或配置文件验证；如无法获取可标注"未检测"）
- **架构决策**：技术选型理由、权衡考虑、未来扩展性（基于实际代码或文档验证；如文档缺失可标注"基于代码推断"）
- **配置参数**：系统配置、环境变量、关键设置（基于实际配置文件验证；如无配置访问权限可标注"配置未获取"）
- **代码位置**：核心文件、配置位置、关键实现（提供精确的文件路径和范围；如无法精确定位可标注"大致位置"）
- **调试信息**：错误信息、性能数据、测试结果（基于实际运行结果；如无法重现可标注"未复现"）

#### 6. 我的偏好与约束（精确记录）
- **质量要求**：代码规范、测试覆盖率、文档标准
- **性能约束**：响应时间、并发量、资源限制
- **兼容性要求**：系统版本、浏览器支持、设备适配
- **禁忌项**：明确禁止的技术方案或实现方式
- **代码风格**：缩进、命名规范、注释要求、代码组织方式

#### 7. 后续行动建议
- **下一步**：具体可执行的行动项
- **优先级排序**：基于依赖关系的任务执行顺序
- **注意事项**：潜在风险和需要特别关注的技术点
</content>

<format>
1. 语言风格：简洁、客观、专业，使用编程领域规范表述；
2. 结构组织：按"核心目标→已确认事实→决策与共识→技术细节→任务进展→待办事项→我的约束"的逻辑组织；
3. 呈现形式：分点列出，关键技术内容用`代码块`/加粗标注，待办事项用"【优先级】+ 内容"明确；
4. **任务状态呈现要求**：
   - 必须严格区分"已完成"、"进行中"、"部分完成"、"待完成"四种状态
   - "已完成"任务必须提供验证证据，不能仅凭推测
   - **代码开发任务特别要求**：
     - "已完成"任务必须明确说明编译/构建状态（通过/失败），功能验证状态（已验证/未验证）
     - 如果存在编译错误，必须标记为"部分完成"或"进行中"，不能标记为"已完成"
     - 如果存在运行时错误，必须标记为"部分完成"或"进行中"，不能标记为"已完成"
     - 如果存在测试失败，必须标记为"部分完成"或"进行中"，不能标记为"已完成"
   - 如果任务未完成，必须如实标记为"进行中"或"部分完成"，不能错误标记为"已完成"
5. 长度限制：严格控制在500词以内，优先压缩冗余，不压缩必保信息。
</format>
</report>"""

SUMMARY_REQUEST_PROMPT = """<summary_request>
<objective>
请对当前对话历史进行精准总结，核心目标是为后续对话提供"无关键信息缺失"的上下文支撑：既要提炼核心逻辑，又要完整保留影响后续决策/操作的关键细节，确保后续对话无需回溯原始历史即可顺畅推进。

**特别针对代码开发任务**：必须完整保留代码变更的上下文、原因、影响范围、错误信息、调试过程、测试结果等关键信息，避免后续大模型因信息缺失而偏离方向。
</objective>

#### 1. 目标层次结构（必须清晰区分）
- **整体目标**（顶层愿景）：
  - 格式："[目标类型] 实现[具体成果]，达到[量化指标]"
  - 示例："[架构升级] 完成用户认证系统重构，达到QPS≥1000，99.9%可用性"
  - 必须包含：业务意义、成功标准

- **阶段目标**（当前阶段交付）：
  - 格式："阶段[序号]：[具体目标] → [验收标准]"
  - 示例："阶段1：数据库表设计完成 → user/auth表结构定义+索引优化方案"
  - 必须包含：当前阶段边界、可验证的交付物

#### 2. 任务状态矩阵（精确跟踪，严格验证）
**⚠️ 关键原则：必须基于实际执行结果和验证证据，禁止推测或假设任务已完成**

- **已完成**（✅）：**仅包含已通过验证的交付成果**
  - **验证标准**：必须同时满足以下条件才能标记为"已完成"：
    1. 有明确的执行记录（如代码已提交、文件已创建、功能已测试）
    2. 有验证证据（如测试通过、代码审查通过、功能运行正常、错误已修复）
    3. 达到验收标准（如满足性能指标、通过所有测试用例、满足我的需求）
    4. **代码开发任务额外要求（必须全部满足）**：
       - ✅ **编译/构建必须通过**：代码必须能够成功编译/构建，无编译错误、无语法错误、无链接错误、无类型错误
       - ✅ **功能必须验证**：功能必须经过实际运行验证，不能仅凭代码存在就认为完成
       - ✅ **错误必须修复**：如果存在编译错误、运行时错误、测试失败，必须明确标记为"未完成"或"部分完成"，不能标记为"已完成"
       - ✅ **测试必须通过**：如果有测试用例，必须通过测试；如果没有测试，必须手动验证功能正常
       - ✅ **代码质量检查**：代码必须符合项目规范，无明显的代码质量问题
  - 格式："[优先级] [交付物] - [验证方式] - [验证证据] - [编译/构建状态] - [功能验证状态]"
  - 示例："P0 用户表结构设计 - 已通过代码审查 - 审查记录：PR#123已合并，测试用例test_user_table通过 - 编译通过，无错误 - 功能已验证，运行正常"
  - **代码开发场景**：必须包含修改的文件路径、函数名、变更类型（新增/修改/删除）、编译状态、测试结果、功能验证结果
  - **禁止行为（严格执行）**：
    - ❌ 不能仅因为"计划执行"或"开始执行"就标记为已完成
    - ❌ 不能因为"看起来应该完成"或"理论上应该完成"就标记为已完成
    - ❌ **不能因为"代码已编写"就标记为已完成**（必须验证编译和功能）
    - ❌ **不能在有编译错误时标记为已完成**（编译错误 = 任务未完成，必须标记为"部分完成"或"进行中"）
    - ❌ **不能在有运行时错误时标记为已完成**（运行时错误 = 任务未完成）
    - ❌ **不能在有测试失败时标记为已完成**（测试失败 = 任务未完成）
    - ❌ **不能因为"功能已实现"但仍有错误就标记为已完成**（有错误 = 未完成）
    - ✅ 必须提供具体的验证证据（编译结果、测试结果、运行日志、审查记录等）

- **进行中**（🔄）：已开始但未完成的任务
  - 格式："[优先级] [任务描述] - [当前进度] - [剩余工作]"
  - 示例："P1 实现JWT认证接口 - 已完成接口定义和token生成，待实现token验证逻辑"
  - **代码开发场景**：必须说明已修改的文件、已实现的函数、待实现的函数

- **部分完成**（⚠️）：已完成部分但未达到完整验收标准
  - 格式："[优先级] [任务描述] - [已完成部分] - [缺失部分] - [编译/构建状态] - [错误信息] - [未通过验证项]"
  - 示例："P2 用户登录功能 - 已完成前端UI和后端接口 - 待补充错误处理和日志记录 - 编译通过但有运行时错误 - 错误：登录接口返回500错误 - 测试用例test_error_handling未通过"
  - **代码开发场景**：必须明确说明：
    - 哪些功能已实现
    - 编译/构建状态（通过/失败/有错误）
    - 具体的错误信息（编译错误、运行时错误、测试失败等）
    - 哪些测试未通过
    - 哪些需求未满足
  - **特别注意**：
    - 如果存在编译错误，必须标记为"部分完成"，不能标记为"已完成"
    - 如果存在运行时错误，必须标记为"部分完成"，不能标记为"已完成"
    - 如果存在测试失败，必须标记为"部分完成"，不能标记为"已完成"

- **待完成**（📋）：尚未开始或等待前置依赖的任务
  - 格式："[优先级] [任务描述] - [前置依赖]"
  - 示例："P1 实现JWT认证接口 - 依赖：用户表完成"
  - 必须包含：任务边界、依赖关系
  - **代码开发场景**：必须包含待修改的文件、函数、具体实现要求

#### 3. 关键信息导航系统（快速索引）
- **关键信息位置**（📍）：使用记忆标签建立索引
  - 项目长期记忆：关键架构决策、配置方案、业务规则
  - 全局长期记忆：通用解决方案、最佳实践、技术标准
  - 短期记忆：当前任务的临时数据、调试信息、中间结果

- **关键文件路径**（📁）：建立项目核心文件映射
  - 配置文件：`src/jarvis/config/` - 系统配置和参数
  - 核心代码：`src/jarvis/jarvis_agent/` - 代理核心逻辑
  - 工具定义：`src/jarvis/jarvis_tools/` - 可用工具集合
  - 测试文件：`tests/` - 测试用例和验证脚本
  - 具体文件：提供精确到文件的路径和关键函数位置
  - **代码开发场景**：必须列出所有已修改/待修改的文件完整路径，标注关键函数/类的行号范围

#### 4. 代码开发专项信息（必保保留，防止后续偏离）
- **代码变更详情**（🔧）：
  - 已修改文件清单：每个文件的完整路径、修改类型（新增/修改/删除/重构）- 基于实际验证；如无法获取完整信息可标注"部分信息缺失"
  - 关键变更点：函数/类名、修改位置、变更原因 - 基于实际代码；如代码不可访问可标注"基于可用信息"
  - 代码变更上下文：基于实际验证的变更原因、解决的问题、替代方案验证结果
  - 影响范围分析：基于可用信息的影响评估；如无法完整分析可标注"影响范围待验证"
  - 依赖关系：基于实际项目验证的修改依赖；如无完整依赖信息可标注"依赖关系部分未知"

- **错误与调试信息**（🐛）：
  - **编译错误**：基于实际编译结果的编译错误信息（错误类型、错误位置、错误原因）、修复状态；如果有编译错误，任务必须标记为"部分完成"或"进行中"，不能标记为"已完成"
  - 遇到的错误：基于实际运行记录的错误信息（堆栈、行号、错误类型）、经过验证的复现步骤；如错误无法重现可标注"错误信息待验证"
  - 调试过程：经过验证的解决方案尝试、具体失败原因、基于实际测试的解决方案；如调试受限可标注"调试过程基于现有信息"
  - 性能问题：基于可用测试的性能瓶颈、优化措施、效果评估；如无完整测试可标注"性能数据待补充"
  - 边界情况：基于测试验证的边界条件、异常处理、测试用例；如测试不完整可标注"边界情况部分验证"

- **测试与验证**（✅）：
  - **编译/构建验证**：基于实际编译/构建结果的验证状态（通过/失败/有错误），具体的编译错误信息（如果有）
  - 测试结果：基于实际运行的单元测试、集成测试、手动测试结果
  - 验证方式：具体如何验证功能正确性、性能指标、兼容性的详细步骤
  - 未通过的测试：实际失败的测试、经过分析的具体失败原因、修复状态
  - 测试覆盖：基于实际测试工具验证的代码覆盖情况
  - **功能验证**：功能是否经过实际运行验证，运行是否正常，是否有运行时错误

- **技术决策与权衡**（⚖️）：
  - 技术选型：基于实际评估选择的方案、经过验证其他方案不可行的具体原因
  - 设计决策：基于实际代码分析的架构设计、接口设计、数据结构设计理由
  - 权衡考虑：基于实际测试数据的性能vs可维护性、简单vs扩展性等权衡分析
  - 已知限制：经过实际验证的当前方案局限性、基于实际分析的未来改进方向

- **未完成工作与待办**（📋）：
  - 部分完成的功能：哪些功能已实现但未完成、缺少什么
  - 待修复的问题：已知bug、技术债务、需要重构的代码
  - 待补充的内容：缺少的测试、文档、错误处理、日志
  - 后续优化方向：性能优化、代码重构、功能扩展计划

#### 5. 上下文完整性检查清单（总结前自检 - 所有结论必须经过验证）
- [ ] 整体目标明确且可量化（包含基于实际需求验证的指标）
- [ ] 阶段目标递进且可验证（每个阶段有基于实际结果验证的验收标准）
- [ ] **已完成任务验证检查（关键）**：
  - [ ] 每个"已完成"任务都有明确的执行记录（代码提交、文件创建、功能测试等）
  - [ ] 每个"已完成"任务都有验证证据（测试通过、审查通过、运行正常等）
  - [ ] 每个"已完成"任务都达到验收标准（满足性能指标、通过测试用例等）
  - [ ] **代码开发任务额外检查**：
    - [ ] 编译/构建必须通过（无编译错误、无语法错误、无链接错误）
    - [ ] 功能必须经过实际运行验证（不能仅凭代码存在就认为完成）
    - [ ] 所有测试必须通过（如果有测试用例）
    - [ ] 无运行时错误（功能必须能够正常运行）
  - [ ] 没有将"进行中"或"部分完成"的任务错误标记为"已完成"
  - [ ] 没有基于推测或假设标记任务为"已完成"
  - [ ] **没有在有编译错误时标记为"已完成"**
  - [ ] **没有在有运行时错误时标记为"已完成"**
  - [ ] **没有在有测试失败时标记为"已完成"**
- [ ] 任务状态分类准确（已完成/进行中/部分完成/待完成），每个任务都有明确的状态
- [ ] 待完成任务有基于实际分析的优先级和依赖关系（任务网络清晰且经过验证）
- [ ] 关键信息可通过经过验证的记忆标签快速定位（索引系统有效性已验证）
- [ ] 关键文件路径准确且最新（经过实际文件系统验证）
- [ ] 技术约束和边界条件已基于实际环境验证明确（兼容性和限制经过验证）
- [ ] 后续行动建议具体可操作且基于实际可行性验证（下一步明确指令经过验证）
- [ ] **代码开发专项检查（所有结论必须经过代码验证）**：
  - [ ] 所有已修改文件的完整路径已基于实际git状态验证列出
  - [ ] 关键函数/类的变更原因和上下文已基于实际代码验证说明
  - [ ] **编译/构建状态已验证**：代码必须能够成功编译/构建，无编译错误
  - [ ] **功能验证状态已确认**：功能必须经过实际运行验证，不能仅凭代码存在就认为完成
  - [ ] 遇到的错误和基于实际调试的过程已记录（包括编译错误、运行时错误、测试失败）
  - [ ] 测试结果和具体验证方式已基于实际运行明确
  - [ ] 技术决策的理由和权衡已基于实际分析验证保留
  - [ ] 未完成工作和待办事项已基于实际项目状态验证列出（包括编译错误、运行时错误、测试失败）
  - [ ] 代码变更的影响范围已基于实际依赖分析验证
  - [ ] **错误状态明确**：如果存在编译错误、运行时错误或测试失败，必须明确标记为"部分完成"或"进行中"，不能标记为"已完成"

#### 6. 核心技术与业务信息（必保保留且经过验证）
1. **技术栈与版本**：经过实际检测验证的Python版本、框架版本、关键依赖
2. **架构决策**：基于实际代码验证的技术选型理由、权衡考虑、未来扩展性
3. **配置参数**：基于实际配置文件验证的数据库配置、API密钥、环境变量
4. **代码位置**：经过实际代码验证的核心函数、配置文件、关键算法实现（**必须包含经过验证的精确文件路径和函数签名**）
5. **调试信息**：基于实际运行验证的错误日志、基于性能测试的性能数据、基于实际测试的测试结果（**必须包含经过验证的完整错误堆栈和调试过程**）
6. **接口定义**：经过代码验证的API端点、参数格式、响应结构（**必须包含经过验证的函数签名、参数类型、返回值类型**）
7. **数据模型**：基于实际数据库或ORM验证的数据库表结构、字段定义、关系映射
8. **代码变更历史**：基于实际git log验证的diff摘要、经过验证的关键变更点、可验证的回滚点（**如果系统提供了git diff，必须整合到经过验证的总结中**）

#### 7. 我的偏好与约束（精确记录）
- **质量要求**：代码规范、测试覆盖率、文档标准
- **性能约束**：响应时间、并发量、资源限制
- **兼容性要求**：系统版本、浏览器支持、设备适配
- **禁忌项**：明确禁止的技术方案或实现方式（**必须明确记录，避免后续偏离**）
- **代码风格**：缩进、命名规范、注释要求、代码组织方式

#### 8. 可省略的冗余内容（无需保留）
- 寒暄与无关闲聊（如"您好""谢谢""今天天气不错"）；
- 重复表述（我多次强调的同一需求，仅保留1次核心表述）；
- **注意**：临时试错/未落地的想法如果包含重要信息（如"尝试了XX方案但失败，原因是YY"），必须保留失败原因，不能省略；
- 与任务无关的细节（如"我提及的其他项目经验""无关的技术科普"）。
- **代码开发场景特别注意**：即使某个方案被放弃，如果放弃原因对后续决策有影响，必须保留。

</guidelines>

<format>
1. 语言风格：简洁、客观、专业，使用编程领域规范表述（如"非阻塞IO"而非"不等待的输入输出"）；
2. 结构组织：按"核心目标→已确认事实→决策与共识→技术细节→代码变更详情→任务进展→待办事项→我的约束"的逻辑组织（替代"时间顺序"，更贴合后续对话需求）；
3. 呈现形式：分点列出，关键技术内容用`代码块`/加粗标注，待办事项用"【优先级】+ 内容"明确（如"【高】补充跨域配置"）；
4. **任务状态呈现要求（关键）**：
   - 必须严格区分"已完成"、"进行中"、"部分完成"、"待完成"四种状态
   - "已完成"任务必须提供验证证据（测试结果、运行日志、审查记录等），不能仅凭推测或假设
   - **代码开发任务特别要求（严格执行）**：
     - "已完成"任务必须明确说明编译/构建状态（通过/失败），功能验证状态（已验证/未验证），测试状态（通过/失败）
     - **如果存在编译错误，必须标记为"部分完成"或"进行中"，绝对不能标记为"已完成"**
     - **如果存在运行时错误，必须标记为"部分完成"或"进行中"，绝对不能标记为"已完成"**
     - **如果存在测试失败，必须标记为"部分完成"或"进行中"，绝对不能标记为"已完成"**
     - **不能因为"代码已编写"就标记为"已完成"**（必须验证编译和功能）
   - 如果任务未完成，必须如实标记为"进行中"或"部分完成"，不能错误标记为"已完成"
   - 对于"部分完成"的任务，必须明确说明已完成部分和未完成部分，以及未通过验证的具体项（包括编译错误、运行时错误、测试失败等）
5. **代码变更呈现**：使用结构化格式，例如：
   - 文件：`src/xxx.py`（修改）
   - 函数：`function_name()`（第10-25行，新增）
   - 变更原因：解决XXX问题，因为YYY原因
   - 影响范围：影响`module_a.py`的`func_b()`函数
   - 验证状态：已通过测试/待测试/测试失败（必须如实标注）
6. 长度限制：严格控制在500词以内，优先压缩冗余，不压缩必保信息（**代码开发任务信息较多时，可适当放宽至800词，确保关键信息不丢失**）。
</format>
</summary_request>
"""


def get_task_analysis_prompt(
    has_save_memory: bool = False, has_generate_new_tool: bool = False
) -> str:
    """根据配置返回任务分析提示词

    参数:
        has_save_memory: 是否有 save_memory 工具（工具可用性）
        has_generate_new_tool: 是否有 meta_agent 工具（原 generate_new_tool，自举式工具生成器）
    """
    # 第一步：记忆保存部分
    if not has_save_memory:
        # 如果没有 save_memory 工具，说明无法保存记忆
        memory_step = """第一步：记忆值得保存的信息
1. 识别任务中的关键信息和知识点
2. 评估是否有值得保存的项目长期记忆或全局长期记忆
3. 注意：当前环境不支持 save_memory 工具，无法保存记忆。请直接说明识别到的关键信息即可。"""
    else:
        # 有 save_memory 工具
        memory_step = """第一步：记忆值得保存的信息
1. 识别任务中的关键信息和知识点
2. 评估是否有值得保存的项目长期记忆或全局长期记忆
3. 如果有价值，使用 save_memory 工具保存有价值的信息：
   - project_long_term: 保存与当前项目相关的长期信息（如项目配置、架构决策、开发规范等）
   - global_long_term: 保存通用的信息、用户偏好、知识或方法（如技术知识、最佳实践、用户习惯等）"""

    # 第二步：工具/方法论分析部分
    if has_generate_new_tool:
        solution_step = """第二步：分析任务解决方案
1. 检查现有工具或方法论是否已经可以完成该任务，如果可以，直接说明即可，无需生成新内容
2. 如果现有工具/方法论不足，评估当前任务是否可以通过编写新工具来自动化解决
3. 如果可以通过工具解决，请使用 meta_agent 工具创建或改进工具：
   - 使用 meta_agent 工具，传入 tool_name 和 function_description 参数
   - 工具将利用 CodeAgent/Agent 智能分析需求，自动生成或改进具备自举和自进化能力的完整工具代码
   - 生成/改进后的工具将自动集成到 Jarvis 生态系统，支持编排 Agent 和 CodeAgent 处理复杂任务
4. 如果无法通过编写通用工具完成，评估当前的执行流程是否可以总结为通用方法论
5. 如果以上都不可行，给出详细理由"""
    else:
        solution_step = """第二步：分析任务解决方案
1. 检查现有工具或方法论是否已经可以完成该任务，如果可以，直接说明即可，无需生成新内容
2. 如果现有工具/方法论不足，评估当前任务是否可以通过编写新工具来自动化解决
3. 如果可以通过工具解决，请优先使用 meta_agent 工具创建/改进新工具（如果环境支持），否则手动提供工具代码
4. 如果无法通过编写通用工具完成，评估当前的执行流程是否可以总结为通用方法论
5. 如果以上都不可行，给出详细理由"""

    # 输出要求部分
    if has_generate_new_tool:
        output_requirements = f"""<output_requirements>
根据分析结果，输出以下三种情况之一：
1. 如果现有工具/方法论可以解决，直接输出说明：
已有工具/方法论可以解决该问题，无需创建新内容。
可用的工具/方法论：[列出工具名称或方法论名称]
使用方法：[简要说明如何使用]
2. 工具创建（如果需要创建新工具）:
{ot("TOOL_CALL")}
{{
  "want": "创建新工具来解决XXX问题",
  "name": "meta_agent",
  "arguments": {{
    "tool_name": "工具名称",
    "function_description": "工具的详细功能描述，说明工具要解决的具体问题和预期行为"
  }}
}}
{ct("TOOL_CALL")}

注意：tool_code 参数推荐使用 ||| 或 ``` 分隔符包裹多行代码，直接换行无需转义，支持保留缩进。
3. 方法论创建（如果需要创建新方法论）:
判断标准：
- 如果方法论特定于当前项目（如项目特定的技术方案、开发流程、规范等），使用 scope="project"
- 如果方法论适用于任何项目（如通用流程、最佳实践、解决方案等），使用 scope="global" 或省略该参数（默认为global）

{ot("TOOL_CALL")}
{{
  "want": "添加/更新xxxx的方法论",
  "name": "methodology",
  "arguments": {{
    "operation": "add/update",
    "problem_type": "方法论类型，不要过于细节，也不要过于泛化",
    "scope": "可选值：'project' 或 'global'（默认）。'project' 保存到项目目录（.jarvis/methodologies/），适用于项目特定的方法论；'global' 保存为全局方法论（用户数据目录），适用于任何项目的通用方法论",
    "content": |||
方法论内容
可以包含多行内容
推荐使用 ||| 或 ``` 分隔符包裹多行字符串，直接换行无需转义，支持保留缩进
包含"双引号"和'单引号'都无需转义
    |||
  }}
}}
{ct("TOOL_CALL")}

注意：如果 content 参数包含多行内容，推荐使用 ||| 或 ``` 分隔符包裹，直接换行无需转义，支持保留缩进。
如果以上三种情况都不适用，则直接输出原因分析，不要使用工具调用格式。
</output_requirements>"""
    else:
        output_requirements = f"""<output_requirements>
根据分析结果，输出以下三种情况之一：
1. 如果现有工具/方法论可以解决，直接输出说明：
已有工具/方法论可以解决该问题，无需创建新内容。
可用的工具/方法论：[列出工具名称或方法论名称]
使用方法：[简要说明如何使用]
2. 工具创建（如果需要创建新工具）:
注意：如果环境支持，请使用 meta_agent 工具创建/改进新工具；如果不支持，请提供完整的工具代码和说明，我需要手动创建工具文件。
3. 方法论创建（如果需要创建新方法论）:
判断标准：
- 如果方法论特定于当前项目（如项目特定的技术方案、开发流程、规范等），使用 scope="project"
- 如果方法论适用于任何项目（如通用流程、最佳实践、解决方案等），使用 scope="global" 或省略该参数（默认为global）

{ot("TOOL_CALL")}
{{
  "want": "添加/更新xxxx的方法论",
  "name": "methodology",
  "arguments": {{
    "operation": "add/update",
    "problem_type": "方法论类型，不要过于细节，也不要过于泛化",
    "scope": "可选值：'project' 或 'global'（默认）。'project' 保存到项目目录（.jarvis/methodologies/），适用于项目特定的方法论；'global' 保存为全局方法论（用户数据目录），适用于任何项目的通用方法论",
    "content": |||
方法论内容
可以包含多行内容
推荐使用 ||| 或 ``` 分隔符包裹多行字符串，直接换行无需转义，支持保留缩进
包含"双引号"和'单引号'都无需转义
    |||
  }}
}}
{ct("TOOL_CALL")}

注意：如果 content 参数包含多行内容，推荐使用 ||| 或 ``` 分隔符包裹，直接换行无需转义，支持保留缩进。
如果以上三种情况都不适用，则直接输出原因分析，不要使用工具调用格式。
</output_requirements>"""

    return f"""<task_analysis>
<request>
当前任务已结束，请按以下步骤分析该任务：

{memory_step}

{solution_step}

请根据分析结果采取相应行动。

重要提示：每次只能执行一个操作！
- 如果有记忆需要保存，可以调用一次 save_memory 批量保存多条记忆
- 保存完所有记忆后，再进行工具/方法论的创建或说明
- 不要在一次响应中同时调用多个工具（如同时保存记忆和创建工具/方法论）
</request>
<evaluation_criteria>
现有资源评估: 检查现有工具/方法论/组合使用是否可解决问题
工具评估: 通用性、自动化、可靠性、简单性
方法论评估: 聚焦通用可重复流程，纳入我的反馈，面向未来复用
</evaluation_criteria>
<tool_requirements>
工具代码要求:
1. 工具类名与工具名称一致，包含name、description、parameters属性，实现execute方法
2. 参数定义遵循JSON Schema，工具调用使用Jsonnet格式（支持 ||| 或 ``` 分隔符多行字符串、尾随逗号）
3. 使用print显示执行过程，返回{{success, stdout, stderr}}结构化结果
4. 妥善处理异常，失败时清理资源。如需调用大模型，创建独立实例避免干扰主流程
</tool_requirements>
<methodology_requirements>
方法论格式: 问题重述、可复用解决流程（步骤化+工具）、注意事项、可选步骤
</methodology_requirements>
{output_requirements}
</task_analysis>"""


# 为了向后兼容，保留原来的常量（使用默认参数，假设有 save_memory 工具）
TASK_ANALYSIS_PROMPT = get_task_analysis_prompt(has_save_memory=True)
