从注意力商品到注意力代理

零、引子

我过多的使用了手机，这是一个事实。过去一个月我统计了我的手机使用时长，日均是 4 小时 31 分钟，其中最长的每天使用 8 个小时，也就是说一天的白天时间几乎全部花费给了手机。平均每小时解锁 66 次手机，也就是几乎每一分钟我都会解锁一次手机，平均每小时会收到 34 条微信消息，也就是每两分钟我就会收到一个微信通知。在我删除小红书和知乎后，近七天在微信上花费的时间是 21 小时，而在删除微信之前在小红书上使用了近乎相同的时间。

这种频率很难仅用「自控力」解释：红点、角标和发现页的默认入口把「回一条消息」的初始意图引向朋友圈、视频号等附加内容，形成焦虑—查看—缓解的循环，事后又把失控归因于个人自律不足。需要退出的不是「手机」这个终端，而是这种由界面设计引导的注意力分配，本质是退出平台资本引导的注意力占有。

很早我就已经意识到了这个问题，不过我几乎是没有采取任何的行动。在一学期前，由于我发现我过多的使用了 B 站，我认为是 B 站使我浪费了大量时间在无用的视频上，因此我在手机上删除了 B 站。后续我又下载过一回，不过最后还是删除了。但是马上，我开始使用小红书、抖音等短视频平台，因此我随着删除了小红书、抖音还有知乎。但是微信上还是有短视频的功能，或者说现在的软件生态导致任何一款 APP 都会往里面塞入短视频这类功能，最后使我发现，只要我还在用手机以及借助手机参与现代生活，我就必然面临注意力被吸取的这个问题。

一、注意力商品化

互联网公司将个人的注意力作为生产材料引入增值链条，本质上是一种新的广告形态。由于互联网的广泛性和创作者的低门槛，使得任何形式的商品都被包装为一篇文章或一个视频被发布。而视频平台、创作者平台，还承担了作为「生活记录者」、「知识分享者」、「艺术创作者」等多种社会生活形态，不能纯粹采用「娱乐经济」、「商品」等形式一概而论。但随着这种新的形态的发展，互联网公司逐渐发展为「流量导向」的生存模式。流量使得视频和文章的记录属性、文学艺术属性等被最大程度弱化（因为流量的本质是所有人有限的注意力，而商品模式才具有相较于其他模式的竞争力）。相比于上个世纪，互联网时代使得注意力以极其廉价的方式被变卖（参考各平台自己推出的流量的价格），同样使得人的生产消费被空前地联结（电商、自媒体、新兴娱乐形式）。

这一系列的资本活动使得个人的注意力被各类软件打造为最容易被俘获的模式（流量推送模式、短视频模式以及创作者自发对其内容结构的调整）。在这套资本模式下，平台把用户的浏览、停留、互动打包为可售卖的注意力，使得个人的生活发展受到了极大的限制（被参与资本的增值而非个人的发展），而这种活动被包装为了一种现代的娱乐活动。平台对用户注意力的占有迫使用户参与无偿劳动，与广泛用户通过该类平台获取的利益不成比例（只要「大 V」以及平台自己打造的高流量账号享有流量，个人为了做一个有质量的流量账号付出的劳动不成正比）。

二、手机作为移动终端

手机有罪论在社会中被反复提及，似乎只要控制了对手机的使用，就可以避免被上述模式俘获。但这混淆了问题的产生的形式和问题产生的原因。现实来看，限制手机使用受到社会关系的约束。具体来说，现代社会的正常运行（而且是以当今如此高效率的运行）无法离开互联网和手机（从社会运行来讲），大部分社会组织都通过微信进行信息交换和文件、指示等的传达（从个人来讲）。手机作为通信终端，承担必要的生产要素。真正的矛盾在于平台对个人注意力的占有和个人发展的矛盾。平台把通信终端改造成注意力采集器，而个人难以真正区分手机作为移动通信终端和娱乐平台（由于这种娱乐平台已经被异化为注意力采集装置）。即便是微信这样的广泛使用的纯聊天平台，也推出了「看一看」、「公众号」、「订阅号」、「视频号」这样的形式来实施对用户注意力的俘获（虽然明面上打着知识分享、生活分享的名号）。

