Wiring Dify into WeCom Customer Service: install a Runner plugin, let an Agent own message.received

Description and use

Automated message exchange between WeCom Customer Service and Dify using the Dify Agent Runner plugin, eliminating manual copy‑paste.

Problem

The WeCom customer‑service side only answers customers; every question is retyped into Dify’s chat box and the answer copied back, so the two systems are not connected.

Outcome

The WeCom Customer Service bot now automatically forwards incoming messages to Dify and returns Dify’s responses, eliminating manual re‑typing.

Workflow

• Create a local LangBot instance (docker network, core and runtime containers).
• Create a WeCom Customer Service bot in LangBot with required credentials.
• Install the Dify Agent runner plugin from the marketplace.
• Create an Agent processor, selecting the Dify Agent runner.
• Configure the runner with Dify base URL, API key, timeout, expiry and identity.
• Bind the event route: set the message.received event to use the new Agent processor.
• Verify the route with the route‑check reply.
• Run an event‑debug test by sending a sample question.
• Check Dify endpoint logs to confirm the request was received.

Evidence

The knowledge base, prompts and tools live in a Dify application; the WeCom customer-service side only answers customers.

Source

On 4.10 the only route was a pipeline: Dify as a provider (Dify service API), wired into one pipeline.

Source

4.11 makes a processor an Agent, whose Runner comes from a plugin.

Source

Runners are marketplace plugins. Dify is the official langbot-team/DifyAgent plugin, runner id plugin:langbot-team/DifyAgent/default.

Source

Connection details live in the processor's runner config. Choose Agent mode, pick Dify Agent, then fill Dify-side values; DOM readings here (measured 2026-10-16): 基础 URL (http://dify:5001/v1), API 密钥, 超时 (30), 过期 (3600), 身份 (发送者).

Source

Event routing maps events to processors; the first match wins. Matching picks by priority from high to low, then list order, and runs exactly one response target.

Source

Run one event-debug pass: Agent detail → event debug → run test with 「请问你们支持私有化部署吗？」.

Source

One measured request line, verbatim: [2026-10-16T16:28:29] POST /v1/chat-messages auth=Bearer app-dem... body={"inputs":{},"query":"…"}

Source