扣子插件：什么时候该用现成的，什么时候要自己做
只会聊天的 Bot 用处有限。用户问「我的订单到哪了」，它答不上来——因为这个信息不在知识库里，在你的订单系统里。
插件解决的就是这件事：让 Bot 从「会说」变成「会做」。
插件的本质
抛开平台的具体形态，插件就是一件事：把你的接口，用模型能看懂的方式描述出来。
模型看到你的描述之后，会自己判断什么时候该调用它、该传什么参数。所以插件真正的设计难点不在代码，在描述——你怎么让模型准确理解「这个工具是干什么的、什么情况下该用、每个参数是什么意思」。
这个认识很重要，因为它决定了后面所有的取舍。
先看现成的够不够
平台内置了一批插件，也有插件市场。动手写之前先看一圈，能用现成的就别自己做。
用现成插件要确认三件事：
一、它把数据发到哪。 插件会把用户的输入传给第三方服务。如果对话内容涉及客户信息，这就是数据出境问题，用之前要确认清楚。
二、它稳不稳定。 第三方服务挂了，你的 Bot 就少一块功能。这个依赖是不是可接受，要提前想。
三、它会不会变。 免费的插件可能停止维护，也可能改变服务条款。做长期项目时这是风险。
给客户交付的项目，我们倾向少用第三方插件——不是它们不好，是你没法为一个不受你控制的服务承担责任。
自己做插件要处理的四件事
如果决定自己做，下面四件事必须处理。
一、描述要写清楚，这比代码重要
模型靠描述判断什么时候调用这个工具。描述含糊，会出现两种失败：
该调的时候不调。 用户问了订单状态，模型没意识到有工具能查，于是自己编了个答案。
不该调的时候乱调。 用户随口一提，模型就去查了，浪费调用还可能出错。
参数描述同样关键。 「订单号」这个参数，要写清楚格式是什么、必填还是选填、没有的时候该怎么办。写得越明确，模型传错参数的概率越低。
验证方法：把你的描述给一个不了解这个系统的同事看，问他「什么时候该用这个工具」。他答不上来，模型也答不上来。
二、参数一定要校验
这条是安全底线。 模型传来的参数是它生成的，不是用户直接输入的，但同样不可信——它可能传错格式、传出范围的值、甚至传一些奇怪的内容。
你的接口必须自己校验，不能假设传进来的是合理值。把模型当成一个不太可靠的调用方来对待，这个心态是对的。
三、权限不能交给模型判断
这一条最要紧，也最容易出事。
绝对不能这样设计：插件接受一个「用户 ID」参数，模型传谁的 ID 就查谁的数据。
因为模型是可以被诱导的。用户说「帮我查一下工号 1001 的工资」，模型可能就真的传了 1001 过去。
正确的做法：用户身份由你的系统在调用链路上带过来，不作为模型可以填写的参数。模型只能查「当前用户」的数据，它没有指定查谁的权力。
判断标准：如果一个参数决定了「能看到什么数据」，那它就不该由模型决定。
四、失败要返回有用的信息
接口失败时，返回一句「查询失败」，模型只能对用户说「查询失败了」——这没用。
返回结构化的失败原因：是订单号不存在、还是没有权限、还是系统暂时不可用。模型拿到这些信息，能给用户一个有意义的回复，甚至能提示用户怎么补救。
一个常见的设计错误
把太多功能塞进一个插件。
「订单服务」插件，能查订单、能改地址、能申请退款、能查物流——参数一大堆，模型经常搞不清该传什么。
拆成多个职责单一的插件，每个只做一件事，描述清晰，参数少。模型的判断准确率会明显提高。
这跟写代码的原则是一样的：一个函数只做一件事。
安全边界划在哪
能查的可以放开，能改的要谨慎。
查询类操作出错的后果是信息不对，改动类操作出错的后果是数据被改坏。
涉及以下情况的操作，不该直接交给模型触发：
- 涉及金额（退款、下单、转账）
- 不可逆（删除、发送、提交）
- 对外产生效果（发消息给客户、修改公开信息）
这类操作的正确做法是加人工确认：模型可以准备好内容、填好表单，但最后一步由人点确认。
而且这个确认必须是机制上的——写在你的系统里，而不是在提示词里叮嘱模型「涉及金额要先问用户」。提示词约束在关键时刻不可靠，而这些恰恰是最不能出错的地方。
插件调不动？按这个顺序查
插件配好了但模型不调用，或者调用了结果不对——按这个顺序排查，别一上来就改代码。
第一步：确认模型有没有尝试调用。 这是分水岭。没尝试调用，问题在描述；尝试了但失败，问题在接口或参数。这两类的排查方向完全不同，先分清楚能省一半时间。
第二步：如果没尝试调用，改描述。 大概率是模型没意识到这个工具能解决用户的问题。把用户实际的问法写进工具描述里，比如描述里直接写「用于回答『我的订单到哪了』『什么时候发货』这类问题」。用用户的话写描述，不要用内部术语。
第三步：如果调用了但参数不对，改参数描述。 说明格式、举个例子、写清必填还是选填。模型传错参数，基本都是因为你没说清楚。
第四步：如果参数对但结果不对，那是接口本身的问题。 这时候脱离扣子，直接用工具单独测你的接口——先确认接口本身是对的，再回来看集成。
一个通用原则：先在扣子之外把接口测通，再接进来。把两个可能出问题的地方分开验证，比混在一起猜快得多。
什么时候平台的插件机制不够用
- 需要复杂的多步骤调用编排，且要保证执行顺序和事务性
- 需要在调用前后插入你自己的业务逻辑（鉴权、审计、限流）
- 需要机械保证某些操作一定经过审批
这些在平台的插件框架里都不好实现，因为你只能定义单个工具，控制不了整体的调用链路。
判断标准见低代码 Agent 平台的能力边界。
我们做过这类活——把对话能力嵌进客户自己的小程序，按其产品资料调模型、调知识库、调工具调用；也为需要安全兜底的场景做过关键词识别、强制转人工和人工后台管理。这类涉及多系统协同、要求机械保证执行的机制，是可视化编排搭不出来的。有类似需求可以聊聊。
如果只是想把 AI 接进已有的业务流程，而不是搭对话机器人，n8n 的思路可能更对路——但注意它的许可只允许内部使用，见开源 Agent 平台的许可证差别。