Plugins

自定义 Plugin

使用 config、actions、hooks、system text、availability、lifecycle 与可选 runtime HTTP routes 构建自定义 plugin

自定义 Plugin

如果你要加的东西主要是:

  • 一组 actions
  • 一组 hooks
  • 一层 system text
  • 一个生命周期拥有的 runtime 边界
  • 一组 runtime HTTP routes

那自定义 plugin 通常就是合适的扩展点。

当前公开入口

@downcity/agent 已经公开了:

  • plugin 类型与契约
  • built-in plugin 导出
  • 本地 Agentplugins: [...] 组装入口

最小骨架

import type { Plugin } from "@downcity/agent";

export const notesPlugin: Plugin = {
  name: "notes",
  title: "Notes Helper",
  description: "Adds note-related actions and prompt guidance.",
  actions: {
    status: {
      execute: async ({ context }) => {
        return {
          success: true,
          data: {
            rootPath: context.rootPath,
          },
        };
      },
    },
  },
};

挂到本地 Agent 上

import { Agent, type Plugin } from "@downcity/agent";

const notesPlugin: Plugin = {
  name: "notes",
  title: "Notes Helper",
  description: "Adds note-related actions and runtime guidance.",
  actions: {
    status: {
      allowWhenDisabled: true,
      execute: async ({ context }) => ({
        success: true,
        data: {
          rootPath: context.rootPath,
        },
      }),
    },
  },
};

const agent = new Agent({
  id: "repo-helper",
  path: "/path/to/project",
  tools: {},
  plugins: [notesPlugin],
});

最重要的设计问题

1. 你到底在扩展什么

先明确你需要的是:

  • actions
  • hooks
  • resolve 点
  • system text
  • lifecycle
  • HTTP

不要默认把每个字段都实现一遍。

2. 哪些 action 需要在 disabled 时仍然可运行

像这些 action:

  • status
  • install
  • configure

通常需要 allowWhenDisabled: true

3. 运行态状态是否应该待在 lifecycle 内

如果这段能力必须:

  • 跟随 plugin start/stop
  • 持有内存状态
  • 在重启后恢复

那就应该把它建模在 plugin lifecycle 里,而不是偷偷塞进无关 hooks。

一个实用规则

在可能的情况下,让 plugin 逻辑尽量只依赖最小稳定的 plugin context,而不是默认假设能拿到所有 runtime singleton。

如果你想看场景化示例