项目索引
info
这里沉淀的是四个自己从零做的项目，外加一篇不绑定具体项目的工程范式沉淀。每篇不复述 README，只写架构决策、设计取舍和踩过的坑。
四个项目
| 项目 | 定位 | 主技术栈 | 沉淀重点 |
|---|---|---|---|
| RAG Agent Platform | 多租户智能体 SaaS 平台 | Spring Boot 3 · LangChain4j · PGVector · RabbitMQ | 异步文档流水线、召回+精排、知识库版本化 |
| Lobster0 | 自托管个人 Agent | Python · SQLite · Playwright · Electron | 权限分层、参数绑定审批、Markdown 记忆 |
| mini-ray | 单机版 Ray 运行时 | C++17 · pybind11 · POSIX 共享内存 | 任务调度、ObjectRef、Python/C++ 边界 |
| EvalHub | LLM/Agent 评测平台 | Python · FastAPI · React · Ollama | 持久化 DAG、可复现指纹、过程证据 |
一篇工程范式沉淀
| 文章 | 主题 | 沉淀重点 |
|---|---|---|
| 对话助手 Agent 工程 | 联网取数 + 工具调用 + 长期记忆的对话式 Agent 参考架构 | 上下文注入顺序与 token 预算、记忆三层读写时机、统一工具协议、Deep Research 状态编排、离线数据飞轮 |
和上面四个项目不同，这篇不对应某个具体代码库，写的是多个 Agent 系统里反复出现的同一组设计问题：上下文由谁装配、记忆在什么时机进出、工具列表由谁裁剪。八张架构图可以脱离具体实现单独读。
它们之间的关系
四个项目不是孤立的，正好覆盖了 LLM 应用栈的四层：
- 做应用（RAG Agent Platform / Lobster0）会逼你回答：检索质量怎么保证？工具执行怎么才安全？
- 做评测（EvalHub）会逼你回答：怎么证明它真的变好了？
- 做基础设施（mini-ray）会逼你回答：这些框架底下到底在干什么？
四条最通用的经验
从四个项目里抽出来、换个场景仍然成立的几条：
1. 异步流水线按「失败域」切分，不按「步骤」切分。 （来自 RAG Agent Platform）OCR 和向量化拆开，是因为失败原因和重试成本不同，不是因为它们是两个步骤。
2. 模型提议，系统裁决。 （来自 Lobster0）模型输出的 Tool Call 只是提议，校验、鉴权、审批、执行、审计全部在系统侧。硬边界与权限模式必须分层，最松的模式也不能变成后门。
3. 跨语言边界只传字节，不传语义。 （来自 mini-ray）C++ 侧不理解 Python 对象，只做二进制搬运。这条边界模糊了，就要在 C++ 里实现半个 CPython。
4. 「跑失败」和「做错了」必须分开记录。 （来自 EvalHub）把基础设施故障记成 0 分会污染所有结论。这条在监控、告警、AB 实验里同样成立。