回看通信历史的发展，人与人的交流，从纸质书信开始，随着早期网络的发展，渐而演变出固定电话、传真、邮件、移动电话、短信等（随着基站、路由器、交换机等网络基础设施的建立）。这些早期人们青睐的通信模式采取 SIP、RTP、T.30、SMTP、SMS 等不同的协议栈（简洁、高效、用于特定场景），随着互联网的兴起，TCP/IP 协议逐步可以取代任意通信协议，使得用户通过 Web 服务可以方便地参与任意的通信以及使用商家提供的服务（只需要手机这一个终端）。这种便利性极大降低了个体与外界交互以及获取外界信息的门槛，但这种便利性被转化为了一种新的商品形式——正如我前面说的，注意力。因此如果我作为个人不把「作为移动终端」和「作为商品」的部分区别开，就无法逃脱被资本的俘获。

三、智能体时代：注意力代理

注意力必须参与社会生活，而个人的注意力在当下极易被俘获，两者之间存在难以调和的矛盾。而随着智能体技术的发展，这个矛盾将逐渐变得可调和。智能体技术通过大模型技术将注意力的成本极致压缩（按照市面大模型的 token 定价，按照不同任务和不同厂商可能价格不同）。2026 年 11 月 1 号，DeepSeek 公司发布了《Super-agent 设计探索：迈向更自主的 Agent 系统》的研究，探索了下一代智能体的形态。通过使用一个超级智能体来减缓用户管理多个异步会话的注意力分散提升项目开发效能，这引出我要讲的点——注意力代理。Herbert Simon——1978 年诺贝尔经济学奖得主——在 1971 年就写下过这样一句话：「信息的丰富会导致注意力的贫乏。」智能体时代将引入私人智能体解决这个问题，利用 AI 丰富的注意力（背后依靠的是算力基础设施）解决个人注意力的匮乏，类似于雇佣了一位管家或秘书。

通过在个人服务器部署一个超级智能体（后面称为 Steward，是我自己专用和正在设计的），以及部署各种业务钩子、流程、定时任务，维护个人的注意力窗口（被传统地理解为管理用户的行为模式和记忆，但这其实最根本是为了维护用户有限的注意力窗口），而超级智能体为了代理实施工作，同时也要管理下派智能体的有限的注意力窗口，而这和管理人的注意力窗口本质上是一码事（但是在实现方式、权限上等不同）。

3.1 Super-agent

DeepSeek 团队为 Super-agent 定义了下面四个基础特征：

连续：用户可以直接在 IM 聊天、GitHub 评论等熟悉的工作界面与它交互，感觉始终只存在一个 Agent，不需要去想「Session X 的上下文中是否有 Y 信息」。例如，用户先在 IM 上提出采用方案 A、随后在 GitHub Pull Request 评论里改为方案 B，它能理解并调整执行方向。
高效：交互响应迅速，同时能并行、高质量地完成多个复杂任务。无需等上一个命令或任务完成，就能接受下一条指令。
主动：无需等待用户逐条下达指令，能持续观察环境事件并主动推进值得处理的事项，不需要介入时则保持安静。
持久：始终在线、直接接入用户真实的工作环境，并在长期运行中遇到异常时自动恢复。

并认为「无论是面向个人的助手，还是面向软件开发等商业场景的 Agent，如果目标是构建一个持续在线、并发响应环境事件的系统，那么在底层就可能会采用相近的架构」。

下面我将基本复述 DeepSeek 团队提出的五个模块构成了支撑上述四个基础特征的基本框架：通过双层架构兼顾连续交互与高效并发，通过事件驱动实现主动响应，通过面向人的交互在交互过程中同时做到连续与高效，并通过计算、状态与环境的分离及 Watchdog 实现跨设备的持久在线与异常自愈。

3.2 双层架构

要同时实现跨信道的连续交互与多任务的高效并发，系统在底层会话组织上面临连续性与吞吐量之间的根本权衡。

