我们来看一个常见的需求：客服负责人希望 Agent 每周汇总所有客诉升级的工单，自动生成一份给管理层汇报的报告草稿。
如果只看架构，这件事并不复杂。Agent 从几个系统读取工单，判断严重程度，归纳原因，再把结果发给负责人。模型、检索和工作流很快就能搭出一个 Demo。
但真正走进现场的时候，事情却往往会卡在另外一些地方。
四个系统里的“升级”不是同一个意思。客服看的是客户情绪，销售看续约风险，交付团队看故障影响；有些客户还有合同约定的特殊处理方式。Agent 发现异常以后，到底是只能提醒，还是可以修改工单状态？报告漏掉一条，谁应该负责发现？最后又应该由谁确认，这份结果已经可以拿去开管理层经营会议？
模型没有办法替企业回答这些问题。它们涉及口径、权限、责任和后果，而这些往往只存在于不同员工的经验里。
Human-in-the-loop
如果问题没有定义清楚，技术开发越快，返工可能也越快。
这也正是很多优秀工程师进入 FDE 现场后最容易不适应的地方。工程训练擅长把一个已经定义的问题解决得更可靠；客户现场却经常连问题本身都没有形成共识。
面对类似上面说到的那种工单总结需求，FDE 首先要做的事，是先拿到上周的五十条真实记录，跟着客服负责人逐条走一遍：为什么这条算升级工单，那条不算？遇到合同例外时谁作判断？报告出来以后，负责人接下来会做什么？
走完这一遍，团队可能发现真正需要的并不是“全自动周报”，而是一份可追溯的初稿：Agent 归集信息并标出依据，客服主管复核高风险项目，销售和交付只处理与自己有关的例外。等到口径稳定、遗漏可测、责任人明确，再考虑放开更多动作。
这并不是保守或投机取巧的做法。恰恰相反，它让自动化进入了真实流程，而不是停在演示里。
现场永远不会等到数据全部干净、流程完全统一、责任毫无争议以后才开始。FDE 的工作，是在不完整的条件下继续推进，同时不让技术掩盖尚未解决的组织问题。
有时要保留人工确认；有时只能让 Agent 起草；有时必须告诉客户，数据口径还没有对齐，现在不适合进入构建；有时则要把一个很吸引人的功能主动移出范围。判断的依据不是“AI 能不能做”，而是业务影响、技术可靠性和团队承接能力能否同时成立。
概括来说——一要永远考虑人的因素；二要敢于说 No。
信任也属于系统设计
很多 AI 系统在 Demo 时表现不错，进入日常工作后却没人敢依赖。原因未必是员工抗拒变化。使用者只是还不知道：这个结果依据什么？错了能否发现和修正？谁有权批准？系统不确定时会怎样？出了问题能不能退回原来的做法？
因此，来源、复核、失败提示、日志和回滚并非上线前才补的工程细节。它们决定了员工是否愿意使用，也决定了负责人是否敢为结果签字。
模型越强，原型越容易做，FDE 越需要把时间花在这些无法自动生成的判断上。责任、例外、信任和使用习惯不是“非技术阻碍”，它们本来就是系统的一部分。
如果准备启动一个 AI 场景，可以先不谈模型。跟着一位真实用户完整做一遍任务，只记录三件事：过程中作了哪些决定，遇到了哪些例外，最后由谁负责。
FDE 的现场工作，也往往就从这里开始。
如果这篇文章对您有所启发，欢迎点赞、关注并转发给更多朋友。更多内容，敬请访问 FFDE.ai ( www.ffde.com.cn )。