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永远只适合做选择题、判断题，不适合做开放创新题。
3.1 KiB
3.1 KiB
NewAgent 改造路线
核心架构
砍掉路由和多张业务 graph，换成一张通用循环图，用 eino compose 搭建。能力通过 tool 横向扩展，图本身不再变。
循环图结构
START → Plan Loop(循环，直到 PLAN_DONE) → Confirm Plan → Execute Loop(ReAct + Reflection) → 交付 → END
- Plan Loop：每轮后端注入上下文（当前阶段、已确定步骤、已收集信息），LLM 每次只想一步，可调感知类 tool 收集信息，输出 [PLAN_DONE] 进入下一阶段
- Confirm：plan 完成后推给用户确认，不 ok 回 Plan 重来
- Execute Loop：按 plan 逐步调 tool，每步完 reflection，发现 plan 有问题可自行修正
- 交付：执行结果推给用户检查
关键设计决策
- 不需要路由：整个 agent 就是一个 tool-use 循环，LLM 自己判断聊天还是干活，上下文理解能力本身就是最好的路由器
- 写操作前必须 confirm：所有会改动日程的 tool 执行前自动触发用户确认，读操作不需要
- Thinking 策略：首轮理解意图时开，后续 tool 循环轮次关掉
- Graph 的角色：从业务流程编排降级为基础设施，编排 agent loop 本身（LLM → tool → LLM 循环），业务逻辑下沉到 tools
工具设计原则
工具做计算，LLM 做决策。LLM 不碰原始时间数据，只看自然语言级别的信息。
感知类（让 LLM "看"时间）
get_free_slots(date_range, min_duration)— 返回空闲时段get_conflicts(proposed_event)— 返回冲突信息get_day_summary(date)— 某天负载概况get_task_context(task_id)— 任务完整上下文
操作类（让 LLM "动手"）
create_event/update_event/delete_event— 基础 CRUDbatch_create_events(events[])— 批量创建swap_events(event_a, event_b)— 交换时间段reschedule_event(event_id, constraints)— 自动找合适时段重排
分析类（让 LLM "想"）
estimate_workload(date_range)— 工作量分布find_best_slot(duration, deadline, preferences)— 给定约束算最优时段check_feasibility(task_list, deadline)— 可行性检测
状态设计
State 和 Context 分离：
AgentState：阶段标记、plan 步骤、confirm 状态、tool 调用记录、轮次计数（流程控制）ConversationContext：消息历史、system prompt、tool schemas、注入的阶段上下文（对话管理）
两者通过 traceID / session 关联，数据结构分开。
落地方式
newagent/复制型搬迁，分层结构延续- 已搬迁：
llm/（client、ark、json）、stream/（emitter、openai）、shared/（time、retry） - 包名统一为
newagent前缀（newagentllm、newagentstream、newagentshared） - 新增
tool/目录存放可插拔工具 - 老 agent 保留对照，跑通再删
优先级
P0（先做）：循环图 + 感知类工具 + 基础 CRUD + ask_user 多轮交互 + confirm 机制 P1（后续）：记忆机制、websearch、skills、分析类工具
协作模式
我（人类）搭函数框架 + 写清楚注释，Codex 负责填充实现。架构决策权在人类手里。