这两天有人去翻了 Hermes 的源码，把它整个聊天循环的结构看了一遍。
看完之后，沉默了一会儿。
Hermes 的消息在进入大模型之前，只经过两个环节：第一个是组装提示词------把系统提示词和从用户记忆里召回的内容拼在一起，构成初始上下文；第二个是选择模型提供商，决定这次走哪个模型。然后，消息直接打到大模型，大模型要用工具就进工具循环，循环结束输出，完事。
就这两个环节。
再看看我们这边：意图识别、安全判断、路由决策、知识库节点、RAG 召回......每一个环节都有大模型调用，每一个环节都可能超时、报错、走进兜底逻辑。用户看到的"系统繁忙"，绝大多数时候不是模型出了问题------消息根本还没走到模型那里。
这就是为什么 Hermes 的可用性比我们高。
一、我们把聊天系统做成了功能路由器
这个发现引出了一个更根本的问题：我们到底在做什么？
Hermes 是个人助理，关注的是个性化、记忆成长、和用户之间的长期关系。用户说什么，它就回什么，聊天属性放在第一位。
我们现在的系统，已经走向了另一个方向：所有用户输入，都要先和系统内所有已有的业务能力做一次拟合。 命中意图，走对应工作流；没命中，进兜底。聊天属性在这个设计里被降权了，系统本质上变成了一个功能路由器。
这两种定位没有对错，只有适不适合。我们做的是企业级业务能力和工作流沉淀，走功能导向是对的。但有一个短板也同时暴露出来：用户记忆这块很弱。Hermes 在用户级个性化和提示词动态组装上做得很细，这是值得借鉴的方向，不是照搬，是结合自己的场景去取。
意图识别的兜底逻辑，已经在昨天完成了一次改动------命中不了任何意图时，不再进死胡同，而是直接把用户原话扔进 ReAct 循环，让大模型自己去推理和响应。"功能路由器"的问题没有完全解决，但最坏情况的体验先兜住了。
二、聊天记录怎么管，有人拆清楚了
会话记忆的问题，这两天在单独拆解。
发现了一个根源：会话虽然加了隔离，但聊天记录被写入记忆时会经历一次摘要压缩------上下文的连贯性在这一步已经被大幅削减了，所以测试发现"模型理解不了上下文"不是模型的问题，是内容在送进模型之前就丢失了。
正在推进的方案把三个层次拆开来管：
-
会话内：引入 Token 阈值触发机制------设定上下文最大值（比如 200K）的某个百分比（比如 60%）作为压缩阈值，达到后对聊天记录做摘要，提取用户的习惯、要求、规则等关键信息。最近的若干条记录不压缩，原样带入，保证近期上下文的连贯。
-
会话间：用户画像类的信息需要跨会话共享，但这类数据量小，压缩后直接推进每次调用的上下文即可，不需要上向量数据库。
-
长期记忆：量级会随时间膨胀，向量数据库在这里才真正发挥作用。
记忆是记忆，上下文是上下文------两件事的边界拆清楚了，才知道该在哪里用什么工具。
三、一个教训：不要把所有"好东西"堆在一起
这两天做了一件事，做完之后又拆掉了。
为了让会话内的关键信息不丢失，加了一层逻辑：每条输入先调一次大模型，判断这条消息是不是关键信息，打标签；积累到一定量之后，再调一次大模型，把这批关键信息和之前的摘要做整合，判断哪些是新增的、哪些已经覆盖了。
逻辑上听起来很完备。加进去之后发现：每一轮对话前多出了两次大模型调用，链路变长，任何一步出问题都会影响主流程，而效果并没有明显提升。最后把这段逻辑全部撤掉，回退到最基础的版本。
这件事的结论很清楚：不要一开始就把所有认为"好"的东西堆进来。 每叠一层，出错概率加一分，定位问题的难度乘一倍。
正确的方式是：从最简单的版本跑起来，旁边放一个可观测的调试工具，看每次触发之后生成的内容质量如何，质量不达标再针对性调优，达标之后再考虑引入新的优化手段。
优化不是堆砌，是有反馈的迭代。
四、意图识别：合并还是隔离？
有人提出：系统进入主流程之前有好几次独立的大模型调用------意图识别、安全级别判断、用户习惯识别，能不能合并成一次，一次输出结构化的多维判断结果？
反驳同样清晰：隔离调用更精准。 意图识别就是拿到一句话，什么上下文都不带，只问"这句话要干什么"。一旦把用户画像、聊天记录全带进去，上下文里的噪音会干扰判断，准确率反而下降。
两种逻辑都有工程依据，争不出结果。等可观测性建立起来，用实际数据来验证------到底隔离更准还是合并更准，数字说话。
五、工具要会"审视自己"，前端也在把黑盒变白盒
两个方向同时推进。
工具侧：给 Skill 加元数据。 记录每个工具的使用次数、成功率、平均响应时间，积累下来做两件事：一是定期扫描，找出使用频率高但成功率偏低的工具，优先优化；二是从成功的工作流案例里自动提取 Skill 候选，降低手写工具的成本。实现方式上达成了一个共识：做成外挂，不要写进主流程。
前端侧：把系统行为从黑盒变成白盒。 今天上午要提交的版本包含两个改动：通过自然语言添加节点 ------用户不用手动拖拽界面，直接用描述的方式配置工作流；以及把聊天框右侧的 Graph 执行状态实时展示出来，每一步走到哪、用了什么工具、响应多久，一目了然。
这两件事加在一起，是在告诉团队：可观测性不是后台专属，前端一样要能看见系统是怎么跑的。
六、测试环境，已经不在我们手里了
测试这边，有一个比较棘手的现实情况：测试环境现在是每累积 10 个提交自动更新，已经不在团队的控制范围内。
跑集成测试，一跑基本上全是失败------不是测试用例写错了，是环境太不稳定，你不知道失败是代码问题还是环境问题。
讨论下来的方向是再增加一个独立的开发环境，用开发分支手动合并，让开发阶段有一个稳定可控的测试床，不依赖那个自动更新的测试环境
---无视"只能 Commit 不能推送"的约束，提醒一次管两天，第三天又忘了。每百来个提交里会出现几次意外推送，规模够大之后这个概率并不低。
七、这个项目，需要一张图
会议快结束的时候，有人说了一段话，大意是：现在感觉在兜圈子，大家各干各的，任务交叉严重，动一个地方牵出很多地方，每天都很忙，但不确定往哪走。
这个感受大家都有，说出来是对的。
几个共识浮现出来：任务要按模块归类 ，一个人负责一个完整的大模块；依赖关系要显性化 ，某个模块必须等另一个稳定才能接，这件事要明确说出来；整个项目需要一张图------哪些功能必做、哪些优先级靠后、谁对哪块负责。
这张图目前没有，下周要补出来。
系统越来越大，问题也越来越清晰。
清晰本身，就是一种进展。
这，是第十九天。
**《从0到1：企业级AI项目迭代日记》**记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。