Skip to content

WeCom remote: connecting WorkBuddy to a WeCom bot ​

💡 One-sentence summary: use WorkBuddy to enable remote task dispatch via WeCom — create a WeCom smart bot, bind it with a long connection, and remotely control your computer from WeCom chats.

You're at a client site, and a colleague @mentions you in a WeCom group: "Send me last month's quotation." In the past you could only reply "wait until I'm back at my desk" — but after setting up WorkBuddy WeCom remote (officially called "WeCom Assistant"), you can simply @mention the bot in WeCom and say a word, and it will find the file on your computer.

This lesson breaks the official "WeCom Assistant integration guide" into 5 steps: first create an API-mode smart bot in WeCom, bind it to WorkBuddy with a WebSocket long connection, then dispatch tasks in a WeCom private chat or group chat — your computer executes them automatically and the results are synced back to the WeCom chat window.

This is lesson 1 of route three in "Scenario practice," based on WorkBuddy v5.9.3 (the minimum requirement for WeCom Assistant is 4.6.4), with content drawn from the official "WeCom Assistant integration guide" and the assistant, scheduled task feature documentation and FAQ.

What you'll be able to do after this lesson ​

  • Create an API-mode smart bot in WeCom and bind it to WorkBuddy via a WebSocket long connection (Bot ID + Secret, or quick binding by QR code)
  • @mention the bot in a WeCom private chat or group chat to dispatch remote tasks: find files, organize materials, generate documents — your computer executes them automatically and the results are synced back to the WeCom chat window
  • Back at your computer, view the full execution record of remote tasks (thinking process, operation steps, generated files, final results) and continue with follow-up questions; remotely approve high-risk operations such as command execution and file modifications
  • When the bot goes offline, troubleshoot per the official checklist: WorkBuddy running status, integration mode on both sides, credentials, network; if there's no response, switch models first and then test again

Why use WorkBuddy instead of web-based AI? ​

CapabilityWeb-based AI / ordinary WeCom botWorkBuddy WeCom Assistant
Touch files on your computer❌ No access to your files in a chat box; everything relies on copy-paste✅ Executes with your local project files, Shell environment, credential permissions, plugins, and tools
Work in WeCom groups❌ Can only respond and mass-send; can't connect to your computer✅ @mention the bot in a group chat to assign team tasks, with results automatically returned to the group chat
High-risk operations under control❌ No execution capability, so nothing to confirm✅ Command execution and file modifications are confirmed with you in WeCom first, and only run after approval
You're away from the computer❌ Even with the web page open, no one does the work for you✅ Send instructions from WeCom, and WorkBuddy on your computer executes automatically
Scheduled task results delivered❌ No one sees them when they run✅ Scheduled task results can be pushed to WeCom (long connection mode only)

Your current predicament ​

  • You're often out and about — in meeting rooms, commuting, at client sites; when a colleague asks for data in a WeCom group, all you can reply is "wait until I'm back at my desk"
  • The work itself isn't hard: find a file, run a summary — but without a computer at hand you just can't do it; remote desktop is laggy and the screen is tiny, so you don't dare do real work on it
  • Team work is scattered across WeCom groups: assigning, following up, and delivering all rely on manually @mentioning back and forth, and nobody knows the progress
  • You've thought about WeCom bots, but ordinary bots can only respond and can't connect to the files and tools on your computer

When to use this technique ​

When you need to:

  • Have your work computer do the work for you while you're away: find files, organize materials, generate documents
  • Assign team tasks directly in a WeCom group, with results returned to the group where everyone involved can see them
  • Follow up on remote task progress anytime, and remotely approve operations that need confirmation

And you don't want to:

  • Open a remote desktop on your phone and tap around on a small screen
  • Make colleagues wait for a file with a "wait until I'm back at my desk"
  • Upload company files to a third-party web-based AI chat box

