1. 产品介绍
给需要跨工具办事的人，一套可组合的自动化工具
n8n 把不同应用连接成工作流，也就是按预先安排的步骤自动处理任务，适合需要反复整理数据、分派请求或更新业务记录的团队。过去，搭建者主要在画布上规定执行顺序；2026 年 9 月 25 日推出的 Agents 增加了智能助手这一入口：写清目标，选择模型和允许使用的工具，由 Agent 根据当前情况决定下一步。
例如，客服收到“最近账号不好用”的消息，往往还不知道该查哪项服务。固定流程可以稳定地查账号和合同，却未必事先知道所有追问。Agent 可以承担理解问题和继续询问的部分，再调用已配置好的查询流程。最终需要的不是一段漂亮回答，而是与业务记录对得上的处理结果。
2. 核心使用流程
先把业务动作准备好，再把判断交给 Agent
以“收到客户投诉，查明情况后留下备注”为教学情境。团队先确定哪些查询和写入允许发生，再把已有工作流作为可调用动作连接给 Agent（智能助手）。固定流程负责具体执行，Agent 负责根据对话判断下一步需要什么。Agents 发布介绍的客服例子就把账号备注封装成接收账号与备注的工作流。
从 Agents 创建草稿，填写职责、选择模型并连接所需工具。访问应用所需的授权信息、操作范围与审批条件都需要配置。Agents 仍处于预览阶段；构建文档列出自托管版本和环境要求，并说明暂不支持 queue mode（将任务排入队列、交给独立进程执行的运行方式），自托管团队应先确认运行条件。
用一条实际请求走通判断与执行
- 先理解输入：客户只说“账号不好用”时，Agent 可以继续询问，再选择需要的查询工具。
- 调用受限动作：工作流按既定步骤读取账号或写入备注，返回结果供后续判断使用。
- 在敏感动作前介入：要求批准的工具会先暂停，用户批准或拒绝后再继续相应路径。审批应围绕具体对象和内容理解，连接了客户资料系统 不等于可以任意修改客户资料。
- 回看会话过程：检查实际调用与结果，确认备注去了正确账号，而不只看最后一段回答是否流畅。
Agent 与工作流也可以反向组合：工作流通过 Message an Agent（向智能助手发消息）把需要理解的一步交出去，再处理返回结果。这使一个不确定的判断可以嵌入原有业务步骤，而不必重建整套自动化。
从草稿预览到团队使用
先在草稿预览里检查几种真实任务，再发布配置，通过连接的渠道或定时任务使用。后续修改继续留在草稿，经过查看再替换发布版本；恢复配置不会撤销已发通知或已写记录。
Agent 与工作流共用执行配额，持续对话也有运行成本。判断是否可用，应同时看任务是否完成、工具是否在正确范围执行，以及团队能否解释失败后的去向。可配置的自由度很有用，但业务权限与核对结果仍需有人负责。
3. 设计亮点与借鉴
把“何时做”与“具体做什么”分开
官方客服例子里，“给账号加备注”被封装成一个只接收账号和备注的工作流。Agent 负责判断是否需要记录，工作流负责按既定步骤写入。这个设计值得记住的地方是：自由度不必属于整个系统，可以只属于需要判断的那一层。
假设同事问某客户为何投诉，Agent 可以先查情况，再决定要不要留备注。它拿到的是受限动作，而不是一句“请小心修改客户资料”的泛化要求。产品设计者由此获得一种更具体的控制办法：不是只改善提示词，而是让工具只提供完成这项任务所需的能力。代价是工具划分需要业务理解，过窄会反复调用，过宽又失去边界。
把审批放在动作发生之前
敏感工具可以要求批准，Agent 会在调用前暂停，用户可批准或拒绝。与最后只看一份处理报告相比，这使人能够在影响仍未发生时介入。例如升级紧急工单会打扰值班同事，审批点就应围绕这次升级所影响的人和内容来理解。
审批的价值不在“多一次点击”，而在它是否对应一个能判断的动作。若用户看不懂要发给谁、要改什么，暂停也容易变成机械放行。官方机制提供介入时机，团队仍要把工具范围和操作含义配置清楚。
让修改中的指令与正在服务的版本分开
草稿与发布版本分离：修改先留在草稿，预览后再发布。发布相当于固定一份当前配置，而不是让同事在每次临时编辑后立即接触新行为。会话又留下工具调用和结果，出现问题时能够从实际过程回看。
例如团队改了“何时升级工单”的规则，可以先在草稿试几种输入，再决定是否替换正在使用的版本。这里保留了探索空间，也保留了明确的生效动作。版本恢复针对配置，不应被理解为撤销此前已经发出的通知或已写入的记录。