外观
苍何的 LobeHub Super-agent：主管分派、交接契约与验收证据
副标题：不自己造调度系统，而是在现成平台上组一支"1 个主管 + 6 个执行"的 AI 团队，把成败压在交接契约上。
一句话定义（本站归纳）：Super-agent 的门槛不在架构图，而在每一次派活时把话说全——目标、输入、可改范围、验收要求，缺一样后面就会断。
背景：自建多 Agent 的第一课
作者苍何（wesight.ai 创始人，前阿里工程师）这篇文章的起点，是读完 DeepSeek Harness 团队的《Super-agent 设计探索》之后的对照反思。
他自己早就试过一次。在 openclaw、hermes 那波热潮里，他动手搭过一套多 Agent 架构，但事后判断：那只是"简单的 multi agent"，没解决事件驱动和自主决策。
他举的例子很具体：
假设有一个搜集热点的 Agent，它把每日热点丢给 team agent，team agent 需要人来确认这些热点去做选题。当这些足够多的时候，人的精力就非常有限了，有时候搜集本身就会变得没意义。
问题不在 Agent 不够多，而在于链条的每一环还在等人。人成了信息筛选器和决策闸门，Agent 越多，闸门前的队列越长。
于是这次他换了路线：不自建调度系统，直接用现成平台。 他选的是 LobeHub（前身 LobeChat，2025 年从聊天工具转型为 Agent 平台，GitHub 80k+ star），并在上面搭了两套东西——一套给 LobeHub 自己的开源协作，一套给自己维护的 codexguide 网站。
团队是怎么组的
他让构建助手在 LobeHub 里建了一个"codexguide 产品研发群"：1 名主管 Agent + 6 名执行 Agent，角色、规则、流程一并配好。除了平台内的 Agent，他还接入了本机的 Codex 与 Claude Code，让这支团队能用上真实项目里的工具。
分工的依据不是"平均分配"，而是三个维度：职责、工具、执行环境。
| 角色 | 擅长什么 | 边界 |
|---|---|---|
| 主管 Agent | 判断该做什么、拆解、派单、协调阻塞 | 不亲自改代码 |
| 内容主编 | 对照官方资料审查仓库与线上页面，产出问题、证据、建议、验收标准 | 默认只读，需要改文件时转交 |
| Codex / Claude Code | 有开发环境，能改文件、跑命令、提 PR | 权限由本机环境与仓库授权决定 |
| Reviewer | 对具体代码版本独立复核 | 不复核"大概的方向"，只复核 commit |
这样安排的原因是：这一轮真正要判断的是"信息有没有过时、结论有没有来源、哪些页面值得先更新"，属于审查工作，所以先落到只读的主编身上；需要本地验证或改文件时，再交给有环境的执行者。
核心：派活时到底要交什么
这是全文最值得抄的部分。主管派活不是发一句话，而是给出一份可以独立执行的工作说明。
委派卡片上的五样东西
以修复 issue #48 为例，一张卡片里写清了：
- 目标仓库与基线 commit；
- 涉及文件；
- 主编检查到的问题（附官方资料链接）；
- 允许的范围——原文写的是"可以提交 PR，但不合并、不发布"；
- 验收要求。
作者把它总结成两个必须明确的问题：
这种交接需要明确两件事：执行者拿到哪些输入，以及这次可以做到哪一步。
第二点尤其容易被忽略。同样是"改文档"，允许改文件、允许 push、允许提 PR、允许合并、允许发布，是五个不同级别的授权，必须分别说清，而不是笼统地说"你去改一下"。
执行者开工前的前置检查
他的协作公约要求执行者动手前先做几件事：
- 读仓库的
AGENTS.md； - 检查
git status、当前分支和基线 commit； - 已有未提交修改要保留；
- 多人同时写代码时用独立 worktree 隔离，无法隔离就先串行。
交付时带回什么
- 文件修改摘要；
- 实际运行过的命令与结果；
- commit 与 PR 链接；
- 明确列出没跑过的测试、没验证的页面。
最后一条是全篇最实用的工程习惯：把"没验证"说出来，比假装验证过有用得多。
证据要落在能被接手的地方
Agent 团队的失败，很多时候不是做错，而是做完之后别人接不上。作者给出的四种产物，各有固定的落点：
| 产物 | 存在哪 | 怎么交接 |
|---|---|---|
| 审查报告 | Agent Documents 保存正文 | 任务评论挂链接，后续执行者先确认链接可读 |
| 修改建议 | 群聊委派卡片或任务说明 | 写清涉及文件、问题证据、改法、验收要求 |
| 代码变更 | Git 分支、commit、PR | 交付记录附链接和命令结果 |
| 复核结论 | 写回对应任务或交付记录 | 注明检查的 commit、发现的问题、未验证项 |
这里有一条他踩出来的经验，值得单独记住：
文件存好了、链接传过去了、接手的人能读到，是三个需要分别确认的环节。
实际发生了什么：内容主编打不开预期的巡检父文档，工具返回 Document not found 和 Parent not found。它把本轮报告暂存在自己的 Agent Documents，再把链接和阻塞原因写回任务评论——工作记录接住了，但预期的归档文档进度和索引并没有更新。主管随后要求：后续轮次先用任务评论保存检查进度、去重线索和未解决项，再尝试建立可用的归档位置。
另一处类似的：Lobe 助手尝试设置独立 Verify，写入后再查询显示 not configured，于是改配任务 Review（autoRetry=true、maxIterations=2）。作者特别注明——这属于配置交接记录，首轮并没有独立判定单，因此不能据此认定已经复核通过。
两件事指向同一条原则：配置成功 ≠ 生效，写入成功 ≠ 可读，交付完成 ≠ 验收通过。
验收的两层
- Reviewer 复核：针对具体版本，而不是"这次改动"。如果之后又提了新 commit，需要重新检查受影响的部分。
- Acceptance：把需求拆成检查项，附上实际产品的截图、录屏、日志，汇总成报告，让人逐项接受或提出修改意见（LobeHub 已把这项能力开源为 acceptance）。
这两层解决的是同一个问题：让"完成"这件事有可核对的证据，而不是一句"已经做完了"。
一次性委派，还是长期任务
这是文章里一个很清楚的判断标准：
| 工作的性质 | 用什么 | 例子 |
|---|---|---|
| 当前群聊里已经明确的工作 | 委派卡片直接交给某个成员 | 修复 issue #48 |
| 需要反复执行、跨天保留进度的工作 | 建独立 Task | 每日巡检 T-2，北京时间每天 9 点 |
| 需要管理依赖和复核轮次 | 优先放进可持续跟踪的任务 | 多轮修改、上游变化后要连带复查 |
他的每日巡检任务页里已经留有首轮、次轮的运行记录，主管、Lobe 助手与内容主编的交接评论都挂在下面；主编自己的页面里还留有"来源：任务"的执行话题。Task 承载"持续这件事"，话题承载"这一轮发生了什么"。
失败与异常怎么处理
协作公约里预先约定了三类情况：
- PR 被打回 / 依赖变化 / 执行失败：把失败原因和证据留在原任务，修复后提交新版本，再按新 commit 复核；
- 上游结论变化：重新检查受影响的下游工作，而不是只改被指出的那一处；
- 缺权限或需要扩大范围：先报告阻塞，由主管协调，或回来找人对齐。
注意最后一条的方向：权限不够时的正确动作是停下来报告，而不是自己想办法绕过去。
"主动"必须写成条件
LobeHub 支持消息事件触发：先按频道范围、关键词等规则筛选，再由模型结合 Agent 的职责判断是否要介入——比如群里有人报了一个缺陷，符合条件就触发后续处理。
但作者强调，"主动"不是一个形容词，而是四个必须回答的问题：
- 什么时候检查？
- 遇到什么情况介入？
- 可以处理到哪一步？
- 哪些地方需要回来找人确认？
条件不讲清楚，主动容易变成添乱；讲清楚了，每轮执行又都留了证据，才能逐步把持续跟进交给它。
这也是对"事件驱动"最落地的解释：事件驱动不是让 Agent 自己决定干什么，而是让触发条件、介入边界、上报时机被提前写死。
平台自举：LobeHub 用 LobeHub 开发 LobeHub
文章开头讲了一个很有说服力的例子。LobeHub 原本支持给任务单独指定模型，但只能在网页上操作；Agent 通过工具或命令行创建任务时缺这个入口——想让一个模型负责规划、另一个负责执行，就卡住了。
流程是这样走的：
text
主管 Agent「Nasa」查清问题
│ 创建任务 T-1149（现状 + 要补的入口 + 验收要求）
▼
执行 Agent「Dario」（基于 Claude Code）
│ 开发、测试，交付 PR #21852
▼
交付记录：修改说明 + 测试结果 + 验收报告 + 部署后仍需验证的部分PR 里明确关联了 T-1149，记录了 AI 参与实现、测试与验证的过程，并已合并。作者的评价很到位：
Agent 这次补上的，正是方便后续 Agent 分工执行的能力。
自己跑通自己的流程，再让流程帮自己跑得更快——这正是 DeepSeek 说的"持久"该有的样子。
它到底改变了什么
作者用一段对比收尾，这段值得完整保留：
- 过去：搜集热点 → 丢给团队 → 等人确认选题 → 人一忙，整条线停住；
- 现在：审查发现的问题接到了实际修改和 PR；担心内容过时就继续配置巡检；短视频调研报告做完了，还接着整理出可以直接安排选题和拍摄的手册。
那次抖音调研跑了一个小时：主管把任务拆成两条线（AI 工具/效率、AI 编程），创建子助理并行检索，最后汇总成对比报告，并进一步产出实战手册——分析结果和"下一步能动手做的事"一起交付。
单个 Agent 再强，困在单次对话里，工作就断在对话边界。有了主管分派和任务衔接，前一步的产物变成下一步的输入，任务才有机会自己往下滚。
他对这套系统的理解也跟着变了：一开始以为用 Agent 是"把自己替换掉"，后来发现不是——重复的、靠信息量驱动的执行可以交出去，剩下的是判断值不值得做、结果有没有达标、下一步往哪走。
能把 Agent 用好的人，核心能力可能不是"会写提示词"，是懂目标拆解，懂验收标准，懂推动迭代。这一套，本质上就是项目管理。只不过，你管的这个团队，全是 AI。
与另外两个样本对照
同一套结构，在三个不同资源条件下长出的三种形态：
| 维度 | DeepSeek（组织级） | 卡兹克（个人自建） | 苍何（个人用平台） |
|---|---|---|---|
| 调度系统 | 自研原型 | 自建自动化中台 | LobeHub 群组 + Task |
| 分工单位 | Router / Worker | 三个模型按专长分工 | 1 主管 + 6 执行 + Reviewer |
| 工作说明 | Ticket / Mandate | rules.json 规则 | 委派卡片 + 交接契约 |
| 权限表达 | 不可变 Mandate | 规则里的通知边界 | 五级授权分别声明 |
| 验收 | PR review + CI | 自建 CI 五步 | 独立 Reviewer + Acceptance |
| 找人的时机 | 注意力预算 | 只推不可逆决策 | 四个"主动"条件 |
苍何这个样本的独特价值在于：它证明了不写调度系统也能起步，但代价是每一处交接必须写清楚。 自建系统可以把契约写进代码强制约束，用平台则只能靠规则和纪律——所以他对"派活要说全"的强调，比前两个样本都更具体。
可复用的落地清单
- 先别写架构。 用现成平台组一个"1 主管 + 若干执行"的小团队，先跑通一次完整交接。
- 每个成员只给一个职责和一种环境。 只读审查的和能动文件的分开。
- 派活时说全五件事：目标、输入材料、可改范围、授权级别、验收要求。
- 交接五级授权分开讲：改文件 / push / 提 PR / 合并 / 发布。
- 交付带回证据：改了什么、跑了什么命令、commit 与 PR、哪些没验证。
- 复核针对 commit，不针对"那次改动"；有新提交就复查受影响部分。
- 一次性的事用委派，反复的事建 Task；跨天有进度就用任务评论承接。
- 区分"存好了 / 链接传过去了 / 对方读得到"，三段分别确认。
- 把"主动"写成四个条件：何时查、何情况介入、能做到哪一步、何时找人。
- 失败留在原任务里：原因、证据、新版本、按新 commit 复核。
边界与风险
- 平台能力决定上限：任务、群组、设备网关都由 LobeHub 提供，换平台等于重做一遍组织方式。
- 契约靠人守，不靠系统拦：规则写在协作公约里，执行者是否遵守、平台是否真正生效（例如 Verify 显示
not configured），需要逐项验证。 - 本地环境是真正的权限边界：能不能读写、能不能 push，最终取决于本机文件权限、CLI 限制和 Git/GitHub 授权，而不是 Agent 的自我声明。
- 证据链容易断在"可读性"上：文档找不到、父级不存在、链接失效，都会让下一轮从零开始。
- 仍有 1 小时级、需要人来判断的工作：报告能产出，但"哪些选题适合我"依然由人决定。
- 是个人实践，不是基准测试：文中未给出量化收益，结论主要来自作者自述。
关联词条
- DeepSeek Super-agent：把人的注意力当作稀缺资源的 Agent 架构（concept）—— 组织级设计与这套实践的源头
- 卡兹克的 Agent 系统（case-study）—— 自建中台路线的对照样本
- Harness（智能体执行框架）（concept）
- Loop Engineering：让 AI 自主闭环运转（pattern）
- Super-agent 专题总览