🎒 Preparation before starting ​

  • Have read the 5.1 assistant overview: six remote channels and security boundaries — this lesson uses its unified configuration entry directly, without repeating the channel overview and security boundaries
  • WorkBuddy on your computer is logged in, version ≥ 4.6.4 (the minimum requirement for WeCom Assistant; the latest version at the time of writing is 5.9.3)
  • Have a WeCom account that can create smart bots — admins use the admin backend, regular members use the client; if you don't have WeCom yet, the official free registration entry is available
  • Both your computer and phone can access the internet normally; during setup, keep the computer on and running WorkBuddy
  • 20 minutes and a cup of water ☕ — ideally follow along and set it up on your work computer, then send a message right after to verify

Follow along with me ​

Step 1: Create a Smart Bot in WeCom (API mode) ​

Why: WorkBuddy cannot appear in WeCom out of thin air—you must first create a "Smart Bot" on the WeCom side and obtain its credentials before binding. Choose one of the two entry points depending on your account role.

Option A: Administrator path (create in the WeCom admin console)

  1. Open the WeCom admin console in a browser and log in with an administrator account
  2. Click "Security & Management" → "Management Tools" → "Smart Bots" → "Create Bot" in order

Option B: Regular member path (create in the WeCom client)

  1. Open the WeCom client, go to "Workbench" → "Smart Bots app" → "Create Bot"

The two paths converge here:

  1. If you first land on the AI auto-generation page, click "Create Manually" in the lower-left corner, then select "Create in API mode"
  2. Fill in two common configuration items:
Configuration itemDescription
Bot nameIt is recommended to use an easily recognizable name, such as "WorkBuddy Assistant"
Visible range (administrator) / Members who can use it (member side)Choose which employees, departments, or tags can use this bot
  1. On the administrator path, click "Add" after "Visible range" to select members; on the member path, click "Edit" after "Members who can use it" to select members
  2. After finishing the configuration, first click "Save" at the bottom of the page, then select "Use long connection" in the "API Configuration" area

You should see: the bot has been created, and "Use long connection" is shown as selected in the "API Configuration" area.

Step 2: Copy the Bot ID and Secret ​

Why: In long-connection mode, these two credentials are how the parties recognize each other—WeCom identifies the bot by its Bot ID, and WorkBuddy connects to it using this pair of credentials.

In the "API Configuration" area (with "Use long connection" selected): copy the Bot ID; click "Click to Get" to obtain the Secret and store it safely.

💡 Why long connection is recommended

Official explanation: In long-connection mode, you no longer need to fill in a URL, Token, or Encoding-AESKey; configuration is simpler, and there is no need to fill back a Webhook URL. There is also a hard reason—scheduled task push only supports long connection; in URL callback mode, turning on the push switch will prompt you to unbind and reconnect (see the advanced tips in this lesson).

You should see: both credentials have been copied and saved, with the Secret kept somewhere safe (do not paste it into a group chat).

Step 3: Register and bind the WeCom assistant in WorkBuddy ​

Why: The credentials exist only on the WeCom side; you also need to "register" once in WorkBuddy—only after this two-way handshake is the binding complete.

  1. Open WorkBuddy and click "Settings - Assistant Settings" in the avatar menu at the lower-left corner
  2. Find "WeCom Assistant Integration" in the "Integrations (BETA)" area and click "Configure"
  3. In the popup, select "WebSocket long connection"; choose either of the two binding methods:
    • Manual entry: Enter the Bot ID and Secret into the input fields
    • Quick binding: Click "Quick Binding" to connect, and scan the QR code in WeCom to complete the binding
  4. Click "Register" to complete the binding
WeCom deployed on-premises? One more address to fill in

If your company uses an on-premises deployment of WeCom, in addition to the Bot ID and Secret, you must also enter the dedicated WebSocket address into the "Custom WebSocket Address" input field:

  • The address is obtained from the WeCom admin console, in a format like ws://<网关>:<端口>/im_openws?bizid=1
  • The protocol must be ws:// or wss://—entering other protocols such as http:// will be blocked with a prompt
  • When left empty, it automatically falls back to the default public cloud address, which does not affect regular (non-on-premises) deployments
  • This input field only appears in WebSocket long-connection mode; URL callback mode is not involved