如果每条事件都交给同一个 Session 处理，虽然上下文最连续，但受限于单个 ReAct Loop 串行执行的速度上限，任务完成耗时长、吞吐低，且多任务的中间细节混杂在一起也会影响完成效果。反过来，如果每条事件都直接新开独立的 Session 去处理，虽然并发吞吐最高，但一旦任务之间并不完全独立，缺少全局上下文会让各个 Session 的结果彼此割裂，同时多个 Session 各自向用户响应也会造成交互混乱。

为了兼顾连续性与吞吐量，我们可以将「维护全局连续性」与「高并发执行」拆分到两个不同的层级中：由常驻的 Router 层统一承接人类交互与全局协调，由上下文隔离的 Worker 层并发执行具体任务。

Router 层是常驻的全局路由层，负责承接所有入口的人类交互。所有跨任务的信息与决策都在 Router 层中汇总，由它充当全局的序点（Sequence Point）、协调点和记忆。在内部实现上，Router 层同样不必局限于单个 Session，甚至部分逻辑未必需要调用 LLM。这里直接选择单个常驻 LLM Session 作为 Router 层的核心实现。当规模进一步扩大、单个会话确实不足以承载时，Router 层内部也可以设计为多层过滤结构，或水平切分（Sharding）为多个会话。切分粒度越细，Router 层的并发吞吐量就越高，但分片之间的记忆与上下文连续性就会越低。在全局记忆问题被解决之前，这一权衡始终存在。

Worker 层由负责具体执行的会话组成，各个 Worker 彼此上下文隔离，挂载完整的执行工具，在独立上下文中专注完成单一任务。由于 Worker Session 直接决定任务结果与代码质量，通常需要配置能力最强的模型。Worker 不会直接与人类交互，其推理过程和工具调用不会直接输出到外部信道，而是向 Router 层汇报状态、由 Router 层统一向用户回复，从而在保障并发度与交付质量的同时避免多个会话各自回复带来的混乱。

3.3 事件驱动

在 Super-agent 中，群聊消息、邮件与日程提醒、代码审查评论、CI 运行结果等环境事件被称为 Trigger。通过监听并响应 Trigger，Agent 不必再像单 Session 模式下那样，等人类下达指令才被动执行一次。

围绕一条环境事件从进入到处理的生命周期，下文将依次讨论四个递进的问题：如何通过程序与模型结合的两级策略过滤大量噪音、如何通过订阅与直通机制将事件路由给 Worker、如何利用 Inline & Spill 与链式召回向模型高密度地注入与按需召回上下文，以及如何利用投机执行根据环境信号在后台提前行动。

事件进入系统后的第一步是过滤，目标是在调用大模型之前先用确定性策略筛除噪音，只将需要语义理解的候选事件交给模型判断。我们采用程序策略与大模型相结合的两级过滤机制：

程序层策略（作为 Fast Path）：针对事件来源、群组范围、用户或机器人白名单等确定性条件，直接通过代码进行快速准入检查，例如对不同来源分别设置「仅响应明确请求」「作为候选事件」或「直接忽略」，在调用模型前滤除大部分无关消息。
语义层策略（作为 Slow Path）：通过程序层准入的候选事件交给 LLM，由它根据用提示词编写的策略和上下文判断是否需要行动。语义层同时作为面向人类的自然语言扩展点，方便随时通过提示词开关或新增策略。

全局 Router 层仅负责新任务的冷启动与跨任务协调，而已确定归属关系的后续事件由程序直接发往对应的 Worker 会话，无需经由 Router 层转发。在实际工作流中，同一个 GitHub Pull Request、同一个 IM 话题或同一封往来邮件串下的连续事件构成一条事件流，即 Thread。（在 Steward 的实现中，更关注私人话题工作话题等，因此在给用户的交互界面中，可以让用户自定义话题，而 Router 处理话题到具体 Worker 的订阅关系）

在 Router 层根据某个 Thread 的初始事件创建 Worker Session 后，该 Worker 会直接订阅对应的 Thread，从而将事件路由分为两条路径：

