修改消息节点

修改消息节点用于替换一条已有消息的文本内容。节点先在当前会话项目和当前用户作用域内定位会话，再按消息 ID 查找该会话中的有效消息；修改成功后，后续查询消息列表、查询会话历史或读取会话上下文时会看到新的内容。

适用场景

• 修正写入会话历史的错别字、错误参数或脱敏后的文本。
• 在测试会话中替换构造的用户消息或助手消息。
• 在进入后续模型节点前，修正上游已创建消息的内容。
• 对业务流程明确允许修改的消息执行受控更正。

节点每次只修改一条消息的文本，不会重新生成模型回答，也不会改变消息角色、消息 ID、所属会话或原有时间顺序。

使用前提与作用域

• 目标会话必须存在，并属于当前会话项目和当前用户。
• 目标消息必须属于该会话，且尚未被删除或随会话历史清空而失效。
• conversationName 可以填写会话名称；当前执行器也会优先把该值尝试作为会话 ID 查找。
• 使用名称查找时不区分大小写；如果存在同名会话，选择最近更新的一条。
• messageId 应来自“创建消息”或“查询消息列表”的实际输出，不要手工猜测。
• 资源库工作流试运行应关联目标应用，使运行上下文提供会话项目；缺少会话项目时返回 isSuccess=false。
• 有明确会话项目时，会按当前用户的项目访问权限执行。

推荐把唯一的 conversationId 传给 conversationName，并同时使用同一会话查询得到的 messageId。这样可以避免同名会话或跨会话消息 ID 导致未命中。

添加与配置节点

1. 在工作流画布中单击“添加节点”。
2. 选择“消息节点”中的“修改消息”。
3. 配置目标会话、目标消息 ID 和新的文本内容。
4. 将 isSuccess 接入条件分支。
5. 成功后重新查询消息列表或会话历史，确认内容已更新。
6. 试运行时使用专门创建的测试会话和测试消息，不要直接修改生产会话。

输入参数

参数	类型	必填	说明
conversationName	String	是	消息所属会话名称；当前执行器也支持传入会话 ID。节点定义不预置非空默认值，截图中的 Default 只是示例配置
messageId	String	是	要修改的消息 ID，必须属于解析出的目标会话
newContent	String	是	修改后的非空文本内容，当前固定按 text 内容类型保存

所有参数均可填写固定值或引用上游变量。三个参数在去除首尾空白后都不能是空字符串；缺失或空白会触发必填参数错误，而不是返回成功。

会话和消息定位

节点按以下范围定位目标：

1. 使用当前运行上下文中的会话项目和当前用户限定可访问数据。
2. 先把 conversationName 当作会话 ID 查找。
3. 未命中时，再把它当作会话名称进行不区分大小写的查找。
4. 在解析出的会话中按 messageId 查找尚未删除的消息。

因此，即使消息 ID 在其他会话中真实存在，只要它不属于本次解析出的会话，节点仍会返回 isSuccess=false。已删除的消息、已清空历史中的旧消息和其他用户的消息也不能通过本节点修改。

实际可修改的内容

当前节点只接受 newContent，并固定把消息内容类型设为 text：

• 会替换消息的文本内容。
• 不会修改 messageId、角色、所属会话或创建时间。
• 不支持通过本节点把消息改成图片、音频、视频或文件消息。
• 媒体 URL 只会作为普通文本保存，不会自动转换成多模态内容。
• 节点定义不提供角色、元数据或消息类型的编辑入口。

如果业务需要保留原文，应在修改前先查询并归档原内容；当前节点不会返回旧内容，也没有撤销操作。

输出参数

参数	类型	说明
isSuccess	Boolean	是否成功找到并更新目标消息

节点只输出布尔值，不返回更新后的消息对象，也不提供失败原因字段。下游应当显式判断：

• true：目标消息已执行更新；需要新内容时，重新查询消息列表或会话历史。
• false：常见原因是缺少会话项目、会话不存在、消息不存在、消息不属于该会话，或消息已经删除。
• 参数缺失、空白、权限校验失败或存储服务异常可能使节点直接执行失败，而不是统一返回 false。

当前版本的执行逻辑

节点执行时按以下顺序处理：

1. 解析运行上下文中的会话项目和当前用户。
2. 校验 conversationName、messageId 和 newContent 均为非空值。
3. 资源库运行上下文没有会话项目时，直接返回 isSuccess=false。
4. 按“会话 ID 优先、名称兜底”的方式定位当前用户的有效会话。
5. 在该会话内查找相同 messageId 且未删除的消息。
6. 把消息内容替换为 newContent，内容类型设置为 text，并更新修改时间和修改人。
7. 只把底层结果中的 isSuccess 标准化为节点输出。

对会话历史和模型上下文的影响

修改成功后：

