这个案例说明什么
智能体上线后好不好用，答案在对话记录里。把每一条用户消息归类，就能看出哪些规则智能体没接住、使用方被迫反复交代。
交付物不是一份建议书，而是可以直接部署的规则文件、Skill 和脚本，每一项都配验收用例。
服务对象
某铁路建设指挥部，开发方基于开源 Agent 框架搭建的质量、安全两个智能体
我的角色
独立咨询方。做诊断和优化方案，交付写好的配置、Skill 和脚本，由对方自行部署。
1现象
- 使用方反复口头传达同一批规则：质量口有 14 条规则被重复交代约 40 次。
- 大量用户消息属于「本可不发生」：质量口约 60%，安全口 17%。
- 安全口 12 条运行要求里，只有 2 条真正闭环；配置里还有凭据明文落盘。
2方法
- 会话挖掘脚本抽取全量会话，质量口 457 个运行轮次、422 条用户消息，再人工逐条归到 7 类工作流。
- 规则落位核查逐条检查每项要求有没有落到配置、Skill 或脚本里，落了是否可靠。
- 配置诊断安全口检查 6 项配置，含 1 项正面发现。
- 验收用例每个交付物配验收用例，质量口 16 条，安全口 24 条。
- 独立审查交付前由 Codex 独立审查，质量口 31 项发现全部采纳，安全口审了三轮。
3量化结果
- 422条用户消息逐条归类质量口；安全口另有 226 条
- 约 60%质量口消息本可不发生
- 2 / 12安全口运行要求真正闭环
- 15 / 16质量口验收用例通过
4交付物
- 质量口交付包 29 个文件：智能体规则文件、6 个 Skill、统计与迁移脚本、12 条验收用例
- 安全口交付包 28 个文件：诊断报告与方案 v1.2，26 件成品，验收用例 24 条
- 企业多 Agent 平台共享语义层调研
- GB/T 48000.3 本体建模标准解读，Agent 协同工作平台参考架构
合计 12 条。来源：安全口运行情况诊断报告 v1.2
合计 289 条。来源：质量口会话挖掘诊断报告 v1.1、安全口运行情况诊断报告 v1.2
关键决策与取舍
只交付成品，不碰对方服务器
方案里不出现「给我方开通权限」这类要求。配置、Skill、脚本都写好打包，由对方自行部署。
验证责任按智能体分开定
质量口在我方的测试环境验证；安全口由开发方部署后自验，我方只交付验收用例。
自动上报通道先不加
在规则落位可靠之前不增加新通道，先把已有要求接住。