Files

steven_li 5ba5c7e4c1 feat(app-instance): 集成Beaver后端并更新配置管理

集成新的Beaver后端服务到应用实例中，替换原有的nanobot实现。

主要变更包括：
- 在Dockerfile和环境配置中添加Beaver相关路径和配置变量
- 更新工作目录结构从.nanobot到.beaver
- 实现Beaver引擎加载器，支持配置文件加载和工具组装
- 添加内置工具如ListDirectoryTool、ReadFileTool、SearchFilesTool
- 更新消息处理流程，支持通道适配器和网关模式
- 重构技能系统，支持显式工具提示和嵌入式检索
- 改进错误处理和生命周期管理

此变更使应用实例能够使用统一的Beaver后端进行AI代理运行时管理。

2026-04-27 17:37:40 +08:00

26 KiB

Raw Blame History

Beaver Backend Flow

这份文档只记录两件事：

我们为什么这么实现
当前代码里真实已经实现了什么

它不是蓝图，也不是未来设计草稿。以后只要主链、装配逻辑、运行时边界发生变化，就必须同步更新它。

1. 参考项目各自借什么

当前 Beaver 的实现思路，主要借了三个参考项目，但借的点是分开的。

1.1 `OpenHarness`

借的是模块边界和 Harness 形态：

Harness / Runtime 应该和 Web、Gateway、产品接入分开
skills / memory / tools / session / orchestration 都属于平台层
运行时最好是可装配的，而不是所有逻辑都塞进一个大 agent 类

所以 Beaver 现在一直在做的事情，是把：

EngineLoader
AgentLoop
ContextBuilder
Session
Tools
Skills

收成一个清晰的运行内核。

1.2 `hermes-agent`

借的是memory、skills、session 的运行时风格：

memory 用 curated CRUD + frozen snapshot
session_search 查历史细节，不把所有历史都塞进 memory
skills 用：
- 显式 skill loading path
- 激活后的 skill 正文显式注入

所以 Beaver 现在这些点都明显受 Hermes 影响：

MemoryService + frozen snapshot
session_search
skill_view
activated skill messages

1.3 `swarms`

借的是后面多智能体 orchestration 的方向：

team orchestration
swarm strategy
multi-agent execution backend

但要注意：它现在还不是当前主链的核心。
当前我们主要先把单 agent runtime 打稳，多智能体还没正式接回主链。

2. 当前我们到底做到哪了

当前已经不是“搭骨架”阶段了，而是：

最小单 agent runtime 已经跑通。

现在已经完成的核心段落是：

4.1 session
4.2 provider
4.3 context
4.4 tools framework + 最小内建工具
4.5 最小主链
5.1 memory 最小接入
5.2 skills 最小接入
6.1 session-first / event-source 第一阶段
6.2 runtime lifecycle 最小骨架
6.2.1 Web / Gateway 最小接主链
app-instance Docker 镜像切到新 beaver 后端

更准确地说，当前 Beaver 已经有：

一个可运行的 AgentService -> AgentLoop 主链
一个外部化的 Session 子系统
一个可工作的 tool loop 框架
Hermes 风格的 memory / skills 接入
LLM-driven 的 SkillAssembler
embedding-driven 的 ToolAssembler
MCP-style 本地工具描述
skill frontmatter tools 会影响本轮工具选择
start()/submit_direct()/stop()/shutdown()/close() 最小 lifecycle
FastAPI /api/ping + /api/chat
Gateway MessageBus -> AgentService -> MessageBus 最小桥接
Docker app-instance 使用 /root/.beaver/config.json 和 /root/.beaver/workspace

已经实测通过：

Docker image build
container /api/ping
/api/chat 调用 qwen-plus
Session SQLite 事件写入
宿主机 curl 直连 app-instance

但还没有：

shell / web 等高风险或外部访问工具
完整 tool permission gates
Web / Gateway 的 realtime streaming
bus retry / routing / persistence
delegation / swarm / team runtime
MCP 全量工具接回 runtime
checkpoint / rewind / fork / crash-resume
skill selector 的 embedding / LLM 选择细节还没有写入 Session event stream
前端完整 auth / sessions / skills / files / ws 兼容新 Beaver API

