f4ef6fb256
🐛 fix(agent/schedulerefine): 修复复合微调分支链路问题，并将 MinContextSwitch 重构为固定坑位重排语义 - 🔧 修复 `schedulerefine` 复合路由中参数透传不完整、缺少 deterministic objective 时错误降级，以及“复合工具执行成功”与“终审通过”语义混淆的问题 - ✅ 保证新的独立复合分支能够正确执行、正确出站，并统一交由 `hard_check` 裁决最终结果 - 🔍 排查时发现 `MinContextSwitch` 上游 `context_tag` 存在整体退化为 `General` 的风险，影响MinContextSwitch - 🛡️ 为 `MinContextSwitch` 增加兜底策略：当标签整体退化时，按任务名关键词推断学科分组，避免分组能力失效 - ♻️ 将 `MinContextSwitch` 从“整周重新寻找新坑位”调整为“坑位不变，任务顺序改变” - 🎯 将落地方式从顺序 `BatchMove` 改为固定坑位原子重写，避免出现远距离跳位、跨天错迁、异常嵌入课位及循环换位冲突 - 🧹 修复 `hard_check` 在 `MinContextSwitch` 成功后仍执行 `origin_rank` 顺序归位、并导致逆序终审误判的问题 - 🚦 命中该分支后跳过顺序归位与顺序硬校验，避免 `summary` / `hard_check` 将有效重排结果误判为失败 📈 当前连续微调规划涉及的全部功能已可以稳定运行；下一步将继续扩展能力边界，并进一步优化 `schedule_plan` 流程 ♻️ refactor: 重整 agent2 架构，并迁移 quicknote/chat 新链路，目前还剩3个模块未迁移，后续迁移完成后会删除原agent并将此目录命名为agent - 🏗️ 明确 `agent2` 采用“统一分层目录 + 文件分层 + 依赖注入”的重构方案，不再沿用模块目录多层嵌套结构 - 🧩 完善 `agent2` 基础骨架，统一收口 `entrance` / `router` / `llm` / `stream` / `shared` / `model` / `prompt` / `node` / `graph` 等层级职责 - 🚚 将通用路由能力迁移至 `agent2/router`，沉淀统一的 `Action`、`RoutingDecision`、控制码解析，以及 `Dispatcher` / `Resolver` 抽象 - 💬 将普通聊天链路迁移至 `agent2/chat`，复用 `stream` 的 OpenAI 兼容输出协议与 LLM usage 聚合能力 - 📝 将 `quicknote` 链路迁移到 `agent2` 新结构，拆分为 `model` / `prompt` / `llm` / `node` / `graph` 多层实现，替换对旧 `agent/quicknote` 的直接依赖 - 🔌 调整 `agentsvc` 对 `agent2` 的引用，普通聊天、通用分流与 `quicknote` 全部切换到新链路 - ✂️ 去除 graph 内部 `runner` 转接层，改为由 node 层直接持有请求级依赖，并向 graph 暴露节点方法 - 🧹 合并 `graph/quicknote` 与 `graph/quicknote_run`，删除冗余骨架文件，收敛为单一 `quicknote graph` 文件 - 📚 新增 `agent2`《通用能力接入文档》，明确公共能力边界、接入方式以及 graph/node 协作约定 - 📝 更新 `AGENTS.md`，要求后续扩展 `agent2` 通用能力时必须同步维护接入文档 ♻️ refactor: 删除了现Agent目录内Chat模块的两条冗余Prompt
48 lines
3.3 KiB
Markdown
48 lines
3.3 KiB
Markdown
# AGENTS.md
|
||
|
||
## 协作偏好（逐条追加）
|
||
|
||
1. 默认语言规则：所有注释、接口文案、说明、评审反馈均使用中文。
|
||
2. 请勤加注释，尤其是复杂逻辑部分，确保代码易于理解和维护。
|
||
3. 每次在本地执行测试命令（如 `go test`）后，必须清理项目根目录下的 `.gocache` 目录，避免缓存文件长期堆积。
|
||
4. 文件编码统一使用 UTF-8（无 BOM），禁止使用 GBK、GB2312 等其他编码，避免中文内容出现乱码。
|
||
5. 进行结构重构时，优先采用“并行迁移”策略：允许新旧目录并存，先迁移、再切流、再验证、最后删除旧实现，禁止一步到位式重命名大改。
|
||
6. 遇到公共能力（如模型调用、JSON 解析、阶段推送、深拷贝、缓存快照读写）时，若在第二处出现重复实现，必须优先评估是否抽公共层，禁止无脑复制第三份。
|
||
7. 迁移期每一轮只允许处理一个能力域或一类公共件，禁止同一轮同时改多个 skill 的结构与逻辑，避免回归问题无法定位。
|
||
8. 新增代码时，必须优先复用已有公共能力；如果暂时无法复用，必须在注释或文档中写明“为什么这次不能抽公共层”，禁止默认复制粘贴旧实现。
|
||
9. 对于明显过大的文件（尤其是同时承载编排、业务、模型交互、工具分发的文件），后续重构时必须拆分职责，禁止继续向单文件堆砌新逻辑。
|
||
10. Prompt、State、模型交互、Graph 连线应尽量分目录/分文件管理，禁止把大段 prompt、节点逻辑、模型 helper 长期混写在同一文件中。
|
||
11. 若本轮任务包含“结构迁移”，最终答复中必须明确说明：本轮迁了什么、哪些旧实现仍保留、当前切流点在哪里、下一轮建议迁什么。
|
||
|
||
12. 若后续在 `backend/agent2` 中新增、下沉、替换任何“通用能力”，必须同步更新 `backend/agent2/通用能力接入文档.md`，否则视为重构信息不完整。
|
||
|
||
## 注释规范（强制）
|
||
|
||
1. 默认使用中文注释，禁止英文注释（专业术语除外）。
|
||
2. 复杂逻辑必须写“步骤化注释”，用 `1. / 2. / 2.1` 这种编号，说明：
|
||
- 这一步要做什么
|
||
- 为什么要这样做
|
||
- 失败时怎么处理
|
||
- 兜底/回退策略是什么
|
||
3. 函数注释至少说明“职责边界”：
|
||
- 这个函数负责什么
|
||
- 不负责什么
|
||
- 输入输出语义（尤其是 bool、error、状态字段）
|
||
4. 涉及分支、重试、事务、幂等、并发、状态机的代码，必须写清楚判断依据与流转条件。
|
||
5. 跨文件调用前必须写“调用目的注释”，让读者不跳转文件也能理解当前代码意图。
|
||
6. 注释禁止空话（如“设置变量”“调用方法”）；必须写业务意图与约束。
|
||
7. 改动代码时，如修改了复杂逻辑，必须同步更新注释；注释过期视为不合格提交。
|
||
8. 不要求每行都注释；简单直白代码可省略，重点保证关键路径可读性。
|
||
|
||
## 注释风格示例
|
||
|
||
推荐：
|
||
- `// 1. 先查缓存，命中则避免回源 DB，降低接口延迟。`
|
||
- `// 2. 缓存未命中再查库；若查库失败直接返回，避免写入不完整状态。`
|
||
- `// 3. 写库成功后再更新缓存，保证“先真后快”，避免脏缓存。`
|
||
|
||
不推荐：
|
||
- `// 查询缓存`
|
||
- `// 调用 DAO`
|
||
- `// 返回结果`
|