产品里最多的那类 bug，不是逻辑错了，而是功能只做了一半：能新建，但不能编辑；能绑定，但切换后状态丢失；能配置，但配置在运行时没生效。
用户感知到的不是"有个细节没处理"，而是"这东西不可靠"。
这一轮的工作，是把智能体中心从"能演示"推到"能用"。
一、新建之后，编辑在哪里
智能体中心上线的时候，支持新建智能体、绑定工具、配置知识库。但有一个问题没处理：建完之后，能不能改？
编辑能力不是新建能力的简单复用。新建时字段是空的，填进去就好；编辑时字段是有值的，加载、回填、修改、保存------每一步都可能出错。这轮发现的一个阻断问题是：编辑时高级配置字段会被误清空，保存之后等于把之前填好的内容覆盖掉了。
这类 bug 特别危险，因为它没有报错，用户也不一定意识到数据丢了，直到某天发现智能体"行为变了"才开始排查。
修复之后补齐了编辑智能体的完整链路，同时把高级选项默认折叠、知识库和技能列表支持滚动、模型下拉去重------这些都是"建完之后真的要用"才会碰到的问题。
二、知识库：接口对了，但接的不是同一个东西
智能体绑定知识库，听起来是一个绑定操作，但底层有一个隐藏问题：绑定的是哪个知识库体系？
系统里同时存在两套知识库，如果绑定接口对接的是旧体系，用户在前端选了知识库，实际上并没有接上任何东西，智能体运行时查询不到任何内容，但也不会报错。这是一类典型的"接口对齐问题"：两端各自运行，但对接的不是同一个对象。
这轮把绑定逻辑切到了线上真正在用的知识库体系，同时修了一个中文名称或特殊字符导致路径解析失败的问题------URL 编码这种事，在英文环境下测不出来，上线后遇到中文名称就断。
三、MCP：从全局注册表到运行时发现
原来的 MCP 工具加载方式是全局注册表：系统启动时注册所有工具，每次请求从注册表里取。这个模式在单租户下没问题，但在多租户环境里会出现两类问题：一是可见性问题，某些平台基线工具在特定租户下不可见；二是隔离问题，全局注册表的状态是共享的，一个租户的工具配置可能影响到另一个租户。
这轮把 MCP 工具的加载改成运行时发现加注入：每次请求时根据当前租户上下文动态发现可用工具，不走全局注册表。同时把工具选择的粒度从工具级改成服务级，用户选择的是哪个 MCP 服务，而不是服务下的每一个工具。
同时修了两个高优问题：TLS 校验被误关掉------这是调试期的临时改动，不应该进生产；发现期缺少鉴权头，导致需要认证的外部服务连不上。
四、安全默认值与升级保护
默认智能体会加载所有内置工具，其中包括执行系统命令和操作进程的工具。这在开发环境是方便的，在生产环境是危险的------如果用户能通过对话触发这类工具，等于在运行容器内有了一个 shell 入口。
修复方式是把这类工具从默认工具集里排除，需要显式配置才能启用。这是一个"安全默认值"的问题------系统的默认状态应该是安全的，不安全的能力需要主动开启，而不是主动关闭。
滚动升级保护机制是用来保证升级时最少有几个副本在线的。但如果只有一个副本，这个配置会变成"必须有一个副本在线，但你要杀掉这唯一一个"------节点排空会永远阻塞，升级永远完不成。这轮修了单副本场景下的保护逻辑，避免运维操作卡死。
智能体中心从第一个提交到这一轮，做了四件事：能建、能编、能绑、能用。 每一件单独看都不复杂，但要四件都做到位，需要把每一个细节走完。
发版之后有人问："为什么智能体中心花了这么久？"因为做一个功能和把一个功能做完，中间差了编辑能力、知识库对齐、运行时解耦、安全默认值、升级保护逻辑。
这，是第五十五天。
**《从0到1：企业级AI项目迭代日记》**记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。
如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。