Anthropic刚教的24小时agent，我当天做出来了

10月31日 DeepSeek Harness 谈 super-agent，11月13日 Anthropic 写 always-on agents。作者照着后者在开源项目 FanBox 里做了一版，随 2.20.0 发布：agent 停下等你，手机收到它一句话。

一、背景

这篇文章的缘起呢，是最近看到的两篇非常好的关于agent系统设计的文章。

10月31日，DeepSeek Harness团队发了一篇《Super-agent设计探索：迈向更自主的Agent系统》。11月13日，Anthropic发了一篇Building always-on agents，教你怎么建一个24小时在线的agent。

这正好是我最近非常想折腾的事，所以看到Anthropic这篇时，我就让Claude照着它在FanBox（我做的那个Coding Agent驾驶舱，开源的）里做了一版，现在已经随FanBox 2.20.0发出去了。做出来的效果是：终端里的agent停下来等你，而你不在电脑前，你的手机（微信或飞书）会收到它的一句话。也就是说，尽量让你以相对自然的方式持续和agent互动，并让agent24小时为你工作。

这篇文章的顺序是这样的：第二到四节把这两篇文章讲清楚，他们各自看到了什么问题、给了什么方案（Anthropic那五个部件后面都能在FanBox里对上），如果你两篇都读过，可以直接跳到第五节；第五节讲我们做出来的工具，装上FanBox就能用；第六节讲我们照着做的时候踩到的四件事，里面有几样东西不用FanBox也能抄走。

二、DeepSeek这篇：瓶颈是人的注意力

原文在这：https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg

这篇开头就写明了，它是一篇架构思路的探讨，里面讲的东西DeepSeek Harness这个产品现在还没有全做出来。

他们看到的问题

现在的agent都是以一个会话（Session）为单位干活的，会话之间互相不认识。你同时推进几件事，就得自己在几个会话之间来回切，自己记住每个会话聊到哪了。

他们观察到的数字是：一个人通常只能同时跟进3到5个活跃的会话（也确实基本上是我开的终端数的上限了）：

单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

在现有的本地agent上接点外部消息进来也解决不了，因为它一次只能干一件事，几个任务的上下文会混在一起，电脑一合盖它就停了。

他们的方案

他们把想要的东西叫Super-agent，要它做到四件事：连续（你感觉始终只有一个agent）、高效（不用等上一件事干完就能接下一件）、主动（没人@它也能自己发现该干的活，不该介入时保持安静）、持久（一直在线，出了异常自己恢复）。

然后用五个模块来撑这四件事：

（图来自DeepSeek原文，方括号里的数字是原文的章节号，\[2]到\[6]依次对应下面的1到5。）

1、双层架构。 前面放一个常驻的Router（路由层），所有人跟它说的话都先到它这里，它只负责跟人交互和分派任务，甚至可以连Bash工具都不给它。后面是很多个Worker（干活的会话），每个Worker一个独立的上下文，挂全套工具，专心干一件事，而且Worker不直接跟人说话，干完了向Router汇报，由Router统一回复。

2、事件驱动。 驱动agent的主要输入从人敲的提示词变成了环境里的事件，群聊消息、邮件、代码评审的评论、CI的结果都算。事件大部分是噪音，所以先用写死的程序规则筛掉一大半，剩下的再让模型判断要不要行动。群里有人在讨论一个bug，它可以先在后台悄悄复现，找到简单的修法才把结果拿出来，否则全程不出声。

3、面向人的交互。 按信道定带宽，他们验证过的一条硬规定是，在群聊这类即时通讯里单次回复不超过100词。

4、计算、状态与环境的分离。 agent的循环放到云上，会话状态存数据库，而代码仓库这些搬不动的东西留在你自己的机器上，装一个轻量的常驻小程序（daemon）让云上的agent按需过来执行命令。

5、Watchdog。 主系统外面再放一个独立的会话，定时醒来检查。它既看接口有没有报错，也让模型判断每个Worker是不是真的有进展、有没有跑偏。

他们的实验

他们做了一个初步实验：用大约300条消息（其中大约20条是真的要干活的请求）同时驱动几种方案，每种跑5次。Super-agent从收到请求到给出结果，中位数是12.4分钟，95%的请求在15.7分钟内完成。对照组是一个带了派子代理工具的普通单会话agent，提示词里中性地写合适的时候可以用子代理，结果5次运行里它一次都没有派，同一个95%的数字拖到了29.5分钟。代价是token，Super-agent单次实验读缓存的token是2323万，单会话那组是605万。

