同样是让用户看见 Agent 的执行过程，四种产品选择了四种完全不同的界面重心。
Work 把来源与成果放在前面，Codex 聚焦文件变更与测试，Claude Code 强调计划、授权与恢复；DeepSeek Harness 则把模型、工具、子 Agent 和 Token 消耗组成一条可下钻的 Trajectory。
它们的差异不是“谁展示得更多”，而是分别把执行过程翻译成了用户需要验收的结果、审查的变更、控制的行动，或调试的 Runtime。
这篇文章真正想回答的问题
Agent 的执行轨迹不是展示得越多越好。产品需要先判断：谁要看、他要据此判断什么、看到之后能采取什么动作。
一、Work、Codex、Claude Code 与 DSH，在让用户判断什么
把这四款产品放在一起，差异并不只是“谁展示得更详细”，而是它们分别选择了不同的用户判断对象。
| 产品 | 默认放到前面的对象 | 用户最后要作出的判断 |
|---|---|---|
| ChatGPT Work | 来源、文件、成果预览、批注 | 这份成果能不能使用？ |
| Codex | 文件变更、diff、测试、分支与 Git 状态 | 这次工程变更能不能接受？ |
| Claude Code | 计划、权限、修改对比、检查点与回退 | 可以继续吗？走错后怎样恢复？ |
| DeepSeek Harness | Session、工具调用、Trajectory 与插件事件 | 为什么这样运行？应该替换或修正哪一层？ |
Work 面向的是一项可交付的工作，所以过程最终要靠近文件和成果；Codex 面向代码仓库，所以 Git 变更是最可信的共同语言；Claude Code 强调一个会真实行动的编码搭档，因此授权与恢复被前置；DeepSeek Harness 面向 Harness 开发者，Runtime 本身就是需要观察和组装的产品对象。
这也解释了为什么不能直接得出“DSH 的可见性更好”。完整 Trace 对 Harness 开发者是工作台，对只想验收结果的用户却可能是噪音。可见性的标准不是信息量，而是它是否贴近用户真正需要承担的判断。
二、DeepSeek 为什么把 Trace 放进主界面
答案首先与目标用户有关。DeepSeek Harness 不是主要面向普通任务用户的办公 Agent，而是供 Agent 开发者观察和组装 Runtime 的 Harness。对这类用户来说，运行过程不是附属信息，本身就是工作对象。
他们需要判断的不是“报告写完了吗”，而是：
- 这次判断使用了哪段上下文；
- 模型、工具与子 Agent 如何衔接；
- 失败发生在模型、工具、插件还是调度层；
- 替换某个组件后，运行路径、成本和结果改变了什么。
因此，把 Trace 放进主界面并不是为了制造“透明感”，而是为了让开发、调试、归因和实验比较进入同一个工作台。尤其在“一切皆插件”的架构下，组件越容易替换，开发者越需要及时看见替换后的影响。
DeepSeek Harness 展示完整 Trace，是因为它的目标用户需要对 Runtime 负责。
三、Trace 不是一条更长的日志
讨论 Agent 可见性时，进度、活动记录和 Trace 经常被混在一起。它们看起来都在展示过程，但服务的判断不同。
| 界面对象 | 回答的问题 | 典型表达 |
|---|---|---|
| 任务进度 | 现在做到哪里？ | 正在检索资料 · 已完成 3/5 |
| 活动记录 | 刚才做了什么？ | 读取文件 · 调用搜索 · 更新报告 |
| 运行轨迹 | 为什么沿这条路径运行？ | 上下文 → 模型请求 → 工具调用 → 结果 → 下一步 |
日志可以只是按时间堆叠的文本；真正可用的 Trace 必须保留关系。一次工具调用要能和它的参数、结果以及后续模型行为对应起来；一轮任务要能区分正常完成、用户取消、等待批准、错误中断或输出截断。
因此，Trajectory 的产品价值不来自“信息很多”，而来自它给运行过程建立了稳定坐标。开发者可以从一轮任务下钻到某个步骤，再定位到某次调用，而不是在一大段日志里猜测前后关系。
Trace 不是模型思维链
这里讨论的是可核验的输入、工具动作、结果、状态变化和使用量，不是要求产品展示模型隐藏的推理过程。运行透明与暴露思维链是两件事。
四、为什么这张 Trace 能成为产品
如果 Trajectory 只是任务结束后临时拼出的一张报表，它依然只是附加的可观测能力。DeepSeek Harness 更关键的选择，是把一次 Session 定义为持续追加的事件记录。
系统提示、上下文注入、用户消息、模型输出、工具调用与结果、轮次和步骤边界，都先成为同一条会话事件流中的事实。聊天界面、Trajectory、统计、恢复和分叉，再分别从这份记录中读取自己需要的部分。
flowchart LR
E["同一条会话事件流"] --> C["对话视图"]
E --> T["运行轨迹"]
E --> R["恢复 / 分叉"]
E --> V["统计 / 评测"]
C --> U1["回答发生了什么"]
T --> U2["解释为什么这样运行"]
R --> U3["从稳定位置继续"]
V --> U4["比较不同运行结果"]
第一，Trace 不再是旁路记录，而是会话事实的一个视图
聊天和轨迹不需要各自维护一套“真相”。当两者来自相同事件序列，用户在聊天里看到的工具结果、在 Trajectory 里检查的调用，以及恢复后继承的历史才有机会保持一致。
第二，恢复与分叉不再只是复制聊天文本
系统可以选择一段稳定的历史前缀，从那里恢复执行，或者创建一条新的运行分支。被继承的不只是对话句子，还包括支撑这次运行的上下文、工具结果与状态边界。
第三，同一事实源可以生成不同语义密度的界面
开发者看完整工具参数，评测人员看耗时和失败位置，普通用户只看“正在核对两份来源，其中一份暂时不可用”。底层记录不必变成所有人的默认界面，但它为不同翻译提供了基础。
这就是我认为它比“做了一张漂亮的 Trace 表格”更深的地方：先把运行事实保存成可以重复解释的对象，再决定让谁看见什么。
五、插件化与 Trace 为什么要一起看
“一切皆插件”解决的是可替换性：模型、工具、技能、会话、存储、沙箱、Agent Loop、调度乃至 UI 都可以组合或更换。但只做到可替换，还不足以形成一个好用的 Harness。
因为每一次替换都会引入新的问题：换了搜索工具，答案变好究竟来自召回结果还是模型行为？改了 Agent Loop，成本为什么上升？新增子 Agent 后，延迟发生在哪一段？
Trace 补上的是可解释的反馈面。两者放在一起，才形成完整的开发循环：
flowchart TB
P["替换插件或运行策略"] --> X["执行真实任务"]
X --> T["检查 Trajectory"]
T --> A["定位差异与失败"]
A --> E["比较 / 评测 / 再设计"]
E -. 进入下一轮 .-> P
对开发者而言，这个组合至少带来四种价值：
- 问题归因：区分问题来自模型、上下文、工具、插件还是调度。
- 实验比较：替换组件后，不只比较最终答案，还比较中间路径、成本和失败位置。
- 会话连续性：基于同一份历史恢复、分叉和回放，而不是重新猜测现场。
- 界面复用：从同一事件事实生成聊天、轨迹、评测和审计视图。
插件化告诉开发者“哪里可以换”，Trajectory 告诉开发者“换完以后发生了什么”。
六、普通用户不该直接读 Trace，但产品不能没有 Trace
这也是 DSH 最容易被误学的地方。看到 Trajectory 很惊喜，不代表企业 Agent 应该把 Tool Call、Token 和完整上下文全部推给业务用户。
更合理的做法，是让同一个运行事实按角色被翻译成不同界面。假设一个诊断 Agent 调用了两份日志，其中一份读取失败：
| 面向谁 | 界面怎样表达同一件事 | 支持的动作 |
|---|---|---|
| 任务使用者 | 正在核对两份日志；一份暂时不可用，当前结论置信度降低 | 补充资料或接受降级结论 |
| 专业复核者 | 来源 A 支持“网络超时”；来源 B 读取失败，尚不能排除应用侧异常 | 检查证据、修改判断 |
| 开发与审计 | 第 2 轮第 3 步，日志工具返回权限错误；重试 1 次；后续分支使用降级策略 | 排障、回放、比较版本 |
这三层分别是任务层、证据层和运行层。它们不是三份互相矛盾的记录，而是同一事实源面向不同责任人的投影。
对光溯这类复杂任务产品，我不会照搬 DSH 的 Trajectory 主界面。但我会借鉴它的底层逻辑：计划变化、证据获取、工具失败、人工确认和最终结论都应留下结构化记录；普通用户默认看任务语言，专业用户展开证据，审计与排障人员再进入完整 Trace。
七、Agent 的执行轨迹，应该展示到哪一层
看完 DeepSeek Harness，我认为 Agent 可见性的产品决策至少有四个判断维度。
- 用户负责什么对象？负责成果、代码变更、执行授权，还是 Runtime 本身？
- 操作风险有多高？越不可逆，证据、权限与恢复入口越应该前置。
- 信息能否改变下一步决定？不能帮助判断的信息，更适合留在运行层。
- 系统状态是否已经被翻译？“工具调用失败”是系统语言；“缺少一份关键证据，结论暂时降级”才是任务语言。
产品验证也不应只看 Trace 展开率。更有价值的指标是：开发者定位失败需要多久，不同插件或策略能否被稳定比较，Session 恢复后是否保持上下文一致；对普通用户，则看他是否减少追问“现在在做什么”、能否在错误扩大前纠偏、是否理解任务为什么仍未完成。
仍然存在的边界
DeepSeek Harness 目前处于开发者预览阶段。完整 Trace 还涉及存储增长、事件结构演进、敏感输入与工具参数的权限、脱敏和保留周期。可观察也不等于已经可评测：有了轨迹，只是获得了归因素材，最终仍需要任务标准与 Eval。
结语：DeepSeek 真正产品化的是 Agent Runtime
回到最初让我停下来的那张 Trajectory。
它的意义不是让普通用户第一次看见 Agent 调用了什么工具，也不是证明 DeepSeek Harness 的界面比其他产品更透明。它真正向前推进的一步，是把 Runtime 从藏在日志和开发工具里的后台机制，变成了可以检查、归因、比较、恢复和继续设计的产品对象。
“一切皆插件”决定了系统哪些部分可以被替换；Session Event 保存实际发生过什么；Trajectory 让变化可以被看见；恢复与分叉则让这份历史还能继续参与下一次运行。
Trace 最有价值的时刻，不是它展示了多少细节，而是它开始支撑用户理解一次运行、定位一次失败，并决定下一步该改哪里。