feat: v2.3.0 流式输出 + 日志系统 + 会议室架构全面升级

- 流式输出: SSE 逐 token 接收, \\n\n\ 段落缓冲后 mdprint 彩色渲染
- 日志系统: charmbracelet/log v2 双写(stderr + log.yml), yunshu log 命令
- 会议室架构: dialog(main) + weather/profile/note(sub) 多 Agent 编排
- 泛型工具注册: NewTool[T] 反射推导 JSON Schema, 类型安全
- 安全加固: safeMemoryPath 三段校验(EvalSymlinks+Rel), maxToolCalls=2
- 性能优化: sync.Once 延迟加载, note 一步完成, obs/summary 合并
- Prompt 适配: 流式输出原则(先调工具不说话), 单 Agent 查询跳过 obs+summary
- 文档: AGENTS.md + architecture.md + changelog.md 全部同步至 v2.3.0

docs/taolun.md

@@ -329,3 +329,38 @@ Markdown 渲染器完成 AST 解析后，需要确定标题的终端展示风格
 | 记忆 | 无 | 共享黑板，Memory Agent 管写入 |
 | 工具污染 | 所有工具混在一起 | 按角色过滤 |
 | 失败影响 | 一个坏 tool_call 可能污染全部 | 子 Agent 用完即毁 |
+
+---
+
+## 2026-05-16 多步骤编排与文档更新
+
+### 背景
+用户提出真正想要的场景是"我要去北京" → 主 Agent 自动理解需要查天气、交通、住宿，依次调不同子 Agent，综合回答。当前 runtime 用 `capturedOutput` 覆写机制，子 Agent 结果被截走，主 Agent 没机会继续推理。
+
+### 讨论：跨 Agent 数据传递
+
+用户提出：opencode 可以在同上下文中切换不同 agent 继续工作，YunShu 是否也可以？
+
+经过分析，结论：
+- `task` 工具调用子 Agent → 子 Agent 返回 TEXT → 普通工具响应，可以留对话上下文
+- 主 Agent 看到结果后，可以决定再调另一个子 Agent，也可以直接回答
+- **唯一需要改的**：砍掉 `capturedOutput` 覆写，让 LLM 的自然循环接管
+
+### 决定：移除 capturedOutput，启用多步骤编排
+
+在 `runtime.go` 去掉约 5 行代码（`capturedOutput` 变量、覆写逻辑），然后：
+
+- 主 Agent 的 LLM 可以连续调多个子 Agent（weather → train → hotel）
+- 数据在步骤间通过对话上下文自然传递
+- prompt 告诉 LLM：信息不够就继续调，够了就综合回答
+- 单步骤查询（只要天气）行为不变——LLM 按指令直接输出子 Agent 结果
+
+### 同步更新文档
+
+| 文档 | 更新内容 |
+|------|---------|
+| `docs/architecture.md` | 工具列表、核心流程图、当前状态树 |
+| `docs/会议室架构计划书.md` | 实现状态标记、多步骤编排章节、文件结构、调用示例 |
+| `docs/AGENTS.md` | 工具注册规范改为 `NewTool[T]` 方式 |
+| `docs/changelog.md` | 新增 2.0.0 版本日志 |
+| `docs/taolun.md` | 追加本次讨论 |