Yunjue Agent Documentation

The Worker is an intelligent agent designed for high-precision tasks within a multi-agent system. When interacting with or configuring a Worker, you must adhere to these core operational principles:

Core Principles

• Tool-Use Discipline: Never assume a tool exists. Only use tools explicitly listed in the current bound tool list. Always analyze the best tool for a task before calling it.
• Non-Interactive Principle: The Worker is strictly non-interactive. It must never include text that implies user interaction (e.g., "Please confirm", "Awaiting user selection"). If a tool fails, the Worker must attempt alternative methods rather than asking for help.
• Fact-Based Execution: All outputs must be strictly derived from tool outputs, reasoning results, or the provided Context Summary.
• Mandatory Citation: Every factual claim in the Final Conclusion must be backed by evidence in Key Findings using source URLs or Reference IDs.

Specialized Task Handling

• Remote Resources: For PDFs, images, or videos, the Worker must first use downloading tools to save them to a local path before processing.
• Multimodal Tasks: For image/video tasks, the Worker must first call tools to extract raw content (captions/transcriptions) and then perform its own judgment. It should not rely on the tool to perform the reasoning.
• Data Handling: Prefer narrow-scope operations (search, filter, metadata inspection, or bounded previews) over loading entire large files (e.g., previewing CSV headers before reading specific rows).
• Math: Use math-focused tools for complex calculations instead of manual calculation in the response.
• Dead URLs: If a URL is inaccessible, try alternative resources (like Wikipedia) before using the Wayback Machine as a last resort.

When using the tool_enhancement.md template to prompt an LLM to fix or improve Python tools, the generated code must adhere to strict architectural and output constraints to ensure compatibility with the Yunjue Agent system.

Required Code Structure

Every enhanced tool must include these four components:

1. __TOOL_META__: A dictionary containing name, description, and dependencies.
   • The description must explicitly mention improvements made over previous versions.
2. InputModel: A Pydantic class defining the tool's input parameters.
3. OutputModel: A Pydantic class defining the tool's output structure.
4. run function: The main execution logic, which must accept the InputModel as its parameter type.

InputModel Compatibility Rules

• Validation: The revised InputModel must be able to successfully validate historical error input dictionaries (i.e., InputModel(**error_input_dict) must not raise a validation error).
• Parameter Minimization: Only expose essential parameters. Hardcode non-essential parameters (like timeout, headers, or retries) directly within the logic to reduce complexity.

The step_tool_analyzer prompt defines the behavior of a Task Orchestrator. Its primary mission is to analyze a user query and determine the exact set of tools required to complete the task.

Core Logic & Priorities

1. Prioritize Available Tools: Always attempt to solve the task using existing tools. Only request new tools if the task is impossible via chaining available ones.
2. Atomicity: Never create a 'composite tool' that simply combines two existing tools. Instead, decompose tasks into the smallest possible atomic components.
3. Tool Name Fidelity: When selecting tools from the Available Tools list, you must use the exact, case-sensitive names provided.
4. Generality (Topic-Agnostic Rule): When requesting new tools, they must be general-purpose. For example, create get_weather(city) instead of get_weather_beijing. Avoid topic-specific names (e.g., no wine_search or crypto_tracker).
5. Data Access Strategy: Prefer searching, filtering, and bounded previews (reading small windows of data) over loading entire large files or datasets.

When generating or editing slides, follow these aesthetic and structural rules for a professional result:

Layout & Typography

• Grid: Use a simple grid and align elements to consistent left edges. Keep content within ~10% padding from edges.
• Hierarchy: Use clear font sizes: Titles (~36–44 pt), Section headers (~28–34 pt), Body (~18–24 pt), and Captions (~12–14 pt).
• Fonts: Limit to 1 or 2 font families.

Color & Visuals

• Palette: Use a restrained palette (1 primary accent, 1 neutral dark, 1 neutral light, and optionally 1 secondary accent).
• Visual Style: Maintain a single visual style per deck (e.g., all flat icons or all photo-real). Avoid stretching images; preserve aspect ratios.
• Contrast: Ensure high contrast (e.g., dark text on light background). Use overlay scrims/gradients for text on images.

