Add a Weibo channel with draft-first publishing controls

Add a Weibo channel with draft-first publishing controls

What would you like to be added?

Add a Weibo channel that helps Qwen Code monitor selected account interactions and prepare comment, direct-message, and Weibo post drafts.

The first version should use an official, documented Weibo Open Platform API when the configured account has the required capabilities. Its safe MVP should:

• receive new mentions, comments, and, when officially available, direct messages for the configured account;
• restrict accepted authors and target posts through explicit allowlists;
• map each Weibo post, comment thread, or DM conversation to a stable, isolated channel session;
• generate comment replies, DM replies, repost-with-comment drafts, or new Weibo drafts without publishing automatically;
• represent a publication draft as structured content including action type, target, final body, mentions, topics, visibility, and ordered media;
• require independent publication approval that previews and binds to the complete final publication object before sending any public post, repost, comment, or DM;
• persist cursors, processed event IDs, and publication results to prevent duplicate agent runs and duplicate external actions.

The MVP should focus on inbound monitoring and draft preparation. Proactive new posts and reposts should remain disabled for automatic delivery until their target and approval lifecycle are proven safe.

If suitable official APIs are unavailable for ordinary accounts, a browser-backed or desktop-backed adapter may be explored separately as a local, explicitly enabled extension. It must not silently replace the API transport, scrape the full feed, bypass platform protections, or claim unattended operation when interactive verification is required.

This issue is a focused implementation follow-up to #8280.

Why is this needed?

Weibo is an important platform for public product communication, community feedback, announcements, and issue discovery. A channel integration could help users:

• monitor mentions and comments related to a project or product;
• collect and classify public feedback;
• investigate technical questions against a working directory;
• prepare accurate comment and DM responses;
• draft announcements, status updates, or repost commentary for human review;
• preserve separate agent context for each public conversation.

Weibo publication is a public external action with a much larger blast radius than a private chat response. Posts and reposts may include mentions, topics, visibility, and media, and a reply sent to the wrong comment or account can cause reputational harm. A normal channel response or general agent tool approval must not be treated as publication permission.

The integration should therefore separate monitoring and drafting from publication. Users should receive value from analysis and draft generation without granting autonomous posting rights.

Additional context

Proposed MVP behavior

Inbound

• Consume new mentions, comments, and supported DMs through the configured official API capabilities.
• Establish an initial cursor without replaying historical mentions, comments, messages, or timeline activity by default.
• Use stable platform account, post, comment, and conversation IDs for access control and routing; do not rely only on display names or mutable handles.
• Include bounded parent-comment, repost-chain, and source-post context plus available media metadata in the inbound envelope.
• Map interactions under the same post/comment thread or DM conversation to a stable threadId.
• Deduplicate events across polling overlap, retries, reconnects, and process restarts.
• Ignore the configured account's own events unless needed to correlate a completed publication.
• Respect API rate limits and expose a visible paused/backoff state instead of retrying aggressively.

Structured drafts

• Comment and DM drafts must retain the exact target account, post, comment, or conversation.
• A post or repost draft must store separately:
  • action type: new post, repost-with-comment, comment reply, or DM;
  • exact target post/comment/account/conversation where applicable;
  • final body text;
  • mentions;
  • topics/hashtags;
  • visibility or audience setting;
  • ordered image/video references and digests;
  • any platform-required metadata.
• Validate text length, mention/topic syntax, media count, format, and size constraints before requesting approval.
• Draft creation, media analysis, and editing must not itself cause an external publication.

Publication approval

• The approval preview must display:
  • the authenticated Weibo account;
  • action type: comment reply, DM, new post, or repost-with-comment;
  • exact target post/comment/account/conversation where applicable;
  • final body, mentions, topics, and visibility;
  • the exact ordered media set;
  • any transformations required by platform limits.
• Approval must bind to an immutable draft identity or digest covering the complete publication object. Changing the account, action, target, body, mentions, topics, visibility, media content, or media order invalidates approval.
• General channel approvalMode, including unattended modes, must not be interpreted as publication permission.
• Proactive new posts and reposts should be disabled in the MVP. An approved comment or DM may target only the interaction that produced the accepted event.
• Failure to resolve the exact authenticated account or target must stop; the adapter must never fall back to another post, comment, account, conversation, or currently open page.

Publication lifecycle

• Persist a publication intent before the external request and store the returned platform object ID after success.
• On timeout or ambiguous failure, reconcile against the platform before retrying to avoid duplicate comments, DMs, reposts, or posts.
• Deleted, hidden, unavailable, or permission-restricted source posts and comments must fail closed.
• If the platform presents a CAPTCHA, risk-control challenge, login confirmation, account verification, or another interactive check, pause and require user intervention. Do not attempt to bypass it.
• Record a local publication audit entry with action, target IDs, content/media digests, result, and platform object ID without storing credentials.

