根据检索到的社区案例与OpenClaw文档，iLink下行消息静默丢弃（sendmessage返回ret:0但不投递）且定位为账号级问题时，通常因该微信号存在旧版OpenClaw/ClawBot残留绑定，导致服务端路由冲突。解除方法如下： 获取账号ID：在部署OpenClaw的服务器执行 openclaw channels status，记录故障微信对应的账号ID（如 9f209b6fa438-im-bot）。 删除残留凭证：手动删除该账号下的三个状态文件： /data/openclaw/state/openclaw-weixin/accounts/<账号ID>.json /data/openclaw/state/openclaw-weixin/accounts/<账号ID>.context-tokens.json /data/openclaw/state/openclaw-weixin/accounts/<账号ID>.sync.json 重启网关：执行 openclaw gateway stop && openclaw gateway start。 重新绑定：运行 openclaw channels login --channel openclaw-weixin 重新扫码授权。 若上述操作后仍无法恢复，或使用的是非OpenClaw的自建客户端，目前尚无公开的iLink服务端解绑API，需通过腾讯云开发者社区或微信开放平台技术支持提交工单，提供完整的 user_id、botId 及对照实验日志申请平台侧清理路由缓存。 官方活动链接：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

下行100%不投递且sendmessage返回ret:0，大概率是账号级残留绑定导致服务端路由指向已失效的旧session。排查步骤： 对照实验：同机同客户端换另一个微信号测试。若新号正常、仅故障号丢失，确认是账号级问题而非客户端或参数错误。 排除常见误判：typing正常显示说明鉴权和上行链路没问题；ret:0不代表投递成功，只是服务端接收确认。 清理本地凭据：删除该账号对应的state文件（如<accountId>.json、.context-tokens.json、.sync.json），重启gateway后重新扫码绑定。 验证修复：若仍不投递，说明残留绑定在iLink服务端侧，本地清理无效。目前无公开解绑API，需通过腾讯云开发者社区或微信开放平台提工单，提供完整user_id、botId及请求日志申请平台侧清理路由缓存。 注意：反复新建bot实例无法解决此问题，根因在服务端路由未更新。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

先给结论：不要把清洗压在某一层，单点必然漏。稳妥做法是“一个共享 normalize 工具 + 分层兜底”：组件层做粘贴拦截和即时提示，提交前统一 normalize 收口，请求拦截器和服务端校验做最后两道防线。三种表单形态复用同一个工具，就不会再漏两处。 一、分层职责怎么放 1. 共享 normalize 工具（核心，只写一份） 把规则收敛成一个纯函数 normalize(value, fieldType)，普通输入、富文本、数组表格的每个字段都调它，按字段类型决定清洗强度。数组表格要逐格遍历，不能只清洗整行字符串——你之前漏的两处，多半就是绕过了提交函数、各自拼装 payload 的入口。 2. 表单组件层（体验层） - 监听 paste 事件，粘贴时先过一遍清洗再填入，减少用户看到脏字符。 - 对已知不可见字符给即时提示，但不要在输入过程中静默改写合法内容。 - 富文本要区分文本节点和标签结构：只清洗文本节点，不能把标签、样式里的合法内容冲掉。 3. 提交前统一 normalize（收口层） 在表单提交的统一出口（提交函数或校验器）对最终 payload 递归遍历所有字段，再过一遍 normalize。统一出口加递归遍历，能兜住各种绕过提交函数的拼装方式。 4. 请求拦截器 / 服务端校验（兜底层） - 拦截器只做最后一道格式兜底，不承担业务清洗。 - 服务端一定要有字段长度、字符黑白名单校验；前端清洗不可信任，超长直接拒绝并报错，而不是截断入库。 二、怎么不误删合法的换行和空格 关键是按字符分类区别对待，而不是一刀切 replace 空白： - 保留：用户主动输入的普通换行、半角空格，以及业务确需的全角空格、段落分隔。 - 归一：Word/微信带来的软换行（\v、\u2028、\u2029 等）按业务需要归一成普通换行；连续制表符、连续空格按字段类型压缩。 - 剔除：零宽字符（\u200B、\u200C、\u200D、\u2060、\uFEFF 等）、不可见控制字符和 BOM；富文本里这些通常没有合法用途。 - 长度：清洗后再按字段上限校验，超出长度明确提示是哪一列、哪一格，而不是默默截断。 建议先列一张“字符分类表”（保留 / 归一 / 剔除），把每种字符的码位写清楚，normalize 按表执行；再准备 Word、微信、Excel 来源的粘贴样本做回归用例，三种表单形态各跑一遍，确认漏不掉。 三、落地顺序 先抽共享 normalize，并在提交出口递归调用，堵住线上脏数据；再补组件层粘贴清洗和提示；最后加服务端校验兜底。用历史脏数据样本回放验证清洗结果，再上新规则。... 展开详请

