66c06eed0a
后端： 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永远只适合做选择题、判断题，不适合做开放创新题。
5.4 KiB
5.4 KiB
WebSearch 两阶段实施计划（newAgent）
1. 目标与范围
本文用于把 newAgent 的 WebSearch 能力按两阶段落地：
- 第一阶段：先接入可用的检索与抓取能力（低风险、快交付）。
- 第二阶段：在第一阶段基础上升级为 WebRAG 语义召回链路（提升复杂问题命中率与可解释性）。
约束：
- 不走
infra/smartflow-mcp-server，直接走newAgent/tools工具注册链路。 - 保持现有执行模式不变：读操作
action=continue + tool_call。 - 第一阶段只接单供应商；第二阶段再考虑 provider fallback。
2. 第一阶段（V1）：WebSearch + 简单抓取
2.1 交付目标
让模型可以：
- 通过
web_search获得结构化检索结果（标题、摘要、URL、来源域名、时间）。 - 通过
web_fetch拉取指定 URL 正文并做最小清洗。 - 在不改主流程的前提下，把结果作为标准
tool observation写回历史。
2.2 计划新增工具
web_search- 输入：
query、top_k、domain_allow、recency_days等。 - 输出：JSON 字符串（
tool、query、count、items[]）。
- 输入：
web_fetch- 输入：
url、max_chars。 - 输出：JSON 字符串（
tool、url、title、content、truncated）。
- 输入：
2.3 代码落点
新增文件：
backend/newAgent/tools/web_tools.go：工具参数解析、输出组装、错误兜底。backend/newAgent/tools/web_provider.go：搜索供应商抽象接口与通用数据结构。backend/newAgent/tools/web_provider_tavily.go（或web_provider_brave.go）：首个 provider 实现。backend/newAgent/tools/web_fetcher.go：URL 抓取与 HTML 最小清洗。
修改文件：
backend/newAgent/tools/registry.go：注册web_search、web_fetch两个读工具。backend/cmd/start.go：初始化 provider 配置并注入 registry（或通过包级配置读取）。backend/newAgent/prompt/execute_context.go：补充新工具的 schema 说明与示例。
2.4 V1 验收标准
- 模型能稳定调用
web_search并拿到可解析 JSON 结果。 web_fetch在正文可达时返回正文，在失败时返回明确错误码与原因。- 工具超时、429、5xx 均不会打断主流程，只返回可恢复 observation。
- 日志可定位：query、tool、耗时、结果数、失败原因。
3. 第二阶段（V2）：WebRAG 语义召回
3.1 交付目标
新增 web_rag_search，把“检索 + 抓取 + 分块 + 召回 + 重排 + 证据返回”收敛为一个读工具，提升复杂问答质量。
3.2 链路设计
- 查询改写：把用户问题改写为 1~3 个检索子查询。
- WebSearch 召回：拿到候选 URL 集合。
- 抓取清洗：抽正文，去噪。
- 分块：按段落与 token 预算切块。
- 召回：向量召回 + 关键词召回（混合召回）。
- 重排：按 query 相关性重排 chunk。
- 输出：返回答案所需证据片段、来源 URL、片段得分。
3.3 代码落点
新增文件：
backend/newAgent/tools/web_rag_tools.go：web_rag_search工具入口。backend/newAgent/tools/web_rag_chunker.go：清洗后分块。backend/newAgent/tools/web_rag_retriever.go：混合召回。backend/newAgent/tools/web_rag_rerank.go：重排层。backend/newAgent/tools/web_rag_store.go：会话级索引缓存（先内存/Redis TTL）。
修改文件：
backend/newAgent/tools/registry.go：注册web_rag_search。backend/newAgent/prompt/execute_context.go：增加web_rag_search使用规范。
3.4 V2 验收标准
- 同类复杂问题下，回答引用质量和相关性明显高于 V1。
- 返回至少包含：
answer_evidence[]（片段+URL+score）。 - 召回或重排失败时可降级到 V1（
web_search + web_fetch）路径。 - 提供基础评估指标：命中率、延迟、成本、失败率。
4. 与记忆系统的关系
WebRAG 与记忆系统 RAG 高度重合，建议“共用内核、分语料适配”：
- 共用：chunk / embed / retrieve / rerank 的通用接口与实现。
- 分开：
MemoryCorpus（私有数据）与WebCorpus（公网数据）的数据源适配层。 - 在工具层保持两个入口：
memory_search与web_rag_search，返回结构尽量统一。
5. 上线顺序与回滚策略
5.1 上线顺序
- 先灰度 V1：仅开放
web_search、web_fetch。 - 观察稳定性与成本后再灰度 V2：
web_rag_search。 - V2 稳定后再考虑 provider fallback 与更长周期缓存。
5.2 回滚策略
web_rag_search异常时，快速降级为 V1 工具集。- V1 供应商异常时，返回“检索暂不可用”的结构化 observation，不阻断主流程。
- 保留 feature flag：按工具级别开关，支持秒级关闭。
6. 风险清单
- 供应商配额/限流导致查询失败。
- 页面反爬与正文抽取质量不稳定。
- RAG 链路成本上升（抓取+embedding+重排）。
- 引用片段与最终答案不一致（需要强制证据对齐策略）。
7. 里程碑建议
- M1（1~2 天）：V1 工具跑通，联调 Execute 节点可调用。
- M2（2~4 天）：V1 稳定性优化（超时/限流/日志/错误码）。
- M3（4~7 天）：V2 WebRAG MVP（混合召回+基础重排+证据输出）。
- M4（后续）：统一 RAG Core，打通记忆系统复用。