After saving the configuration, restarting WorkBuddy will reconnect automatically; if the address is unreachable, the interface will show a clear connection error state, making it easier to troubleshoot network or address configuration issues.

You should see: Registration succeeded, and the WeCom assistant integration shows as bound.

Step 4: Send the bot a "Hello" ​

Why: A successful binding does not mean the channel is usable—first verify the entire chain with a zero-cost message.

In the WeCom contacts, find the newly created bot under the "Created by the Enterprise" group, click "Send Message", and send a simple message (for example, "Hello").

You should see: WorkBuddy receives the message and returns a reply in WeCom—if the bot replies normally, it means WorkBuddy has been successfully connected to WeCom.

Step 5: Dispatch your first remote task in WeCom ​

Why: Once the chain has been verified, you can start running real tasks. The division of labor is clear: WeCom sends the instructions, and your computer executes them.

Send a task instruction directly to the bot in a WeCom chat, for example:

text
Help me find the latest quotation in the D:/Work/Quotations directory on my computer,
read out the customer name, total amount, and validity period, and reply to me directly.

You should see:

  • WorkBuddy executes on your computer, with the process and results synced back to the WeCom chat window
  • Back at your computer, you can view the full execution process and results in this task; on the assistant page you can view the complete execution record of remote tasks: thinking process, operation steps, generated files, and final results
  • You can continue to follow up and refine the task on your computer, and you can also check the progress in WeCom at any time

💡 This is the unique value of WorkBuddy

The WorkBuddy on your computer executes tasks using your local project files, Shell environment, credential permissions, plugins, and tools—in the official words: whatever you can do on your computer can also be done remotely via WeCom. Web-based AI can only "chat"; here it actually executes.

For remote tasks versus the regular tasks you normally run on your computer, the official documentation gives three points of comparison:

Comparison itemRegular taskAssistant (remote task)
Working directoryFreely specifiedFixed to the assistant's dedicated folder
New conversationSupports multiple parallel tasksOnly one session, with all remote instructions handled centrally
Context managementHistory can be cleared to start overKeeps the full conversation history, which cannot be cleared

Official recommendation: prefer regular tasks in the main interface for local operations; use the assistant only when you need remote triggering or a unified view of records.

📋 Magic Prompt ​

Copy the following instruction into the WeCom chat box and send it to the bot; replace the content in 【】 with your actual situation.

📝 Check files remotely during your commute ​

Expected effect: while you are out, have your computer dig through files and report key information for you—no need to open a remote desktop.

text
## Role
You are my office assistant and can operate the files on my computer.

## Task
Find the latest file related to 【file keyword】 in 【directory path】, read it, and reply to me with the key information.

## Input information
### Required fields
- Directory path: 【e.g., D:/Work/Quotations】
- File keyword: 【e.g., quotation, or customer/project name】

### Optional fields
- Time range: 【e.g., only files modified this week?】
- Fields to extract: 【e.g., customer name, total amount, validity period?】

## Output specification
- Reply directly in the WeCom chat: file name + modification time + key information

## Constraints
- ✅ Read only—do not modify, move, or delete any files
- ✅ If you can't find it, honestly state where you looked and why it wasn't found
- ❌ Do not fabricate file contents
- ❌ Do not perform deletion-type operations

📝 Group Chat Team Tasks ​

Expected result: @mention the bot in a WeCom group to assign team tasks, and the results go straight back to the group where everyone involved can see them.

text
## Role
You are our team's office assistant, handling collaboration tasks assigned to you via @mentions in the group.

## Task
Summarize the [Material Sources] into the [Deliverable], and reply with the result to the group once done.