3. 当前真实主链

当前主入口已经不是 CLI 逻辑，而是：

service = AgentService()
await service.process_direct("你好")

上面是 direct/debug path。宿主层进入运行模式后，正式入口是：

service = AgentService()
await service.start()
result = await service.submit_direct("你好")
await service.stop()
service.close()

宿主层现在也已经开始接到这条 lifecycle 上：

app = create_app()        # FastAPI lifespan 内部托管 AgentService.start()/shutdown()
await run_gateway()       # Gateway 常驻进程托管 AgentService.start()/shutdown()

模型与 provider 配置现在从 backend sandbox config 统一读取，而不是从前端或 channel 请求里传密钥。Docker 单实例部署时，配置路径优先级是：

BEAVER_CONFIG_PATH
NANOBOT_CONFIG_PATH
BEAVER_HOME/config.json
NANOBOT_HOME/config.json
<workspace>/.beaver/config.json

当前 app-instance 会把每个用户实例自己的数据目录挂到 /root/.beaver，所以 Beaver 会默认读取：

/root/.beaver/config.json

这份配置跟随单个 sandbox 容器/数据卷，不放在前端，也不放在宿主机全局目录。 Web / Gateway / Channel 只传 message/session_id/user_id 等业务输入。

app-instance 镜像当前也已经切到新 Beaver 后端：

entrypoint.sh
├─ 启动 python -m uvicorn beaver.interfaces.web.app:create_app --factory
├─ 使用 /root/.beaver/config.json
└─ 使用 /root/.beaver/workspace

旧的 nanobot web、backend/nanobot、backend/bridge、vendored swarms 不再进入新镜像。

这套 lifecycle 当前明确是：

start() 进入一个 AgentLoop 实例的运行模式
运行模式下，外部任务只能走 submit_direct()
运行模式下，不允许再直接调用 process_direct()
stop() 是 instance-scoped
- 只针对当前这个 AgentLoop 实例
- 不是 session-scoped
- 也不是 platform-scoped
stop() 调用后会拒绝新任务，已入队任务正常收尾
stop() / shutdown() 支持 graceful timeout；必要时可 force cancel
close() 只能在该实例已停止后调用

3.1 Web / Gateway 当前怎么接

这一层现在已经不是纯占位了，而是最小宿主层：

beaver/interfaces/web/app.py
- FastAPI lifespan 启动时：
  - 创建或接收 AgentService
  - 如果 app 自己创建 service，则 await service.start()
- Web 接口现在有最小正式 schema：
  - WebChatRequest
  - WebChatResponse
  - WebStatusResponse
- /api/chat 请求：
  - 用结构化 request schema 校验输入
  - await service.submit_direct(...)
  - 把常见 runtime / config 错误收成 HTTP 错误
  - 外部注入但尚未进入 running mode 的 service，会返回 503
- /api/ping：
  - 返回 status/running/mode
  - 不会为了 health check 额外 boot runtime
- app 关闭时：
  - 如果 app 自己创建 service，则 await service.shutdown(timeout_seconds=5.0, force=True)
- app 自己接管 lifecycle 时：
  - 若 start() 失败，会立即 close() 做 startup cleanup
beaver/interfaces/gateway/main.py
- run_gateway() 启动时：
  - 如果 gateway 自己创建 service，则 await service.start()
- 持有最小 MessageBus
- 可选接收 ChannelManager / channel adapters
- ChannelManager 和 channels 参数二选一：
  - 传 ChannelManager：外部提前配置好 channel
  - 传 channels：gateway 内部创建 ChannelManager 并注册这些 channel
- inbound 流向：
  - channel adapter 发布 InboundMessage
  - MessageBus.inbound
  - gateway bridge 常驻消费
  - await service.handle_inbound_message(...)
- outbound 流向：
  - AgentService 内部完成 InboundMessage -> OutboundMessage 映射
  - gateway bridge 写回 MessageBus.outbound
  - 如果启用了 ChannelManager，则分发给对应 channel adapter
  - 未启用 ChannelManager 时，保留直接消费 bus.outbound 的最小测试能力
