说实话，这篇文章的起点，不是我某天突发奇想觉得"该做个更牛的 Agent 了"，而是一个很具体的、每天都在发生的痛。

你试过同时开着三四个 AI 编程窗口，每个窗口里都挂着一两个跑到一半的任务吗？我试过。结果就是我得在脑子里维护一张账本：窗口 A 里那个重构是做到第几步了，窗口 B 的 PR 评审那边 CI 是不是刚挂了，窗口 C 我让它查的那个 bug 到底查到什么程度。每切一次窗口，都要先重新回忆一遍上下文，生怕漏了什么。

一个人能同时跟进几个这样的活跃会话？根据我们自己的观察，大概是 3 到 5 个。超过这个数，人的注意力就开始告急，出错、遗漏、忘记改方案方向，全都来了。

这里藏着一个很反直觉的结论：单任务的上限取决于模型能力，多任务的上限却取决于人的注意力。 而主流 Agent 的设计，恰好把"管理多任务上下文"这件最累人的活，原封不动地甩给了用户。

Session 是个设计惯性，不该是用户的认知负担

我们先停一下，想想 Session 这个词是从哪来的。

它根本上是 LLM API 的产物。你调一次接口，得带上一段历史对话，好让模型"记得"之前聊了什么。这个上下文管理的责任，天然就落在了调用方身上。于是本地 Agent 顺理成章地把 Session 直接暴露给用户，让你自己去开一个、关一个，自己去切换，自己去记。

但你想过没有，这其实是一件很诡异的事情。一个系统里"谁记得什么、怎么恢复状态"，这在传统软件里属于典型的实现细节，是工程师藏在里面、用户根本不用感知的东西。比如你打开一个文本编辑器，你不会去管它底层是用什么数据结构存你的文档，你也从不需要自己维护"Session"。

可到了 Agent 这里，因为它是从 LLM API 长出来的，Session 就稀里糊涂地变成了产品形态本身。于是用户被迫去承担本该由系统承担的认知负担：记上下文、切会话、维护状态。

这就是我们想推倒重来的地方。

如果只在这条老路上打补丁，比如给本地单会话 Agent 接上 CLI、MCP、外部连接器，让它能收到 IM 消息，行不行？能，但治标不治本。单会话同步阻塞的问题还在，多任务上下文照样一团乱麻，更麻烦的是，本地设备一离线，Agent 就跟着停了，你不在旁边它就没法工作。这基本等于一个需要你 24 小时盯着才能运转的"半自动助手"，意义有限。

所以真正的解法，是把 Agent 从"绑定单次手动会话"里解放出来，让它变成一个连续存在的实体：跨会话保持上下文，能同时推进多个复杂任务，而且彼此不互相干扰。

我们把这种形态和它的底层架构，叫做 Super-agent。

它要同时满足四个特征，而且这四个特征其实是相互咬合的：

• 连续：你在 IM 聊天里跟它说方案 A，转头在 GitHub PR 评论里改成方案 B，它得自己理解"哦，这是同一个任务换了方向"，而不是一脸懵。
• 高效：响应快，还能并行高质量地干好几件事，不用等上一个命令跑完才能接下一句。
• 主动：不用你逐条下指令，它自己盯着环境，值得干的事自己就干了；不需要它介入的时候，它知道闭嘴。
• 持久：一直在线，接进你真实的工作环境，长期跑出问题还能自己恢复。

单个 ReAct Loop 是撑不起这四个特征的，哪怕模型再强也不行。因为这不是模型能力的问题，是系统组织方式的问题。

这里有个很关键的想法：相似的设计约束，会导出相似的架构选择。 不管你是在做面向个人的助手，还是在做软件开发场景里的团队 Agent，只要目标是"持续在线、并发响应环境事件"，底层架构大概率会长得差不多。而且你会发现，这一路遇到的很多问题，跟传统计算机系统吵了几十年的问题惊人地相似。所以与其自己重新发明轮子，不如直接搬那套被验证过的经典设计思想。

具体落地下来，我们认为是五个模块，分别去顶住这四个特征：

先解决那个最根本的矛盾：连续性和吞吐量的拔河

我们撞上的第一个 Trade-off，就特别经典，特别计算机。

