P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程传送门http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。

前言

先说个画面。

周三上午十点，我桌面上开着八个窗口。第一个在等我确认选题，第二个在等我回一段代码，第三个卡在一半问我“要继续吗”，第四个是我自己忘了关的。

我以为我在并行，其实我在挨个儿道歉。

那一刻我想明白一件事：Agent 变强了，我的注意力没变强。模型从“能聊”进化到“能干活”，而我还是那个一个脑子、两只手、一杯凉了的美式的人。

所以“让一群 Agent 一起干活”这件事，卡住的地方从来不在模型，在我。

1. 一个对话窗口，就是一间隔间

1.1 我以为我在并行，其实我在挨个道歉

单聊的本质是：一次一件事，说完就断。

切到新对话，我得把上下文重新讲一遍。讲第一遍还行，讲第三遍我开始自动精简，像在给不同亲戚解释我的工作——对大姨讲版本，对二舅讲赚钱，对我妈讲“反正挺好的”。

同时开的会话一多，我的注意力就开始做负载均衡，最后均衡到零。

我甚至给自己找过理由：这叫多线程。

不，这叫多任务卡顿，还带内存泄漏。

1.2 我真正想要的，是一个“一直在”的东西

后来我发现，我需要的不是更聪明的回答，是一个能持续看着、能自己接手的角色。

它得知道昨天干到哪儿了。它得在旁边盯着信息流，有事就动，没事就待着。它最好还能在我睡着的时候接着跑。

我管这个东西叫“办公室那个永远都在的同事”。你去接水，他在；你下班，他还在；第二天你一来，他说“昨天那事儿我处理了”。

现实里这种人一般会升职。现实里我也没有这种同事。

2. 这套系统到底“Super”在哪

2.1 一群 Worker，各带各的记忆

它的核心不是一个大模型，是一群小执行者。

具体工作由多个 Worker 并行做，每个保留独立上下文，按需连真实的工具环境。

这句话翻译成人话：一个人干一件事，脑子里只装这件事，不互相污染。

这点在我家是做不到的。我妈一句话能同时打断三个人，而且三个人都被打断了。

2.2 少绕一圈的通道

已有任务的后续消息，可以沿着订阅通道直接送到对应的 Worker，不用再绕一遍 Router。

这就是公司里那个不经过三层审批的直通电话。效率高得让人不适应，第一天用还会怀疑是不是自己越级了。

2.3 一个记账的，一个喊人的

底下的数据库保存会话状态。翻译一下：谁干到哪儿了，有记录。

这一点已经比很多团队强了。我待过的地方，进度只存在于某个人的脑子里，那个人一请假，项目就地失忆。

外面的 Watchdog 监控异常和执行进展。它不干活，只负责出事的时候喊人。

公司里这个角色一般叫项目经理。

2.4 四个词，我一个都没有

这套东西配合起来，让系统有条件同时接活、持续执行，出问题还能恢复。

总结成四个词：连续、高效、主动、持久。

我念完之后默默看了眼自己的待办清单。四个词，一个都不沾。我的状态是：断断续续、勉强够用、被动等催、撑到周五。

3. 我自建过一套，架构图特别漂亮

3.1 三层架构、五个角色、七条通道

在 openclaw 和 hermes 火的时候，我也动手搭过。

三层架构、五个角色、七条消息通道。图很好看，配色我调了四十分钟，发出去能收二十个赞。

跑起来第二天，我发现五个角色里有四个在等我。

第五个在等我确认它能不能等。

3.2 热点 Agent 打卡，我在等人批

举一个最好懂的例子。

我有个搜集热点的 Agent，每天很勤快，搜六十条丢进群里，然后它下班了。

接下来是我：一条条看，挑能用的，判断值不值得做。批到第八条的时候，第一条已经过时了。第六十条我压根没打开。

所以那套系统最大的成果，是把“信息过载”从“我一个人扛”升级成了“我们一群人围观信息过载”。

它不是不聪明。它是不会自己决定。所有决策都要回到我这儿签字。

我是唯一的审批人，也是唯一的瓶颈，还是唯一那个半夜还在想选题的人。

4. 后来我把活儿外包了

4.1 一个老项目，长成了平台

LobeHub 算比较早期的 AI 开源项目，原名 LobeChat。最早一批玩 GPT 的人基本都碰过。

2025 年改名 LobeHub，从聊天工具变成了 Agent 平台。现在八十多 k star。

