Files

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 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 成熟
再考虑更强自治

5.2 KiB Raw Blame History Unescape Escape