AI OPERATIONS
从工作出发运营 Agent，不再追着聊天窗口跑
Busabase 为 AI 运营团队提供一个共享工作区，承接 Agent 提议、人工决策、正式记录、可复用 Skill 和实时运营界面。你能看见什么在等待、谁负责判断，以及哪些结果可以被下游信任。
运营断层
Agent 越多，隐藏队列越多，除非所有工作共享同一份状态
当每个 Agent 都保留自己的聊天记录、草稿目录和完成定义，团队就看不见哪里阻塞、什么已经接受、哪些结果能被另一个 Agent 继续使用。
可见性
关键提议进入一个队列
按状态与影响处理工作，不必监控每一段 Agent 对话。
责任
每个决定都有负责人
责任绑定到记录和验收点，而不是最后打开聊天的人。
连续性
正式状态不会随会话消失
记录、Doc、文件、Skill 和 AirApp 可被下一位成员与 Agent 继续使用。
恢复
被拒绝的工作仍然可解释
差异、评论、版本和来源说明提议为何改变，或为何没有成为事实。
AI 运营闭环
围绕共享工作运营 Agent，而不只看一张 Agent 列表
Busabase 不是 Agent 运行时或编制管理系统。它负责让 Agent 结果成为可见工作和被接受的正式状态。
通过 Skill、MCP 或 OpenAPI 给兼容 Agent 配置受限访问。
Agent 带着具体说明提交结构化变更、文件或应用更新。
AI 运营在一个 Inbox 看见待处理工作、负责人和下一步决策。
审核人检查实际结果与证据，再决定是否成为正式状态。
人、Agent、API、自动化和 AirApp 读取同一份已接受状态。
运营契约
每个关键 Agent 结果都带着足够的行动上下文
有价值的单位不是一次 Agent 运行，而是带状态、责任、证据和明确下游影响的可审核结果。
| 运营信号 | 责任人 | 团队得到什么 |
|---|---|---|
| 待处理提议 | 流程负责人 | 可见的决策队列，而不是隐藏草稿 |
| 字段或文件差异 | 审核人 | 实际变更，而不是一段总结 |
| 来源与证据 | 领域负责人 | 接受或拒绝的判断依据 |
| 正式记录与历史 | 工作区团队 | 下一条工作流可复用的持久状态 |
持续运营
Agent 停止后，已接受结果仍然清晰可见
记录详情把当前值、来源和审核历史放在一起。运营者可以调查一次决定、恢复上下文，并改进 Prompt 或 Skill，而不必重新拼接日志。
适用场景
多个 Agent 共同维护有后果的状态
- 多个 Agent 或自动化为同一团队产出工作
- 团队需要统一处理和接受关键变更
- 正式结果必须跨会话、跨工具保留
- 运营需要清晰来源和恢复能力
产品边界
它不是运行时或遥测平台
- 调度和托管长时间 Agent 进程，应使用 Agent 平台
- 高频 Trace 和指标，应使用可观测性基础设施
- 同步交易写入，应使用事务数据库
- Agent 清单、成本与模型治理，应使用 Agent Registry
AI 运营常见问题
Busabase 会运行或调度 Agent 吗？
不会。Agent 运行在你选择的环境。Busabase 承接这些 Agent 周围的共享工作、审核边界、正式状态和可复用运营资产。
每个 Agent 动作都要审批吗？
不需要。只审核会形成业务事实或影响下游的写入。草稿、检索缓存和低风险操作可以保持轻量。
多个 Agent 可以使用同一个工作区吗？
可以。兼容 Agent 可以读取相同的正式记录、Doc、文件和 Skill；关键写入仍以带来源的提议进入。
错误提议如何恢复？
合并前可以拒绝或要求修改。提议及历史仍然可见，团队能改进流程而不污染正式数据。
一个工作区，多个 Agent
给 AI 运营一个决定什么能被信任的可见入口
先连接一个 Agent，让一份关键结果走完审核，再让下一条工作流复用正式状态。