我第一次用 LobeChat 的时候它还没这么红，用完还提了个 issue。那个 issue现在大概已经被这八十多 k 人埋了。

4.2 他们用自己，开发自己

更值得注意的是：他们已经在用 LobeHub 持续开发和迭代 LobeHub 本身。

自己吃自己做的饭，还越吃越壮。

有个具体案例。LobeHub 原本支持给任务单独指定模型，但只能在网页上点。Agent 通过工具或命令行创建任务时没这个入口，于是“一个模型负责规划、另一个模型负责执行”就卡住了。

主管 Agent Nasa 查清问题，建了 T-1149，把它分派给基于 Claude Code 的执行 Agent Dario。

一个叫 Nasa，一个叫 Dario。一个像要上天，一个像在地上拽绳子。

任务里写清了现状、要补的入口、验收要求。Dario 接手后继续开发，最后交付 PR #21852，给内置任务工具和命令行补上了指定模型的能力。

交付记录里附了修改说明、测试结果、验收报告，也老实写了需要部署后继续验证的部分。

“需要部署后继续验证”，这句话翻过来就是“我这边跑通了，线上我不敢保证”。我很喜欢这种诚实。比“应该没问题”强一百倍。

PR 里明确关联了 T-1149，记录了 AI 参与实现、测试、验证的过程。目前这条 PR 已经合并。

也就是说，这条链是真走完了，不是在演示视频里走完了。

4.3 最妙的一笔

Agent 这次补上的能力，正好是方便后面 Agent 分工执行的能力。

有点像新来的实习生，第一天上班先把会议室的投影修好了。

你不知道该夸他懂事，还是该怀疑他早就想开这个会。

5. 我拉了一个群：1 个主管，6 个执行

5.1 先把规矩写死，再开工

我最近也在自己的活儿里试了类似的协作，具体是更新我的 Codeguide 网站。

我先把想要的分工和协作方式告诉构建助手，让它帮我搭了一个“codexguide 产品研发群”。

群里 1 名主管 Agent，6 名执行 Agent，角色、规则、流程一起配好。

这个群有几个特点：没有闲聊，没有“收到”，没人在群里发早安图，也没人凌晨两点发一句“在吗”。

效率高得有点冷清。

5.2 云端负责想，本地负责动

除了 LobeHub 自己的 Agent，我还接入了本地的 Codex 和 Claude Code，让这支团队能用上实际项目里的工具。

怎么接的？我看过它的开源实现。以 CLI 连接为例：

lh connect
# 连接设备网关
# 收到执行请求后，在本机启动对应的 Agent 运行流程
# 请求里带：Agent 类型 / 工作目录 / 提示词 / 话题标识

所以云端分派的工作，能落到具体某台机器、某个目录上。

这个分工很像我和我的健身卡：一个负责制定计划，一个负责躺在家里的抽屉里。

所以接入前有两件事要先办：本机 CLI 能正常用；通过桌面端或 CLI 连接器把设备接上，给执行成员配好环境和工作目录。

能读文件、能跑命令、能推代码，还取决于本机文件权限、CLI 执行限制，以及 Git、GitHub 的登录授权状态。

工具接通了不等于权限到位。这个道理我在公司 VPN 上已经学过很多次了。

5.3 第一棒为什么给内容主编

我让它对全站内容做审查，给出更新优先级。

主管先把审查交给内容主编：对照官方资料检查代码仓库和线上页面，整理问题证据、修改建议、验收标准。

为什么先给主编？因为这轮要判断的不是“怎么改”，是“哪儿已经过期了”。

我给主编设定的是默认只读。

这个设定很关键。一个能直接改文件的审查员，最后一定会把审查做成修改。等他改完了，你就永远不知道原来错在哪。

要本地验证或者动文件，再交给有开发环境的 Codex、Claude Code，另外安排 Reviewer 独立复核。

分活的依据不是谁聪明，是职责、工具、执行环境。

主编交出报告，里面有发现的问题、对应证据、修改建议和排期。每条都带来源，我能顺着链接一项项点开。

平时我核对的是同事那句“我记得是这样的”，现在至少有个能点开的链接。这个体验挺新鲜。

5.4 一张能独立执行的委派卡

具体怎么派，看一次修 #48 的记录。

主管让 Codex 改第三方 API 鉴权文档并提 PR，之后交 Reviewer 复核；另外两个 issue 由主管自己处理。

这次没开群组的 Task 记录，委派过程以卡片形式留在群聊消息流里。展开之后，长这样：

