2026-06-20：Phase 6 起步，先把 Agent 做成工程能力

柒和远方
2 阅读6分钟

2026-06-20：Phase 6 起步，先把 Agent 做成工程能力

今天正式进入 Phase 6，多 Agent 系统。

这一阶段很容易做歪：给几个 prompt 起名字，包装成 RouterAgent、TutorAgent、MemoryAgent，然后宣称自己是多 Agent。那样对项目没有实际价值。PrepMind 现在已经有 Chat、OCR、错题本、FSRS 复习、RAG 知识库和学习计划，如果 Agent 不能把这些能力组织得更稳定、更省钱、更可控，那就只是概念堆叠。

所以今天的目标不是一次性做完所有 Agent，而是先把地基打好，再接入最接近用户体验的 TutorAgent。

Phase 6.0：Agent Runtime 地基

第一步做的是 Agent Runtime。

它的核心作用是把后续所有 Agent 放进同一套结构里，而不是每个 Agent 各写各的 prompt 和状态。

今天补齐的基础能力包括：

  • AgentState：承载用户输入、路由结果、聊天上下文、RAG 命中、评估结果、建议动作和错误信息。
  • ActionProposal：所有需要写库的动作都先变成建议，用户确认后再执行。
  • RouterAgent：先用确定性规则判断用户意图，不急着每次都调用模型。
  • 阈值 guard：ReviewAgent、MemoryAgent、PlannerAgent、WrongQuestionOrganizerAgent 不会每次聊天都跑。
  • AgentRun / AgentStep recorder：为后续 trace、成本统计和调试留出位置。
  • 降级链路：Agent 失败不能破坏 Chat 主流程。

这里最重要的设计原则是：Agent 先给建议，不直接改事实数据。

比如后续 WrongQuestionOrganizerAgent 可以建议把一道题放进“高等数学 -> 曲线积分与格林公式”，但不能静默移动用户错题。用户手动重命名、移动、合并专题之后，AI 只能尊重或给建议，不能覆盖。

这对真实产品很重要。学习类产品里，用户的数据组织权应该在用户手里，AI 只负责降低整理成本。

阈值触发，而不是每次都跑

今天也重新明确了一个边界：回顾、记忆、计划、错题整理这类 Agent 不应该每次对话都触发。

更合理的触发方式是：

新增错题达到一定数量
同一知识点反复出错
连续使用达到一定天数
用户打开计划页
用户主动点击整理/分析
用户上传或替换资料

这样做有两个好处。

第一是成本可控。之前真实模型调用成本突然飙升，已经说明无节制上下文和频繁模型调用会很危险。Agent 阶段必须默认省钱，只有真正有价值的时候才调用更重的分析。

第二是体验更自然。用户只是问一道题时，不应该突然触发学习计划、长期记忆和错题整理。主流 AI 产品也是这样：即时回答要快，深度分析可以异步或手动触发。

Phase 6.1：RouterAgent 接入 Chat

第二步是把 RouterAgent 接进 /api/chat。

这里没有重写 Chat 主链路，因为之前的 Chat 已经承担了很多稳定能力：

  • 流式输出。
  • OCR activeStudyContext 注入。
  • RAG 检索和参考资料追加。
  • token 预算裁剪。
  • mock/live 双开关成本保护。
  • Markdown 和公式渲染。

所以 Phase 6.1 的正确做法是：让 Agent 只参与路由和 prompt shaping，不替代现有模型输出链路。

现在 /api/chat 的顺序变成：

用户消息
  -> chat-agent-runtime
  -> RouterAgent 判断路线
  -> 生成 route metadata
  -> 组合 activeStudyContext / Agent prompt / RAG prompt
  -> 继续原来的 mock 或 live 流式输出

响应头里也会带上轻量调试信息：

  • x-prepmind-agent-route
  • x-prepmind-agent-confidence
  • x-prepmind-agent-rag-required

这些头不会泄露完整 prompt 或用户内容，但足够我们本地验证路由是否合理。

Phase 6.2：TutorAgent 策略层

