从0到1：企业级AI项目迭代日记 Vol.58｜一个工单解决的事，不值得等一个发版周期

今天有人问了两个问题。

第一个：为什么在测试环境里调试好的 Agent，上了生产环境就变了？第二个：为什么一个客户想调整一下邮件模板的样式，需要等下一个发版周期？

两个问题的答案指向同一件事：我们把太多属于“配置”范畴的东西，写进了代码里。

一、开发环境和生产环境，配置不一致

测试环境调得好好的 Agent，上生产环境表现不一样——最常见的原因不是代码变了，是环境配置变了。模型版本不一样、工具集不一样、知识库不一样、甚至底层服务的地址不一样，任何一个变量不同，结果都可能偏差。

这次把“配置”和“逻辑”彻底拆开了。Agent 的完整配置（模型、工具、知识库、技能）可以按环境独立维护。同一个 Agent，测试环境用最新的实验模型跑验证，生产环境跑稳定模型，互不干扰。管理员可以在 Admin 后台选择“复制上一份配置到当前环境”，再手动调整差异项。发版时，每个环境的配置独立演进，互不覆盖。

配套的分支策略也做了调整：主分支只接纳经过完整回归的稳定代码。测试环境跑的是开发分支，验证通过后通过合并请求合入主分支。生产环境只从主分支拉取发布版本，不直接接收开发分支的代码。同时修了一个配套问题：发版前做数据库结构迁移时，迁移脚本按时间顺序线性编号。以前多个人并行开发时可能写出相同编号的迁移文件，导致发版时迁移失败。现在做了冲突预防机制，同一个编号只能被一个人占用，其他人必须跳过。

配置不用改代码、环境独立演进、分支策略隔离——三者合在一起，测试环境和生产环境“不一致”的问题才算真正解决。

二、工具发现和工具使用分开

MCP 工具集管理有一个常见的问题：平台内置的工具和用户自定义的 MCP 工具混在一起，用户不知道哪个是平台提供的、哪个是自己接的，也不知道哪些工具在当前环境下是可用的。

这次拆成了两步：第一步是“工具发现”——系统列出所有可用的工具，并标注来源（平台内置/自定义MCP）和环境可用性；第二步是“工具选择使用”——用户在 Agent 配置里从已发现的工具中挑选需要的勾选。

这样一来，用户可以看清自己接入了什么，管理也有清晰的入口。Agent 加载工具时只读取已选中的子集，不会把全量工具塞进上下文撑爆窗口。

之前还有一个问题：MCP 工具如果返回了超大结果，会直接塞进上下文，阻塞后续推理。现在对这些结果做了大小限制，超过阈值的会被截断或摘要处理，不会让一条工具返回值毁掉整段对话。

三、日志分层：让排查不再需要翻几万行记录

之前排查一个问题，大概流程是：翻几万行日志记录，找到那条报错，再顺着链路往前倒。一次排查半小时起步。

这次做了两件事：一是日志分层，正常运行的日志和错误日志分开存储，排查时只查错误日志，不需要在大海里捞针；二是执行链路追踪，每一条请求从入口到出口都有一个唯一标识，所有相关日志打上同一个标识，顺藤摸瓜一次看完。

同时把日志存储策略也调了一下：保留周期从永久改成滚动保留，避免存储无限膨胀；引入冷热分层，近期日志走高速查询，老旧日志压缩归档。

这一轮改动的共同逻辑是：配置不用改代码、工具拆成两步走、日志分层可追踪。每一条都是“工单级”的优化——单个改动不大，但用户每天都会碰到。

这，是第五十八天。

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

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