面向人机交互的Harness：打造以产物为中心的智能体工作流

最近，我一直在 Better Harness 里思考编码智能体的工作闭环：用户究竟想完成什么，智能体读取了哪些上下文、执行了哪些操作。

在与多个编码智能体（如Copilot, Cursor, Aider等）“协作”的过程中，我时常感到一种割裂感。它们往往在“理解我的意图”和“完成我的任务”之间，缺少一个清晰、连贯且透明的中间地带。用户的指令、智能体读取的代码上下文、生成的方案、执行的修改，这些环节像是独立运作的孤岛，我们只能看到首尾两端的输入和输出，过程则成为一个“黑盒”。

这种割裂导致了几个核心问题：

上下文丢失：当我提出一个复杂需求时，智能体可能在后续交互中“忘记”之前确认的关键约束或背景。
意图偏离：由于缺乏对用户最终“产物”的持续追踪，智能体容易陷入局部优化，生成了符合语法但偏离整体设计的代码。
控制感薄弱：作为用户，我难以在过程中进行精准干预和校正，往往只能等待其“一气呵成”或彻底重来。

因此，我开始构想一种以产物（Artifact）为中心的设计模式。这里的“产物”并非仅指最终的代码文件，而是一个在交互过程中持续存在、可演进、可检视的工作实体。它可以是：

一份需求描述文档
一个架构设计草图
一组正在被编辑的代码文件
一个测试用例集合

基于这个核心理念，我们设计了Harness交互循环。它大致分为三个阶段：

1. 意图对齐与产物初始化 当用户提出一个请求时，智能体首先做的不是直接修改代码，而是尝试将用户的自然语言意图，转化为对一个“初始产物”的描述。例如，用户说“把这个函数改成异步的”，智能体可能会创建一个名为 async_refactor_plan 的产物，列出需要修改的函数、要使用的 async/await 模式、需要添加的错误处理等。用户可以立即看到并校正这个“计划产物”，确保双方从同一起点出发。这类似于在 SDD 文档驱动开发实战中强调的，用文档先行来锚定共识。

2. 过程执行与产物演进 一旦产物计划得到确认，智能体便进入执行阶段。每一步操作（如读取一个文件、生成一段代码、运行一次测试）都会显式地记录在这个“产物”的变更历史中。产物自身会随着操作的完成而状态演进（例如，从“计划中”到“实施中”，再到“测试通过”）。这使得交互过程不再是黑盒，用户可以随时“回滚”到某个中间状态，查看某次修改的具体内容，或基于当前产物状态提出新的微调指令。

3. 反馈闭环与产物完善 在每一轮操作后，产物都会呈现出一个可评估的中间状态。智能体需要主动利用这个状态来寻求反馈。例如，在完成一轮代码重构后，它可以询问：“产物 async_refactor_plan 的代码部分已更新，我是否需要根据此变更产物，生成相应的单元测试？” 这种围绕产物的、持续的、细粒度的互动，形成了一个强大的正反馈循环，确保智能体的工作始终锚定在用户的最终目标上。

这种设计不仅仅是为了提升“编码”效率，更是为了重塑信任与控制。当我们面对日益强大的AI能力时，需要的或许是更“务实”的路径，聚焦于赋予它可靠的“超级能力”来完成具体任务，而非追求难以捉摸的“超级智能”。就像讨论AI发展时提到的超级能力而非超级智能：AI发展的务实路径，在工程实践中，可解释、可控、可协作往往比全知全能更为重要。

将Harness的这种思想应用到更广泛的场景，例如前端开发中深入解析 React Server Components 的渲染机制，我们或许可以想象，未来的IDE或开发平台，其核心工作区就是一个动态的“产物仪表盘”，开发者与多个AI Agent围绕同一组产物进行协作，而非在无数聊天窗口和代码文件间疲于奔命。

总之，以产物为中心的Agent Loop，为我们提供了一个设计下一代智能开发工具的有趣视角。它的核心价值在于：将无形的“交互过程”转化为有形的“产物资产”，让智能体的工作可追溯、可中断、可协作。这或许是通往更自然、更高效人机融合编程时代的一块坚实基石。