案例自研轻量编排层替代 LangChain，端到端延迟从 8 秒压到 2.1 秒。FastAPI + Next.js 14 全栈：多模型混编、积分计费、多租户权限，已落地客服/风控/内容生产三个场景。
2025 年 Q2，我们开始构建熵衍——一套面向企业级场景的多模型智能体编排平台。出发点是：市面上已有不少框架（LangChain、AutoGPT、CrewAI），但把它们真正部署到企业生产环境时，普遍卡在三个点上——多模型编排的延迟不可控、长程任务执行的可靠性不足、以及计费与权限体系缺失。
熵衍不是又一个编排框架。它是一套已跑在生产环境里的智能体执行基础设施：FastAPI + Next.js 14 全栈方案，支持 OpenAI / Anthropic / 自有模型混编，内置积分计费、多租户权限、多模态分析能力。
早期原型我们确实用了 LangChain 做编排链。两周后发现三个问题：
链式调用的延迟叠加。 LangChain 默认的 SequentialChain 让每一步串行执行，一个「分析→检索→生成→审核」的四步任务，端到端延迟经常超过 8 秒——用户等不了。
调试黑箱。 LangChain 的 verbose 日志在单步调试时够用，但当一个任务涉及 5 个工具调用 + 3 次反思回环时，日志变成一堵墙，定位一次调用失败花了我们 40 分钟。
多模型切换的隐式耦合。 LangChain 的模型抽象层让切换模型「看起来很简单」，但实际上不同模型的 tool calling 格式、system prompt 行为、token 计数方式差异巨大——从 OpenAI 切到 Anthropic，光适配就花了 3 天。
最终方案：自建轻量编排层——用 FastAPI 的依赖注入管理模型客户端，用 Redis Stream 做模块间消息传递，用 PostgreSQL 存任务状态和审计日志。执行逻辑写成纯 Python 函数，不用任何框架的「链」抽象。代码量比 LangChain 方案多了约 600 行，但端到端延迟从 8 秒降到 2.1 秒，调试效率提升了不止一个量级。
坑一：长程任务的中间状态丢失。 一次执行跑到第 4 步时 Redis 连接断开，前 3 步的中间结果全部丢失，只能重来。修法是改为「每步双写」——Redis 做热缓存、PostgreSQL 做持久化。Redis 挂了也能从 PG 恢复，代价是每步多 15ms 写入延迟。
坑二：多模型并发下的 token 计数漂移。 不同模型的 tokenizer 不同，同一个 prompt 在 OpenAI 算 420 token、在 Anthropic 算 387 token、在自有模型算 510 token。计费系统如果用单一计数方式，月度对账误差能到 18%。最终方案是每次调用后从 API response 取实际消耗数，不做客户端预估。
坑三：外部工具调用的超时雪崩。 调用外部 API 时如果某个接口响应慢（>5s），整个任务链阻塞。加了 3 秒超时 + 重试队列后，又遇到重试风暴——一个慢接口触发 3 个并发任务同时重试，打挂了对方。最终方案是令牌桶限流 + 指数退避：每个工具独立限速，重试间隔 2s→4s→8s，最多重试 2 次。
前端：Next.js 14 · React 19 · Radix UI · Tailwind CSS · Handsontable · lucide-react
后端：FastAPI · SQLAlchemy · Alembic · asyncpg · PostgreSQL · Redis · httpx + aiohttp · python-jose（JWT）
为什么不选更多：刻意避开了 LangChain/LlamaIndex 等重量级编排框架——它们的抽象层在企业生产环境带来的调试成本超过了便利性。也评估过 Temporal 做任务调度，但对当前场景来说过重，Redis Stream 的轻量级消息队列够用且运维成本低得多。
]]>