串起身份、编排、知识、工具和模型网关，给出可以分阶段实现的平台设计。
本文于 2026-09-12 补充整理，按 2026-09 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
从一个业务闭环确定平台边界
这个系列的示例目标是：员工提出问题，系统查找授权范围内的知识，按需查询工单历史，准备明确提案，确认后创建工单，并能在故障后核实结果。
平台蓝图应服务于这个闭环。先把模块职责和数据所有权写清楚，再讨论微服务数量、集群规模或多 Agent。本文是设计蓝图，不代表这些模块已经在本仓库实现。
六个模块如何协作
| 模块 | 核心职责 | 持有的权威数据 |
|---|---|---|
| 任务应用层 | 创建、取消、查询、流式订阅 | 任务入口契约 |
| 编排运行时 | 状态推进、预算、租约、恢复 | 任务状态与检查点 |
| 知识服务 | 入库、检索、引用与版本 | 文档与索引发布清单 |
| 工具执行层 | 参数校验、授权、审批、幂等 | 提案与操作账本 |
| 模型网关 | 能力路由、配额、适配、用量 | 路由与使用记录 |
| 评测观测层 | 版本验收、轨迹关联、告警 | 评测结果与运行证据 |
身份由已有认证系统提供，模块之间传递受信任的主体上下文。模型不成为身份源，消息队列也不成为任务状态的唯一权威来源。
核心运行路径
浏览器
│ 创建任务 / 订阅事件
Java API
│ 本地事务：任务 + outbox
任务存储 ── 投递器 ── 队列 ── Worker
├─ 知识检索
├─ 模型网关
├─ 工具执行器 ── 工单系统
└─ 检查点 / 事件 / 操作账本
任务执行期间，不持有跨越模型调用的长数据库事务。每次状态推进是短事务，外部副作用通过操作标识和结果查询协调。
SSE 可以从事件存储订阅进度。浏览器断线不决定数据库中的任务事实，重连也不会重新发起业务动作。
数据所有权防止模块互相侵入
知识模块负责决定哪些文档版本可检索；工具模块负责判断工单是否实际创建；编排器只保存它们返回的引用和结果，不直接修改所有模块的表。
应用可以共用 PostgreSQL 实例，但应按模块隔离表访问。先建立代码边界和接口契约，后续才有条件按资源需求拆进程。
向量检索若采用 pgvector，仍需由知识模块实现权限、版本和删除流程；数据库扩展提供的是检索能力，不是完整知识治理平台。
分阶段部署更容易验证
第一阶段采用模块化单体，完成只读问答和引用验证。第二阶段加入异步 Worker、操作账本和审批写入。第三阶段在实际负载证明有必要时，独立扩展模型网关或检索服务。
CPU 密集的解析和重排，与主要等待网络的模型调用，可以使用不同工作池或进程。是否独立部署取决于资源争用和故障影响，而不是每个模块都必须一个服务。
共享组件故障时应有明确结果：队列不可用但 outbox 已提交，可显示排队；模型不可用可保留任务等待或返回受控失败；工单响应丢失必须对账。
给平台设定可验收的交付物
最小可验证版本应包括：可重复装载的合成知识集、两个租户、只读问答、一个审批写工具、任务查询接口、异常恢复案例和固定评测集。
后续再加入成本看板、多模型路由和长期记忆。没有一个可恢复的写操作闭环，先建设复杂的 Agent 市场或可视化编排器，很难证明平台解决了核心问题。
面向架构评审，可以沿着“一个请求从哪里来、状态存在哪里、故障后谁负责恢复”讲解全图。每条连线都有数据和责任，图才具有工程意义。