目标仓库: codexguide
基线 commit: a1b2c3d
涉及文件: docs/auth/api-key.md
问题证据: 主编审查报告 R-11-03
官方资料: platform.openai.com/docs/...
边界: 可以提交 PR / 不合并 / 不发布

这张卡其实是一份需求文档。目标、输入、范围、验收，一次说清。

在我待过的公司，凑齐这四样通常要开三次会，还得有一个人在会后补纪要约时间。

“可以提 PR，但不合并、不发布”，这个边界写得很克制。翻译成人话：你可以干活，但别说这事儿成了。

这种交接必须讲清两件事：执行者拿到哪些输入，这次能做到哪一步。

审查意见只能当线索。涉及鉴权这种技术细节，Codex 还得回查官方文档和当前仓库，自己确认建议成立不成立。

不能因为“主编说的”就直接改。这条对 AI 有效，对人更有效。

5.5 开工前的三条起手式

我在协作规则里写死了：执行者开工前先读 AGENTS.md，看 git status、当前分支、基线 commit。

有未提交的修改必须保留。多人同时写代码用独立 worktree 隔离，隔离不了就串行。

cat AGENTS.md
git status
git branch --show-current && git rev-parse HEAD
git worktree add ../wt-fix48 -b fix/48-auth-doc

翻译一下：先看看地上有没有别人的东西，别一屁股坐上去。

很多人不是不会写代码，是不看现场。上来就改，改完发现改的是别人昨天要提交的那版。

允许改文件、允许 push、允许提 PR、允许合并发布，这四件事我分开写。

因为它们是四个不同的权限，不是一种“你看着办”。

规则是给执行者守的，实际能到什么程度，还是本机权限和服务端说了算。

5.6 交付要带证据

我对交付的要求很硬：

- 文件修改摘要
- 实际跑过的命令 + 输出
- commit 链接
- PR 链接
- 没跑过的测试、没验证的页面（必须写出来）

最后一条最狠，也最有用。它把“我觉得没问题”挡在门外。

“我觉得没问题”这句话，我在评审会上听过太多次。通常下一句是“应该不会有影响”。

然后是线上告警。

6. 复核：别让“我看过了”进交付

6.1 只看具体 commit

Reviewer 要复核具体版本。如果后面又推了新 commit，得检查受影响的部分。

不然就会出现经典的三角关系：你验的是 A，上线的是 B，出事的是 C。

我第一次遇到这种情况时还试图解释。后来学会了，只问一句：你验的是哪个 commit。

6.2 把口头验收变成检查项

还有另一种验收方式，Acceptance：把需求拆成检查项，附上实际产品的截图、录屏、日志，汇总成报告，让人逐项接受或者提意见。

这套东西更像人话。因为“你看一下”不是验收，“检查项 1 通过，检查项 3 不通过”才是。

我这轮群组规则里，先要求 Reviewer 对具体代码版本独立复核；需要看页面表现时，再把截图、录屏这些证据一并纳入。

证据不是给谁面子，是给将来的自己留个解释的机会。

7. 把一次性检查，改成每天九点的闹钟

7.1 这一轮审查暴露的真问题

网站最大的问题不是代码，是时效性。

官网出了新消息，我忙起来没同步，网站的信息就慢一拍。

这跟我的知识库一个毛病：永远比世界晚两周，而且我还觉得挺新。

这次把已有问题改好了，后面有更新，还是得有人持续跟。

所以我让它加了自动巡检，把这次检查变成定期任务。

主管分析需求后，把内容比对交给内容主编，把定时巡检交给 Lobe 助手。

7.2 委派和 Task 的分界线

这也是我后来想明白的一条线：

当前群聊里已经明确的工作，用委派卡片交给对应 Agent 就行。

像每天巡检这种要反复执行、跨天保留进度的，更适合建成独立的 Task。

后面依赖多、复核轮次多的活，我也优先塞进可持续跟踪的任务里。

判断标准很简单：这件事要不要“明天接着昨天的”。要，就建 Task；不要，就派卡片。

7.3 一个每天九点上班的同事

这项每日巡检被建成了独立的 T-2，设定在北京时间每天 9 点执行。

"task": "T-2"
"title": "codexguide 内容每日巡检"
"schedule": "0 9 * * *"
"timezone": "Asia/Shanghai"
"inputs": ["官方更新源", "仓库 docs", "线上页面"]
"output": "审查报告 + 更新优先级"
"permission": "只读；改动需另行委派"

它比我上班准时。