- 同时等待 stop_event
- 退出时：
  - 先尝试 await service.shutdown(timeout_seconds=5.0, force=True)
  - 再等待 bridge 协程收尾；必要时取消 bridge
  - 再等待 outbound dispatch 协程收尾；必要时取消 dispatch
- 如果 gateway 自己接管 lifecycle 且 start() 失败：
  - 会立即 close() 做 startup cleanup
- 未处理完的 inbound：
  - 不再静默丢下
  - 会被冲刷成结构化 outbound error
beaver/foundation/events/message_bus.py
- 已有最小：
  - MessageBus
  - InboundMessage
  - OutboundMessage
- 当前只做双队列桥接：
  - inbound
  - outbound
- 还没有 broker / topic routing / retry / persistence
beaver/interfaces/channels/*
- 已有最小 channel adapter 层：
  - ChannelAdapter
  - ChannelManager
  - MemoryChannelAdapter
- 当前 channel 职责很窄：
  - 把外部输入发布成 InboundMessage
  - 接收并投递 OutboundMessage
- MemoryChannelAdapter 只用于本地测试和内嵌接入，不是正式消息 broker

所以现在已经明确：

Web / Gateway 属于宿主层
它们不直接 new AgentLoop 或绕过运行模式
它们复用：
- start()
- submit_direct()
- stop()
- shutdown()
ownership 语义：
- 自己创建的 AgentService：自己负责 lifecycle
- 外部注入的 AgentService：默认不自动 start/shutdown，除非显式要求接管
gateway 已经从“只会常驻等待”推进到“最小消息桥接层”
- external inbound message
- channel adapter
- MessageBus.inbound
- service.handle_inbound_message(...)
- MessageBus.outbound
- channel adapter outbound delivery

3.2 总体链路

当前代码里的主链可以概括成：

AgentService
  -> AgentLoop
    -> Session
    -> Memory
    -> SkillAssembler
    -> ToolAssembler
    -> ContextBuilder
    -> Provider
    -> ToolExecutor
    -> Session writeback

3.3 详细顺序

用户输入 task
│
├─ AgentService.create_loop()
│  ├─ 创建 AgentLoop(profile, loader)
│  └─ loop.boot()
│
├─ AgentLoop.boot()
│  └─ EngineLoader.load()
│     ├─ SessionManager
│     ├─ MemoryStore
│     ├─ MemoryService
│     ├─ ToolRegistry
│     ├─ ToolAssembler
│     ├─ ToolExecutor
│     ├─ SkillsLoader
│     ├─ SkillAssembler
│     └─ ContextBuilder
│
├─ AgentLoop.process_direct(task)
│  │
│  ├─ 生成 `session_id` / `run_id`
│  │
│  ├─ memory_service.reload_for_new_run()
│  │  └─ 建立本轮 frozen memory snapshot
│  │
│  ├─ sessions.ensure_session(session_id)
│  ├─ sessions.append_message(event_type="run_started", hidden)
│  │
│  ├─ make_provider_bundle()
│  │  ├─ main provider
│  │  ├─ fallback provider
│  │  ├─ auxiliary provider 可用于 skill 选择
│  │  └─ embedding runtime 提供 embeddings 的 model/api_key/api_base
│  │     说明：它是独立配置线，只支持 OpenAI-compatible embeddings endpoint
│  │
│  ├─ skill_assembler.assemble(task_description=task, provider=selector_provider, embedding_runtime=..., ...)
│  │  ├─ 读取全量可用 skill 候选摘要
│  │  ├─ 用 `text-embedding-v4` 对全量候选做相似度召回
│  │  ├─ 把召回结果交给 LLM 做最终选择
│  │  └─ 返回 activated_skills
│  │
│  ├─ ContextBuilder.build_skill_activation_messages(...)
│  ├─ 如果 activated_skills 非空：
│  │  └─ sessions.append_message(event_type="skill_activation_snapshotted", hidden)
│  │
│  ├─ tool_assembler.assemble(task_description=task, activated_skills=..., ...)
│  │  ├─ always tools
│  │  │  ├─ memory
│  │  │  ├─ session_search
│  │  │  └─ skill_view
│  │  ├─ 读取 activated skill 的 frontmatter `tools`
│  │  ├─ 用 `text-embedding-v4` 对工具描述做相似度召回
│  │  ├─ 返回本轮选中的 ToolSpec
│  │  └─ ToolSpec 同时可导出 MCP descriptor 与 provider schema
│  │
│  ├─ sessions.append_message(event_type="tool_selection_snapshotted", hidden)
│  │
│  ├─ ContextBuilder.build_messages()
│  │  ├─ system prompt 包含：
│  │  │  ├─ base system prompt
│  │  │  ├─ session metadata
│  │  │  ├─ execution context
│  │  │  └─ frozen memory snapshot
│  │  ├─ messages 里显式插入 activated skill messages
│  │  ├─ 再拼 visible history
│  │  └─ 最后追加当前 user input
│  │
│  ├─ sessions.update_system_prompt()
│  ├─ sessions.append_message(event_type="system_prompt_snapshotted", hidden)
│  ├─ sessions.append_message(event_type="user_message_added")
│  │
│  ├─ 进入最小 tool loop
│  │  ├─ provider.chat(messages, tools=schemas)
│  │  ├─ sessions.update_usage()
│  │  ├─ sessions.append_message(event_type="assistant_message_added")
│  │  ├─ ContextBuilder.add_assistant_message(...)
│  │  ├─ 如果没有 tool calls：
│  │  │  └─ 结束
│  │  └─ 如果有 tool calls：
│  │     ├─ ToolExecutor.execute_tool_call(...)
│  │     ├─ sessions.append_message(event_type="tool_result_recorded")
│  │     ├─ ContextBuilder.add_tool_result(...)
│  │     └─ 再回 provider.chat(...)
│  │
│  ├─ 成功结束：
│  │  └─ sessions.append_message(event_type="run_completed", hidden)
│  │
│  ├─ 异常结束：
│  │  ├─ 补 assistant error message
│  │  └─ sessions.append_message(event_type="run_failed", hidden)
│  │
│  └─ return AgentRunResult
│     ├─ session_id
│     ├─ run_id
│     ├─ output_text
│     ├─ finish_reason
│     ├─ tool_iterations
│     ├─ provider_name
│     ├─ model
│     └─ usage

4. 当前模块边界

4.1 `EngineLoader`

职责：装配运行时依赖。

当前已经装配：

SessionManager
MemoryStore
MemoryService
ToolRegistry
ToolAssembler
ToolExecutor
SkillsLoader
SkillAssembler
ContextBuilder

4.2 `AgentLoop`

职责：执行单次 run。

当前已经负责：

direct run 主链
provider 调用
最小 tool loop
session 事件写回
usage 汇总

当前还没负责：

更复杂的 message bus mode
多 worker / 并发调度
provider/client 级 async shutdown hooks
multi-agent orchestration

4.3 `Session`

职责：外部化的运行事实存储。

当前实现重点：

sessions 表
- projection / summary row
messages 表
- 当前主事件流
run_id
- 把同一个 session 里的多次 run 切开

当前主要读取接口：

get_event_records(session_id)
- 整个 session 的完整事件流
get_run_event_records(session_id, run_id)
- 某一次 run 的事件片段
list_run_ids(session_id)
- 发现当前 session 中有哪些 run
get_visible_history(session_id)
- 给 ContextBuilder 用的可见历史切片
session_search
- 只检索可见 transcript
- 不把 hidden prompt / skill snapshot 当成搜索候选

当前关键 hidden 事件：

run_started
skill_activation_snapshotted
tool_selection_snapshotted
system_prompt_snapshotted
run_completed
run_failed

4.4 `Memory`

职责：durable facts，不是 transcript。

当前实现重点：

curated CRUD
frozen snapshot
每次新 run 开始时刷新 snapshot
当前 run 中途写 memory 不反向污染本轮 prompt

4.5 `Skills`

职责：外置 skill 装配与按需查看。

当前实现重点：

SkillsLoader
- 扫描 workspace/skills/*/SKILL.md
- 扫描 builtin skills
SkillAssembler
- 输入 task description + 候选 skill 摘要
- 先用 embedding 做语义召回
- 再调一次 LLM 直接选择 skills
- 没有匹配时返回空 skills
skill_view
- 显式加载 skill 正文或支持文件
activated skills
- 按 Hermes 风格作为显式消息注入