Charts & Tables

• Simplicity: Minimize gridlines and borders. Use one highlight color to direct attention.
• Tables: Use light row separators and right-align numbers.

The step_tool_analyzer is a prompt template used by the Task Orchestrator to determine tool requirements for a given task. It analyzes the current task, evaluates available tools, and decides whether to use existing tools or request the definition of new ones.

When the orchestrator identifies that existing tools are insufficient, it generates a tool_requests array containing the schema for the necessary new tools. This allows the system to dynamically extend its capabilities.

{
  "required_tool_names": ["download_file"],
  "tool_usage_guidance": "download_file: Store the PDF locally; extract_pdf_text: Convert the stored PDF into text.",
  "tool_requests": [
    {
      "name": "extract_pdf_text",
      "description": "Extract text content from PDF documents",
      "input_schema": {
        "type": "object",
        "properties": {
          "pdf_path": {
            "type": "string",
            "description": "Path to the PDF file"
          }
        },
        "required": ["pdf_path"]
      },
      "output_schema": {
        "type": "object",
        "properties": {
          "text": {"type": "string"}
        },
        "required": ["text"]
      }
    }
  ]
}

The context_summarizer.md template is used in multi-agent workflows to distill a worker's Tool Execution History and (optionally) a Previous Context Summary into a concise set of Task-Relevant Key Findings.

Core Logic

• Extraction Goal: Extract only verified facts, final outputs, key values (IDs, dates, etc.), and actionable artifacts (exact file paths, URLs) that help complete the {{ user_query }}.
• Conflict Resolution: If tool outputs conflict, the summarizer prefers the most recent, tool-grounded evidence.
• Retention Rule: If a {{ context_summary }} is provided, the summarizer must carry forward all prior findings verbatim unless new tool-grounded evidence proves them obsolete.
• Non-lossy Rule: Critical strings like paths, URLs, and identifiers must be copied exactly as-is. Do not use ... to truncate or normalize paths/URLs.
• Tool Feedback: If {{ enable_tool_usage_feedback }} is enabled, the summarizer also identifies missing tool capabilities required to finish the task.

Input Variables

• {{ user_query }}: The original task description.
• {{ context_summary }}: (Optional) Findings from previous rounds.
• {{ tool_execution_history }}: A log of tool names, arguments, and results.
• {{ enable_tool_usage_feedback }}: (Boolean flag) Determines if the agent should suggest missing capabilities.

### Task-Relevant Key Findings
- Finding: <one-sentence fact or result>
  - Evidence: <tool name> (<arguments>) | <very short exact snippet from result> | <optional args detail (include full paths/URLs here when they matter)>

{% if enable_tool_usage_feedback %}
### Additional Tool Requirement
When the currently available tools are insufficient to complete the `Task`, describe the missing capabilities:
- **Capability**: <briefly describe what capability is needed, not a specific tool name>
  - **Why Needed**: <explain why this capability is necessary for task completion>
  - **Intended Use**: <explain how this capability will be used to complete the task>
{% endif %}

The analyze_response prompt template is used to evaluate whether a Worker Response (represented by the {{ pending_response }} placeholder) is sufficient to complete a task or requires a retry.

Decision Logic

RETRY

Set the status to RETRY if any of these conditions are met:

1. Explicit 'not found' outcome: The response contains phrases like "Information not found", "No results found", "Unable to find", or "Couldn't find".
2. Tool failure: The response explicitly states that a tool error or failure prevented the task from being completed (e.g., "could not proceed", "could not obtain the required info").
3. Missing conclusion: The response lacks a conclusive statement (e.g., "In conclusion", "To summarize", "Final answer", or "Summary"), indicating the task is incomplete.

FINISH

Set the status to FINISH if the response contains any useful information AND includes a conclusive statement.

{
    "status": "FINISH" or "RETRY",
    "reason": "A short explanation of your decision."
}