多Agent协作这个赛道,本栏目此前已经横评过一轮「编排层」——谁调度谁、怎么传递上下文。但把最近十天的素材榜数据摊开看,会发现编排器只是多故事的四分之一:真正的新面孔在回答一个更上层的问题——这些被调度起来的Agent,按什么隐喻组织起来?本期拆四个正在涨的仓库:Anthropic官方把Agent组织成一条业务链(commerce-agents),民间作者把Agent组织成一家公司(headcount),两位极客把Agent组织成异构模型流水线(fable-orchestrator与codex-astra-luna-orchestrator)。三种组织隐喻,三种成本结构,三种适用场景。全部星值取自本栏目每日素材榜的GitHub Search API快照(8月31日—9月11日),可复核。
先说清楚评分依据:本期四个对象,星值轨迹有每日快照支撑,属硬数据;但仓库内部SKILL.md未能逐文件实测,因此「设计质量」基于仓库公开描述与结构形态推断,「实战效果」以社区热度轨迹佐证为主。凡属推断,正文都会标出来。五星制,权重按本栏目惯例:功能完整度25%、设计质量25%、实战效果20%、上手难度15%、社区活跃度15%。
| 对象 | 定位 | 功能完整度 | 设计质量 | 实战效果 | 上手难度 | 社区活跃度 | 加权综合 |
|---|---|---|---|---|---|---|---|
| anthropics/commerce-agents | 官方业务蓝图 | ★★★★★ | ★★★★★ | ★★★★ | ★★★★ | ★★★★★ | 4.7 |
| cbrock84/headcount | 公司制Agent组织 | ★★★★ | ★★★★ | ★★★ | ★★★★ | ★★★ | 3.7 |
| donvito/codex-astra-luna-orchestrator | 双角色分诊 | ★★★ | ★★★★ | ★★★ | ★★★★ | ★★★★ | 3.6 |
| codejunkie99/fable-orchestrator | 三模型流水线 | ★★★★ | ★★★★ | ★★★ | ★★★ | ★★★ | 3.5 |
| 仓库 | 8/31 | 9/3 | 9/5 | 9/7 | 9/8 | 9/10 | 9/11 | 近期日均增星 |
|---|---|---|---|---|---|---|---|---|
| commerce-agents | — | 325 | 1927 | 2202 | 2491 | 2651 | 2732 | ≈134(9/5后企稳) |
| headcount | 783 | 1113 | 1244 | 1296 | 1320 | 1348 | — | ≈17(9/7后),峰值期曾达≈110 |
| fable-orchestrator | — | 329 | 466 | 547 | 572 | 594 | 599 | ≈34 |
| codex-astra-luna-orchestrator | — | — | — | — | — | 869 | 965 | ≥96(仅一天增量可见) |
两条曲线值得盯住:commerce-agents上架首两日冲了约1600星(日均800),随后回落到日均134但仍是最稳的高位平台;headcount则从日均110一路衰减到日均17,增速跌去八成半——这是本期最值得警惕的一条曲线,后面细说。
仓库描述一句话:「Reference blueprint for building shopping and merchant agents with Claude. Examples in retail, commerce…」。拆开看三个关键词。第一,reference blueprint(参考蓝图)——它不是装上就能用的单个技能,而是一套告诉你「购物侧Agent和商家侧Agent各自怎么写、怎么对接」的官方样板。第二,shopping与merchant两个词——官方没有把多Agent当成一个通用调度问题,而是按交易的两侧各建角色:一边替买家,一边替商家。第三,examples in retail——描述明确写了带示例,示例目录是官方仓库一贯的教学手法(本栏目拆官方pdf技能时讲过「三层渐进披露」,蓝图的examples承担的就是第三层的照抄入口)。
星值曲线佐证了官方身份的号召力:9月3日325星,9月5日进入素材榜「新上架」栏时已1927星,两天1600星的冲量在民间仓库里罕见;此后六天稳定在日均134星,9月11日2732星,是四件中唯一「冲高后不失速」的。短板也明确:蓝图要自己接线。它给你的是建筑图纸,不是精装房——想跑起来,你得自己准备商品数据、会话管理和部署环境,对只想「装个技能就生效」的新手,它的交付物偏重。Python仓库,适合拿它当架构课本来读,再决定哪些片段搬进自己的项目。
「An agent organization for Claude Code, structured as a company — 15+ departments, 125+ skills, each…」——素材榜描述在「each」处截断,按上下文推断(注意,此处是推断)应是「每个技能对应一个岗位」。这个隐喻设计得相当彻底:不是「一个主Agent带几个帮手」,而是部门制——15个以上部门、125个以上技能,技能粒度等于岗位粒度。你要它做的事,先在「公司」里找到对口部门,再由对口岗位的技能承接。
它是四件中星值基数最早起量的(8月31日已有783星,日均增星一度110),但也是曲线最令人担忧的:9月7日后日均增星衰减到17左右。一个诚实的解释是科层制的固有成本——真实公司都在砍层级,而headcount给你装了15个部门;当用户的任务只是「改个bug」时,穿过部门找岗位的组织开销反而高于直接派活。它的价值在「组织感」:给团队演示、给非技术干系人一个直观的心智模型,它是四件里最好的;给生产流水线降本增效,它是四件里最存疑的。评分表里「实战效果」只给三星,原因在此。
「Use Astra as orchestrator and Luna for subagents in Codex」——描述只有一句话,但信息密度不低:Astra当编排者,Luna当子代理,整个组织只有两级。与headcount的15部门相比,这是另一个极端:不建组织架构,只保留「分诊台→执行者」这一条最小通路。它跑在Codex里而非Claude Code里,这一点值得注意——多Agent组织隐喻已经开始跨harness复制,说明这套写法不绑定单一工具。
数据上它是当期增速最猛的:9月10日首次入榜即869星,9月11日965星,单日+96,在四件中排第一。短板同样来自极简:单一编排模式。所有任务都走「Astra拆解→Luna执行」一条路,没有第二档深度,遇到需要多角色协商的任务,它没有给出结构。功能完整度三星,就是这个意思。
「Fable 5.1 orchestrates. GPT-5.6 Luna and DeepSeek V4 Flash implement.」——这句描述是四种隐喻里最「工程」的一个:编排与执行不仅角色分离,模型也分离。Fable 5.1负责调度,GPT-5.6 Luna与DeepSeek V4 Flash负责干活,三种模型按职责分层。这个设计指向一个现实动机:编排消耗的是「判断力」,执行消耗的是「 tokens」,把贵模型用在刀刃上、把便宜模型用在量上——多Agent第一次成了成本结构工具,而不仅是能力工具。
一个有趣的真实观察:fable的描述里执行者是「GPT-5.6 Luna」,astra-luna的描述里子代理也叫「Luna」。两个不同作者的编排器是否选了同一个执行模型,仅凭素材榜描述无法确证,此处存疑标注。曲线方面,fable从9月3日329星爬到9月11日599星,八天+270,日均34,稳但不够陡。风险点在模型版本绑定:描述里写死了三个模型版本号,上游一升级,编排逻辑就得跟着改——这是把模型名写进SKILL.md的作者们共同的结构性风险。
把四件放在一起,能提炼出三条值得写进你自己SKILL.md的设计结论(此节为本栏目分析,非仓库原文):
第一,协作结构本身成了一等公民。 四件仓库没有一个在描述里谈「提示词技巧」,它们卖的都是结构: commerce-agents卖「交易两侧」的结构,headcount卖「部门-岗位」的结构,两个编排器卖「编排-执行」的结构。这意味着SKILL.md的写作重心正在从「怎么提示」上移到「怎么编组织」——先用一句话把组织隐喻说清楚,再谈任何细节。
第二,隐喻的粒度决定受众。 双角色(astra-luna)粒度最小,上手最快、增速最陡;三模型流水线(fable)粒度中等,多一层配置但换来成本分层;公司科层(headcount)粒度最大,组织感最强但增速失速——粒度与增速在这个样本里呈现明显的负相关。给新技能选组织粒度时,宁小勿大。
第三,业务隐喻比科层隐喻抗跌。 commerce-agents的隐喻(买家侧/商家侧)直接映射真实业务流,星值冲高后仍守住平台;headcount的隐喻(部门/岗位)映射的是组织形式而非业务价值,冲高后失速八成半。结论倾向:让结构跟着业务流走,别跟着组织架构图走。
flowchart TB
Q["多Agent协作的三种组织隐喻"] --> R1["业务蓝图:官方路线"]
Q --> R2["公司科层:民间路线"]
Q --> R3["模型分工:极客路线"]
R1 --> CA["anthropics-commerce-agents"]
R2 --> HC["cbrock84-headcount"]
R3 --> FB["codejunkie99-fable-orchestrator"]
R3 --> AL["donvito-codex-astra-luna"]
CA --> CA1["买家侧与商家侧成对建角色"]
HC --> HC1["15部门125技能岗位制"]
FB --> FB1["三种模型按职责分层"]
AL --> AL1["编排者与子代理两级"]
flowchart TD
S["你的多Agent要解决什么"] --> T["跑通一条真实业务流程"]
S --> U["给团队一个直观的组织感"]
S --> V["大量子任务要控制成本"]
T --> T1["选commerce-agents当蓝本"]
U --> U1["选headcount当演示组织"]
V --> V1["选fable或astra-luna做分工"]
四个仓库均可通过 Skills CLI 或直接克隆取用(参数名以 skills.sh 各仓库页面为准):
# 官方业务蓝图
npx skills add anthropics/commerce-agents
git clone https://github.com/anthropics/commerce-agents
# 公司制组织
npx skills add cbrock84/headcount
git clone https://github.com/cbrock84/headcount
# 三模型流水线
npx skills add codejunkie99/fable-orchestrator
git clone https://github.com/codejunkie99/fable-orchestrator
# 双角色分诊(Codex侧)
npx skills add donvito/codex-astra-luna-orchestrator
git clone https://github.com/donvito/codex-astra-luna-orchestrator
# 先查再装
npx skills find orchestrator
一句话收束:编排层解决「谁干活」,组织隐喻决定「像什么」——而数据显示,像业务的比像公司的活得久。下期若继续这条线,值得盯的是这些隐喻会不会出现第五种:把组织结构外包给外部系统(数据库、看板、聊天记录)而非写死在SKILL.md里。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