当前 skill 语义已经定成：

run-scoped
- skill 激活只对当前 run 生效
不是 session-scoped
- 不默认跨 run 持久化为 session 状态
explicit loading path
- skill_view
no-match means no skill injection
- 如果 assembler 没选出 skill
- 当前 run 不拼接 skill messages
- 也不会写 skill_activation_snapshotted

4.6 `Tools`

当前内建工具：

echo
memory
skill_view
session_search
list_directory
read_file
search_files

当前工具基础设施：

ToolSpec
- 以 MCP-style descriptor 作为本地统一描述
- 可导出 to_mcp_descriptor()
- 可导出 OpenAI-compatible to_provider_schema()
ObjectBackedTool
ToolRegistry
ToolExecutor
ToolAssembler

当前工具选择语义：

工具选择是 run-scoped
memory / session_search / skill_view / 只读 filesystem tools 是 always tools
activated skill 的 frontmatter 可声明：

---
tools:
  - terminal
  - read_file
---

ToolAssembler 会合并：
- always tools
- activated skill 显式声明的 tools
- task description embedding top10 tools
当前只信任 frontmatter / metadata 里的显式 tools，不从 skill 正文里猜工具名
如果 skill 声明了未注册工具，当前会忽略，不阻断 run

当前 filesystem tools 的边界：

