AI · 多 Agent 运筹系统 · 2026
OmniRoute
四个 Agent 协同，把一段自然语言的供应链扰乱报告，变成可执行的运筹方案和一份高管能读的决策摘要。
- 类型
- 自研项目
- 我的角色
- 独立开发 · 多 Agent 与运筹
- 年份
- 2026
- 技术
- Python · FastAPI · PuLP · Multi-Agent
要解决的问题
供应链扰动通常以自然语言出现——邮件、IM、临时通报。要把它变成运筹模型，得人工翻译成变量、约束和目标；求解结果还要校验物理冲突，最后再翻译成业务语言。这条链路每一步都靠人，慢，而且容易断。
我做了什么
- 01
拆成四个 Agent
Router 负责理解与结构化，Solver 负责建模求解，Simulation 负责数字孪生校验，Executive 负责商业摘要。每个 Agent 只做一件事，接口固定。
- 02
把自然语言变成边界条件
Router 用链式推理把扰乱报告拆成货物、车辆、时间窗与约束，输出统一的结构化边界条件，交给下游。
- 03
自动建模与求解
Solver 用 PuLP 生成线性/混合整数模型，调用 CBC 求解，覆盖 VRP 等场景；求解器通过适配层隔离，可替换。
- 04
仿真校验与商业摘要
Simulation 在数字孪生里回放方案、检测冲突并触发自反思；Executive 把结果转成 P&L 对比和高管可读的摘要。
关键决策
Agent 之间用统一消息总线
不让 Agent 互相直接调用。每个 Agent 继承统一基类、通过消息总线通信，链路可观测、可替换、可单独测试。
求解器适配层
建模与求解隔离开，CBC 换成 SCIP 或别的求解器时，业务层不用改。运筹系统里，最容易被焊死的就是求解器。
用测试锁住整条决策链
105 个测试覆盖单元、集成与 E2E：从 Router 输出被 Solver 消费，到 Solver 结果被 Simulation 校验，再到完整链路编排。
结果
四个 Agent、FastAPI 接口与 Next.js 前端控制台全部可运行；105 个自动化测试在本地全部通过（单元 / 集成 / E2E）。前端为演示界面，图表数据为本地模拟；后端编排、求解与校验逻辑有测试覆盖。
105
自动化测试
4
Agent
9,950
行 Python
11
测试文件
踩过的坑
- 多 Agent 的难点不是让它们说话，而是定义清楚每一步的输入输出契约。
- 运筹模型必须可替换，不能把求解器焊死在业务逻辑里。
- 测试要覆盖链路，不只是单点；链路断了，单点全绿也没用。