已订阅（Fast Path）：同一 Thread 下的后续事件由程序直通已订阅的 Worker，无需 Router 层再次调用工具转发。若新事件超出了当前任务的范围，Worker 也可取消订阅或交回 Router 层重新分派。
未订阅（Slow Path）：Router 层仍可观测所有事件以掌握全局状态，但仅负责判断和分派尚未被订阅的新事件。

此外，Thread 与 Worker 之间的订阅是多对多的关系。一个 Worker 可以同时订阅多个相关的 Thread，同一个 Thread 也可以被多个 Worker 订阅。当多个 Worker 在同一个工作环境或讨论中发生交集时，该 Thread 下的新事件会同时直通给所有订阅它的 Worker，使它们无需点对点通信，也有机会获知彼此的操作并自行解决冲突。而在输出侧，Worker 仍将关键结论汇报给 Router 层，由 Router 层统一向用户回复并同步全局记忆。

在事件经过过滤与路由、进入目标 Session 后，下一个问题是应当向模型的上下文窗口注入多少信息。由于系统输入从有限的人类提示词转向了环境持续产生的半结构化事件，工具调用与事件注入的结构设计变得更加重要。注入过多会挤占窗口、稀释模型注意力，注入过少又会迫使模型反复调用工具读取，增加执行步数。浪费上下文窗口，就是浪费模型的智能。为此，我们可以将有限的上下文窗口当作 Cache 来管理。借用编译优化与计算机系统中的概念，上下文注入的设计可以归纳为两个基本操作。Inline 是指将近期很可能用到的信息直接内联进当前上下文窗口，以省去额外的工具调用往返。Spill 则是指将超出窗口预算或低频使用的完整信息留在上下文窗口之外，仅在窗口内保留引用或摘要，供模型按需读取。结合计算机系统设计中经典的局部性（Locality）思想，我们可以用 Inline & Spill 对事件注入和工具调用逐步优化：

从最少信息开始：最初只提供当前对象的 ID 和内容摘要。
利用局部性逐步 Inline 关联信息：将近期很可能用到的信息 Inline 到上下文中，先附上紧密关联对象的 ID，再附带时空相邻的内容，例如内容前 50 字、IM 消息的前后相邻消息与所回复的消息，或代码评论所在评审讨论中的相邻评论。
超出上限则 Spill：对无法全部 Inline 的长内容设定较小的长度上限，将超出部分 Spill 到窗口之外。一种简单直接的做法是截断超出部分并保留续读入口，模型需要完整内容时再调用工具读取。

此外，在大量后续事件直通 Worker、且系统在长期运行中累积了许多历史任务后，Router 层既不能把所有任务的全量历史都放入自己的上下文窗口，又需要在用户跨信道提起某个旧任务时找回上下文。将 Inline & Spill 一致地应用到系统中的各类对象后，就得到了一种按需展开的多跳检索机制，即链式召回（Chain of Recall）。这种链式召回过程缓解了 Router 层在长程中丢失先前信息的问题。

具体来说，系统为 Trigger、Thread 和 Worker Session 等对象赋予唯一 ID，并在注入时内联紧密关联对象的 ID，使这些对象在底层构成一张引用图。由于每一次调用工具召回的对象本身同样遵循 Inline & Spill，其返回结果中又会内联下一跳关联对象的摘要与 ID，模型便可以从当前事件出发，顺着引用关系逐步按需召回上下文。例如从一条当前消息读取所在 Thread，再从 Thread 内联的 ID 追踪到相关的 Worker Session，进而找到该 Worker 关联的另一个代码评审 Thread。或者对于私人场景，这个引用图串联了用户的各种问题和信息。

借鉴计算机系统中的投机执行（Speculative Execution）思想，Agent 可以在还不确定结果是否会被采用时，根据环境信号在后台提前尝试，通过消耗额外的后台算力来减少人类的等待与介入成本。结果有价值就交付，没有价值就丢弃。在个人助手场景下，当收到一封会议邀约邮件或待办消息时，Agent 可以先在后台核对日程冲突、搜集相关背景资料并备好回复草稿，待用户过目后即可直接确认发出。

