后端: 1. Prompt 层从 execute 专属骨架重构为全节点统一四段式 buildUnifiedStageMessages - 新增 unified_context.go:定义 StageMessagesConfig + buildUnifiedStageMessages 统一骨架,所有节点(Chat/Plan/Execute/Deliver/DeepAnswer)共用同一套 msg0~msg3 拼装逻辑 - 新增 conversation_view.go:通用对话历史渲染 buildConversationHistoryMessage,各节点复用,不再各自维护提取逻辑 - 新增 chat_context.go / plan_context.go / deliver_context.go:各节点自行渲染 msg1(对话视图)和 msg2(工作区),统一层只负责"怎么拼",不再替节点决定"放什么" - Chat/Plan/Deliver/Execute 的 BuildXXXMessages 全部从 buildStageMessages 切到 buildUnifiedStageMessages,移除旧路径 - 删除 execute_pinned.go:execute 记忆渲染合并到统一层 renderUnifiedMemoryContext - Plan prompt 不再在 user prompt 中拼装任务类 ID 列表和 renderStateSummary,改为依赖 msg2 规划工作区;Chat 粗排判断从"上下文有任务类 ID"改为"批量调度需求" - Deliver prompt 新增 IsAborted/IsExhaustedTerminal 区分,支持粗排收口和主动终止场景 2. Execute ReAct 上下文简化——移除归档搬运、窗口裁剪和重复工具压缩 - 移除 splitExecuteLoopRecordsByBoundary、findLatestExecuteBoundaryMarker、tailExecuteLoops、compressExecuteLoopObservationsByTool、buildEarlyExecuteReactSummary、trimExecuteMessage1ByBudget 等六个函数 - 移除 executeLoopWindowLimit / executeConversationTurnLimit / executeMessage1MaxRunes 等预算常量 - msg1 不再从历史中归档上一轮 ReAct 结果,只保留真实对话流(user + assistant speak),全量注入 - msg2 不再按 loop_closed / step_advanced 边界切分"归档/活跃",直接全量注入全部 ReAct Loop 记录 - token 预算由统一压缩层兜底,prompt 层不再做提前裁剪 3. 压缩层从 Execute 专属提升为全节点通用 UnifiedCompact - 删除 execute_compact.go(Execute 专属压缩文件) - 新增 unified_compact.go:UnifiedCompactInput 参数化,各节点(Plan/Chat/Deliver/Execute)构造时从自己的 NodeInput 提取公共字段,消除对 Execute 的直接依赖 - CompactionStore 接口扩展 LoadStageCompaction / SaveStageCompaction,各节点按 stageKey 独立维护压缩状态互不覆盖 - 非 4 段式消息时退化成按角色汇总统计,确保 context_token_stats 仍然刷新 4. Retry 重试机制全面下线 - dao/agent.go:saveChatHistoryCore / SaveChatHistory / SaveChatHistoryInTx 移除 retry_group_id / retry_index / retry_from_user_message_id / retry_from_assistant_message_id 四个参数,修复乱码注释 - dao/agent-cache.go:移除 ApplyRetrySeed 和 extractMessageHistoryID 两个方法 - conv/agent.go:ToEinoMessages 不再回灌 retry_* 字段到运行期上下文 - service/agentsvc/agent.go:移除 chatRetryMeta 及 resolveRetryGroupID / buildRetrySeed 等全部重试逻辑 - service/agentsvc/agent_quick_note.go:整个文件删除(retry 快速补写路径已无用) - service/events/chat_history_persist.go:移除 retry 参数传递 5. 节点层瘦身 + 可见消息逐条持久化 - agent_nodes.go 大幅简化:Chat/Plan/Execute/Deliver 节点方法移除 ToolSchema 注入、状态摘要渲染等逻辑,只做参数转发和状态落盘 - 新增 visible_message.go:persistVisibleAssistantMessage 统一处理可见 assistant speak 的实时持久化,失败仅记日志不中断主流程 - 新增 llm_debug.go:logNodeLLMContext 统一打印 LLM 上下文调试日志 - graph_run_state.go 新增 PersistVisibleMessageFunc 类型 + AgentGraphDeps.PersistVisibleMessage 字段 - service/agentsvc/agent_newagent.go 精简主循环,注入 PersistVisibleMessage 回调;agent_history.go 精简历史构建 - token_budget.go 移除 Execute 专属预算检查,统一到通用预算 前端: 1. 移除 retry 相关 UI 和类型 - agent.ts 移除 retry_group_id / retry_index / retry_total 字段及 normalize 逻辑 - AssistantPanel.vue 移除 retry 相关 UI 和交互代码(约 700 行精简) - dashboard.ts 移除 retry 相关类型定义 - AssistantView.vue 微调 2. ContextWindowMeter 压缩次数展示和数值格式优化 - 新增 formatCompactCount 工具函数,千位以上用 k 单位压缩(如 80k) - 新增压缩次数显示 3.修复了新对话发消息时,user和assistant消息被自动调换的bug 仓库:无
142 lines
5.9 KiB
Go
142 lines
5.9 KiB
Go
package newagentprompt
|
||
|
||
import (
|
||
"fmt"
|
||
"strings"
|
||
|
||
newagentmodel "github.com/LoveLosita/smartflow/backend/newAgent/model"
|
||
"github.com/cloudwego/eino/schema"
|
||
)
|
||
|
||
const planSystemPrompt = `
|
||
你是 SmartMate 的规划器。
|
||
你的职责不是直接执行任务,而是先把用户意图拆成一组清晰、稳定、可逐步执行的自然语言计划,并严格按后端约定的 JSON 协议输出。
|
||
|
||
请遵守以下规则:
|
||
1. 只负责规划,不要假装已经调用了工具,也不要伪造执行结果。
|
||
2. 每一轮只推进一步规划;如果信息不足,应明确转成 ask_user,而不是继续硬猜。
|
||
3. 若当前计划仍不完整,就继续围绕当前任务补全计划,不要跳去执行细节。
|
||
4. 若你认为计划已经完整可执行,请返回 action=plan_done,并附带完整 plan_steps。
|
||
5. plan_steps 必须使用自然语言,便于后端将完整 plan 重新注入到后续上下文顶部。
|
||
6. 只输出 JSON,不要输出 markdown,不要输出额外解释,不要在 JSON 外再补文字。
|
||
7. 每次输出前先评估任务复杂度:simple(简单明确,无复杂依赖)、moderate(多步操作,需要一定推理)、complex(需要深度推理、多方案比较或复杂依赖关系)。
|
||
8. 粗排识别规则:若满足以下两个条件,在 action=plan_done 时附加 needs_rough_build=true 和 task_class_ids:
|
||
条件1:用户输入中存在"任务类 ID"字段(见上下文"任务类 ID"部分);
|
||
条件2:用户意图明确是"批量安排/帮我排课/把任务类排进日程"等批量调度需求。
|
||
满足时:后端会在用户确认计划后自动运行粗排算法(硬性约束已由算法保证,无需 LLM 校验)。
|
||
你的 plan_steps 应聚焦于"用读写工具优化方案",建议两步:
|
||
第1步:用 get_overview / query_target_tasks / query_available_slots 等读工具审视粗排结果,找出可优化的点(时段分布不均、空位未利用等);
|
||
第2步:用 move / batch_move 等写工具微调后,将最终方案展示给用户确认。
|
||
禁止安排任何"校验/验证约束"步骤——硬性约束由算法兜底,LLM 不需要操心。
|
||
|
||
你会看到:
|
||
- 当前阶段与轮次信息
|
||
- 已有完整 plan(如果之前已经规划过)
|
||
- 当前步骤(如果已存在)
|
||
- 置顶上下文块
|
||
- 可用工具摘要
|
||
- 历史对话
|
||
|
||
请基于这些输入继续规划,而不是重复忽略既有 plan。
|
||
`
|
||
|
||
// BuildPlanSystemPrompt 返回规划阶段系统提示词。
|
||
func BuildPlanSystemPrompt() string {
|
||
return strings.TrimSpace(planSystemPrompt)
|
||
}
|
||
|
||
// BuildPlanMessages 组装规划阶段的 messages。
|
||
//
|
||
// 职责边界:
|
||
// 1. 负责把 state + context 收敛成统一 4 段式规划阶段模型输入;
|
||
// 2. 不负责解析模型输出,也不负责判断规划质量;
|
||
// 3. msg3 中的状态文本由本函数显式传入,确保统一骨架下仍能看到完整计划与阶段信息。
|
||
func BuildPlanMessages(state *newagentmodel.CommonState, ctx *newagentmodel.ConversationContext, userInput string) []*schema.Message {
|
||
return buildUnifiedStageMessages(
|
||
ctx,
|
||
StageMessagesConfig{
|
||
SystemPrompt: BuildPlanSystemPrompt(),
|
||
Msg1Content: buildPlanConversationMessage(ctx),
|
||
Msg2Content: buildPlanWorkspace(state),
|
||
Msg3Suffix: BuildPlanUserPrompt(state, userInput),
|
||
Msg3Role: schema.User,
|
||
},
|
||
)
|
||
}
|
||
|
||
// BuildPlanUserPrompt 构造规划阶段的用户提示词。
|
||
func BuildPlanUserPrompt(state *newagentmodel.CommonState, userInput string) string {
|
||
var sb strings.Builder
|
||
|
||
sb.WriteString("请继续当前任务的规划阶段,严格输出 JSON。\n")
|
||
sb.WriteString("目标:围绕最近对话和规划工作区信息,产出一份稳定、可执行的自然语言计划;若关键信息不足,请明确 ask_user。\n\n")
|
||
sb.WriteString(BuildPlanDecisionContractText())
|
||
|
||
trimmedInput := strings.TrimSpace(userInput)
|
||
if trimmedInput != "" {
|
||
sb.WriteString("\n用户本轮输入:\n")
|
||
sb.WriteString(trimmedInput)
|
||
sb.WriteString("\n")
|
||
}
|
||
|
||
return strings.TrimSpace(sb.String())
|
||
}
|
||
|
||
// BuildPlanDecisionContractText 返回规划阶段的输出协议说明。
|
||
func BuildPlanDecisionContractText() string {
|
||
return strings.TrimSpace(fmt.Sprintf(`
|
||
输出协议(严格 JSON):
|
||
- speak:给用户看的话;若 action=%s,这里通常就是要追问用户的问题
|
||
- action:只能是 %s / %s / %s
|
||
- reason:给后端和日志看的简短说明
|
||
- complexity:任务复杂度,只能是 simple / moderate / complex
|
||
- plan_steps:仅当 action=%s 时允许返回;返回时必须是完整计划,不是增量
|
||
- plan_steps[].content:步骤正文,必填
|
||
- plan_steps[].done_when:可选,建议写"什么情况下算这一步做完"
|
||
- needs_rough_build:仅当满足粗排识别规则时为 true,否则省略;为 true 时后端自动运行粗排算法
|
||
- task_class_ids:needs_rough_build=true 时必填,从上下文"任务类 ID"字段读取
|
||
|
||
合法示例:
|
||
{
|
||
"speak": "我先把计划再收束一下。",
|
||
"action": "%s",
|
||
"reason": "当前信息已足够继续规划",
|
||
"complexity": "moderate",
|
||
}
|
||
|
||
{
|
||
"speak": "你更希望我优先安排今天,还是按整周来规划?",
|
||
"action": "%s",
|
||
"reason": "当前时间范围仍不明确",
|
||
"complexity": "simple",
|
||
}
|
||
|
||
{
|
||
"speak": "计划已经整理好了,我先给你确认一下。",
|
||
"action": "%s",
|
||
"reason": "当前计划已具备执行条件",
|
||
"complexity": "simple",
|
||
|
||
"plan_steps": [
|
||
{
|
||
"content": "先确认本周可用时间范围",
|
||
"done_when": "拿到明确的可用时间段列表"
|
||
},
|
||
{
|
||
"content": "基于可用时间生成执行安排",
|
||
"done_when": "得到一份用户可确认的安排方案"
|
||
}
|
||
]
|
||
}
|
||
`,
|
||
newagentmodel.PlanActionAskUser,
|
||
newagentmodel.PlanActionContinue,
|
||
newagentmodel.PlanActionAskUser,
|
||
newagentmodel.PlanActionDone,
|
||
newagentmodel.PlanActionDone,
|
||
newagentmodel.PlanActionContinue,
|
||
newagentmodel.PlanActionAskUser,
|
||
newagentmodel.PlanActionDone,
|
||
))
|
||
}
|