在给跟进工作流设计评测样本时，我专门放进了一类危险输入：通话里没有明确预算，但上下文足以诱导模型「顺手补全」一个看似合理的数字。

一个编造出来的预算往往语气自然、格式正确，甚至比真实信息更像一条合格的 CRM 记录。用户不会因为模型前九次答对，就原谅第十次把不存在的承诺写进客户档案。

第一层是生成约束。事实字段必须能在输入文本中找到依据；没有依据就留空或标记「待确认」，不能为了完整而补全。

第二层是结果校验。JSON Schema 只能保证输出结构正确，不能证明事实正确。金额、日期、人物与承诺等高风险字段必须附带原文片段。

第三层是交互与权限。AI 输出首先是一份草稿，用户确认后才变成正式记录。系统需要保留修改前后差异、确认人与操作时间。

当前阶段性评测中，无依据内容率由早期约 25% 降至约 8%，直接确认率由约 30% 提升至 50% 以上。可靠不是一个版本的属性，而是一套持续运行的机制。

当产品里出现线索、跟进和知识三个 AI 模块，最自然的冲动是把它们连接起来，再增加一个主管 Agent 负责分工。

假设任务严格串联三个步骤，每一步成功率都是 90%，在高度简化的假设下，端到端成功率可能只有 72.9%。这不是实测结果，只是说明局部错误可能沿链路传播。

线索判断偏了一点，跟进策略沿用偏差，知识检索又为错误方向找到了看似合理的材料。每个局部输出都能自圆其说，最终结果却离目标越来越远。

MVP 阶段，我让线索、跟进与知识三条工作流独立运行。每条链路都有明确输入、输出、质量指标与人工确认点。

主管 Agent 必须维护任务状态、检查中间结果、判断是否重试、汇总冲突、控制工具权限，并在无法继续时请求人工介入。

Multi-Agent 不是产品先进程度的证明。只有当动态协作比固定工作流产生可测量的增益，它才值得进入系统。

传统 CRM 擅长保存事实，却很少理解事实之间的关系。大模型让系统第一次有机会参与这种判断。

跟进摘要、字段提取与 FAQ 查询是高频任务。它们要求速度快、成本低、结构稳定。让模型为一句摘要展开长时间推理，通常没有产品价值。

流失风险分析、大客户策略与复杂商机判断则不同。它们调用频率低，但一次判断可能影响高价值机会，更高的延迟与推理成本可能是合理的。

快速路径处理高频、明确、低风险的任务；深度路径处理低频、高价值、需要多因素综合判断的任务。

面向销售展示的不应该是模型冗长的内部思考过程，而是一份可验证的决策摘要：结论、依据、不确定性和建议行动。

系统真正需要知道的是：什么事情值得深思，什么事情必须立即返回，什么结果必须保留证据并经过人工复核。