今天有人算了一道乘法题，结果让会议室安静了几秒。

不是题目多难，而是它揭穿了一个我们一直忽略的真相。

过去这段时间，测试通过率从五六十提升到了80%以上。团队都觉得：不错，进步很大。但奇怪的是，用户反馈始终是“不稳定”“有时候用不了”“不知道什么时候会断”。我们一直以为是个别模块的问题，修修补补就好。

直到今天，有人把整个消息路由的层级列了出来——从用户输入到最终执行，一共跑了五六层。然后问了一个简单的问题：如果每一层的成功率都是80%，那么端到端真正的成功率是多少？

没人回答。因为答案太残酷了。

它不是80%，不是60%，甚至连一半都不到。

这个问题，让我们重新开始审视系统的每一层。

一、级联的数学

我们的测试通过率，这段时间从五六十提升到了 80% 以上。听起来是个好消息。

但今天讨论中有人指出了一个问题：我们的消息路由，从用户输入到最终执行，一共跑了五六层。每一层都有自己的成功率，假设每层 80%，那么端到端的成功率是多少？

80% × 80% × 80% × 80% × 80% ≈ 33%

你以为在评估一个“80分”的系统，用户实际感受到的是三成左右的可靠性。

这不是某个模块的问题，是架构设计的问题。级联越深，误差越叠，到最后你会发现：每一个节点单独看都是“正常的”，但整条链路就是跑不稳。这是一类很难被发现的问题，因为你的监控告诉你每个模块都 OK，但用户告诉你“这个东西不好用”。

你评估的是节点成功率，用户感受到的是端到端成功率。 这两个数字之间，隔着一个级联乘法。

二、薄框架，重 Skill

找到问题之后，方向其实清晰：减少中间层。

今天提到了一个硅谷工程师总结的设计哲学：薄框架，重 Skill。

意思是：路由层要薄，能少就少，不要堆中间件；但 Skill（最终执行的能力单元）要做扎实，做丰富。用户的请求尽可能短路径到达最终执行，而不是经过五六道转发、解析、再路由才到。

每一个中间层都有两个代价：一是增加延迟，二是增加失败概率。如果这一层不是必须存在的，它就是个负担。

我们现在的问题是，历史迭代中积累了很多“当时有用”的路由节点，但随着模型能力提升，有些节点已经可以省掉——模型自己就能做好判断，不需要先过一层意图分类再转发。

这不是重构的问题，是不断问自己“这一层为什么存在”的问题。 回答不上来，就该删掉。

三、同步 vs 异步——把非关键路径移出主循环

另一个降低主链路故障率的方向：把不需要实时等待的操作，移到异步执行。

典型的场景是审计日志和知识库写入。这两件事必须发生，但不需要在用户等待回复的这 15 秒里发生。如果把它们放在主循环里同步执行，它们的任何一次超时或报错，都会影响用户看到的结果。

移到异步之后，主循环只做“给用户返回答复”这一件事，其他的事情在后台完成。失败了可以重试，延迟了不影响用户感知。

Claude 有一个功能叫“梦境”——趁用户不看的时候，在后台做一些整理和预热的工作。这个思路是对的：不是所有在对话中发生的事，都需要发生在对话的等待时间里。

把同步和异步的边界划清楚，主循环就会变得干净，故障率自然下降。

四、一个今天才解决的工程细节

工作流里有一类场景：执行到某个节点，需要人工审批，流程暂停，等审批结果。

这在单层图里是有解法的，LangGraph 的 Checkpoint 机制支持暂停和恢复。但我们遇到的问题是嵌套结构——人工审批节点在子图里，父图不知道子图暂停了，也就没办法正确恢复。

这个问题存在了一段时间，昨天终于解决了，今天合进了主版本。

这类问题有一个共同特点：框架文档告诉你“支持断点恢复”，但没告诉你嵌套子图场景下父图感知不到子图状态。你只能在真实构建的过程中撞上它，然后花时间排查。

这也是为什么集成测试比单元测试更重要——你的每个模块都能跑，不代表它们组合在一起也能跑。

五、版本节奏，以及接下来分兵

从这周开始，我们定下了固定的发版节奏：每周二小版本，每周五大版本。 这不只是发布计划，更是一种团队纪律——倒逼每个节点有明确的交付物，不能无限期地“还在改”。

本周五的大版本是知识库相关能力，下周五是工作流。

从下周起，团队会拆成三个方向：Base 层继续迭代、传统贸易行业落地、电商方向探索。Base 层和行业层之间要做好解耦，Base 的每次更新能统一推到上层，而不是每个方向各自维护一套。

这是从“把产品做出来”到“让产品能被复制到行业”的过渡。 以后每个行业工作流做完，就是一个可以直接卖的垂直解。

这，是第二十四天。

《从0到1：企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。

---

如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。