Agent 生态对比：技能包与子代理

本页读什么？

近年 AI 编程助手生态里，「技能包 / 斜杠命令」和「子代理 / 团队」经常被混在一起讨论。这里把同一问题下的不同解法拆开写清楚：前者多是 Markdown 与工作流纪律，后者是上下文隔离与协作拓扑。下文表格与要点均来自列出的原文，便于你核对与延伸阅读。

📚 参考来源

下列为原文链接。本页为学习笔记式整理，不替代原文；引用处观点版权归各作者所有。

知乎专栏

中文社区长文（需在浏览器登录或打开知乎查看正文）。

打开知乎专栏 →

Particula Tech

Superpowers vs GStack: Which AI Coding Skill Pack Actually Works?（2026-03）

阅读原文 →

Daily Dose of Data Science

Claude Subagents vs. Agent Teams（Avi Chawla，2026-03）

阅读原文 →

一、技能包与工作流：Superpowers vs GStack

两者都针对同一类痛点：智能体跳过规划、跳过测试、写出「看起来对」但在生产环境出问题的代码；但治理方式几乎相反。

Superpowers：用流程强制约束

强调刚性多阶段管线（头脑风暴、Git worktree、写计划、子代理执行、TDD、代码审查、收尾），在写代码前完成设计与验证。
「1% 规则」：只要技能可能适用就必须触发；技能里用「红旗」话术抵消模型常见的偷懒借口。
子代理按任务隔离执行 + 多阶段审查；新版本侧重可视化头脑风暴、按界面驱动拆分文件结构、实现任务可路由到更便宜模型等。
代价：正式编码前常有十余分钟量级的规划开销；长会话、多子代理时 token 消耗显著。

GStack：用角色与斜杠命令模拟「虚拟团队」

大量可手动调用的斜杠命令，覆盖产品/CEO 视角、工程评审、设计评审、Staff 级代码审查、调查、QA、安全（OWASP + STRIDE）、发布与复盘等。
特色是持久化 Chromium + Playwright 的分层架构，可做真实截图与点击级 UI 验证（对 Web 项目价值大；部分凭据能力曾侧重 macOS）。
TDD 可用但未像 Superpowers 那样「写测试前写的代码要删掉」式强制；更适合希望按需调用、覆盖从想法到 ship 全链路的人。

对照表（摘自 Particula 文章维度）

维度	Superpowers	GStack
哲学	流程强制，单一管线、少捷径	角色专精，按需叫「专家」
触发方式	技能自动触发为主	用户主动输入斜杠命令
TDD	强制 RED-GREEN-REFACTOR	有 `/qa` 等，非强制
视觉 / UI 验证	v5 起有浏览器侧 mockup 等	持久 headless 浏览器 + 真实交互
子代理	一等公民（每任务干净上下文）	非核心卖点
更适合	复杂变更、测试与质量硬约束	产品思考 + 全 sprint + 可视化 QA + 发布自动化

实践中常见组合：用 GStack 做产品范围与架构锁定与 UI/安全验证，用 Superpowers 管实现与 TDD 纪律。

二、平台范式：Subagents vs Agent Teams

问题不应默认成「要不要多智能体」，而是「任务需要哪种协调方式」。Claude 生态里两条路径差异很大。

Subagents（子代理）：隔离与压缩

独立上下文、独立系统提示与工具集；完成单一任务后，通常只把汇总结果回传给父代理，不把完整推理链塞进主会话。
价值不仅是并行，更是上下文压缩：大量探索在子窗口完成，主窗口保持干净。
硬约束：子代理不能再 spawn 子代理，彼此不直连对话；父节点是唯一协调者，行为可预测。
适用：可 embarrassingly parallel 的检索、代码库探索、互不依赖的分析条线。

Agent Teams（智能体团队）：协作与共享状态

长生命周期的多个代理实例，可点对点通信，通过共享任务列表（含依赖如 blockedBy）做真实协调。
前端与后端代理可直接协商接口变更，而不必事事经 lead 转发。
适用：工作中途发现会改变其他线程方向的场景，需要持续协商而非一次性交付摘要。

一句话对照

	Subagents	Agent Teams
协作模型	发任务 → 收结果（fire-and-forget）	持续对话与共享任务状态
信息路径	仅回流到父代理	同伴之间可直接同步
典型用途	并行研究、探索、独立子问题	需协商、依赖链复杂的联调