根据检索到的腾讯云社区案例及iLink协议文档，你遇到的现象属于已知的“账号级下行静默丢弃”问题，并非你的代码或Gateway故障。 ret=0 的含义：在 iLink sendmessage 接口中，ret=0 仅代表服务端成功接收并校验了请求参数（鉴权通过、格式合法），不代表消息已成功投递到用户终端。该接口设计上不返回 message_id 即表示未进入有效投递队列。 故障定性：多个社区帖子（2026-08-31、10-12、10-28）记录了完全一致的症状：特定微信号上行正常、sendtyping 正常显示、sendmessage 返回 ret=0，但正文100%丢失；同机换号立即恢复。这已被定位为腾讯侧针对特定账号的下行通道拦截或风控标记，与Bot实例、Token新旧无关。 Typing与正文链路差异：sendtyping 走的是轻量级状态信令通道，而正文消息走独立投递队列。Typing正常仅证明会话连接存活，不能证明正文投递链路畅通。 建议：此问题客户端无法自愈。请通过腾讯云工单提交该用户ID（o9cq809nGraLoZYHeN7VGHmzDmaM@im.wechat）及复测时间戳，要求核查下行队列丢弃原因及账号风控状态。目前无公开API可获取投递级Trace ID。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

你遇到的ret=0但消息不投递，是iLink已知问题。社区已有完全相同的对照实验：同一进程换微信号下行立即正常，故障号无论换几个bot实例都100%丢失，定位到账号级绑定残留，不是协议或客户端问题。 解绑只能由官方处理，用户侧清缓存、重扫码无效。建议带user id、服务器域名、绑定时间及“换号对照正常”的复现结论，通过腾讯云开发者社区或工单联系iLink/ClawBot团队请求清理残留绑定。 临时方案是换一个未绑过的微信号顶替，等旧号残留解除再切回。目前公开材料未提供该问题的官方修复时间表，也未说明是否属于策略性限制，需以官方工单回复为准。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

故障账号 iLink user_id：o9cq80-3-txDdq_oh5LL_eZh-__4@im.wechat 环境：Windows（DeepSeek Harness 桌面版）+ @xmanrui/dsh-im 5.10.0（自建 iLink bot 客户端）； 手机 鸿蒙 HarmonyOS【7.0.0.111 SP12】，微信【Version 8.0.23】 现象（2026-11-11 21:37 起，全部为本机实测）： - 上行 getupdates 正常，消息能收到，context_token 正常入库； - sendtyping 手机端正常显示“正在输入”； - sendmessage 稳定返回 HTTP 200 {"ret":0}，本机日志零报错； - 手机端收到的正文为 0 条，包括「连接测试」这类最朴素的纯文字消息也收不到。 已排除（每次重绑都清理旧 token 后重新扫码）： - 5 次全新 bot 实例，逐条完全复现： 2436f223e90e@im.bot（21:46）、67dafbe221de@im.bot（21:53）、 6cb49db33593@im.bot（22:06）、62c556286126@im.bot（22:40） - 移除接入后重新扫码、清空本地状态均无效； - 非本地网络/凭据问题：上行与 typing 均正常，仅下行正文不投递。 诉求： 1. 请协助解除该微信号在 iLink / ClawBot 侧指向历史连接或失效会话的残留绑定， 使新绑定的 bot 能正常下行投递； 2. 若属于已知故障或策略限制，请告知原因及预计恢复时间； 3. 如需完整请求/响应报文或抓包，我可以提供。... 展开详请

