CodePilot Sub-agent 委派运行语义落地指南:竞品对照、可信运行合同与验收矩阵

发布时间:2026/10/10 1:47:04
CodePilot Sub-agent 委派运行语义落地指南:竞品对照、可信运行合同与验收矩阵 人工智能AI 应用AI Agent交互助手MCP Clients本地部署【免费下载链接】CodePilotA multi-model AI agent desktop client — connect any AI provider, extend with MCP skills, control from your phone. Built with Electron Next.js.项目地址https://gitcode.com/gh_mirrors/co0dep/CodePilot点击查看免费下载本文基于 CodePilot 仓库内调研文档 docs/research/subagent-orchestration-competitor-followup-2026-07-24.md 整理成文并以仓库源码subagent-orchestration.ts、subagent-status.ts、subagent-models.ts、db.ts与执行计划 docs/exec-plans/active/same-runtime-multi-model-subagents.md 为事实依据进行深化。导读本篇技术指南围绕 CodePilot 的多模型 Sub-agent 编排展开父会话决定主控、子 Agent 每次调用显式选择 ProviderModel、CodePilot / Claude Code / Codex 三条 Runtime 各自适配。文中完整梳理了 VS Code Copilot、Pydantic AI Harness、OpenAI Agents SDK、Roo Code、Gemini CLI、Cline、LangGraph / Microsoft Agent Framework 以及 Google ADK / AutoGen GraphFlow 的可借鉴与不应照搬之处并逐条对应到 CodePilot 已落地的可信委派运行合同logical run / physical attempt 分层、route fail-closed、settling 终态、结构化 provenance、workflow DAG。读完本文你将掌握一套可复用的子 Agent 编排设计准则、CodePilot 的 P0–P2 落地路径以及一张可直接用于回归验收的 17 条验收矩阵。一、结论优先补委派运行语义而非继续扩大 RuntimeCodePilot 当前父会话决定主控、子 Agent 每次显式选择模型、三条 Runtime 各自适配的方向没有走偏。最近反复出现的问题不主要是还少接了某个框架而是委派执行合同尚未完全产品化。本轮调研承接 docs/research/cross-runtime-multi-agent-orchestration-2026-07-22.md在排除 Craft Agents、OpenCode、Claude Code / Codex 原生 Sub-agent 和 AutoGen 后最有参考价值的竞品是VS Code / GitHub Copilot Subagents最接近 CodePilot每次调用可显式指定子模型的方向给出了明确的模型解析优先级、当前工具和用量展示Pydantic AI Harness SubAgents在委派预算、超时、失败隔离、共享 usage、子事件流方面最完整OpenAI Agents SDK对 tool call identity、嵌套事件、审批后恢复、最终完成语义和幂等副作用的定义最严谨Roo Code Boomerang Tasks父任务暂停、子任务独立历史、完成后只回传结果、父子任务导航的产品模型最清楚Gemini CLI Subagents证明继承父工具面和子 Agent 不得继续委派可以同时成立Cline Subagents / Agent Teams把一次性的轻量并行研究与可跨会话恢复的团队任务拆成两层LangGraph / Microsoft Agent Framework不建议当前引入其完整工作流框架但其 checkpoint、恢复和副作用幂等原则应直接进入 CodePilot 的运行合同。核心判断一个子任务是否可信取决于 requested/effective route、逻辑任务与物理 attempt、真实终态、结构化产物、预算、恢复和可观察性是否一致而不是它能否成功拉起一个进程。二、竞品逐项对照借鉴什么、不照搬什么2.1 VS Code / GitHub Copilot Subagents多模型共识与成本回退陷阱官方文档已把同一任务交给不同模型再比较共识与分歧作为正式使用模式。其子模型解析顺序为父 Agent 本次调用显式指定的模型自定义 Agent 的默认模型父会话模型。聊天 UI 会显示子 Agent 名称、当前正在使用的工具展开后可查看 prompt、全部工具调用和返回结果悬停还可查看子 Agent 的 AI credits。值得借鉴CodePilot 未来即使重新引入 Agent Template也应采用同样的调用参数 模板默认值 继承父会话优先级模板不应重新变成固定 Profile多模型共识可以做成受支持的编排模式同一输入、不同模型、独立上下文父 Agent 必须显式整理一致结论、冲突结论和证据差异胶囊或详情面板应在运行中显示current tool / elapsed / tokens / cost但 cost 只能在 Provider 返回可信 usage 时展示缺失即不显示禁止假 0。不应照搬VS Code 在子模型超过父模型成本层级时会静默回退到父模型。CodePilot 已有 requested/effective route 诚实展示要求显式指定的子模型不可静默回退应在启动前失败并询问用户或把可接受 fallback 作为用户明确选项VS Code 默认把子 Agent 折叠为 tool callCodePilot 已有用户裁决应继续用聊天流中的单行胶囊不退回折叠卡片。2.2 Pydantic AI Harness SubAgents预算与子事件流最完整Pydantic AI 的 SubAgents 使用单一delegate_task(agent_name, task)工具每个 child 获得独立上下文。它允许共享父子 usage给每个 delegate 设置usage_limits、timeout_seconds、max_calls和失败策略并能把 child event stream 传回调用方委派工具本身会从继承工具中排除避免递归。值得借鉴CodePilot 不能只靠depth1、concurrency2和墙钟 timeout 控制运行。每个 run 还应支持maxTurnsmaxToolCallsmaxProviderRequestsidleTimeouthardTimeout可获得时的 token / cost budget父子 usage 应能聚合但不同 Provider 的费用不能伪装成统一精确值。应先可靠保存 requests、tokens、tool calls金额只显示真实返回值Pydantic 把这些限制定义为soft limitsdelegate 返回转向消息后父 Agent 仍可能继续。CodePilot 的 foreground one-shot 合同选择受控终止并尽量保留部分结果是产品适配是否把 budget exhausted 从failed改为partial仍需单独决策child event stream 应作为 UI 当前活动与审计历史的数据源而不是从最终文本猜测进度。不应照搬Pydantic 的静态 named-agent registry 很适合服务端应用但 CodePilot 的模型目录是用户配置且动态变化的。应继续让 route 可由本次调用选择模板只提供身份和策略默认值。2.3 OpenAI Agents SDKtoolCallId 路由标识与幂等副作用OpenAI Agents SDK 把 manager agents-as-tools 与 handoff 明确区分。CodePilot 当前属于前者父 Agent 保持对话控制权child 只完成一段工作。Agent tool 支持传递嵌套运行事件toolCallId是回传结果和恢复审批的路由标识官方同时强调副作用应按 call ID 幂等。其 streaming result 还有一个重要语义只有 run 与回调全部完成后completed才会 resolve取消后可能没有 final output需要从可序列化状态恢复而不是伪造一条新消息继续。值得借鉴agent_name只用于展示不能作为运行路由键。数据库、SSE、权限请求、取消和重试都必须使用不可变的logical_run_id / attempt_id / tool_call_id模型结束输出不等于任务已完成。结果 checkpoint、artifact 持久化、权限回执和必要的 post-processing 全部结束后run 才能进入 terminal completedeffective route、usage、run identity 等 UI 元数据应走 app-only metadata不应混入模型可见的 tool result 再污染上下文审批恢复应恢复原 run state不能把批准后的继续执行建成一个没有关联的新子任务。2.4 Roo Code Boomerang Tasks双向 context contract 与显式依赖Roo Code 为每个子任务创建独立历史。父任务暂停child 完成后通过明确的 completion result 回传父任务再恢复UI 可以在父子任务之间导航并展示层级。向下传递的是明确任务向上返回的是完成结果而不是 fork 整段父历史。值得借鉴把 context contract 写成双向合同down目标、必要上下文、route、工具/权限、预算up状态、summary、sources、artifacts、warnings、usage、provenance详情侧栏应支持父任务与当前 child 的明确导航不能只展示一段临时文本顺序依赖的子任务应表达为显式依赖而不是让父模型靠自然语言记住等 A 完成再启动 B——这正是 CodePilot Phase 6 落地workflow_id/task_key/depends_on的动机。不应照搬Roo 默认在创建和完成时都要求批准对日常 CodePilot 使用过于打断。只有 route、成本或权限边界发生实质变化时才需要启动审批Roo 把 child completion summary 作为父任务主要事实源。CodePilot 不能只信自由文本 summary状态、来源、产物和真实路由必须由应用层结构化字段承载。2.5 Gemini CLI Subagents继承工具面与禁止递归可同时成立Gemini CLI 把每个 subagent 暴露成父 Agent 的工具。Generalist 可以继承父 Agent 的工具与配置但运行在独立上下文专用 Agent 可以覆盖模型、max turns、工具和会话策略。即使工具配置使用通配符subagent 也不能继续调用 subagent。值得借鉴继承 Runtime 原生工具与禁止递归委派不是二选一。CodePilot 应继续继承该 Runtime 本身支持的工具面再在最后一步硬排除 delegation toolSUBAGENT_TOOL_NAMES与深度 1 语义即由此而来Agent 身份、模型、工具、预算应是独立字段。一个研究员可以本次用 Kimi、下次用 DeepSeek而不是身份名称隐含 route未来可提供用户直接点名 Agent 的入口但 direct invocation 与父模型自动委派应共用同一运行合同。2.6 Cline Subagents 与 Agent Teams两层产品模型Cline 的轻量 Subagents 只用于同一会话内的并行研究每个 child 有独立上下文、token budget、工具调用/费用统计若未开启自动批准启动前会展示计划发送的 prompts。Cline Agent Teams 则是另一层协调者、共享任务板、inter-agent mailbox、mission log并把团队状态持久化以支持跨会话恢复。值得借鉴CodePilot 当前的 foreground Sub-agent 只应解决一次委派。共享任务板、Agent 互发消息、长期恢复属于未来的Agent Team / Workflow不应继续塞进当前单个胶囊当启动需要用户批准时批准面板可展示将发送给各 child 的任务摘要与真实 route详情面板可增加每个 run 的工具调用数、token、可信费用和执行时间如果未来做跨窗口、跨客户端或后台长期任务应把协调和执行与 UI 进程解耦Cline 的 hub-spoke 设计就是为 session 存活、多客户端和进程隔离服务。不应照搬Cline 轻量 Subagents 固定只读、不可联网或使用 MCP与 CodePilot 已确定的继承 Runtime 本身支持的工具不一致当前阶段不应直接做 team mailbox 或任务看板这会把尚未稳定的一次委派语义放大成更难恢复的分布式状态。2.7 LangGraph 与 Microsoft Agent Frameworkcheckpoint 与幂等原则进合同两者都把 durable execution 建立在 step / superstep checkpoint 上。恢复时可能重跑当前 step因此外部副作用必须幂等已完成的调用结果应被 checkpoint恢复后不应重复执行。值得借鉴CodePilot 应区分三个粒度logical delegation用户眼中的一个子任务physical attempt一次 Provider / Runtime 执行step / tool call可能产生副作用的最小恢复单元重试应创建新 attempt但 UI 默认只展示一个逻辑胶囊并在详情中说明第 2 次尝试写文件、命令、外部 API 等副作用需要稳定 idempotency key否则恢复运行可能重复执行。不应照搬当前无需引入 Temporal、LangGraph 或完整 workflow runtime。先在本地数据库和现有 Runtime adapter 上建立相同语义再决定是否需要外部工作流引擎。2.8 Structured workflow 复核Google ADK / AutoGen GraphFlow / LangGraph / Pydantic真实会话3f0085c5fc664deca85005d70b1abfca暴露了 one-shot 提示词合同解决不了的结构问题父模型在同一 assistant turn 里同时生成 Qwen research 与 DeepSeek copy 两个 tool inputSDK 虽然串行执行它们但DeepSeek 的 prompt 已在 Qwen 输出产生前被冻结因此不可能自动获得 Qwen 结果。父模型甚至把 DeepSeek prompt 写成目前处于等待状态导致一个本应由编排器表达的依赖被伪装成已启动的 Agent。四个参考实现给出的共同解法很一致Google ADKworkflow agent 负责顺序/并行LlmAgent 用output_key把最终文本写入 session state下游 instruction 从 state 注入。官方并行研究示例让三个 researcher 各写独立output_key再由后续 merger 消费而不是提前生成 merger 的输入AutoGen GraphFlownode 是 Agent、edge 是允许的执行路径顺序、parallel fan-out、join、condition 都由DiGraph控制。官方明确建议当执行顺序或分支需要严格控制时应从 ad-hoc group chat 切到 structured workflowLangGraph共享State是快照node 返回 state updateedge 决定下一 nodecheckpointer 在 super-step 边界持久化。它还明确要求可重跑 node 的副作用必须幂等Pydantic AI Harnessdelegate_task适合自包含的一次委派父 deps/usage 与 child event 可统一传递当任务需要跨重启、长运行或 human-in-the-loop 时官方另用 Temporal / DBOS / Prefect / Restate durable integration而不是让 delegate 自由文本承担恢复。CodePilot 取舍不引入上述框架依赖三条 Runtime 继续只是 worker backend在 CodePilot 自己的 durable orchestration layer 增加workflow_id task_key depends_on。Adapter 先写 queued run应用层只从sqlite.subagent_runs读取上游 terminal result并在真正启动下游 Runtime 时编译 child prompttool_use arrived、schema accepted、durable queued、Runtime executing、terminal是不同事实。managed 胶囊只为 durable row 展示参数/route 预检错误不冒充 Agent依赖 task 失败或没有 durable result 时下游不启动 Provider未声明依赖的 wait/stand-by placeholder 在应用层拒绝调用方按拓扑顺序先创建 upstream缺失上游仅保留短暂并行创建宽限随后 fail-fast避免 serial tool executor 因 dependent-first 顺序长期阻塞这一步先支持轻量 DAG edge不扩成完整 workflow engine。应用层会拒绝 self/indirect cycle真正的循环节点、条件分支、跨进程 worker、恢复后副作用重放仍属于后续层。源码证据src/lib/subagent-orchestration.ts 的validateSubagentDispatchSpec完整实现了上述语义——workflow_id/task_key 必须成对出现INVALID_DEPENDENCY_SPEC、key 限 1–160 个 ASCII 字符、depends_on必须是 task_key 字符串数组、禁止自依赖并通过isDependencyPlaceholder的正则含中英文等待/待命/stand-by模式识别未声明依赖的占位 prompt 并返回DEPENDENCY_DECLARATION_REQUIRED。resolveSubagentDependencies以 30 分钟默认等待、150ms 轮询、5 秒缺失依赖创建宽限区分DEPENDENCY_NOT_FOUND从未创建上游与DEPENDENCY_TIMEOUT上游存在但未在 deadline 前终止依赖就绪后由compileSubagentPromptWithDependencies在启动 Runtime 前注入codepilot_dependency_results结构化 JSON。三、调研识别的问题与 P0 落地状态以下条目保留当时的设计判断同时补充 2026-07-24 P0 已落地的事实。执行状态、验证证据与未结项以 docs/exec-plans/active/same-runtime-multi-model-subagents.md 为准不能用 research 文档代替。3.1 逻辑任务与物理调用没有完全分层用户说启动三个 Sub-agent产品应显示三个逻辑任务。某个任务因 403、timeout 或用户允许 fallback 而重试可以产生多个 physical attempts但不应再增加同级胶囊。建议的数据关系parent turn └─ logical delegation run ├─ attempt 1 → failed / AUTH_FORBIDDEN └─ attempt 2 → completed └─ tool calls / artifacts / usage关联必须来自显式、不可变的 ID不能靠agent_name、prompt、模型或时间接近程度猜测首次调用省略logical_run_id应用层生成 logical run并把该 ID 返回给调用方父 Agent 只有在重试同一个任务时才复用上一 attempt 返回的logicalRunId每次 Provider / Runtime 执行仍生成新的attempt_id与递增attempt_number未来若增加胶囊上的重试按钮应由应用层直接携带原logical_run_id这是比依赖模型记忆更可靠的入口缺省行为必须保守并优先保留审计事实没有显式 retry 关联时创建新的 logical run、平铺为另一枚胶囊宁可让用户看到两次调用也不得按名称或相似文本静默合并显式 ID 也不是无条件通行证最新 attempt 仍在 running/settling 时拒绝为LOGICAL_RUN_STILL_RUNNING已经 completed 时拒绝为LOGICAL_RUN_ALREADY_COMPLETED。只有 failed/partial/timed_out/cancelled 等 terminal 结局允许追加 attempt。P0 已按上述规则落地历史 physical-only 行保守回填为各自独立的 logical run / attempt 1没有推测旧调用之间的重试关系。active/completed 应用层守卫在 Provider 启动与 physical row 插入之前拒绝。源码证据subagent_runs表以logical_run_id TEXT NOT NULL DEFAULT 、attempt_number INTEGER NOT NULL DEFAULT 1 CHECK(attempt_number 0)建模db.ts并建唯一索引(parent_session_id, logical_run_id, attempt_number)。旧行通过 additive migration 回填logical_run_id id对应 attempt 1。前端聚合由 subagent-view.ts 的collapseLogicalSubagentRuns完成同一 logical run 只保留一个胶囊attemptCount取最大 attempt_number。3.2 模型解析和 fallback 尚未成为不可变合同建议固定为explicit per-call route editable template default route inherit parent route本次调用显式指定 route 后任何不可访问、未授权或 Runtime 不支持都必须 fail-closed只有用户或父 Agent 在工具参数里提前声明允许的 fallback 才能重试每个 attempt 都保存 requested route 与 effective route二者不同必须产生显式 warning。P0 同时收紧了既有 capability gateClaude 路径不再因存在任意 MCP server就推断具有 read / network / write 能力network_search只由真实工具面证明。Runtime 上报的模型与请求 route 不一致时当前 attempt 以ROUTE_MISMATCH失败不接受静默 fallback。源码证据src/lib/subagent-models.ts 的listSubagentRoutes只从当前 Runtime 兼容目录 已认证虚拟 ProviderxAI/OpenAI OAuth生成精确provider_id model候选reportedModelMatchesSubagentRoute做 exact大小写不敏感身份匹配共享 vendor 前缀也不被接受。getSubagentRoutingGuidance将requested/effective分开、禁止sonnet/opus/haiku协议槽位冒充目标模型等约束写进三 Runtime 共用的工具说明。3.3 terminal completed 仍可能早于用户真正拿到结果建议内部增加settling语义即使不直接显示给用户running → settling (模型终止等待结果、artifact、usage 和回调落盘) → completed / partial / failed / timed_out / cancelled只有结构化结果与用户可见内容已经 durable 后才写 terminal。否则刷新后仍会出现数据库完成但内容或文件没保存的假完成。实现落点不能直接扩展subagent_runs.status该列有 terminal 状态的CHECK闭集。P0 采用独立的phase IN (running, settling, terminal)列status继续表达用户可见执行结局additive migration、legacy backfill 和原子 terminal transaction 已进入执行计划与回归测试。源码证据src/lib/subagent-status.ts 显式定义SubagentRunPhase running | settling | terminal与SubagentExecutionStatusrunning/completed/partial/failed/cancelled/timed_out分离subagent_runs表同时具备phase、status、dispatch_statequeued/executing/settling/terminal与terminal INTEGER CHECK(terminal IN (0,1))四列db.tsterminal 写入只允许第一次原子收口。3.4 结果仍缺统一的结构化来源建议父 Runtime 最终接收统一结果interface DelegatedAgentResult { status: completed | partial | failed | timed_out | cancelled summary?: string error?: { code: string; httpStatus?: number; retryable?: boolean } sources: Array{ title?: string; uri?: string; trust: external | workspace | runtime } artifacts: Array{ kind: string; pathOrId: string; persisted: boolean } warnings: Array{ code: string; message: string } usage?: { requests?: number inputTokens?: number outputTokens?: number toolCalls?: number costUsd?: number measurementSource?: provider | runtime } provenance: { logicalRunId: string attemptId: string attemptNumber: number requestedProviderId?: string requestedModel?: string effectiveProviderId?: string effectiveModel?: string } }trust、route 和 persisted 状态应由应用层填写不能让 child 模型自报。P0 已保留 top-level structurederror并用costUsd明确货币缺失 usage 不显示假 0。measurementSource尚未持久化属于 P1 provenance 补强在它落地前只有 Adapter 从真实 Provider / Runtime 响应取得的金额才允许展示。源码证据src/lib/subagent-status.ts 的DelegatedAgentResult与上表一一对应sources带trust、artifacts带persisted、provenance带factSource: sqlite.subagent_runs。child 侧的机器可读 outcome 由 reported-subagent-outcome.ts 处理child 必须以其__CODEPILOT_SUBAGENT_OUTCOME__前缀开头声明completed / partial / failedparseReportedSubagentOutcome扫描正文中任意位置的平衡 JSON marker并配合explicitlyReportsSubagentTaskFailure识别无法完成此任务等失败语义防止模型停止说话被当成任务成功。3.5 budget 只有粗上界没有整棵树的真实核算并发数和深度只解决失控扩张不解决单个 child 长时间烧 token 或重复调用工具。预算既要 per-attempt也要聚合到 parent turn。Provider 没有 usage 时应显示不可用不能显示 0。P1 将落地 per-attempt 与 parent-tree 的 turns / requests / tool calls / timeout / token 预算usage 增加 measurement source。3.6 UI 有状态但缺运行中事实单行胶囊方向正确下一步不是重新做卡片而是补少量可信信息当前工具或阶段已运行时间attempt 次数partial / waiting approval / settlingtoken、工具调用和费用有真实数据时详情面板中的 prompt、route、事件、来源、产物和错误。源码证据subagent_run_events表以event_type闭集started/activity/tool_started/tool_completed/permission_requested/permission_resolved/partial_result/settling/terminal/route_warning保存 lifecycle带 monotoniccursor与(logical_run_id, cursor)索引db.ts每个 physical attempt 只保留最近 200 次事件变更详情 API 首包有界、随后按after_cursor增量返回。SubagentRunViewsubagent-view.ts承载 requested/effective route、workflow/task/dependency、dispatchState 与结构化结果运行中即可挂载侧边栏。3.7 批准、取消、重试仍可能命中错误对象两个同名 Agent 并行时名字不能参与路由。所有用户动作都必须带稳定的 run / attempt / call ID。取消一个 attempt 不应取消 sibling 或父回合父回合 Stop 则必须向下传播。权限请求也遵守同一规则。P0 前的 childcanUseTool裸透传会让审批弹窗看起来属于父会话现已由 wrapper 注入 run / session / agent transport metadata并记录permission_requested / permission_resolvedlifecycle event。真实凭据下的审批归属和定向批准仍保留在 Smoke Ledger不能用合同测试冒充。3.8 恢复语义尚未覆盖副作用幂等保存正文和 run 状态只是第一步。若 child 写文件后进程退出、但 terminal 尚未落盘恢复不能无条件重跑写操作。至少需要为可恢复 tool call 保存输入摘要、call ID、状态和结果引用。此属 P2tool-call checkpoint 与副作用幂等。3.9 一次性 Sub-agent 与长期 Agent Team 需要产品分层当前胶囊代表 foreground delegation。未来只有在需要共享任务板、Agent 间通信、后台持续运行和跨会话恢复时才引入 Team / Workflow 概念。否则用户会无法判断一个胶囊究竟是一次调用、一个长期 worker还是一个可继续对话的 session。四、落地状态与后续优先级P0可信运行合同2026-07-24 已完成代码与定向验证引入logical_run_id与attempt_id分层只有显式 retry 关联才复用逻辑胶囊固化 route 优先级与 fail-closed禁止任何静默模型回退terminal 写入晚于结果、artifact、usage 和 post-processing 持久化以独立phase列支持settling统一结构化 result / error / provenance应用层标注 trust 和 requested/effective routechild lifecycle 使用 typed event至少包含 current tool、activity time、permission、partial result 和 terminal。上述五项已进入 active exec plan、定向回归与 Dev UI smoke真实 Provider route report、retry ×N、审批和长任务切换聊天仍按 Smoke Ledger 待测。截至 docs/exec-plans/active/same-runtime-multi-model-subagents.md 的 Phase 7 记录三 Runtime managed 的 Qwen → DeepSeek → Kimi 依赖链含 packaged xAI OAuth / Grok 4.5 的 managed child均已真实 smokesubagent-orchestration.test.ts、subagent-run-persistence.test.ts、subagent-virtual-provider-routes.test.ts等定向套件覆盖了 route/terminal/permission/workflow 合同。P1补预算、观察性和常用编排per-attempt 与 parent-tree 的 turns / requests / tool calls / timeout / token 预算usage 增加 measurement source胶囊和详情面板增加真实 elapsed、attempt、tool、usage无数据不造值顺序、并行与依赖关系成为显式字段——2026-07-24 已进入 exec plan Phase 6三 Runtime 共用workflow_id/task_key/depends_on、queued dispatch state 与 app-side result handoff compiler真实三模型链 smoke 已跑通增加多模型共识编排模板同题独立运行父 Agent 输出 agreement / disagreement / evidence用户可直接点名 Agent 身份但身份选择与模型 route 选择保持独立。P2再做恢复和长期协作审批后从原 run state 恢复tool-call checkpoint 与副作用幂等确有需求后再设计后台 Team / Workflow、任务板和 inter-agent mailbox跨 Runtime Broker 在以上合同稳定后进入不提前放大状态复杂度。五、建议补入的验收矩阵场景必须成立一个逻辑 Agent 首次 403、用户通过重试按钮或父 Agent 显式复用logical_run_id换模型重试UI 仍是一枚胶囊详情有两个 attemptsrequested/effective route 分别可见两次调用未声明 retry 关联即使 Agent 名称、prompt 或模型相同保留两个 logical runs / 两枚胶囊不静默推断和合并复用仍在 running/settling 的 logical IDProvider 不启动、不新增 attempt返回LOGICAL_RUN_STILL_RUNNING并引导等待/读取当前 run复用已 completed 的 logical IDProvider 不启动、不新增 attempt、不遮蔽成功结果返回LOGICAL_RUN_ALREADY_COMPLETED新工作必须使用新 logical run显式模型不可访问不继承父模型、不静默换模型返回结构化失败并询问用户child 已生成正文但 artifact 持久化失败不得显示 completed保留 partial 与明确 warningchild 模型结束回调仍在落盘保持 running/settling刷新后不会提前 completed两个同名 Agent 并行权限、事件、详情、取消按 ID 隔离不按名字串台取消 sibling AA cancelledB 继续父回合可继续收 B父回合显式 Stop所有 active child 收到取消并进入终态max turns 触顶当前行为返回 partial保留正文、来源、artifact 和已用 usagebudget 触顶当前行为返回 failed MAX_BUDGET若 P1 决定改为 partial必须作为显式行为变更并补迁移/回归不能当成当前验收写文件后、terminal 前进程退出恢复不得重复同一副作用记录 interrupted/可恢复状态Provider 实际路由与请求路由不一致不把 attempt 伪装为成功命中目标模型产生 route mismatch warning外部内容含伪造 completion marker应用层状态不受外部文本影响external source 保持 untrusted切换聊天或刷新运行继续胶囊从 durable event 恢复最终结果不丢、不重复父模型在同一 turn 声明research → copy → implementation三个 durable taskcopy 启动时 prompt 含 research terminal resultimplementation 含其声明的全部上游结果tool input 因 schema/capability 格式错误被拒不创建subagent_runs不显示幽灵 Agent 胶囊父 Agent 收到结构化错误并修正downstream prompt 写等待 Agent 结果但未声明依赖Provider 不启动返回DEPENDENCY_DECLARATION_REQUIRED同 workflow 重复 task_key不创建第二个 logical Agent只有显式复用失败 logical run 才能成为 retry attemptA depends B、B depends Aclosing task 在 durable insert / Provider 启动前返回INVALID_DEPENDENCY_SPEC不得等待到超时源码佐证上述错误码闭集定义于 src/lib/subagent-status.ts 的SubagentStatusErrorCode含LOGICAL_RUN_STILL_RUNNING、LOGICAL_RUN_ALREADY_COMPLETED、INVALID_DEPENDENCY_SPEC、DEPENDENCY_NOT_FOUND/TIMEOUT/FAILED、DUPLICATE_TASK_KEY、MAX_TURNS、MAX_BUDGET、ROUTE_MISMATCH等 22 个并在 subagent-orchestration.ts 的依赖解析循环与 db 层守卫中逐一落地duplicate task_key与循环依赖在 durable insert 前由应用层 DAG 校验拒绝。六、建议暂时明确不做不因竞品保守而重新把 child 限制成只读继续遵守用户已经确认的 Runtime 工具继承语义不开放任意深度递归当前 depth 1 保持不复制 VS Code 的静默成本层级回退不把 child 的自由文本 summary 当 terminal 或来源事实不立即引入完整 workflow engine、team mailbox 或跨进程 daemon不让 Profile / Template 再次成为调用子模型的必选前置。七、参考资料仓库内继续深入阅读本文事实基线docs/research/cross-runtime-multi-agent-orchestration-2026-07-22.mdP0 落地执行计划含 Smoke Ledger 与决策日志docs/exec-plans/active/same-runtime-multi-model-subagents.md核心编排实现src/lib/subagent-orchestration.tsworkflow DAG 校验、依赖解析、handoff 编译状态/结果/生命周期类型src/lib/subagent-status.ts、src/lib/reported-subagent-outcome.ts路由解析与工具合同src/lib/subagent-models.tsUI 视图聚合与胶囊分流src/lib/subagent-view.ts持久化 schema 与迁移src/lib/db.tssubagent_runs/subagent_run_events定向回归测试src/__tests__/unit/subagent-orchestration.test.ts、src/__tests__/unit/subagent-run-persistence.test.ts、src/__tests__/unit/subagent-virtual-provider-routes.test.ts说明原调研文档中引用的 VS Code、Pydantic AI、OpenAI Agents SDK、Roo Code、Gemini CLI、Cline、LangGraph、Google ADK、AutoGen、Microsoft 等外部官方资料链接均为行业背景参考本文按仓库证据边界规范不再重复输出外部链接落地事实一律以 CodePilot 仓库内文档、源码与测试为准。赞分享人工智能AI 应用AI Agent交互助手MCP Clients本地部署【免费下载链接】CodePilotA multi-model AI agent desktop client — connect any AI provider, extend with MCP skills, control from your phone. Built with Electron Next.js.项目地址https://gitcode.com/gh_mirrors/co0dep/CodePilot点击查看免费下载相关推荐Julep 不变量测试矩阵Invariant Test Map为可组合 AI Agent 运行时建立行为契约Julep 不变量测试矩阵Invariant Test Map为可组合 AI Agent 运行时建立行为契约 导读 本文围绕 Julep 仓库中 testAI AgentAgent 框架后端Brakeman 安全策略解读受支持版本范围与漏洞报告流程Brakeman 安全策略解读受支持版本范围与漏洞报告流程 本文基于 Brakeman 仓库根目录下的 SECURITY.md https://link.gi人工智能AI 应用AI Agent交互助手MCP Clients本地部署大麦网抢票脚本怎么用4 个参数配好Python 自动登录、0.3 秒轮询、自动下单大麦网抢票脚本怎么用4 个参数配好Python 自动登录、0.3 秒轮询、自动下单 Automatic_ticket_purchase 是大麦网抢票的 Py网页爬虫工作流自动化上一篇Windows 11终极瘦身指南如何用Win11Debloat轻松清理系统垃圾下一篇Revery国际化方案多语言应用开发实践创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询