API and local fallback boundaries

Weibo API availability and permitted operations may differ by account type and can change independently of Qwen Code. The adapter should capability-detect mentions, comments, DMs, media upload, reposting, and publishing, then disable unsupported features with a clear diagnostic.

A browser-backed or desktop-backed implementation, if pursued, should be an explicit local extension with observe-only and dry-run modes. It should use structured DOM/accessibility elements where available, remain visible to the user, and pause on unexpected UI, identity, login, or risk-control state. It must not:

• scrape or continuously inspect the full feed;
• evade CAPTCHA, rate limits, anti-automation, or account protections;
• extract browser/session credentials;
• automate bulk follows, likes, reposts, comments, or unsolicited DMs;
• use fixed-coordinate speculative clicks when target identity is uncertain.

Suggested acceptance criteria

• A new mention or comment from an allowed account on an allowed post starts or resumes the correct isolated thread and produces a draft.
• A blocked author or unconfigured post is not forwarded to the agent.
• Initial startup does not process historical interactions by default.
• Polling overlap and restart do not process the same event twice.
• A publication draft preserves action, target, body, mentions, topics, visibility, and media order as separate fields.
• No public post, repost, comment, or DM is sent before independent publication approval.
• approvalMode: "yolo" or another unattended agent mode does not bypass publication approval.
• Changing any approved account, action, target, text, metadata, visibility, media, or media order invalidates approval.
• Ambiguous failures and retries do not create duplicate external actions.
• Missing API capabilities, rate limits, login changes, CAPTCHAs, and risk-control challenges pause safely with an actionable status.
• The adapter never falls back to a different target and never attempts to bypass platform protections.

Follow-up scope

Proactive new posts, repost automation, scheduled publishing, analytics, moderation actions, trending-topic discovery, full-feed collection, multi-account management, bulk engagement, browser-backed operation, and additional authorization flows should be tracked separately. Full-feed scraping and anti-automation bypass are explicitly not goals of this channel.

No separate Weibo Channel implementation issue was found. The broader platform roadmap is tracked in #8280.

中文

希望增加什么？

增加一个微博 Channel，帮助 Qwen Code 监控指定账号互动，并准备评论、私信和微博发布草稿。

首个版本应在配置账号拥有所需能力时使用官方、公开文档化的微博开放平台 API。安全 MVP 应支持：

• 接收配置账号的新 @提及、评论，以及正式 API 可用时的私信；
• 通过显式白名单限制允许的作者和目标微博；
• 将每条微博、评论线程或私信会话映射为稳定、隔离的 Channel session；
• 生成评论回复、私信回复、转发评论草稿或新微博草稿，但默认不自动发布；
• 将发布草稿表示为结构化内容，包括操作类型、目标、最终正文、@提及、话题、可见性和有序媒体；
• 发送任何公开微博、转发、评论或私信前，都需要独立发布审批，并预览和绑定完整的最终发布对象；
• 持久化游标、已处理事件 ID 和发布结果，避免重复 Agent 运行和重复外部操作。

MVP 应聚焦入站监控和草稿准备。在目标与审批生命周期被证明安全之前，主动新发微博和转发应保持禁用，不能自动投递。

如果普通账号无法获得合适的正式 API，可以单独评估 browser-backed 或 desktop-backed 的本地显式启用扩展。它不得静默替代 API transport，不得抓取完整 feed，不得绕过平台保护，也不能在需要交互验证时声称支持无人值守运行。

本 Issue 是 #8280 的聚焦实现后续。

为什么需要？

微博是公开产品沟通、社区反馈、公告和问题发现的重要平台。Channel 集成可以帮助用户：

• 监控与项目或产品相关的提及和评论；
• 收集并分类公开反馈；
• 基于工作目录调查技术问题；
• 准备准确的评论和私信回复；
• 起草公告、状态更新或转发评论，供人工审核；
• 为每个公开会话保持独立的 Agent 上下文。

微博发布是公开的外部操作，其影响范围远大于私聊回复。微博和转发可能包含 @提及、话题、可见性和媒体，将回复发到错误评论或账号可能造成声誉损害。普通 Channel 回复或通用 Agent 工具审批不得被解释为发布权限。

因此，集成应将监控和草稿生成与正式发布分开。即使用户不授予自主发布权限，也能使用分析和草稿生成能力。

补充信息

建议的 MVP 行为

入站

• 通过配置的正式 API 能力接收新提及、评论和受支持的私信。
• 建立初始游标，默认不回放历史提及、评论、消息或时间线活动。
• 使用稳定的平台账号、微博、评论和 conversation ID 做访问控制与路由，不能只依赖显示名称或可变 handle。
• 在入站 envelope 中包含范围受限的父评论、转发链、源微博上下文和可用媒体元数据。
• 将同一微博/评论线程或私信会话下的互动映射为稳定 threadId。
• 对轮询重叠、重试、重连和进程重启产生的事件进行去重。
• 忽略配置账号自身的事件，除非用于关联已完成发布。
• 遵守 API 速率限制，显示明确的暂停/退避状态，而不是激进重试。

