Sim 仓库 council 技能深度解析：多智能体并行探索（Fan-out Exploration）模式实战指南

Sim 仓库 council 技能深度解析多智能体并行探索Fan-out Exploration模式实战指南【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000 builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim本指南围绕 Sim 仓库中的.agents/skills/council/SKILL.md展开系统讲解council议事会这一元探索技能的设计意图、Frontmatter 规范、三步执行协议与 Plan Mode 分支并结合仓库内 scripts/sync-skills.ts、cleanup、ship 等源码佐证其底层机制。读完你将掌握如何在跨大量文件的宽泛任务中通过初探 → 并行 fan-out 任务智能体 → 汇聚收敛的协议高效组织多智能体协作以及 Sim 仓库如何通过技能同步脚本将 SKILL.md 分发给 Claude 与 Cursor 等不同 Agent 客户端。council 是什么定位为元探索工具而非服务集成器在 Sim 仓库的.agents/skills/目录下共维护了 40 个技能skill按用途可分为三类功能构建型技能如add-tools、add-block、add-connector、add-trigger、add-model用于为 Sim 集成创建工具、块、触发器、模型等具体产物多数带有agents/openai.yaml独立 Agent 卡片质量审查型技能如you-might-not-need-state、you-might-not-need-an-effect、memory-load-check、react-query-best-practices针对具体反模式做分析与修复元meta技能如council、cleanup、ship、you-might-not-need-*系列它们不直接产出业务代码而是编排其他技能或智能体的协作流程。council属于典型的元技能。其 Frontmatter 中的description给出了精确定义Spawn parallel task agents to explore a given area of the codebase from multiple angles, then use their findings to answer the question or build a plan. Use when a task needs broad fan-out exploration across many files before acting.翻译过来即并行派生出多个任务智能体从多个角度探索代码库中给定的兴趣区域再用它们的发现回答问题或构建计划。适用场景是行动之前需要在大量文件间做宽泛扇形展开fan-out探索的任务——例如这个错误可能由哪些模块导致重构某个核心流程会影响哪些调用方新功能应该落在架构的哪一层这类需要覆盖面广、视角多元的问题。值得注意的是council的 Frontmatter 里有一段设计注释直接点明了它的定位No agents/openai.yaml by design: council is a meta/exploration utility (like cleanup, ship, you-might-not-need-*), not a service-integration builder, so it intentionally ships no standalone agent card.即council 有意不提供agents/openai.yaml因为它与cleanup、ship、you-might-not-need-*一样是元/探索工具而非服务集成构建器因此刻意不随附独立 Agent 卡片。这一点是理解其定位的关键。Frontmatter 规范name、description、argument-hint与仓库中所有 SKILL.md 一样council使用 YAML Frontmatter 声明元数据。完整的 Frontmatter 如下--- name: council description: Spawn parallel task agents to explore a given area of the codebase from multiple angles, then use their findings to answer the question or build a plan. Use when a task needs broad fan-out exploration across many files before acting. argument-hint: area-of-interest # No agents/openai.yaml by design: council is a meta/exploration utility (like cleanup, ship, you-might-not-need-*), not a service-integration builder, so it intentionally ships no standalone agent card. ---对照 scripts/sync-skills.ts 中loadCanonicalSkills与parseSkill的解析逻辑可以看出这套 Frontmatter 是被脚本强制校验的name必须与技能目录名完全一致否则脚本直接抛错frontmatter name must equal the directory namecouncil目录因此必须声明name: councildescription必填字段缺失即报错missing description in frontmatter。它同时充当两个角色——人类可读的功能摘要以及sync-skills.ts同步时被完整保留的投影内容argument-hint可选为调用方提示技能参数形式。council的提示为area-of-interest即用户需要提供一个兴趣区域例如某个功能模块、某段错误日志、某个待重构的子系统#注释Frontmatter 块内的注释行同样会被解析器保留。sync-skills.ts的parseSkill仅要求文件以---\n开头并找到结束的\n---\n中间行不强制键值结构因此这段设计说明注释会原样保留在投影中成为分发到各客户端后的上下文说明。三步执行协议初探 → fan-out → 汇聚council的执行流程由正文中的三段指令定义构成一个完整的探索-并行-收敛协议Based on the given area of interest, please: 1. Dig around the codebase in terms of that given area of interest, gather general information such as keywords and architecture overview. 2. Spawn off n10 (unless specified otherwise) task agents to dig deeper into the codebase in terms of that given area of interest, some of them should be out of the box for variance. 3. Once the task agents are done, use the information to do what the user wants. If user is in plan mode, use the information to create the plan.第一步主智能体初探Dig Around在派发任何子智能体之前主智能体先围绕用户给定的area-of-interest亲自在代码库中挖一圈目标是建立关键词集合与架构概览两级粗粒度认知关键词keywords从兴趣区域中提取与代码库内标识符函数名、类型名、目录名、常量名可对应的检索词为后续子智能体的定向搜索提供锚点架构概览architecture overview判断该区域在 Sim 整体架构中的位置。仓库根目录的 AGENTS.md 给出了顶层结构apps/sim为 Next.js 应用含app/、blocks/、executor/、lib/、tools/、triggers/等子目录packages/下为sim/db、sim/utils等共享包这一步的价值是让主智能体先形成兴趣区域落在哪一层、可能涉及哪些包边界的判断再决定 fan-out 的方向与数量。这一步与sync-skills.ts无关属于技能运行时行为但它决定了第二步 fan-out 的质量——初探越准确子智能体的分工越有效。第二步并行派发 n10 个任务智能体Fan-out这是council的核心机制也是最值得展开的设计点默认并发数为 10Spawn off n10 (unless specified otherwise)。调用方可通过显式指定覆盖默认值例如在参数中声明更小或更大的并发数以适配任务规模与上下文预算强调多样性variancesome of them should be out of the box for variance——要求部分子智能体跳出常规视角out of the box刻意采用非典型切入角度。这是为了避免 10 个智能体从同一角度出发、产出高度同质化的重复发现牺牲探索覆盖面换取答案的多样性并行执行所有子智能体在同一轮中并发运行互不等待、互不依赖各自独立深挖兴趣区域的某一侧面最后统一汇总结果。这一多角度并行、刻意混入异质视角的模式与仓库中另一个元技能cleanup的并行分析阶段异曲同工——cleanup会在单条消息里同时派发 8 个 passeffects、memo、callbacks、state、React Query、emcn、url-state、comments作为子智能体并行分析同一 scope再进入汇聚与应用阶段。两者的差异在于cleanup的并行体是固定编排的 8 个预定义 passcouncil的并行体则是根据兴趣区域动态生成的 n 个自由探索智能体。第三步汇聚收敛与应用所有任务智能体完成后主智能体收集全部发现据此执行用户的实际诉求用户提出的是问题 → 用汇聚后的信息回答问题用户提出的是任务 → 用汇聚后的信息构建行动计划用户处于Plan Mode规划模式→ 用汇聚后的信息创建计划If user is in plan mode, use the information to create the plan。Plan Mode 分支是一个显式的行为开关同样的探索流程在普通模式下输出答案或方案在 Plan Mode 下则输出结构化的实施计划供用户确认后再进入执行阶段。这与cleanup的fixtrue|false参数设计思路一致——把分析与动手分离探索/分析阶段只读、不修改是否落地由调用方决定。参数化与调用约定argument-hint 与 $ARGUMENTScouncil通过argument-hint: area-of-interest声明其唯一参数兴趣区域。调用形态如/council area-of-interestarea-of-interest可以是任意可定位的探索范围描述例如一个功能模块名undo-redo 功能;一段架构问题工作流执行引擎中 DAG 的依赖解析;一个待排查的现象知识库连接器下载超大文件时的内存行为;一个重构目标把工具执行边界迁移到 InternalToolConfig.operation。对比仓库中其他技能的参数约定可以看出其设计差异cleanup使用[scope] [fixtrue|false]结构并在正文中用$ARGUMENTS解析.agents/skills/cleanup/SKILL.md而council保持极简——一个兴趣区域即可驱动整套 fan-out 流程n值仅在用户显式指定时覆盖默认的 10。设计决策为什么 council 刻意不带独立 Agent 卡片在.agents/skills/下功能构建型技能普遍携带agents/openai.yaml。例如 .agents/skills/add-tools/agents/openai.yaml 的内容为interface: display_name: Add Tools short_description: Build Sim tools from API docs brand_color: #EA580C default_prompt: Use $add-tools to create or update Sim tool definitions from service API docs.这类 Agent 卡片为技能提供面向 LLM 平台的独立展示显示名、短描述、品牌色、默认提示词使其可以作为独立 Agent 被直接调用。而council明确不提供该文件理由在 Frontmatter 注释中写得很清楚它是元/探索工具与cleanup、ship、you-might-not-need-*同类不是服务集成构建器。从仓库结构可以推断其深层逻辑元技能的价值在于被编排而非被独立部署council由主智能体在任务开始时调用作为探索前置阶段存在本身不产出可交付的集成产物因此不需要以独立 Agent 形态面向用户避免 Agent 卡片的语义错配add-tools的 Agent 卡片描述的是构建工具配置这一具体产出若为council配备卡片会暗示它可独立完成某项业务交付与其探索辅助的真实角色冲突与姊妹元技能保持一致的仓库约定同样作为元技能的cleanup、ship、you-might-not-need-*系列均无agents/openai.yamlcouncil遵循同一约定。技能分发机制sync-skills.ts 如何让 council 到达各客户端理解council的另一个关键维度是 Sim 仓库如何管理技能文件的分发。scripts/sync-skills.ts 定义了完整的投影projection机制规范源canonical source.agents/skills/name/SKILL.md是唯一权威来源Frontmatter 只允许name、description、可选argument-hint及正文Claude 投影.claude/skills/name是指向完整规范技能目录的符号链接symlink这样 Claude 客户端能拿到完整技能目录包括council这类技能可能附带的所有资源Cursor 投影Cursor 直接发现.agents/skills因此无需投影这也是council等技能在 Cursor 侧零成本可用的原因废弃清理旧的.claude/commands/name.md与.cursor/commands/name.md投影在同步时被删除在--check模式下视为过期孤儿链接清理findOrphanedClaudeLinks会找出规范技能已不存在但.claude/skills中残留的符号链接并移除。实际使用命令定义于仓库根目录 package.json# 写入/修复所有技能投影 bun run skills:sync # 只检查投影是否过期过期则 exit 1供 CI 使用 bun run skills:sync --check # 或 bun run check:skills对应脚本内部实现bun run scripts/sync-skills.ts # write projections bun run scripts/sync-skills.ts --check # fail (exit 1) if any projection is stale校验逻辑还包含一条强约束每个 SKILL.md 必须以---\n开头且包含终止的\n---\nname必须等于目录名description必须存在——council的 SKILL.md 正是完全符合此规范的示例.agents/skills/council/SKILL.md。实战场景与使用建议综合上述机制council在 Sim 仓库中的典型使用方式可归纳如下何时用 council任务涉及跨多个目录/包的理解单一线性检索容易遗漏关联如评估把 X 模块迁移到 Y 架构的影响面需要多视角交叉验证结论如排查一个可能由前端、执行引擎或持久化层共同导致的问题行动前需要一份基于全库证据的探索报告或实施计划尤其是用户处于 Plan Mode 时。何时不用 council任务目标明确、范围集中在单文件或单目录直接阅读与编辑即可任务需要的是确定性产物如新增一个工具配置应使用add-tools等功能构建型技能任务是对既有改动做质量审查应使用cleanup固定 8-pass 并行分析 顺序应用而非自由探索。调用模板/council 兴趣区域描述 [可选: 指定子智能体数量 n]例如/council knowledge-connector 文件下载的字节上限与失败处理会触发主智能体先建立关键词CONNECTOR_MAX_FILE_BYTES、readBodyWithLimit、stubOrSkipBySize等与架构概览再并行派发 10 个智能体从不同角度深挖默认值 10可覆盖最后汇聚成一份完整分析或行动计划——这正是仓库内memory-load-check等技能所关注的内存边界问题在探索阶段的理想前置步骤。小结council是 Sim 仓库中一个设计精炼的元探索技能它以极简的 Frontmattername/description/argument-hint声明接口以初探 → 并行 fan-out n10 个智能体含异质视角→ 汇聚收敛的三步协议组织多智能体协作并通过 Plan Mode 分支将探索结果与执行决策解耦。它刻意不配备独立 Agent 卡片与cleanup、ship等元技能共同构成仓库的编排层而 scripts/sync-skills.ts 则保证council的规范源能通过符号链接投影到 Claude、被 Cursor 直接发现并在 CIbun run check:skills中保持各客户端技能面一致。理解这套机制你就掌握了 Sim 仓库中大规模探索任务的标准打开方式也能将其中的 fan-out 模式复用到自己的多智能体工作流设计中。【免费下载链接】simSim is the collaborative workspace to build, deploy, and monitor AI agents and workflows. Used by 100,000 builders.项目地址: https://gitcode.com/GitHub_Trending/sim16/sim创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考