jcode Swarm 模型路由与生成策略从 swarm-prompt 覆盖层到 deep 模式递归编排【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode在 jcode 中swarm是一个多智能体并行协作机制一个协调者coordinator可以按需生成一批 worker 代理让它们并行执行计划任务、互相通过私信与广播协调并把完成报告回传给拥有者。由于 swarm 是复杂、动态的系统其路由策略并没有被硬编码进配置文件而是以**提示词prompt**的形式直接交给模型 —— 这份提示词就是 swarm_prompt.md。读完本文你将掌握 jcode swarm 的模型路由优先级model/agents.swarm_model/inherit、按任务类型选择推理强度effort的实战用法理解label与单层/递归生成swarm-deep的结构约束并能在全局或项目级覆盖这份内置提示词。为什么 swarm 路由策略是一份提示词而不是配置文件打开 swarm_prompt.md文件第一行注释就直截了当地声明This file IS the swarm config.Swarm 是复杂的动态系统因此路由策略用哪个模型、什么推理强度、如何组织生成结构被设计成直接传给模型的提示词而不是普通配置文件中的一组选项。这样的好处是路由决策本身可以被模型理解并执行同时运维者可以随时编辑这份提示词来微调 swarm 的整体行为而无需改动二进制或重启服务。这份内置文件在源码中通过include_str!编译进二进制见 prompt.rs/// Built-in default swarm prompt: model-routing guidance for spawned swarm /// agents (which model/effort to pick per task kind). Users can override it by /// creating ~/.jcode/swarm-prompt.md (global) or ./.jcode/swarm-prompt.md /// (project). See [load_swarm_prompt]. pub const DEFAULT_SWARM_PROMPT: str include_str!(prompt/swarm_prompt.md);三级覆盖优先级load_swarm_prompt的实现prompt.rs给出了明确的加载顺序项目级./.jcode/swarm-prompt.md—— 以当前工作目录为基准对特定仓库生效全局级~/.jcode/swarm-prompt.md—— 对所有项目生效内置默认DEFAULT_SWARM_PROMPT—— 当上面两个路径都不存在或内容为空时回退使用。pub fn load_swarm_prompt(working_dir: OptionPath) - String { let project_dir working_dir.unwrap_or(Path::new(.)); let candidates [ Some(project_dir.join(.jcode).join(swarm-prompt.md)), crate::storage::jcode_dir() .ok() .map(|dir| dir.join(swarm-prompt.md)), ]; for path in candidates.into_iter().flatten() { if let Ok(content) std::fs::read_to_string(path) { let trimmed content.trim(); if !trimmed.is_empty() { return trimmed.to_string(); } } } DEFAULT_SWARM_PROMPT.trim().to_string() }从源码可以看到候选文件即使存在只要trim()后为空字符串也会被跳过继续向下查找 —— 因此你可以通过放置一个空文件来禁用某一层的覆盖。自定义 swarm 提示词应当完整继承内置提示词的模型路由、effort 与结构约束再叠加你自己的组织策略例如固定某个团队的 worker 模型、禁止某些任务类型、调整深度阈值。model为新 worker 选择模型与认证路由内置提示词的第一条核心指令是模型路由Passmodelto choose a model for newly spawned workers, including workers created by assignment orrun_plan.也就是说model参数不仅影响通过spawn直接创建的 worker也覆盖通过任务分配assignment和run_plan批量编排创建的 worker。其优先级规则如下场景生效的模型选择spawn 调用显式传入model显式值生效覆盖agents.swarm_model未传model但配置了agents.swarm_model使用该配置默认值未传model且未配置swarm_model继承协调者coordinator的模型与路由传model: inherit即使配置了swarm_model也强制继承协调者模型需要特别注意的是模型选择不会改变已经复用reused的 worker。也就是说如果你先 spawn 了一个 worker 再用model指定别的模型该 worker 不会因此切换 —— 模型路由只作用于新生成的 worker。用swarm list_models检查可用模型与路由在执行路由决策前可以先运行swarm list_models检查当前可用的模型和路由。该命令在协议与服务器层均有实现例如 wire.rs 中的ListModels请求、client.rs 与 client_lifecycle.rs 中的处理逻辑TypeScript SDK 也同步暴露了对应能力见 protocol.ts。路由前缀同时固定认证通道提示词中特别提到一种路由前缀写法Route-prefixed values such asopenai-api:gpt-6-astrapin the authentication route as well as the model.即openai-api:gpt-6-astra这样的值不仅锁定了模型gpt-6-astra还锁定了认证路由openai-api。当你的环境配置了多个 provider 或同一 provider 的多个认证入口时这种写法可以避免模型被路由到错误的认证通道上。effort按任务类型分配推理强度提示词给出的 effort 指导是任务类型 → 推理强度的映射任务类型推荐effort实现类任务implementationeffort: low设计、调查、调试、审查、验证默认 effort不传上下文获取 / 批量阅读 / 摘要总结effort: none这里默认 effort意味着在 spawn/assign 调用中省略effort字段让 worker 沿用 provider 或会话当前的推理强度。实现任务用low是因为这类工作通常有明确规格、不需要过度推理而纯读取/总结类任务用none可以显著减少无谓的思考开销、提升吞吐。从 config/default_file.rs 可以看到默认的 worker 推理强度同样可以配置# Default reasoning effort for spawned swarm workers when the spawn call does # not pass an explicit effort (low, medium, high, ...). Leave unset so # workers inherit the provider-wide reasoning effort. # Env override: JCODE_SWARM_EFFORT # swarm_effort medium另外prompt.rs 中还定义了一个特殊的 effort 哨兵值swarm含义是使用该模型支持的最强推理并主动用 swarm 工具编排工作由 provider 在构造 API 请求时翻译为真实的最强 effort。这是配置默认 调用级覆盖 特殊哨兵三层机制的完整闭环。配置默认值[agents]段提示词建议用[agents] swarm_model设置未来 worker spawn 的默认模型用model参数做任务级选择。与 swarm 相关的全部默认配置集中在 config/default_file.rs 的[agents]段[agents] # 默认模型留空或设为 inherit/coordinator 则继承 spawn 会话的模型 # Env override: JCODE_SWARM_MODEL # swarm_model inherit # 默认推理强度low、medium、high 等 # Env override: JCODE_SWARM_EFFORT # swarm_effort medium # worker 生成方式 # inline - 进程内、无窗口在协调者界面以实时图廊展示默认 # visible - 打开带头部的终端窗口别名 headed # headless - 进程内创建无终端窗口 # auto - 优先 visible窗口打不开则回退 headless # Env override: JCODE_SWARM_SPAWN_MODE swarm_spawn_mode inline # 单个 swarm 内并发存活 worker 的 RAM 安全预算0 禁用该守卫仅剩 1000 的绝对硬顶 # Env override: JCODE_SWARM_MAX_CONCURRENT_AGENTS swarm_max_concurrent_agents 32 # 内联 swarm 图廊带最多占聊天高度的百分比1-90默认 40% # swarm_gallery_max_pct 40 # 内联 swarm 条布局vertical默认每行一个代理或 horizontal单行 chips # Env override: JCODE_SWARM_STRIP_LAYOUT # swarm_strip_layout vertical其中swarm_model的类型定义在 config-types 中为pub swarm_model: OptionString即允许未设置继承或设置具体模型名。所有键均可选注释中给出的值即为内置默认。关键的环境变量覆盖包括JCODE_SWARM_MODEL、JCODE_SWARM_EFFORT、JCODE_SWARM_SPAWN_MODE、JCODE_SWARM_MAX_CONCURRENT_AGENTS、JCODE_SWARM_STRIP_LAYOUT适合 CI 或容器场景按部署环境差异化注入。swarm_max_concurrent_agents 32是针对递归 ad hoc 生成和 deep 模式run_plan并行的 RAM 安全预算这个项目本身就以 The most RAM efficient harness 著称完成或停止的 worker 会释放槽位。底层还定义了绝对硬顶MAX_SWARM_MEMBERS: usize 1000见 jcode-swarm-core/src/lib.rs服务器在触及可配置的并发预算之前不会到达这个硬停点。label让 swarm UI 可读的生成结构约束提示词的第二大部分是生成结构指导第一条就是 labelAlways passlabelwhen spawning (e.g.label: api reviewer) so the swarm UI shows what each agent is for. The explicitspawnaction rejects missing or blank labels.每个 spawn 调用都必须携带label例如api reviewerswarm UIswarm info widget会用它来展示这个代理是干什么的。label是强制的 —— 显式spawn动作会拒绝缺失或空白的 label。单层 fan-out 与 deep 模式递归在普通normal模式与 light-swarm 模式下swarm 是单层扇出只有**根会话root session**可以生成代理worker 必须直接完成分配给自己的任务并回报结果不能创建下一代这样从结构上就把机会性opportunistic的 swarm 使用限制在有界范围内避免失控的指数级扩张。**递归生成recursive spawning**被保留给运行在swarm-deep模式下的根会话deep 模式下生成者拥有自己的子代理childrenmanager 式的任务分解可以在实质性改善覆盖时创建更深的子树深度受可配置的存活 worker 预算swarm_max_concurrent_agents与绝对成员上限1000约束。更完整的架构语义可以参考 SWARM_ARCHITECTURE.md从源码结构看父-子边由report_back_to_session_id编码子代理回报给生成它的会话沿这条链回溯即可重建祖先关系与深度树中部成员退出stop/崩溃/断连/关闭功能时其直接子代会被重新挂靠到存活的祖父节点兜底挂到当前协调者否则成为根 —— 从而保证跨成员变更时拥有权、停止权限、子树广播范围与完成回报保持连贯。spawn、run_plan、assign_task等请求的协议层与服务器层实现分别位于 wire.rs、comm_graph.rs 与 swarm.rs相关行为有大量端到端测试覆盖例如 comm_control_tests 下的assign_double.rs、assign_busy_skip.rs、auto_worker_filter.rs。完成回报与消息约束worker 的交付物约定虽然 swarm prompt 本身聚焦于路由与生成结构但配套的源码给出了 worker 交付物的硬约束了解它们能让你更正确地使用这个系统完成报告被生成/分配的代理必须以有用的最终助手回复结束每一轮被提示的工作服务器会自动把该最终回复转发给拥有它的协调者作为完成报告。报告应包含结果/状态、变更或发现、执行的验证、阻塞项或后续事项 —— 而不是仅仅一句done。相关哨兵常量SWARM_COMPLETION_REPORT_MARKER定义在 jcode-swarm-core/src/lib.rs。tldr 约束超过 240 字符的消息体必须提供单行tldr上限 200 字符让接收端 UI 能折叠成一行展示避免长文本冲垮 transcriptvalidate_swarm_tldr函数会校验并给出可操作的错误信息jcode-swarm-core/src/lib.rs。通知即软中断所有代理间通信私信、频道消息、广播、计划更新、生命周期事件都以通知形式排队为软中断在运行中代理的安全点注入从而允许消息在单轮内交错送达而不必开启新的一轮。实战小结把以上内容收束成一份可执行的清单模型路由调用级model优先于agents.swarm_model两者都缺省时继承协调者model: inherit强制继承路由前缀如openai-api:gpt-6-astra同时固定认证通道用swarm list_models提前核对可用项模型路由不影响已复用的 worker。推理强度实现任务effort: low设计/调查/调试/审查/验证走默认纯读取与总结用effort: none默认强度可用agents.swarm_effort或JCODE_SWARM_EFFORT配置。生成结构spawn 必传label普通/light 模式只有根会话能生成、worker 不得再生成下一代需要递归子树时让根会话运行在swarm-deep模式并留意 32 的并发预算与 1000 的成员硬顶。覆盖内置提示词在~/.jcode/swarm-prompt.md全局或./.jcode/swarm-prompt.md项目级放置自定义提示词加载优先级为项目级 全局级 内置默认自定义内容请完整保留内置提示词中的路由、effort 与结构约束再叠加你的组织策略。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 jcode Swarm 模型路由与生成策略：从 swarm-prompt 覆盖层到 deep 模式递归编排
jcode Swarm 模型路由与生成策略从 swarm-prompt 覆盖层到 deep 模式递归编排【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode在 jcode 中swarm是一个多智能体并行协作机制一个协调者coordinator可以按需生成一批 worker 代理让它们并行执行计划任务、互相通过私信与广播协调并把完成报告回传给拥有者。由于 swarm 是复杂、动态的系统其路由策略并没有被硬编码进配置文件而是以**提示词prompt**的形式直接交给模型 —— 这份提示词就是 swarm_prompt.md。读完本文你将掌握 jcode swarm 的模型路由优先级model/agents.swarm_model/inherit、按任务类型选择推理强度effort的实战用法理解label与单层/递归生成swarm-deep的结构约束并能在全局或项目级覆盖这份内置提示词。为什么 swarm 路由策略是一份提示词而不是配置文件打开 swarm_prompt.md文件第一行注释就直截了当地声明This file IS the swarm config.Swarm 是复杂的动态系统因此路由策略用哪个模型、什么推理强度、如何组织生成结构被设计成直接传给模型的提示词而不是普通配置文件中的一组选项。这样的好处是路由决策本身可以被模型理解并执行同时运维者可以随时编辑这份提示词来微调 swarm 的整体行为而无需改动二进制或重启服务。这份内置文件在源码中通过include_str!编译进二进制见 prompt.rs/// Built-in default swarm prompt: model-routing guidance for spawned swarm /// agents (which model/effort to pick per task kind). Users can override it by /// creating ~/.jcode/swarm-prompt.md (global) or ./.jcode/swarm-prompt.md /// (project). See [load_swarm_prompt]. pub const DEFAULT_SWARM_PROMPT: str include_str!(prompt/swarm_prompt.md);三级覆盖优先级load_swarm_prompt的实现prompt.rs给出了明确的加载顺序项目级./.jcode/swarm-prompt.md—— 以当前工作目录为基准对特定仓库生效全局级~/.jcode/swarm-prompt.md—— 对所有项目生效内置默认DEFAULT_SWARM_PROMPT—— 当上面两个路径都不存在或内容为空时回退使用。pub fn load_swarm_prompt(working_dir: OptionPath) - String { let project_dir working_dir.unwrap_or(Path::new(.)); let candidates [ Some(project_dir.join(.jcode).join(swarm-prompt.md)), crate::storage::jcode_dir() .ok() .map(|dir| dir.join(swarm-prompt.md)), ]; for path in candidates.into_iter().flatten() { if let Ok(content) std::fs::read_to_string(path) { let trimmed content.trim(); if !trimmed.is_empty() { return trimmed.to_string(); } } } DEFAULT_SWARM_PROMPT.trim().to_string() }从源码可以看到候选文件即使存在只要trim()后为空字符串也会被跳过继续向下查找 —— 因此你可以通过放置一个空文件来禁用某一层的覆盖。自定义 swarm 提示词应当完整继承内置提示词的模型路由、effort 与结构约束再叠加你自己的组织策略例如固定某个团队的 worker 模型、禁止某些任务类型、调整深度阈值。model为新 worker 选择模型与认证路由内置提示词的第一条核心指令是模型路由Passmodelto choose a model for newly spawned workers, including workers created by assignment orrun_plan.也就是说model参数不仅影响通过spawn直接创建的 worker也覆盖通过任务分配assignment和run_plan批量编排创建的 worker。其优先级规则如下场景生效的模型选择spawn 调用显式传入model显式值生效覆盖agents.swarm_model未传model但配置了agents.swarm_model使用该配置默认值未传model且未配置swarm_model继承协调者coordinator的模型与路由传model: inherit即使配置了swarm_model也强制继承协调者模型需要特别注意的是模型选择不会改变已经复用reused的 worker。也就是说如果你先 spawn 了一个 worker 再用model指定别的模型该 worker 不会因此切换 —— 模型路由只作用于新生成的 worker。用swarm list_models检查可用模型与路由在执行路由决策前可以先运行swarm list_models检查当前可用的模型和路由。该命令在协议与服务器层均有实现例如 wire.rs 中的ListModels请求、client.rs 与 client_lifecycle.rs 中的处理逻辑TypeScript SDK 也同步暴露了对应能力见 protocol.ts。路由前缀同时固定认证通道提示词中特别提到一种路由前缀写法Route-prefixed values such asopenai-api:gpt-6-astrapin the authentication route as well as the model.即openai-api:gpt-6-astra这样的值不仅锁定了模型gpt-6-astra还锁定了认证路由openai-api。当你的环境配置了多个 provider 或同一 provider 的多个认证入口时这种写法可以避免模型被路由到错误的认证通道上。effort按任务类型分配推理强度提示词给出的 effort 指导是任务类型 → 推理强度的映射任务类型推荐effort实现类任务implementationeffort: low设计、调查、调试、审查、验证默认 effort不传上下文获取 / 批量阅读 / 摘要总结effort: none这里默认 effort意味着在 spawn/assign 调用中省略effort字段让 worker 沿用 provider 或会话当前的推理强度。实现任务用low是因为这类工作通常有明确规格、不需要过度推理而纯读取/总结类任务用none可以显著减少无谓的思考开销、提升吞吐。从 config/default_file.rs 可以看到默认的 worker 推理强度同样可以配置# Default reasoning effort for spawned swarm workers when the spawn call does # not pass an explicit effort (low, medium, high, ...). Leave unset so # workers inherit the provider-wide reasoning effort. # Env override: JCODE_SWARM_EFFORT # swarm_effort medium另外prompt.rs 中还定义了一个特殊的 effort 哨兵值swarm含义是使用该模型支持的最强推理并主动用 swarm 工具编排工作由 provider 在构造 API 请求时翻译为真实的最强 effort。这是配置默认 调用级覆盖 特殊哨兵三层机制的完整闭环。配置默认值[agents]段提示词建议用[agents] swarm_model设置未来 worker spawn 的默认模型用model参数做任务级选择。与 swarm 相关的全部默认配置集中在 config/default_file.rs 的[agents]段[agents] # 默认模型留空或设为 inherit/coordinator 则继承 spawn 会话的模型 # Env override: JCODE_SWARM_MODEL # swarm_model inherit # 默认推理强度low、medium、high 等 # Env override: JCODE_SWARM_EFFORT # swarm_effort medium # worker 生成方式 # inline - 进程内、无窗口在协调者界面以实时图廊展示默认 # visible - 打开带头部的终端窗口别名 headed # headless - 进程内创建无终端窗口 # auto - 优先 visible窗口打不开则回退 headless # Env override: JCODE_SWARM_SPAWN_MODE swarm_spawn_mode inline # 单个 swarm 内并发存活 worker 的 RAM 安全预算0 禁用该守卫仅剩 1000 的绝对硬顶 # Env override: JCODE_SWARM_MAX_CONCURRENT_AGENTS swarm_max_concurrent_agents 32 # 内联 swarm 图廊带最多占聊天高度的百分比1-90默认 40% # swarm_gallery_max_pct 40 # 内联 swarm 条布局vertical默认每行一个代理或 horizontal单行 chips # Env override: JCODE_SWARM_STRIP_LAYOUT # swarm_strip_layout vertical其中swarm_model的类型定义在 config-types 中为pub swarm_model: OptionString即允许未设置继承或设置具体模型名。所有键均可选注释中给出的值即为内置默认。关键的环境变量覆盖包括JCODE_SWARM_MODEL、JCODE_SWARM_EFFORT、JCODE_SWARM_SPAWN_MODE、JCODE_SWARM_MAX_CONCURRENT_AGENTS、JCODE_SWARM_STRIP_LAYOUT适合 CI 或容器场景按部署环境差异化注入。swarm_max_concurrent_agents 32是针对递归 ad hoc 生成和 deep 模式run_plan并行的 RAM 安全预算这个项目本身就以 The most RAM efficient harness 著称完成或停止的 worker 会释放槽位。底层还定义了绝对硬顶MAX_SWARM_MEMBERS: usize 1000见 jcode-swarm-core/src/lib.rs服务器在触及可配置的并发预算之前不会到达这个硬停点。label让 swarm UI 可读的生成结构约束提示词的第二大部分是生成结构指导第一条就是 labelAlways passlabelwhen spawning (e.g.label: api reviewer) so the swarm UI shows what each agent is for. The explicitspawnaction rejects missing or blank labels.每个 spawn 调用都必须携带label例如api reviewerswarm UIswarm info widget会用它来展示这个代理是干什么的。label是强制的 —— 显式spawn动作会拒绝缺失或空白的 label。单层 fan-out 与 deep 模式递归在普通normal模式与 light-swarm 模式下swarm 是单层扇出只有**根会话root session**可以生成代理worker 必须直接完成分配给自己的任务并回报结果不能创建下一代这样从结构上就把机会性opportunistic的 swarm 使用限制在有界范围内避免失控的指数级扩张。**递归生成recursive spawning**被保留给运行在swarm-deep模式下的根会话deep 模式下生成者拥有自己的子代理childrenmanager 式的任务分解可以在实质性改善覆盖时创建更深的子树深度受可配置的存活 worker 预算swarm_max_concurrent_agents与绝对成员上限1000约束。更完整的架构语义可以参考 SWARM_ARCHITECTURE.md从源码结构看父-子边由report_back_to_session_id编码子代理回报给生成它的会话沿这条链回溯即可重建祖先关系与深度树中部成员退出stop/崩溃/断连/关闭功能时其直接子代会被重新挂靠到存活的祖父节点兜底挂到当前协调者否则成为根 —— 从而保证跨成员变更时拥有权、停止权限、子树广播范围与完成回报保持连贯。spawn、run_plan、assign_task等请求的协议层与服务器层实现分别位于 wire.rs、comm_graph.rs 与 swarm.rs相关行为有大量端到端测试覆盖例如 comm_control_tests 下的assign_double.rs、assign_busy_skip.rs、auto_worker_filter.rs。完成回报与消息约束worker 的交付物约定虽然 swarm prompt 本身聚焦于路由与生成结构但配套的源码给出了 worker 交付物的硬约束了解它们能让你更正确地使用这个系统完成报告被生成/分配的代理必须以有用的最终助手回复结束每一轮被提示的工作服务器会自动把该最终回复转发给拥有它的协调者作为完成报告。报告应包含结果/状态、变更或发现、执行的验证、阻塞项或后续事项 —— 而不是仅仅一句done。相关哨兵常量SWARM_COMPLETION_REPORT_MARKER定义在 jcode-swarm-core/src/lib.rs。tldr 约束超过 240 字符的消息体必须提供单行tldr上限 200 字符让接收端 UI 能折叠成一行展示避免长文本冲垮 transcriptvalidate_swarm_tldr函数会校验并给出可操作的错误信息jcode-swarm-core/src/lib.rs。通知即软中断所有代理间通信私信、频道消息、广播、计划更新、生命周期事件都以通知形式排队为软中断在运行中代理的安全点注入从而允许消息在单轮内交错送达而不必开启新的一轮。实战小结把以上内容收束成一份可执行的清单模型路由调用级model优先于agents.swarm_model两者都缺省时继承协调者model: inherit强制继承路由前缀如openai-api:gpt-6-astra同时固定认证通道用swarm list_models提前核对可用项模型路由不影响已复用的 worker。推理强度实现任务effort: low设计/调查/调试/审查/验证走默认纯读取与总结用effort: none默认强度可用agents.swarm_effort或JCODE_SWARM_EFFORT配置。生成结构spawn 必传label普通/light 模式只有根会话能生成、worker 不得再生成下一代需要递归子树时让根会话运行在swarm-deep模式并留意 32 的并发预算与 1000 的成员硬顶。覆盖内置提示词在~/.jcode/swarm-prompt.md全局或./.jcode/swarm-prompt.md项目级放置自定义提示词加载优先级为项目级 全局级 内置默认自定义内容请完整保留内置提示词中的路由、effort 与结构约束再叠加你的组织策略。【免费下载链接】jcodeThe most RAM efficient harness项目地址: https://gitcode.com/GitHub_Trending/jcod/jcode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考