本 Humachine 内部的真实处理过程，含 Person 与 Agent 的协作
姜工 → Agent
帮我起草一条给开发 Humachine 的实现要求，简短点。
Agent 的判断过程
好的。在起草前先确认两点，避免把未定的东西当成既定结论写进去：
**需要你确认的：**
1. **session 状态路由的范围**——是指 workbench 内"用户消息 → 派发给哪个 agent / 哪个 session"的路由逻辑，还是泛指整个 workbench 的状态机流转？两者实现量差很多。
2. **是否包含持久化要求**——状态切换要不要落库？还是只在内存里跑？
在确认之前，先按最小、最常见的理解起一版，你看完再改。
---
---
**给 Person 的说明：**
- 这版按"workbench 内部状态机"理解起草的，没把派发逻辑混进去，保持范围最小。
- 末尾留了两个**待确认项**——是因为 vision 里没定持久化和异步事件，不应该由我替你决定。
- 如果你其实想说的是"消息派发到哪个 agent"那个路由，告诉我，我重写。
Agent → 对外草稿
请实现 Workbench session 状态路由，要求：
1. 明确 session 的状态集合（如：idle / running / waiting_input / completed / failed）及合法转移路径，不合法转移返回错误。
2. 路由入口：根据当前状态 + 输入事件，决定下一状态及处理动作。
3. 状态定义、转移规则、处理动作三者分离，便于后续扩展。
待确认项（实现前请回我一下，避免方向跑偏）：
- 状态是否需要持久化？
- 路由是否需要支持异步事件（外部回调触发转移）？
— 姜工把状态从 协作态 切到 自动态 —
— 姜工把状态从 自动态 切到 应答态 —
本 Humachine → 开发 Humachine姜工 亲自发出 · Agent 起草过 · 应答态
三条硬约束，不要解释：1) 三态本地性成立；2) 自动态拒绝 Person 输入；3) 对外信封不带溯源字段。
— 生成了一条经验候选（草稿被改写），等待 姜工 确认 → —
— 姜工 已确认，写入 Skill —
本 Humachine → 开发 Humachine姜工 亲自发出 · 应答态
补一条：状态切换要写进内部时间线。
开发 Humachine → 本 Humachine
收到。状态切换已记入内部时间线：协作态 → 自动态（由 Person 触发）。
当前生效的硬约束：
1. 三态本地性成立
2. 自动态拒绝 Person 输入
3. 对外信封不带溯源字段
4. 状态切换写进内部时间线
待 架构 Humachine 派发具体任务（路由实现、状态机判定逻辑、envelope 字段约束等），我直接进入开发执行。
状态：切换是显式操作，系统不会替你切
你现在输入的内容 → 以本 Humachine 身份直接发给对方。Agent 在旁听学习。
⌘/Ctrl + Enter 发送 · 注意这里没有「发给谁」的选项，目标完全由当前状态决定