外观
卡兹克的 Agent 系统
副标题：一个非专业用户用一年时间搭出的个人 Agent 自动化体系——事件中台、模型分工、自建 CI、飞书批奏折。
一句话定义（stated）：把 Agent 当同事而不是工具——事件推动工作，规则决定谁来做，人只批奏折。
背景：从设计师到"自己的皇帝"
作者自述一年前是完全不懂开发的设计师，一年后搭起了自己的 Agent 自动化系统，做出了百万月活的公益产品 AIHOT 并开源（约 9000 star），还花了 5 天给公司做了一轮 AI 化改造。这篇文章是他对自己近一年系统的一次完整拆解。
文章的引子来自 DeepSeek 的《Super-agent 设计探索》：
一个人通常只能同时跟进 3 到 5 个活跃的会话。单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
作者用朱元璋废丞相的故事做了类比：洪武十七年，八天收到 1660 件奏札、三千多件事，皇帝再勤政也顶不住，只能说出"朕一人处此多务，岂能一一周遍"。今天的 Agent 用户面对的是同一个结构性问题——所有任务的起点都是你，你不打开窗口，什么都不会发生。
他的解法不是"更努力地多开几个窗口"，而是把任务发生的起点从人身上拿掉，用信号触发 Agent；Agent 能自己处理的就处理掉，只有拿不准的才升级到人。他把这种能力称为领导力。
系统全貌
text
定时任务 / Webhook / 飞书 / GitHub / 邮件 / 告警
│ 统一事件格式
▼
┌───────────────────┐
│ 自动化中台 │ 规则匹配、去重、派单、留痕
│ （轻量服务器） │ rules.json
└───────────────────┘
│ 长轮询接单（≤50s）
┌───────────────┼───────────────┐
▼ ▼ ▼
Claude Code Codex(Sol) Codex(Terra)
主力开发 运维 / 审查 浏览器 / 电脑操控
│ │ │
└───────────────┴───────────────┘
│ 提交 PR 后交棒
▼
┌───────────────────┐
│ CI 中台 │ 审查→检查→合并→发布→核实
│ （本地 M4 Mac） │ 每个任务一台全新虚拟机
└───────────────────┘
│ 只有"必须拍板"的事
▼
飞书 AI 助理「小卡」→ 卡片 → 点击决策整条链路里，人只出现在最后一步。作者称之为批奏折。
模块一：自动化中台——所有事件的唯一入口
为什么需要中台
事件来源五花八门：飞书消息、机器人、邮件、系统告警、GitHub 事件、定时任务。如果每接一种事件就写一套脚本，接三五个还行，接到几十个一定会乱。所以作者自建了一个很小的独立服务，部署在一台轻量服务器上，专门管理事件触发、规则匹配和结果回收，后来把定时任务也统一纳入了。
统一事件格式
不管事件从哪来，进入中台时都被压成一条很短的消息，只含几样东西：
| 字段 | 作用 |
|---|---|
| 来源 | 哪个系统发来的 |
| 类型 | 如 feedback.new |
| 对象 | 涉及哪条记录 / 哪个项目 |
| 一句话摘要 | 足够人快速判断 |
| 回链 | 回到原会话或原始记录的地址 |
例如"虚实中台发来 feedback.new #12"，就是同事又提了一条新意见，编号 #12。格式统一之后，后面的规则匹配、去重、派单才有共同的判断基础。
rules.json：把"谁来做"写成配置
所有规则集中在一个 rules.json 里。作者以"同事意见"为例，描述的逻辑大致是：
- 对产品新意见、同事补充、以及已经拍过板的决定；
- 交给 M5 上的 Claude Code；
- 在项目代码目录里，用
hub-feedback这个 skill 处理； - 给 Agent 的指令只有一句：按 skill 里对应的那一节办；
- 每条意见单独开一轮，同一条意见同时只跑一轮，最多三条并发；
- 做完后只在需要人决策时才通知，否则不推送。
下面是按原文描述重建的示意结构，不是原文逐字：
json
{
"match": { "source": "hub-feedback", "type": "feedback.new" },
"executor": "claude-code@M5",
"model": "claude-opus-5.5",
"cwd": "~/code/hub",
"skill": "hub-feedback",
"instruction": "按 skill 对应章节处理；每条意见单独一轮，同一条同时只跑一轮，最多 3 条并发",
"notify": "decision-only"
}长轮询：不把家里的 Mac 暴露到公网
Webhook 能把消息推到中台，但中台推不到作者家里和办公室内网的 Mac。于是反过来做：每台 Mac 上跑一个接单程序，挂在 中台上等活，一次最长等 50 秒，有活立刻接走，没活就重新挂上。这样 Mac 不需要公网入口，延迟也接近实时推送。
中台带来的五个好处
- 接新事件变简单：不用写新脚本，在
rules.json加一条规则，几分钟生效。 - 换 Agent / 换模型变简单：哪类事交给谁只是规则里的一行字，出了更好的模型随时替换。
- 统一去重：网络抖动、同事补充说明、又贴一张图，都会产生重复事件；如果每条都叫醒 Agent，同一件事会有多个 Agent 同时改，必然冲突。中台统一去重。
- 单一出口：所有 Agent、所有任务要找人都只走"小卡"这一个入口，避免多个脚本、多个机器人把飞书刷屏。
- 数据沉淀：每件事何时来、从哪来、交给谁、结论是什么、是否需要人留意、后来怎么解决，全部留在中台数据库，还能跳回当时 Agent 干活的会话。哪条流水线最忙、哪个 Agent 干得最多、哪类事老出问题，一眼可见。
作者还做了一个可视化网页，把自动化流水线像种田游戏一样展示出来，并与现实时间和天气打通——现实下雪，自动化小镇也下雪。这是个人趣味，但也说明可观测性本身会反过来推动系统被维护。
模块二：Agent 执行——模型分工与本地部署
模型分工
作者的前提很现实：Token 不是无限的。即使开了 200 美元的 Claude 会员，猛用三天也能消耗近 90%。不同模型擅长的方向也不同，所以需要调度，追求整体性价比而不是单点最强。
| 模型 | 角色 | 主要工作 |
|---|---|---|
| Claude Opus 5.5 | 主力开发 | 自动化开发、复杂需求、需要主观能动性和决策的活；几个核心项目的大部分代码 |
| GPT-6.1 Sol | 运维 + 审查 | 告警、每日系统日报、到期复查；查 bug 并直接修；同时负责 PR 审查 |
| GPT-6.1 Terra | 浏览器 / 电脑操控 | 操控登录好各账号的 Chrome，抓没有 API、正常拿不到的数据（平台舆情、GEO 检查） |
有一条原则作者特别强调：做决策和做管理的模型，必须是智力和主动性最强的。"不能用笨逼来指挥聪明的"，否则会乱套。他自己日常主动触发的任务也都交给 Claude，而不是用更弱的模型去指挥强模型。
为什么坚持本地
作者有两台 Mac Mini：M5 Pro 是日常主力，M4 跑 Agent 自动化任务，两者通过局域网互通，基本都在本地，没有上云。原因有四条：
- 代码仓库、发布权限、飞书身份、登录好各种账号的 Chrome 全在这两台机器上；上云就要在每家云复制一份登录和权限，既麻烦又不安全。
- 很多国内服务在海外云端 Agent 上不可用，跨境访问北京的服务器经常慢和超时。
- 浏览器类任务尤其如此，微信等产品在云虚拟机浏览器里直接崩。
- 两台机器本来就是现成的，一直开着功耗也很低。
代价是本地机器成为单点，需要自己负责可用性、备份和物理安全。
Skill = 沉淀下来的 SOP
每个自动化任务基本都配一个专属 Skill。作者对 Skill 的理解很朴素：它就是沉淀给 Agent 用的 SOP，里面附带规则、参考资料和脚本。
例如每周日早上的"大扫除"定时任务，配的 Skill 写的是：把这一周合进来的屎山找出来删掉——同一件事写了两遍的、为个案打的补丁、停用了却没拆干净的、变成流水账的文档，能删的直接删掉，再上线。
好处是解耦：想改任务细节就改 Skill，不用改 Agent 执行本身的逻辑，清晰、可控、可管理。
模块三：CI 中台——Agent 的活到 PR 为止
为什么要自建
量太大了。仅 AIHOT 一个项目，2026 年 10 月就合入近 1000 个合并请求，平均一天二三十个，每个还要来回跑几遍检查。GitHub 自带 CI 即使开会员也只有每月 3000 分钟免费额度，按这个提交量，每月超额费用要 50 美元以上。
于是作者在闲置的 M4 Mac Mini 上自建了 CI 中台：机器现成、性能更强、在北京跑得比 GitHub 的机器快。作者也提示，如果有 Linux 机器做 CI 会更合适；ARM Mac 上是模拟环境，但对他够用。
五步流水线
关键边界：Agent 的活干到"提交代码、开 PR"就结束了，它自己不能上线。 后面全部交给 CI 中台。
| 步骤 | 做什么 | 关键约束 |
|---|---|---|
| 1. Agent 审查 | 每个 PR 合入前先过一遍 Codex（GPT-6.1 Sol）审查 | 只读、不能改、不能联网、读不到密钥；只报真会出错的问题，不报代码风格；最多审 3 轮 |
| 2. 检查 | 类型检查、全部测试、构建、数据库只能加不能改等硬规则 | 任一条不过就不能合；每个任务开一台全新虚拟机，跑完连机器带身份一起删 |
| 3. 合并 | 审查和检查都通过后由 GitHub 自动合并 | 两项规则写死在 GitHub 上，任何 Agent、任何工具都绕不过 |
| 4. 发布 | 合入主干后自动触发发布流程 | 派给 M4 上单独开的发布虚拟机 |
| 5. 核实 | 等发布流程跑完，再去线上确认当前版本已包含这次改动 | 确认真的上线后，把结果写回 GitHub，这一轮才结束 |
审查的规则与数据
作者借鉴了 Anthropic 的《How the Claude Code team does code review》：每个改动合并前都审，但最多审 3 次。早期也遇到过 Codex 无限挑错、审 10 轮还在磨叽的情况，所以把轮数上限写死。
审查规则同样重要：
- 审查者只读，不能改代码；
- 不能联网，不能读密钥；
- 只报真会出错的问题，不报"可以写得更好"的风格问题——否则能给你挑几十条，改到天荒地老。
作者给出的两周数据（四个项目）：
| 指标 | 数值 |
|---|---|
| 审查的 PR | 298 个 |
| Codex 报出的问题 | 333 条 |
| 合并前修掉 | 306 条 |
| 其中最严重一档 | 51 条 |
| 单次审查中位耗时 | 2 分多钟 |
| 审查占该任务 Token | 5%–15% |
| 从交代码到上线中位耗时 | 2–3 分钟 |
这套流程的核心不是"AI 审查一定比人强"，而是把验收变成不可绕过的流水线：写代码的模型和审代码的模型分开，审查、检查、发布各司其职，Agent 没有直接上线的权限。
模块四：在飞书上批奏折
能自动解决的都自动解决了，最后能推到人这里的，一定是需要决策或影响较大的事。
什么才配推到人面前
早期踩过坑，有时一天推几十条，严重消耗注意力。现在只保留几类必须由人拍板的决策：
- 删数据；
- 停服；
- 花钱；
- 对外发消息；
- 改产品方向；
- 新建或轮换密钥；
- 修改权限。
其余事情 Agent 全权做完上线。
票拟与批红
作者用明代政务做类比：奏章先交内阁，大学士把处理建议写在小票上贴在奏章上，叫票拟；皇帝看一眼，同意就用红笔批下去，叫批红。
他的飞书卡片就是 Agent 写的票拟：卡片里给出背景、建议动作和选项，人只需要点击；等在审批处的 Agent 收到决策后继续干活，卡片自己改成结论。例如某天晚上有人混进 AIHOT 的飞书群、移除了推送机器人后退群，这个此前未知的漏洞触发报错，进而触发整条自动化工作流，最终给他推了一张卡片。
决定台账
为了不重复打扰人，仓库里维护了两份文件：
- 「卡兹克定的事」：只记录本人亲口做出的决定，带原话和日期；
- 「定了不做的事」：记录被拒绝过的事情，Agent 以后再碰到直接照此回答，不再拿来问。
这本质上是把人的判断外化成可检索的策略，与 DeepSeek 把授权写成 Policy / Mandate 是同一个方向，只是个人版更轻。
唯一坚持手工的事：用户反馈
有一件事作者完全没有交给 Agent：用户反馈。每一条他都亲自看，把有价值的亲手复制给 Agent 去执行，解决后给对方邮箱发一封真诚的回信。
这既是质量控制，也是一种仪式感——系统可以接管流程，但不应该接管关系。
可复用的落地清单
作者反复强调这是非专业用户的个人探索，不是标准答案。但其中的顺序对普通用户很有参考价值：
| 阶段 | 最小动作 | 判断标准 |
|---|---|---|
| 1. 找事件 | 把重复工作改成定时任务或 Webhook | 事情能在你不打开窗口时发生 |
| 2. 建入口 | 所有事件先进入一个统一队列 / 中台 | 新增来源不用写新脚本 |
| 3. 写规则 | 用一份规则文件描述"什么事件交给谁、何时问人" | 换模型只改一行 |
| 4. 本地执行 | Agent 跑在自己的机器上，给最小权限 | 凭证不出内网 |
| 5. 自动验收 | 审查、测试、构建、发布都进流水线 | Agent 无法直接上线 |
| 6. 决策收口 | 只保留不可逆 / 高代价 / 对外的决策给人 | 每天打断次数可计量 |
| 7. 沉淀判断 | 建"定的事 / 不做的事"台账 | 同一个问题不问第二遍 |
| 8. 先观察再放开 | 新流程先只记录"本来会做什么" | 行为符合预期再执行 |
边界与风险
- 是个人经验，不是基准测试：文章没有对照组，收益主要来自作者自己的体感与业务结果。
- 模型与价格有时效性：文中出现的模型版本、会员价格、额度都只代表 2026 年 11 月前后的状态。
- Token 成本真实存在：200 美元档位猛用三天消耗近九成，自动化越密，成本越需要单独核算。
- 本地单点：两台 Mac 承担了执行、CI、凭证和浏览器身份，机器故障就是系统性故障。
- 权限面很大：登录态 Chrome、发布权限、飞书身份集中在一处，必须靠最小权限、只读审查、临时虚拟机等手段隔离。
- 品味依赖：什么该自动化、什么必须手工（例如用户反馈），高度依赖作者自己的判断，难以直接复制。
关联词条
- DeepSeek Super-agent：把人的注意力当作稀缺资源的 Agent 架构（concept）
- Harness（智能体执行框架）（concept）
- Loop Engineering：让 AI 自主闭环运转（pattern）
- Super-agent 专题总览