n8n 给 Agent 接工具：把业务动作写成可核验的调用契约

把工具描述写成可观察的动作 “处理客户问题”太宽泛，审核时也无法判断一次调用是否正确。更好的边界是“按客户编号查询最近一张已开出的工单”，并说明没有匹配结果如何返回。工具本质上是 Agent 可调用的接口，业务含义需要由工作流设计者明确。 选与实际实现对应的工具 n8n 官方列出 Call n8n Workflow Tool、Custom Code Tool 和 HTTP Request Tool，分别用于把工作流暴露为工具、运行自定义代码和获取网页或 API 数据。已有稳定的内部工作流时，可以先复用它的业务规则；只有简单查询需求时，也可评估直接 HTTP 调用。 这里的选择标准是哪里已经有清晰的输入输出与错误处理，而不是哪种节点名称更像智能功能。 区分用户给定和模型推断的参数 官方资料链接了 $fromAI() 动态填写工具参数的机制。允许动态参数，并不意味着用户编号、日期或操作对象一定推断正确。建议把必须由系统提供的身份信息与模型可选择的查询条件分开，并在执行前检查枚举、范围和缺失值。 例如用户说“看一下昨天那张单”，模型没有足够上下文时，应进入澄清或查找候选的流程，不能把任意一张工单当成确定对象。 把“查订单”缩成一份可检查的契约 例如自拟工具 get_order_status，接收 order_id，由登录态提供 customer_id，只返回该客户可见订单的状态。订单号可来自用户输入，客户身份不让模型凭聊天内容自行填写；服务端仍须按身份核对订单归属。工具说明还应写清“只查询，不取消、不退款”，让动作范围能与执行记录对照。 返回可以约定为 status、order_id、order_status、message 四个字段：查到订单时 status 为 found；不存在或不可见时，按应用原有规则返回统一的 not_found；服务故障则返回暂时不可用状态。这个结构是示例契约，不是 n8n 固定协议。是否向用户区分不存在与无权限，应由原有业务规则决定，不能为了让模型好理解而暴露他人订单。 用户说“取消它”，而工具只有查询能力时，合格结果是说明当前只能查询，或转入已有取消流程。即使模型生成了“取消成功”，也必须有对应动作的实际执行结果才能成立。 先单独测试工具，再接 Agent 准备一个确实存在的编号、一个不存在的编号和一个格式错误的编号。直接验证工具返回的数据结构与状态，随后再让 Agent 通过自然语言调用。若直接调用已失败，继续修改 Agent 提示通常无法修复接口协议。 返回结果应让模型分清业务无结果与服务暂时不可用，内部可保留更细的失败原因；对外是否区分无权限由应用规则决定，避免把所有失败都压成空字符串。这是编辑给出的接口组织建议，并非平台强制格式。 核对最后一句话有没有证据 记录 Agent 选择的工具、实际参数、工具返回及最终回答。若工具只查询了状态，模型却声称已完成修改，应修改工作流契约和回答约束，并用同样案例复验。工具可用、被正确选择、执行成功和叙述准确，是需要分别观察的环节。 接入写入类工具时，把查询与修改分别命名，返回已受理、处理中或已完成的真实状态。异步接口仅接收了请求，最终回答就应保留“处理中”，等后续状态确认后再说完成。

本篇涉及的工具1

n8n

把已有工作流、代码或 HTTP 接口接成 Agent 可调用的业务工具。

适合场景

准备把内部查询、已有工作流或 API 接给 n8n Agent 的开发者。

需要留意

身份来源、参数约束与返回状态仍由应用契约校验。

了解项目 访问官网