3.4 面向人的交互

要在实际的人机交互体验中同时做到连续与高效，还需要在交互方式与交互渠道上解决两个问题：一是如何通过异步 ReAct Loop 消除后台耗时操作对前台对话的阻塞，使会话无需等待上一个命令或任务完成即可随时接受新指令；二是当交互发生在用户熟悉的不同工作信道时，如何让系统的输出方式匹配对应信道的带宽与人的使用习惯。在本 Steward 项目中，还需要向用户提供一个完整的前端交互系统。

在经典的 ReAct Loop 中，模型发起一次同步的 run() 工具调用后，循环会阻塞，直到工具执行完毕并返回最终结果，在此期间会话无法响应任何新的用户输入。要消除这一阻塞，需要将对话从一问一答的半双工模式转变为全双工模式。为此，我们将耗时的命令与子任务工具调用改为异步的 start() 和 stop()，构成异步 ReAct Loop。模型调用 start() 后立即收到「已启动（Started）」的返回，循环不再等待该工具；在后台工具执行完成后，系统再将最终结果作为一条新的事件消息投递进会话；同时，模型也可以根据上下文调用 stop() 主动终止执行时间过长的后台命令。由此，前台对话响应与后台任务执行得以解耦，Agent 在后台运行耗时任务的同时也能响应人类输入。新输入在当前推理步结束后即被处理，不必等待后台工具完成。

不同工作信道具有不同的信息密度与交互习惯，系统的输出需要与之匹配。如果将面向单人终端的交互方式直接搬入群聊，把冗长的推理过程与密集的工具调用原样输出，在多人协作中极易造成信息过载。在 Super-agent 中，双层架构已经解决了其中一部分问题：具体任务中冗长的推理过程和密集的工具调用都被隔离在 Worker Session 内部，不会直接输出到外部信道，而由 Router 层统一负责对外交互。在此基础上，系统还需要接入用户日常使用的各类工作环境，并通过提示词针对不同信道定制交互规范：

IM 等即时通讯信道：侧重低打扰的轻量沟通，像人类同事一样只在需要决策或验收时发送通知，只问直接问题、给简短结论。我们验证过的一条简单有效的硬性规定是单次回复不超过 100 词。
GitHub、邮件与文档等异步信道：侧重结构化、高信息密度的异步交付，例如在创建或更新 Pull Request 时按项目规范撰写完整的问题背景、改动说明与验证结果，或在个人助手场景下直接起草结构化的邮件与文档摘要。

在 Steward 项目中，需要通过前端可视化地呈现用户的注意力，让用户能够快速掌握当前生活工作中的各种事件和任务，读取自己的计划安排和进度，审阅各种事件。

3.5 计算、状态与环境的分离

现有的本地 Agent 默认将推进 Agent Loop 的计算、需要持久保存的会话状态，以及代码仓库与本地工具链等执行环境绑定在同一台设备上。一旦设备休眠或离线，Agent 就会停止运行，且无法访问其他设备上的环境。要让 Super-agent 做到持久在线并灵活接入各类真实工作环境，我们可以借鉴计算机系统中存算分离（Compute-Storage Separation）的思想，分两步解耦这三者的绑定：第一步先将推进 Agent Loop 的计算与持久化的会话状态分离，使 Agent 摆脱单机生命周期限制、实现云端持久在线；第二步再将云端的 Agent Loop 与重状态的执行环境解耦，让真实工作环境留在原地并支持跨设备访问。

推进 Agent Loop 的计算可以做成无状态的，需要持久保存的是会话状态。因此，第一层解耦是将推进 Agent Loop 的计算放入云端无状态的弹性计算容器中（目前 Steward 使用的就是阿里云提供的云服务器），而将 Session 等持久化状态存入数据库。无状态计算容器可以水平扩展、重启或替换，会话与任务的连续性则由持久化存储保障，从而使 Agent 摆脱单台本地设备的生命周期限制，实现云端持久在线。

