关于 send_message_to_agent 的一点建议

[Tyyabb]

Pre-checks

• I have searched existing issues and this is not a duplicate.

What problem does this solve?

当智能体A send_message_to_agent 智能体B去做某件事时，智能体B会把事情做了再回复A，若智能体B所做的事比较复杂时，等待时间太长了，常常导致超时 异常中断。能不能让B收到消息后先回复,表示知晓任务，等完成后再回复智能体A？或者有人提供更好的方法吗？确保智能体之间的对话流畅。

Proposed solution

No response

Willing to contribute?

• I'd be interested in working on this.

[39499740]

Great suggestion! After analyzing the current architecture, I think this is not only feasible but the infrastructure is already largely in place. Here is a concrete implementation plan.

Current Problem

For native agents, send_message_to_agent is synchronous and blocking: Agent A calls the tool, which invokes Agent B's LLM inline (with up to 50 tool-call rounds), and waits for the full response before returning. The default LLM timeout is only 120 seconds with 3 retries, so complex tasks easily time out.

Proposed Solution: Differentiate by msg_type

The tool already defines three msg_type values (notify, consult, task_delegate) but the actual code does not differentiate — all types go through the same synchronous path. We can leverage this existing enum:

1. notify → Fire-and-forget (async, no reply expected)

Agent A sends a message and immediately gets back a confirmation. Agent B is woken asynchronously via the existing Trigger mechanism.

Flow:

A → send_message_to_agent(B, "...", msg_type="notify")
  → Save message to shared ChatSession
  → Create an on_message trigger on Agent B (from_agent_name=A)
  → Return immediately: "✅ Notification sent to B"

Agent B wakes up via the trigger daemon, reads the message from the session history, and acts on it. No reply back to A is expected.

2. task_delegate → Async with callback (B replies when done)

This is exactly the pattern you described: B acknowledges receipt and replies later when finished.

Flow:

A → send_message_to_agent(B, "Please prepare the Q3 report", msg_type="task_delegate")
  → Save message to shared ChatSession
  → Write focus item: - [ ] wait_b_report: Waiting for B to complete Q3 report
  → Create on_message trigger on A: from_agent_name=B
  → Wake B asynchronously (via trigger or direct LLM call in background)
  → Return immediately: "✅ Task delegated to B, you will be notified when complete"

B completes the task:
  B → send_message_to_agent(A, "Q3 report is done...", msg_type="notify")
  → A's on_message trigger fires
  → A wakes up, sees focus item + B's message
  → A processes result and notifies the user

3. consult → Synchronous (current behavior, unchanged)

Keep the existing request-response pattern for quick questions where a real-time reply is needed.

Why This Works — Existing Infrastructure

The architecture already has the key building blocks:

1. Focus mechanism (focus.md): Agent A writes a pending focus item tracking the delegated task. When A is woken later, it reads focus.md in its system prompt and knows what it was waiting for.

2. Trigger system (on_message type): The trigger daemon already evaluates on_message triggers every 15 seconds, checking for new messages from specific agents or users. It can wake Agent A when B replies.

3. Native agents can initiate A2A: When an agent is woken by a trigger, it has the full tool set available (including send_message_to_agent), so B can proactively message A back after completing its task — exactly like real-world delegation.

4. OpenClaw async pattern: The async queue-based pattern for OpenClaw agents (GatewayMessage + poll/report) already proves the architecture supports non-blocking A2A.

5. Chain depth protection: MAX_AGENT_CHAIN_DEPTH = 5 already prevents infinite A→B→A→B loops.

Implementation Scope

The main change is in _send_message_to_agent() to branch by msg_type:

• notify: Save message → create trigger on target → return immediately
• task_delegate: Save message → write focus → create on_message trigger → wake target async → return immediately
• consult: Keep current synchronous behavior

This is a moderate-scope change concentrated in one function, with the rest of the infrastructure already in place.

Phased Rollout Suggestion

1. Phase 1: Make notify truly fire-and-forget (simplest, solves many timeout issues)
2. Phase 2: Implement task_delegate with async callback via focus + triggers
3. Phase 3: Optional UX enhancements (progress indicators in the UI, task status tracking)

Would love to hear thoughts on this approach. The key insight from your suggestion — letting B reply asynchronously — aligns perfectly with how the Focus + Trigger system already manages context across agent wake-ups.

[39499740]

@wisdomqin