list_directory 只能列当前 ToolContext.workspace 内的目录
read_file 只能读 workspace 内 UTF-8 文本文件
search_files 只能搜索 workspace 内文件名和 UTF-8 文本内容
绝对路径如果解析后不在 workspace 内，会拒绝
workspace 内指向外部的符号链接，读取 / 搜索时会拒绝
二进制文件会拒绝读取，并在搜索时跳过

当前还没有默认注册：

shell / exec tools
web search / web fetch tools
MCP tools
spawn / team tools

4.7 `Providers`

当前已经实现：

provider registry
runtime resolution
main provider
fallback provider
auxiliary provider
embedding runtime 配置线

当前状态：

fallback 已经是“每次调用都先 main，再 fallback”
auxiliary provider 已经可用于 skill 选择
embedding runtime 当前用于 SkillAssembler 的候选召回
embedding runtime 当前也用于 ToolAssembler 的工具召回
auxiliary provider 还没有进入主对话 tool loop

5. 当前最重要的设计决定

这几条是现在已经定下来的，不应该再反复漂：

5.1 `Session-first`

当前 Beaver 明确在往这个方向走：

运行事实优先写回 Session
Session 是 replay / audit / resume 的基础
prompt 不是状态源，Session 才是

5.2 `Harness != Product Interface`

当前主入口已经是：

AgentService
AgentLoop

而不是 CLI 本身。
CLI、Web、Gateway 后面都应该只是接口层。

5.3 `Skill selection` 外置

已经不再让 AgentLoop 自己“决定该选哪个 skill”，而是：

task description
  -> SkillAssembler
    -> AgentLoop

5.4 `Skills` 采用 Hermes 风格

不是：

skill 正文长期塞进 system prompt
summary 让模型自己猜怎么展开

而是：

activated skill messages
skill_view

5.5 `Tools` 采用 MCP-style 描述

当前本地工具不再只是一段 OpenAI function schema，而是先收敛成：

ToolSpec
├─ name
├─ description
├─ input_schema
├─ toolset
└─ always_available

其中 name/description/input_schema 可直接导出 MCP-style descriptor：

{
  "name": "memory",
  "description": "...",
  "inputSchema": {}
}

provider 需要的 OpenAI-compatible schema 由 ToolSpec.to_provider_schema() 转换出来。

