Agent 能继续运行，客户事实能跟着继续吗？

OpenAI 在 2026 年 9 月 10 日发布 Agents API 公测，强调长时间运行的 Agent 需要上下文管理、工具调用和中间结果保存。其 API 更新记录也说明了 durable sessions、恢复和 MCP 连接。对于销售团队，这让“让 AI 花一段时间准备一份客户方案”更加现实。

但任务会恢复，不代表客户事实会自动正确。销售 Agent 可以记住上一轮操作，却仍可能把另一个客户的价格、几个月前的交期或未经确认的产品适配放进新提案。长任务扩大了工作范围，也扩大了错误被传播的范围。

把两种“记忆”分开

任务记忆回答“Agent 做到哪一步”：已读哪些文件、下一步是什么、哪些动作失败，是否能从检查点继续。销售记忆回答“这个客户和产品究竟是什么”：客户主体、联系人、历史活动、产品事实、来源及有效期。前者可以由 Agent 运行框架管理；后者必须有独立、可审计的数据结构。

例如，「示例客户 A 公司」要求下周演示。Agent 暂停前已准备产品资料；恢复后若只记得“演示需求”，却不记得该需求来自哪封邮件、适用于哪个分公司、哪些规格还待工程确认，那么流畅续跑反而会生成一封过度承诺的邮件。

建议每条被 Agent 复用的销售事实至少有六个字段：主体、信息类型、原始来源、发生时间、确认状态、可见范围。没有这些字段，长上下文只是更长的聊天记录。

长任务的四个检查点

1. 开始前：锁定对象

先用公司名加邮箱域名、电话或其他硬标识核对客户，再读取该客户的画像与近期活动。产品词或国家相似不等于同一客户。若身份不唯一，任务可继续做公开资料研究，但客户专属写入必须停下。

2. 研究中：保存来源和未决问题

每个重要结论都应能返回原邮件、会议记录、产品文档或网页。Agent 的摘要可作为工作稿，不能自行成为来源。对“适用型号”“价格有效期”“交付承诺”等高风险项，明确标成已确认或待确认。

3. 恢复时：重验会变化的事实

恢复运行时不应把旧 checkpoint 当成实时世界。客户是否已经回复、报价是否更新、产品配置是否改变，都值得重新读取。可以复用稳定背景；业务状态、负责人和下一步行动则要按最新记录校对。

4. 写回后：读回目标对象

一封邮件已发送、一场会议已完成，应进入带时间的 activity；稳定公司事实才进入 profile。写入后按对象 ID 读回，核对客户、正文和时间。如果读回失败，保留写入 ID 进行诊断，避免重复创建。

KnowSales 适合承担哪一层

KnowSales 的客户画像、activity、产品知识及 MCP 工具，为不同 AI 工作入口提供同一套销售上下文。来源引用帮助使用者检查答案依据；写入仍需要权限、目标确认和读回。想了解这一分层，可以先读为什么销售 AI 需要独立客户记忆层和MCP 长期记忆架构。

KnowSales 的持久任务底座目前处于 Production Owner 灰度，最终 L1 验收尚未完成。因此，本文讨论的“长任务恢复”是选择销售 Agent 的架构要求，不表示该能力已经对所有 KnowSales 用户开放。

如何先做一个低风险试验

选一个已明确身份的客户，让 Agent 只读地完成“核对近三次活动、列出仍待确认的问题、给出会前摘要”。人工对照原始记录，检查它是否引用对了客户、是否区分了历史承诺和当前状态。只有这一层稳定，再扩大到草拟回复；写回应作为单独的确认步骤。

常见问题

Agents API 本身会保存 CRM 客户档案吗？

它提供 Agent 运行与会话能力；客户档案的质量、权限和生命周期仍由业务系统设计。两种记忆不能互相替代。

上下文窗口更大，是否就不需要销售记忆层？

更大的窗口能装更多材料，但不会自动判定哪个客户、哪条事实最新，也不会自动建立写回审计。

任务恢复后最应该重新检查什么？

客户新回复、报价和交期、负责人、活动状态，以及任何影响对外承诺的事实。

先从什么任务开始验证？

从只读客户摘要开始。可用销售 Agent 的业务验收清单检查身份、来源和权限，再逐步增加动作。

要检验你现有 AI 工作入口能否读到正确的客户上下文，可先了解 KnowSales 连接方式，从只读问题开始。