entropy-box – skill Khác cho agent AI

Entropy Box

Entropy Box is an agent-native knowledge compiler and capability substrate for

embodied-AI development. It compiles fragmented papers, repositories, ROS packages,

models, datasets, simulators, benchmarks, standards, and engineering documentation

into a persistent, typed, deduplicated, machine-consumable knowledge artifact.

Its public Panorama Graph is not merely a search index or visualization. It represents

the field through domains, vertical topics, task chains, normalized capabilities,

implementation assets, dependency relations, and evidence. Use it to understand where

a technical problem sits in the whole embodied-AI system and how knowledge can be

composed into an engineering path.

Solution Consult is the primary runtime capability. The calling agent remains

responsible for clarifying the request, decomposing broad goals into bounded technical

questions, deciding which questions need separate consultations, and synthesizing the

results. Do not send an underspecified ambition such as "build a general robot" as one

query and treat the returned text as a complete solution.

The imported September 2026 snapshot reports more than 52,177 entity nodes, 7,913 task chains,

66,714 dependency edges, 37,757 atomic capabilities or associated assets, and 2,511

vertical topic libraries. These counts evolve; verify the live site before quoting

them.

When to Use

• Use when you need a grounded, source-linked implementation path for an embodied-AI task (manipulation, navigation, perception, control, planning, simulation, and related systems).
• Use when selecting or comparing methods, capabilities, assets, dependencies, or evidence for a bounded technical requirement.
• Use when mapping a problem to the embodied-AI field, tracing task chains, or assembling a development workflow from retrieved structure.
• Do not use it to directly control physical robots, or for unrelated scientific domains or generic software development.

What this skill enables

Choose and sequence modes according to the user's task:

1. Solution consultation — ask how a bounded technical requirement can be

implemented, which approaches can satisfy it, and which capabilities, dependencies,

assets, constraints, and gaps belong in the candidate solution.

2. Targeted knowledge search — run RAG retrieval for a concrete question or build a

fuller understanding of a technology selected during consultation.

3. Entity anchoring — resolve a known ID, name, or alias to a structured topic,

capability, or asset record.

4. Evidence verification — retrieve source-linked comparisons, limitations,

engineering notes, negative results, and benchmark context.

5. Panorama navigation — place a question within the embodied-AI field, find

adjacent domains and topics, and explain the wider technical context.

6. Topic research — inspect a vertical topic as a structured unit rather than a

bag of documents.

7. Task-chain analysis — decompose a goal into ordered, branching, or merging

engineering steps.

8. Capability and dependency analysis — identify what a system must be able to do,

what each capability requires, and which capabilities are reusable across topics.

9. Asset discovery and selection — connect capabilities to repositories, packages,

models, datasets, simulators, sensors, benchmarks, and other implementation assets.

10. Grounded workflow assembly — compose task chains, capabilities, assets, evidence,

constraints, and gaps into a candidate development workflow.

11. Knowledge-compiler analysis — study how fragmented technical knowledge is

normalized, admitted, related, updated, and made available to agents.

The scope is broad inside embodied AI and bounded outside it. Do not trigger this skill

for unrelated scientific domains or generic software development merely because a task

mentions AI.

Panorama structure

The public taxonomy spans 15 top-level domains:

• Foundation Models
• Human-Robot Interaction
• Learning and Adaptation
• Localization
• Manipulation
• Mapping and SLAM
• Motion and Control
• Multi-Robot Systems
• Navigation
• Perception
• Planning and Decision
• Reasoning and Agents
• Safety and Trust
• Simulation and Digital Twins
• System Infrastructure

Do not treat these domains as isolated folders. Many real systems cross several of

them. A mobile manipulator, for example, may require perception, localization,

navigation, planning, manipulation, motion control, safety, simulation, and system

infrastructure.

Read [references/panorama.md](references/panorama.md) when mapping a field, traversing

graph layers, or producing a capability landscape.

Route each question correctly

| User need | Route |

| --- | --- |

| Task-level "how": accomplish an embodied-AI task with given robots/sensors | Consult |

| A concrete technical question or a deep study of a selected method | Search |

| A known CAP_..., AST_..., topic ID, name, or alias | Lookup |

| Why one method was chosen, known defects, comparisons, or benchmarks | Evidence |

| A broad field map or adjacent technical context | Panorama Graph and Topics |

Consult is the primary route for solution-seeking requests. Search is supporting RAG,

not a substitute for solution assembly. Lookup is an exact anchor rather than a full

technical study: it can accept names and aliases such as YOLOv7, not only IDs. After

Consult produces a technical selection, use Search to understand that selection more

fully before presenting it as a recommendation.

A Consult question must be task-level. Entropy Box organizes knowledge as task

chains; Consult answers "how do I accomplish a given task with a given kind of robot or

sensor" — for example "how should a robot arm with vision pick peaches?" or "how should

a biped robot go downstairs?" Such questions can be assembled into ordered, branching,

merging task chains. Generic algorithm-tradeoff questions are out of Consult scope —

for example "should I use impedance or admittance control?" is an algorithm-selection

Q&A detached from a concrete task and is not a question the task-chain model is built to

answer as its primary route; if algorithm facts or source-backed comparisons are needed,

use Search / Evidence, but do not feed such a question to Consult as a solution request.

Lookup is an exact anchor. When it returns "no matching candidate entity", do not

conclude the concept is absent from the graph — confirm with Search first. Chinese

concept phrases should prefer Search (Lookup's exact match is not guaranteed for Chinese

natural phrases); prefer Lookup only for IDs and exact English/technical aliases.

Core workflow

Privacy and data handling. Entropy Box is a third-party public service. Before sending any project context (robot configuration, environment, interfaces, datasets, or safety constraints) to /api/consult, /api/search, /api/lookup, or /api/evidence/search, strip credentials, secrets, and personal or proprietary details, and confirm with the user that the remaining context is safe to transmit. Do not send confidential material without explicit approval.

1. Clarify a bounded technical need

Determine whether the user is asking for:

• a field map;
• a topic explanation;
• a technical solution space;
• a system architecture;
• an asset shortlist;
• a capability or dependency trace;
• a source-backed comparison;
• a complete development workflow;
• an explanation of the knowledge compiler itself; or
• an integration with another agent.

Preserve the task, environment, robot or simulator, sensors, actuators, compute budget,

interfaces, real-time constraints, available data, safety boundary, and success

criteria. When missing information would materially change the solution, ask the user

focused follow-up questions. Prefer several concrete questions over one grand query.

Do not keep questioning once the remaining uncertainty can be stated as an assumption.

2. Decompose before calling Entropy Box

The calling agent, not the retrieval service, owns top-level decomposition. Split a

multi-system request into bounded technical questions whose inputs, outputs, operating

conditions, and success criteria are understandable. Separate perception, estimation,

planning, control, safety, simulation, and infrastructure questions when they require

different implementation decisions.

Do not fragment a simple request unnecessarily. Decompose until each question can be

answered as a concrete implementation need, not until every task step becomes a

separate query.

3. Consult each implementation question

Use Consult for task-level questions of the form "how can this task be implemented?" or

"which methods can satisfy these constraints?" Frame the Consult question as a task, for

example "how should a robot arm with vision pick peaches?" or "how should a biped robot

go downstairs?" — not as a task-detached algorithm-selection question. Make m

… (nội dung đầy đủ có trong gói tải về)