原文：数字生命卡兹克，《折腾了整整1年，毫无保留地分享一下我这套Agent自动化系统。》，2026-11-02
卡兹克说自己一年前是完全不懂开发的设计师。现在他搭了一套系统：同事提意见、线上报错、到点的定时任务，都会自动叫 AI 去干活。大部分事 AI 自己办完，只有要他拍板的，才推到他飞书上，他点一下就行。
这里说的 Agent，指 Claude Code、Codex 这类能自己改代码、查资料的 AI 工具。这一页把这套系统按原文拆开讲，图里的方块都能点开看细节。
说明：内容只取自原文，原文没交代的地方标了 文章未说明。原文的配图这里看不到，图里才有、正文没写的内容不补。
卡兹克是从 DeepSeek 的一篇技术文章说起的。那篇文章开头有一句话，他认为是最重要的。
打开 Claude Code 或 Codex，给一个任务，看着它干，干完检查，再给下一个。所有事情的起点都是人。不打开那个窗口，什么都不会发生。所以模型再强，能同时推进的也就是盯得过来的 3 到 5 个窗口。
把“任务从哪开始”这件事从人身上拿掉，让各种信号去触发 Agent。Agent 能自己处理的自己处理掉，拿不准、必须由他决策的，才推到他面前。他自己只做最后一步，在飞书上点一下确认，他管这一步叫“批奏折”。
1380 年，朱元璋借胡惟庸案废了中书省和丞相，六部直接对皇帝负责。洪武十七年九月，给事中张文辅给他报了一笔账：
朱元璋当场说：“朕一人处此多务，岂能一一周遍”，意思是一个人管这么多事，不可能每件都照顾到。卡兹克拿这件事说明：现在每个人用 Agent，递上来的东西多了，也会碰到同样的问题。所以要设计一套调度，让人只做最关键的判断。
原文的架构图是一张图片，这里按正文文字重画。系统分四块：自动化中台、Agent 执行、CI 中台、飞书批奏折。按 ①～⑤ 的顺序看，点任意一个方块看细节。
← 图比屏幕宽，左右滑动看全图 →
动画里点的多少、哪些被去重、哪些推给他，都是随机演示，不是真实数据。原文只说了大方向：大部分事 Agent 自己办完，只有一小部分推到他面前。
rules.json），决定交给哪台 Mac 上的哪个 Agent。只有最后一步：飞书里的 AI 助理小卡弹一张卡片，他点击确认。点完以后 Agent 收到决策，自己继续干活。
既然要把人从起点拿掉，就得设计“什么时候、在什么信号下叫 Agent 干活”。原文把这些信号统称为事件。中台就是专门管所有事件的地方。
定时去找：每隔一分钟或一小时主动去查一次（轮询），看有没有新活。Claude 和 Codex 的软件里就能直接设，他设了一大批定时任务，比如：
找上门：定时去查不够及时。同事提了意见、线上报了错，不能等到第二天早上再看。这种事要让对方系统一出事就主动发一条消息过来，这种做法叫 Webhook。消息来源有飞书消息、飞书机器人、邮件、各种系统的告警，格式各不相同。
事件触发后要叫醒的 Agent、模型、推理深度都不一样。原文举的例子：
如果每种事件都单独写一套脚本接来源、叫 Agent，三五个还行，到十几个、几十个就管不过来了。所以他自建了这个中台管所有事件触发，后来把定时任务也纳了进来。
中台本身是一个很小的独立服务，部署在线上一台轻量服务器上，有自己的网址和数据库。所有事件先发到这里，由它统一决定交给哪个 Agent、统一叫醒、统一收结果；需要他决策时，通过飞书给他弹卡片。
不管从哪来，发到中台的都是一条很短的消息，只有五样东西：
virxact-hub）feedback.new#12虚实中台发来一条 feedback.new #12，意思是同事给虚实中台又提了一条新意见，编号 #12。
格式统一以后，后面就好办：中台收到事件，去查 rules.json 里的规则，看该交给谁。
这条消息在中台里用什么字段名存储 文章未说明，这里只按原文列出的五样东西写。
各系统能把消息推给线上的中台，但中台没法直接找到他的 Mac。他的 Claude 和 Codex 都装在本地，两台 Mac 放在家里和办公室的内网里（局域网，外面连不进来）。所以反过来做：每台 Mac 跑一个接单程序，主动连着中台等活。每次连接最长等 50 秒，有活立刻领走，没活就重新连上接着等。这样 Mac 不用暴露到公网，速度跟实时推送也差不多。
接单程序叫什么、怎么认证、接到活之后怎么启动 Claude Code / Codex 文章未说明
不用再写一套新脚本，在 rules.json 里加一条规则就行。他跟 Agent 说一句，Agent 改完文件、过了检查，几分钟就生效。
“过了检查”具体查什么 文章未说明
哪类事交给谁，就是规则里的一行字。今天交给 Claude Opus 5.5，明天想换成 GPT-6.2 Astra，改一行就行。以后出了更好用的模型，可以随意替换。
对应到下面那条规则，就是 "to": "m5-claude" 这一行。
自动化跑起来以后，同一件事被发好几遍是常态：网络抖一下，来源以为没发出去，会再发一遍；同事提完意见，又补一句话、又贴一张图，又是好几条事件。如果每来一条就叫醒一次 Agent，同一件事会有好几个 Agent 同时在改，最后一定乱。所以由中台统一去重。
试一下：按下面的按钮往中台发事件。规则是同一条意见同时只跑一轮，最多三条一起跑（对应规则里的 parallel: 3）。
重复来的消息是直接丢掉，还是并进正在跑的那一轮，还是等这一轮结束再处理 文章未说明。超过三条时怎么办 文章未说明，演示里让它排队。
不管哪个 Agent、哪个任务要找他，都只走一条路：小卡，他在飞书里的 AI 助理。每条规则都写清楚了，只在必须由他判断和决策的时候才说。这样不会这个脚本发一条、那个机器人发一条，把他的飞书刷屏。
对应到规则里，就是 "tell": "needed" 这一行。
所有事件都从中台过，每件事都留了底，记在中台的数据库里。点开任何一件任务，还能直接跳到当时 Agent 干活的那个会话，看它到底干了什么。
| 原文列出的记录项 | 以 #12 为例 |
|---|---|
| 什么时候来的 | 文章未说明 |
| 从哪来的 | 虚实中台 |
| 交给了哪个 Agent | m5-claude（按那条规则） |
| 它最后的结论是什么 | 文章未说明 |
| 有没有需要他留意的 | 文章未说明 |
| 后来又是怎么解决的 | 文章未说明 |
| 链接 | 跳到当时 Agent 干活的会话 |
攒久了，哪条流水线最忙、哪个 Agent 干得最多、哪类事老出问题，一眼就能看出来。以后换模型、改规则，也有数据依据。
他说自己受种田游戏影响多，玩《戴森球计划》时最喜欢看密密麻麻的自动化流水线。所以做了一个网页，把流水线像游戏一样展示出来，并且跟现实世界的时间和天气打通：现实下雪，自动化小镇里也下雪。原文附了一段渲染视频。
小镇的具体画面、用什么做的、天气数据从哪来 文章未说明。右边只是按“跟时间、天气打通”这一点做的示意，不是原作。
所有派活规则都写在 rules.json 这份配置文件里。原文给了“同事意见”这一条。先看原文自己写的人话版：
下面这段就是把这句话写成电脑能读的格式。左边是原文给出的规则（为了好读做了分行，内容没改），右边是每一项的解释。点一下任意一边，另一边会同步高亮。
1{2 "name": "中台意见",3 "when": {4 "source": "virxact-hub",5 "types": ["feedback.new", "feedback.followup", "feedback.decided"]6 },7 "to": "m5-claude",8 "cwd": "~/code/work/virxact-hub",9 "skill": "hub-feedback",10 "ask": "按其中“被 Agent 自动化中台叫起来的”一节处理。",11 "group": "hub-feedback",12 "parallel": 3,13 "tell": "needed"14}
这条规则的名字：处理中台（虚实中台）的意见。原文没有单独解释这个字段。
触发条件。消息的来源和类型都对得上，才按这条规则办。（这一项原文没单独解释，这里按规则的写法说明。）
事件从哪来：虚实中台。就是统一格式里“从哪来”那一项。
feedback.new：对产品的新意见feedback.followup：同事的补充feedback.decided：他拍过板的决定
这三种都交给同一个地方处理。
交给谁：M5 上的 Claude Code。要换 Agent，就改这一行。
在哪干：虚实中台的代码目录。cwd 就是电脑里的文件夹路径。
用哪个 skill：hub-feedback。这个 skill 里具体写了什么 文章未说明
给 Agent 的指令只有一句：按 skill 里对应的那一节办，也就是 skill 里“被 Agent 自动化中台叫起来的”那一节。
原文的人话翻译里有“每条意见单独开一轮，同一条意见同时只跑一轮”，但没说这句对应哪个字段。group 具体管什么 文章未说明
最多三条一起跑。
做完了，只在需要他决策的时候才告诉他，否则不推给他。tell 还能填哪些值 文章未说明
加一条新规则的方式：他跟 Agent 说一句，Agent 改完文件、过了检查，几分钟就生效。rules.json 一共有多少条规则 文章未说明
事件触发之后，就是 Agent 领任务、干活。这一块讲四件事：用哪几个模型、跑在哪台机器上、为什么不上云、每个任务怎么配 skill。
他开了 200 刀（美元）的 Claude 会员，猛用 3 天就能用掉近 90%。几个主流模型擅长的活也不一样，所以要分工，把额度花在合适的地方。目前是 200 刀 Claude 会员加 100 刀 GPT 会员，基本够用。
比较复杂、需要主观能动性、要做决策的活：AIHOT 的自动化开发、同事对公司中台提的意见。他几个核心项目的代码，大部分也是它写的。
中台例子里写的是 “Claude Opus 5.5 high 推理”。他自己日常主动发起的任务也用 Claude。
管所有项目的运维：告警、每天早上的系统日报、各种到期的复查。出了问题就去查，查到 BUG 直接修。效果好，性价比高。
CI 中台第一步的审查也用它（通过 Codex）。中台例子里写的是 “GPT-6.1 Sol xhigh”。
直接操控他 Mac Mini 上那个登录好各种账号的 Chrome。每天去各平台搜大家对 AIHOT 的讨论、每周去各家 AI 问 GEO 问题，这些没有接口、正常拿不到的数据，都靠它。
中台例子里写的是 “Codex 用 GPT-6.1 Terra xhigh”。这个 Chrome 在哪一台 Mac 上 文章未说明
他的看法：做决策、做管理的模型，得是智力和主动性最强的。他见过不少人用 Grok 或别的弱一点的模型去指挥 Claude，他认为不对，弱模型指挥强模型会乱套。另外，规则里换模型只改一行，比如从 Claude Opus 5.5 换成 GPT-6.2 Astra。
新买的
他的主力日常用机。前面那条 rules.json 规则的 "to": "m5-claude"，就是交给这台上的 Claude Code。
去年买的
Agent 自动化任务基本都跑在这台上。CI 中台也自建在这台上（见下一节）。
日常需要从 M5 Pro 操控 M4，直接让 Agent 操控，或者用 UU 远程。两台分别跑哪些具体任务，除上面提到的以外 文章未说明
skill 就是给 Agent 写好的操作手册（原文叫 SOP，标准作业流程），里面附带一些规则、参考和脚本。他基本上每个自动化任务都配一个专属 skill。
好处是清晰、可控、可管理：想改这个任务的细节，直接改 skill，不用动 Agent 执行本身的逻辑，两边分开。
前面规则里的 skill 和 ask 两个字段就是这样配合的：规则只指定用哪个 skill、按哪一节办，具体怎么办写在 skill 里。
一个定时任务，配了一个专门的 skill，内容是把这一周合进来的“屎山”找出来删掉。要找的是这几种：
能删的直接删掉，再上线。
这个 skill 的原文和“能删”的判断标准 文章未说明
CI 就是代码写完以后，自动帮你审查、测试、上线的那一整套流水线。不管 Claude 还是 Codex，Agent 的活干到提交代码、提一个合并请求（PR）就结束，它自己不能上线。后面的事全交给 CI 中台，一共五步。
GitHub 自带的 CI 用它自己的机器，超出额度要另外交钱。每个合并请求还要来回跑好几遍检查，那点额度扛不住。
所以他在家里那台老的 M4 Mac Mini 上自建了 CI：机器现成，不另花钱；性能更强；机器在北京，跑得比 GitHub 自己的 CI 快。后来项目多、Agent 多，就把这个本地 CI 升级成了中台，所有项目都用它。
他的补充：如果你有 Linux 机器做 CI 会更好。他的 Mac 是 ARM 的，跑的其实是模拟环境，但他觉得够用。
CI 中台用什么软件搭的 文章未说明
能自动解决的，Agent 都自己解决了。最后推到他这里的，只剩需要他做的决策或者大事。
他不想让 Agent 绕道 DOT、Grok Bot 这类个人 AI 助手来找他，嫌麻烦，于是直接连进飞书：由飞书里的 AI 助理“小卡”给他推一张卡片，他第一时间能看到，直接在卡片上做选择。
他点完以后，之前等他审批的 Agent 接着往下干，卡片自己改成结论。
卡片的真实文字、按钮名称只在原文截图里 文章未说明，这里用“选项 A / B”代替，只演示交互。
朱元璋是一个人硬扛。到了他的子孙，摸索出一套办法：
一一对应：
卡片的交互方式有用，但更要紧的是：到底什么事该推到他面前。之前踩过坑，有时一天给他推几十条，严重影响注意力。现在必须先问他的只有这几类：
剩下的，Agent 自己全权做完、上线。
原文最后写了“等等”，完整清单 文章未说明
这两份文件在哪个仓库、谁来写入、点完卡片后会不会自动记进去 文章未说明
他每天会收到一些用户直接发来的反馈。每一条他都亲自看。他觉得能做的，就复制粘贴发给 Agent 去解决；解决完以后，给对方的邮箱发一封真诚的回信。这一环不走中台，没有自动化。
选一个例子，按“下一步”或“自动播放”。当前走到的环节会在下面这一排标红；点这一排里的环节，可以直接跳到那一步。