DOCSEARCHbyAlgolia
Submit Docs

YesImBot AI Agent Runtime

repository·v4·Indexed 41 days ago

https://github.com/yeswearebot/yesimbot

A Koishi-based AI agent runtime and plugin suite for integrating Large Language Models (LLMs) into group chats. It features a 'message-first' architecture, a dedicated agent runtime (@yesimbot/agent-runtime) for managing model turns and tools, and a chat-learning plugin (koishi-plugin-yesimbot-chat-learning) that allows bots to learn communication styles and response patterns from real conversation data.

Tokens
140.5K
Snippets
321
Records
580
Agent score
51%

What's inside YesImBot

  1. Overview of koishi-plugin-yesimbot-command-bridge

    v4
    The koishi-plugin-yesimbot-command-bridge plugin allows the YesImBot main LLM to interact with the Koishi ecosystem by calling Koishi commands via tool calling. The plugin takes full control over the command's input and output, preventing the command's natural output from being sent directly to the chat channel. Instead, the LLM decides whether to paraphrase and relay the command results to the users.

  2. Overview of koishi-plugin-yesimbot-chat-learning

    v4

    The koishi-plugin-yesimbot-chat-learning plugin enables a bot to learn communication styles, response patterns, and topic initiation methods from real group chats. It transforms historical chat data into auditable, correctable, and cross-group aggregatable style priors, which are then injected into the LLM context as bounded prompt blocks.

    Key Features:

    • Channel Isolation: Maintains independent learning states per channel to prevent cross-contamination.
    • Relationship-Based Learning: Uses message relationship graphs (quotes, replies, mentions) rather than simple temporal adjacency to determine conversation flow.
    • Intent Abstraction: Uses models to label role / intent, turning dialogues into intent chains and real samples.
    • Style-Centric: Focuses on describing the style of a conversation chain (e.g., tone, sentence structure) rather than summarizing the content.
    • Bounded Injection: Prompt injection is subject to token budgets, ensuring that while learning data grows, the injected context remains manageable.

  3. Overview of koishi-plugin-yesimbot-global-brain

    v4

    The koishi-plugin-yesimbot-global-brain plugin provides a shared knowledge base (a "Global Brain") that allows the same Bot to share knowledge, questions, and experiences across multiple chat sessions (groups and private chats).

    Unlike standard context merging, it does not combine all chat histories into one context or automatically forward messages. Instead, it acts as a cross-session memory where one session can deposit interesting content, and other sessions can read summaries and decide whether to use or express that content based on the local chat atmosphere.

  4. Customize the Koishi Console home page with koishi-plugin-yesimbot-console

    v4
    The koishi-plugin-yesimbot-console plugin allows you to customize the Koishi Console home page. It works by using ctx.console.addEntry() to register client-side entry points and utilizes the server-side yesimbotPanel DataService to provide status information regarding health, models, configurations, capabilities, and plugin states.

  5. Extend event variants via declaration merge

    v4

    Platform adapters can extend the EventMap by declaration-merging new event variants. When a new variant is merged:

    • The persisted yesimbot.event payloads for that variant must contain the closed host event base fields plus the declaration-merged variant fields.
    • These payloads must not inherit arbitrary Universal.Event resources by default.
    • The system relies on Satori-shaped resources and must not introduce parallel Source, Scope, or Sender models.

  6. How WorldEngine handles chat perception via the 'Phone'

    v4

    To prevent WorldAgent subjects from having omniscient cross-channel context, WorldEngine uses a restricted perception model called the phone.

    • Notifications: When unread messages occur in a channel, WorldEngine submits a minimal notification to the WorldAgent. This notification contains the chat access point identity, unread count, and timestamp, but omits sender, content, and media.
    • Perception Path: The subject only gains access to message content by 'opening' the conversation via phone tools.
    • State Management: Opening the phone or selecting a conversation does not change the 'read' state; only advancing the read cursor through returned records does.

  7. How GlobalAgents and GlobalScope work

    v4

    A GlobalScope is a platform-agnostic identity used to address a GlobalAgent. Unlike channel-based scopes, a GlobalScope MUST NOT contain or imply a platform, Bot, Session, channel, or delivery target. It is identified solely by a type: "global" and a non-empty agentId.

    When a plugin addresses a GlobalScope using a valid agentId, the Core uses that ID as the persistent runtime and storage identity. This allows multiple trusted plugins to resolve and interact with the same running GlobalRuntime without needing exclusive ownership handles.

  8. Use experimental tag mode

    v4

    The tagMode is an experimental feature that adds a tagging system on top of the existing category system. When enabled, sticker_steal will automatically tag stickers during collection.

    New capabilities provided by tagMode:

    • sticker_tags: Query current tags and their counts.
    • sticker_send: Allows passing multiple tags to find and randomly send a sticker that matches the most tags.
    • sticker_search: Supports filtering stickers by tags.

    To enable this mode, update your configuration:

    yesimbot-sticker-manager:
  tagMode: true

    tagMode only adds a tags field and does not modify the existing category field, so existing functionality remains intact.

  9. Manage multiple WillEngine instances

    v4

    You can run multiple instances of yesimbot-will-policy simultaneously (e.g., by cloning the plugin in the Koishi management page). This allows you to apply different behaviors to different channels or platforms.

    Execution Order (Priority)

    If multiple plugin instances match a message, they are executed based on their priority value.

    • Lower numerical values have higher priority (they execute first).

    Channel/Platform Filtering

    Do not use the plugin to implement channel filtering. Instead, use the built-in filter feature in the Koishi management page to determine which plugin instance applies to which specific channel or platform.

  10. Implement Private Deliberation Boundaries

    v4

    The specification requires that private model deliberation (e.g., chain-of-thought) remains hidden from users.

    Implementation Requirements for Runtimes:

    • Separation: Private deliberation must be kept separate from user-visible replies.
    • Host Parser Responsibility: If a runtime uses a structured private-deliberation element in its output protocol, the host parser must remove it before delivery to the user.
    • Non-Configurable Security: The removal of private deliberation must be mandatory and cannot be disabled by any persona or plugin.
    • Handling User Requests: If a user explicitly asks for hidden reasoning or chain-of-thought, the subject should provide conclusions, evidence, or a rationale instead of exposing the raw private deliberation.
    • History Handling: When stored private deliberation is replayed to the model as history, the subject must not treat it as content that was already delivered to a reader.

  11. Understand the End-to-End Message Flow in WorldEngine

    v4

    The WorldEngine manages how messages from external platforms are processed and how the WorldAgent acts upon them. The flow follows these stages:

    Inbound Platform Message

    1. Session Resolution: The Core Messenger admits and resolves a Session.
    2. Message Emission: ChannelRuntime persists the canonical channel message and emits yesimbot/message.
    3. WorldEngine Acceptance: WorldEngine accepts messages only from configured chat access points and stores the phone record.
    4. Notification: On an unread transition (from 0 to 1), WorldEngine submits a phone.notification to its running GlobalScope.
    5. Perception: The WorldAgent receives the notification but must use specific phone tools to read message pages.

    WorldAgent Action

    1. Turn Execution: GlobalRuntime runs a single finite WorldAgent turn.
    2. Tool Validation: A WorldEngine tool validates and persists the proposed activity.
    3. Acknowledgement: The tool returns a start acknowledgement.
    4. Adjudication: WorldEngine adjudicates or executes the activity based on its timing.
    5. Completion: Upon completion, WorldEngine commits the result and submits a custom completion message.

    Stop and Restart Lifecycle

    • Stopping: Stopping WorldEngine stops its timers and explicitly stops the GlobalRuntime. The GlobalRuntime interrupts active turns and tools, releases memory, and preserves sessions, assets, and WorldEngine data.
    • Persistence: World time continues from its persisted affine anchor.
    • Restarting: Restarting reloads domain state, supplies a complete GlobalAgent definition, reconciles one offline interval, and submits at most one resume perception.