AGENT 交付与交接
Agent 说“做完了”，不等于完成交接
可靠交接必须说明目标、展示真实产物、携带证据、记录人工决定，并把已接受状态留在下一位成员或 Agent 可以使用的地方。
工作流问题
聊天总结会隐藏范围漂移、证据缺失，以及“提议完成”和“正式接受”的差别。
一条 Change Request 把意图、产物、差异、来源、审核人与接受版本连在一起。
结构
先把工作建模，再扩大规模
类型化字段和关系让 Agent 产出在不同渠道与客户间保持一致。
审核
检查真实交付物
渲染后的内容、文件和字段差异，比原始 Payload 更容易判断。
权威
把提议和事实分开
只有已接受工作才成为下游系统读取的正式数据。
复用
把方法留在工作旁边
Skill、Doc、证据和 AirApp 在首次跑通后仍可继续使用。
运营流程
从请求到正式交接
持久工作流让每次状态变化清楚可见，也给下一位参与者一个明确起点。
01
定义
明确预期结果、负责人、字段、证据和验收规则。
02
产出
Agent 准备结构化记录、文件和专用界面。
03
检查
责任人审核实际结果，并在需要时要求修改。
04
接受
通过的版本成为正式状态，并保留来源与历史。
05
运营
人、Agent、API 和应用从正式状态继续工作。
交付契约
一条 Change Request 把意图、产物、差异、来源、审核人与接受版本连在一起。
持久的状态变化，而不是一条消息
| 交付物 | 负责人 | 运营价值 |
|---|---|---|
| 范围和验收标准 | 流程负责人 | 共同认可的完成定义 |
| 结构化提议与证据 | Agent 与执行者 | 可检查的真实结果 |
| 审核决定 | 流程责任人 | 清楚的权威边界 |
| 正式记录与运营界面 | 客户或内部团队 | 持久的状态变化，而不是一条消息 |
可见结果
持久的状态变化，而不是一条消息
已接受产物会继续连接证据、历史和下游用途，而不是变成另一个脱离流程的导出文件。
适合使用 Busabase 的情况
结果必须成为可复用工作
- Agent 产出必须成为结构化、可审核工作
- 多个成员或系统依赖已接受版本
- 负责人需要清晰差异、证据和历史
- 工作流不能随一次 Agent 会话结束
这些情况应该选择其他系统
明确周边系统的职责
- 直接向渠道发布，应使用发布平台
- 同步产品交易写入，应使用事务数据库
- 模型推理托管和调度，应使用运行时
- 没有人会做有效判断时，不要机械增加审批
常见问题
Busabase 会自己生成内容或客户方案吗？
不会。Agent 和团队负责执行，Busabase 负责结构化交付物、审核、正式状态、可复用方法和运营界面。
已审核结果可以进入其他系统吗？
可以。下游工具通过 API 读取正式记录，未通过的提议仍然保持隔离。
每一份草稿都要审核吗？
不需要。对公开、合同、财务、客户可见或会被复用为业务事实的结果设置审核。
项目或 Campaign 结束后会留下什么？
已接受记录、证据、Doc、文件、Skill、历史和 AirApp 都留在工作区，可以继续运营。
Agent 交付与交接
持久的状态变化，而不是一条消息
可靠交接必须说明目标、展示真实产物、携带证据、记录人工决定，并把已接受状态留在下一位成员或 Agent 可以使用的地方。