设计原则（摘自 Daily Dose 文章）

按上下文边界拆任务，而不是按组织角色硬拆；否则会在 handoff 处丢信息。
五种常见编排：顺序链、路由（分类器选处理器）、并行、编排器-工作者、评估-优化循环。
先单代理推到极限，再为可度量的痛点加多代理；编码场景慎用多个代理同时写代码，易隐含冲突。

Repo-backed 补充：三种团队运行时壳

这一节不是再讲抽象概念，而是用本地 reference 把三种更具体的运行时壳摆在一起：reference/reference_agent/feynman/、reference/reference_agent/ChatDev/、reference/reference_agent/multica/。

feynman 更像 research-agent CLI shell：单入口 CLI + bundled research agents + bundled skills，重点在研究工作流与产物生成。
ChatDev 2.0 更像 workflow-orchestration shell：用零代码配置 agent / workflow / task，再配 Web Console 承接更长的多代理编排。
Multica 更像 managed-agent platform shell：围绕 board、workspace、runtime、daemon、agent profile 和 issue assignment 管完整生命周期。

这三者对读者有个直接帮助：看到 "Agent Teams" 时，不要只想成一个概念词，而要继续追问它到底更偏哪种壳层。

运行时壳	这轮本地样例	更像解决什么问题	为什么值得和 Subagents / Teams 一起看
research-agent CLI shell	`feynman`	用单入口 CLI 把 research、review、draft、audit 这些多代理研究动作压成一套可直接调用的研究终端。	它说明多代理不一定先长成"团队平台"，也可以先长成强工作流的研究壳。
workflow-orchestration shell	`ChatDev 2.0`	用零代码配置 agent、workflow、task，让用户搭配不同多代理流程并在 Web Console 里执行。	它说明 Agent Teams 还可以进一步抽象成"编排平台"，不再只是固定角色聊天。
managed-agent platform shell	`Multica`	把 agent 当长期 teammate，围绕 board、runtime、daemon、workspace 和 issue assignment 管完整生命周期。	它说明团队协作真正变厚时，难点会转成 runtime 管理、任务分发和状态可视化，而不是 prompt 本身。

如果再往前收一层，可以直接看它们各自默认的协调方式：

feynman 更像 一个主入口替你调度多个研究角色，协作结果尽量收束到单条研究终端与产物目录里。
ChatDev 2.0 更像 把代理之间的协作关系写成 workflow，重点是可配置编排，而不是长期 team board。
Multica 更像 把代理当长期成员持续接任务，重点是 runtime、issue、comment、status 和 daemon 组成的队友生命周期。

还要防一个常见误读：ChatDev 2.0 已经不是早期那种"CEO / CTO / Programmer"角色扮演式虚拟软件公司主叙事了。按本地 `reference/reference_agent/ChatDev/README.md`，它在 2026-01-07 明确转向了 Zero-Code Multi-Agent Platform，重点变成用户自己配置 agent / workflow / task。换句话说，今天再拿 ChatDev 举例，教学重点应该放在编排壳，而不是只记住那套经典角色剧本。

这会帮助读者把 "Agent Teams" 这件事再拆细一点：有的系统主要在优化单入口多角色工作流，有的在优化可配置编排，有的已经开始优化长期的人机协作组织面。

实操补充：如果你正在使用 Claude Code 并需要具体配置 Subagents、启用 Agent Teams（tmux 模式）、结合 Git Worktree 做分支隔离，或配置 Routines 定时任务，可参考社区实操指南：Claude Code 多 Agent 并行方案深度解析 ↗。

三、小结：两条线怎么一起想

不必把「技能包」和「子代理/团队」当成同一件事：前者回答在终端里按什么纪律写与审，后者回答多个会话之间如何分工与同步。

1

工作流与技能包

Superpowers、GStack 这类方案，把 TDD、评审、角色化命令固化成可重复调用的套路；选型取决于你更怕「没测试」还是更缺「产品/UI/发布」一条龙。

2

多智能体拓扑

需要干净摘要回主会话时用 Subagents；需要同伴之间持续对齐时用 Agent Teams。先画清上下文边界，再决定拆不拆、怎么拆。

3

阅读原文

细节、版本与批评意见以原文为准：Particula、Daily Dose of DS、知乎专栏。

Agent 生态对比 技能包与子代理