steven_li
2c5205b06e
- 添加MinIO用户文件系统配置选项(BEAVER_MINIO_ROOT_USER等) - 更新外部连接器配置结构，包括BASE_URL和认证令牌设置 - 改进connector provider支持更多类型(official, feishu_bot等) - 实现Mistral模型推理模式支持reasoning_effort参数 - 增强外部连接器策略配置和运行时配置管理 - 添加connector bridge事件验证和安全保护机制 - 优化任务路由逻辑，区分simple_chat和new_task场景 - 更新初始技能工具提示配置，分离authoring admin功能
61 lines
2.4 KiB
Markdown
61 lines
2.4 KiB
Markdown
# Auto-Accept Task When a New Topic Starts
|
|
|
|
## Goal
|
|
|
|
Prevent unrelated follow-up conversation from being appended to the previous
|
|
Task. When the Intent Agent decides that the user's current message starts a
|
|
new topic, Beaver should silently accept the previous Task before processing
|
|
the current message.
|
|
|
|
## User Experience
|
|
|
|
- No confirmation dialog or extra assistant message is shown.
|
|
- A related follow-up or requested change continues the existing Task.
|
|
- An unrelated lightweight message is handled as `simple_chat`.
|
|
- Unrelated work that needs Task capabilities is handled as `new_task`.
|
|
- Before either new-topic path continues, the previous Task is formally
|
|
accepted.
|
|
|
|
## Routing Rules
|
|
|
|
The existing Intent Agent actions remain unchanged:
|
|
|
|
- `continue_task` and `revise_task` belong to the active Task.
|
|
- `close_task` and `abandon_task` keep their existing explicit semantics.
|
|
- With an active Task, `simple_chat` means an unrelated lightweight new topic.
|
|
- With an active Task, `new_task` means unrelated work that needs a separate
|
|
Task.
|
|
|
|
The Intent Agent guidance must explicitly distinguish unrelated lightweight
|
|
conversation from revisions. A message must not be classified as
|
|
`revise_task` merely because an active Task is awaiting acceptance.
|
|
|
|
## State Transition
|
|
|
|
Before processing a `simple_chat` or `new_task` decision:
|
|
|
|
1. Check whether the active Task is `awaiting_acceptance`.
|
|
2. Find its latest completed run.
|
|
3. Record a normal `accept` acceptance against that run.
|
|
4. Continue processing the current message using the original routing
|
|
decision.
|
|
|
|
The normal acceptance path must be reused so that the Task becomes `closed`,
|
|
`final_accepted_run_id` is recorded, acceptance events are persisted, run
|
|
memory is updated, and skill-learning candidates can be generated.
|
|
|
|
Tasks without an acceptance-eligible completed run are left unchanged. Router
|
|
failures retain the existing conservative `continue_task` fallback and must
|
|
not auto-accept a Task.
|
|
|
|
## Testing
|
|
|
|
Backend tests must cover:
|
|
|
|
- An unrelated `simple_chat` message accepts the previous Task and is not
|
|
appended as another Task run.
|
|
- A `new_task` decision accepts the previous Task and creates a separate Task.
|
|
- `continue_task` and `revise_task` do not auto-accept the active Task.
|
|
- Router failure fallback does not auto-accept the active Task.
|
|
- Auto-accept records the final accepted run and normal acceptance history.
|