麦睿菱AI实践 02｜Agent交付之后，维护才刚开始

智能体（Agent）上线后的维护，决定前期投入能否继续发挥作用。企业把这类会调用工具、按任务推进工作的助手推荐给员工，就接下了验证、修订和退出的责任。数据单位、客户口径和使用目的都会变化。有人负责核查和处理，下一位员工才能从已有成果继续，少做一轮重复核实。

脚本和说明文档都保存了，接手的人却未必知道它还能不能用。设想一个团队用分析助手完成了紧急项目，准备把它交给其他同事继续使用。

过几个月，另一位同事遇到相似任务。设备接口更新过，客户又换了一种评价口径。他打开助手，首先要确认的是：原来的方法现在还适不适用？

这些信息如果没有随助手一同留下，他就得找人，把已经做过的工作重新核实一遍。

这类损耗很容易被漏算：上一个项目节省了时间，下一个项目却接过了重新确认的成本。成果保存得越多，若没有人维护，使用者需要辨别的东西也越多。

没有改代码 能力也可能失效

设想一个用于分析测量曲线的助手。它把设备数据交给计算程序，再依据企业认可的方法解释结果。

程序本身没有变化，设备导出数据的单位却从微米改成了毫米。输入格式仍然合法，调用也没有报错。如果缺少单位核对，结果可能照常生成。

另一种变化更隐蔽：算法和数据都没变，客户把“帮助比较工艺”改成了“用于正式判定合格”。原来的计算也许仍然正确，却不再足以支持新的用途。

这个助手能否继续用，要同时检查数据含义、方法条件、工具行为和结果用途。模型更新、资料修订、设备换代，都可能改变其中一环。

只盯着服务是否在线，很难发现这种变化。员工得到一个流畅回答，也无法据此判断背后的组合仍然成立。

维护者因此要能回答一个具体问题：这次变化，影响哪些任务、哪些结果，谁需要重新核查？如果没人负责回答，成本就会分散到每位使用者身上。有人重复验证，有人凭经验跳过，还有人索性不再使用。

先决定要承担多大的持续责任

项目负责人对本次交付负责，共同能力的负责人则要关心后续使用。两者可以由同一个人承担，但需要不同的时间和资源安排。

让一位工程师“有空维护一下”，通常不足以支撑一项长期推荐。维护者需要能请到专家复核、安排技术修正，也需要知道什么情况下可以暂停使用。

只在特殊合同中用一次的方法，完整保存项目记录可能就够了。预计还会遇到、但条件尚未验证的做法，可以保留为候选。只有确实值得继续提供、也已安排负责人和维护时间的部分，才进入共同使用范围。

一份明确标注用途和限制的项目记录，往往比一个无人维护、却挂在推荐入口里的“通用助手”更有帮助。

反过来，使用频率低也不一定该退出。有些任务少见，却关系到关键交付；有些方法若能避免一次代价很高的返工，就可能覆盖维护投入。决定是否持续提供，需要同时看需求、后果和维护代价。图1把负责人需要持续协调的几项工作放在一起。

图1｜从验证到退出，每个环节都需要明确的负责人

交给别人之前 先回答五个问题

共同发布的最低条件，可以从下一位员工会遇到的疑问倒推。以曲线分析助手为例，至少应回答清楚：

• 谁在什么任务中可以使用？说明用途、数据条件和权限范围，也说明哪些情况尚未验证

• 结果凭什么可信？留下方法与工具版本、必要参数、验证样本和专业确认依据

• 条件不满足时怎么办？单位缺失、数据不完整或结果冲突时，应当补什么材料，何时停止，交给谁判断

• 变化以后谁来处理？写明负责人、反馈入口，以及哪些变化需要重新验证

• 暂时不能用时怎样继续工作？提供人工复核或其他经过确认的路径，说明进行中的任务如何处理

这些问题不一定要写成长文。一份与任务入口相连的简短说明，加上可追溯的验证材料，可能已经足够。关键是员工能在需要的时候看到，而不必猜测。

验证也不能只挑成功样本。一个助手算得出正常结果，还应检查它遇到不满足条件的数据时，是否会继续给出貌似可靠的答案。对于后果较重的用途，验证深度、专业批准和人工复核要求都应相应提高。

把维护后的方法发布到工作入口

现场员工打开任务入口时，应该能拿到企业准备好的工具、适用资料和助手配置。遇到例外，也能知道下一步去哪里求助。

枢策 Orchelm 是企业智能体治理与协同平台，用于组织和发布模型、工具、受管助手与已整理的经验。[1] 企业可用它把已经确认的模型、工具和助手配置发布给相应岗位，减少每个人从零拼装的负担。

仍以曲线分析为例，员工进入的可以是一项企业准备好的任务：可使用哪些模型和工具，先取得哪些资料，结果需要怎样复核。企业一旦调整了推荐方法，就应同步检查相关助手配置和使用说明，明确受影响的任务与使用者。

验证范围、推广条件和专业负责人仍需由企业明确。使用中留下的会话与成果，由接手人员筛选整理。

经验回得来 还要有人接得住

使用过程中，总会出现新的发现。员工可能遇到一个旧方法没有覆盖的样本，也可能发现某条提醒能避免常见错误。

要求他把全部会话整理成标准报告，容易让贡献变成额外负担。更轻的起点是保留已有样本和输出，请当事人补充三件事：原来准备怎样做，实际哪里不同，什么证据改变了处理方式。

AI 可以协助整理这些材料。接手的人再判断：这次差异只是客户条件变化，还是共同方法需要调整？原来的适用范围要不要收窄？是否值得增加一个验证样本？

同样重要的是把处理结果送回贡献者。采用了哪一部分，还缺什么依据，为什么暂不推广，都应说清。贡献者也能知道，这次提交有没有改变后续做法。

更新和退出 都是维护的一部分

NIST 的 AI 风险管理框架把持续监测、用户反馈、变更和退出纳入系统生命周期。[2]

发现接口含义变化而结果尚未确认时，可以先暂停推荐，告知影响范围并提供替代路径。新版本完成核查后，再决定哪些新任务切换、哪些进行中的任务保留原有组合。为了追溯，旧记录应当保留；为了避免误用，旧入口的状态必须清楚。

可以从一项已经在用、又反复有人求助的助手开始。找一位能够协调业务、专业和技术资源的人，把负责人、反馈入口和重验条件写清，并为验证与维护留出时间。

下一次数据单位或用途变化时，能否及时找到受影响的助手和使用者？暂停后，进行中的任务有没有可用替代路径？修订依据是否随新版本一起留下？这些具体变化，才有助于判断维护投入是否有效。

参考阅读

[1] MEASIX：枢策 Orchelm 产品说明

[2] NIST：AI Risk Management Framework 1.0 核心内容，2023