五一节前最后一天，腾讯会议集成做了一次比较完整的优化：用户可以在聊天里直接配置自己的会议 token，转写和纪要在模型回复之后，气泡上方会直接弹出下载按钮，不用再跳转页面。
测试通过。上线。
放了五天假，今天开会，发现下载按钮不见了。
没有报错，没有日志，功能就这么安静地没了。
一、两个功能消失，原因一模一样
飞书端也有一个类似的故事。
此前曾经实现过一个不小的能力------飞书支持直接推送文件类型的消息。流程是：先把文件下到本地，上传到飞书云端，拿回 filekey，再把这个 key 推进消息里。用户收到的不是下载链接，而是一个可以在飞书里直接打开的文件。这个功能之前测试通过过一次，后来 webchat 和飞书消息逻辑做了合并统一，那段行为也跟着消失了。
两个功能，失踪原因相同：不是谁写错了代码，而是多人并行改动在合并时，某个边界处的行为悄悄变了，没有人注意到。
这是规模扩展的代价。团队越大，并行改动越多，这种问题出现的概率就越高------不是技术问题，是协作结构问题。
针对这两个功能，现在的处理方式是把它们各自写成集成测试用例，加进 QA Runner 里。往后只要任何改动触碰到这两段行为，Runner 就会在第一时间告警，锁住问题，定位是哪一层出了岔子。
不是在防止 Bug，是在确保 Bug 出现时能被看见。
二、空回复的根因，藏在意图路由里
意图识别那边，五一前后一直在修一个问题。
场景是：用户说"帮我查一下最近的会议记录"，没提"腾讯"两个字。系统意图路由一看，觉得这是在查文件，就把请求推给了知识库节点。知识库里没有这类内容，空手而归，整个对话流就僵在那里------用户收到了一个什么都没有的回复。
修法是在知识库节点之后把 ReAct 循环接上去。即使知识库没查到东西，循环依然继续推理，它会识别到"会议"这个关键词，进而调用腾讯会议的 MCP 工具，再把结果返回给用户。
路由没走对，但循环把它兜住了。
这是图结构重构之后带来的一个副产品：节点职责清晰，某个节点空手而归，链路不会因此断掉。空回复这个问题，算是彻底关掉了。
三、超时设置，是下一个要拆的炸弹
今天讨论时间最长的问题：全链路超时。
现在的情况是前端有超时、后端有超时、各个中间节点也可能有超时。前端的超时时间目前设的是 20 秒，只要某个环节稍微慢一点，用户侧看到的就是"系统繁忙"，然后什么都没了。问题是你不知道是哪里慢了，也不知道那个请求走到哪一步断的。
做并行任务测试的时候更明显------某些任务需要四五百秒，任何一层超时都能把它切断。
讨论下来，方向是把超时机制整体去掉，换成推理过程的流式显示。用户看到的不是转圈等待，而是系统当前走到哪个节点、在做什么、调用了什么工具。推理过程本身就是进度条，步骤可见就不会觉得系统挂了。
这个改法顺带解决了另一个问题：人工审核节点该在哪里出现。如果工作流每步都可见，审核按钮就放在那个节点旁边，需要的时候点，不打断聊天流。
四、腾讯会议 MCP，暴露了两个典型的模糊地带
腾讯会议的 MCP 接口，这段时间测出了两个比较具体的问题。
一个是时间区间模糊。"帮我查最近的会议记录"，"最近"是多久？大模型会自己决定一个时间窗口，但没有约束的情况下，不同的模型、不同的上下文，给出的窗口差距很大。用户发现查出来的会议对不上，多半是因为时间被模型随意解读了。
另一个是状态过滤。腾讯会议 MCP 的查询接口有一个状态参数，早期版本默认只返回"已结束"的会议，进行中的、待开始的全被过滤掉，用户的会议列表里有很多内容，查出来却只有一小部分。现在的修法是把状态传成 all，查回全部状态再让模型判断。时间区间的问题还在处理中。
这两个 Bug 有个共同特征：不是代码写错了，是模型的决策和接口设计之间留了一段没有约束的空地，问题就长在那里。
五、意图识别不到，不应该打断用户
飞书端和 webchat 端，在意图兜底这件事上有一个差异。
webchat 那边，如果模型判断出的意图可信度太低，界面会弹出选项卡让用户手动选："你是想做 A 还是 B？"这个设计在 PC 端还能接受，但飞书是移动聊天流，中途弹出选项让用户选，体验上很割裂。
更合理的方向是：识别不到意图，不打断用户，直接把原始输入交给大模型作为闲聊兜底处理。模型用上下文推断，用户感知不到路由失败这件事。
真正需要人工介入的，只有那些需要明确授权的操作------敏感工具调用、需要审核的输出------这些才值得让用户停下来确认。意图不明这种事，机器自己处理就行。
六、五一"休假"，其实在找图编辑的出路
假期间，图编辑的问题一直没有完全放下。
现有的图编辑界面是自己手写的，改起来难度不小。于是花了一两天去研究同类开源项目，看他们怎么做专门的拖拽式工作流------找到了一个叫 Lam Flow 的开源方案，内置了大量节点类型，低代码化程度比较高，UI 细节也比现有的要成熟。
但它用的底层是 Nine Chart，只支持单向工作流，没有循环结构。我们的 Agent 图需要支持循环和断点恢复，这条路走不通。
目前还在找基于 Net Graphic 做的 UI 方案。知识库那边进展相对顺利一些------召回已经接进了主流程，后台可以看到知识图谱的实体关系，文档里涉及的人名、机构、关键词之间的关联，都能以图的形式展示出来。
七、右侧多了一栏，聊天界面要变了
今天聊到一个对产品体验影响比较深远的方向：把工作流节点可视化带进聊天界面。
新的设计思路是在聊天框右侧，实时展示当前对话的完整工作流进度------每个节点的名称、状态、响应时间，工具调用了什么，输入输出是什么。人工审核如果需要触发，按钮就出现在那个节点旁边。中间区域是聊天本身，工具选择、语音输入、文件上传放在输入框旁边。
这不只是视觉改变。它意味着系统的行为第一次对用户变得可解释、可观测、可干预。
与此同时，后台那些只有实施人员才用得到的东西（Graph 管理、节点配置、意图体系配置）和普通用户用到的东西（聊天、设置、知识库入口）要彻底拆开，各放其位。这件事从架构上讨论过很多次，现在终于要落到 UI 上了。
八、接口标准，是下周最重要的一张图纸
结尾说一件今天提到但分量不轻的事：基座化的接口标准要定下来。
不管是腾讯会议、知识库、飞书，还是之后要做的垂直行业场景，所有能力都要从同一个出口进出。这个出口的输入格式、输出规范、错误处理机制，需要在这周内明确成文。周五前的目标是：稳定版图编辑上线，接口标准第一稿拿出来讨论。
底座稳了，上面才能快。 垂直行业的工具包，要能在这个标准上一层层叠进去，不需要每次都往核心层改。
有个声音在今天的会议里反复出现：再不推，黄花菜就凉了。
大厂都在做 Agent，但他们做的是通用能力；我们要做的是针对具体行业的定制------电商、财务、制造，每个场景的工作流都是不一样的，通用底座+行业插件，这条路走得越快，护城河就越深。
这件事没有等的道理。
这，是第十八天。
**《从0到1：企业级AI项目迭代日记》**记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。