06 - 改进路线图

那五项能够快速消除已知风险和债务的修复工作：

1. 将 Tavily API 密钥从 mcp_servers.json 中移出

将其放入环境变量，或一个权限设为 chmod 600 的密钥文件中，主配置文件仅引用该文件。这只需花费五分钟，却能解决当前明文存储带来的实质性隐患：密钥可能出现在用户提交的配置文件中、以明文形式被备份下来，或被未授权进程读到。

完成标志： 密钥不出现在任何可能被提交、以明文备份或被除必要进程以外的任何东西读取的文件中。

2. 将备份副本拷贝到 AI_DATA 存储卷之外

备份系统本身很可靠；差距纯粹在于“不在本机”。只需手动复制到另一块物理硬盘或云存储，即可消除那个唯一的单点故障——否则一旦驱动器故障，丢失的将不只是误删的数据，而是全部数据。

请按项目 SOP 设置每季度定时提醒。

3. 将“先正则匹配、再嵌入”模式应用到 skills/loader.py

代码库中已有现成的确切修复方案（步骤 5.9 / 5.10），针对的是一个结构相同的问题。这更接近"移植一个已验证的方案"而非"解决一个新问题"，是一项能直接修复已确认的、有日志记录的误报问题的良好扩展练习。

4. 清理孤立文件 (memory_test2.db、过期的 wiki-ingest-state)

在删除前确认这些文件可以安全删除。这很简单，但能消除下一个人（包括未来的你）查看文件夹时的困惑。

那些需要更多精力但价值会持续累积的工作项值得趁势头正猛时推进：

5. 扩展评估/测试题范围，超出当前 20 道题

在 20 道题的基线上获得 65%（13/20）的正确率是一个真实信号——但样本量太小。几个新失败的题目可能大幅拉低通过率，但这并不意味着实际退步；反之，几个新通过的题目也可能轻易掩盖真正的退步。

若将这些测试题从当前数量扩展到 50–100 道，并直接从已在记录的生产流量中反馈（项目已通过 logs/agents/feedback.jsonl 收集反馈），就能让"这个改动是改善还是损害了结果？"变得更加可信。

6. 为主端点添加经模式验证的请求模型

将当前的裸 json.loads() 替换为正式请求模式（Pydantic，因 FastAPI 已原生支持它），能将令人困惑的内部错误转化为对任何格式错误的调用方返回清晰、可操作的 400 响应。添加成本低，且在每次调试集成时都能持续受益。

7. 添加轻量级自动化测试运行 项目已具备真实的端到端和流式测试（test_endpoint_e2e.py、test_streaming.py），缺失的环节在于没有任何机制自动运行这些测试。将这些测试集成到简单的重启前检查中（即在 Restart-Agent-Server.command 实际替换新代码之前），可以在回归问题影响生产流量之前就将其捕获，从而闭合了项目自身 SOP 所提及的流程闭环（“运行测试套件”是“更新服务器代码”的第 3 步，但尚无机制强制执行）。

8. 为写入操作构建人工审批关卡 这是项目自身护栏清单中明确未实现的唯一一项护栏。鉴于当前的写入范围已经有限（仅限于知识库文件夹），无需过于复杂——即使采用简单的“暂停并记录日志，要求第二次显式确认调用”模式，也能在“沙箱隔离”与“人工监督”之间填补空白。

9. 手动获取剩余的 .mil / .gov 受限文档 来自 GAO/各军种财务报告库和 DFAS/各军种财务管理的知识库中，约有 二十余个文件 因自动下载受限而缺失，且确切的 URL 已在设置指南的手动下载表格中记录清楚。这纯属执行层面工作，而非工程开发——最难的部分（确定缺失了哪些内容以及从哪里获取）已经完成。

10. 逐一验证剩余已集成的项目 在指向该服务器的大约 十九个 其他项目中，仅有 一个 已通过直接测试确认在新代理商服务器上正常工作；其余项目均假设遵循相同的集成模式。一次简短的验证过程（确认每个项目的环境变量中包含指向 :8443 的有效代理商服务器密钥，而非过期的 :443/网关密钥）即可在用户发现问题之前捕获静默故障。

仅在出现特定且已记录的触发需求时，才值得重新审视的可选改进：

11. 评估微调适配器与质量基线的对比 微调管线已端到端跑通（LoRA 冒烟测试已证实），但在仅 约 13 个示例 上进行训练，本就不预期能产出可部署的成果。以下两个条件满足时值得重新审视：

• 评估套件（第 5 项）生成了足够多的 PASS 标注样本用于训练；且
• “最终实际针对哪个生产模型”这一根本问题已得到解决（冒烟测试故意使用了小型替代模型）。

12. 如果延迟成为实际问题，调查提示前缀缓存的替代方案 Ollama 未提供此控制选项，且 vLLM（通常的解决方案）无法在 Apple Silicon 上运行。如果这真正成为瓶颈而非已知的文档限制，现实的解决路径有：

• 支持 Apple Silicon 前缀缓存的推理服务层（值得直接调研——该领域发展迅速）；或
• 缩小稳定的系统提示前缀体积，从而每次只需重新处理更少的内容。

13. 仅在必需工具仅提供此类传输时，添加 HTTP/SSE MCP 传输支持 目前设计为仅支持 stdio，已足够覆盖所有已接入的工具。仅在确有必要接入的特定 MCP 服务器需要此功能时才构建——不要基于猜测提前做（这会带来实实在在的维护负担）。

14. 仅当并发负载确实超出单台 Mac Studio 处理能力时，才重新评估水平扩展方案 内存限流器、缓存和 MCP 会话池均基于单进程假设设计。多实例部署需将这些组件迁移至共享存储（Redis，或哪怕仅通过适当锁定机制使用共享 SQLite 文件）——这是实实在在的工作量，鉴于当前单实例架构更简洁且无已知 Bug（仅有已知的扩展上限问题），在没有实际容量需求前不值得提前投入。

15. 仅当扩大后的评估集（第 5 项）显示出真正的、反复出现的多跳关系问答失败模式时，才考虑 Tier 3（图）知识检索。 项目自身的知识管理指南已明确指出这一点：不要盲目构建图谱 RAG。索引和维护成本高昂，且预期向量 RAG 结合精心整理的 Wiki已能覆盖绝大多数实际问题。

第 1–4 项每项工作量均在 1 小时以内，且能实质性降低风险或减少技术债——无论其他优先级如何，都应完成这些。第 5–10 项效果会叠加：更大的评估集（#5）能让后续所有更改（包括 #11）的评估更加客观公正，而补齐手动下载缺口（#9）并验证集成（#10）完全是“完成已做好 90% 的收尾工作”的事务。

第 11–15 项真正属于可选项，应仅由实际观察到的需求触发，而非仅仅因为它们在清单上就提前构建——这种纪律性（基于真实证据响应需求，而非凭空预期），正是 00_Project_Timeline.md 中记录的大部分修复工作得以产出的核心原则。

Here is the translation of all four knowledge-bank test-files into Simplified Chinese. Code blocks, technical terms, proper nouns, URLs, and document names are preserved verbatim. The structure (headings, lists, tables) is kept identical to the originals.