Files

T

gongzhiyongandClaude Sonnet 4.6 c6ca9dc126 fix: restore workspace components accidentally dropped from git index

workspace/ files existed on disk but were not included in previous
incremental commit, causing git to record them as deleted. Re-adding
all workspace card components, AgentWorkspace, ActivityTimeline, and
WorkspaceCardRenderer to properly track them.

Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com>

2026-04-10 03:09:41 +08:00

8.6 KiB

Raw Blame History

Auto / Pro 模式下的 CoT 可视化方案

目标

在不暴露模型原始 Chain-of-Thought（CoT）的前提下，让用户能够直观看到：

当前系统正在做什么
是否进入了工具调用
调用了什么工具
工具调用的大致输入/输出摘要
当前步骤耗时与状态
最终答案是如何逐步形成的

本方案的核心不是“展示原始 CoT”，而是展示一层结构化执行轨迹（reasoning trace / agent activity trace）。

为什么不建议直接展示原始 CoT

风险

直接展示模型原始 CoT 会带来以下问题：

可能泄露系统提示词、工具策略、内部规则
推理内容冗长、不稳定、不适合用户阅读
不同模型对 CoT 的输出风格差异很大，难以统一前端体验
可能包含错误中间判断，影响用户信任
在 Auto / Pro 模式中，原始推理链可能过于技术化，用户看不懂

更合适的做法

把原始 CoT 转换成可控的、结构化的、面向用户的“执行过程摘要”，只暴露：

当前阶段
是否进入工具调用
工具名称
参数摘要
返回摘要
当前状态
耗时

Auto / Pro 两种模式的建议差异

Auto 模式

推荐默认展示“简版执行轨迹”：

正在分析问题
已调用知识库
已调用工单系统
正在整理答案

特点：

信息量少
不打扰主聊天体验
用户可以看到系统不是“黑箱”
适合普通用户

Pro 模式

推荐展示“详细执行轨迹”：

当前阶段
工具名
入参摘要
返回摘要
耗时
失败/重试信息
最终归纳步骤

特点：

更像开发者/高级用户视图
更适合调试、排障、验收
有助于建立系统透明度

后端事件流设计建议

如果当前后端已经有：

on_tool_start
on_tool_end

那已经具备基础条件。

建议在 SSE / Stream 事件中统一补齐以下事件类型。

1. reasoning 事件

用于表示阶段性思考摘要。

{
  "type": "reasoning",
  "stage": "分析问题",
  "message": "正在判断是否需要外部工具"
}

2. tool_start 事件

{
  "type": "tool_start",
  "tool": "kb_search",
  "title": "调用知识库",
  "input_summary": "查询关键词：产品规划"
}

3. tool_end 事件

{
  "type": "tool_end",
  "tool": "kb_search",
  "title": "知识库返回结果",
  "output_summary": "命中 3 条知识库记录",
  "duration_ms": 842,
  "status": "success"
}

4. tool_error 事件

{
  "type": "tool_error",
  "tool": "ticket_list",
  "title": "工单系统调用失败",
  "error_summary": "请求超时",
  "duration_ms": 3000,
  "status": "error"
}

5. status 事件

{
  "type": "status",
  "stage": "整理答案",
  "message": "正在结合上下文生成最终回复"
}

6. final 事件

{
  "type": "final",
  "message": "最终回复内容"
}

建议的数据结构

前端可以统一维护一个 trace item 数组，例如：

interface TraceItem {
  id: string;
  type: "reasoning" | "tool_start" | "tool_end" | "tool_error" | "status";
  stage?: string;
  tool?: string;
  title: string;
  message?: string;
  inputSummary?: string;
  outputSummary?: string;
  errorSummary?: string;
  status?: "running" | "success" | "error";
  durationMs?: number;
  createdAt: number;
}

这样前端很好做时间线、折叠面板、状态图标和耗时展示。

前端展示建议

组件拆分建议

建议新增三个层次的组件：

TraceStatusBar
- 展示当前阶段进度
- 适合默认显示
TraceTimeline
- 展示完整事件流
- 支持折叠/展开
TraceTimelineItem
- 每个步骤卡片
- 可显示工具、耗时、状态、摘要

展示样式建议

每个步骤卡片包含：

图标（思考 / 工具 / 成功 / 失败 / 生成中）
标题
副标题
时间 / 耗时
可展开详情

比如：

分析问题
调用知识库
知识库返回 3 条结果
调用工单系统
生成最终答案

颜色建议：

蓝色：进行中
绿色：成功
红色：失败
灰色：普通状态/历史步骤

工具调用摘要生成建议

重点：不要把完整参数和完整返回直接丢给前端。

应在后端做摘要清洗，例如：

输入摘要

原始参数：

{
  "query": "搜索知识库中关于产品规划的内容",
  "top_k": 5,
  "filters": {"source": "internal"}
}

转换后：

查询关键词：产品规划
返回条数：5
数据源：internal

输出摘要

原始返回可能很长，不适合直接展示。

转换后：

命中 3 条知识库记录
返回最近 5 条工单
找到 2 条相关外部搜索结果

安全边界

必须明确哪些信息可以展示，哪些不能展示。

可以展示

阶段名
工具名
参数摘要
输出摘要
耗时
状态
错误摘要

不建议直接展示

原始 system prompt
原始思维链文本
完整工具参数（可能含敏感信息）
完整工具原始返回
内部路由策略细节
模型原始 scratchpad

和现有 SOC 项目的对接建议

根据当前项目情况，最适合的落地方式是：

后端

在现有流式聊天接口中，补充和规范以下事件：

reasoning / status
tool_start
tool_end
tool_error
final

如果当前 backend/app/api/chat.py 已经处理：

on_tool_start
on_tool_end

那可以继续补一层“摘要映射”，把底层事件包装成前端可直接消费的 trace event。

前端

在聊天消息区域中，为 assistant message 增加一个“执行过程”区域：

默认折叠
Auto 模式展示简版
Pro 模式展示详版

推荐位置：

放在 assistant 回复消息上方或下方
与最终答案同属一个回答块
不要单独跳页面

MVP 最小落地版本

如果要快速上线，建议只做以下能力：

后端 MVP

输出 4 类事件：

status
tool_start
tool_end
final

前端 MVP

显示一个可折叠区域：

分析问题
调用工具：知识库
工具返回：3 条结果
生成答案

Auto / Pro 区别

Auto：默认折叠，只展示 1 行状态摘要
Pro：默认展开详细时间线

这样最省改动，也能马上解决“用户看不到模型在做什么”的问题。

最终建议

一句话总结：

不要展示原始 CoT，应该展示“结构化执行轨迹”。

对 SOC 项目最合理的方案是：

后端补齐 reasoning / tool / status 事件
前端把这些事件渲染成时间线
Auto 展示简版，Pro 展示详版
只展示摘要，不暴露原始推理链

这样既能满足“用户想知道模型做了什么”，又不会引入原始 CoT 暴露风险。

可以继续的下一步

后续如果需要，可以继续细化为三份落地文档：

后端事件协议定义
前端组件与交互设计
SOC 项目具体改造点（按文件路径拆解）

8.6 KiB Raw Blame History Unescape Escape