我也给自己设了 9 点的闹钟。它每天 9 点开始检查，我每天 9 点把闹钟按掉。同一个时间，两种文明。

任务页里已经有首轮和第二轮的运行记录，主管、Lobe 助手、内容主编的交接评论都留在下面。

从内容主编自己的页面，还能找到“来源：任务”的执行话题。

Task 承载持续巡检，每一轮执行有自己独立的话题记录。一次话题归档，后续照计划继续。

这个设计很像值班表。班次是固定的，值班记录是每天新写的。

7.4 文件存好了、链接发出去了、人能不能读到

这里撞上一个真问题。

有一轮，内容主编打不开预期的巡检父文档，工具返回 Document not found、Parent not found。

它没崩。它把本轮报告先存在自己的 Agent Documents，再把链接和阻塞原因写回任务评论。

我先给它鼓个掌——至少它知道先保住作业本。

但这事也暴露了一个真相：文件存好了、链接传过去了、接手的人能读到，是三件不同的事。

我发了十年文档，到现在还在被这三件事轮流教育。

主管随后要求，后面几轮先用任务评论保存检查进度、去重线索、未解决项，再试着建一个可用的归档位置。

这能先把工作接住。但另一个 Agent 到底读不读得到报告，还得实际打开验证。

“我发了”不等于“你收到了”。“你收到了”不等于“你打开了”。“你打开了”不等于“你看懂了”。

这三句话我建议做成工位贴纸。

8. 那些“配置成功”的瞬间，通常不是成功

8.1 写了 Verify，查出来 not configured

还有一次更典型。记录里，Lobe 助手尝试设置独立 Verify，写入之后再查，显示 not configured。

它很冷静地转去配任务 Review：

Verify: 设置 → 查询 → not configured
Review: autoRetry = true
Review: maxIterations = 2

翻译一下：验不了就重试，最多两次。

这很像我在健身房办卡时的自我安慰——先办，来不来再说。

8.2 配置记录不是验收单

这些是配置交接记录。首轮还没有独立判定单，所以不能据此认定已经复核通过。

这个区别很重要，重要到很多人一辈子没搞清。

写下“已开启检查”，不等于检查过了。写下“已配置复核”，不等于复核通过了。

我见过太多周报：动作写得很足，结果一个字没有。

9. 出问题的时候，规矩比聪明有用

PR 被打回、依赖变了、执行失败，这几种我在协作公约里都写了处理方式：

失败        → 原因 + 证据留在原任务
修复        → 提交新版本 → 按新 commit 复核
上游结论变  → 重查受影响的下游工作
缺权限/扩范围 → 先报阻塞，再找主管或我确认

公约的价值不在写得多好，在于出事的时候不用现想。

人一慌就开始讲道理。讲完道理天亮了，问题还在那儿，而且还多了一个“我们复盘一下”。

LobeHub 还支持由消息事件触发工作：先按频道范围、关键词筛，再由模型结合 Agent 职责判断要不要介入。

比如群里有人反馈了个缺陷，条件符合就能触发后续处理。

所以“主动”这个词，得先把条件说清楚：什么时候检查，遇到什么情况介入，能处理到哪一步，哪些地方必须回来找人。

不讲条件的主动叫添乱。我妈就特别主动。

10. 让它自己去搬砖

10.1 去 X 上找别人的用法

除了跟进官方更新，我还想给网站补一些实际案例，就让它去 X 上找值得参考的 Codex 用法。

它检索后整理了一批案例，逐个给了推荐理由，方便我判断哪些值得进一步研究。

它还翻到一个我好久之前提的 issue，在里面做了详细回复。

这一步对我真正有用的地方，是判断依据和后续建议都留在原来的问题下面。

以后再处理这个 issue，我能顺着记录确认进展。

不像我，很多想法留在微信收藏里，然后再也没打开过。我的收藏夹是一座只有入口没有出口的博物馆。

10.2 抖音选题：两条线一起跑

短视频的选题调研，我也交出去了。

我让它分析抖音上 AI 工具、AI 效率、AI 编程相关的作品，看看哪些做法值得借鉴，再结合评论区整理用户的真实需求。

接到任务后，它把调研拆成两条线，各建一个子助理，并行跑：一条查 AI 工具与效率，一条查 AI 编程。

执行过程中，右侧面板会显示当前任务和资源占用，还能看本机 CPU、内存、磁盘。

我第一次知道我的电脑在替我加班。它没有加班费，也没有怨言，只是风扇开始唱歌。

想细看就点开子助理，能看到执行过程和输出。

