P02：Chat、Workflow 与 Agent——不要把界面当成架构

产品讨论中经常出现这样的分类：

我们应该做 Chat、Workflow，还是 Agent？

这个问题混合了两个不同维度：

Chat 是用户与产品交互的方式；
Workflow 和 Agent 是系统决定执行路径的方式。

一个 Chat 产品背后可以只是单次模型调用，也可以运行固定 Workflow，还可以驱动 Agent。反过来，一个 Agent 也不一定需要聊天界面，它可以在后台定时运行，通过任务中心、通知或报告向用户交付结果。

本章建立一个更准确的产品模型：先选择执行架构，再选择与任务匹配的交互界面。

用户场景

考虑下面五种产品：

产品需求	合适的执行方式	合适的交互方式
改写选中的一段文字	普通 AI 功能	编辑器内联按钮
员工提交报销申请	Workflow	表单和进度页
客服回答并办理业务	Router / Agent / Handoff	Chat
深度研究并输出报告	Agent	任务工作台
每天监控竞品变化	Scheduled Agent	后台任务和通知

如果所有需求都被做成聊天框，用户会被迫通过对话表达本可以结构化填写的信息，也难以理解长任务的状态。如果所有带聊天框的产品都被称为 Agent，团队又会高估系统的实际自主性。

产品视角

用户问题

选择交互方式时，应该判断用户需要完成哪种行为：

表达开放意图：适合 Chat；
填写明确字段：适合表单；
编辑已有内容：适合内联操作；
管理长任务：适合任务工作台；
被动接收变化：适合后台任务和通知。

自然语言很灵活，但它不应该替代所有产品控件。

产品价值

Chat 的主要价值是降低开放输入和澄清需求的门槛。Workflow 的主要价值是稳定执行已知过程。Agent 的主要价值是根据观察结果动态决定下一步。

它们可以组合：

Chat 获取用户意图
    -> Workflow 完成身份和规则校验
    -> Agent 处理无法预先枚举的部分
    -> Workflow 执行高风险业务动作

好的 AI 产品往往不是“纯 Chat”或“纯 Agent”，而是把灵活决策放在真正需要的位置。

用户体验

可以使用二维矩阵选择产品形态：

执行架构 \ 交互界面	内联/表单	Chat	任务工作台	后台/通知
普通 AI 功能	改写、提取	简单问答	通常不需要	批量生成
Workflow	审批、录入	引导式办理	多步骤流程	定时流水线
Agent	智能操作建议	动态助手	深度研究、Coding	监控、主动助理

这个矩阵说明：执行架构和界面可以自由组合，但并非每种组合都同样自然。

自主性边界

Chat 容易让用户误以为系统只是在“回答问题”，但对话背后可能触发真实动作。因此产品需要把回答和执行区分开：

“我建议你发送这封邮件”属于建议；
“邮件已经准备好，等待确认”属于准备；
“邮件已发送”属于执行结果。

只要系统可能执行外部动作，就应该在界面上显示动作对象、影响范围和确认状态，而不能只在一条自然语言回复里含糊表达。

数据与权限

不同界面会影响数据边界：

Chat 用户可能输入超出预期范围的敏感信息；
表单能限制字段，但可能缺少上下文；
任务工作台通常包含文件、中间产物和更长的历史；
后台 Agent 需要长期凭证、触发条件和通知权限。

产品设计需要明确每种入口能够访问的数据，而不是默认一次授权适用于所有任务。

失败与降级

不同产品形态的失败体验也不同：

产品形态	合理的失败处理
Chat	解释缺少什么信息，并允许用户补充
Workflow	标出失败步骤并从断点重试
任务工作台	保留计划、中间结果和阻塞原因
后台 Agent	通知用户、暂停后续动作并提供处理入口

把长任务只放进 Chat 的常见问题是：用户看到“正在处理”，但不知道完成了多少、是否可以离开、失败后还剩下什么。

产品指标

除了任务成功率，还应该观察界面是否与任务匹配：

完成任务需要多少轮对话；
用户有多少输入可以被结构化控件替代；
澄清问题是否减少了错误；
长任务中途退出率；
任务恢复成功率；
高风险动作确认前的取消率；
后台通知打开率与后续处理率。

采用判断

适合 Chat 的情况：

用户目标开放，难以用固定字段描述；
需要多轮澄清；
用户会基于结果继续追问；
任务以信息交换为主。

不适合只用 Chat 的情况：

输入字段和业务规则高度稳定；
用户需要比较、筛选或批量编辑；
任务运行时间长，需要状态管理；
包含支付、发送、修改或删除等高风险操作；
结果主要是文件、报告、代码或可编辑 artifact。

最小架构理论

交互层和执行层

将 AI 产品拆成两个正交层：

Interaction Layer
  chat | form | inline | workspace | background
                    |
                    v