今天最后落地的是 TutorAgent policy。

之前 Chat 里虽然已经能“讲题”，但本质上是 prompt 里提醒模型要像老师一样讲。问题是，这种方式太笼统。用户问“怎么做”、问“为什么这一步成立”、问“我这样写对吗”、问“只要答案”，其实需要完全不同的回答策略。

所以 TutorAgent 被设计成一个确定性策略层，先不直接调用模型，只负责判断讲题方式。

目前支持六类意图：

explain_solution   完整讲解解法
socratic_hint      苏格拉底式提示
step_check         检查用户步骤
concept_bridge     解释概念/公式/定理
answer_direct      直接给答案
general_follow_up  普通追问

比如：

  • “讲一下这道题怎么做” -> explain_solution
  • “为什么这一步可以这样变形” -> socratic_hint
  • “我这样写对吗” -> step_check
  • “这个公式是什么意思” -> concept_bridge
  • “直接告诉我答案” -> answer_direct

这个策略不会自己生成最终答案，而是生成短 prompt，交给 /api/chat 现有的模型链路继续流式输出。

这样设计的好处是很清楚的：

  • 策略可测试。
  • 不增加真实模型调用。
  • 不破坏现有 Chat / OCR / RAG 链路。
  • 后续可以把策略结果作为 Agent trace 记录下来。

一个容易踩坑的细节

今天修了一个意图优先级问题。

最开始，“this step / 这一步”容易被识别成 step_check。但用户说：

Why can this step be done like this?
为什么这一步可以这样变形？

这不是让 AI 判断“我写得对不对”，而是在问“这一步背后的依据是什么”。更合理的策略是 socratic_hint。

所以现在只有强校验信号才进入 step_check，比如：

  • is it correct
  • am I right
  • check
  • 我这样对吗
  • 哪里错

而“为什么 + 这一步”会优先归为提示和讲解。这个细节看起来小，但会直接影响讲题体验。如果 AI 动不动就像批改作业一样回答，用户会觉得很别扭。

成本边界没有放松

今天也确认了一遍：@repo/agent 目前不直接调用真实模型。

真实模型调用仍然只在 /api/chat 中发生，而且必须同时满足：

AI_PROVIDER_MODE=live
AI_ENABLE_LIVE_CALLS=true

默认开发仍然是 mock。

这点必须坚持。Agent 阶段功能会越来越多，如果每个 Agent 都能随便调模型，成本会失控，调试也会变得混乱。现在的原则是：

  • Router 先用轻量规则。
  • Tutor policy 先用确定性策略。
  • Review / Memory / Planner / Organizer 按阈值触发。
  • live 验收只用少量固定用例。

今天完成后的状态

今天完成后，Phase 6 已经不是停留在规划阶段。

已落地：

  • Phase 6.0 Agent Runtime 地基。
  • Phase 6.1 RouterAgent 接入 Chat。
  • Phase 6.2 TutorAgent 策略层。

还没有做：

  • KnowledgeVerifierAgent
  • WrongQuestionOrganizerAgent
  • KnowledgeDedupAgent / KnowledgeOrganizerAgent
  • ReviewAgent / PlannerAgent
  • MemoryAgent
  • Agent trace UI 和成本看板

下一步最应该做的是 KnowledgeVerifierAgent。因为 Phase 5 已经把 RAG 跑通了，但用户上传资料不一定正确。如果 AI 检索到错误笔记就盲从，反而会误导用户。

Verifier 的价值在这里：

RAG 命中资料
  -> AI 生成回答初稿
  -> KnowledgeVerifierAgent 判断资料和回答是否可信
  -> 如果资料可疑，回答时温和提示用户核对对应片段

这会成为 PrepMind 区别于普通 RAG Demo 的关键点：不是“检索到了就引用”，而是“检索到了也要判断能不能信”。

今天这一轮没有做很炫的前端效果，但把 Phase 6 的工程边界立住了。后面的 Agent 越多，这个地基越重要。

avatar
文章
阅读
粉丝