智能体上线那天，项目组通常很兴奋。
演示顺利，领导认可，业务部门开始用。然后项目组撤了，去忙下一个项目。
三个月后，回答开始出错，员工不再用，系统还在，但已经没人管。
智能体不是一次性交付。它需要维护。
要维护什么
知识。 产品、价格、政策会变。知识不更新，回答就会过期。 权限。 员工转岗、离职、项目结束，权限要跟着变。 日志。 谁在什么时候让智能体做了什么，出问题要能查。 评测。 每月用固定测试集跑一次，防止改一个坏三个。 版本。 模型、提示词、工具接口都会变，变更要有记录，能回滚。
这五件事，缺一件，系统就会慢慢失真。
谁负责
建议至少有两个角色：
- 业务 owner：负责知识、场景边界、验收标准；
- 技术 owner：负责接口、权限、日志、版本和故障处理。
不能只写“IT 负责”。IT 管不了业务口径，也判断不了哪条知识该更新。
如果公司小，可以一个人兼两个角色，但责任要写清楚。
维护节奏
每周：看一次未解决问题和转人工记录，补知识或调流程。 每月：跑一次测试集，看准确率、完成率、人工接管率。 每季度：盘一次权限，清理不用的账号和过期资料。 每次变更：记录改了什么，保留回滚版本。
维护不需要很久，但要固定。没有日历提醒，通常就不会做。
没有维护会怎样
一开始只是个别回答不准。员工发现后，会开始绕开系统，回到人工。
然后使用率下降，项目组以为“员工不接受”，其实是系统过期了。
最后系统还在，但没人信。再想重启，成本比第一次上线更高。
一个判断
上线前问三个问题：
- 谁每天看未解决问题？
- 谁每月跑测试集？
- 谁在员工离职时收权限？
三个问题都有名字，系统才有机会长期可用。
维护最好写进合同或岗位说明，不要只靠项目组自觉。可以做一个简单的维护表：知识更新时间、负责人、测试结果、权限变更、故障记录。每月花半小时填一次，比出事后再查有用。系统小的时候，一个人可以兼两个角色，但名字要写上去。维护不是额外工作，是系统的一部分；没有记录，换人就会断档。别等系统出错才想起它。
维护表不要太复杂，能回答“谁、什么时候、改了什么”就够。简单才能坚持，复杂表格通常没人填。维护频率可以低，但不能断；断了再补，成本更高。最好设一个固定日历提醒。
维护要有名字，也要有日期，不然就会拖。要落实。