后端: 1. execute 主链路重构为“上下文工具域 + 主动优化候选闭环”——移除 order_guard,粗排后默认进入主动微调,先诊断再从后端候选中选择 move/swap,避免 LLM 自由全局乱搜 2. 工具体系升级为动态注入协议——新增 context_tools_add / remove、工具域与二级包映射、主动优化白名单;schedule / taskclass / web 工具按域按包暴露,msg0 规则包与 execute 上下文同步重写 3. analyze_health 升级为主动优化唯一裁判入口——补齐 rhythm / tightness / profile / feasibility 指标、候选扫描与复诊打分、停滞信号、forced imperfection 判定,并把连续优化状态写回运行态 4. 任务类能力并入新 Agent 执行链——新增 upsert_task_class 写工具与启动注入事务写入;任务类模型补充学科画像与整天屏蔽配置,粗排支持 excluded_days_of_week,steady 策略改为基于目标位置/单日负载/分散度/缓冲的候选打分 5. 运行态与路由补齐优化模式语义——新增 active tool domain/packs、pending context hook、active optimize only、taskclass 写入回盘快照;区分 first_full / global_reopt / local_adjust,并完善首次粗排后默认 refine 的判定 前端: 6. 助手时间线渲染细化——推理内容改为独立 reasoning block,支持与工具/状态/正文按时序交错展示,自动收口折叠,修正 confirm reject 恢复动作 仓库: 7. newAgent 文档整体迁入 docs/backend,补充主动优化执行规划与顺序约束拆解文档,删除旧调试日志文件 PS:这次科研了2天,总算是有些进展了——LLM永远只适合做选择题、判断题,不适合做开放创新题。
2.0 KiB
2.0 KiB
newAgent 优化待办 Handoff
日期:2026-04-21 来源:迁移 agent/ → newAgent/ 完成后的架构审视
1. TaskQuery 紧急度提升统一
问题
LLM 工具查询任务(AgentService.QueryTasksForTool)使用 applyReadTimeUrgencyPromotion 只做内存态优先级提升,不触发 outbox 写 MySQL。
前端查询任务(TaskService.GetUserTasks)使用 deriveTaskUrgencyForRead + tryEnqueueTaskUrgencyPromote,会异步持久化。
两条路径行为不一致:LLM 看到的优先级可能比 DB 里的高。
方案
service/task.go— 从GetUserTasks中提取公共方法(如GetTasksWithUrgencyPromotion),返回已提升的[]model.Task并触发 outboxservice/agentsvc/agent.go— 新增taskSvc *service.TaskService字段service/agentsvc/agent_task_query.go— 重写QueryTasksForTool,调用 TaskService 公共方法;删除applyReadTimeUrgencyPromotion死代码cmd/start.go— 注入 TaskService 到 AgentService
涉及文件
| 文件 | 改动 |
|---|---|
service/task.go |
提取公共方法 |
service/agentsvc/agent.go |
加 taskSvc 字段 |
service/agentsvc/agent_task_query.go |
重写,删 applyReadTimeUrgencyPromotion |
cmd/start.go |
注入 TaskService |
2. service/agentsvc 层瘦身(低优先级)
现状
service/agentsvc/ 目前 11 个文件,大部分是 HTTP→DB 转接层,职责合理。但有两个纯逻辑文件理论上可下沉:
| 文件 | 内容 | 可移至 |
|---|---|---|
agent_memory_render.go |
纯文本转换,零 DB 交互 | memory/ 包 |
agent_task_query.go 的 taskMatchesQueryFilter / sortTasksForQuery |
纯过滤/排序 | newAgent/tools/ |
判断
当前体量小(加起来约 200 行纯函数),搬出去收益不大,反而多一层 import 间接。如果未来这些函数膨胀再搬不迟。
3. go mod tidy
迁移完成后 go.mod 中有未使用的依赖(如 github.com/bytedance/mockey)。建议跑一次 go mod tidy 清理。