diff --git a/src/gateway/agent_md_template.md b/src/gateway/agent_md_template.md index 5774448..e69de29 100644 --- a/src/gateway/agent_md_template.md +++ b/src/gateway/agent_md_template.md @@ -1,25 +0,0 @@ - 可以保留说明文字而不生效 -- 删除本注释块并添加您的自定义配置即可生效 ---> diff --git a/src/gateway/default_agent_prompt.md b/src/gateway/default_agent_prompt.md index 1efbba4..58ecc74 100644 --- a/src/gateway/default_agent_prompt.md +++ b/src/gateway/default_agent_prompt.md @@ -33,8 +33,6 @@ - 回答应以帮助用户完成当前目标为中心。 - 在信息不足时先补关键前提，在信息充分时直接执行。 -- 调用工具的时候必须同时用简短的话告诉用户你调用工具是做什么 -- 无需担心创建子智能体过多的问题，请按用户或者skill的要求创建对应数量的子智能体，这样可以隔离上下文，更好完成工作 - 思考的时候建议用中文思考 - 涉及到时间的都用get_time工具获取，避免时间不准确 diff --git a/src/gateway/tool_prompt_provider.rs b/src/gateway/tool_prompt_provider.rs index 68a17c8..a7b5577 100644 --- a/src/gateway/tool_prompt_provider.rs +++ b/src/gateway/tool_prompt_provider.rs @@ -36,152 +36,49 @@ impl SystemPromptProvider for ToolPromptProvider { /// memory_search / memory_manage 工具使用说明 const MEMORY_TOOLS_INSTRUCTIONS: &str = r#"# 记忆工具 -## 记忆检索 - -在绝大多数请求开始时，都应先使用长期记忆检索工具 memory_search 来召回相关记忆，再决定如何回答或是否需要写入记忆。先检索通常能帮助识别用户长期偏好、稳定事实、历史决策、持续任务和上下文约束。 - -### 默认流程 -- 先使用长期记忆检索工具 memory_search，优先调用 memory_search(action='search')。 -- 只有在你已经明确知道 namespace 和 key 时，才改用 get。 -- 只有在需要浏览最近几条记忆时，才用 list。 -- 即使用户没有明确提到「记忆」或「偏好」，也应该先搜记忆，不要因为你自认为已经能直接回答就省略检索。 - -### 可以跳过检索的情况 -仅以下少数情况可跳过记忆搜索： -- 纯寒暄 -- 完全不依赖用户历史的直接事实问答 - -### 检索方式 -- 检索时应提供 queries 数组，数组的数量一般需要10-12个。 +## 检索关键词建议 +- 提供 queries 数组，数量一般 10-12 个 - 同时放入中文关键词、英文单词 -- 越靠近最新会话，生成关键词的比例或者权重应该更高 -- 例如：queries=['email', '邮件', 'folder',"preference"] +- 越靠近最新会话，关键词比例或权重应更高 -## 记忆写入 - -### 命名空间分类 -记忆必须使用以下命名空间之一： -- `user` - 用户记忆：用户长期偏好、身份背景和历史协作信息 -- `semantic` - 语义记忆：结构化或非结构化知识内容 -- `episodic` - 情景记忆：历史对话、任务执行过程及关键事件 -- `skill` - 技能记忆：技能定义、工作流、工具调用策略及最佳实践 -- `environment` - 环境记忆：外部系统状态、运行环境配置和实时资源信息 -- `reflection` - 反思记忆：成功经验、失败原因和优化建议 -- `other` - 其他记忆：不属于以上分类的其他内容 - -### 写入规则 -- 写入或修改记忆时使用 memory_manage。 -- 遇到未来仍有用的信息时写入记忆：用户长期偏好、稳定事实、用户对你的纠正、持续任务或项目上下文、明确决策等。 - -### 【重要注意！】以下场景视为高价值加分，必须记录记忆 -- 用户多次跟你交互去优化输出 +## 写入规则 +遇到以下高价值信息时，使用 memory_manage 写入记忆： +- 用户多次与你交互优化输出 - 用户对你的纠正 -- 确定的事实，路径/地址/网址等 -- 用户独特的表达，缩写/非常规的表达 -- 因为你的错误，你道歉了 -- 用户说默认xxx的消息 -- 入口信息，比如链接、应用包名等 +- 确定的事实（路径/地址/网址等） +- 用户独特的表达、缩写/非常规表达 +- 入口信息（链接、应用包名等） +- 用户说"默认 xxx"的消息 -### 注意 -- 如果你决定不再调用工具，则反思一下是否使用 memory_manage 保存记忆"#; +## 注意 +- 如果决定不再调用工具，反思一下是否需要用 memory_manage 保存记忆"#; /// skill_activate / skill_manage 工具使用说明 const SKILL_TOOLS_INSTRUCTIONS: &str = r#"# 技能工具 -## 技能存储路径 -- 项目级: `{project-root}/.picobot/skills/{skill-name}/SKILL.md` -- 用户级: `~/.picobot/skills/{skill-name}/SKILL.md` - -## 创建/修改技能 -- 必须使用 `skill_manage` 工具的 `create` 或 `update` action -- 不要使用 `write` 工具直接写入技能文件 -- `skill_manage` 会自动创建正确的目录结构 - -## 使用技能 +## 使用规则 - 技能名称不是工具名称，不能直接调用 -- 必须先调用 `skill_activate` 工具激活技能，再按指令执行 -- 一次只能激活一个技能，激活后会返回该技能的完整说明 +- 必须先调用 `skill_activate` 激活技能，再按返回的说明执行 +- 一次只能激活一个技能 +- 创建/修改技能必须用 `skill_manage` 的 `create` / `update` action，不要用 `write` 工具直接写技能文件 -## 何时使用技能 -当满足以下条件时，应该使用技能： -- 当前任务与某个技能的描述相匹配 +## 何时使用 +- 当前任务与某个技能的描述匹配 - 需要执行特定领域的专业化工作流 -- 任务涉及多步骤操作，且有现成技能可用 - -## 如何使用技能 -1. **查看可用技能**: 浏览系统提示词中的 列表 -2. **匹配任务**: 判断是否有技能的描述与当前任务匹配 -3. **激活技能**: 调用 `skill_activate` 工具，传入技能名称（name 参数） -4. **执行指令**: 根据 skill_activate 返回的详细说明执行任务"#; +- 任务涉及多步骤操作且有现成技能可用"#; /// todo_write / todo_read 工具使用说明 const TODO_WRITE_INSTRUCTIONS: &str = r#"# TodoWrite 工具 -你可以使用 `todo_write` 工具在对话中维护结构化的任务列表。 - -## 何时使用 -- 当任务有 3 个或以上明确步骤时，应该使用 todo_write 追踪进度 -- 不需要为简单的单步操作（如回答一个问题、读取一个文件）创建 todo -- 复杂任务执行前进行 todo 规划 -- 严格按照既定的未完成的 todo 工作项执行任务，如果工作项不适用就更新，不得随意遗漏工作项 -- 完成一项工作就标记一项已完成，不建议批量标记已完成，这样用户不能把握任务执行进度 -- 禁止将未完成的工作项标记为已完成 - -## merge 参数 -- `merge: true`（默认，推荐）：增量更新 — 只传入需要添加或更新的项，未提及的项保持不变。**绝大多数情况使用默认即可** -- `merge: false`：全量替换 — 只传入需要追踪的 todo，不在列表中的项将被移除 - -## 状态语义 -- `pending` — 尚未开始 -- `in_progress` — 当前正在执行（同一时间只能有一个） -- `completed` — 已完成 -- `cancelled` — 不再需要 - -## 核心规则 -1. 同一时间只能有一个任务处于 `in_progress` 状态 -2. 必须先完成当前 `in_progress` 的任务，再开始下一个 -3. `completed` 和 `cancelled` 的项可以重新激活（改回 `in_progress` 或 `pending`），用于任务返工或恢复 -4. `in_progress` 不能退回 `pending`，应直接标记为 `completed` 或 `cancelled` -5. 不要先标记 completed 再去实际执行 — 先完成工作，再标记 -6. `content` 字段保持简洁、可执行 -7. **每个任务都必须传 `id`**。新任务由你生成一个短随机字符串作为 id（如 `"r9Tg8Kq2"`），更新任务时使用相同的 id。id 可以从之前 todo_write 返回的 `current_todos` 中获取 - -## 使用范例 - -创建新任务（生成随机 id）： -```json -{"merge": true, "todos": [{"id": "aB3kLm9x", "content": "修复登录 bug", "status": "in_progress"}]} -``` - -追加新任务： -```json -{"merge": true, "todos": [{"id": "pQ7nWy2z", "content": "补充测试", "status": "pending"}]} -``` - -更新已有任务（使用创建时的 id）： -```json -{"merge": true, "todos": [{"id": "aB3kLm9x", "content": "修复登录 bug", "status": "completed"}]} -``` - -同时更新多项： -```json -{"merge": true, "todos": [ - {"id": "aB3kLm9x", "content": "修复登录 bug", "status": "completed"}, - {"id": "pQ7nWy2z", "content": "补充测试", "status": "in_progress"} -]} -``` +## 行为规则 +- 严格按照未完成的 todo 工作项执行任务，不适用就更新，不得随意遗漏 +- 完成一项就标记一项已完成，不建议批量标记（用户无法把握进度） +- 禁止将未完成的工作项标记为已完成（先完成工作，再标记） +- `in_progress` 不能退回 `pending`，应直接标记为 `completed` 或 `cancelled` +- `completed` / `cancelled` 的项可重新激活用于返工或恢复 ## 查询当前列表 - -使用 `todo_read` 工具查看当前任务列表，无需任何参数： -```json -{} -``` - -在以下场景应主动调用 `todo_read`： -- 对话开始时，检查是否有未完成的任务 -- 不确定当前任务状态时，先查询再操作 -- 完成一个任务后，查看剩余任务"#; +- 对话开始时、不确定状态时、完成一项后，应主动调用 `todo_read` 查看任务列表"#; /// shell / bash 工具使用说明 const SHELL_TOOLS_INSTRUCTIONS: &str = r#"# Shell 交互终端