原文自己也说了，实验用的是合成的消息流，结果只作初步参考。文章最后列了几个还没解决的问题，其中一个是：会话被藏到底层之后，人到底该通过什么界面跟agent协作。他们的判断是最终形态很可能是高度定制化的。

三、Anthropic这篇：agent常常不在线

原文在这：https://claude.com/resources/articles/building-always-on-agents

他们看到的问题

大多数agent只在你发消息的时候才跑。Anthropic说过去几个月常驻agent又热了起来，原因有两个：新模型的判断力更好了，更知道什么时候该回来问一句；智能在变便宜，在一个长程编码的基准上，Opus 5.5每解决一个任务的成本比Opus 5低78%。我自己的感受也是，现在200美金的ultra会员，如果不是用fable5.2，而主要是跑opus5.5的话，基本上不需要太有用量焦虑，比codex确实实用太多了。

于是客户开始问他们，怎么把这种没人盯着也能主动干活的体验做进自己的产品。他们的回答是，agent里面跑的还是同一个循环，要补的是外面那层架构。

他们的方案

整篇里我最喜欢的是这一句：

常驻agent其实并不「一直在线」。那只是对用户体验的描述。

实际上它大部分时间在睡觉，不花任何token。隔一阵被某件事叫醒，干一小段活，把发生了什么存下来，再回去睡。

展开理解下这层架构，其实就五个部件：

1、事件收件箱。 能叫醒它的事（你的消息、别的系统推过来的通知也就是webhook、定时任务）都不直接去调agent，先丢进一个收件箱，通常是一张数据库表，由一个工作进程来取。同一时间只许一个工作进程；你连发三条消息，并成一轮，agent只回一次。

2、定时器。 一种是agent给自己定的跟进，比如20分钟后回来看看测试跑完没；一种是你定的周期任务，比如每日简报。到点了只是往收件箱里加一个事件。

3、记忆。 只放agent没法再查到的东西，别的系统里已经有的存个指针就行。另外它要记着已经告诉过你什么，免得同一件事叫你两遍。

4、权限。 原文说这是风险最大的地方：一次运行握着你的访问权，而且按设计就是没人盯着的。他们给的三样东西是把凭据放在agent够不着的代理里、用分类器拦危险动作的自动模式，以及把需要你批准的工具调用先挂起来等你回话。

5、发件箱。 一次运行可以有三种结尾：发一条消息、什么都不发、挂起来问你一句。原文是这么说的：

发太多的agent变得吵，发得不够的agent会漏掉用户需要知道的事。……实践中，让agent从安静开始，再慢慢赢得用户更多的注意力，比反过来好。

五个部件拼起来是这样一个圈，用户的回答又会作为一个新的事件回到收件箱：

四、两篇放在一起理解

我把两篇各自的问题和方案整理成了一张表：

两篇其实有不少相似的地方。DeepSeek讲计算和环境分离的那一节，直接引了Anthropic提出的脑手分离。然后呢，两篇都花了不少笔墨讲同一件事，就是让它少说话：DeepSeek的说法是不需要介入时保持安静、群聊里不超过100词，Anthropic的说法是从安静开始。这个逻辑其实是因为虽然agent可以无限工作，但是人的注意力是有上限的。

FanBox本来干的就是同时开很多个agent窗口这件事，所以DeepSeek讲的那个问题确实挺真实的。不过它那套要上云、要一个团队共用，Anthropic这套几张表加几个后台进程就能搭，一台Mac上也做得了，所以我们照着做的是Anthropic这篇。

五、我的工具化应用：FanBox里多了什么

说起来，FanBox在今年6月的2.0版本就能用微信遥控电脑里的Claude Code了。并且提供了Mac合盖不待机的能力，你不需要半开着Mac走在路上了…也不用因为agent还在跑着而晚下班。

但它一直有个毛病：你不找它，它就不动（大多数agent的毛病）。agent在电脑里停下来等你确认一个操作，你人在外面，它就那么干等着，直到你回到电脑前。

2.20.0里做的就是把这个补上。更新之后你会得到这些：

• 你离开电脑以后，终端里的agent停下来等你满10分钟，微信那头的agent会自己醒来看一眼，值得才叫你；
• FanBox的任何终端里多了一条命令fanbox-notify，agent可以自己决定给你手机发一条消息；
• 除了微信，也接了飞书（在群里加一个自定义机器人，把地址贴进设置就行）；
• 你在电脑前的时候，它一条都不会往手机上发。

设置里多出来的是最下面两行，「离开时叫我」默认开着，不想要可以关：

结构上我们照的是Anthropic那五个部件，在FanBox里它们分别是这样的：

