FDE × Agent
让 AI 真正进业务
谁来改造流程？Agent 在哪里干活？
价值怎样落到开源、节流和组织能力？
老板买的不是 AI，
而是一段业务改善
客户少等待，员工少切系统。
同样的团队，承接更多业务量。
按当前制度办事，关键动作留痕。
减少查找、搬运、返工和无效等待。
FDE 是人／团队；
Agent 是一套系统
找真问题、做方案取舍、接入现场、推动上线并验证结果。
读懂情况、判断下一步、调用受控工具，完成或升级任务。
模型可以通用，
流程、数据和责任却各不相同
现场到底卡在哪。
结果、范围与风险。
人、Agent与规则分工。
接数据、知识和工具。
沙箱、影子、试点、灰度。
看采用、成本与结果。
不是谁更高级，
而是谁主要对哪段结果负责
诊断问题、提出建议，重点是“方向是否清楚”。
验证匹配、演示方案，重点是“客户是否愿意采用”。
在明确范围内建设系统，重点是“软件是否做对”。
把模糊问题一路做到生产使用，重点是“流程是否跑通”。
固定规则能解决，优先普通软件；
复杂判断难覆盖，再考虑 Agent
- 输入主要是表单和字段
- 步骤稳定，可以提前写清
- 错误代价高，需要强确定性
- 要理解工单、对话和附件
- 例外多，规则维护越来越难
- 要结合多个系统选择下一步
客户只提交一张工单，
背后却是一整条业务链
“设备用了一个月就出现异响，上周师傅来过但没有修好。合同说一年保修，现在影响生产，怎么处理？”情景示例，用于解释方法；不代表真实企业或已部署结果。
问答型 AI 停在建议；
Agent 继续把任务向前推进
根据工单生成一次回复，但不会主动核对业务事实。
围绕目标观察、判断、调用受控工具，直到完成、拒绝或转人工。
Agent 不是一个模型，
而是一套工作系统
推进处理，但不承诺赔偿。
读懂复修失败和停产影响。
工单、当前记录和有效制度。
查事实、提交处理方案。
检查缺项；完成、停止或转人。
客服小李不是在处理一张工单，
而是在手工拼一条业务链
理解故障和生产影响。
核对设备和保修范围。
确认上门记录和结果。
寻找备件和工程师排期。
选择补信息、上门或升级。
回复、派单、通知和跟进。
先把四件事问清楚：
结果、基线、权限、责任
更快形成可执行方案，减少错判保修、重复派单和错误承诺。
现在每单查几个系统、处理多久、返工多少、客户等待多久。
能读哪些合同和记录，哪些数据不能发给外部模型，首版禁止哪些动作。
谁确认、谁接管、多久响应，以及客服是否真的愿意每天使用。
先做“带依据的处理方案”
暂不自动回复和派单
- 自动承诺维修时间和赔偿
- 自动创建上门任务并通知客户
- 一旦错判，损失和争议很难撤回
- Agent 生成依据和待确认方案
- 客服确认后，系统才回复和派单
- 赔偿仍由有权限的负责人决定
看、查、判、写、交：
把每张工单推进到可确认方案
在不自动承诺赔偿和派单的前提下，判断补充信息、二次上门还是升级主管，并给客服一份有依据的处理方案。
合同、维修记录和工程师排期来自业务系统；信息不足、数据冲突或风险过高则停止并转人工。
让模型处理不确定判断，
让代码锁住权限和固定步骤
理解与建议
是否复修失败？还缺什么？该上门还是升级？
处理工单语言、上下文和例外。
校验与执行
能否查看？是否在保修？是否重复派单？
硬规则校验；经确认后创建并回写任务。
决定与负责
赔多少钱？是否承担停产损失？是否改合同？
有权人员批准、接管并承担责任。
FDE 不只证明“它能成功”
还要主动寻找它会怎样失败
省下时间只是产能，
转化成经营收益才叫价值
新增总成本包括：模型、检索与工具、系统集成、运维、人工审核、员工培训和流程调整。
开源不是让 AI 凭空卖货，
而是少错过本来存在的机会
高意向客户更早得到有效回复
看线索响应时间过去顾不过来的长尾客户也能被跟进
看有效跟进覆盖率结合库存、交期和客户上下文建议下一步
看有效机会、转化与毛利把一线反复出现的问题反馈给产品
看问题闭环周期好的 FDE 交付会留下能力，
而不是制造新的依赖
- 制度、工具和权限有负责人
- 测试、日志和运行手册可交接
- 内部团队能运行、评估和排错
- 重复需求变成通用能力
- 失败案例变成回归测试
- 避免每个客户都从零定制
不是只懂行业，
也不是只会模型
代码、数据、API、云与安全
＋ Agent、知识、工具和评估
也能打开终端解决问题。
不懂训练大模型仍有机会，但如果没人能建设和维护生产系统，就不能把团队包装成完整 FDE。