jarvis-ai-assistant 0.7.8__py3-none-any.whl → 1.0.2__py3-none-any.whl

jarvis/jarvis_agent/prompts.py

@@ -1,72 +1,337 @@
 # -*- coding: utf-8 -*-
-from jarvis.jarvis_utils.tag import ct, ot
+from jarvis.jarvis_utils.tag import ct
+from jarvis.jarvis_utils.tag import ot
 
 DEFAULT_SUMMARY_PROMPT = """<report>
-请生成任务执行的简明总结报告，包括：
+请生成任务执行的上下文结构化总结报告，作为后续对话的"无关键信息缺失"上下文支撑：
 
 <content>
-1. 任务目标：任务重述
-2. 执行结果：成功/失败
-3. 关键信息：执行过程中提取的重要信息
-4. 重要发现：任何值得注意的发现
-5. 无效方案总结：如果当前是在修复问题，请总结尝试过但无效的方案，避免后续重复尝试
-   - 已尝试的方法及其失败原因
-   - 排除的错误假设
-   - 不可行的解决路径
-6. 后续建议：如果有的话
+#### 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>
-"""
+</report>"""
 
 SUMMARY_REQUEST_PROMPT = """<summary_request>
 <objective>
-请对当前对话历史进行精准总结，核心目标是为后续对话提供“无关键信息缺失”的上下文支撑：既要提炼核心逻辑，又要完整保留影响后续决策/操作的关键细节，确保后续对话无需回溯原始历史即可顺畅推进。
+请对当前对话历史进行精准总结，核心目标是为后续对话提供"无关键信息缺失"的上下文支撑：既要提炼核心逻辑，又要完整保留影响后续决策/操作的关键细节，确保后续对话无需回溯原始历史即可顺畅推进。
+
+**特别针对代码开发任务**：必须完整保留代码变更的上下文、原因、影响范围、错误信息、调试过程、测试结果等关键信息，避免后续大模型因信息缺失而偏离方向。
 </objective>
 
-<guidelines>
-#### 一、必保保留的关键信息（按优先级排序，不可遗漏）
-1. 核心目标与边界：用户最终要完成的任务（含量化指标，如“3天内实现接口”“QPS≥1000”）、明确排除的范围（如“暂不支持批量上传”）；
-2. 已确认的关键事实：技术栈（含版本，如“Python 3.9 + Django 4.2”）、环境配置（如“测试环境地址：http://test.example.com”）、数据/参数（如“数据库表名：user_info，分页大小：20条”）；
-3. 重要决策与共识：双方确认的方案（如“选用JWT做身份验证”）、否定的方案（如“排除Redis集群，用单机缓存”）、决策依据（如“因团队无K8s运维经验，选择Docker Compose”）；
-4. 技术细节（精准保留，不简化）：
-   - 可直接复用的内容：完整命令（如“pip install requests==2.31.0”）、代码片段（关键逻辑，用`代码块`标注）、文件路径（如“/data/logs/app.log”）、接口地址/参数（如“POST /api/login，必填字段：phone/code”）；
-   - 报错与调试信息：错误类型（如“IndexError”）、报错关键词（如“list index out of range”）、已尝试的有效/无效操作（如“修改索引为[-1]无效，更换httpx库报错消失”）；
-5. 任务进展与待办：
-   - 已完成步骤（如“已完成数据库表设计，已编写登录接口草稿”）；
-   - 待解决问题（明确优先级，如“高：跨域问题未处理；中：异常捕获逻辑待补充”）；
-   - 待确认/待补充信息（明确责任人与需求，如“用户需提供：测试数据库账号；助手需补充：接口文档示例”）；
-6. 用户偏好与约束：明确要求（如“代码需加注释”“输出JSON格式”）、限制条件（如“服务器内存4GB”“需兼容Windows 10”）、禁忌项（如“不可使用第三方ORM”）。
-
-#### 二、可省略的冗余内容（无需保留）
-- 寒暄与无关闲聊（如“您好”“谢谢”“今天天气不错”）；
+#### 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方案”，未确认的不保留）；
-- 与任务无关的细节（如“用户提及的其他项目经验”“无关的技术科普”）。
+- **注意**：临时试错/未落地的想法如果包含重要信息（如"尝试了XX方案但失败，原因是YY"），必须保留失败原因，不能省略；
+- 与任务无关的细节（如"用户提及的其他项目经验""无关的技术科普"）。
+- **代码开发场景特别注意**：即使某个方案被放弃，如果放弃原因对后续决策有影响，必须保留。
+
 </guidelines>
 
 <format>
-1. 语言风格：简洁、客观、专业，使用编程领域规范表述（如“非阻塞IO”而非“不等待的输入输出”）；
-2. 结构组织：按“核心目标→已确认事实→决策与共识→技术细节→任务进展→待办事项→用户约束”的逻辑组织（替代“时间顺序”，更贴合后续对话需求）；
-3. 呈现形式：分点列出，关键技术内容用`代码块`/加粗标注，待办事项用“【优先级】+ 内容 + 责任人”明确（如“【高】补充跨域配置 - 助手”）；
-4. 长度限制：严格控制在500词以内，优先压缩冗余，不压缩必保信息（若必保信息较多，可适当放宽至600词）。
+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
+    has_save_memory: bool = False, has_generate_new_tool: bool = False
 ) -> str:
     """根据配置返回任务分析提示词
-    
+
     参数:
         has_save_memory: 是否有 save_memory 工具（工具可用性）
-        has_generate_new_tool: 是否有 generate_new_tool 工具
+        has_generate_new_tool: 是否有 meta_agent 工具（原 generate_new_tool，自举式工具生成器）
     """
     # 第一步：记忆保存部分
     if not has_save_memory:
@@ -83,25 +348,26 @@ def get_task_analysis_prompt(
 3. 如果有价值，使用 save_memory 工具保存有价值的信息：
    - project_long_term: 保存与当前项目相关的长期信息（如项目配置、架构决策、开发规范等）
    - global_long_term: 保存通用的信息、用户偏好、知识或方法（如技术知识、最佳实践、用户习惯等）"""
-    
+
     # 第二步：工具/方法论分析部分
     if has_generate_new_tool:
         solution_step = """第二步：分析任务解决方案
 1. 检查现有工具或方法论是否已经可以完成该任务，如果可以，直接说明即可，无需生成新内容
 2. 如果现有工具/方法论不足，评估当前任务是否可以通过编写新工具来自动化解决
-3. 如果可以通过工具解决，请使用 generate_new_tool 工具创建新工具：
-   - 使用 generate_new_tool 工具，传入 tool_name 和 tool_code 参数
-   - tool_code 应包含完整的工具类定义，遵循工具代码要求
+3. 如果可以通过工具解决，请使用 meta_agent 工具创建或改进工具：
+   - 使用 meta_agent 工具，传入 tool_name 和 function_description 参数
+   - 工具将利用 CodeAgent/Agent 智能分析需求，自动生成或改进具备自举和自进化能力的完整工具代码
+   - 生成/改进后的工具将自动集成到 Jarvis 生态系统，支持编排 Agent 和 CodeAgent 处理复杂任务
 4. 如果无法通过编写通用工具完成，评估当前的执行流程是否可以总结为通用方法论
 5. 如果以上都不可行，给出详细理由"""
     else:
         solution_step = """第二步：分析任务解决方案
 1. 检查现有工具或方法论是否已经可以完成该任务，如果可以，直接说明即可，无需生成新内容
 2. 如果现有工具/方法论不足，评估当前任务是否可以通过编写新工具来自动化解决
-3. 如果可以通过工具解决，请设计并提供工具代码（注意：当前环境不支持 generate_new_tool 工具，需要手动创建工具文件）
+3. 如果可以通过工具解决，请优先使用 meta_agent 工具创建/改进新工具（如果环境支持），否则手动提供工具代码
 4. 如果无法通过编写通用工具完成，评估当前的执行流程是否可以总结为通用方法论
 5. 如果以上都不可行，给出详细理由"""
-    
+
     # 输出要求部分
     if has_generate_new_tool:
         output_requirements = f"""<output_requirements>
@@ -114,44 +380,10 @@ def get_task_analysis_prompt(
 {ot("TOOL_CALL")}
 {{
   "want": "创建新工具来解决XXX问题",
-  "name": "generate_new_tool",
+  "name": "meta_agent",
   "arguments": {{
     "tool_name": "工具名称",
-    "tool_code": `# -*- coding: utf-8 -*-
-from typing import Dict, Any
-
-class 工具名称:
-    name = "工具名称"
-    description = "Tool description"
-    parameters = {{
-        "type": "object",
-        "properties": {{
-            # 参数定义
-        }},
-        "required": []
-    }}
-    @staticmethod
-    def check() -> bool:
-        return True
-    def execute(self, args: Dict[str, Any]) -> Dict[str, Any]:
-        try:
-            # 使用print显示执行过程
-            print("ℹ️ 开始执行操作...")
-            # 实现逻辑
-            # ...
-            print("✅ 操作已完成")
-            return {{
-                "success": True,
-                "stdout": "结果输出",
-                "stderr": ""
-            }}
-        except Exception as e:
-            print(f"❌ 操作失败: {{str(e)}}")
-            return {{
-                "success": False,
-                "stdout": "",
-                "stderr": f"操作失败: {{str(e)}}"
-            }}`
+    "function_description": "工具的详细功能描述，说明工具要解决的具体问题和预期行为"
   }}
 }}
 {ct("TOOL_CALL")}
@@ -186,7 +418,7 @@ class 工具名称:
 可用的工具/方法论：[列出工具名称或方法论名称]
 使用方法：[简要说明如何使用]
 2. 工具创建（如果需要创建新工具）:
-注意：当前环境不支持 generate_new_tool 工具。如果需要创建新工具，请提供完整的工具代码和说明，用户需要手动创建工具文件。
+注意：如果环境支持，请使用 meta_agent 工具创建/改进新工具；如果不支持，请提供完整的工具代码和说明，用户需要手动创建工具文件。
 3. 方法论创建（如果需要创建新方法论）:
 {ot("TOOL_CALL")}
 {{
@@ -208,7 +440,7 @@ class 工具名称:
 注意：如果 content 参数包含多行内容，推荐使用 ||| 或 ``` 分隔符包裹，直接换行无需转义，支持保留缩进。
 如果以上三种情况都不适用，则直接输出原因分析，不要使用工具调用格式。
 </output_requirements>"""
-    
+
     return f"""<task_analysis>
 <request>
 当前任务已结束，请按以下步骤分析该任务：

jarvis/jarvis_agent/protocols.py

@@ -1,4 +1,7 @@
-from typing import Any, Protocol, Tuple, runtime_checkable
+from typing import Any
+from typing import Protocol
+from typing import Tuple
+from typing import runtime_checkable
 
 
 @runtime_checkable
@@ -26,4 +29,4 @@ class OutputHandlerProtocol(Protocol):
         返回：
             一个元组，包含一个布尔值（是否返回）和结果。
         """
-        ...
+        ...