Busabase × OpenHandsOpenHands 知识库
OpenHands 可以在本地、sandbox 或远程 Agent Server 中执行软件任务。Busabase 记录这次运行真正证明了什么、谁审核了结果，以及哪些后续流程可以依赖它。
当前 OpenHands 工作面
一个生态包含多种 runtime，任务记录必须说明实际运行的是哪一个。
OpenHands 当前区分 Agent Canvas、Software Agent SDK 与 Agent Server、Cloud、Enterprise 和 Sandbox Server。SDK 定义 conversation、tool、event、workspace 和 security policy，客户端与部署层使用这些接口。
控制中心
管理不同 backend 上的 conversation 与 automation。
执行 API
定义 Agent 行为，并通过 REST/WebSocket 暴露 conversation 与 workspace。
托管运行
提供托管执行、协作、权限、用量和预算。
隔离层
创建并管理承载 Agent Server 的运行环境。
事件历史与已接受结果
持久化 conversation 能证明发生了什么，却不能决定什么已经成为事实。
OpenHands SDK 可以持久化消息、action、observation、tool output、execution state、metrics、workspace context 和已激活 Skill。event log 很适合做执行证据，但业务状态或发布状态仍需要 runtime 之外的明确负责人和审核决定。
按时间记录执行证据
消息、action、observation 和状态变化的 append-only 历史
实际产物
目标环境中的文件、patch、测试、报告和命令
经过审核的运营含义
结果、证据引用、负责人、决定和下游状态
运行台账
把目标、执行边界、证据和决定拆成独立字段。
不要把完整 event stream 塞进一个长文本字段。关联持久化 conversation，只提取用于比较运行、调查失败和向下游交接已接受工作所需的少量事实。
| 字段 | 含义 |
|---|---|
| run_id | OpenHands conversation 或 automation run 的稳定链接 |
| goal | 本次运行被要求交付的结果 |
| workspace_ref | 仓库、revision、sandbox 和环境 |
| execution_state | 排队、运行、暂停、等待、完成、错误或卡住 |
| evidence_refs | Event、文件、commit、测试日志和 observation |
| proposed_outcome | Agent 对结果的简洁解释 |
| decision | 接受、有条件接受、拒绝、重跑或已替代 |
| owner | 对该决定负责的人 |
| next_action | 结果接受后解锁的下游工作 |
动作安全与数据权威
确认一条高风险命令，与接受一项任务结果，保护的是两道边界。
OpenHands 把 confirmation policy 与 security analysis 分开。AlwaysConfirm、NeverConfirm 和 ConfirmRisky 决定何时暂停执行，analyzer 负责判断 action 风险。Busabase 审核则继续追问：这次运行的解释能否更新正式记录。
SDK 的直接 execute_tool() 调用会绕过正常 Agent loop 中的 analyzer 与 confirmation，调用方必须自己实现防护。
用证据推动状态变化
允许事件提出状态更新，不允许 delivery log 代替决策。
OpenHands 状态变化时，Webhook 或 callback 可以打开 Change Request。delivery log 只证明事件已经到达；审核者仍要检查 event、workspace 产物和证据能否支持拟议运营状态。
| Runtime event | 记录提议 | 人的工作 |
|---|---|---|
| conversation.finished | 关联最终回复与证据引用 | 提议 ready_for_review |
| conversation.error | 关联错误与最后一次成功 observation | 提议 blocked |
| waiting_for_confirmation | 关联待执行 action 与风险上下文 | 分配人工决定 |
| rerun.completed | 关联上次运行与变化后的输入 | 提议替代结果 |
连接当前维护的工作面
使用当前 Skills 与 MCP 文档，不把旧 runtime 配置带进新流程。
OpenHands 支持 AGENTS.md、可移植 Agent Skills、project/user Skill scope 和可配置 MCP tools。当前产品架构以 Agent Canvas 与 Software Agent SDK/Agent Server 为核心。CLI 与 MCP 设置遵循 Busabase 连接页，并明确哪一个 backend 与 workspace 拥有本次运行。
关于自主运行记录的问题
OpenHands 知识库常见问题
Busabase 会取代 OpenHands conversation persistence 吗？
不会。OpenHands persistence 保存恢复或检查 conversation 所需的 event history 与 execution state。Busabase 保存其他团队与系统可以依赖的已审核解释。
每个 OpenHands event 都要建记录吗？
不用。大多数 event 留在 run log。只有有意义的状态变化、异常、证据或需要 runtime 外负责人接手的结果才进入记录。
Conversation finished 就等于结果已接受吗？
不等于。Finished 只描述执行状态。是否接受还取决于目标、证据、测试、业务影响和责任审核者。
OpenHands 能把 Busabase 作为 Agent Skill 使用吗？
OpenHands 支持 Agent Skills 规范与 project/user scope。Skill 可以说明工作流并调用已有工具，但不会自己授予权限；访问能力仍来自环境和 credential。
页面应采用哪套 OpenHands 配置？
只采用当前 Agent Canvas、SDK/Agent Server、Cloud/Enterprise 与当前 Skills/MCP 文档。不要把旧 V0 config.toml 或 trajectory 设置当成通用 V1 行为。
从一个自主任务开始
在下一次 OpenHands 运行前，先写清验收契约。
执行前定义目标、workspace、证据字段和审核者。让 OpenHands 生产工作与事件轨迹，由负责人决定哪个结果能成为可复用状态。