Execution Layer
  model call | workflow | agent | hybrid

交互层负责获取目标、展示状态和给予用户控制；执行层负责决定下一步、调用能力并维护任务状态。

Chat 后面的四种实现

1. Chat -> Model -> Response

2. Chat -> Router -> Fixed Workflow -> Response

3. Chat -> Agent Loop -> Tools -> Response

4. Chat -> Workflow Guard -> Agent -> Approval -> Action

用户看到的可能都是聊天界面，但系统的可控性、成本和风险完全不同。因此产品文档不应只写“采用 Chat 方案”，而要同时描述执行架构。

Agent 不等于聊天机器人

下面的系统都可能是 Agent，但不需要持续对话：

每天监控数据异常并生成调查任务；
在后台阅读一批资料并输出研究报告；
根据代码仓库状态修复测试；
收到事件后分析影响并准备操作建议。

它们更适合任务对象、进度事件、artifact 和通知，而不是把所有状态塞进消息列表。

产品体验流

以深度研究为例，纯 Chat 体验可以改造成任务工作台：

Chat / Form 提交目标
    -> 显示范围与计划
    -> 创建可离开的后台任务
    -> 工作台显示步骤、来源和中间产物
    -> 需要选择时通知用户
    -> 交付可编辑报告
    -> Chat 用于追问和继续研究

Chat 仍然存在，但它不再承担任务状态、文件管理和所有控制操作。

系统执行流

Chat / Form / Trigger
        |
        v
Intent and Input Normalization
        |
        v
Product Policy and Router
   |        |         |
   v        v         v
Model    Workflow    Agent
Call                 Controller
   \        |         /
    \       v        /
     -> Typed Task State
             |
             v
 Progress / Approval / Artifact / Notification

无论入口是什么，执行结果都写入结构化任务状态，再由不同界面消费。这样可以避免 Chat 历史成为系统唯一的状态存储。

最小可运行实践

运行产品形态建议器：

python examples/product-decisions/product_shape_advisor.py

它分别输出：

execution_mode：普通 AI 功能、Workflow 或 Agent；
interface_mode：内联/表单、Chat、任务工作台或后台通知；
required_controls：审批、进度、取消恢复等产品能力。

这个示例的重点不是规则是否覆盖所有产品，而是强制团队分别讨论执行架构和交互界面。

正常场景

“研究并比较三家公司的产品策略”需要根据中间证据调整计划，而且运行时间较长。建议器会选择 Agent 执行和任务工作台，同时要求进度、取消与恢复。

“提取合同中的固定字段并写入审核队列”步骤稳定，应采用 Workflow 和表单/任务界面，而不是因为使用自然语言模型就设计成 Chat Agent。

失败与降级场景

失败一：Chat 成为唯一状态

用户关闭页面后任务丢失，或者重新进入时只能看到长消息历史。解决方式是引入独立 task state，由 Chat 只负责显示和操作任务。

失败二：高风险动作藏在回复中

Agent 在一段回复中表示“已经替你发送”，用户无法在执行前检查对象和内容。解决方式是把动作提升为结构化 approval card。

失败三：固定流程被包装成自由对话

用户需要反复回答本可以用表单一次收集的问题。解决方式是 Chat 负责解释和处理例外，表单负责稳定字段。

产品指标与架构对比

可以对同一任务测试 Chat-only 与 Hybrid UI：

指标	Chat-only	Chat + Structured UI
平均对话轮数	记录	记录
信息填写完成率	记录	记录
长任务中途退出率	记录	记录
错误操作取消率	记录	记录
任务恢复成功率	记录	记录
用户完成时间	记录	记录

如果结构化界面减少了轮数和错误，就没有必要为了“更像 AI”而坚持纯 Chat。

上线检查清单

是否分别定义了交互层和执行层？
Chat 是否真的降低了开放输入或澄清成本？
稳定字段是否使用了更合适的结构化控件？
长任务是否具有独立状态、进度和恢复入口？
高风险动作是否从自然语言回复中提升为明确确认？
Agent 是否可以在没有 Chat 页面持续打开时安全运行？
产品文档是否准确描述系统自主性？

小结

Chat、Workflow 与 Agent 不是同一层面的三个选项。

更准确的产品设计方法是：

先决定执行路径由代码还是 Agent 动态控制；
再根据用户任务选择 Chat、表单、内联、工作台或后台通知；
最后补齐与自主性匹配的进度、审批、失败恢复和权限控制。

下一篇将讨论 Agent 产品的自主性阶梯，进一步拆解“建议、准备、有界执行和高自主运行”的产品边界。

延伸练习

选择一个现有 Chat 产品，画出它背后的实际执行架构。
找出三项更适合表单、按钮或任务工作台的对话操作。
为同一个研究任务设计 Chat-only 和 Chat + Workspace 两种体验，并定义比较指标。