结构化草稿

• 评论和私信草稿必须保留准确的目标账号、微博、评论或 conversation。
• 微博或转发草稿必须分别保存：
  • 操作类型：新微博、转发评论、评论回复或私信；
  • 适用时准确的目标微博/评论/账号/conversation；
  • 最终正文；
  • @提及；
  • 话题/标签；
  • 可见性或受众设置；
  • 有序图片/视频引用及摘要；
  • 平台要求的其他元数据。
• 请求审批前校验文本长度、提及/话题语法、媒体数量、格式和大小限制。
• 创建草稿、分析媒体和编辑内容本身不得产生任何外部发布。

发布审批

• 审批预览必须展示：
  • 当前认证的微博账号；
  • 操作类型：评论回复、私信、新微博或转发评论；
  • 适用时准确的目标微博/评论/账号/conversation；
  • 最终正文、@提及、话题和可见性；
  • 准确且有序的媒体集合；
  • 平台限制要求的任何转换。
• 审批必须绑定覆盖完整发布对象的不可变草稿身份或摘要。修改账号、操作、目标、正文、提及、话题、可见性、媒体内容或媒体顺序后，审批失效。
• Channel 通用 approvalMode（包括无人值守模式）不得被解释为发布权限。
• MVP 中禁用主动新发微博和转发。已批准的评论或私信只能面向产生该已接受事件的准确目标。
• 无法精确解析认证账号或目标时必须停止；禁止 fallback 到其他微博、评论、账号、conversation 或当前打开页面。

发布生命周期

• 对外请求前持久化发布 intent，成功后保存平台返回的对象 ID。
• 超时或失败结果不明确时，重试前先与平台核对，避免重复评论、私信、转发或微博。
• 源微博或评论已删除、隐藏、不可访问或权限受限时必须安全失败。
• 平台出现验证码、风控挑战、登录确认、账号验证或其他交互检查时，暂停并要求用户介入，禁止尝试绕过。
• 记录本地发布审计，包括操作、目标 ID、内容/媒体摘要、结果和平台对象 ID，但不得保存凭据。

API 与本地 fallback 边界

微博 API 的可用性和允许操作可能因账号类型而不同，也可能独立于 Qwen Code 变化。Adapter 应检测提及、评论、私信、媒体上传、转发和发布能力，仅禁用不受支持的功能，并给出清晰诊断。

如果实现 browser-backed 或 desktop-backed 方案，它应是显式启用的本地 extension，并提供 observe-only 和 dry-run 模式。应尽量使用结构化 DOM/Accessibility 元素，对用户保持可见，并在 UI、身份、登录或风控状态异常时暂停。它不得：

• 抓取或持续检查完整 feed；
• 规避验证码、限流、反自动化或账号保护；
• 提取浏览器/session 凭据；
• 自动执行批量关注、点赞、转发、评论或非请求私信；
• 在无法确定目标身份时使用固定坐标进行猜测性点击。

建议验收条件

• 白名单账号在白名单微博下的新提及或评论能够启动或恢复正确的隔离 thread，并生成草稿。
• 被拒绝作者或未配置微博不会转交给 Agent。
• 首次启动默认不处理历史互动。
• 轮询重叠和重启不会重复处理同一事件。
• 发布草稿会分别保留操作、目标、正文、提及、话题、可见性和媒体顺序。
• 未经独立发布审批，不会发送公开微博、转发、评论或私信。
• approvalMode: "yolo" 或其他无人值守 Agent 模式不能绕过发布审批。
• 修改任何已审批的账号、操作、目标、文本、元数据、可见性、媒体或媒体顺序都会使审批失效。
• 结果不明确的失败和重试不会产生重复外部操作。
• API 能力缺失、限流、登录变化、验证码和风控挑战会安全暂停，并显示可操作状态。
• Adapter 永远不会 fallback 到其他目标，也不会尝试绕过平台保护。

后续范围

主动新发微博、自动转发、定时发布、数据分析、内容管理、热点发现、全量 feed 收集、多账号管理、批量互动、browser-backed 操作和更多授权流程应分别跟踪。抓取完整 feed 和绕过反自动化明确不属于本 Channel 的目标。

未发现单独的微博 Channel 实现 Issue。更广泛的平台路线见 #8280。

No implementation files or tests are named in the issue. Start with the broader platform roadmap in #8280 and locate the existing channel entry points before checking official Weibo API capabilities. Done means inbound allowlisted interactions produce isolated drafts, while publication requires independent approval and duplicate or unsafe actions fail closed.