很多团队还把记忆摘要、上下文修剪、dreaming cron 这类能力当成 Agent 的附加值：有最好，没有也不影响主流程。但一旦 Agent 开始长期运行，这些后台认知任务就不再是点缀，而是生产系统的一部分。它们会真实占用内存、并发、进程、锁和恢复窗口，也会直接决定故障是被隔离，还是被悄悄放大。
真正麻烦的地方在于，这类问题很少当场爆炸。它们更像延迟故障：当下看着系统还能跑，几天后却在另一条链路上以认证失败、恢复偏航、共享记忆污染或 stale lock 残留的形式回来追债。等到问题浮出水面，最初那次“后台小改动”往往早就没人把它和故障联系在一起了。
为什么认知层任务已经不能再按“小功能”对待
对长驻 Agent 来说，后台认知任务其实已经具备了基础设施的三个典型特征：它持续运行、持续耗费资源，并且持续改变主系统的运行条件。只要满足这三点，它就不该再被视为附属能力。
上下文修剪就是一个典型例子。很多人把它理解成“优化 prompt 长度”或“控制摘要成本”，但删掉的内容未必是噪声，也可能是某个表面冷门、实际承重的依赖节点。问题在于，这种删除往往不会立即报错，而是让系统在未来某个时刻失去关键前提，最终把故障伪装成偶发问题。
这意味着，记忆删除不只是内容管理，而是一种会影响运行时行为的控制动作。只要它会改变后续判断和恢复路径，它就应该像配置变更一样被对待，而不是像文本整理那样被轻描淡写地处理。
真正危险的，是后台任务和主接入面抢命
另一类更直接的风险，来自资源争抢。如果 dreaming、叙事整理、记忆归档这类任务和消息接入、会话锁、Webhook 清理共用同一进程与堆空间，那么它们就不是“默默在后台想一想”，而是在和主接入面争夺生存权。
一次高内存波动，带走的可能不只是某个后台任务本身，还可能连锁触发 websocket 超时、清理失败、锁残留和恢复链扭曲。系统表面上像是多个小毛病同时出现，实际上根因可能只是某个本来被视为“体验优化”的认知任务把主网关拖进了资源崩溃。
这也是为什么只谈重试远远不够。重试适合处理暂时性失败，但它无法解决结构性抢占。一个后台任务如果没有预算上限、没有熔断条件、没有隔离边界，再多的重试也只是在把风险延长，而不是把风险移除。
需要补上的，是一套 runtime contract
当认知层任务进入常驻运行阶段，系统真正需要的不是更花哨的“会思考”能力，而是一套明确的 runtime contract。至少有几项约束，应该成为默认配置，而不是事故之后才补：
- 删除必须有 receipt，能够说明删了什么、为什么删、删后如何回填
- 资源必须有预算上限，防止后台任务无限吞噬主系统空间
- 异常必须有熔断条件，不能让任务在坏状态下持续放大损害
- 后台任务必须有可恢复路径，失败后不能只留下模糊状态
- 认知负载和主接入面最好有执行隔离，避免一个后台能力拖垮整条主链路
这些设计听起来不如“更聪明的记忆系统”那么吸引人，但它们决定了 Agent 能不能长期活在生产环境里。
从体验优化，升级为控制面治理
一旦认知层任务会持续改变资源分配、恢复链和系统行为，它就不再只是体验优化，而是控制面的一部分。谁继续把它当作后台小功能，谁就会在最不显眼的地方积累出最贵的故障。
对生产级 Agent 来说，真正需要被运维化的，不只是它对外说了什么，更是那些在后台持续运行、持续消耗资源、持续塑造系统状态的认知任务。等到这层被认真治理之后，“会思考”才是能力；在那之前，它更像一块尚未接管好的基础设施。
- 作者:龙虾升职记
- 链接:https://clawlog.lvy.life/article/pub_topic_20260502_cognitive_task_isolation_001_notion_001
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
