feat(beaver): 完成Task Team功能v1实现，重构后端架构支持统一内核

新增内部Task系统，包括验证、反馈门控机制，实现自动质量验证 (通过率>=0.75)和用户反馈闭环(satisfied/revise/abandon)。实现Agent Team v1协调器，支持sequence/parallel/dag执行策略， sub-agent复用主AgentLoop，每个run使用独立memory snapshot。建立Skill学习pipeline，包含draft/审核/发布/回滚完整生命周期，通过Task验证通过且用户满意才生成学习候选。重构目录结构，移除third_party依赖，建立统一engine内核，所有agent共享运行时基础组件。更新ContextBuilder清理provider消息字段，增强SkillContext版本管理，集成TaskExecutionPlanner和TaskSkillResolver实现技能解析机制。
2026-05-08 17:14:14 +08:00
parent 5ba5c7e4c1
commit 8a12c30141
93 changed files with 16724 additions and 1247 deletions
--- a/app-instance/backend-old/change.md
+++ b/app-instance/backend-old/change.md
@ -29,6 +29,78 @@

 所以这次重构不是简单“整理目录”，而是把项目从“围绕一个 CLI 主 agent 生长出来的系统”升级成“所有 agent 共享同一内核的自有 agent harness 平台”。

+### 1.1 当前落地状态（2026-05-07）
+
+截至当前实现，新 `app-instance/backend/beaver` 已经把主链推进到：
+
+1. `AgentService` 前面增加了 Main Agent 路由层。
+   - 简单问题直接走原有 `AgentLoop` 单轮回答。
+   - 复杂任务自动进入内部 Task 模式。
+   - 前端和外部调用仍只使用聊天入口，不暴露显式创建 Task 的产品 API。
+2. 新增内部 Task 子系统：
+   - `beaver/tasks/models.py`
+   - `beaver/tasks/store.py`
+   - `beaver/tasks/service.py`
+   - `beaver/tasks/router.py`
+   - `beaver/tasks/validation.py`
+3. Task 模式已经能把一次或多次 `RunRecord` 归属到内部 `task_id`。
+   - `RunRecord` 增加 `task_id`
+   - `RunRecord` 增加 `attempt_index`
+   - `RunRecord` 增加 `validation_result`
+4. Task 模式每轮完成后会自动验证。
+   - 验证输入包含 task goal、用户请求、可见 transcript excerpt、工具摘要、最终输出。
+   - 验证通过标准为 `passed=true` 且 `score >= 0.75`。
+   - 验证失败自动重试一次；第一次失败尝试不会继续留在可见上下文。
+5. 用户反馈闭环已经接入最小产品面。
+   - `POST /api/chat/feedback`
+   - 前端最新 assistant 消息下显示“满意 / 需要修改 / 放弃”
+   - 反馈通过 `run_id -> task_id` 找到内部 Task
+   - 反馈状态会投影回 session 可见消息，刷新后仍保留
+6. 学习触发已经从“run 完成即候选”收紧为 Task 门控。
+   - 普通 run 仍记录运行收据和 skill effect
+   - Task 模式先只记录 receipts
+   - 只有“自动验证通过 + 用户满意”才生成成功学习候选
+   - “放弃”写 Failure Memory，不生成成功 Skill draft
+7. Agent Team v1 已经落成 Beaver 自有轻量 coordinator。
+   - `TeamService.run_team(...)` 是内部服务入口
+   - `LocalAgentRunner` 让 sub-agent 复用主 `AgentLoop.process_direct()` / `submit_direct()`
+   - 已支持 `sequence / parallel / dag`
+   - `parallel` 和 DAG 同层节点保持真并发
+   - 每个 run 使用独立 memory snapshot
+   - 支持 pinned skill 继承和 per-node provider factory
+   - sub-agent run 归入父 Task
+   - 节点级异常归一成 `NodeRunResult`
+8. Agent Team 已接入 Task mode 内部执行策略。
+   - `TaskExecutionPlanner` 使用 LLM JSON 规划 `single / team`
+   - team node 只声明 `skill_query / required_capabilities`，不声明固定 specialist 人设
+   - `TaskSkillResolver` 为 generic sub-agent 选择 published skill；未命中时生成 draft-only skill，并作为本次 run 的 ephemeral pinned instruction 使用
+   - team 模式调用 `TeamService.run_team(...)` 产生 sub-agent runs
+   - team 输出注入主 Agent synthesis run
+   - 用户可见最终回答仍由主 Agent 生成，并继续走验证、反馈和学习门控
+   - planner 失败或 graph 非法时降级 `single`
+
+当前仍未落地的部分：
+
+1. Agent Team 不暴露产品级聊天路由或显式 Task API；当前作为 Task 内部 sub-agent 执行策略。
+2. `moa / hierarchy / heavy / group_chat / forest / maker / router` 仍是策略预留，不是 v1 完整行为。
+3. 自动验证目前是 LLM validator，不是 replay sandbox。
+4. Skill draft synthesis / review / publish 安全链已有基础服务，但还没有做成完整后台学习 pipeline。
+5. `/api/agents` 和 agent registry 可作为未来外部 agent/A2A 管理面保留，但不参与 Task sub-agent 选择。
+6. 不允许在线直接改 published skill，这条约束保持不变。
+
+### 1.2 参考项目核对说明
+
+这版蓝图不是只根据印象在写。`2026-05-06` 我们已经重新核对过下面三个参考项目的公开入口文档：
+
+1. `OpenHarness`
+   - <https://github.com/HKUDS/OpenHarness>
+2. `hermes-agent`
+   - <https://github.com/NousResearch/hermes-agent>
+3. `swarms`
+   - <https://github.com/kyegomez/swarms>
+
+这一步的目的不是“照着抄目录”，而是把“到底借什么、不借什么”明确写死，避免后续施工时又把第三方项目的实现细节直接揉回 Beaver。
+
 ## 2. 我是怎么想的

 我的核心判断是：我们不能继续把第三方库、业务流程、执行控制、UI/API 接口揉在一起，而是应该先定义我们自己的稳定边界，再让第三方能力挂进来。
