最近，我一直在 Better Harness 里思考编码智能体的工作闭环：用户究竟想完成什么，智能体读取了哪些上下文、执行了哪些操作， 结果有没有得到验证，以及这些过程中暴露出来的经验，能否继续沉淀为下一次任务可以复用的能力。

而随着现在的 Coding Agent 工作对象从代码不断扩展，从 API、网页到 PPT、Word、Notebook、3D 模型、动画等不同类型的产物。我们会发现： 它们面对的其实是同一个问题：智能体如何理解产物、修改产物、展示结果，并根据人的反馈继续下一轮工作。

这也让我开始重新思考一个问题：

当人与智能体共同面对的是一份会被持续修改、审阅和交付的工作产物时，我们还应该把对话当作人机交互的中心吗？

所以，我们在 https://github.com/qoderai/better-harness 中引入一种新的探索性的 Harness 分析视图：Artifact View。

引子：从以对话为中心，到以产物为中心

今天的大多数智能体产品，仍然围绕对话来组织任务：用户输入一段需求，智能体读取上下文、调用工具、修改文件，再把执行过程和最终结果返回到对话中； 即使产品旁边已经放置了代码编辑器、终端、文件浏览器和预览窗口，对话记录仍然承担着保存目标、解释过程和串联上下文的主要职责。

这种交互方式可以称为以对话为中心的智能体闭环。在这套模式里，对话既是任务入口，也是过程记录，还是智能体解释结果的主要载体。

在代码场景中，这种方式之所以还能成立，是因为任务的真实状态并不只存在于对话里，它同时存在于代码仓库、文件内容、符号关系、Git 差异、编译结果和测试报告中；即使智能体遗失了一部分对话上下文，它仍然可以重新读取项目，找到相关代码，运行测试，再次进入之前的工作现场。

但是，当工作对象变成 PPT、表格、架构图、移动设备或者三维场景之后，情况就开始不一样了。用户可能在两轮对话之间手工调整了一页幻灯片， 移动了一个节点，修改了几个单元格，或者在模拟器中切换到了另一个页面；下一次交互开始时，智能体不能只回顾聊天记录， 还必须重新理解眼前这份已经发生变化的工作产物，以及用户刚刚通过直接操作表达出来、却未必被完整记录进对话中的意图。

换句话说，一旦人开始直接操作产物，对话就不再拥有完整的工作现场。。

以产物为中心的 Agent Loop

因此，我更愿意把这种新的协作方式称为：

以产物为中心的智能体协作闭环，是人与智能体围绕同一份可持续演化的工作产物展开协作的过程；对话仍然负责表达目标和解释判断， 但真正承载工作现场的，不再只是对话，而是双方正在共同维护的产物及其状态。

这里所说的产物，可以是一段代码，也可以是一份演示文稿、一张架构图、一个工作簿、一个正在运行的设备界面，或者一个包含空间和物理状态的模拟世界。 它们的内部结构和运行方式并不相同，但都有一个共同点：

它们都不是一次生成之后便结束的文件，而是会被持续进入、修改、验证和审阅的工作对象。

从早的 PPT Agent 到 ChatGPT 中采用的 Agent 看到轨迹。上一个阶段的主流 Office Agent 更喜欢基于 HTML 来展示结果， PPTX 只是最后的导出物 —— 在过去的模型能力及交互形态有限的情况下，这种方式已经是最接近“产物中心”的实现了。

不过，在各类 GUI Agent 更完善之后，形态发生了一些变化。比如 Codex 基于自己的 Office 相关的 API/DSL 封装，以及可以直接生成、编辑 PPT，并 与 PPT 进行交互。

示例：以网页为核心的 Browser Agent 的闭环

浏览器智能体可能是最容易理解的例子。它之所以比“把网页截图发给模型”更进一步，是因为网页本身拥有浏览器运行时： 智能体既可以看到页面，也可以点击、输入、滚动和截图，还能够结合页面元素、控制台日志和网络请求理解操作前后的变化； 换句话说，网页不是智能体最后交付的一张图片，而是一个能够被不断观察、操作，再重新观察的工作环境。

到了新一代 Coding Agent，这个闭环又向前走了一步：智能体不只是自己操作网页，人也开始直接通过网页向智能体表达意图。以 Cursor、Qoder 的浏览器设计模式为例，用户可以直接选择运行中页面里的元素，通过绘制、语音或者文字补充修改要求， 而系统则把被选中的元素、背后的代码、周围布局和视觉关系一起交给智能体。

这里发生的变化其实很重要：

用户不再需要先把自己看到的问题翻译成一段完整的自然语言，再告诉智能体“我说的是哪个地方”

产物本身开始承担上下文和指令入口的一部分职责。

