Files
JARVIS/development-doc/plan/agent-update/phase-3-dynamic-collaboration.md
WIN-JHFT4D3SIVT\caoxiaozhu a3fe4d24fc feat(agents): Phase 7-10 hook system, plugins, skills, orchestration
Phase 7: Built-in Hooks (audit_log, dangerous_confirmation, security_scan)
Phase 8: Plugin system (PluginManager, PluginSandbox, PluginManifest)
Phase 9: Skills registry (SkillRegistry, local/plugin/MCP loaders)
Phase 10: TeamLeader, RemoteTransport, BackgroundTaskManager
2026-04-04 22:56:27 +08:00

5.2 KiB
Raw Permalink Blame History

Phase 3动态协作阶段Dynamic Collaboration

日期2026-04-03 状态:已实现受限基线,仍有扩展空间


1. 阶段目标

在 Phase 2 已具备任务拆解、owner 分配、结果回收、verifier 收尾的基础上,让 Jarvis 获得受约束的动态协作能力

这一阶段的重点不是做成无限 swarm而是做到

  • 协作运行时能追踪 parent / root / depth
  • 动态创建行为受到权限和预算限制
  • 内部消息和事件能留下轨迹
  • 长流程可以中断和恢复
  • 所有动态行为都可观察、可审计

2. 当前代码中已落地的能力

当前 Jarvis 已经在 backend/app/agents/graph.py 中落地了 Phase 3 的核心基线。

2.1 Agent tree tracking

当前 state 已具备:

  • agent_id
  • parent_agent_id
  • root_agent_id
  • collaboration_depth
  • spawned_agent_ids

这意味着当前已经可以追踪:

  • 谁是根 agent
  • 谁创建了谁
  • 当前协作深度是多少
  • 本轮生成了哪些 child agents

2.2 受限动态创建

当前已具备:

  • _create_child_agent() 负责生成 child agent id
  • _spawn_permission_for_role() 控制哪些角色可创建子 agent
  • 基于 budget / role policy / depth 的限制已存在
  • 若不满足条件,会记录 agent.spawn.blocked

换句话说,当前已经不是“自由创建”,而是受治理的动态创建

2.3 生命周期事件

当前已具备事件类型:

  • agent.created
  • agent.spawn.blocked
  • agent.message.sent
  • agent.message.received
  • agent.interrupt.requested
  • agent.interrupt.completed
  • agent.recovery.started
  • agent.recovery.completed
  • agent.task.interrupted
  • agent.task.recovered
  • agent.task.reassigned
  • agent.collaboration.budget.updated

本次又新增:

  • agent.phase.changed
  • agent.checkpoint.recorded

说明当前运行时已经具备较完整的协作生命周期可见性

2.4 Interrupt / Recovery

当前已具备:

  • _record_interrupt()
  • _record_recovery()
  • interrupted_tasks
  • recovery_trace
  • recovery_points

这使得长流程协作已经具备最小中断 / 恢复链路,而不只是一次性执行。


3. 本次补强Phase 3 显式阶段与检查点

本次改动把原本分散在运行时内部的动态协作过程,进一步显式化。

3.1 Phase 切换

在协作 flow 中,现在会显式进入:

  • phase_2_controlled_collaboration
  • phase_3_dynamic_collaboration
  • phase_4_visibility_and_verification

其中 phase_3_dynamic_collaboration 表示:

  • 子任务已进入 dispatch / spawn / child execution 阶段
  • 运行时已经处于真实的动态协作执行态

3.2 Dynamic Collaboration checkpoints

当前已记录的关键 checkpoint 包括:

  • collaboration.task_dispatch
  • collaboration.task_result_collected

它们分别表示:

  • 某个 task 已被派发给 child agent 执行
  • 某个 task 的结果已被回收并进入统一状态

这使得 Phase 3 已经从“逻辑隐含”变成“运行时显式可追踪”。


4. 当前实现对应关系

设计目标 当前状态 落点
Parent/root/depth 追踪 已实现 state.py + graph.py
受限动态创建 已实现 _create_child_agent, _spawn_permission_for_role
预算快照 已实现 budget_state, collaboration_budget_history
生命周期事件 已实现 event_trace, schemas/event.py
中断 / 恢复记录 已实现 _record_interrupt, _record_recovery
phase / checkpoint 显式化 已实现 state.py, graph.py
独立 EventBus 未独立落地 当前以 event_trace 代替
Worker 主动发起新一轮协作 未完全开放 当前仍以受控主路径为主

5. 与原方案相比的调整

原方案强调:

  • 独立 event_bus.py
  • 独立 dynamic/
  • 独立 recovery/

而当前代码采取的是:

  • 先把动态协作基线做到 graph.py 内可运行
  • 再通过 event_trace / recovery_trace / budget_state 稳定对外暴露
  • 最后再决定是否做物理模块拆分

因此文档应调整为:

已完成的能力层

  • 动态协作并不是未来规划,而是已存在的运行时能力
  • 当前已经具备最小治理、最小动态创建、最小恢复机制

尚未完成的工程层

  • 还没有真正的发布/订阅式 EventBus
  • 还没有对外开放 worker 自主再委派能力
  • 还没有把 dynamic / recovery 拆成单独模块目录

6. 验收结论

当前 Phase 3 可以按“已实现受限基线”验收:

  • parent / root / depth 可追踪
  • child agent 创建行为受预算和权限约束
  • spawn blocked 会留下事件证据
  • 协作消息与事件链路可重建
  • interrupt / recovery 有最小闭环
  • phase / checkpoint 已可记录
  • 尚未形成真正的发布订阅 EventBus
  • 尚未开放更自由的 worker→worker 动态协作

7. 真实边界

当前 Phase 3 的真实状态是:

Jarvis 已经具备“带约束的动态协作运行时”,但仍不是一个无限扩张、自由重组的 swarm 平台。

这正是当前阶段应该保持的边界:

  • 先保证治理
  • 再考虑放宽动态能力
  • 先保证 trace / verifier / budget 成熟
  • 再考虑更强自治