6. 对照施工指南，我们现在处于哪一步

这部分严格对齐 施工指南.md 的第 6 阶段编号，不再自行改号。

6.1 第一步：Session 升级为事件源模型

当前状态：基本完成第一阶段目标，但还不是完整 event-source 系统。

已经具备：

messages 表已经承担主事件流语义
每次 run 都有独立 run_id
AgentLoop.process_direct() 已按事件阶段写回 Session
已有：
- get_event_records(session_id)
- get_run_event_records(session_id, run_id)
- list_run_ids(session_id)
- get_visible_history(session_id)
session_search 只检索可见 transcript，不把 hidden snapshots 当搜索候选

当前还没做：

checkpoint
rewind
fork session
crash-resume protocol

所以更准确地说：

6.1 的“Session-first / event-source 第一阶段”已经落地
但更完整的 event-source 能力还没有做完

6.2 第二步：runtime 生命周期协议补齐

当前状态：最小 lifecycle 骨架已经完成。

已完成：

EngineLoadResult.close()
AgentLoop.close()
AgentService.close()
AgentService.shutdown()
AgentLoop.run()
AgentLoop.stop()
AgentLoop.submit_direct()
AgentService.start()
AgentService.stop()
AgentService.submit_direct()

还没做：

统一 shutdown hooks
更完整的 provider/client 资源释放协议
多 worker / bus / 调度策略

6.2.1 Web / Gateway 现在如何接这套 lifecycle

当前状态：最小宿主层接入已经完成。

已经完成：

Web 通过 FastAPI lifespan 托管 AgentService.start()/shutdown()
Web 请求只走 AgentService.submit_direct()
Gateway 已有最小 MessageBus -> AgentService.handle_inbound_message() -> MessageBus 桥接
Gateway 已支持可选 ChannelManager，把 outbound 分发回 channel adapter

当前 app-instance Docker 已完成：

Dockerfile 只安装 backend/beaver
entrypoint 启动 beaver.interfaces.web.app:create_app
每个实例挂载 /root/.beaver
配置读取 /root/.beaver/config.json
workspace 使用 /root/.beaver/workspace
宿主 curl /api/chat 已实测通过

这一小步还没做：

realtime streaming
retry / broker persistence
外部真实 channel adapter 全量接入

6.3 第三步：回填 bus 模式

当前状态：只完成了前置地基，还没有按施工指南真正收口。

已经具备的前置件：

MessageBus
InboundMessage
OutboundMessage
AgentService.handle_inbound_message()
Gateway bridge 常驻消费 inbound 并写回 outbound
AgentLoop.run() 已有最小运行循环

但严格按 施工指南.md 来看，6.3 还没有正式完成，因为现在还缺：

把 bus mode 明确成 runtime 的正式运行形态之一
明确 run() 如何稳定消费 inbound message
明确 bus mode 与 direct mode / queue mode 的职责边界
明确停机、取消、冲刷 pending inbound 时的统一语义
再决定后续是否需要更复杂的 worker / retry / routing

也就是说：

现在不是“还没 bus”
而是“已经把 bus 协议映射收口到 AgentService，但还没按施工指南把它扩成完整 bus runtime 模式”

6.4 单 agent lifecycle 如何扩展到 team

当前状态：关系已经定死，但实现还没开始。

当前已经明确：

team 不会共享一个大 AgentLoop 跑所有成员
每个 team member 都应有自己独立的 AgentService / AgentLoop
team coordinator 在上层调度多个 member 实例
因此当前这套 start()/submit_direct()/stop()/close() 首先是 member-level lifecycle

当前还没开始的部分：

delegation
team runtime
swarms orchestration backend
group discussion / workflow orchestration

7. 对照 `change.md`，哪些长期目标还没开始

change.md 讲的是总蓝图，不是当前施工编号。下面这些仍然是长期目标，还没有正式进入当前阶段实现：