第二层解耦是让 Agent Loop 在云端运行，而让重状态的执行环境留在原地，仅在端侧部署一个不保存会话状态的轻量 daemon，它只负责执行命令与返回结果，相当于把执行环境留在云端之外，由 Agent 按需读取其中的上下文。这一思路与 Anthropic 提出的「脑手分离」（Decoupling the brain from the hands）一致，同样让 harness 保持无状态，把会话日志存放在 harness 之外，并通过统一接口按需接入执行环境。两者的区别在于场景。那篇文章描述的是托管服务，主要讨论按需创建的沙箱和客户 VPC 内的资源；这里首先要接入的是用户日常使用、可能间歇在线的个人机器，上面有未提交的修改和本地凭据。因此，这种设计既支持 BYOM（Bring Your Own Machine），即把用户日常使用的开发机或个人电脑接入云端 Agent，也支持接入云端托管机器或按需创建的计算环境。

由此，一个 Agent 不再受限于单台机器，而是可以在不同的执行设备之间切换，根据任务需要选择环境来执行命令并获取环境中的上下文。它甚至能够支持间歇在线的设备，例如在用户的某台个人设备重新上线后，再由云端 Agent 自动触发并完成需要在该设备上执行的任务。

3.6 Watchdog

要实现持久在线，除了存算分离，还需要让系统在长期运行中能从异常中自动恢复。持久在线的分布式系统很难仅靠主系统内部逻辑保证长期可靠运行，需要在主系统之外引入独立的外部控制回路，即 Control Loop。

同时，在 Agent 系统中，仅靠传统的进程存活探测或监控脚本是不够的，因为许多异常并非进程崩溃，而是模型在执行中陷入无效循环或偏离目标。因此，长期运行的 Agent 系统不仅需要监控基础设施的存活，还需要监控任务本身的进展。

DeepSeek 团队在主系统外部配置了一个独立的 Watchdog Session，用定时消息驱动它，构成外部的 Control Loop。Watchdog 除了处理接口报错、状态恢复失败等基础设施故障，还会由模型判断各个 Worker 是否有实质进展、方向是否偏离整体目标。发现异常时及时介入修复，遇到外部偶发故障则持续复查直至恢复正常。

由于 Watchdog 本身也是一个具备完整工具能力的 Agent Session，维护者可以用自然语言向它询问故障原因，也可以让它在线修正主系统的行为，例如增删提示词、调整触发规则。

四、个人方案：分层退出

依托智能体时代的超级智能体技术，代理大量注意力，个人的生活学习得以从中抽离。为了兼顾必要的社交和工作消息，将手机暴露为纯粹的移动通信和交互终端，我采取了下面的「三层暴露面」组织：

界面层退出：关闭朋友圈入口、视频号、公众号非必要关注；微信只作为消息收件箱。微信作静默处理，非必要不查看微信，或者只在特定时间集中查看（例如晚 7 点到 8 点）。卸载小红书、知乎、B 站、抖音等一切自媒体账号，理解主动分享与内容传播的心理学机制，并采用现实生活的方式代替。
消息层降级：用 MacroDroid 获取微信消息，服务器端智能体做摘要、分类、待办提取，再推送到个人终端。
关系层替代：对家人、密友、紧密合作者建立「急事电话、非急事邮件/短信」的惯例，并用响应可靠性积累信用。对愿意了解与合作的人开放必要的社交账号，但不使用，并将流量引渡到主站 hi55555.cn 中。

五、总结

我尝试做的，是把微信从内容消费的场所降级为消息收件箱，用智能体承担持续待命和初步筛选的成本，再在人际关系里慢慢建立电话、邮件、短信这些替代通道。这套做法能收回一部分注意力分配权，但它有一个清楚的上限：消息通道本身仍然绑在微信上，学校、班级和项目组的通知不会因为我的偏好而改道。界面层的退出可以很快完成，关系层的替代却需要周围人的配合，也需要我用可靠的响应去换信用。所以这更像一次有限度的实验，检验个人能在制度性信息流面前把边界划到什么位置，以及划出这条边界要付出多少协调成本。