2025：在 Solvely 做 AIO 教育引擎，我如何把 Agent 做成闭环系统

加入数驱互动后，我主导的核心工作是 Solvely.ai 的 AIO（All-In-One）教育内容生成引擎。业务目标很明确：让 Flashcard、Quiz、Study Guide 从人工生产升级为智能体自动化生产。真正挑战在于，教育场景输入长、追问多、文件杂，系统如果只有“会生成”这一项能力，很快就会在性能和一致性上失稳。

问题一：长文档首包太慢，用户等不到结果

用户经常一次上传几十页课件。早期链路里，首 token 时间（TTFT）在 35.7 秒左右，体验非常差。我围绕 Gemini 的上下文缓存能力做了两类改造：

可复用上下文前置缓存，减少重复编码成本。
非复用片段改流式输出，尽早返回首包。

最终 50 页文档场景的 TTFT 降到 17.4 秒，下降 51%。这个优化不是单点技巧，而是缓存策略、请求编排、输出机制一起改。

问题二：多轮对话 token 成本失控

教育场景会连续追问，若每轮都把大段历史上下文重新注入，成本和延迟都会飙升。我在上下文工程侧引入 Token Mask + 上下文感知状态机，只保留当前任务真正相关的上下文窗口。配合 KV Cache 复用策略后，token 使用量下降约 90%，整体响应速度提升约 91%。

这个结果背后是一个关键工程判断：多轮系统不是“记住越多越好”，而是“在正确时机记住正确信息”。

问题三：多文件问答中，事实容易漂移

学生会同时上传讲义、习题和笔记，模型很容易出现来源混乱。为此我把 Knowledge Map 引入检索生成链路，先在结构层建立文件间关系，再在回答阶段绑定引用来源，降低“说对了但说不清依据”的情况。

此外我也把 LangExtract 用在结构化抽取环节，让题型、知识点、难度标签等信息提取更稳定，便于后续自动出题与复用。

工程化落地：没有可观测，就没有可迭代

算法效果要稳定上线，发布与监控体系必须跟上。我独立开发了算法部署平台，支持 Web/iOS 自动扩容、灰度发布和回滚；并搭建全链路监控看板，持续追踪准确率、P95/P99 延迟和失败分布。很多“看似模型问题”的故障，最终都在观测数据里定位到上下游依赖或缓存策略。

我对 Agent（angent）系统的定义

在这个项目里，我把 Agent 定义为“规划-执行-反馈”的闭环系统，而不是几个 prompt 串联。只有闭环具备以下能力，才算生产可用：

可规划：能拆任务并动态调整路径。
可执行：能稳定调用工具和检索链路。
可反馈：失败可归因、可回灌、可迭代。

Solvely 这一阶段的最大收获，是把很多概念级“Agent 能力”转成了线上稳定指标。对我来说，这也是从“做模型”走向“做系统”的关键一步。