## Input information
### Required fields
- Material sources: [e.g., this week's reports from each group under the D:/周报/ directory on my computer]
- Deliverable: [e.g., a team weekly report with three sections: progress, risks, and next week's plan]

### Optional fields
- Output format: [e.g., save as a Word document and place it in D:/Weekly Reports/Summary/?]
- Notify: [@whom?]

## Output specification
- Send the summary result back to the WeCom group chat; if files were generated, report the file paths

## Constraints
- ✅ All content comes from the provided materials, with nothing added or embellished
- ✅ List uncertain information separately under "To be confirmed"
- ❌ Do not make up items not present in the materials
- ❌ Do not modify the original material files

📝 Progress Tracking and Result Acceptance ​

Expected result: after a task is assigned, follow up at any time—don't let remote tasks become "fire and forget."

text
## Task
Follow up on the task just assigned:
1. Report the current step of progress
2. If completed, provide the result and the location of the output
3. If stuck on an operation that needs confirmation, explain clearly what you need my approval for

## Constraints
- ✅ Report honestly—if it's in progress, say it's in progress
- ❌ Do not claim unfinished work as completed just to close things out

💡 Everyday chat can be more casual

The magic Prompt is a complete structure; for important tasks, it's recommended to write it out in full (what to do + what's available + how it should be, see 3.1 the requirements methodology). The WeCom assistant uses a single session with complete history retained, so for daily follow-ups one or two sentences are fine—"Is that task from earlier done yet?"

Checkpoint ✅ ​

  • The bot can be found in the "Created by the enterprise" group of the WeCom contacts, and sending "你好" gets a reply
  • WorkBuddy version ≥ 4.6.4, and the WeCom assistant integration in "Assistant Settings" shows as bound
  • The binding uses a WebSocket long connection—later, if you want to push scheduled task results to WeCom, only it is supported
  • I understand that WeCom is only responsible for sending instructions and approving operations; the real work happens on my computer: it must stay powered on and running WorkBuddy
  • I understand that remote tasks are fixed in the assistant's dedicated folder, handled centrally in a single session, and the history cannot be cleared
  • I've tried assigning remote work once and saw the complete execution record on my computer

Pitfall Reminders ​

❌ The bot doesn't reply ​

Symptom: WorkBuddy shows as registered or configuration is complete, but the bot doesn't reply to messages in WeCom, disconnects occasionally, or loses connection when reopened after working the first time.

Cause: The official FAQ lists "integration completed but no response after sending messages" as a common issue across QQ, WeCom, WeChat, Feishu, and DingTalk—connection drops, model anomalies, or credential mismatches are all possible.

Correct approach (following the official troubleshooting order): confirm that WorkBuddy is running and the assistant service is enabled; verify that WeCom and WorkBuddy use the same integration method; for long connections, check the Bot ID and Secret; for URL callbacks, check the Token and Encoding-AESKey; confirm the computer's network is working. The official FAQ also offers one tip: switch models first and test again—some no-response issues can be alleviated by switching models.

❌ Long connection registration fails ​

Symptom: clicking "Register" in WorkBuddy gives an error and the binding fails.

Correct approach (official checklist): confirm that "Use long connection" is selected on the WeCom side; re-copy the Bot ID and Secret to avoid extra spaces; if the Secret has expired, retrieve a new one from the WeCom admin console and register again; for private deployments, check the custom WebSocket address protocol (ws:// or wss://), gateway, and port, and confirm the address is accessible from the current computer.

❌ URL verification fails (URL callback mode) ​

Symptom: after pasting the Webhook URL back into WeCom, verification doesn't pass.

Correct approach (official checklist): make sure WorkBuddy is running; check whether the assistant service has started normally; re-copy the Webhook URL to ensure no characters are missing or extra; confirm the Token and Encoding-AESKey exactly match what's configured in WorkBuddy.

❌ Prompt saying "Webhook domain owner verification failed" ​

Symptom: when configuring the Webhook address on the WeCom side, a prompt appears saying domain owner verification failed.

Cause: the WeCom side performs domain owner verification on Webhook addresses.

Correct approach: officially, it's recommended to first check whether the Webhook address is complete and consistent with the current configuration requirements; if it still fails, keep a screenshot of the error and submit it for troubleshooting.

❌ As soon as the computer shuts down, the bot goes "offline" ​

Symptom: after shutting down the computer after work, the bot doesn't reply to messages in WeCom; the next day after booting up it works again.

Cause: the bot isn't broken—WeCom is only responsible for sending instructions, approving operations, and follow-up messages; the entire environment that executes tasks (files, Shell, credentials, plugins, tools) is on your computer, and if the computer isn't online, no one is doing the work.

Correct approach: during periods when remote work is needed, keep the computer powered on and running WorkBuddy (this is a prerequisite listed officially). For how to handle the lock-screen scenario, see the next lesson C2 Mobile Remote Control.

Advanced Tips (Optional) ​

🔧 URL callback integration (alternative option). Long connection is the recommended path; if you're already using Webhook configuration, or need URL callbacks due to network or deployment constraints, follow the official alternative procedure:

  1. In the WeCom "API Configuration" area select "Use URL callback," click "Randomly get" on the right side of the Token and Encoding-AESKey input boxes, and save these two parameters—the official docs stress: if lost, registration cannot be completed
  2. WorkBuddy Go to "Assistant Settings" → "WeCom AIBot Integration" → "Configure," switch the registration dialog to "Use URL callback," enter the Token and Encoding-AESKey, and click "Register"
  3. Copy the Webhook URL generated after successful registration, go back to the WeCom bot creation page, paste it into the URL input box, and click "Save"

⚠️ URL callbacks cannot receive scheduled task pushes

Scheduled task pushes only support WebSocket long connections. If the assistant is currently connected via URL callback, turning on the push switch will prompt "URL callback connections do not currently support message pushes; you need to unbind and reconnect"; after reconnecting, the ability to receive messages previously handled via URL callback will also switch to the long connection method.

🔧 Push scheduled task results to WeCom. Once the bot is bound, local scheduled tasks (for example, a weekly report every Friday at 17:00) can push their results to WeCom. See 3.3 Scheduled Tasks and C4 Daily News Brief. Official note: push failures do not affect the execution of the task itself.

🔧 Create a dedicated task group. The official capability list includes "create a dedicated task group, long-term bound to WorkBuddy for handling routine team work": add the bot to a project group, @mention the bot to assign tasks and track progress, and when a task is completed, automatically notify the relevant people in the group—assigning, acceptance, and record-keeping all happen in the same group.

Lesson Summary ​

✅ WorkBuddy WeCom remote in five steps: create a bot (API mode) → get Bot ID + Secret → register and bind in WorkBuddy → send "你好" to verify → assign the first remote task.

✅ Long connection first: no need to paste back a Webhook URL, three fewer parameters to fill in; scheduled task pushes also only support it.

✅ WeCom is the remote control, the computer is the host: WeCom only sends instructions and approves operations; files, Shell, credentials, plugins, and tools are all on your computer—keep it powered on and running WorkBuddy.

✅ Three characteristics of remote tasks: fixed assistant dedicated folder, centralized handling in a single session, and history that cannot be cleared; prefer regular tasks for local work.

✅ High-risk operations require confirmation: command execution, file modifications, and the like are executed only after being approved in WeCom.

Key configuration recap:

Configuration itemValue in this lessonDescription
WorkBuddy version≥ 4.6.4Minimum requirement for the WeCom assistant
Bot creationManual creation · API modeAdmins go through the admin console, members through the client
Connection methodWebSocket persistent connection (recommended)Bot ID + Secret, or quick binding via QR code scan
Private WeCom addressws://<网关>:<端口>/im_openws?bizid=1Protocol must be ws:// or wss://
Bot entry pointWeCom contacts → "Created by the enterprise"Tap "Send message" to assign a task

Next lesson preview ​

WeCom solved "assigning tasks within a chat tool"; the next lesson solves "remote control from your phone". In the next lesson you will learn C2 Remote control from your phone: get your work computer working during your commute.

You will learn:

  • How to configure the "Connect mobile" switch and "Allow running while locked"
  • Official scenarios and prompts for remotely finding files and troubleshooting errors during your commute
  • Resuming chats remotely, automatic return of output, and the rule that resuming a chat does not consume extra credits

Related tutorials ​