Description
OpenAB currently bridges Discord with ACP-compatible coding CLIs, and openab/gateway already supports additional channel adapters (e.g. Feishu). This feature request proposes adding WeCom (企業微信) as a new channel adapter, enabling enterprises that standardize on WeCom for internal communication to run OpenAB agents without forcing users onto Discord.
Use Case
Many enterprises in Greater China standardize on WeCom for internal collaboration and cannot adopt Discord/Slack for compliance, network, or organizational reasons. With a WeCom adapter, these teams could:
- @mention an OpenAB agent in a WeCom group chat or DM and receive a reply
- Maintain per-(corp, chat, sender) conversation sessions
- Deploy a self-hosted gateway inside their compliance boundary
Proposed Solution
Add a new wecom adapter to openab/gateway, mirroring the existing Feishu adapter. Use WeCom 自建應用 (self-built application) + callback mode — not 群機器人 webhook, which is send-only and cannot receive user messages.
Data flow:
WeCom server
→ callback URL (HTTP GET signature verify / POST encrypted XML)
→ gateway adapter (signature verify + AES-256-CBC decrypt + XML parse)
→ normalize to GatewayEvent
→ resolve session
→ OpenAB Core / agent flow
→ cgi-bin/message/send REST API to reply
Session key scheme:
wecom:{corp_id}:{chat_id}:{sender_id}
DMs continue across turns; group chats avoid mixing multiple users into one context.
Implementation should mirror the Feishu adapter for: token cache + auto-refresh (with a mutex to prevent concurrent refresh races), callback signature verification, normalize → GatewayEvent transformation, and the send-message REST client. Avoid prematurely abstracting a generic enterprise-IM framework — get WeCom working first, refactor later.
MVP Scope (v1)
In:
- WeCom 自建應用 mode + callback
- Text message DMs (bidirectional)
- Text messages in group chats, gated by
@bot mention (to avoid flooding)
- AES-256-CBC + SHA1 signature verification
- Access token auto-refresh with concurrency-safe lock
- Single corp + single agent configuration
Out (deferred to v2+):
- Image / file / card / voice messages
- Multi-tenant (multi-corp)
- Multiple agents in one corp
- Contact directory sync
- Third-party ISV applications
- Group "shared thread" semantics
Configuration
Expected environment variables:
WECOM_CORP_ID
WECOM_AGENT_ID
WECOM_SECRET
WECOM_TOKEN # signature verification
WECOM_ENCODING_AES_KEY # AES-256-CBC encrypt/decrypt
WECOM_GROUP_REQUIRE_MENTION=true # group mention gate
WECOM_WEBHOOK_PATH=/webhook/wecom # callback URL path
Secrets must come from environment / Kubernetes secret refs, not be baked into the image.
Risks & Considerations
| Risk |
Impact |
Mitigation |
| AES + XML decryption complexity |
Decryption failure blocks all inbound |
Strict adherence to official spec; unit tests; reference open-source implementations |
| Callback must be publicly reachable |
Self-host users need reverse proxy / IP allowlist |
Provide deployment doc + frp example |
| WeCom API endpoints in mainland China |
Latency / sporadic timeouts from overseas regions |
Real-environment latency test; consider China-region deployment or proxy |
| Token expiry race |
Concurrent refresh conflicts |
Single refresher task / mutex |
| API rate limits |
Send throttling |
Rate limiter |
| Deployment requires WeCom corp admin |
Narrows audience to B2B |
Document prerequisite clearly |
| Callback payload may differ from official docs |
Parsing fails silently |
Verify with a real corp before shipping; do not rely on docs alone |
Acceptance Criteria
- New
wecom adapter in openab/gateway, structurally mirroring the Feishu adapter
- WeCom 自建應用 callback verification (signature + AES decryption) passes against a real WeCom server
- Bidirectional text DM works end-to-end with an OpenAB agent
- Group-chat replies are triggered only when the bot is
@-mentioned (when WECOM_GROUP_REQUIRE_MENTION=true)
- Session continuity within
wecom:{corp_id}:{chat_id}:{sender_id} across turns
- Access token cache with concurrency-safe auto-refresh
- Deployment docs covering: corp_id / agent_id / secret / token / encoding_aes_key / callback URL / IP allowlist
- All secrets sourced from environment variables; nothing baked into the image
Notes
This issue is intentionally scoped as a feature request / RFC, not an implementation task.
Description
OpenAB currently bridges Discord with ACP-compatible coding CLIs, and
openab/gatewayalready supports additional channel adapters (e.g. Feishu). This feature request proposes adding WeCom (企業微信) as a new channel adapter, enabling enterprises that standardize on WeCom for internal communication to run OpenAB agents without forcing users onto Discord.Use Case
Many enterprises in Greater China standardize on WeCom for internal collaboration and cannot adopt Discord/Slack for compliance, network, or organizational reasons. With a WeCom adapter, these teams could:
Proposed Solution
Add a new
wecomadapter toopenab/gateway, mirroring the existing Feishu adapter. Use WeCom 自建應用 (self-built application) + callback mode — not 群機器人 webhook, which is send-only and cannot receive user messages.Data flow:
Session key scheme:
DMs continue across turns; group chats avoid mixing multiple users into one context.
Implementation should mirror the Feishu adapter for: token cache + auto-refresh (with a mutex to prevent concurrent refresh races), callback signature verification, normalize → GatewayEvent transformation, and the send-message REST client. Avoid prematurely abstracting a generic enterprise-IM framework — get WeCom working first, refactor later.
MVP Scope (v1)
In:
@botmention (to avoid flooding)Out (deferred to v2+):
Configuration
Expected environment variables:
Secrets must come from environment / Kubernetes secret refs, not be baked into the image.
Risks & Considerations
Acceptance Criteria
wecomadapter inopenab/gateway, structurally mirroring the Feishu adapter@-mentioned (whenWECOM_GROUP_REQUIRE_MENTION=true)wecom:{corp_id}:{chat_id}:{sender_id}across turnsNotes
This issue is intentionally scoped as a feature request / RFC, not an implementation task.