微信授权后网页加载失败，先别急着重装。大概率是OAuth缓存脏了或系统时间偏了。 桌面端删掉%APPDATA%\Tencent\WorkBuddy\oauth\下的session_cache.json和wechat_auth_state.bin，macOS路径在~/Library/Application Support/WorkBuddy/oauth/。同时检查系统时间是否自动同步，偏差超5分钟JWT验证必挂。 网络环境也要排查，校园网和企业网常拦截AI工具域名，换手机热点试一下最直观。有代理的话执行netsh winhttp reset proxy清残留。 如果图形界面死活加载不出来，保持WorkBuddy运行，按Ctrl+Shift+I开控制台输window.workbuddy.auth.forceLogin()绕过前端直接认证。 以上都不行就翻日志目录里最近的workbuddylogs，搜502或redirect_uri mismatch定位具体报错。 官方详细解决方案：https://cloud.tencent.com/product/workbuddy?Is=sdk-topnav... 展开详请

这确实是目前企业微信智能表格的体验痛点。官方暂未提供“一键复制当前记录链接”的快捷按钮，只能右键记录手动复制链接，操作路径较深。更关键的是，由于智能表格底层是数据库而非传统电子表格，记录没有固定的行列坐标，导致链接打开后只能跳转到所在视图或数据表，无法像Excel那样精准锚定到具体某一行，尤其在数据量大时定位感极差。 这是产品架构决定的阶段性限制，并非网络或权限问题。目前可行的折中方案是：在表格内新增一个“唯一ID”字段，复制链接后通过筛选该ID快速定位；或在反馈入口提交需求，推动官方优化记录级分享与跳转能力。短期内建议将需要频繁分享的记录单独导出或转为文档卡片，避免反复经历“复制链接-打开-手动翻找”的流程。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

报障前先按下面清单过一遍，能省不少来回。 准备这些材料：Bot ID（xxx@im.bot）、目标用户 ID、是否群聊、最后正常发送时间、开始异常时间。日志里重点截 ret、errcode、errmsg、context_token 这几项，还有 /ilink/bot/sendmessage 的入参。 优先排查： ret=-2 / 缺 context_token：用户超过 8 小时没互动，token 失效，让对方先发一条再重试。 errcode=-14：登录态过期，重新扫码。 无报错但不投：gateway 长轮询断链或进程僵死，ps aux 查一下，不行就重启。 群聊不投：iLink Bot 一般不支持普通群聊，改用 1v1。 多实例冲突：同一 token 被多个 gateway 占着，停掉多余的。 定时推送失效：24 小时窗口内用户没发消息，加个健康检查消息刷新 token。 提报话术： Bot ID：xxx@im.bot，目标：xxx@im.wechat，1v1/群聊：，最后正常时间：，异常开始：。sendmessage 返回 ret=，errmsg=__，context_token 已/未携带。日志见附件，已确认 gateway 存活/已重启，对方已于 __ 发过消息仍不投递。 把 ret、token 是否有效、是否群聊、是否超 24 小时无用户消息写清楚，基本就能定位。 官方详细解决方案：https://cloud.tencent.com/solution/wechat... 展开详请

ret:0 但 100% 不投递，且换 4 个 bot 实例都复现——这个组合基本可以排除 bot 侧发送逻辑的问题，重点查平台侧路由和账号绑定：1. 先确认「同一微信号」的绑定关系：iLink/企微侧的 sendmessage 是走「账号路由」的，如果你这 4 个 bot 用的是同一个应用/同一个路由 key（比如相同的 agentId 或相同的关联小程序），那本质上还是同一条通道，换实例没用——正确做法是换应用或换路由配置，而不是换 bot 进程；2. 检查消息的 to 字段：微信侧会话分「用户会话」和「群会话」，下行消息必须带对 receiver 类型和正确的 openid/external_userid，类型不匹配时很多网关会静默丢弃而不是报错；3. 抓服务端日志看消息是否真的进了投递队列：ret:0 只代表「网关已接收」，不代表「已投递」，要看投递层有没有 ack 记录，如果投递记录里没有微信侧的回执，说明消息卡在网关到微信侧的链路上，这种一般要去查该微信号的授权状态（token 过期、token 刷新失败都会静默丢）；4. 最后检查微信侧的「会话隔离」：如果微信号被标记为测试号或会话未激活，下行也会被静默丢弃。建议先抓网关投递日志区分「未进队列」和「进了队列但无回执」，这两个方向查起来完全不同。... 展开详请

我也是这个问题，已经弄了两天了没有好 同样的sendmessge返回ret=0 但微信端收不到消息，请求排查是否存在旧绑定残留 这是我的 user id o9cq809RhAAANrPiSBx7JAMeJPLk@im.wechat 希望问题尽快解决，谢谢！... 展开详请