jianf/HomeAgent

Fork 0

mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-21 17:38:10 +00:00

Files

JianFeeeee 59c9dd5153 docs+test: Lua stage 写回能力文档与测试(与 C ABI v2 对齐)

2026-08-15 18:08:01 +08:00

29 KiB

Raw Blame History

中文 | English

HomeAgent Plugin Development Guide

Overview

All external interaction capabilities of HomeAgent comes from plugins. Plugins interact with the kernel through PluginSDK (Go API).

SDK Repository: Plugin development tools, template code, and example plugins are hosted in the homeagent-sdk repository.

git clone https://gitcode.com/JianFeeeee/homeagent-sdk.git
cd homeagent-sdk

Each plugin implements a three-method interface:

type Plugin interface {
    Name() string
    Start(sdk *PluginSDK) error
    Stop() error
}

Three Development Methods

Method	Use Case	Complexity
Dynamic .so/.dll plugin (recommended)	Independently distributed third-party plugins	Medium, generated using `plugindev` toolchain
Built-in plugin	Released with HomeAgent	Simple, requires merging into main repo
Lua script plugin	Lightweight rapid prototyping	Simple, generated using `plugindev init --lua`

1. Quick Start: Using the plugindev Toolchain

plugindev is the unified plugin development toolchain provided in the SDK repository, supporting both Go and Lua plugin types.

Installation

cd homeagent-sdk/tools/plugindev
go build -o plugindev
# Add plugindev to PATH or use directly

SDK Version Management

plugindev sdk manages local SDK versions:

plugindev sdk list       # list installed SDK versions
plugindev sdk current    # show current SDK version
plugindev sdk latest     # show latest available version
plugindev sdk install v0.8.0  # install a specific version
plugindev sdk use v0.8.0      # switch to a version
plugindev sdk path       # show current SDK path

SDK is stored at ~/.homeagent/plugindev/sdk/<version>/; plugindev init reads the current SDK version for go.mod.

Source Debugging

plugindev debug interprets plugin source and prints a call trace, no compilation environment needed:

plugindev debug [dir]   # dir defaults to the current directory

Creating a Go Plugin

plugindev init myplugin
cd myplugin
# Edit plugin code
vim plugin.go
# Build and package (default is a multi-platform bundle, see below)
plugindev build
# Output: dist/myplugin_bundle.hmap
# Single-platform build:
plugindev build --no-bundle
# Output: dist/myplugin_linux_amd64.hmap (or windows_amd64)

Creating a Lua Plugin

plugindev init myluaplugin --lua
cd myluaplugin
# Edit plugin code
vim main.lua
# Local test
lua main.lua
# Build and package
plugindev build
# Output: dist/myluaplugin_lua.hmap

Template Project Structure

Go plugin:

myplugin/
├── plg.json       — Plugin metadata (name, version, entry, target platforms)
├── plugin.go      — Plugin implementation (Plugin interface + NewPlugin export)
├── go.mod         — Go module definition
├── README.md      — Documentation
└── thirdpart/     — Optional external source code directory

C ABI bridge files (z_bridge_gen.go + z_entry.c) are auto-generated at build time.

Lua plugin:

myluaplugin/
├── plg.json       — Plugin metadata (entry: "main.lua", targets: "lua")
├── main.lua       — Plugin implementation (Lua version of Plugin interface)
├── sdk.lua        — SDK mock layer (supports `lua main.lua` standalone testing)
└── README.md      — Documentation

Build & Package

plugindev build automatically handles compilation and packaging:

cd myplugin
plugindev build                      # default bundle mode (multi-platform)
plugindev build --no-bundle          # single-target build (per plg.json targets)
plugindev build --target linux/amd64 # append a target on top of plg.json targets
plugindev build --outdir dist        # output directory (default: dist)
plugindev build --sdk-path <path>    # SDK path override (go.mod replace)
plugindev build --replace <mod@path> # append a go.mod replace directive (repeatable)

Execution process:

