智能体能连续干7天，企业该给它一张“记忆保质期表”

一个智能体替销售跟进线索、替采购核验供应商、替运营追踪异常时，最难的往往不是“能不能把任务跑久”，而是它第二天继续工作时，还该相信昨天的什么。客户偏好、已批准的报价、库存状态、例外处理意见——这些信息都很有用，也都可能过期。把它们一股脑塞进长期记忆，会让智能体看起来更连贯，却可能把过时判断带进下一次动作。

Google Cloud在7月29日更新Gemini Enterprise Agent Platform：其Agent Runtime支持连续运行最长7天；Agent Memory Bank可按结构化模式保留用户偏好、既往决定和账户历史。它还把智能体身份、网关、注册表、评估和可观测性放到同一组能力中。这组更新说明，长周期智能体正在从“多轮对话”进入“跨天执行”。但企业真正需要管理的，不是记忆容量，而是每一条记忆的有效期和使用资格。

会记住，不等于应该继续相信

短期上下文解决的是“这次对话说了什么”；业务记忆解决的是“这个客户通常怎样决策”。两者都不能自动替代事实核验。比如客户曾偏好邮件沟通，不代表当前投诉也可直接发出补偿；采购负责人上周批准过一家供应商，也不代表今天还能绕过预算、合规或库存变化。越是能跨天执行的智能体，越不能把历史信息当成持续有效的授权。

长周期智能体最危险的失误，不是“忘了”，而是把一条本该失效的记忆，当成仍然有效的行动依据。

因此，企业可以把“记住什么”从模型能力问题，改写成一张可管理的记忆保质期表。它不要求团队先搭建复杂平台，先为高价值任务建立五个字段即可：这条记忆来自哪份系统记录或人工确认；它适用于谁、哪类任务；何时自动失效；谁有权续期或撤销；过期或冲突时智能体应查询什么、升级给谁。

把记忆拆成三类，动作才不会越跑越偏

第一类是稳定偏好，例如常用语言、沟通渠道、已确认的角色关系。这类可以保留较久，但仍要允许用户和负责人修改。第二类是阶段事实，例如当前报价、项目状态、排期、库存和政策版本；它们必须带来源与时间戳，超过窗口就重新查询。第三类是行动授权，例如“可否发邮件、提交订单、写回CRM、触发退款”。它不该存成一条方便调用的偏好，而应在每次执行时重新匹配金额、对象、时间窗和审批条件。

这也是为什么Google把Agent Identity、Agent Gateway和Agent Registry一起强调：前者让动作能关联到具体运行身份，后者提供集中策略入口与组织级目录。对企业而言，目录不只是“我们有多少智能体”，还应回答“它保存哪些业务记忆、依据哪套规则、何时必须刷新”。只有把记忆和身份、权限、动作连起来，团队才看得懂一次自动决策凭什么发生。

先给一个跨天任务装上“刷新点”

不必等到智能体可以连续运行一周，才开始治理。选一个已有的跨天流程即可：例如销售跟进、内容审核或工单追踪。把开始、关键状态变化、发出外部动作之前设为刷新点。每到刷新点，智能体都要区分：哪些是可继续引用的稳定信息，哪些必须从源系统重新取数，哪些必须请人确认。这样做会稍微增加一次查询或升级，却能避免“昨天正确、今天照做”的隐性风险。

Google Cloud还提出在线评估与端到端可观测性：构建阶段迭代的指标，可以延续到生产环境。对长周期任务来说，最值得持续看的并非“记忆命中率”，而是过期记忆被拦下多少次、刷新后结论改变多少次、人工撤销集中在哪个字段。它们会告诉企业：问题在知识源、有效期设计、授权边界，还是流程本身。

STARBOX视角：让记忆成为可更新的业务资产

在STARBOX的组织—BOX—智能体三层架构里，组织层不只定义数据与审批边界，也要规定哪些记忆可长期保留、哪些必须按业务时点刷新；BOX层沉淀客户旅程、品牌口径、任务模板和经过验证的来源；智能体层则只在有效信息和当次授权内执行。DDABC闭环把人工纠正、过期拦截与冲突案例回写，让保质期表越用越贴近真实业务。

企业未来比的不会是谁的智能体“记得更多”，而是谁更清楚哪些信息该被记住、该在何时失效、失效后该如何安全地重新确认。能连续执行7天只是技术能力；让它在第7天仍基于正确事实做出正确动作，才是生产能力。