上周，DeepSeek 的 Super-agent 设计文章提出一个很刺耳的问题：一个人通常只能同时跟进三到五个活跃会话。单个 Agent 再强，几项任务一起推进时，最先被用完的可能还是人的注意力。
一位从设计转向独立开发的产品创作者，花了将近一年，搭出了一套自己的应对办法。他让事件自动叫醒 Agent，让代码经过独立的审查和检查再上线，只把少数必须由人决定的事，送到飞书里等他点一下。
整套系统的目标很直白：人不在电脑前，事情也能继续往前走。那么，从一条消息出现，到一次任务真正交付，中间到底发生了什么？
当每件事都等你开口
平常使用 Claude Code 或 Codex，很容易形成一种熟悉的节奏：打开窗口，交代任务，看它执行，检查结果，再交代下一件。工具已经能做不少事，工作的起点却仍是那个坐在屏幕前的人。你不打开窗口，新任务就不会开始；你同时盯着的窗口越多，切换和判断越吃力。
这个困境让人想起朱元璋。洪武十三年废除中书省和丞相后，六部直接对皇帝负责。到了洪武十七年，给事中张文辅统计过八天的奏章：一千六百六十件，涉及三千三百九十一项事务。平均一天两百多件奏章、四百多项事务。朱元璋感叹，一个人面对这么多事，怎么可能件件照顾周全。
明太祖朱元璋画像（资料图）。图片：Wikimedia Commons，公有领域。
把皇帝和使用 Agent 的人放在一起，当然只是个比喻。但两者有一个相似的结构：如果所有信息都要先到你这里，由你亲自分配、追问、确认，下面的执行能力越强，你反而越容易成为队列里最慢的一环。
这位创作者想解决的，就是任务的起点和人的介入点。他希望新反馈、告警、邮件、定时检查等信号自己成为任务的入口；Agent 能处理的自己处理，真正要拍板的再递到人面前。他把这理解为一种管理工作：决定什么可以放手，什么必须亲自判断。
他的系统因此分成几段：事件进入自动化中台，中台分派给本地 Agent；涉及代码的任务进入 CI 中台；需要人的决定，才由飞书里的 AI 助理送来一张卡片。最后那一下点击，是他给自己保留的“批奏折”。
文中工作流示意：事件进入中台，交给本地 Agent；代码经 CI 交付，需要决策时回到飞书卡片。
让事件找到该干活的 Agent
定时任务是最容易想到的入口。每天固定时间生成报告，每周检查一次产品在不同 AI 平台上的回答，或者定时扫描开源项目的新问题和合并请求，Claude 与 Codex 的应用都能承接这类安排。他已经把一批周期性工作放在那里运行。
但同事刚提交意见、线上刚报错，往往等不到第二天的例行检查。这类任务要靠事件到达时主动触发。飞书消息、邮件、系统告警、产品反馈都可以推来信号，只是每个来源的格式不同，要找的 Agent 也不一定相同。
于是他建了一个很小的独立服务，把所有入口收在一起。事件先转换成统一格式：来源、类型、对象、一句话摘要，以及能返回原处的链接。中台拿到这条短消息，按规则决定交给谁、在哪个项目目录工作、用哪个 Skill、同类任务可以并行几条，以及完成后是否需要通知他。
例如，同事提交一条新的中台意见，系统收到的是类似“feedback.new #12”的事件。规则会把新意见、补充说明和已经拍板的决定，交给负责该项目的 Claude Code，在对应代码目录加载处理反馈的 Skill。同一条意见一次只运行一轮，不同意见最多并行三轮。任务做完，只有需要人判断时才通知他。
规则集中放在一个文件里，改变路由就改对应条目。某类任务今天适合交给 Claude，明天换成另一种模型，也不用把整个事件接入重新写一遍。随着入口增多，这种集中管理尤其重要：几十种事件各自维护一套唤醒脚本，很快就会变得难以追踪。
还有一个现实问题：中台在公网服务器上，真正运行 Claude 和 Codex 的两台 Mac 却在内网，外面不能直接推送到机器上。他让每台 Mac 常驻一个接单程序，向中台发起最长约五十秒的等待请求。有任务就接走，没有就继续等。这样既能及时领活，也不用为了接收 Webhook 把本地电脑暴露到公网上。
中台还负责挡住重复劳动。网络抖动可能让同一事件被发送几次；同事提完一条意见，又补文字、再贴图片，也会形成多个信号。如果它们各自叫醒一个 Agent，同时修改同一件事，结果很容易互相覆盖。中台把相关事件归到同一对象上，让同一件事保持单轮处理。
它也收拢了人的消息入口。不同 Agent 不直接各发各的通知，只有真正需要决策的事项才通过飞书里的“小卡”抵达。每个任务从何而来、分给谁、结论是什么、有没有等待人决定，都会留在数据库里；点开任务，还能回到执行时的会话。日后看哪条流水线最忙、哪种任务总出问题，也有记录可查。
这套后台甚至有一张像游戏小镇的可视化页面，任务像流水线一样运行，画面会随现实时间和天气变化。这个细节很私人，却说明了他在乎的一件事：自动化不能只是黑箱里“好像在干活”，还要能看见它此刻在做什么。
Agent 在哪里执行，为什么要分工
事件找到了人选，下一步才是执行。这里的约束很实际：模型额度有限，不同模型也各有合适的工作。他使用的是每月约二百美元的 Claude 订阅和约一百美元的 GPT 订阅。按他的使用强度，Claude 的额度曾在三天内消耗接近九成，因此把所有任务都扔给最贵的模型，并不能让系统稳定运行。
在他的分工里，Claude Opus 主要承担开发和需要持续判断的复杂任务，包括产品迭代、公司内部中台的反馈处理。GPT-6.1 Sol 主要处理运维：系统告警、日报、到期复查，以及查到问题后的修复。GPT-6.1 Terra 负责浏览器和电脑操作，到已经登录账号的 Chrome 里搜集平台讨论，或定期向多个 AI 产品提出相同问题，观察 AIHOT 的呈现情况。
这些分工是他在自己的任务和预算下形成的安排。中台的作用，是把事件类型与执行环境、模型和推理强度的选择放在一起管理。规则一改，后来出现更合适的模型，就能替换对应岗位，而不用改写整条流水线。
运行地点也有讲究。他有两台 Mac mini：一台 M5 Pro 用作日常主力机，另一台 M4 长期开机，承担大部分自动化任务。代码仓库、发布权限、飞书身份和登录好各类账号的浏览器原本就在这两台机器上。本地执行省去了把这些登录状态和权限复制到云端的麻烦，也让一些依赖国内服务或已登录浏览器的任务更容易接上。
M4 Mac mini 背面资料图，可见有线网络与外接接口。摄影：AzureSaturn，CC0，Wikimedia Commons。
每类重复任务还有自己的 Skill。他把 Skill 当成写给 Agent 的工作规程：该读哪些材料，按什么顺序处理，什么时候需要停下来问人。比如每周清理代码和文档的任务，Skill 会要求找重复实现、个案补丁、停用后没有拆干净的部分和流水账式文档。要调整这个任务的做法，改 Skill 即可；事件中台只管什么时候唤醒它、交给谁。
于是，一条事件不必携带长篇指令。它告诉中台“发生了什么”，规则给出“叫谁、去哪里”，Skill 再回答“具体怎么做”。这三层分开，才让任务多起来之后仍有地方可管。
代码交出去之后，还有五道关
Agent 写完代码，工作并没有结束。他把代码交付的后半段做成另一套共享流水线，供几个项目一起使用。原因是任务量已经很大：按他的统计，AIHOT 在一个十月合入了接近一千个合并请求，平均每天二三十个，一个请求还可能反复跑检查。若全部依赖 GitHub 提供的机器和额度，他估算每月会多出五十美元以上费用。
他于是把家里那台 M4 Mac mini 也用作 CI 的执行机器。无论任务由 Claude 还是 Codex 开始，开发 Agent 把代码提交并提出合并请求后就停手，后面的审查、检查、合并、发布、核实，交给 CI 中台。
第一步是另一个 Agent 审查。项目代码大多由 Claude 编写，合并前再由 Codex 从另一视角找真正可能出错的地方。审查 Agent 只有读取权限，不能改代码，也接触不到密钥。它只报会影响正确性的问题，跳过单纯的风格建议；审查次数设上限，避免在小问题上来回消耗。
他给出过一组近期统计：两周内，四个项目合计审查二百九十八个合并请求，提出三百三十三条问题，其中三百零六条在合并前修复，最严重的一档有五十一条。这些数字反映的是这套流程自己的运行记录，不能直接推成所有 Agent 项目的错误率，但足以说明为什么他愿意在每次合并前多设一道检查。
第二步是自动检查：类型、测试、构建，以及数据库变更只能新增不能修改等项目硬规则。任一项不过，就不能合并。检查在 M4 上新开的隔离环境里运行，跑完即销毁，避免把 Agent 提交的代码直接放到日常使用的 Mac 环境里执行。
第三步是合并。审查与检查都通过后，GitHub 才自动把代码合入主干；这两道要求被写进仓库规则，不靠某个 Agent 临时记得遵守。第四步是发布，主干有新改动后，发布流程再使用专门的隔离环境执行。
第五步尤其容易被忽略：核实。发布任务显示完成，并不等于线上已经运行了这次改动。交付程序会等发布流程结束，再查询线上版本是否包含这次提交，确认后把结果写回 GitHub。开发 Agent 回头看合并请求，就能知道它究竟停在审查、检查、发布，还是已经上线。
他报告这五步从提交到上线的中位耗时约两三分钟。这个速度来自他自己的项目和设备配置；更关键的设计，是把“代码已经写完”与“改动真的送达线上”之间的状态逐一接起来。只有最后一步核实通过，这次任务才算真正交付。
最后一张卡片，只留给必须由人决定的事
系统越能自动干活，消息出口反而越要克制。早期卡片一天能来几十条，作者发现自己又变回那个不停处理奏章的人。于是他把需要先问人的事缩到几类：删除数据、停服、花钱、对外发消息、改变产品方向、新建或轮换密钥、修改权限。其他能够按既定规则完成的任务，让 Agent 自己处理到结果。
需要他决定时，飞书里的 AI 助理推来一张卡片，列出问题和建议处理意见。他点选后，等待中的 Agent 收到决定继续执行，卡片也更新为最终状态。原文把这比作明代的“票拟”和“批红”：前面的人先把建议写好，最后的决定仍在皇帝手里。放到这套系统里，卡片就是把复杂过程压缩成一个有上下文的判断时刻。
更重要的是，同一件事不反复请示。他把亲口做过的决定连同日期和原话存起来，也记录已经明确拒绝过的方向。Agent 再遇到类似事项，先按既有决定处理。这样减少的并非某一次点击，而是以后同一问题反复占用注意力的次数。
但他留了一类内容给自己亲自看：用户反馈。用户直接写来的意见，他逐条阅读，认为值得做的才亲手交给 Agent 跟进。问题解决后，再给对方回信。对他来说，这是自动化链条之外有意保留的一次人与人的接触。
这套系统的起点，是一个原本不懂开发的设计师想让工作继续向前；一年之后，他拥有了事件中台、本地 Agent、CI 流水线和飞书决策卡片，也把这些能力用于自己的开源产品和公司项目。产品月活、Star 数和合并请求规模，都是他分享时给出的个人项目成绩，真正贯穿全文的仍是同一个问题：当 Agent 越来越能执行，人应该把注意力放在哪里？
他的答案不是彻底退场。事件自己来，Agent 自己领活，代码自己过关，只有需要承担判断的地方，人再回来。那些值得亲自读的反馈，也依然留在手里。
从不知道 CI 是什么，到能把整条交付链搭起来，他把这一年的变化归于持续开发和持续学习。自动化省下来的注意力，最后又回到了创造、回应和好奇心上。