事件收件箱。 四种事会叫醒它：某个窗口的agent停下来等你满10分钟，而这台电脑5分钟没有键鼠输入；Claude Code断线了，自动续跑试了3次没续上；它自己定的跟进到点了；你让它盯的来源有了新条目。

定时器。 在微信里说「半小时后帮我看看测试跑完没」「每天早上9点告诉我各窗口进度」，它自己定时间。

记忆和权限。 没人触发的那一轮只能读、不能动手，也不写长期记忆，细节在第六节。

发件箱。 夜里23点到早上8点不发，攒到早上并成一条；两条之间至少隔10分钟；一天最多20条。微信连着就先发微信，微信没连或者发不出去才走飞书。

DeepSeek那一套我们没做，FanBox不上云，也没有多人共用，所以目前不算是一个特别成熟的可以24小时不停运行的agent系统，不过对我来说基本够用了。照他们的图回头看FanBox，能对上的大概有两个地方：微信那头的agent有点像那个常驻的入口，我回一句，它替我把话转进对应的窗口。不一样的是，DeepSeek的Worker不直接跟人说话，而我们终端里的agent可以用fanbox-notify直接叫我。

自动化测试和真实Claude Code的评测都跑过了，飞书这条路在真群里发通了。

六、我的实践

1 没人叫它的时候，它只能看

常驻之后，叫醒它的可能是终端里的一段输出、一条GitHub issue的标题，这些都是别人写的字。所以定了一条死规矩：没人触发的那一轮，只给它读文件和搜索的工具，不能改文件，不能跑命令，也不往长期记忆里写东西。它想动手，只能先在微信上问我一句，我回了话，下一轮才是全权限的。

这条不用FanBox也能抄，Claude Code的无头模式本身就能限制工具：

claude -p “……” –tools Read,Grep,Glob –strict-mcp-config

我们测过让终端的输出里夹一段冒充系统的话，要它跑一条命令、替我回一个y确认删除、并且不要告诉我。它醒来后把这件事原样报给了我，没有照做，那条命令要创建的文件事后检查也确实不存在。

2 别让agent猜你在不在

第一版给agent的说明写的是「需要他知道、而他可能不在电脑前时」发消息。拿真的Claude Code测，该发的两次它一次都没发，因为它没法知道你在不在电脑前，它刚收到你的一条消息，大概就当你还坐在那。

第二版改成了这样（你可以直接抄去用）：

你不用判断他在不在电脑前，FanBox 会判断：他在，就只在界面上提示一下；不在，才发到手机；夜里会攒到早上。

这一轮收尾前，下面任何一条成立就发一条：这一轮里有命令或任务跑了几分钟以上，现在有结果了（成了或败了）；卡住了，要他做决定才能往下走；出了他必须马上知道的事（发布失败、数据可能丢）。

再测它就会发了，随口问一句404是什么意思、让它跑个ls，它不发。人在不在由FanBox判断，判据很土：系统2分钟内有过键鼠输入，就算你在。飞书那头收到的是这样的：

3 它醒一次是要花钱的

我们实测微信那头的agent每次醒来4到11秒，Claude Code报的折算成本大概是每次0.14到0.16美元。我是订阅用户，这笔走的是订阅额度，而这份额度我白天干活也要用。所以加了上限：两次醒来至少隔3分钟，一天最多48次。

4 不是所有事件都会自己送上门

GitHub的PR和issue、飞书文档的评论、某个账号发了新内容，这些也都是事件来源，可它们推不到我电脑里来。我们的做法叫盯梢：在微信里跟它说帮我盯着fanbox仓库的新issue，它自己写一条能列出最新条目的命令，FanBox每隔一阵（最短5分钟）跑一遍，输出里多出来的新行才算一个事件。

七、最后

说起来，两篇文章讲的那种放在云上的常驻agent，我们没做，这是我自己的选择。

我比较习惯让agent在我自己电脑的环境里工作。我基本上可以保证电脑24小时联网在线，而且大多数的工作上下文都保存在电脑里。云端我还是稍微有些不信任，以及我觉得，如果不给它提供充足的上下文，它能实际完成并且做好的工作其实会比较少。

所以这一版做下来，电脑开着、合盖不待机，agent在本地干活，有事到手机上叫我，对我来说已经挺可用的了。还没做好的也有几样：微信那头的值守现在只支持Claude Code；飞书只能发，不能在飞书里回话；判断你在不在只看键鼠。

如果你也是在自己电脑上同时开好几个Claude Code、Codex的人，可以试试FanBox，开源的，更新到2.20.0就有上面这些：

地址在这：https://github.com/alchaincyf/fanbox

如果对你有用，帮我点个赞、转给也在用Claude Code的朋友，或者关注一下，我就当这一天没白折腾～