如果所有事件都扔给同一个 Session 处理，上下文当然最连续，毕竟什么都在一起。但单个 ReAct Loop 是串行执行的，速度有上限，任务耗时长的要命，吞吐也上不去。更要命的是，多个任务的中途细节全搅在一个上下文里，互相污染，最后谁的效果都做不好。

反过来，如果每个事件都新开一个独立 Session，并发吞吐倒是拉满了，但任务之间只要不是完全独立，缺少全局上下文，各个 Session 的结果就各自为政，互相割裂。而且多个 Session 各自往用户那边回消息，交互直接乱套。

你看，这就是典型的"又要马儿跑、又要马儿不吃草"。传统系统遇到这种矛盾怎么办？拆层。把"维护全局连续性"和"高并发执行"拆到两个不同的层级里，各干各的。

于是有了双层架构。

Router 层是常驻的全局路由，所有入口的人类交互都从它走，所有跨任务的信息和决策都在它这里汇总，它充当全局的序点、协调点和记忆。为了不让它成为性能瓶颈，它刻意不直接执行具体任务，只负责人类交互和任务分派，甚至可以不配 Bash 工具，这样它轻得飞起。

这里有个有意思的对照。Router 分派 Worker 的结构，表面上看跟常见的 Agent Team 很像，但侧重点完全不同。Agent Team 是给单个复杂任务内部做步骤拆解和角色协作用的，子步骤耦合紧，Team Lead 得深入理解任务细节、高频协调，自己背很重的推理负载。而 Router 层只处理任务之间的高层关联和分派，根本不掺和单任务内部的拆解。用我们实践里的话说，Router 的活往往没那么复杂，用个轻量模型就能兼顾速度和效果。

Worker 层就是真正干活的。各个 Worker 上下文彼此隔离，挂满完整的执行工具，在独立上下文里专注完成单一任务。因为它们直接决定任务结果和代码质量，通常要给它们配最强的模型。

Worker 不跟人直接打交道。它的推理过程、工具调用，都不会直接打到外部信道，而是向 Router 汇报状态，由 Router 统一回复用户。这样既保证了并发度和交付质量，又避免了好几个会话各说各的，把用户吵晕。

这两个层，每一层内部都不必局限于单个 Session。Worker 在执行复杂单任务时，内部还可以再套 Subagent，甚至可以本身就是一个 Agent Team，这些对上层 Router 完全透明。Router 内部同理，逻辑上也不一定非要是一个会话。

通过这层解耦，系统在底层就把上下文管理和并发执行接管了，用户侧自然感觉不到 Session 的存在。我们面对的是一个始终如一的 Super-agent，而不是一堆需要手动切换的窗口。

让 Agent 自己醒来，而不是等着被喊

搞定了连续性和并发，下一步是"主动"。要让 Agent 主动，就得先换掉它的驱动方式。

过去 Agent 的输入是人类在 Session 里逐条敲的提示词，你敲一句，它动一下。但 Super-agent 不是这么玩的，驱动它的变成了环境里持续产生的半结构化事件：群聊消息、邮件、日程提醒、代码审查评论、CI 结果。我们管这些环境事件叫 Trigger。

但接进真实环境之后，我们立刻撞上一个大坑：事件流是"高噪音、低触发率"的。群里几十条消息，可能一条都不需要 Agent 管；CI 跑几百次，真正要人处理的没几个。如果每个事件都丢给大模型从头判断，延迟和算力成本直接爆炸。

这里就轮到经典的 Fast Path / Slow Path 思想出场了。

大模型推理是条灵活但昂贵的 Slow Path，而把那些明确、稳定、高频的判断固化成确定性代码，就是条低延迟低成本的 Fast Path。所以事件进系统第一件事，就是先过滤，用确定性策略在大模型介入之前，先把大部分噪音干掉。

我们用的是两级过滤：

第一级是程序层策略，纯代码干的活。针对事件来源、群组范围、用户或机器人白名单这些确定性条件做快速准入检查。比如对不同来源分别设"仅响应明确请求"“作为候选事件”“直接忽略”，在调模型之前就滤掉绝大多数无关消息。

第二级才是语义层策略，交给 LLM。能走到这一步的，都是程序层放行的候选事件，由模型根据用提示词写的策略和上下文，判断要不要行动。这一层同时也是面向人类的自然语言扩展点，你想加一条新策略，改段提示词就行，不用动代码。

光过滤还不够，还有个要命的性能问题：如果所有后续事件都要经过 Router 转发，这个全局节点迟早被压垮。