• 后续查询消息列表和查询会话历史会读取到新内容。
• 后续基于该会话重新组装上下文的模型调用会使用新内容。
• 已经生成并保存的助手回答不会因为上游消息被修改而自动重新生成。
• 消息位置、角色和消息 ID保持不变，所以修改不会自动修复错误的角色顺序。

如果修改的是较早的用户消息，而后续助手回答是基于旧内容生成的，会话历史可能出现语义不一致。此类场景应评估是否同时清理后续消息并重新生成，而不是只修改一条上游消息。

重复执行与并发修改

• 使用相同内容再次修改同一条有效消息，仍会执行更新并返回成功，不应把它当作“内容发生变化”的判断依据。
• 当前更新没有版本号或条件更新参数；多个流程并发修改同一消息时，后完成的写入会覆盖先完成的写入。
• 节点不返回更新后的版本或时间戳，不能直接用于乐观锁判断。

重要消息应由上游串行化修改，或在业务层保存原内容、修改人和业务版本，避免无意覆盖。

推荐编排

修改已知消息

取得 conversationId → 查询消息列表 → 选择 messageId → 保存原内容 → 修改消息 → 判断 isSuccess → 再次查询确认

不要把查询其他会话得到的消息 ID 与当前会话混用。

修正后继续调用模型

修改消息 → 判断成功 → 查询会话历史确认 → 调用大模型 → 按需写入新的 assistant 消息

修改消息节点本身不会调用模型。若旧回答已经不再适用，应在符合数据留存要求的前提下显式处理旧回答。

试运行与验收

建议使用专门的测试会话：

1. 创建测试会话，并保存其 conversationId。
2. 创建一条带唯一测试文本的消息，并保存 messageId。
3. 使用该会话 ID、消息 ID 和新的唯一文本执行修改节点。
4. 确认 isSuccess=true。
5. 查询消息列表，确认内容已更新，但消息 ID、角色和所属会话未变化。
6. 使用其他会话和同一消息 ID 执行，确认返回 isSuccess=false。
7. 删除或清空测试消息后再次执行，确认不能修改已失效消息。
8. 使用空白 newContent 执行，确认节点明确报必填参数错误。
9. 连续两次写入不同内容，确认最终读取到最后一次写入的内容。

常见问题与处理

现象	原因	处理
isSuccess=false	会话或消息未命中、作用域不匹配、消息已删除，或资源库没有会话项目	核对应用关联、当前用户、会话 ID 和消息 ID；重新查询消息列表
提示参数必填	会话、消息 ID或新内容为空，或引用的上游变量没有值	在上游增加非空校验，并检查变量路径
消息确实存在但仍返回 false	传入了错误会话，或消息属于其他用户、项目或已清空的历史	使用同一会话的查询结果重新取得 ID
修改后模型回答没有变化	节点只更新历史消息，不重新调用模型	在成功分支重新调用模型，并按业务规则处理旧回答
修改后历史语义不连贯	后续回答仍是基于旧内容生成的	评估并清理受影响的后续测试消息，再重新生成
想修改角色但没有入口	当前节点只开放内容修改	重新创建正确角色的消息，并按留存规则处理旧消息
两个流程互相覆盖内容	当前更新没有版本条件，后完成的写入覆盖先完成的写入	串行化修改，或在业务层增加版本和审计控制
无法恢复旧内容	节点不返回原文，也没有撤销能力	修改前先查询并归档原内容

与旧文档的核对结论

旧文档内容	当前处理
每次只能修改一条消息	保留，与当前节点定义和执行器一致
需要会话名称、消息 ID 和新内容	保留；补充 conversationName 也支持会话 ID，且所有值不能为空
消息 ID 来自查询消息列表	保留；补充也可使用创建消息的输出，并且 ID 必须属于本次目标会话
新内容只支持文本，不支持多模态	保留；当前执行器固定设置 contentType=text
输出只有 isSuccess	保留；补充 false 与直接执行失败的边界，以及节点不返回修改后的内容
修改后存储内容和模型可见历史同步变化	保留并细化；后续读取和模型调用使用新内容，但已经生成的回答不会自动重算
可以修改静态会话或动态会话	不作为当前契约沿用；当前实现按项目、用户和会话 ID/名称作用域定位，没有该分类参数
资源库试运行需要关联智能体或应用	调整；当前节点需要会话项目，通常由关联应用提供；缺失时返回 false

发布前检查

• 已优先使用唯一 conversationId，没有依赖可能重复的会话名称。
• messageId 来自同一会话的创建或查询结果。
• newContent 是非空文本，没有把文件对象或媒体 URL 当作多模态消息。
• 已确认业务允许修改这条消息，并满足审计和数据留存要求。
• 需要恢复时，已在修改前保存原内容。
• 下游先判断 isSuccess，成功后重新查询确认实际内容。
• 已评估修改历史消息对后续回答语义一致性的影响。
• 已避免多个流程无版本控制地并发修改同一消息。