智能体还是工作流？按任务的不确定程度选择

区分固定规则与临场判断

收到表单后检查必填项、按部门分配、保存结果，这些规则可以提前确定。阅读一段模糊需求、判断应查哪类资料，则可能需要模型理解内容。不要为了使用 Agent 而将已有清楚规则变成自由判断。

普通工具完成单一动作，如格式转换或查询记录；工作流规定动作的顺序；智能体可以在约束内选择工具或下一步。实际产品的命名各异，比较时应看执行方式而不是名称。

在同一项业务中组合使用

以询价整理为例，模型提取客户需求，程序检查字段，业务人员补充缺失信息，再按规则进入处理队列。这里的读取、提取、校验和交接各有明确作用。

只有当任务确实需要多轮判断，例如发现缺失条件后选择进一步检索，才增加智能体的自主范围。同时说明允许的工具、最大执行范围和停止条件，避免无限追加操作。

按维护能力决定复杂度

能够运行的原型还需要日志、失败处理与版本记录。团队没有能力定位多轮调用问题时，较明确的流程通常更便于交接和维护。复杂度应随实际需求增加。

Dify 与 n8n 等平台都提供应用或流程编排能力，具体功能因版本和部署方式不同。选型时用自己的任务样例比较，检查结果与运行记录，不把官方示例当作企业环境已经验证的效果。

把业务责任与模型判断拆开设计

设计前列出三种决定：可以由规则直接判断的、需要模型理解材料的、必须由业务负责人作出的。比如客户编码是否存在可以查询系统，邮件里哪段表达交货要求需要语言理解，是否承诺某个交期则取决于企业授权。三个决定即使出现在同一页面，也不宜交给同一种执行方式。

智能体的自主程度可以逐步增加。先让它提出下一步建议，由确定流程执行；确认建议质量与权限控制可用后，再开放有限工具选择。团队应能解释每一项自主能力解决了什么问题，以及错误发生时由谁发现和处理。

以询价整理为例，画出可交接的执行链

入口接收邮件后，先分配业务标识并保存来源，再提取型号、数量和条件。程序核对字段与产品目录，缺失项进入待补充状态。只有资料齐全且经过适当确认，才将结果交给后续业务。该例用于说明设计方法，不代表某个产品已接入企业邮件或订单系统。

如果客户使用含糊称呼，可以让模型选择查找产品目录或历史术语表，但检索范围和可返回字段必须明确。检索后仍无法确定型号，应把不确定项返回业务人员。智能体有能力继续查找，不意味着它有权代替客户决定需求。

工具越多，越需要清楚的停止条件

为每个工具说明用途、输入字段、返回内容和可能的副作用。相似名称却含义不同的工具会增加选择错误；一个工具承担过多业务动作，则让审核和恢复变得困难。优先使能力职责清楚，再考虑是否需要统一包装。

运行限制可以包括允许访问的对象、最大调用次数、等待时间和费用范围。限制触发时返回当前完成部分、未完成事项与原因。不能以“继续努力完成任务”替代停止策略，否则模型可能反复检索同一资料或重复尝试已明确失败的接口。

让中间状态成为可以检查的业务记录

执行状态至少应区分已接收、处理中、等待资料、等待确认、已完成与失败。保存状态时同时保留业务标识和相关版本，避免使用者只看到聊天窗口里的自然语言描述。对关键动作，可额外记录目标对象与系统返回的结果标识。

人工修改提取结果后，后续步骤应使用确认后的值，并保留原始结果以便追查。工作流重跑时要知道哪些结果可以复用、哪些需要重新审核。尤其不要让一个旧的确认动作自动覆盖后来变化的客户、金额或发送内容。

平台比较应使用同一任务与同一验收条件

比较 Dify、n8n 或代码实现时，准备同一组脱敏输入，核对连接现有系统的方式、日志可见范围、权限控制与维护难度。平台提供的能力名称只是入口，实际版本、套餐和部署环境才决定可用范围。价格和配额应单独查询当前服务说明。

演示之后，安排未参与搭建的人根据说明修改一个字段、定位一次失败并重跑任务。能否完成这些操作，可以帮助判断方案是否适合长期维护。对尚未验证的功能，写入待核验清单，避免把未来可以开发的能力作为当前交付内容。

先画询盘的确定步骤与判断步骤

把接收去重、提取需求、字段检查、人工补缺和正式处理分别画出。规则明确的交给程序，需要理解的由模型辅助；只有确实需要选择下一步时才增加自主范围，并记录停止与接手机制。