Reads plg.json targets/bundle fields to determine build targets (bundle takes priority, see below)
Auto-generates C ABI bridge code (z_bridge_gen.go + z_entry.c; Windows only z_bridge_gen.go)
Go plugin: Runs go build -buildmode=c-shared (produces .so / .dylib / .dll)
Lua plugin: Packages source code directly, no compilation needed (contents: plugin.json + main.lua, plus optional README.md, LICENSE, thirdpart/*.lua)
Generates plugin.json output manifest
Packages as .hmap distribution (zip format, containing plugin.json + binary)

plg.json (project config) vs plugin.json (output manifest)

File	Purpose	Key fields
`plg.json`	Project metadata, maintained by developer	`targets` — single-target build list (e.g. `"linux/amd64,windows/amd64"`); `bundle` — multi-platform bundle switch (default `true`)
`plugin.json`	Build artifact manifest, auto-generated	`entry` — entry filename; `platforms` — declared platforms

Each target produces a separate .hmap; binary name by platform:

Platform	Binary
Linux	`plugin.so`
macOS	`plugin.dylib`
Windows	`plugin.dll`

Build Targets & Multi-platform Bundle

plugindev build defaults to bundle mode (unless plg.json explicitly sets "bundle": false): it builds linux/amd64 + darwin/amd64 + windows/amd64 in one pass, producing a single .hmap with all platform binaries. The output manifest includes a platforms field. The kernel auto-selects the correct binary during installation.

plugindev build              # default bundle, outputs dist/myplugin_bundle.hmap
plugindev build --bundle     # explicitly enable bundle (same as above)
plugindev build --no-bundle  # disable bundle, build per plg.json targets

Notes:

In bundle mode the plg.json targets field is ignored; the three platforms above are always built
Cross-compilation needs the corresponding toolchains (e.g. building darwin on Linux requires clang/macOS SDK); if a toolchain is missing the build fails — use --no-bundle to build only the current platform
Single-target output naming: {name}_{os}_{arch}.hmap, e.g. myplugin_linux_amd64.hmap

Output in dist/ directory:

dist/
├── myplugin_bundle.hmap           # default bundle: multi-platform
├── myplugin_linux_amd64.hmap      # after --no-bundle: Linux
├── myplugin_windows_amd64.hmap    # after --no-bundle: Windows
├── myplugin_darwin_amd64.hmap     # after --no-bundle: macOS
└── myplugin_lua.hmap              # Lua plugin

Deployment

Install via PluginMgr HTTP API (three methods):

# 1. Install from URL (http/https only, streamed, no local temp file)
curl -X POST http://127.0.0.1:9876/plugins \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/myplugin.hmap"}'

# 2. Install from local path (reads the given file, source file untouched)
curl -X POST http://127.0.0.1:9876/plugins \
  -H "Content-Type: application/json" \
  -d '{"path": "/path/to/myplugin.hmap"}'

# 3. Upload binary directly
curl -X POST http://127.0.0.1:9876/plugins \
  --data-binary @dist/myplugin.hmap

9876 is the pluginmgr local port (defaults to listening on 127.0.0.1 only, no auth).

Reload plugins via /api/v1/plugins/reload or restart the kernel to activate.

Or upload via the WebUI plugin management page, or through the WebUI HTTP API (default port 8080, requires the api_key bearer token; it proxies to pluginmgr):

curl -X POST http://127.0.0.1:8080/api/v1/plugins \
  -H "Authorization: Bearer <api_key>" \
  -H "Content-Type: application/json" \
  -d '{"path": "/path/to/myplugin.hmap"}'

2. Go Plugin Development in Detail

Plugin Interface

package main

import "gitcode.com/JianFeeeee/homeagent-sdk/sdk"

type Plugin struct {
    name string
    sdk  *sdk.PluginSDK
}

func (p *Plugin) Name() string { return p.name }

func (p *Plugin) Start(s *sdk.PluginSDK) error {
    p.sdk = s
    // Register config items, tools, stage hooks, etc.
    return nil
}

func (p *Plugin) Stop() error {
    // Clean up resources
    return nil
}

// NewPluginFactory creates plugin instance (called by main.go or Windows bridge)
func NewPluginFactory(name string, config map[string]interface{}) (sdk.Plugin, error) {
    return &Plugin{name: name}, nil
}

Entry Point

plugindev init generates plugin.go with the NewPlugin export function directly, which is the entry point when the kernel loads the plugin:

func NewPlugin(name string, config map[string]interface{}) (sdk.Plugin, error) {
    return &Plugin{name: name}, nil
}

At build time, plugindev build auto-generates C ABI bridge code (z_bridge_gen.go + z_entry.c), shared by both Windows DLL and Linux/macOS .so builds. No manual bridge code needed.

PluginSDK Core API

Tool Registration — Make your capabilities callable by LLM

s.RegisterTool("weather_query", sdk.ToolDef{
    Name:        "weather_query",
    Description: "Query weather for a specified city",
    NoMemory:    false,                            // false=output participates in memory, true=skip
    // Cleaner:  func(output string) string {     // Optional: clean output before vector/jieba/distill
    //     return extractJSON(output, "content")
    // },
    Parameters: map[string]interface{}{
        "type": "object",
        "properties": map[string]interface{}{
            "city": map[string]interface{}{
                "type":        "string",
                "description": "City name, e.g. Beijing",
            },
        },
        "required": []string{"city"},
    },
}, func(args map[string]interface{}) (interface{}, error) {
    city, _ := args["city"].(string)
    return map[string]interface{}{
        "city":    city,
        "temp":    25,
        "weather": "Sunny",
    }, nil
})

NoMemory and Cleaner

NoMemory and Cleaner are optional fields on ToolDef that control how tool output participates in the memory computation layer (vectorization, jieba tokenization, distillation):

NoMemory (default false): When true, the tool's output is excluded from all memory computation (vector, tokenization, distillation), but the original text is preserved in Context and Document. LLM attention is unaffected. Use cases: cmd_run (unpredictable noise in command output), pure operation tools like file upload/delete.
Cleaner (optional): A function func(output string) string. When set, the tool output is filtered through this function before participating in vectorization/jieba/distillation. Typical use: stripping SQL prefixes, extracting a content field from JSON. The original output is never modified — Cleaner only affects the computation layer input.

Decision matrix:

Tool output → valuable for LLM attention?
  ├── No  → NoMemory=true (output preserved, skipped in computation)
  └── Yes → Contains cleanable noise?
       ├── Yes → Cleaner filters before computation
       └── No  → Normal memory, no extra handling

Note

: Cleaner is a Go func type (json:"-"), cannot cross C ABI boundaries, so it is unavailable for C/C++/Rust remote plugins. Lua plugins are not affected: pass a Lua function in the def table (cleaner = function(text) return text end) — the Go bridge calls it back per invocation during memory computation.

Stage Hooks — Intervene in message processing flow

7 stages:

Stage	Timing	Purpose
`on_input`	Message just arrived at Agent	Blacklist, rate-limit, short-circuit
`pre_action`	About to call LLM	Inject context
`post_action`	LLM returned results	Modify output/tool list
`before_toolcall`	Before tool execution	Audit, reject, modify params
`after_toolcall`	After tool execution	Desensitize, rewrite results
`before_output`	Before output	Format adaptation, leak cleanup
`after_output`	After output	Statistics/logging

// Global: receive all stage events
s.RegisterStage(sdk.StagePreAction, func(ctx *sdk.StageContext) error {
	ctx.Lock()
	ctx.ContextMsgs = append(ctx.ContextMsgs, map[string]interface{}{
		"role":    "system",
		"content": "Injected context content",
	})
	ctx.Unlock()
	return nil
})

// Own tools only: only before_toolcall/after_toolcall for this plugin's tools
s.RegisterStage(sdk.StageBeforeToolcall, myHandler, sdk.StageScopeOwnTools)

Configuration Management

// Register config definition
s.Settings().RegisterDef(sdk.ConfigDef{
    Key:         "plugin.myplugin.api_key",
    Default:     "",
    Type:        "string",
    DisplayName: "API Key",
    Description: "API key",
    Category:    "myplugin",
})

// Read/write config
val, err := s.Settings().Get("api_key")
s.Settings().Set("api_key", "new-value")

// Read core config
s.Settings().GetCore("llm.model")

// Read other plugin's config
s.Settings().GetPlugin("other_plugin", "some_key")

Input Delivery

// Normal delivery (processed in order)
s.InjectText(source, channel, text string)

// Interrupt delivery (can interrupt current LLM processing)
s.InjectInterruptText(source, channel, text string)

// No memory recording
s.InjectTextNoMemory(source, channel, text string)

Input Channel Registration — Declare External Message Sources

s.RegisterInputChannel("qq", sdk.ChannelDef{
    NoMemory: true,
    Cleaner: func(text string) string {
        return strings.TrimSpace(text)
    },
})

ChannelDef controls channel behavior in the memory computation layer:

Field	Default	Description
`NoMemory`	`false`	Channel input/output skips vectorization/keyword/distillation; original text preserved in context
`Cleaner`	`nil`	`func(string) string` computation filter (does not modify original text)

Noisy sources (QQ group messages, RSS feeds, etc.) should set NoMemory: true.

Output Channel Registration — Declare Output Destinations

s.RegisterOutputChannel("email", 1, "Send Email", sdk.ChannelDef{
    NoMemory: true,
}, func(args map[string]interface{}) (interface{}, error) {
    to, _ := args["to"].(string)
    subject, _ := args["subject"].(string)
    body, _ := args["body"].(string)
    return map[string]interface{}{"status": "sent"}, nil
})

Parameters: name (route key), caps (1=text/2=rich/4=file/8=image), desc, def (ChannelDef), handler (callback).

Event Subscription

import "gitcode.com/JianFeeeee/homeagent-sdk/sdk"

unsub := s.Events().Subscribe(sdk.EventToolCall, func(evt *sdk.Event) {
    log.Printf("Tool was called: %v", evt.Payload)
})
defer unsub()

Capability Access

// Graph Memory (entity-relation store)
entities, relations, err := s.Memory().Recall([]string{"keyword"}, 2)

// Document Memory (vector store)
docs := s.DocMemory().Query("query text", 3)

// Knowledge
results, err := s.Knowledge().Search("query", 5)

// LLM source management
s.LLM().ListSources() // returns []string
s.LLM().SetSource("deepseek")

Event Subscription (built-in plugins)

// Subscribe to system events, returns unsubscribe function
unsub := s.Subscribe("tool_call", func(evt *events.Event) {
    log.Printf("Tool was called: %v", evt.Payload)
})
defer unsub()

// Publish event
s.Publish(&events.Event{
    Type:    "custom_event",
    Payload: map[string]interface{}{"key": "value"},
})

IO Channel Management (built-in plugins)

// Register a channel (bind device driver), dev must implement the agentIO.Device interface:
//   Name() string
//   Type() DeviceType
//   Description() string
//   Tools() []ToolDef
//   Execute(tool string, args map[string]interface{}) (interface{}, error)
//   Start() error
//   Stop() error
//   OutputCapabilities() OutputCapability
s.RegisterChannel("mydevice", deviceImpl)

// Unregister a channel
s.UnregisterChannel("mydevice")

// List all channels
channels := s.ListChannels()

Input Delivery (built-in plugins)

// Queued delivery (processed in order)
s.InjectInput(source, channel, eventType string, payload map[string]interface{})

// Synchronous delivery (waits for response)
resp := s.InjectInputSync(source, channel, eventType string, payload map[string]interface{})

// Interrupt delivery (can preempt current LLM processing)
s.InjectInterrupt(source, channel, eventType string, payload map[string]interface{})

// Synchronous text shortcuts
resp := s.InjectTextSync(source, channel, text string)
resp := s.InjectTextSyncNoMemory(source, channel, text string)

// Get output channel
outputCh := s.OutputChan()

Note

: Subscribe, Publish, RegisterChannel, UnregisterChannel, ListChannels, InjectInput, InjectInputSync, InjectInterrupt, InjectTextSync, InjectTextSyncNoMemory, OutputChan are only available in built-in plugins (internal/sdk package). External dynamic plugins should use the public APIs: InjectText, InjectInterruptText, InjectTextNoMemory.

3. Lua Plugin Development in Detail

Lua plugins are suitable for lightweight rapid prototyping, requiring no Go compilation environment. Changes take effect after kernel restart.

Execution Model

Lua plugins run inside the kernel process on a gopher-lua interpreter (single Lua state guarded by a mutex). This differs fundamentally from Go plugins:

Passive callback model: main.lua executes only once at load time. Afterward, tools, stage hooks, output/input channels, and registered APIs are all invoked by the kernel via callbacks into Lua functions. Plugins cannot start background tasks on their own.
No concurrency / no long-running services: Lua has no goroutines, coroutine scheduling, os/io libraries, or socket listening. The only outbound capability is sdk.http.get/post (synchronous). Any blocking loop will stall every call of that plugin while holding the lock.
For long-running services (listening on a port, background polling, timers) use a Go plugin (.so/.dll built with the toolchain, which may spawn goroutines — see the webui/cli plugins). The Lua equivalent is event-driven: register tools/stage hooks/channels to be called back by the kernel, or interact with external processes via sdk.http.

Plugin Structure

-- main.lua
local plugin = {
  name = "myluaplugin"
}

function plugin.start(sdk)
  sdk.log("info", "myluaplugin starting...")

  sdk.register_tool("myluaplugin_hello", {
    description = "A hello world tool",
    parameters = {
      type = "object",
      properties = {}
    }
  }, function(args)
    return { content = "Hello from myluaplugin plugin!" }
  end)

  sdk.log("info", "myluaplugin started")
end

function plugin.stop()
  sdk.log("info", "myluaplugin stopped")
end

return plugin

SDK Mock Layer

sdk.lua provides a pure Lua SDK mock implementation, supporting lua main.lua standalone testing:

lua main.lua
# Output:
# [lua-plugin] info: myluaplugin starting...
# [lua-plugin] register_tool: myluaplugin_hello
# [lua-plugin] info: myluaplugin started

When running inside the kernel, sdk.* global variables are injected by the Go layer, and all functions marked with -- !impl are replaced with real implementations.

Lua SDK API

The sdk.* API of Lua plugins is fully aligned with external plugins (C ABI / toolchain-built .so/.dll): registration functions raise a Lua error on failure; data functions uniformly return (result, err) with err == nil on success. Subsystems not wired by the core (e.g. SocialAPI) return empty values instead of errors.

Registration

Function	Description
`sdk.log(level, msg)`	Log output
`sdk.register_tool(name, def, handler)`	Register tool; `def` supports `description`, `parameters`, `no_memory`, `cleaner`
`sdk.register_stage(stage, handler, scope)`	Register stage hook; `scope` is `nil`/`"global"` (default) or `"own_tools"` (fires only for `before_toolcall`/`after_toolcall` when the tool belongs to this plugin)
`sdk.register_api(name)`	Register API
`sdk.register_output_channel(name, caps, desc, def, handler)`	Register output channel; `def` supports `no_memory`, `cleaner`
`sdk.register_input_channel(name, def)`	Register input channel; `def` as above
`sdk.set_auto_restart(enabled)`	Auto-restart the plugin after a crash

Stage hook context

Stage handlers receive the full context (same as external plugins): raw_message, user_id, group_id, phase, llm_text, final_text, no_memory, response (when responded), tool_calls, tool_results.

Stage writeback (ABI v2): the ctx table passed to the handler is a reference — mutating writable fields inside the handler syncs back to the core StageContext (aligned with the C ABI v2 external-plugin capability):

sdk.register_stage("on_input", function(ctx)
  ctx.raw_message = "[clean]" .. ctx.raw_message   -- modify input, adopted by core
end)

sdk.register_stage("post_action", function(ctx)
  ctx.llm_text = ctx.llm_text .. "[tail]"            -- modify LLM output
  ctx.tool_results = { { call_id = "x", result = "rewritten" } }
end)

Writable fields: raw_message, llm_text, final_text, user_id, group_id, no_memory, response, tool_calls, tool_results. Other fields are read-only.

IO and config

Function	Description
`sdk.get_setting(key)` / `sdk.set_setting(key, value)`	Own plugin config read/write
`sdk.settings.get_core/set_core/list_core(key)`	Core config read/write
`sdk.settings.get_plugin/set_plugin/list_plugin(plugin, key)`	Other plugin config read/write
`sdk.settings.list/defs/dump/plugins(prefix)`	Config queries
`sdk.settings.register_def(def)`	Register config definition (WebUI display)
`sdk.inject_text(source, channel, text)`	Deliver text message
`sdk.inject_interrupt(source, channel, text)`	Interrupt delivery
`sdk.inject_text_no_memory(source, channel, text)`	Deliver without memory computation

Data APIs (aligned with C ABI, all return (result, err))

Sub-table	Functions
`sdk.memory.*`	`recall(query, depth)`, `commit({triples})`, `introspect()`, `merge(source, target)`, `purge(criteria, hard)`
`sdk.doc.*`	`query(text, top_k)`, `insert({id,title,content})`, `remove(id)`, `stats()`
`sdk.knowledge.*`	`search(query, limit)`, `add(tag, content)`, `list()`
`sdk.text_memory.*`	`append({role,content,timestamp,channel})`
`sdk.llm.*`	`list_sources()`, `set_source(name)`, `current_source()`
`sdk.social.*` (read-only)	`get_person(name)`, `get_network(name, depth)`, `get_trait(name, trait)`, `get_relations(name)`, `list_persons()`
`sdk.json.*`	`encode(val)`, `decode(str)`
`sdk.http.*`	`get(url)`, `post(url, body, content_type)`

4. Built-in Plugins

Built-in plugins use init() self-registration, compiled into the kernel, no separate deployment needed.

Directory Structure

internal/plugins/yourplugin/
    plugin.go       — Plugin main file

Minimal Plugin Example

package yourplugin

import (
    "gitcode.com/JianFeeeee/HomeAgent/internal/plugin"
    sdk "gitcode.com/JianFeeeee/HomeAgent/internal/sdk"
)

func init() {
    plugin.RegisterFactory("yourplugin", func(name string, config map[string]interface{}) (sdk.Plugin, error) {
        return New(name), nil
    })
}

type Plugin struct {
    name string
}

func New(name string) *Plugin {
    return &Plugin{name: name}
}

func (p *Plugin) Name() string { return p.name }

func (p *Plugin) Start(s *sdk.PluginSDK) error {
    // Initialize plugin here: start goroutines, register tools, subscribe events, etc.
    return nil
}

func (p *Plugin) Stop() error {
    // Clean up resources
    return nil
}

Register with Kernel

Add blank import in internal/plugins/all.go:

package plugins

import (
    _ "gitcode.com/JianFeeeee/HomeAgent/internal/plugins/yourplugin"
    // ... other plugins
)

5. Best Practices

Start() is non-blocking — start long tasks in goroutines, don't block Start
Stop() cleans up resources — close connections, stop goroutines, cancel subscriptions
Unique tool names — use plugin name prefix to avoid conflicts
When handler returns error, LLM will receive it and may retry
Use InjectInterruptText for interrupts, InjectText for normal delivery
Use Settings().Get/Set for config, don't hardcode
External Go plugins compile independently, not tied to kernel version; only built-in plugins need recompilation with kernel

6. Plugin Management

CLI Commands

/plugin list                  # List all plugins with status (loaded/disabled)
/plugin disable <name>        # Disable plugin (immediate, no longer receives input)
/plugin enable <name>         # Enable plugin (restored after restart)
/plugin reload                # Reload all plugins

WebUI

Dashboard plugin list provides "Disable/Enable" buttons in the actions column. Disabling WebUI itself shows a confirmation dialog to prevent misoperation.

Built-in Plugin API

pmgr := s.PluginMgr()
pmgr.DisablePlugin("qq", "admin")       // Disable
pmgr.EnablePlugin("qq")                  // Enable
list := pmgr.ListDisabledPlugins()       // List disabled plugins
loaded := pmgr.ListLoadedPlugins()       // List loaded plugins
pmgr.IsPluginDisabled("qq")              // Check if disabled
pmgr.ReloadPlugins()                     // Reload all plugins

Internal: records are stored in SQLite disabled_plugins table (name, disabled_at, disabled_by). Disabling takes effect immediately (plugin stops receiving input); full removal requires a restart.

Note

: PluginMgr() is only available to built-in plugins; external dynamic plugins cannot call it directly.

7. Example Plugin Reference

SDK Repository Examples (`homeagent-sdk/example/`)

Example	Type	Features
weather	Go	Weather queries (wttr.in); demonstrates NoMemory/Cleaner/stage hooks/channels/text memory
luademo	Lua	Full-featured Lua example covering the whole v0.8.0 Lua SDK surface
qq	Go	NapCat OneBot integration, 17 tools, full input/output channel wiring
memo	Go	Memo management, PreAction injection + timed interrupt dual reminder
files	Go	File system operations, 4 write modes, sandbox isolation
browser	Go	Web search + HTTP fetch (SSRF) + Chromium render (merged from web/webfetch)
bili	Go	Bilibili video download (yt-dlp)
editdoc	Go	Office document editing and format conversion
a2a	Go	Agent-to-Agent protocol
ocr	Go	Offline text recognition (Tesseract)
sanitizer	Go	Output sanitizer filter
calendar	Go	Calendar management
rss	Go	RSS subscriptions
ai_image	Go	AI image generation
music	Go	Music playback

Built-in Plugins

Plugin	Location	Features
Timer	`internal/plugins/timer/`	Simplest complete example, registers one tool + interrupt feedback
CLI	`internal/plugins/cli/`	Unix socket listener + synchronous request-response
WebUI	`internal/plugins/webui/`	HTTP service + dependency injection

Want to understand the project goals? See OVERVIEW.md. Want to understand the architecture? See ARCHITECTURE.md. SDK repository and development tools? See homeagent-sdk.

29 KiB Raw Blame History