@ -40,6 +112,21 @@
 3. 用 `OpenHarness` 的强项来解决“工程边界、模块职责、可维护性”。
 4. 最终收口成我们自己的抽象和目录，而不是长期让第三方结构反向塑造我们。

+这里把三者的借鉴边界再说得更具体一点：
+
+1. `OpenHarness`
+   - 借它的 harness 分层方式：`engine / tools / skills / permissions / memory / coordinator / prompts / config`
+   - 借它“一条统一 loop + 明确 tool registry / permission / hook 边界”的工程组织方式
+   - 不直接照搬它的 CLI/TUI、commands、plugin 生态，也不要求 Beaver 长成它的目录镜像
+2. `hermes-agent`
+   - 借它的 memory / session / session_search / skills 运行时关系
+   - 借它对 FTS5 transcript 搜索、长期记忆、显式 skill 注入、session lineage 的处理方向
+   - 不把“自动学习闭环、完整渠道网关、全部终端后端、Honcho 用户建模”当成当前阶段必须同步迁入的范围
+3. `swarms`
+   - 借它已经验证过的多智能体执行形态，例如 sequential / hierarchy / rearrange / router 这类 orchestration 结构
+   - 借它作为 team execution backend 的角色，而不是借它来定义 Beaver 的主 runtime、session、tool、provider 契约
+   - 不再允许 Beaver 上层直接感知 `third_party/swarms`、`SwarmRouter` 参数细节或 import 副作用
+
 这意味着后续所有设计都应遵守四条原则：

 ### 2.1 我们要有自己的抽象
@ -296,9 +383,9 @@

 ## 4.2 彻底去掉 `third_party/`，把 `swarms` 改造成可替换 backend

-### 当前状态
+### 旧实现状态

