一个系统能不能真正被团队用起来，不取决于它有多少功能，取决于改一个东西之后要不要重启、本地能不能跑起来、工具调用的 loading 会不会卡住不动。
今天做的大量工作，表面上是修复，本质上是在降低"使用这套系统"的摩擦力------对开发者是本地环境能跑、改动能及时生效；对最终用户是流式响应不卡顿、登录退出行为正常。
这类工作没有什么戏剧性，但它们决定了一个系统是 "能演示"还是"能日常用"。
一、工具热更新：改完不用重启
之前的问题是：后台加了一个新 MCP 工具，webchat 进程能感知到，但 orchestrator 和 worker 进程不知道。结果是前端看起来配置了，Agent 聊天里就是用不了，只能重启 worker 才生效。
修法是在工具变更时向所有进程广播------后台完成增删改后，发一条广播，相关进程收到后刷新自己的工具列表。
这件事背后有一个更普遍的工程问题：多进程架构里，任何一份"运行时状态"都可能在多个进程里有副本，一处更新不等于全局更新。 热更新广播解决的不只是 MCP 工具这一个场景，而是建立了一套进程间状态同步的机制。
二、LLM 链路收口：双轨彻底拆掉
LLM 主链路存在了一段时间的 "双轨"------legacy 路径和 LangChain v1 路径并行存在，靠配置项分发。这种设计在迁移过渡期合理，但如果长期留着，每次排问题都要先确认"当前走的是哪条路"，维护成本越来越高。
这次把 legacy 路径整个删掉，llm_backend、structured_output_backend 相关旧配置一并移除，intent/task/llm 调用统一走 LangChain v1。
双轨存在的时间越长，拆的时候越贵。技术债的利息是按时间收的，不是按代码量收的。 趁着还没有太多下游依赖锁死 legacy 路径，这时候拆是成本最低的窗口。
三、流式事件链修复：工具调用的完整生命周期
流式工具调用一直有一个表现问题：前端工具调用的 loading 状态会卡住不消失。根因在于流式 middleware 里 tool_call_start、tool_call_end、tool_call_error 这几个事件没有被正确透传------前端发出了工具调用请求，但没收到"工具调用结束"的信号，loading 就永远悬着。
同时修的还有两个 Claude 特有问题：消息裁剪时 tool_calls 字段丢失，会导致 Claude 报 400 prefill 错误；llm_turn_end 事件没有携带文本内容，导致某些场景下前端展示不完整。
这三个问题在现象上看起来不相关，但都指向同一件事：流式事件链必须完整，任何一个环节的缺失都会让前端失去状态感知能力。 修的方式是在 middleware 层统一补齐事件，而不是散在各处打补丁。
四、Windows 开发环境可用了
企业 AI 项目大多数人的主力开发机是 Windows，但之前本地跑后端会碰一串问题：asyncio 事件循环在 Windows 默认是 ProactorEventLoop，和 psycopg 异步连接池不兼容；add_signal_handler 在 Windows 下直接报错；子进程管理和日志处理也有差异。
这次把这些问题系统性修掉，同时新增了 run_local.py 一键启动脚本，支持拉起后端服务加前端 Vite，带 --no-migrate、--real-login、--debug、--only 等选项。
开发环境能不能跑起来，是一个人能不能参与进来的门槛。 一个需要踩五个坑才能把本地环境搭起来的项目，实际参与门槛比代码本身高得多。
五、退出登录失效：一个被忽视的 UX 细节
退出登录无效------点了退出，刷新页面还是登录状态。原因是 cookie 在多个 path 下都存着，logout 时只清了一处，其他 path 下的 cookie 还在，下次请求还是带着认证信息过来。
同时修的还有树节点嵌套展示问题（孙节点的缩进层级丢失）和并行任务重复渲染问题。
这类 UX 问题的特点是：在测试阶段很少被专门测，在真实使用中却是第一印象。一个退出登录不生效的系统，会让用户怀疑整个认证体系是否可靠。
今天的工作没有一个"大功能"，但把五六个让系统"不好用"的地方填掉了。LLM 链路的收口、流式事件的修复、Windows 环境的打通，每一件单独看都不算里程碑，合在一起是系统从"可以 demo"走向"可以日常跑"的一步。
这，是第三十八天。
**《从0到1：企业级AI项目迭代日记》**记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。