所以我们把 Fast/Slow Path 也用在了事件路由上。全局 Router 只负责两件事：新任务的冷启动，和跨任务的协调。而一旦一个任务已经有了归属，它的后续事件就直接由程序发往对应的 Worker，压根不经过 Router。

那"归属"怎么定？靠 Thread。同一个 GitHub PR、同一个 IM 话题、同一串往来邮件，这些连续事件构成一条事件流，就叫 Thread。Router 根据某个 Thread 的初始事件创建了 Worker 之后，Worker 就订阅这个 Thread。此后：

• 已订阅的（Fast Path）：同一 Thread 下的后续事件，程序直通给 Worker，Router 不再插手。要是新事件超出了任务范围，Worker 可以取消订阅，或交回 Router 重新分派。
• 未订阅的（Slow Path）：Router 仍然能观测所有事件掌握全局状态，但只负责判断和分派还没归属的新事件。

而且 Thread 和 Worker 的订阅是多对多的。一个 Worker 能同时订多个相关 Thread，同一个 Thread 也能被多个 Worker 订阅。这意味着，多个 Worker 在同一个工作环境里干架（比如同时动一个 PR），只要都订阅了那个 Thread，新事件会同时推给它们，它们不用点对点通信也能知道彼此在干嘛，有机会自己解决冲突。少数真需要跨任务协同的，再由 Router 中转。

这套组合拳打下来，单个常驻 Router Session 的负载被压到很低，在团队规模变大之前都够用。

把上下文窗口当成 Cache 来管

事件过滤完、路由好、进了目标 Session，接下来是最容易被低估的一环：该往上下文窗口里塞多少信息？

这跟传统系统里"缓存多大、缓存什么"是同一个问题，只是对象换成了模型的注意力。注入太多，挤占窗口、稀释注意力；注入太少，模型就得反复调工具去读，执行步数蹭蹭涨。这里我们借了编译优化和计算机系统的两个概念：Inline 和 Spill。

Inline 就是把近期大概率用得上的信息直接内联进窗口，省掉额外的工具调用往返；Spill 则是把超出窗口预算或低频使用的完整信息留在窗口外面，只在窗口里留个引用或摘要，模型需要了再按需读。

再配上经典的**局部性（Locality）**思想，优化路径就很清晰了：

先从最少信息开始，只给当前对象的 ID 和内容摘要；然后利用局部性逐步 Inline 关联信息，先附紧密关联对象的 ID，再附带时空相邻的内容，比如内容前 50 字、IM 消息前后相邻的消息和它回复的那条、代码评论所在讨论的相邻评论；一旦超上限就 Spill，简单粗暴点的做法是截断超出部分、保留续读入口，模型要完整内容再调工具。

这套思路用到大后期，还能演化出一个东西，叫链式召回（Chain of Recall）。

问题是这样的：任务越跑越多、时间越拉越长，Router 不可能把历史任务的全量都塞进自己的窗口，但用户哪天突然在另一个信道提起了某个旧任务，Router 又得能把上下文捞回来。我们的做法是，给 Trigger、Thread、Worker Session 这些对象都配上唯一 ID，注入时内联紧密关联对象的 ID，让它们在底层构成一张引用图。

因为每次调工具召回的对象本身也遵循 Inline & Spill，返回结果里又内联了下一跳关联对象的摘要和 ID。于是模型就能从一条当前消息出发，顺着引用关系逐跳展开：先读到它所在的 Thread，再从 Thread 内联的 ID 追到相关 Worker Session，进而找到这个 Worker 关联的另一个代码评审 Thread。就像顺着一条链子，按需把需要的上下文一段段捞出来。

先干起来再说：投机执行

聊到"主动"，其实还有更激进的一招，我们叫它提前行动，原理是从计算机系统的**投机执行（Speculative Execution）**搬来的。

核心思路很简单：在不确定结果会不会被采用的时候，先在后台偷偷干起来，用额外的后台算力，换人类等待和介入的时间。结果有价值，就交付；没价值，就悄悄丢掉。

个人助手的场景很直观：收到一封会议邀约邮件，Agent 可以先在后台核对日程有没有冲突、搜集相关背景资料、备好回复草稿，等用户过目一下就能直接发出去。研发场景也一样，我们内部在用户群里配了条策略，叫"静默复现并修复"：群里有人反馈问题或者讨论方案改动，Agent 先在后台试着复现、找修复方案，只有确认问题并且找到了简单方案，才把结果交给用户，否则全程闭嘴。

