How Six Agents Tackle Complex Commands and Tool Bloat in AI Data Generation

Introduction

In the "AI data generation" (AI造数) scenario, users issue rich natural‑language queries that must be turned into precise tool calls. The core challenges are extracting exact commands, selecting the right tool from a large pool, and assembling a tool chain to satisfy multi‑step instructions.

Single‑Agent vs Multi‑Agent

Single‑agent mode delegates all work—intent parsing, tool governance, and execution—to one reasoning agent. This works for simple cases but suffers from low accuracy and high latency when queries become complex.

Multi‑agent mode splits responsibilities into four focused agents: intent‑recognition, tool‑engine (filter + parse), reasoning‑execution, and summarizer/interaction. Weak agents are replaced by engineering solutions, improving response time.

Core Issues

Precise extraction of user intent from diverse queries.

Filtering the appropriate tool from a library of thousands.

Constructing a reliable tool chain for multi‑step commands.

Prompt Engineering

The prompt must define the LLM’s workspace ("find and execute tools"), provide necessary context (environment, platform), set strict principles, and include representative examples. Lessons learned:

Do not enforce custom output styles on reasoning agents; it harms model performance.

If principles have little effect, add more examples.

Examples may introduce hidden attributes (e.g., an implicit "environment" field).

Abstracting model, ability, and process improves accuracy (expanded in the 2.0 section).

Tool Governance

Tool descriptions must contain basic info, functional description, output schema, and troubleshooting guidance. Tools are divided into public (stable, strict) and private (flexible) pools. With >7,000 tools, isolation prevents "tool explosion" and conflict cascades.

Intent Recognition

Eight intent types are defined (data creation, data operation, data query, data validation, tool consultation, tool operation, project operation, other). An IntentResult model captures intent type, action, object, environment, and related entities. Example workflow:

# Role:
You are XiaoZhi, an intelligent robot for software R&D.
# Background:
- Data environments: offline, pre‑release.
- Tool platforms: "BlueSea" (standard data creation) and others (varied capabilities).
# Steps:
1. Analyze user input, classify intent into creation/query/operation.
2. Echo intent to user.
3. Execute appropriate tool chain based on intent.
4. Return result.

Concrete examples show how the system asks for missing parameters, selects the correct tool, and handles failures.

Tool Engine

Tools are abstracted into ToolEssentialModel containing function type, environment, domain, dependent and output entities. The engine performs two stages:

Tool parsing agent stores all ToolEssentialModel objects in a cache.

Filtering engine uses the IntentResult to compute similarity scores via text similarity + synonym dictionary and embedding similarity, then selects the top‑few candidates (typically ~5 out of >100).

Images illustrate the reduction from 105 tools to 5 candidates.

Reasoning Execution

The execution agent follows a reverse‑reasoning → forward‑execution workflow:

Traverse the execution_plan generated by intent recognition.

For each step, find the tool that best matches the expected result.

Recursively resolve required input entities by locating upstream tools that can produce them.

Build a tool chain (Tool A → Tool B → … → Tool N).

Execute the chain forward, handling errors and providing compensation.

Reverse reasoning example: to fulfill "grant a coupon", the system first finds the coupon‑creation tool, then discovers it needs a user ID, so it calls the user‑creation tool, and finally executes the coupon tool.

Implementation uses qwen‑max for deep reasoning and qwen‑plus for fast intent and tool parsing.

Results

Filtering reduces candidate tools from >100 to ~5, cutting the LLM’s token load by an order of magnitude and keeping latency stable even as the tool pool grows. Logs show consistent tool‑candidate counts regardless of total tool volume.

Recommendations

Use the single‑agent approach when the tool set is small, the user and tool authors share terminology, and latency is not critical.

Adopt the multi‑agent architecture for open platforms with many contributors, large tool libraries, and complex multi‑step queries, accepting the added operational complexity.

Overall Takeaways

Building AI‑driven products requires rigorous abstraction of user intent, strict tool description standards, and layered agent design to bridge the semantic and functional gaps between users and tool providers. Normalizing queries often yields dramatic improvements when the model still struggles.