示例：网页到可交互的 Canvas 形态

在诸如 Cursor/Qoder 的 Canvas 能力吧把这种方式进一步扩展到了智能体自己生成的工作产物。用户可以直接选择和批注画布里的界面元素， 让智能体根据这些局部反馈继续修改，也可以通过画布中嵌入的按钮直接触发后续动作。这里真正重要的，不是多了一个更漂亮的预览窗口， 而是用户不再需要把“我指的是哪里”重新翻译成文字，产物本身已经成为下一轮交互的入口。

当智能体把代码审查、测试报告、架构说明或者调研结果组织成可阅读、可筛选、可操作的界面时，Canvas 就不应该只是一次性的 HTML 输出，而应该进一步把团队对信息组织、证据呈现和下一步操作的经验带进产物；更重要的是， 画布中的结构化节点也可以成为后续行动的入口，使用户能够从某个风险、某段差异或者某项建议直接发起修复、解释或追问， 而不必重新回到聊天框里描述一遍上下文。

Browser Agent 和 Qoder Canvas 的实现方式并不相同，但它们共同体现了一种变化：智能体的交互界面正在从“对话中附带一个结果”，转向“人与智能体共同操作一份产物”。

在这种模式里，语言仍然重要，但语言不再承担全部上下文；用户看到的对象、选中的区域、留下的批注、直接进行的修改以及最终作出的批准， 同样属于任务的一部分。

而问题也就自然地从“Canvas 应该长什么样”，进一步走向了另一个层次：如果产物本身开始成为人机协作的工作现场，那么 Harness 应该如何理解和维护这个现场？

Harness 如何成为人与智能体的协作环境

如果只是增加一个画布或者预览窗口，这种协作仍然很容易退回到“看图说话”。画布解决的是人如何直接进入产物，领域运行时解决的是 智能体如何理解和操作产物；而 Harness 要做的，则是把人的意图、智能体的操作和产物的变化连接成一个持续运行的闭环。

具体来说，它至少需要处理四件事情：

• 维护持续变化的任务意图。 不只记录最初的提示词，也要记录用户选中了什么、批注了什么、拒绝了什么，以及最终为什么接受结果。
• 让操作落在确定的产物版本上。 无论是网页元素、幻灯片中的图表，还是画布中的节点，每次选择、修改和验证都应该指向同一个版本和语义对象，避免智能体操作已经过期的截图、坐标或者内容。
• 让不同产物使用各自的运行时。 网页交给浏览器，代码交给代码仓库和构建系统，文档、表格、图表和模拟器也保留自己的结构、操作和验证方式。
• 保留可以被检查的验证证据。 智能体不能只说一句“已经完成”，Harness 还需要记录产物发生了什么变化、哪些结果已经验证、哪些仍然无法确认，并把这些信息交给人判断。

在 Better Harness 当前的产物模型里，一份产物因此也不再只是一个文件路径，而是一个带有明确版本、结构和展示方式的工作对象。 人的选择、智能体的修改以及后续验证，都应该落在同一个产物版本上，双方才真正是在面对同一份工作现场。

这也不意味着所有产物都要被塞进同一种画布。文档可以转换成带有结构和语义地址的数据快照，需要运行才能呈现的内容则可以经过受约束的构建和隔离预览。Harness 统一的是意图、版本、操作、回执和证据，而不是不同领域内部的模型。

flowchart TB
    H[人：目标、选择、批注与决定]
    X[Harness：意图、版本、权限、过程与证据]
    G[智能体：理解、规划与执行]
    R[领域运行时：观察、定位、操作与验证]
    A[产物：页面、代码、文档、图表或设备状态]

    H <--> X
    G <--> X
    X <--> R
    R <--> A
    H <--> A

其中最关键的是“人 ↔ 产物”：在传统的 Agent Loop 中，人主要通过提示词间接改变工作对象；而在以产物为中心的协作里，人和智能体都可以直接修改同一份产物。Harness 要维护的，正是这些操作背后的意图、版本和验证关系。

因此，面向产物的 Harness 不需要统一所有领域模型，而是统一协作方式，不统一领域实现 。目前的产物视图先解决版本绑定、结构理解和安全呈现；接下来再逐步连接选择、批注、写回、版本比较和验证证据，形成完整的以产物为中心的 Agent Loop。

总结：从单一闭环走向多元化闭环

从代码、网页到演示文稿、表格和模拟世界，不同产物都会形成各自的观察、操作和验证闭环。所谓多元化的 Agent Loop， 就是让不同产物拥有适合自己的协作方式，而 Harness 负责连接人的意图、智能体的操作与验证结果。

当对话不再是唯一中心，产物才真正成为人与智能体共同工作的地方。