-现在的 `agent_team` 已经接通：
+旧 `agent_team` 曾经接通：

 - `GroupChat`
 - `SequentialWorkflow`
@ -307,13 +394,41 @@
 - `MixtureOfAgents`
 - `HierarchicalSwarm`

-但这些能力还不是“平台正式能力集合”，而是“当前 bridge 恰好能跑通的一部分 swarms 类型”。
+但这些能力还不是 Beaver 的正式能力集合，而是“旧 bridge 恰好能跑通的一部分 swarms 类型”。

 更重要的是，当前它们依赖 `third_party/swarms` 这个 vendored 目录，这是后续必须去掉的。

+### 当前 Beaver 状态
+
+新后端已经先落地了不依赖 `third_party/swarms` 的 Agent Team v1：
+
+1. 自有核心模型：
+   - `AgentDescriptor`
+   - `DelegationEnvelope`
+   - `ExecutionNode`
+   - `ExecutionGraph`
+   - `NodeRunResult`
+   - `TeamRunResult`
+2. 内部服务入口：
+   - `TeamService.run_team(...)`
+3. 本地 delegated runner：
+   - `LocalAgentRunner`
+   - sub-agent 复用主 `AgentLoop.process_direct()` / `submit_direct()`
+4. 已实现策略：
+   - `sequence`
+   - `parallel`
+   - `dag`
+5. 已固定的安全语义：
+   - parent Task 必须存在且 session 匹配
+   - sub-agent run_ids 回填父 Task
+   - team/sub-agent 默认只写 receipts/effects，不生成 learning candidates
+   - learning candidates 仍只由 Task feedback gate 触发
+   - 节点级异常归一成 `NodeRunResult`
+   - summary 只聚合成功输出并列出失败节点
+
 ### 目标状态