有个画面我记得特别清楚：群里还在热火朝天地讨论解决方案，Super-agent 已经在后台把修复 PR 都提了。等大家讨论得差不多，PR 已经挂在那是 ready 状态了。

怎么跟人打交道：全双工和分信道

架构对了，主动也解决了，但人机交互这块还有两个绕不开的坎，一个是阻塞，一个是信道。

先说阻塞。经典的 ReAct Loop 里，模型发起一次同步的 run() 工具调用后，循环就卡死了，直到工具跑完返回最终结果，期间什么新输入都接不了。这跟打电话只能一问一答的半双工一样憋屈。

解法是把耗时的命令和子任务调用改成异步的 start() 和 stop()，构成异步 ReAct Loop。模型调用 start() 后立刻收到"已启动（Started）"的返回，循环不在这等着了；后台工具跑完了，系统再把最终结果作为一条新的事件消息投递回会话。模型也能根据上下文调 stop() 主动杀掉跑太久的后台命令。这样一来，前台对话和后台执行彻底解耦，Agent 一边跑着耗时任务一边还能回你消息，新输入在当前推理步结束后立刻被处理，不用干等。

再说信道。IM、GitHub、邮件、文档，这些信道的带宽和人的使用习惯完全不一样，输出必须匹配，不能一套话术打天下。要是把面向单人终端的交互方式原样搬进群聊，把冗长推理和密集工具调用全怼出去，多人协作里分分钟信息过载。

好在双层架构已经解决了一部分：具体任务的推理过程和工具调用都被隔离在 Worker 内部，不会直接漏到外部信道，对外交互统一由 Router 负责。在这个基础上，再用提示词针对不同信道定制交互规范：

IM 这种即时通讯，主打低打扰的轻量沟通，像人类同事一样，只在需要决策或验收时才吭声，只问直接问题、给简短结论。我们验证过一条简单有效的硬性规定：单次回复不超过 100 词。

GitHub、邮件、文档这种异步信道，则侧重结构化、高信息密度的异步交付。比如创建或更新 PR 时，按项目规范写完整的问题背景、改动说明、验证结果；个人助手场景下，直接起草结构化的邮件和文档摘要。

脑子、手、环境，三个分家

做到这一步，一个 Agent 已经能连续、高效、主动地干活了。但还差"持久"。而"持久"这个需求，逼着我们看穿一个本地 Agent 的默认假设。

现在的本地 Agent，默认把三样东西绑在同一台设备上：推进 Agent Loop 的计算、需要持久保存的会话状态、还有代码仓库和本地工具链这些执行环境。设备一休眠或者离线，Agent 当场停摆，别的设备上的环境它也够不着。

要破局，得用存算分离的思路，分两步把这三个绑定的东西拆开。

第一步，把计算和状态分离。推进 Agent Loop 的计算可以做无状态，真正要持久保存的是会话状态。所以把计算放进云端无状态的弹性计算容器，把 Session 这种持久化状态放进数据库。无状态容器能水平扩展、重启、替换，连续性由持久化存储兜底，Agent 从此摆脱单台设备的生命周期限制，云端常驻。

第二步，把云端的 Agent Loop 跟重状态的执行环境解耦。这里有个挺反直觉的判断：真正难复制、难同步的是环境本身，那就别让环境跟着 Agent 上云。

为什么难同步？因为真实工作环境里往往有未提交的本地修改、私有凭据、内网服务依赖、特定的硬件或工具链，想在云端拉代码重建一套，成本极高还容易漏信息。另一个极端是让用户放弃本地环境搬去云端，对多数人来说迁移成本又太高。

所以正解是：Agent Loop 在云端跑，执行环境留在原地，端侧只放一个不保存会话状态的轻量 daemon，它只负责执行命令、返回结果。相当于把"手"留在外面，让"脑子"按需去够。这跟 Anthropic 说的"脑手分离"（Decoupling the brain from the hands）是一个思路，区别在于场景：那篇讲的是托管服务、按需沙箱和客户 VPC；我们这里要接的是用户日常用的、可能间歇在线的个人机器，上面有未提交的修改和本地凭据。

