确定的步骤交给Workflow
Workflow适合处理顺序明确、权限固定、出错方式已知的任务。收到客户需求以后先识别车型，再检查配置约束，随后读取价格规则。每一步都能写清输入、输出和异常处理，流程就应该保持确定。
确定流程能给Agent划出边界。模型可以判断客户描述对应哪类需求，却不能绕过报价权限，也不能自己修改价格规则。企业系统里常见的可靠性，很多来自这些看起来并不聪明的限制。边界越清楚，错误越容易停在该停的位置。
需要判断的步骤交给Agent
Agent适合处理输入不完整、路径需要临时选择、工具需要组合调用的任务。客户只说了一句使用场景，系统要从产品知识、历史案例和配置规则里补齐信息，再决定下一步问什么。这里很难写成一串固定条件。
Agent获得的自由度越高，过程记录越重要。它调用了哪些工具，读取了哪些资料，为什么选择这条路径，人工改了哪一处，都应该留下轨迹。轨迹能帮助排查失败，也会成为后续Eval的材料。
Outcome后面还有Eval
一次任务完成以后，系统要知道结果是否合格。它得过验收。客服场景可以看问题有没有解决，报价场景可以检查配置、价格和审批是否一致，销售跟进还要看客户是否接受下一步沟通。Outcome必须对应可验证条件，不能只靠一句“任务完成”。
Eval把这些条件变成可重复检查的任务。失败案例进入评测集，人工修改说明系统缺了什么。缺资料就补Context，工具返回不稳就修Tool Routing，流程边界不清就改Workflow。系统每次更新以后重新跑Eval，改动才有证据。
人工治理属于流程
高风险决策、异常处理和最终责任仍由人承担。人工确认不应只在系统失败以后临时补救，它需要出现在流程设计里。金额超过什么范围需要审批，哪些客户承诺必须确认。跨团队读取数据还要有单独权限。
人工修改也有价值。用户把报价里的一个配置改掉，系统应记录修改原因。原因进入反馈以后，下一次相似任务可以提前检查。人参与得越清楚，系统越容易知道自己哪里做得不好。
AI销售工作台能证明到哪里
当前项目资料显示，AI销售工作台已经上线，功能流程包含车型查询、配置匹配、报价辅助和客户跟进。它可以用来展示Workflow、知识检索和Agent怎样进入销售流程。
现有资料没有提供转化率、报价准确率提升或节省工时等量化结果。页面会把它标为已上线的业务流程案例，不把尚未验证的效果写成成果。这条边界很重要。框架可以帮助理解系统，项目证据决定我们能把话说到哪里。
企业要建立经营闭环，可以先挑一个结果容易验收的业务切片。确定步骤进入Workflow，判断任务交给Agent，高风险节点由人处理，再用Outcome和Eval记录结果。跑过几轮以后，系统会逐渐知道该读什么、哪里要停、怎样改进。