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 导出
- 本地
Agent的plugins: [...]组装入口
最小骨架
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:
statusinstallconfigure
通常需要 allowWhenDisabled: true。
3. 运行态状态是否应该待在 lifecycle 内
如果这段能力必须:
- 跟随 plugin start/stop
- 持有内存状态
- 在重启后恢复
那就应该把它建模在 plugin lifecycle 里,而不是偷偷塞进无关 hooks。
一个实用规则
在可能的情况下,让 plugin 逻辑尽量只依赖最小稳定的 plugin context,而不是默认假设能拿到所有 runtime singleton。