Compare commits

...
Author SHA1 Message Date
weichenandCursor a3f0b80759 Propose the agent harness and link it from the roadmap
Why: Tool-call history is flattened into assistant text, so the model imitates calls and invents artifact ids. The fix belongs to a shared harness, not another prompt tweak.
Evidence: Proposal 2026-10-01-agent-harness.md records the 2026-10-01 session evidence, the ZCode and Claude Code patterns, and the P0-P4 acceptance.
Impact: Documents only. P0 code lands in the backend on the same branch name. P1-P4 are not implemented here.
Refs: feature/agent-harness-p0
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-01 12:25:31 +00:00
weichen f3a3a5deb4 Document the base extension roadmap and plugin contract v2
Why: The base must stay unmodified by downstream products, so the roadmap, compatibility window, and plugin contract need a written proposal before further forks.

Evidence: Three proposals under docs/proposals and a short pointer in the plugin development guide.

Impact: Tag commands in the compat proposal are not executed.

Refs: Agent-System-Dev feature/base-extension-roadmap
2026-10-01 10:47:11 +00:00
weichenandCursor a0da588f90 Document the base extension roadmap and plugin contract v2
Why: The base must stay unmodified by downstream products, so the roadmap, compatibility window, and plugin contract need a written proposal before further forks.
Evidence: Three proposals under docs/proposals and a short pointer in the plugin development guide.
Impact: Downstream work follows extension-point requests and a published base version. Tag commands in the compat proposal are not executed.
Refs: .task/feature-base-extension-roadmap.md
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-10-01 10:34:30 +00:00
weichen 8ee5d5c467 Merge pull request 'Document project inbox dual view and archive flow (CF3)' (#30) from feature/project-inbox-r1 into main 2026-09-30 19:19:28 +00:00
5 changed files with 343 additions and 0 deletions
+2
View File
@@ -5,6 +5,8 @@
参考实现:Dev 仓 `plugins/example`(覆盖全部五类能力,可直接复制改造)。
契约 v2(声明 / 进程内编译 / sidecar / 前端 ESM,下游仓不得改基座)见提案 `docs/proposals/2026-10-01-plugin-contract-v2.md`。`make plugin-new NAME=<id>` 生成声明式骨架。
## 1. 目录结构
```
+124
View File
@@ -0,0 +1,124 @@
# Agent harness:回合循环、结果把控与多代理编排
状态:**proposed(2026-10-01)**;owner:weichen;主任务:Dev 仓 `feature/agent-harness-p0`。
规范依据:Development-Guidelines(workflows/delivery.md、standards/collaboration.md、standards/agent-execution.md);本文是项目级消费,不复制其正文。
撰写日期:2026-10-01。对标来源:[zai-org/ZCode](https://github.com/zai-org/ZCode)(Apache-2.0,`apps/zcode-cli/packages/core`)、[Claude Code 公开文档](https://code.claude.com/docs/en/overview) 与其插件仓 [anthropics/claude-code](https://github.com/anthropics/claude-code)。
本文只定义 harness 的职责、分期与验收。P0 随本文落地;P1–P4 各自另开任务,不在本文实施。
---
## 1. 问题与证据
2026-10-01,会话 `cnv_96f639abf03a` 第 26 轮(开发库 `runtime/dev/data/agent-system.db`)用户要求「重新总结纪要」。助手正文里出现了 `[调用工具 run_python(…)]`、`[工具结果 ok …]`、`[产出工件 …(二进制内容,正文见工件查看器)]`,并给出工件 ID `art_1a2b3c4d5e6f`。该轮落库部件只有 `thinking` 与 `text`,没有任何 `tool_call`;`artifacts` 表里没有这个 ID,所以界面显示「未找到该文件」。同会话第 16、20 轮的 `art_7b24c0b7e2f1`、`art_4f9d2c1a8b3e` 同样不存在。第 22、24 轮才是真实的工具调用与工件。
直接原因在上下文组装:`modules/backend/internal/ctxasm/ctxasm.go` 把历史里的工具调用压成文本 `[调用工具 …]` / `[工具结果 …]` 写进助手消息。模型把这种文本当成「我以前就是这样调用工具的」格式,在正文里模仿。虚假交付守卫(`claimsFalseDeliverable`)只纠正一次,第二段「文件已正常生成并登记」既没有 `art_` 编号,也匹配不上「已生成….docx」正则,被当成最终回复放行。
同一机制下还有这些结构性缺口(2026-10-01 只读梳理):
- 三套循环各自为政。直连走 `LLMRunner`;小队成员走 `agent-native` 的 `runtime.Run`(已有 `GetSteering` / `GetFollowUp`,直连没用);`delegate_task` 背后的 `SubLLMRunner` 是单次调用、没有工具。
- 是否完成由干活的模型自报。`quality_review` 与版式检查只靠提示词约定;`agent.sub.verify` 要求输出的 `VERDICT` 没有解析方;模型评分 `Judge` 只有类型、没有接线。
- 没有逐轮提醒。计划和待办只给界面看,不回灌给模型。技能只按当前这条用户文本匹配一次。
- 子 run 的助手消息落在同一会话,列表不按 run 过滤,下一轮会被当成主对话回放。
- 插件工作流只有数据、没有执行器。`WorkflowDef.IntentID` 没有消费方。意图识别没有路由到工作流。
- 预算耗尽时直接返回错误,已生成的部件不落库。工具结果按字节截断,可能切在 UTF-8 字符中间。
## 2. 对标结论
两边的共同点:工具调用按提供方的原生消息回放,而不是压成正文;完成与否由循环或另一个评估者判定,不由干活的模型宣布;子代理上下文隔离,只把摘要交回父会话;每条续跑路径都有次数上限。
| 机制 | ZCode | Claude Code | 本基座采纳 |
|---|---|---|---|
| 历史回放 | `tool_calls` + `role=tool`;没有结果的调用补占位,并区分「未执行」与「副作用未知」 | 同形(公开文档描述为工具结果回传) | 采纳。占位文案按原因区分 |
| 完成判定 | 同模型、不带工具,按证据清单输出 `{passed, reason, nextAction}`;拿不准判不通过。验证器自身出错时放行 | `/goal`:每轮结束后由另一个模型判断,不成立就开下一轮 | 采纳证据清单。交付物场景下验证器出错改为判不通过,并设次数上限 |
| 结束门禁 | Stop hook 返回继续并注入上下文,最多 3 次 | Stop / SubagentStop 返回 `decision: block` + `reason`;`stop_hook_active` 防止死循环 | 采纳 `block + reason`,上限 3 |
| 提醒 | 按来源节流,包在 `<system-reminder>` 里,位置不破坏工具消息配对 | 规范、待办、后台完成以 system-reminder 插入,不改 system 段 | 采纳 |
| 异常 | 同名同参数连续 3 次给警告,不直接终止;输出被截断最多续写 3 次,续写提示不入库 | 公开文档未给出同等细节 | 采纳警告与续写 |
| 子代理 | Markdown frontmatter 定义;调用方不能指定模型;嵌套深度从工具白名单上限制为 1;后台完成用通知回传,多条合并 | 同形。子代理只回传最终结果,中间过程不进父上下文 | 采纳 |
| 评审 | expert 的 critic 用 JSON 判定,可按节点重开,每层有上限 | `code-review` 插件:并行找问题,每条再独立验证,未通过的丢弃 | 采纳「并行评审 → 逐条验证 → 过滤 → 汇总」 |
| 工作流 | 阶段产物落盘,下游只传路径;确定性检查优先于模型自报;人工升级以单个节点为粒度 | feature-dev:阶段之间有人工门禁 | 采纳产物落盘与确定性检查优先。脚本化动态工作流留到 P4 再决定 |
## 3. 目标
harness 是基座能力,不是某个下游的领域规则。它回答四件事:这一轮看到什么、循环何时继续或停止、怎样判定结果为真、多个代理怎样拉起、分配、评审和汇总。
内核放在 `agent-native` 的 `runtime`,直连、小队和子代理共用同一套循环。`core.Part` 到模型消息的投影留在 backend:内核不认识 `core` 类型。
```text
agent-native runtime
TurnLoop 预算、输出续写、重复调用检测
Transcript 原生回放,没有结果的调用补占位
ReminderBus 按来源节流的提醒,不改 system 段
HookBus PreTool / PostTool / Stop / SubagentStop
CompletionGate 确定性检查 + 不带工具的验证器
SubagentRuntime profile、深度 1、只回传摘要、完成通知
backend 适配
LLMRunner 薄适配:事件、部件、落库
ctxasm core.Message 投影为模型消息
交付物门禁 工件存在、版式检查、quality_review
工作流执行器 引擎驱动步骤,IntentID 路由
```
## 4. 分期
### P0 回放保真与守卫加固(本文随附实施)
- 助手历史按 `assistant{ToolCalls}` 与 `tool{ToolCallID, Content, IsError}` 回放。没有结果的调用补「(无结果:运行中断)」;孤立的结果跳过;空 ID 用 `hist_<消息ID>_<序号>` 补上。
- 参数超过 4000 字符时截断其中的长字符串,结果仍是合法 JSON。
- 跳过被守卫降级的过程文本(`Process=true` 且后面紧跟的不是工具调用)。从助手历史文本里剔除存量的 `[调用工具 `、`[工具结果 `、`[产出工件 `。
- 守卫改成 `deliverableGate(body, produced, rc) (block bool, reason string)`,形状与 P1 的 Stop 门禁一致,P1 时平移进内核。
- 新增判定:正文里出现伪造调用标记;本轮没有工件时声称文件已生成、已登记或已保存。纠正上限 2 次。回灌用占位文本,不把伪造正文再塞给模型。两次之后仍谎称,终轮正文降为过程,并追加一条非过程提示,说明本轮没有实际生成文件。
- 提示词 `base.deliverables` 写明:工具只能通过函数调用触发,不要在正文里书写调用标记。版本升到 5。
验收:回放后的模型输入里不再出现 `[调用工具` 文本;用第 26 轮那种「只有伪造标记、没有真实工具调用」的输入,守卫会拦住,不会再登记一个不存在的工件 ID。
### P1 内核原语
给 `agent-native` 的 `runtime.Config` 加上 Stop 门禁、工具前后钩子、提醒通道、重复调用检测、输出被截断时的续写,以及预算耗尽时保留已有部件再收尾。`LLMRunner` 改为 `runtime.Run` 的薄适配。P0 的 `deliverableGate` 平移成一个 Stop 门禁。
验收:backend 与 agent-native 的既有测试保持通过;直连与小队成员走同一个循环。
风险:`agent-native` 在 Dev 仓 `deps/`、backend 的 `deps/`、agent-squad 的 `deps/` 各有一处 gitlink。P1 起要按依赖顺序推进指针,不能只改最外层。
### P2 结果把控
- 独立验证器:不带工具的一次模型调用,按证据清单输出 JSON `{passed, reason, nextAction}`。拿不准判不通过。验证器出错或返回无法解析的内容时也判不通过(与 ZCode 的放行不同),整个门禁最多 3 次。
- 确定性检查排在模型自报之前:本轮登记的工件确实存在、`housestyle.lint` 没有 error、`quality_review` 达到通过线。
- 计划和待办按节奏用提醒回灌。例如连续多轮没有更新待办才提醒一次,避免每轮都占上下文。
验收:评测夹具里「声称已交付但没有工件」的用例全部被拦下,并留下可核对的原因。
### P3 多代理
- 子代理用 Markdown 加 frontmatter 声明(`name`、`description`、`tools`、`model`、`maxTurns`),复用现有 `agent-sub-*.md` 并补上 frontmatter。调用方不能指定模型。
- `delegate_task` 改为带工具的子循环。工具白名单里去掉派发类工具,嵌套深度为 1。父会话只收到摘要和工件路径。
- 支持后台运行。完成后用通知回传,多条合并成一次注入。
- 子 run 的消息与父会话历史隔离,不再被下一轮当成主对话回放。
- `squad_orchestrate` 与直连子代理用同一套运行时。评审走「并行找问题 → 每条独立验证 → 丢掉未验证的 → 汇总」。
### P4 意图到工作流
给 `WorkflowDef` 补执行器,由引擎驱动 `prompt` / `tool` / `hitl` / `artifact` / `card` 步骤,而不是只在插件清单里列出。用 `IntentID` 把命中的意图接到工作流。critic 可以按节点打回重做,每一层都有次数上限。是否引入脚本化的动态工作流,留到 P4 评审时决定。
## 5. 不在本文范围
- 单份纪要的内容质量(例如「3 项决议」与表格行数对不上)。那是生成质量,不是回放与门禁。
- 把直连路径并进小队入口。小队仍是一种入口,循环归内核。
- 下游领域的阶段门禁、文档树和追溯关系。那些留在下游仓。
## 6. 已知待查项
以下来自同一次只读梳理,不在 P0 修改。各自另开任务前先复核当前代码。
- `quality_review` 的工作区路径疑似用了全局根,而文件工具用的是 `<根>/<owner>/<会话>`。单测把根直接设成文件所在目录,可能测不出来。
- 工具确认卡算出了参数预览,但没有放进卡片,用户看不到参数就要批准。
- 小队入口读的是默认 owner 的设置,不是当前租户的。
- 插件宿主 `SettingsSchema` 持读锁时再调用会再次取读锁,中间若有写锁等待,有死锁风险。
## 7. 验收(P0)
- `modules/documents`:本文与路线图第 3 阶段的链接。
- `modules/backend`:`go test ./internal/ctxasm/ ./internal/runtime/ ./internal/prompts/` 通过;随后在 Dev 仓 `make test` 做组合验证。
- 回放用例覆盖:真实工具调用变成原生消息、缺结果时补齐、超长参数仍是合法 JSON、降级文本被跳过、存量伪造标记被剔除、工件正文回填保持不变。
- 守卫用例覆盖:只有伪造标记也会拦截、纠正两次后附系统提示、回灌的是占位文本、引用已存在的工件不算谎称。
@@ -0,0 +1,80 @@
# 基座路线图修正:基座不可改,下游独立仓二次开发
状态:**实施中(2026-10-01)**;owner:weichen;主任务:Dev 仓 `feature/base-extension-roadmap`。
规范依据:Development-Guidelines(workflows/delivery.md、standards/collaboration.md);本文是项目级消费,不复制其正文。
撰写日期:2026-10-01。
---
## 1. 基准
Agent-System 是通用智能体基座:提供入口、能力、接口和基础功能,并能理解需求、对话、完成任务。页面、功能、工具、技能、MCP、知识库等模组通过插件接入。
`~/downloads/agent-system-design`(智能研发管理系统,9 篇文档)是**下游特别系统**。它将在一个或多个独立仓库里二次开发,**不得修改基座**。修改基座的唯一合法理由是新增基础能力或扩展接口,路径为:下游提出扩展点申请 → 基座实现并发版 → 下游升级。
基座只提供引擎、注册点和公开接口。领域数据与领域规则留在下游。延续骨架设计 4.12:知识库是数据,检索引擎是基础设施。
已拍板且本次不推翻的约束:非容器化、单二进制优先;不迁移老系统资产与数据格式;在途 run 不做透明恢复(标记 `interrupted`,用户重发)。
## 2. 原差距清单的处置
对照基准从「两树一网蓝图」改为「通用基座 + 下游不改基座」。原清单编号沿用讨论稿。
### 2.1 留在基座
| 编号 | 项 | 本次落点 |
|---|---|---|
| 3 | 持久化后台任务,与会话锁解耦 | `background_tasks` + `/api/tasks` |
| 5 | 仅 cmdbus 待确认态持久化 | `pending_confirms`;run 仍不透明恢复 |
| 6 | HITL 超时计时 | `AskHITL` 尊重 `TimeoutSec` |
| 8 | 记忆实现 | `memory_entries` + `/api/memory` |
| 9 | 默认可选嵌入 | `models.embedding.provider=hash` 本地档;未设置仍按 D23 退化为全文 |
| 13 | 通用审计(不含领域依据包) | `audit_events` + `/api/audit` |
| 17 | LLM 成本与预算告警 | 日 token 累计,超预算写审计 |
| 20 | 命令双入口对拍 | 每个内置命令必须出现在 `command-pairs.json`,否则测试失败 |
| 22 | logging / error-code 接线 | 启动日志走 `logging-system`;插件失败带 `sys.unavailable` |
| 24 | 依赖边界 lint | `make test-boundaries` 并入 `make test` |
上下文滚动压缩:`summarizeBeyond=true` 时,窗口外历史改为抽取式摘要注入,不再只丢弃。
代码执行:沿用已有解释器沙箱(工作区、超时、`runtime.exec` 开关),不另开无沙箱执行器。
### 2.2 交给下游仓
版本链与三态关系边、两速管道、文档/切片并发编辑、切片标签 schema、加密与 OCR 档位、ABAC 四元组、审计依据包、飞书业务、通知聚合、领域模板与流程骨架、领域评测指标、三套环境与故障注入、领域导出导入,以及设计文档自己的数据模型欠账。
基座只提供这些下游会用到的通用口:渠道声明、知识数据集声明、后台任务、审计写入、插件隔离存储、混合检索。
### 2.3 不采纳
- 容器编排交付(与骨架「非容器、单二进制」冲突)。
- 旧系统资产导入(与「不迁移、不兼容老数据格式」冲突)。
- 为单一领域预造版本链、三态边、时间点重建。出现第二个使用方再上提基座。
## 3. 阶段
1. **公开扩展面与兼容规则**(本提案第 4 节 + 同日兼容提案)。下游今天必须能依赖基座,而不是 fork。
2. **插件契约 v2**(同日插件提案):声明、进程内编译、sidecar、前端 ESM。
3. **智能体质量回路**:后台任务、记忆、上下文摘要、本地嵌入档、HITL 超时、确认态持久化、LLM 预算、通用评测夹具。回合循环、完成判定与多代理编排见 [2026-10-01-agent-harness.md](2026-10-01-agent-harness.md)(P0 起实施,内核下沉到 agent-native)。
4. **工程基座**:日志与错误码、通用审计、边界 lint、命令对拍、会话导出。
目标系统薄切片放在 `examples/downstream-rdm`。它只 import 公开包。独立远程仓库由 owner 另行创建;本次不 `git init` 新仓。
## 4. 公开扩展面(不改模块路径)
后端业务代码继续留在 `internal/`。新增可导入包:
- `agent-system-backend/pkg/extension`:进程内注册、宿主 API 客户端、`Main`。
- `agent-system-backend/pkg/extension/link`:把 `Main` 接到 `app.Run`(仅基座与下游 main 空白导入)。
模块路径保持 `agent-system-backend` / `agent-system-core` / `agent-system-ui`。下游 `go.mod` 用 `replace` 指向检出或 Gitea SSH。改成可直接 `go get` 的路径会打断现有全部 import,留到单独发版任务。
`agent-system-ui` 仍是源码组合(提案 D29:出现第二宿主再发 npm)。本次补上 `exports` 指向的插件 SDK 源文件,不执行 npm 发布。
公开面版本:`extension.SurfaceVersion = 2.0.0-experimental`。契约快照测试锁定导出符号;增删导出必须改快照。
版本 tag 与包发布是高后果操作。准备命令见兼容提案,由 owner 确认后执行。本次不打 tag、不推送。
## 5. 扩展点申请
下游缺能力时开任务卡,写清:调用场景、希望的公开符号或 HTTP 路径、不改基座时的阻碍。基座只在批准后加公开面并发版。下游禁止提交修改 `internal/` 的补丁作为交付。
@@ -0,0 +1,58 @@
# 扩展面兼容与演进
状态:**实施中(2026-10-01)**;owner:weichen;主任务:Dev 仓 `feature/base-extension-roadmap`。
撰写日期:2026-10-01。配套:[基座路线图修正](2026-10-01-base-extension-roadmap.md)、[插件契约 v2](2026-10-01-plugin-contract-v2.md)。
## 1. 版本
| 面 | 标识 | 规则 |
|---|---|---|
| 插件清单 | `apiVersion` | 接受 `1.0` 与 `2.0-experimental`。其他值整包拒绝(fail-closed) |
| 公开 Go 包 | `extension.SurfaceVersion` | `2.0.0-experimental`。实验窗口内允许破坏性调整,但必须改契约快照并在提案里写一句 |
| HTTP API | 路径前缀 `/api/` 与 `/host/v1/` | 已发布路径只加字段,不改语义、不删字段。新能力用新路径 |
弃用:公开符号先标记注释 `Deprecated:`,至少一个下游可升级的版本之后才删除。实验窗口内的删除仍要改快照测试,不能静默。
## 2. 兼容窗口对插件清单的具体含义
- `1.0`:原有 tools/panels/cards/intents/prompts/settings/commands/workspaces 行为不变。`requires.network` 为空时出站仍放行(历史清单没有白名单)。
- `2.0-experimental`:同上,并接受 skills、mcpServers、knowledge、parsers、agents、channels、pages、scope、backend。`requires.network` 为空时 **拒绝** 声明式 HTTP 出站。
新增 JSON 字段一律 `omitempty`,避免 1.0 黄金清单的编码发生变化。
## 3. 契约快照
`modules/backend/pkg/extension/surface_test.go` 用 AST 列出 `pkg/extension` 的导出类型与函数,与 `surface.txt` 比较。CI 通过 `make test`(含 `go test ./...`)执行。未更新快照的导出变更会失败。
依赖边界:`make test-boundaries` 拒绝
- `pkg/extension` 导入 `agent-system-backend/internal`
- 本仓 `examples/` 导入 `agent-system-backend/internal`
## 4. 下游依赖(replace,本次不改模块路径)
```
require agent-system-backend v0.0.0
require agent-system-core v0.0.0
replace agent-system-backend => ../Agent-System-Dev/modules/backend
replace agent-system-core => ../Agent-System-Dev/modules/core
```
后端模块自身的 `replace`(agent-native、logging-system 等)不会被下游继承。下游若编译进 `pkg/extension/link`(会拉起整个后端),需要复制后端 `go.mod` 里的 replace,并把路径改到基座检出。只做声明式插件则不需要 Go 依赖。
## 5. 发版命令(owner 执行,本次未执行)
```
git tag -a v0.2.0-experimental -m "extension surface 2.0.0-experimental"
git push origin v0.2.0-experimental
```
npm 发布 `agent-system-ui` 仍按 D29 推迟到第二宿主出现。不要在实验窗口把 `private` 改成 false 后直接发布。
## 6. 扩展点申请模板
- 场景:哪一个下游仓、哪条用户路径走不通。
- 希望新增的公开符号或 `/api`、`/host/v1` 路径。
- 为何不能用现有注册点、后台任务、审计、KV、命令总线组合出来。
- 兼容:加字段还是新路径。
@@ -0,0 +1,79 @@
# 插件契约 v2
状态:**实施中(2026-10-01)**;owner:weichen;主任务:Dev 仓 `feature/base-extension-roadmap`。
撰写日期:2026-10-01。配套:[路线图](2026-10-01-base-extension-roadmap.md)、[兼容规则](2026-10-01-extension-compat-policy.md)。
## 1. 四种形态
下游按需要选一种或组合。基座对四种形态使用同一份 manifest 与同一套 fail-closed:任一资产解析失败则整包拒绝,保留上一状态。
| 形态 | 下游交付 | 基座职责 |
|---|---|---|
| 声明 | `plugin.json` + 资产目录 | 注册 tools/skills/mcp/knowledge/parsers/agents/channels/pages/commands/… |
| 进程内编译 | 下游 `main` import `pkg/extension` 并 `RegisterCompiled` | `link` + builder 模式产出**下游自己的**单二进制 |
| sidecar | 原生进程,manifest `backend.mode=sidecar` | 拉起、健康(进程存活)、停止;环境变量注入 Host API |
| 前端 ESM | `pages/*.json` 指向模块 | UI SDK 只暴露命令、SSE 与 `@ui` 组件;页面不得另起设计令牌 |
进程内编译适合要事务一致性的领域逻辑。sidecar 适合异构语言或强隔离。声明式 HTTP 工具仍然只描述调用,不携带任意代码。
## 2. manifest 增补
`apiVersion` 用 `2.0-experimental` 才强制网络白名单。字段见 `modules/core/plugin_v2.go`。
- `provides.skills`:`skills/<name>.md`,宿主写入 `<data>/skills/plugin-<id>/`。
- `provides.mcpServers`:并入小队 MCP 配置(与 `tools.mcp.servers` 合并)。
- `provides.knowledge|parsers|agents|channels|pages`:声明登记,供清单 API 与前端加载。
- `scope.tenants/projects`:空 = 全部可见。
- `backend.command`:sidecar 可执行文件(相对插件目录或 PATH)。`schemaVersion` 记入 `plugin_schema`。
密钥查找顺序:`secrets.<pluginId>.<authRef>`(按工具执行时的 `OwnerID`),再回落同名全局设置。不再在绑定期固定读 `OwnerDefault`。
## 3. Host API(sidecar 与外部进程)
监听由基座在本机拉起,令牌随进程环境变量 `AGENT_HOST_API`、`AGENT_HOST_TOKEN` 下发。
| 方法 | 路径 | 作用 |
|---|---|---|
| PUT/GET | `/host/v1/kv/{key}` | 插件隔离 KV(带 owner 与 plugin id) |
| POST | `/host/v1/audit` | 写通用审计 |
| POST | `/host/v1/commands/{id}` | 走命令总线 |
| POST | `/host/v1/llm` | 代理聊天补全;未配置模型返回 503,不静默伪造 |
| GET | `/host/v1/knowledge/search` | 混合检索(引擎在基座) |
插件故障不拖垮基座:sidecar 退出只记日志与审计,不退出主进程。
## 4. 进程内注册
```go
func init() {
extension.RegisterCompiled(extension.InProc{
ID: "rdm",
Register: func(reg extension.Registry) error {
return reg.AddSkill("rdm-note", "# …")
},
})
}
```
下游 main:
```go
import _ "agent-system-backend/pkg/extension/link"
func main() { extension.Main(extension.Options{Addr: "127.0.0.1:8787"}) }
```
## 5. 前端
`@ui` 导出 `createPluginBridge`:`execCommand` 与 `subscribeEvents`。插件页面模块默认导出 `mount(el, bridge)` / `unmount()`。宿主按 `pages[].module` 动态 `import()`。插件 TSX 与基座一样受 design-guard 约束(令牌、无私人 keyframes、无行内字号)。
## 6. 生命周期
- 启用:`POST /api/plugins/{id}/enabled`,按租户记 `plugin_grants`。
- 升级:`backend.schemaVersion` 大于已记录版本时调用宿主迁移钩子(KV 命名空间不清空;钩子由进程内扩展提供)。版本只升不降,降级拒绝装载。
- 管理面:`GET /api/plugins` 返回 manifest(含 v2 provides)以及技能/页面/渠道声明。既有设置页「插件」分组继续承担热重载。
## 7. 开发体验
- `make plugin-new NAME=<id>` 在 `examples/plugins/<id>` 生成声明式骨架。
- `examples/plugins/decl-demo`、`examples/downstream-rdm`、`examples/sidecar-demo`、`examples/page-demo` 各覆盖一种形态。
- 验收:`examples/downstream-rdm` 的测试不导入 `internal`,并由 `make test-boundaries` 卡住。