skills 生命周期系统
- SkillDraft
- SkillVersion
- review / publish / rollback
Hermes-style learning loop
- 智能体定期整理 / 提示记忆
- 复杂任务完成后可自主创建技能
- 技能在使用过程中自我提升
- FTS5 + LLM 摘要的跨会话回忆增强
- Honcho 风格辩证用户建模
swarms 作为正式 backend 接回平台
delegation / subagent / team orchestration

当前只完成了这些基础入口：

curated memory CRUD
session_search
skill loader / skill_view
skill assembler
tool assembler

7.1 权限与治理

还没做：

完整 permission gates
tool policy
MCP 工具治理

已完成的最小边界：

只读 filesystem tools 强制限制在 ToolContext.workspace
路径解析使用真实路径，防止相对路径、绝对路径、符号链接逃逸
当前还没有 shell / write / network 工具，因此还没进入高风险授权阶段

7.2 前端兼容

当前只做了最小 chat response 兼容：

前端 sendMessage() 已兼容 Beaver 的 output_text

还没做：

/api/auth/*
/api/sessions
/api/status 完整页面数据
/api/skills
/api/files
/ws
浏览器端免登录或新 auth 接入策略

8. 下一步从哪开始最合理

如果严格按 施工指南.md 的施工顺序继续，下一步应是：

完成 6.3 回填 bus 模式
- 明确 bus mode 的正式运行语义
- 让 AgentLoop.run() 与 MessageBus 的关系稳定收口
- 把 inbound / outbound 结果结构定稳
然后再进入 6.4
- 先把 team lifecycle 关系写成更可实现的 coordinator 约束
再进入第 7 阶段
- delegation
- local subagent
再进入第 8 阶段
- team / swarms backend

如果按 change.md 的长期方向看，后面还要补：

skills 生命周期
Hermes-style learning loop
更完整的 memory / governance / frontend

一句话总结：

当前 Beaver 已经完成到“单 agent runtime + memory/skills + lifecycle + Web/Gateway 最小接入”，按施工指南的编号，下一步应是 6.3 回填 bus 模式。

8. 文档维护要求

以后只要发生以下任一变动，必须同步更新本文件：

EngineLoader 装配项变化
AgentLoop 主链变化
Session 事件流结构变化
Memory 接入方式变化
Skills 装配方式变化
Tools 默认集合变化
Web / Gateway / multi-agent 真正接入主链

26 KiB Raw Blame History Unescape Escape

Beaver Backend Flow

1. 参考项目各自借什么

1.1 OpenHarness

1.2 hermes-agent

1.3 swarms

2. 当前我们到底做到哪了

3. 当前真实主链

3.1 Web / Gateway 当前怎么接

3.2 总体链路

3.3 详细顺序

4. 当前模块边界

4.1 EngineLoader

4.2 AgentLoop

4.3 Session

4.4 Memory

4.5 Skills

4.6 Tools

4.7 Providers

5. 当前最重要的设计决定

5.1 Session-first

5.2 Harness != Product Interface

5.3 Skill selection 外置

5.4 Skills 采用 Hermes 风格

5.5 Tools 采用 MCP-style 描述

6. 对照施工指南，我们现在处于哪一步

6.1 第一步：Session 升级为事件源模型

6.2 第二步：runtime 生命周期协议补齐

6.2.1 Web / Gateway 现在如何接这套 lifecycle

6.3 第三步：回填 bus 模式

6.4 单 agent lifecycle 如何扩展到 team

7. 对照 change.md，哪些长期目标还没开始

7.1 权限与治理

7.2 前端兼容

8. 下一步从哪开始最合理

8. 文档维护要求

26 KiB

Raw Blame History

1.1 `OpenHarness`

1.2 `hermes-agent`

1.3 `swarms`

4.1 `EngineLoader`

4.2 `AgentLoop`

4.3 `Session`

4.4 `Memory`

4.5 `Skills`

4.6 `Tools`

4.7 `Providers`

5.1 `Session-first`

5.2 `Harness != Product Interface`

5.3 `Skill selection` 外置

5.4 `Skills` 采用 Hermes 风格

5.5 `Tools` 采用 MCP-style 描述

7. 对照 `change.md`，哪些长期目标还没开始