收消息API 重用返回值以实现快捷回复

[danni-cool]

收消息API 重用返回值以实现快捷回复

[rcy1314]

个人见解：单通道发送接收是可以做到，比如webhook接收信息post到tg，再设置一个tg机器人post到固定群昵称，就形成了一个发送和接收的回路，加上tg的特性如果拉入该机器人到频道则可以在频道内实现双向接收和发送，在但接收需要name值的判断和对name值的单独包装定义，所以在这里，除了艾特别人时可以看到昵称，基本上对话中自己设置不到可以双向或单独回路的不同的昵称，需要在规则中添加一个存储发送人的昵称name值并轮询和判断下一个会话时舍弃存储的上个name值继续存储本次对话的name值，完成一个不同对话的机制，也可以单独把name定义函数值，在集成中可以设定该name值

[danni-cool]

个人见解：单通道发送接收是可以做到，比如webhook接收信息post到tg，再设置一个tg机器人post到固定群昵称，就形成了一个发送和接收的回路，加上tg的特性如果拉入该机器人到频道则可以在频道内实现双向接收和发送，在但接收需要name值的判断和对name值的单独包装定义，所以在这里，除了艾特别人时可以看到昵称，基本上对话中自己设置不到可以双向或单独回路的不同的昵称，需要在规则中添加一个存储发送人的昵称name值并轮询和判断下一个会话时舍弃存储的上个name值继续存储本次对话的name值，完成一个不同对话的机制，也可以单独把name定义函数值，在集成中可以设定该name值

回复同一个人呢的话，为什么要存储 name，而不是作为流的一部分，从源头(source里带有请求人信息）打标记，带到结束去post呢。

这个issue的提案，是为了改进这个功能，既然是请求的发起方，作为消息接受服务器，只要根据昵称去处理逻辑，最后并回应请求就好了，相当于一对一回复。

[rcy1314]

回复同一个人呢的话，为什么要存储 name，而不是作为流的一部分，从源头(source里带有请求人信息）打标记，带到结束去post呢。

这个issue的提案，是为了改进这个功能，既然是请求的发起方，作为消息接受服务器，只要根据昵称去处理逻辑，最后并回应请求就好了，相当于一对一回复。

需求场景不同，也许我提出的不符合开发中的一环，或者和这个issue的提案不是一回事，我想要流中能提取name【有，但无法单独定义该函数】来记录是哪些人发送的信息，造成即便你能通过改进做到一对一回复，但在记录中无法记录有哪些人进行了对话。或许有人可以解答是否可以把name值作为json中的一个函数值，如果可以，则我的疑问就得到了解决，提过一次，不过我自己改的逻辑并不好，或者是否该放弃发送者名称的记录而选择其它场景

[danni-cool]

我想要流中能提取name【有，但无法单独定义该函数】来记录是哪些人发送的信息

1. 以n8n举例确实无法单独定义一个 flow就能携带 name，但至少每个flow去处理的时候都需要向下传递 name字段。当然你为了方便全局暂存也是合理的做法，但我认为不应该是全局，而是每个环境运行时有自己的变量空间，所以flow向下传递是个合理的场景。我提的issue 包括后面要加的response即回复是优化这个场景。

即便你能通过改进做到一对一回复，但在记录中无法记录有哪些人进行了对话

1. 为啥记录不了？source字段里的 from.payload.name 就是talker
2. 如何回应是你服务器的策略，比如匹配到 @推送助手 就回复他，匹配特殊关键词，开始回复，那此时确实要存一下 这个人+关键词开关状态。但貌似不是我的项目需要去解决的问题

[rcy1314]

1. 为啥记录不了？source字段里的 from.payload.name 就是talker
2. 如何回应是你服务器的策略，比如匹配到 @推送助手 就回复他，匹配特殊关键词，开始回复，那此时确实要存一下 这个人+关键词开关状态。但貌似不是我的项目需要去解决的问题

👌

[danni-cool]

@rcy1314 https://www.npmjs.com/package/@telepilotco/n8n-nodes-kv-storage?activeTab=readme 这个 key-value storage 适合n8n存储场景，执行时存储、工作流存储、全局存储，蛮灵活，不用一层层传递了