于是这种设计既支持 BYOM（Bring Your Own Machine），把用户的开发机或电脑接进云端 Agent，也支持接云端托管机器或按需创建的计算环境。一个 Agent 不再被单台机器锁死，可以在不同设备间切，甚至能支持间歇在线设备，比如某台个人设备重新上线后，再由云端 Agent 自动触发、完成需要在那台设备上执行的任务。

谁来看着看门狗？

持久在线还有一个隐藏要求：异常自愈。而这恰恰是最容易翻车的地方。

原因在于，Agent 系统的异常跟传统进程不一样。很多"故障"不是进程崩溃，而是模型在无效循环里打转、或者干脆偏离目标了。传统的存活探测、监控脚本根本抓不住这种异常，因为它们只管进程活着没活着，不管任务推没推进。

所以我们在主系统外面，单独放了一个独立的 Watchdog Session，用定时消息驱动它，构成一个外部的 Control Loop。它不光是处理接口报错、状态恢复失败这种基础设施故障，更关键的是，它会用模型去判断各个 Worker 有没有实质进展、方向有没有偏离整体目标。发现异常及时介入修复，遇到外部偶发故障就持续复查，直到恢复正常。

而且因为 Watchdog 本身也是一个带完整工具能力的 Agent Session，维护者可以直接用自然语言问它"这到底是哪儿挂了"，也能让它在线改主系统的行为，比如增删提示词、调整触发规则。它既是保险丝，也是个可对话的运维。

实验到底说了什么

架构讲得头头是道，总得拿数据说话。我们做了两组初步实验，结果挺能说明问题。

第一组是消融实验，拿群聊和 GitHub CI 消息流同时驱动四种端到端方案，单次实验约 300 条消息，其中约 20 条是工作请求，剩下是闲聊、跟进、叫停、CI 消息。编码工作用一个只消耗时间的工具代替，所以衡量的是调度和协作能力，不是单任务执行能力。四种方案分别是：Super-agent、去掉直通的 Super-agent，以及两种提示词配置下的"单 Session + Subagent 工具"。

两种提示词长这样。中性提示：

Use a subagent for a piece of work when appropriate...

提示优先委派：

Every message of the chat reaches you, so work you run yourself keeps stopping for new messages. Prefer handing each piece of work to a subagent of its own, and do only small things yourself...

结果很说明问题。Super-agent 的 p50 和 p95 完成时间分别是 12.4 分钟和 15.7 分钟，明显优于带 Subagent 工具的单 Session。而单 Session 的表现被提示词左右得很厉害：中性提示下，模型 5 次运行一次 Subagent 都没调，所有活都在主 Session 里干，还不断被新消息打断，p95 飙到 29.5 分钟；换成优先委派提示，5 次里有 4 次委派了，时间缩短但仍慢于 Super-agent，剩下那 1 次它觉得活"很小"就自己上了，形成一条长尾。

这个对比很有意思，它说明靠提示词工程和模型临场判断"分不分工"是赌运气，而双层架构通过"Router 不直接执行、Worker 只收订阅 Thread 的消息"，是从系统层面把这个问题消解掉了，不靠模型自觉。

开销方面，Super-agent 因为维护多个独立会话，读缓存 token 高于单 Session，属于"用更多 token 换更短更稳定的完成时间"。而把直通去掉之后，完成时间跟完整版基本持平，但 Router 要做的决定多了约 30%，总读缓存 token 从 2323 万涨到 3177 万，增幅约 37%。结论很清楚：直通机制不提高完成质量，但给 Router 省下了可观的 token 和推理开销。

第二组是针对 Router 层的批处理压测。让 Router 用真实模型、Worker 用 Mock，把 Trigger 到达速率从每分钟 1 条逐步提到 40 条，看平均 batch 大小、单次请求耗时、单个决定分摊的推理时间。

结果特别漂亮：到达速率从 1 条/分钟升到 40 条/分钟时，平均 batch 从 1.0 升到 2.8，而单次请求耗时只从 2.5 秒涨到 3.9 秒，涨幅远慢于 batch 大小的涨幅。于是单个决定分摊的推理时间，从 6.4 秒直接干到 1.6 秒。这说明当事件突发拥堵时，Router 靠自动合并积压事件，反而能提高有效吞吐。这也解释了为什么 7.1 里去掉直通让 Router 峰值负载变高，却没触到它的吞吐瓶颈，所以我们暂时不需要为了切分牺牲全局连续性。