10.3 一小时，一份报告加一本手册

两条线跑完，它把结果汇成一份分析报告：比较账号体量、视频数据，也分析内容深度、标题和评论反馈。

再往下，梳理每条视频的内容类型、可能的传播因素、值得借鉴的做法，以及评论区透出的需求信号，最后给出选题策略、推荐结构和需要避开的坑。

不只如此，它还整理了一本实战手册：从账号冷启动、能直接上手的选题，到脚本撰写、不同类型视频的拍摄和复盘。

整个任务大约跑了一小时。

以前我拿到这种分析，会给它在收藏夹里办一场体面的葬礼。这次它直接接到了下一步，我不用再“回头再整理”。

“回头再整理”是我人生最大的一个项目，一直在延期，且没有预算。

10.4 微信里丢一句话就开始干活

交办入口也不一定非得是后台。

我把它接进了微信。我在微信里说一句：找一下最近一周用 opus 5.5 做视频的优秀案例。

它分配子代理，开始搜。

这是最舒服的一点：想到什么就地交办。不用开电脑，不用切窗口，不用先说服自己“等会儿再弄”。

“等会儿”这个词，毁掉的项目比我见过的所有 bug 都多。

11. 我改掉的三个认知

11.1 不是替换我，是把我捞出来

用了这段时间，我对 Agent 的理解变了。

一开始我总以为，用 Agent 就是把自己“替换”掉。后来发现根本不是。

重复的、靠信息量堆出来的执行，确实可以交出去。

剩下的是更需要我的部分：判断值不值得做，结果达不达标，下一步往哪走。

说得再直白点：搬箱子的人没了，签收的人还得在。

而且签收比搬箱子难。搬箱子只要力气，签收要眼力，还要敢说“这箱不对”。

11.2 核心不是会写提示词

我越来越觉得，能把 Agent 用好的人，核心能力可能不是“会写提示词”。

是懂目标拆解，懂验收标准，懂推着迭代。

这三件事，换成任何一份工作描述，都长得很眼熟。

因为这套东西有个更朴素的名字：项目管理。

唯一的区别是，你带的这个团队，不用订团建餐，不用处理谁跟谁不对付，也不会有人在群里发六十秒语音。

11.3 前一步的产物，变成下一步的输入

这一整套跑下来，我感受最深的是：前一步做完，工作有机会接着往下走。

审查发现的问题，接到了实际修改和 PR；担心内容过期，就配了巡检；调研做完，又长出一本可以拿去安排拍摄的手册。

单个 Agent 再强，困在单次对话里，工作就断在对话的边界。

有了主管分派和任务衔接，前一步的产物变成下一步的输入，任务才有机会自己往下滚。

回头看我最早自建的那套多 Agent 架构，其实卡在同一个地方。

搜集热点的 Agent 把结果丢给团队，等人确认选题。人一忙，整条线就停了。

没有事件驱动，没有自主决策，人就是瓶颈，而且还自带加班。

现在我能把更多注意力放在目标和结果上：哪些内容值得更新，哪些选题适合我，交付有没有达标。

当然，这些判断还得自己做。

任务开始前把目标、范围、验收要求讲清楚；结果交回来，顺着证据检查，提出具体的修改意见。

这套流程听起来很行政。但它救过我好几次，尤其是在我特别想点“就这样吧”的时候。

12. 最后说一句

单个 Agent 是把好刀。一群 Agent 是一间厨房。

刀再快，没人配菜、没人看火、没人尝咸淡，最后端出来的还是一盘焦的。

我现在更在意的，不是让某一个 Agent 更聪明，是让这一群能接上手。

你也在搭自己的那套吗？

评论区说说，你现在卡在哪个环节——是模型不够强，还是发现自己成了瓶颈。

如果是后者，别急。那说明方向对了，只是你还没把自己从执行里捞出来。

如果这篇让你少开两个窗口，点个赞。

要是你明天还是开了八个，也没关系，我们这种人，先从关掉第四个开始。

P.S. 目前国内还是很缺AI人才的，希望更多人能真正加入到AI行业，共同促进行业进步，增强我国的AI竞争力。想要系统学习AI知识的朋友可以看看我精心打磨的教程 传送门http://blog.csdn.net/jiangjunshow，教程通俗易懂，高中生都能看懂，还有各种段子风趣幽默，从深度学习基础原理到各领域实战应用都有讲解，我22年的AI积累全在里面了。注意，教程仅限真正想入门AI的朋友，否则看看零散的博文就够了。