交付方法论
为什么方法论比模型选型重要
换一个模型通常只影响效果的一小部分，而流程设计与评测体系决定大部分结果。我们把这套流程完整公开——包括每个阶段的退出条件，以及什么情况下我们会建议你停止投入。
诊断
1–2 周
盘业务流程，找出 3 个值得做 Agent 的环节，输出诊断报告与 ROI 测算
输入
业务流程访谈、现有系统清单、历史数据样本
主要动作
- 梳理可 Agent 化的环节，按「人力消耗 × 数据可得性 × 出错代价」排序
- 测算现有环节的人力成本与出错成本
- 核对数据是否已电子化、能否通过 API 或数据库访问
交付物
《诊断报告》：场景排序、ROI 测算、风险清单
退出条件
若测算下来不成立，我们直接告诉你不要做——这份报告也可能是「不建议投入」的结论
设计
1 周
定义 Agent 边界、人机分工、评测指标与验收线
输入
诊断阶段确认的目标场景、业务负责人访谈
主要动作
- 先定义「什么情况必须转人工」，再定义能力范围
- 确定失败降级策略：工具超时、检索冲突、置信度不足时怎么处理
- 与业务方书面确认评测指标与验收线
交付物
Agent 能力边界文档、人机分工图、评测指标与验收线、降级策略
退出条件
业务负责人书面确认验收线；未确认不进入建造
建造
2–4 周
接系统、搭检索、编排工作流、接权限网关
输入
确认后的设计与所需系统访问权限
主要动作
- 知识治理：文档结构还原、版本与生效日期标注、冲突检测
- 对接业务系统 API，配置权限网关与字段级脱敏
- 编排多步工作流，配置工具调用与超时降级
- 搭建日志与审计链路
交付物
可运行 Agent、系统集成、权限网关、日志与审计
退出条件
内部自测通过，进入验证阶段
验证
1–2 周
跑评测集，对照验收线，不达标不进下一步
输入
评审集（分层抽样）、验收线
主要动作
- 离线评测：逐条对照验收线，报告必须附失败案例分析
- 对照人工基线，明确哪些指标我们还不如人工
- 回归测试：工具故障、知识冲突、越权请求等边界用例
交付物
评测报告（含失败案例分析）、对照基线数据
退出条件
达到验收线才进入上线；未达标则回到建造或按约定退款
上线与运维
持续
灰度上线、监控看板、月度迭代
输入
通过验证的 Agent、业务方确认的上线计划
主要动作
- 灰度上线并由业务方观察真实使用情况
- 监控告警：处理量、转人工率、异常回答、工具失败率
- 月度评测回归，防止知识漂移与效果衰减
- 评测集与运维手册交付客户，支持自行接管
交付物
运维手册、评测集、监控看板、月度迭代记录
退出条件
客户可自行接管；不订阅运维也可以
评测体系
没有评测集，就没有交付
这是我们和大多数团队最本质的区别。我们不接受「看起来效果不错」作为交付标准，也不同意在缺少评测的情况下上线。
离线评测集
从真实历史数据中分层抽样构建，覆盖高频简单问题、低频复杂问题、边界与故障用例（工具超时、知识冲突、越权请求）。样本量与抽样方式必须写进报告。
线上灰度对照
上线后与人工处理结果做同期对照，而不是只看绝对数值。这一步才能发现流量结构变化带来的效果漂移。
人工抽检
按固定比例抽检线上真实会话，由业务方人员判定。抽检比例与判定标准在阶段二就确定，避免事后调整口径。
失败案例分析
评测报告必须包含失败案例分析——哪些问题答错了、为什么错、是知识问题还是编排问题。只给准确率的报告没有意义。
幻觉与越权拦截率
单独统计模型在缺少工具返回值时是否自行编造、是否触发了不允许的操作。这两项是安全底线，不作为效果指标。
回归测试
每次知识库更新或提示词调整后重跑评测集，防止修好一个问题、弄坏另外三个。这是长期运维里最主要的日常工作。
边界
我们明确不做的三件事
把边界说清楚，比把能力说满更有用。这三条不是谦虚，是我们认为做了会损害交付质量的取舍。
不做模型训练与微调
微调的知识更新成本高、可解释性差，在绝大多数业务场景里不如检索增强加工具调用来得实在。需要微调的场景我们会建议交给专门团队。
不做没有评测指标的交付
如果无法定义一个可测量的成功指标，说明这个场景还没有被想清楚。这种情况下开工，最后只能靠感觉验收，对双方都是浪费。
不做无法人工兜底的自动化
任何涉及资金、合规、人身安全的决策环节，都必须保留人工确认。我们不交付「没有人管」的自动化流程。
想知道这套流程用在你自己的场景上会是什么样？预约免费初诊。