先定义“可用”
不要仅凭几个成功示例判断效果。先收集覆盖常见任务、困难任务与不适用任务的样本，明确结果怎样评估、由谁评估，以及在哪些情况下应拒绝回答或转交人工。
- 输出是否准确、完整，并符合当前业务口径？
- 知识问答是否能提供可核验的来源？
- 响应时间和资源成本是否满足任务要求？
- 错误会造成什么影响，哪些任务不适合自动执行？
把数据与权限纳入设计
确认数据来源、更新方式、可访问范围和保留规则。应用读取文档或调用业务接口时，应遵循使用者与系统的授权边界。需要验证检索、缓存及输出环节是否可能越过这些边界。
不同部署环境、模型供应方和企业制度会影响方案选择，不能用一个通用架构替代具体项目评估。
关键操作保留确认
检索信息与执行操作的风险不同。涉及修改业务记录、对外发送内容或推进关键流程时，应明确哪些操作需要人工确认，怎样展示依据，以及如何取消、撤销或复核。
工具调用的输入、结果和错误需要可追踪；自动化流程应能解释当前进展，避免把失败隐藏在“成功”状态中。
准备失败路径与上线方案
考虑接口超时、模型不可用、数据缺失、任务重复提交和并发使用。对可以重试的操作设计幂等与重试边界，对无法自动恢复的情况明确通知与人工处理方式。
- 保留可回退的版本与发布记录。
- 先在受控范围验证，再扩大使用范围。
- 明确错误、延迟、使用量和成本的观测方式。
- 说明故障时的降级方式、负责人和处理路径。
交接也是交付的一部分
应用上线后，业务规则、知识资料和接口仍会变化。交接资料应说明如何使用、更新、排查问题以及确认改动后的效果。业务负责人和技术负责人应共同明确维护责任。
本指南为实施方法建议，非客户案例；检查项需要按业务场景和项目范围取舍。相关服务见 鸣序科技 FDE 服务说明。