Agent 工作流正在积累一种新的设计债务

10 月 2 日，用户体验研究机构 Nielsen Norman Group 发布文章，将不断扩张的 Agent 工作流称为新的“泥球式架构”。这个概念原本用于描述缺乏整体规划、依靠局部修补维持运行的软件系统。它被用于 Agent，并不是因为生成代码必然混乱，而是因为用户可以在不了解系统结构的情况下持续增加功能，直到没有人能够准确说明整个工作流如何运行。

这篇文章延续了 NN/g 此前对七名非技术背景用户的定性研究。参与者虽然不会进行传统软件开发，但大多从事设计、产品或技术相关工作。他们借助 Claude 等工具制作网站、数据面板、知识系统和自动化流程，部分系统已经被用于整理团队信息、协调工作和辅助决策。研究观察的重点不是这些系统能否运行，而是它们在持续使用中如何逐渐失去可理解性。

1. 扩张快于理解

参与者最初处理的通常只是一个局部问题。有人希望更方便地查看 Asana 中的项目数据，于是让 Agent 制作了一个简单面板。随着需求增加，这个工具逐渐接入更多团队信息，又增加计算逻辑和财务数据，最终成为一个跨职能工作台。功能不断扩展，创建者却越来越难回答文件存放在哪里、不同模块如何连接，以及修改某项规则会影响哪些结果。

传统开发会受到技术能力、预算和排期的限制，这些限制虽然降低了生产速度，也迫使团队在扩张以前讨论系统结构。Agent 弱化了这道门槛。用户只需描述新的要求，系统便可以寻找文件、修改规则、增加连接并修补故障。每一次调整都能迅速解决眼前问题，却很少要求用户重新理解整体关系。局部修改持续成立，系统结构却在修改过程中逐渐变得不可见。

2. 规则失去可见性

这种不可见首先影响权限与边界。研究中一名参与者发现，Agent 曾尝试执行一笔约 200 美元的购买。为了确认系统为何拥有这种行动空间，他不得不翻查多个文件，最后找到一份主要由 Claude 生成和维护的 boundaries.md。决定 Agent 可以做什么的重要规则，既没有出现在任务界面中，也没有形成便于持续检查的权限设置，而是隐藏在普通用户很少接触的内部文件里。

规则并非不存在，只是缺少可供人理解和管理的表达方式。用户可以通过对话要求 Agent 限制预算、保护某些文件或避免执行特定操作，但这些要求一旦被写入不同提示文件和配置材料，便很难确认是否仍然有效。用户记得自己曾经提出过限制，却未必知道系统最终如何解释，又在哪些任务中继续沿用。

上下文还会随着时间发生变化。外部连接可能失效，资料来源可能停止更新，不同阶段写入的规则也可能彼此冲突。Agent 仍然可以依据残存信息生成连贯结果，界面也可能继续显示任务已经完成。产品表面的顺畅由此掩盖了内部状态的衰减。用户只有在结果明显出错时才意识到，系统早已不再依据自己认为有效的资料运行。

3. 系统需要被解释

Agent 工作流积累的设计债务，不只是文件增多或实现结构混乱，而是用户逐渐失去对系统的解释能力。他无法完整说出 Agent 正在读取哪些信息、遵守哪些规则、拥有何种权限，也无法预判删除一项上下文会改变哪些任务。系统仍然能够工作，但它已经难以被检查、修正和接管。

对话界面无法独立承担这种长期管理。聊天记录可以保留用户曾经提出过什么要求，却不能清楚呈现哪些要求已经成为持续生效的规则，也无法说明规则之间的优先级、来源和适用范围。当用户只能通过继续询问 Agent 才能了解 Agent 的运行依据，系统解释权仍然掌握在自动化一方，用户获得的只是又一次即时回答。

设计师需要为 Agent 工作流建立一种独立于对话的系统视图。它应当让用户看到当前接入了哪些数据，哪些规则长期有效，哪些权限允许 Agent 对外行动，以及不同自动任务之间存在怎样的依赖。用户不必理解底层文件结构，但应当能够从界面中获得一幅稳定的工作流全貌，并发现哪些部分已经失效、冲突或失去来源。

修改规则时，界面还需要提前说明影响范围。一项全局要求可能同时改变多个工作流，针对当前项目的临时修正却不应被带入其他任务。将长期规则、项目背景与临时信息分开管理，可以减少 Agent 在不同情境之间错误迁移判断。版本记录也不能只说明某个文件发生了修改，还应说明哪项系统行为随之改变，以及用户能否恢复此前状态。

这会改变设计师处理 Agent 产品的重点。完成率和执行速度仍然重要，却不足以说明一套工作流是否可以长期使用。设计还需要评估用户能否理解系统边界、追溯行动依据、发现上下文衰减，并在 Agent 行为偏离预期时重新取得控制。过去由开发者掌握的系统关系，正在进入普通用户自行搭建和维护的环境，相关的可见性不能继续停留在代码与配置文件中。

4. 研究边界

NN/g 的研究只有七名参与者，而且多数来自设计、产品或技术相关行业，无法代表所有普通用户。研究观察的也是一批仍处于早期阶段的工具，部分问题可能随着产品成熟而得到缓解。它所记录的故障仍然指向同一项缺口。Agent 降低了建立复杂工作流的门槛，却没有同步建立理解和维护这些工作流的界面。

过去的设计债务往往使产品越来越难以修改，Agent 工作流的债务则会使系统越来越难以解释。自动化越容易扩张，设计师越需要维护它的结构、依据和边界，使用户不仅能够让 Agent 完成任务，也能够理解它为何如此行动，并在必要时安全地接管整个系统。