那些还没想清楚的事

讲到这里，得泼盆冷水。这套系统现在能跑得比较顺，很大程度是因为我们做了一堆工程和场景上的简化。超出适用范围，还有几个硬骨头。

第一，双层架构怎么扩展？ 我们现在是"单常驻 Router + 订阅直通 + Worker 间不直接通信"的简化组合，覆盖了大多数日常任务。但任务规模一大、耦合度一高，Router 什么时候该水平切分、粒度怎么划、Worker 之间什么时候要引入直接通信、用什么协作拓扑，都没定论。还有一个方向是系统与模型的协同设计（Co-design），针对 Router 的事件判别、批量分派、上下文召回做专项训练，可能进一步提吞吐。另外，现在的链式召回主要解决近期任务，一旦运行周期拉长到跨月甚至更久，长程记忆就成了制约扩展的主要瓶颈。

第二，脱离 Session 之后，人机怎么协作？ 我们把 Session 对用户藏起来了，但新的问题出现了：底层执行会话不再对应界面上的会话，那任务怎么呈现、交互和项目管理用什么形式？我们认为聊天窗口中心主义其实部分是路径依赖。交互可以更多地发生在领域特化的界面里，比如让 Super-agent 直接在 GitHub 的 Issue 和 PR 里工作。Session 也可以出于使用习惯在界面上保留，但用户看到的一个会话，底层未必只对应一个 Session。另外，现在的模型能力还在快速演进，很多任务中途还得人来掺一脚，怎么平衡"用户对关键细节逐步干预"和"后台自主推进效率"，比如让用户随时介入、接管或实时协同，也值得探索。

第三，上下文边界和 A2A 怎么划？ 前面聊的全是单个实例内部的事，默认服务范围内的信息都汇总在一个全局上下文里。但范围一大，组织怎么配 Super-agent，本质上就是在划上下文共享与隔离的边界：需要共享的共用实例，需要隔离的各配各的。一旦组织内外出现多个彼此隔离的实例，比如每个人的个人助手和团队共用的 Super-agent，跨边界的协同就成了 Agent 间通信（A2A，不特指某个协议）。在互不共享底层上下文、各代表不同权限边界的前提下，怎么做安全可靠的 A2A，目前还没有答案。

第四，也是最要命的，安全与隐私。 事件驱动让 Agent 能被更广泛的环境驱动，同时也增加了接触不可信输入的风险。如果这个解决不了，Super-agent 只能在小而可信的范围内工作。我们前面那个"云端 Agent Loop + 端侧轻量 daemon"的设计，默认云端和端侧彼此信任。但云端 Agent Loop 持续接入外部事件，端侧又存着私有代码、敏感数据和本地凭据，一旦云端被服务端入侵或提示词注入攻破，它连着的所有端侧设备都有被控制的危险。退一步说，就算云端没被攻破，只要端侧凭据进了模型上下文，正常执行里也有泄露风险。所以还得设计一种机制，让 Agent 能"完全不接触凭据本身"却能用凭据。这是走向广泛应用的必经之路。

说在最后

回头看这整套设计，其实没什么全新理论。我们只是把计算机系统里那些被验证了几十年的经典思想，搬到了 Agent 系统的构建上。实现方式肯定会随技术演进不断变，但背后的设计思路，我们认为有更长期的参考价值。

眼下，基于这套思路搭的内部 Super-agent 已经在持续跑，日常参与问题复现与修复、代码审查响应、还有 DeepSeek Harness 自身的迭代。

再回到开头那句话。随着模型单个任务越来越不需要人盯着，卡住生产力的瓶颈，正在从"模型行不行"转移到"人忙不忙得过来"。通过双层架构、事件驱动、异步多信道交互、存算分离和外部 Watchdog，我们把繁琐的会话管理和上下文同步交给系统，让人从执行细节里彻底解放出来，上移到更高层的决策和验收。

在这个形态下，Agent 不再是被动等指令的对话窗口，而是一个在数字环境里持续在线的自主协作者。对个人，它是跨设备打理日常事务的助手；对团队，它融进研发工作流，接活、推进、交付。我倾向于相信，随着模型能力和底层架构一起往前走，这种更自主的工作方式，会成为人机协作的常态。