[建议 / Feature] 规划会话自动派生多个可选便宜模型的开发执行体(成本分层编排)
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 22
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
前置检查 / Prechecks
- 我已搜索现有 Issues 和 Discussions,无完全重复(相关但不相同:#177、#100、#266、#225)
- 我已阅读 CONTRIBUTING.md
类别 / Category
Agent 交互 / 编排(兼涉模型配置)
Agent 框架 / Agent framework
ZCode Agent(自研)
使用场景 / Use case
我希望用强模型在一个会话里做需求规划与任务拆解,然后自动创建多个开发执行体(子代理或独立会话),各自绑定更便宜的模型执行机械的实现任务——即"规划用贵模型、执行用便宜模型"的成本分层流水线。
目前实测有三个卡点,自动化断在"开执行体"这一步:
- Agent 工具无具体模型参数:派发的子代理默认继承主会话模型(部分版本仅支持 sonnet/opus/haiku 能力档位),无法把某个实现子代理定向到指定的便宜 provider+model(关联 #177)。
- 自动化派生的会话模型被锁死:Cron/定时自动化创建的会话,其 model/provider 在创建时绑定为当前会话所用模型,且事后不可修改,无法让派生会话跑在便宜模型上。
- 缺少编程式建会话接口:没有"以指定模型新建会话"的 API/工具,规划会话无法自己拉起 N 个不同模型的执行会话并回收结果。
当前的 workaround 是:人工另开新会话 → 手动选便宜模型 → 把 plan 文件/任务简报喂进去。规划和执行可以分离,但"开会话"这一步必须人工完成。
建议方案 / Proposal
- Agent dispatch 支持指定具体 provider+model(与 #177 一致),或自定义 subagent 定义支持 model frontmatter,使实现/评审子代理可锁定便宜模型;
- 自动化/派生会话(Cron 等)支持显式指定 model/provider,而不是只能继承创建者;
- 提供 spawn-session 编程接口:规划会话一次调用即可创建绑定指定模型的新会话、传入任务简报(plan 文件路径 / task brief),执行完成后结果可被规划会话回收(可复用现有的跨会话上下文读取能力);
4.(可选)编排视图:展示各执行体状态与成本,失败任务可一键升级模型重试。
预期价值 / Expected value
- 成本分层:强模型只做规划与终审,机械实现走便宜模型,多任务并行开发的整体成本显著下降;
- 上下文隔离:规划会话上下文不被实现细节污染,长任务更稳;
- 与 #100 的手动多代理定义互补:本需求侧重"规划 → 自动派生 → 便宜模型执行 → 结果回收"的全自动流水线。
感知优先级 / Perceived priority
Medium(仅供参考,最终以团队评估为准)
版本 / 环境 / Version & environment
ZCode(Windows 11,2026-08)
补充说明 / Additional context
关联 issue:#177(子代理 provider+model 选择)、#100(多代理并发编排+决策者)、#266(子代理 metadata 暴露 model/effort 字段)、#225(会话分叉/并行开发,已关闭)。本 issue 聚焦"自动派生 + 模型分层",如团队认为应并入 #177 或 #100 跟踪,也可以直接关闭并指路。
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing related issues #177, #100, #266, and #225, then inspect the existing cross-session context reading capability mentioned in the proposal. Clarify the boundaries between model selection, derived-session creation, task-brief passing, and result collection; done should be a maintainer-approved scope with concrete entry points and acceptance criteria.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ai-infra-agents
- Domain
- ai, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100