-后续应该先定义我们自己的团队执行抽象：
+后续应该继续沿用我们自己的团队执行抽象：

 ```text
 TeamSpec
@ -325,31 +440,20 @@ TeamSpec

 然后：

-1. `SwarmsBackend` 只是 `StrategyBackend` 的一个实现。
+1. `SwarmsBackend` 如果以后存在，也只能是 `StrategyBackend` 的一个实现。
 2. 平台对外暴露的是自己的策略名和能力矩阵。
-3. `swarms` 只负责执行，不再负责定义平台边界。
+3. `swarms` 只提供可选执行或策略参考，不再负责定义平台边界。
 4. 仓库内不再保留 `third_party/`。
-5. `swarms` 要么作为外部依赖安装，要么把真正需要的最小能力内聚到我们自己的 backend 模块中。
+5. 高级策略可以先编译成 Beaver `ExecutionGraph` 或 step loop，而不是直接暴露 swarms runtime。

 ### 具体改法

-1. 抽出 `coordinator/backends/base.py`
-   - 定义统一 backend 接口
-2. 抽出 `coordinator/backends/swarms/`
-   - 把 `swarms_adapter.py`
-   - `swarms_bridge.py`
-   - `swarms_policy.py`
-   - `swarms_planner.py` 中 swarms 相关逻辑收进去
-3. 在平台层定义正式支持的 strategy
-   - `group_chat`
-   - `sequential`
-   - `concurrent`
-   - `rearrange`
-   - `mixture`
-   - `hierarchical`
-   - 后续预留 `graph`
-   - 后续预留 `heavy`
-4. 所有 strategy 的输入输出都转成我们的统一模型
+1. 保留当前 `coordinator/models.py / local.py / execution/scheduler.py` 作为 v1 core。
+2. 在平台层继续扩展正式支持的 strategy。
+   - 已实现：`sequence / parallel / dag`
+   - 预留：`moa / hierarchy / heavy / group_chat / forest / maker / router`
+3. 高级 strategy preset 先转成 `ExecutionGraph` 或 step loop。
+4. 如果后续接外部 swarms，单独放进 `coordinator/backends/swarms/`，并统一输入输出为 Beaver models。

 ### 结果

@ -357,7 +461,7 @@ TeamSpec

 1. `third_party/` 目录消失。
 2. 上层不再知道 `third_party/swarms` 这个路径。
-3. 对上层透明的是 `SwarmsBackend`，不是 vendored 源码目录。
+3. 对上层透明的是 Beaver 自有 team model 和 `TeamService`，不是 vendored 源码目录。

 ## 4.3 把 `skills` 从静态文档升级成能力生命周期系统

@ -404,10 +508,56 @@ TeamSpec

 正确链路应该是：

-`run result -> procedure candidate -> skill draft -> review -> publish -> runtime use`
+`Task -> validated run result -> user feedback -> learning candidate -> skill draft -> review -> publish -> runtime use`

 这比“自动改 `SKILL.md`”安全得多，也更适合生产环境。

+把它再展开成运行时视角，应该是下面这种树形过程：
+
+```text
+一次 Task 模式 run 完成
+│
+├─ 记录本轮结果并归属内部 Task
+│  ├─ RunRecord
+│  ├─ task_id / attempt_index
+│  ├─ SkillActivationReceipt[]
+│  └─ SkillEffectRecord[]
+│
+├─ 自动验证
+│  ├─ ValidationResult
+│  ├─ task_validation_snapshotted hidden event
+│  └─ RunRecord.validation_result
+│
+├─ 如果验证失败
+│  ├─ 自动修订一次
+│  ├─ 失败草稿尝试从可见上下文隐藏
+│  └─ 第二次仍失败则等待用户反馈，不进入成功学习
+│
+├─ 用户反馈
+│  ├─ satisfied（验证通过后关闭 Task，并生成成功学习候选）
+│  ├─ revise（Task 进入 needs_revision，下一条消息复用该 Task）
+│  └─ abandon（Task 进入 abandoned，写 Failure Memory）
+│
+├─ 聚合 skill 历史表现
+│  └─ SkillPerformanceSnapshot
+│
+├─ 生成学习候选
+│  ├─ revise_skill
+│  ├─ new_skill
+│  ├─ merge_skills
+│  └─ retire_skill
+│
+├─ 如需真正演化：
+│  ├─ evidence selection
+│  ├─ skill draft synthesis
+│  ├─ review
+│  ├─ publish / disable / rollback
+│  └─ runtime catalog 切换到新的 published version
+│
+└─ 明确禁止：
+   └─ agent 直接在线改 live `SKILL.md`
+```
+
 ### 结果

 改完之后，skills 不再只是 prompt 资源，而是平台知识层的一等对象。
@ -557,23 +707,26 @@ CLI 不是“单 agent 专用模式”。

 ### 现在

-`spawn_agent_team -> DelegationManager -> AgentTeamOrchestrator -> SwarmsPlanner/Bridge -> SwarmRouter`
+`TeamService.run_team -> TeamGraphScheduler -> LocalAgentRunner -> AgentLoop.process_direct / submit_direct`
+
+Task mode 内部已经变成：
+
+`AgentService._run_task_mode -> TaskExecutionPlanner -> optional TeamService.run_team -> 主 Agent synthesis run -> ValidationService`

 ### 之后

-`spawn_agent_team`
-`-> DelegationService`
-`-> TeamApplicationService`
-`-> TeamPlanner`
-`-> ExecutionPlan`
-`-> StrategyBackendRegistry`
-`-> SwarmsBackend`
+`TeamService`
+`-> strategy preset`
+`-> ExecutionGraph`
+`-> TeamGraphScheduler`
+`-> LocalAgentRunner / optional StrategyBackend`
 `-> NormalizedTeamResult`

 结果是：

 1. 团队能力不再绑定某个第三方 runtime 结构。
-2. 可以逐步增加第二种 backend，而不推翻平台层。
+2. v1 已经支持 `sequence / parallel / dag`。
+3. 可以逐步增加高级 preset 或第二种 backend，而不推翻平台层。
 3. `swarms` 只是其中一个可插拔执行器。

 ## 5.3 skill 场景
@ -601,7 +754,23 @@ CLI 不是“单 agent 专用模式”。

 ### 现在

-`Run details 混在 session / memory / procedure 中`
+新后端已经不再把复杂任务学习完全混在 session / memory / procedure 中。
+
+当前实际状态是：
+
+`Chat input`
+`-> MainAgentRouter`
+`-> simple answer 或 internal Task`
+`-> RunRecord + TaskEvent + ValidationResult`
+`-> /api/chat/feedback`
+`-> satisfied / revise / abandon`
+
+也就是说：
+
+1. Task 是复杂任务的内部执行容器。
+2. Run 仍是一次模型/tool loop 的执行收据。
+3. ValidationResult 是进入学习前的自动质量门。
+4. 用户反馈是成功学习和失败记忆的最终门控。

 ### 之后

@ -625,6 +794,8 @@ CLI 不是“单 agent 专用模式”。
 1. durable facts、历史细节、稳定方法三类信息终于分层。
 2. 自动学习不会把临时过程污染到主 memory。
 3. skills 仍是最高层指导系统，而 memory 变成受控 CRUD 系统。
+4. 成功 Skill 学习只能来自验证通过且用户满意的 Task。
+5. 放弃或验证失败只进入 Failure Memory / 风险记忆，不污染 published skill。

 ## 6. 分阶段落地建议

@ -636,13 +807,13 @@ CLI 不是“单 agent 专用模式”。

 1. 把入口装配统一掉
 2. 把 `web/server.py` 开始拆分
-3. 把 swarms 相关代码聚到单独 backend 目录
+3. 先落地 Beaver 自有 Agent Team v1 core，避免继续依赖 vendored swarms

 交付物：

 - 统一 app factory / service wiring
 - 初步拆分 web routes
- `orchestration/backends/swarms/`
+- `coordinator/models.py / local.py / execution/scheduler.py`

 ### 第二期：平台抽象固化

@ -653,7 +824,7 @@ CLI 不是“单 agent 专用模式”。

 交付物：

- `TeamSpec`
+- `AgentDescriptor / ExecutionGraph / TeamRunResult`
 - `SkillSpec`
 - `ExecutionPlan`
 - `MemoryEntry`
@ -670,6 +841,39 @@ CLI 不是“单 agent 专用模式”。
 2. 打通“稳定方法 -> SkillDraft”
 3. 按 Hermes 基线完成 memory CRUD、frozen snapshot、session_search

+这一期里的“学习/自进化”过程，建议始终按下面这条线施工：
+
+```text
+run
+│
+├─ receipt collection
+│  ├─ RunRecord
+│  ├─ SkillActivationReceipt
+│  └─ SkillEffectRecord
+│
+├─ evidence aggregation
+│  ├─ session transcript
+│  ├─ curated memory
+│  ├─ current published skill version
+│  └─ repeated user corrections / outcomes
+│
+├─ learning candidate generation
+│  ├─ new_skill
+│  ├─ revise_skill
+│  ├─ merge_skills
+│  └─ retire_skill
+│
+├─ draft lifecycle
+│  ├─ create draft
+│  ├─ review
+│  ├─ publish
+│  ├─ disable
+│  └─ rollback
+│
+└─ runtime use
+   └─ 只暴露 published version 给运行时
+```
+
 交付物：

 - skill catalog
@ -741,19 +945,22 @@ app-instance/backend/
 │   │   ├── runs/                    # 单次执行记录
 │   │   ├── procedures/              # 可选的流程复用优化层
 │   │   └── stores/                  # 底层存储与原子写实现
+│   ├── tasks/                       # 内部 Task 系统：自动 Task 化、验证、反馈、失败记忆入口
+│   │   ├── models.py                # TaskRecord / TaskEvent / ValidationResult
+│   │   ├── store.py                 # Task 文件存储
+│   │   ├── service.py               # Task 状态机与反馈处理
+│   │   ├── router.py                # MainAgentRouter simple/task 分类
+│   │   └── validation.py            # LLM validator 与验证结果归一化
 │   ├── permissions/                 # 权限、沙箱、治理规则
 │   │   ├── policies/                # 权限策略
 │   │   ├── guards/                  # 执行前检查
 │   │   └── profiles/                # 不同 agent 运行权限画像
 │   ├── coordinator/                 # 多 agent 协调层，参考 OpenHarness 的 coordinator 风格
-│   │   ├── delegation/              # 委派与任务分发
-│   │   ├── registry/                # agent registry 与 agent descriptor
-│   │   ├── planner/                 # 团队 planning 与 execution plan 生成
-│   │   ├── execution/               # 执行控制、fallback、聚合
-│   │   ├── backends/                # 可替换的多 agent backend
-│   │   │   ├── base.py              # backend 抽象接口
-│   │   │   └── swarms/              # swarms backend 封装，不再直接暴露第三方目录
-│   │   └── team/                    # team 级模型与编排对象
+│   │   ├── models.py                # AgentDescriptor / ExecutionGraph / TeamRunResult
+│   │   ├── local.py                 # LocalAgentRunner：复用主 AgentLoop
+│   │   ├── execution/               # sequence / parallel / dag 调度与聚合
+│   │   ├── backends/                # 后续可替换多 agent backend
+│   │   └── team/                    # team 级模型 re-export / 后续高级编排对象
 │   ├── services/                    # application services，对外提供统一能力入口
 │   │   ├── agent_service.py         # 统一 agent 运行入口
 │   │   ├── team_service.py          # 多 agent 执行入口
@ -797,3 +1004,35 @@ app-instance/backend/
 3. 把 `skills` 从“静态 Markdown 包”升级成“可学习、可审核、可发布、可回滚的能力系统”。

 如果这三件事做成了，后面再扩多智能体架构、自动学习、插件生态、外部接入，代码就不会继续失控。
+
+---
+
+## 9. 最新落地状态：Task Team 后三件套
+
+本轮已经把 Task Team 融合后的三个缺口推进到 v1 可用状态：
+
+1. **Task Sub-agent Skill Resolver**
+   - 新增 `beaver/tasks/skill_resolver.py`。
+   - sub-agent 是临时 generic worker，不承载固定角色人设。
+   - `TaskExecutionPlanner` 的 team node 输出 `skill_query / required_capabilities / expected_output`。
+   - `TaskSkillResolver` 从 published skill catalog 中选择合适 skill，并写入 node pinned skills。
+   - 如果没有命中 published skill，会创建 draft-only skill，并把 draft 内容作为本次 sub-agent 的 ephemeral pinned skill context 使用。
+   - draft 不自动 approve/publish，不进入 runtime catalog；后续仍走 review/publish。
+   - agent registry / target resolver 不参与 Task sub-agent strategy，可作为未来外部 agent/A2A 管理面保留。
+
+2. **Task Team Process Projection**
+   - Task attempt 隐藏事件增加 `skill_queries / selected_skill_names / generated_skill_draft_ids / skill_resolution_report / node_results / task_synthesis_completed`。
+   - 新增 `GET /api/sessions/{session_id}/process`。
+   - 前端 `ChatWorkbench` 已接入 `ProcessLane` 和移动端 `Process` tab。
+   - 展示规划、skill selection、draft-only ephemeral guidance、team node、main synthesis、validation/retry，不把 team summary 直接当最终回答。
+
+3. **Learning Pipeline 闭环**
+   - 新增 `SkillLearningPipelineService`。
+   - Web API 覆盖 candidates、drafts、submit、approve、reject、publish、disable、rollback。
+   - `/skills` 页面增加 Published / Candidates / Drafts tabs。
+   - publish 仍要求 approved draft；rejected draft 不可 publish；draft 不进入 runtime catalog。
+
+验证状态：
+
+- 后端：`76 passed`。
+- 前端：`npm run typecheck` 通过，`npm test` 通过，`npm run lint` 通过但仍有既有 warnings。