opensource/proxycast
3
0
Fork 0
mirror of https://github.com/aiclientproxy/proxycast.git synced 2026-09-24 23:10:56 +08:00
Code Issues Packages Projects Releases Wiki Activity

release: v1.10.0

Browse Source
This commit is contained in:
coso
2026-04-13 13:07:08 +08:00
parent 0f15b8a71e
commit bf03e44ac7
273 changed files with 12344 additions and 26363 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/aiprompts/commands.md
+1
View File
@@ -68,6 +68,7 @@
同理，聊天运行时初始化的 `aster_agent_init` 在浏览器 DevBridge 模式下也不能再被放进 `mockPriorityCommands`。只要桥接在线，它就必须优先读取后端真实 `provider_name / model_name`，让聊天入口拿到当前运行时模型。
进一步地，围绕运行时模型解析的真相命令：`aster_agent_init`、`get_default_provider`、`get_provider_pool_overview`、`get_api_key_providers`、`get_model_registry`、`get_provider_alias_config`、`fetch_provider_models_auto`、`get_model_registry_provider_ids`，在浏览器 DevBridge 模式下如果桥接失败，必须直接抛错，不能再通过 `safeInvoke` 静默退回 mock；否则前端会把“后端未连上 / 命令失败”误显示成假的 Provider / 模型列表。
同时要明确，`aster_agent_init` 只负责初始化 Agent，并不保证已经完成 Provider 配置；当它未返回 `provider_name / model_name` 时，前端不得把本地硬编码默认值当作真实模型，而应继续回退到 `get_default_provider` + 已配置 Provider/模型注册表解析链，拿到当前工作区真正可用的 `provider/model`。
同一条约束也适用于 Prompt Cache 能力判断：运行时与前端都不得因为某个自定义 Provider “长得像 Anthropic 协议”就推断它支持官方 Anthropic Automatic Prompt Caching。当前事实源必须继续按 ProviderType 判断：`anthropic` 走自动缓存能力，`anthropic-compatible` 只保留显式 `cache_control` 语义；若上游没有实现 Automatic Prompt Cache，`cached_input_tokens` 为空不能直接归因到 Lime 没发字段。
文档导出链路同样遵循这条路径。当前主入口为 `src/lib/api/document-export.ts`，统一承接：
docs/aiprompts/overview.md
+1
View File
@@ -213,6 +213,7 @@ lime/
### 7. 多 Provider 与兼容层
- OAuth 与 API Key Provider 并存
- 凭证池、模型路由、协议兼容与 HTTP Server 作为底层支撑
- Prompt Cache 等运行时能力按 ProviderType 判断；`anthropic-compatible` 只表示 Anthropic wire format 兼容，不等于自动 Prompt Cache 能力
### 8. 本地优先与可扩展
- 桌面应用、本地工作区、插件与外部工具扩展
docs/aiprompts/playwright-e2e.md
+7 -4
View File
@@ -140,10 +140,13 @@ npm run test:contracts
1. 进入 `设置 -> AI 服务商`
2. 确认默认落在 `服务商设置`，左侧能看到 Provider 列表，右侧是当前 Provider 配置
3. 确认首屏不会默认混入 OEM Offer、套餐或云端模型目录
4. 点击 `云端服务`
5. 确认 OEM 会话、Offer 卡片、默认来源和模型目录改为在该页单独展示
6. 如当前环境故意破坏了 `models/index.json`，确认 Provider 模型区会提示“模型真相源异常”，而不是静默显示空态
3. 如果列表中存在 `anthropic-compatible` Provider，确认左侧会展示 `显式缓存` badge，而不是暗示自动 Prompt Cache
4. 点进该 Provider 后，确认右侧头部仍展示 `显式缓存` badge
5. 进入编辑区后，确认 `Provider 类型 / API Host` 附近会提示“Anthropic 兼容不等于自动 Prompt Cache，需要显式 cache_control”
6. 确认首屏不会默认混入 OEM Offer、套餐或云端模型目录
7. 点击 `云端服务`
8. 确认 OEM 会话、Offer 卡片、默认来源和模型目录改为在该页单独展示
9. 如当前环境故意破坏了 `models/index.json`，确认 Provider 模型区会提示“模型真相源异常”，而不是静默显示空态
### 社媒内容工作流
docs/aiprompts/providers.md
+11 -4
View File
@@ -128,22 +128,29 @@ anthropic-version: 2023-06-01
## Prompt Cache 能力边界
Lime 当前把 Prompt Cache 能力视为 **Provider 类型能力**，而不是“请求长得像哪家协议”：
Lime 当前把 Prompt Cache 能力视为 **Provider 显式声明优先、类型默认兜底**，而不是“请求长得像哪家协议”：
- `anthropic` / `claude` / `claude-oauth`：声明为 `automatic`
- `anthropic-compatible`：声明为 `explicit_only`
- `anthropic` / `claude` / `claude-oauth`：默认 `automatic`
- `anthropic-compatible`：默认 `explicit_only`，但自定义 Provider 可显式声明为 `automatic`
- 其它 Provider：默认 `not_applicable`
前台提示层额外保留一个**已知官方 Host 例外**：
- 对 `https://open.bigmodel.cn/api/anthropic` 这类智谱官方 Anthropic 兼容 Host，Lime 前台不再把它误报成“仅显式缓存”
- 这只影响 UI 提示与 badge 收口，不代表 Lime 会把该 Host 直接等同于 Anthropic `cache_control` 自动注入语义
这条事实源当前收敛在：
- 前端：`src/lib/model/providerPromptCacheSupport.ts`
- 后端：Provider 类型与运行时能力判断链
- 模型注册表映射：只负责 provider/model 目录归一，不参与 Prompt Cache 能力推断
需要特别注意：
1. `anthropic-compatible` 只表示接入方兼容 Anthropic wire format，不等于上游已经实现 Anthropic Automatic Prompt Caching
2. Lime 不会因为某个自定义渠道“长得像 Anthropic”就默认把它当成官方 Anthropic 自动缓存能力
3. 对 `anthropic-compatible` 渠道，Lime 只保留显式 `cache_control` 语义；如果上游没有实现 Automatic Prompt Cache，`cached_input_tokens` 为空不能直接归因到 Lime 没发字段
3. 对自定义 `anthropic-compatible` 渠道，只有在上游明确声明支持 Automatic Prompt Cache 时才应配置为 `automatic`
4. 若未声明自动缓存，Lime 只保留显式 `cache_control` 语义；如果上游没有实现 Automatic Prompt Cache，`cached_input_tokens` 为空不能直接归因到 Lime 没发字段
排查这类问题时，优先确认三件事：
docs/aiprompts/quality-workflow.md
+9
View File
@@ -96,6 +96,7 @@
- 优先补现有 `*.test.tsx` 的关键文案、状态与交互断言
- 如果目标区域已有 snapshot / 结构化快照机制，沿用现有机制
- 不要因为“只是 UI”就跳过回归
- 如果改动涉及 Provider 类型切换、Prompt Cache 提示或模型/协议能力认知，至少补到“列表扫描态、详情头部、创建/编辑入口、聊天发送前或结果解释”中的实际受影响落点，避免同一语义只在单点出现
### 4. 配置与依赖改动必须成组提交
@@ -198,6 +199,8 @@ node scripts/check-generated-slop-report.mjs --input "<cleanup-json>"
同时，`scripts/report-generated-slop.mjs`、`scripts/check-generated-slop-report.mjs`、`scripts/harness-eval-history-record.mjs`、`scripts/harness-eval-trend-report.mjs`、`scripts/lib/generated-slop-report-core.mjs`、`scripts/lib/harness-dashboard-core.mjs` 这条 harness cleanup/report 主链，在 `verify:local` 的 smart 模式里默认也按 bridge/contracts 风险处理。
本地 `verify:local` 输出里如果看到 `bridge 校验（harness cleanup contract）`，说明命中的就是这条 cleanup/report 契约门禁，而不是普通 DevBridge 变更。
CI 里的 `.github/workflows/quality.yml` 结果摘要现在也会透出 `bridge_reasons`，并写入 `GITHUB_STEP_SUMMARY`，用于区分这次是 `harness_cleanup_contract`、`bridge_runtime`，还是 `workflow_full_suite` / `fallback_full_suite` 这类全量触发。
结果摘要默认按 `Scope / Required Gates / Notes / Recommended Next Action / Failure` 分段，优先让人一眼看清“为什么触发”“哪些门禁必跑”“最终为什么失败”，以及失败后本地最应该先跑哪条命令。
如果命中的是 `harness_cleanup_contract`，推荐动作应优先指向 `npm run harness:cleanup-report:check`，而不是只给一条泛化的 bridge 校验建议。
作用：
@@ -460,6 +463,12 @@ CI 里的 `.github/workflows/quality.yml` 结果摘要现在也会透出 `bridge
- 资源索引损坏时，GUI 会明确提示“模型真相源异常”
- 不会再静默回退数据库或把错误伪装成空模型列表
如果本轮修改了 Provider 类型与 Prompt Cache 能力边界，还应额外确认：
- `anthropic-compatible` 不会再被 UI 或运行时误显示成“自动 Prompt Cache”
- Provider Pool 的列表、详情、创建和编辑入口中，受影响落点会继续提示“显式 cache_control”
- 聊天侧 `ModelSelector / Inputbar / MessageList / TokenUsageDisplay` 与 Provider Pool 的口径保持一致
### Layer 4：交互型 E2E
入口：
docs/aiprompts/terminal.md
+9 -33
View File
@@ -1,8 +1,8 @@
# 内置终端
# 终端底层能力
## 概述
内置终端模块提供 PTY 管理和会话管理功能。
Lime 仍保留终端底层能力，用于复用运行时、诊断与会话管理；独立前端 `terminal / sysinfo / files / web` 页面已经下线，不再保留 `src/components/terminal/` 页面模块。
## 目录结构
@@ -13,9 +13,11 @@ src-tauri/src/terminal/
├── session.rs # 会话管理
└── commands.rs # 终端命令
src/components/terminal/
├── Terminal.tsx # 终端组件
└── TerminalTabs.tsx # 多标签管理
src/lib/api/terminal.ts
src/lib/terminal/
├── store/ # 终端状态与输入态
├── stickers/ # 终端贴纸状态
└── vdom/ # VDOM 状态与类型
```
## PTY 管理
@@ -49,35 +51,9 @@ impl PtyManager {
}
```
## 前端组件
## 前端边界
```tsx
// src/components/terminal/Terminal.tsx
export function Terminal({ sessionId }: { sessionId: string }) {
const termRef = useRef<HTMLDivElement>(null);
const xtermRef = useRef<XTerm>();
useEffect(() => {
const xterm = new XTerm();
xterm.open(termRef.current!);
xtermRef.current = xterm;
// 监听输出
listen(`terminal-output-${sessionId}`, (event) => {
xterm.write(event.payload);
});
// 发送输入
xterm.onData((data) => {
invoke('terminal_write', { sessionId, data });
});
return () => xterm.dispose();
}, [sessionId]);
return <div ref={termRef} className="h-full" />;
}
```
前端当前只允许通过 `src/lib/api/terminal.ts` 和 `src/lib/terminal/*` 复用终端会话、事件和状态能力，不再新增独立页面壳。
## Tauri 命令
docs/content/01.introduction/2.installation.md
+1 -1
View File
@@ -59,7 +59,7 @@ Lime 当前仅提供 macOS 与 Windows 桌面端安装包，Linux 版本已暂
启动 Lime 后，你应该看到：
1. 主窗口正常打开
2. 左侧出现主要入口（AI Agent、项目、资源、图片生成等）
2. 左侧出现主要入口（AI Agent、项目、资源、设置等）
3. 可以进入设置页并看到版本信息
## 常见安装问题
docs/content/01.introduction/3.quickstart.md
+3 -3
View File
@@ -26,7 +26,7 @@ navigation:
1. 用一句话描述你的目标
2. 让 Agent 先给结构，再生成首稿
3. 如需视觉内容，进入图片生成功能继续产出与迭代
3. 如需视觉内容，在 AI Agent 中用 `@素材` 搜图或触发图片生成，再把结果沉淀到资源库
## 步骤 3：沉淀到资源库
@@ -51,7 +51,7 @@ navigation:
### 我可以直接改图吗？
可以。上传参考图后，若所选模型支持编辑接口，会自动走编辑链路。
可以。先在资源库上传参考图，再从 Claw 发起图片任务；若所选模型支持编辑接口，会自动走对应链路。
### 我还需要排查底层协议怎么办？
@@ -61,4 +61,4 @@ navigation:
- [首页与工作台](/user-guide/dashboard) - 理解核心导航
- [资源库](/user-guide/resources) - 管理创作资产
- [图片生成与编辑](/user-guide/image-generation) - 深入图片链路
- [图片生成与素材链路](/user-guide/image-generation) - 理解 Claw 与资源页如何协同
docs/content/02.user-guide/1.dashboard.md
+2 -3
View File
@@ -15,15 +15,14 @@ navigation:
- **AI Agent**：对话、任务推进、内容初稿
- **项目**：按创作目标管理长期内容
- **资源**：统一查看文档、图片、语音、视频
- **图片生成**：生成图片、参考图编辑、结果回流资源库
- **设置**：调整主题、模块开关、连接与高级选项
## 推荐工作方式
1. 先在项目中选择一个主题方向
2. 在 AI Agent 中完成结构和首稿
3. 需要视觉时进入图片生成
4. 回到资源库统一管理结果
3. 需要视觉时在 AI Agent 中使用 `@素材` 或图片任务
4. 回到资源库统一管理本地图片、图库素材与回流结果
## 主题方向
docs/content/02.user-guide/12.settings.md
+2 -2
View File
@@ -23,7 +23,7 @@ navigation:
你可以按使用习惯定制入口：
- 启用或停用工作区主题（如社媒、短视频、小说）
- 启用或停用导航模块（如 AI Agent、项目、图片生成、终端、工具、插件）
- 启用或停用导航模块（如 AI Agent、项目、资源、设置、插件）
这样可以让侧边栏更聚焦，减少干扰。
@@ -49,7 +49,7 @@ navigation:
### 个人创作者
- 保留：AI Agent、项目、资源、图片生成
- 保留：AI Agent、项目、资源
- 关闭：暂时不用的高级模块
- 目的：让工作台聚焦在“日常产出”
docs/content/02.user-guide/14.resources.md
+8 -2
View File
@@ -41,9 +41,15 @@ navigation:
## 资源与创作联动
### 从图片生成回流资源库
### 从 Claw 与图片任务回流资源库
在图片生成页选择目标资源库后，成功生成的图片可自动写入当前项目。
在 Claw 中发起图片生成任务，或从图片任务结果执行入库后，成功生成的图片会自动写入当前项目。
资料库的图片视图还统一承接：
- 本地图片上传
- 我的图片库浏览
- 选图后插入当前画布
### 从资源继续对话创作
docs/content/02.user-guide/15.image-generation.md
+46 -25
View File
@@ -1,55 +1,76 @@
---
title: 图片生成与编辑
description: 通过文本与参考图完成图片生成、编辑与资产沉淀
title: 图片生成与素材链路
description: 通过 Claw 与资源库完成搜图、图片生成、编辑与资产沉淀
navigation:
icon: i-heroicons-photo
---
# 图片生成与编辑
# 图片生成与素材链路
图片生成页用于完成从“文字描述”到“可用图片素材”的全过程。
Lime 不再把图片能力拆成独立页面。
现在的事实源是：
- Claw：负责联网搜图、图片生成、参考图编辑和任务推进
- 资源库：负责本地图片上传、我的图片库浏览、结果沉淀和插图复用
- 设置：负责图片模型、Provider 与联网搜图 Key 配置
## 基本流程
1. 选择模型与参数（尺寸、比例、数量）
2. 输入提示词
3. 可选上传参考图
4. 生成后选图并沉淀到资源库
1. 在 AI Agent 中明确视觉目标
2. 需要找参考图时，用 Claw `@素材` 进行联网搜图
3. 需要生成或编辑图片时，在 Claw 发起对应图片任务
4. 结果自动或手动沉淀到资源库
5. 在资源库图片视图继续筛选、上传、插图或复用
## 参考图与编辑
## 联网搜图与生成
### 上传参考图
### 联网搜图
可上传参考图作为创作输入，帮助模型更贴近目标风格或构图。
当你需要灵感图、风格参考或可复用素材时：
### 编辑链路
- 在 Claw 中使用 `@素材`
- 联网图片搜索结果会以任务结果或素材候选的形式返回
- 选中的图片可以继续进入正文插图、封面或图片任务链路
当模型支持图片编辑接口时，系统会优先尝试编辑端点；
若不可用，会自动回退到可用生成端点，尽量保障出图成功率。
### 图片生成与编辑
## 历史记录
当你已经明确提示词或参考图后：
历史区域会保存你的生成记录，支持：
- 在 Claw 发起图片生成任务
- 如模型支持参考图编辑，系统会优先走编辑链路
- 若某条接口不可用，运行时会回退到可用生成链路，尽量保障出图成功率
- 查看单张或批次结果
- 重新选择目标图继续迭代
- 将历史结果补录到资源库
## 本地图片与我的图片库
本地图片与历史沉淀图片已经统一收口到资源库图片视图，你可以在这里：
- 上传本地图片
- 浏览“我的图片库”
- 选图后直接插入当前画布
- 在当前项目下统一管理图片资产
## 与资源库联动
### 目标资源库
### 结果回流
生成前可指定目标资源库（项目），用于自动沉淀图片资产。
图片任务会根据当前项目和资源库选择自动回流；如果需要，也可以在结果完成后再手动入库。
### 补录历史
### 插图复用
如果历史图片尚未入库，可使用“补录历史到资源库”进行批量回填。
进入资源库的图片可以直接被当前画布复用，不需要再回到旧图片页面挑选。
## 配置入口
相关配置分布在两个位置：
- 图片模型与默认策略：设置中的媒体服务配置
- 联网图片搜索 Key：设置中的网络搜索配置
## 实用建议
### 先定方向再出图
先在 AI Agent 里明确画面目标，再进入图片生成功能，会减少无效尝试。
先在 AI Agent 里明确画面目标，再决定是 `@素材` 搜图还是直接发起图片任务，会减少无效尝试。
### 一次只改一个变量
@@ -57,4 +78,4 @@ navigation:
### 把可用版本及时入库
选中可用图片后尽快入库，方便后续在资源页检索和复用。
选中可用图片后尽快入库，方便后续在资源页检索、插图和复用。
docs/content/05.troubleshooting/1.common-issues.md
+2 -2
View File
@@ -48,8 +48,8 @@ navigation:
### 处理建议
- 回到图片生成页确认目标资源库
- 对历史结果执行“补录到资源库”
- 先确认当前项目与资源库选择一致
- 回看 Claw 中对应图片任务是否已经成功并完成入库
- 回资源页切换“全部”核对总量
## 生成失败或超时
docs/content/index.md
+2 -2
View File
@@ -7,7 +7,7 @@ navigation: false
# Lime 文档中心
Lime 是创作类 AI Agent 平台。
你可以在同一个工作台里完成对话、创作、图片生成、项目沉淀与资源复用。
你可以在同一个工作台里完成对话、创作、Claw 素材与图片任务、项目沉淀和资源复用。
## 从这里开始
@@ -34,7 +34,7 @@ Lime 是创作类 AI Agent 平台。
- [首页与工作台](/user-guide/dashboard)
- [资源库](/user-guide/resources)
- [运行时 AGENTS 规则](/user-guide/runtime-agents)
- [图片生成与编辑](/user-guide/image-generation)
- [图片生成与素材链路](/user-guide/image-generation)
- [设置](/user-guide/settings)
- [插件中心](/user-guide/plugins)
docs/roadmap/harness-engine/README.md
+395
View File
@@ -0,0 +1,395 @@
# Lime Harness Engine 对照路线图与长期检查表
> 状态：进行中，P0 已完成首刀收口
> 更新时间：2026-04-13
> 对照基线：LangChain 博文《The Anatomy of an Agent Harness》
> 目标：把 Lime 当前已经具备的 Harness 能力、真实缺口、后续建设优先级和长期复查口径收敛到一份可执行文档，而不是继续停留在抽象口号层。
配套图纸：
- `docs/roadmap/harness-engine/diagrams.md`
## 1. 先给结论
按 LangChain 这篇文章的标准看，Lime **已经不是“只有模型壳”的产品**，而是已经具备较完整 Harness 底座的 Agent 工作台。
但更准确的判断不是“已经完全成熟”，而是：
- **底座型 Harness：已基本成形**
- **闭环型 Harness：仍是部分完成**
- **长时自治型 Harness Engine：还没有完全收口**
一句话总结：
**Lime 当前最大的短板，不是“没有工具”或“没有运行时”，而是“证据闭环、长期执行闭环、动态装配闭环还不够强”。**
---
## 2. 本文使用的判断标准
LangChain 这篇文章把 Harness 定义为：
> 模型之外的一切代码、配置、执行环境、工具、约束、状态与编排逻辑。
因此本文不只看 prompt，也不只看 tool 数量，而是按下面这些维度对 Lime 做判断：
1. 系统提示词与规则注入
2. 文件系统与 durable state
3. Bash / code execution
4. sandbox / approval / execution policy
5. tools / skills / MCP / browser runtime
6. memory / search / AGENTS 注入
7. context rot 治理
8. long-horizon execution
9. verification / replay / review / evidence
10. just-in-time tool/context assembly
11. trace-driven harness self-improvement
---
## 3. Lime 当前总判断
### 3.1 已经成立的部分
Lime 当前已经明确具备以下 Harness 基础设施：
- system prompt 与 memory prompt 注入
- workspace / filesystem / artifact 持久化边界
- bash 与通用代码执行入口
- sandbox / approval / restriction profile
- skills / MCP / browser / workspace tools
- 子代理委派、handoff、evidence、replay 基础链
- context compaction、tool output compression、tool io offload
这说明 Lime 的主问题已经不是“缺零件”，而是“怎样把这些零件收敛成更强的闭环”。
### 3.2 仍然偏弱的部分
Lime 当前仍然缺少下面三类关键闭环：
1. **证据闭环不够强**
`runtime -> evidence -> verification outcome -> review -> regression -> promote`
这条链已经有雏形，但还没有形成默认强约束。
2. **长时执行闭环不够强**
当前已有 queue / resume / provider continuation / auto continue / subagent，但还没有把“任务未完成时必须继续推进到完成标准”变成统一的 runtime 纪律。
3. **动态装配闭环不够强**
当前有 catalog、surface、skill progressive disclosure，但 tool/context 仍偏“预配置”，而不是更强的 per-turn JIT 组装。
---
## 4. 对照矩阵
| LangChain Harness 能力 | Lime 当前状态 | 当前事实源 | 结论 |
| ------------------------------------- | ------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| System Prompts / 规则注入 | 已落地 | `src-tauri/src/services/memory_profile_prompt_service.rs`、`src-tauri/src/services/memory_source_resolver_service.rs` | Lime 已把 profile、memory source、project rule 注入到 system prompt 主链，不是裸 prompt 模式 |
| Filesystem / Durable Storage | 已落地 | `docs/aiprompts/overview.md`、`src-tauri/src/commands/aster_agent_cmd/tool_runtime/workspace_tools.rs` | Workspace、artifact、项目目录、文件工具都已经进入主链 |
| Bash / Code Execution | 已落地 | `src-tauri/src/agent_tools/catalog.rs`、`src-tauri/src/agent_tools/execution.rs` | Lime 已具备通用执行能力，不依赖“预先定义完所有工具” |
| Sandbox / Approval / Policy | 已落地 | `src-tauri/src/agent_tools/execution.rs`、`docs/aiprompts/commands.md` | restriction profile、sandbox profile、warning policy 都已进入 runtime 主链 |
| Tools / Skills / MCP / Browser | 已落地 | `docs/aiprompts/skill-standard.md`、`docs/aiprompts/command-runtime.md`、`src-tauri/src/agent_tools/catalog.rs` | Lime 已有较完整 capability surface，不是单一 chat tool 模型 |
| Memory / Search / AGENTS 注入 | 已落地 | `src-tauri/src/services/memory_source_resolver_service.rs`、`docs/aiprompts/overview.md` | 记忆与规则文件已进入生产链，Web/MCP/search 也已存在 |
| Context Rot 治理 | 部分落地 | `src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs`、`src-tauri/crates/aster-rust/crates/aster/src/context_mgmt/mod.rs`、`src-tauri/crates/agent/src/tool_io_offload.rs`、`src-tauri/crates/aster-rust/crates/aster/src/context/compressor.rs` | 已有 compact、tool output compression、tool offload，但产品侧可见性与默认治理还不够强 |
| Long-Horizon Execution | 部分落地 | `src-tauri/src/commands/aster_agent_cmd/runtime_turn.rs`、`src-tauri/src/commands/aster_agent_cmd/tool_runtime/subagent_tools.rs`、`src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs` | 已有 auto continue、provider continuation、subagent、queue/resume，但还没形成统一 completion loop |
| Verification / Replay / Review | 部分落地 | `docs/aiprompts/harness-engine-governance.md`、`src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs`、`src/lib/agentRuntime/harnessVerificationPresentation.ts`、`src-tauri/src/services/runtime_review_decision_service.rs` | evidence / replay / analysis / review 已成链；前端 verification 展示语义已收敛到共享 helper，review template 也开始直接携带同一份 structured verification summary，但验证结果尚未成为所有后续动作的默认硬约束 |
| Just-in-Time Tool / Context Assembly | 待加强 | `src-tauri/src/agent_tools/catalog.rs`、`docs/aiprompts/skill-standard.md`、`docs/aiprompts/command-runtime.md` | 已有 surface/profile/skill progressive disclosure，但仍偏静态 catalog，不够按任务即时裁剪 |
| Trace-Driven Harness Self-Improvement | 待建设 | `docs/aiprompts/harness-engine-governance.md`、现有 evidence/replay/export 主链 | 已经具备取证底座，但还未形成“基于 trace 自动发现缺口并推进治理”的稳定平台能力 |
---
## 5. 关键事实源与它们分别证明了什么
### 5.1 Prompt / Memory / Rules
- `src-tauri/src/services/memory_profile_prompt_service.rs`
证明 Lime 已把用户画像与 memory prompt 合并进 system prompt，而不是只靠前端临时拼接。
- `src-tauri/src/services/memory_source_resolver_service.rs`
证明 Lime 已支持 user memory、durable memory、project rule、多层目录记忆来源解析。
### 5.2 Workspace / Tool Surface / Execution
- `src-tauri/src/agent_tools/catalog.rs`
证明 Lime 已有 tool catalog、surface profile、capability、lifecycle、permission plane 这些 Harness 级抽象。
- `src-tauri/src/agent_tools/execution.rs`
证明 Lime 已把 warning policy、restriction profile、sandbox profile 做成统一执行策略，而不是 scattered 规则。
- `src-tauri/src/commands/aster_agent_cmd/tool_runtime/workspace_tools.rs`
证明 workspace tool 不只是文件读写，还承担 output summary、metadata、observability 编码职责。
### 5.3 Skills / Scene / Browser / MCP
- `docs/aiprompts/skill-standard.md`
证明 Lime 对 skill 的理解已经是 bundle，而不是单一 Markdown 提示词。
- `docs/aiprompts/command-runtime.md`
证明 Lime 已把 `@`、`/`、`scene`、`ServiceSkill`、tool/runtime binding 做成明确产品主链。
- `docs/aiprompts/overview.md`
证明 browser runtime、plugin、MCP、terminal、artifact、workspace 都已进入总架构。
### 5.4 Context Rot / Offload / Continuation
- `src-tauri/src/commands/aster_agent_cmd/command_api/runtime_api.rs`
证明 Lime 已有 `agent_runtime_compact_session`、resume thread、thread read model、evidence export 这类 runtime 操作主链。
- `src-tauri/crates/aster-rust/crates/aster/src/context_mgmt/mod.rs`
证明 Aster 已有 continuation message 与 compact 后续写逻辑，Lime 不是完全没有 continuation。
- `src-tauri/crates/aster-rust/crates/aster/src/context/compressor.rs`
证明 tool output 已有 head/tail compression。
- `src-tauri/crates/agent/src/tool_io_offload.rs`
证明 Lime 已有通用 tool arguments/results offload、preview、eviction policy 与 `offload_file` 协议。
- `src-tauri/src/commands/aster_agent_cmd/runtime_turn.rs`
证明 Lime 已有 auto continue、provider continuation state 恢复与 runtime 级 continuation 配置。
### 5.5 Evidence / Replay / Review / UI
- `docs/aiprompts/harness-engine-governance.md`
证明 Lime 已明确要求 evidence pack 作为事实源，replay / analysis / review / UI 都应复用它。
- `src/lib/agentRuntime/harnessVerificationPresentation.ts`
证明前端 verification label / variant / description 已开始从 `HarnessStatusPanel` 本地解释收敛到共享 helper，GUI 消费层不再各自维护一套语义。
- `src-tauri/src/services/runtime_review_decision_service.rs`
证明 review decision 模板不再只携带 failure / recovered 文本列表，而开始直接透传 structured verification summary，review 消费层可以继续复用 evidence 同一份事实。
- `src/components/agent/chat/components/HarnessStatusPanel.tsx`
证明前端已经能消费 evidence pack，并开始在 evidence / review 两个消费面直接复用共享 verification presentation helper；但展示仍偏状态卡，不是完整治理闭环。
---
## 6. 当前进度看板
### 6.1 按能力维度统计
- 已落地：6 项
- 部分落地：3 项
- 待加强：1 项
- 待建设：1 项
### 6.2 按建设层次统计
| 层次 | 当前状态 | 说明 |
| ------------ | -------- | ------------------------------------------------------------------------------------ |
| 底座层 | 高 | prompt、memory、workspace、tool、sandbox、subagent、artifact 都已进入现役主链 |
| 运行时治理层 | 中高 | catalog、execution policy、compact、offload、evidence 已存在，但默认动作链还不够统一 |
| 闭环验证层 | 中 | replay / review / evidence 已有，verification outcome 到修复决策还不够强绑定 |
| 长时自治层 | 中 | continuation / queue / resume / subagent 已有，但 completion loop 仍偏弱 |
| 自我改进层 | 低 | 已能导出 trace 和证据，但还没有稳定的 trace-driven governance 平台 |
### 6.3 本文建议的总体评级
- **当前阶段评级：B**
- **更准确描述：Harness 底座较强，闭环能力中等，自治能力未完全收口**
### 6.4 本轮已落地
- `agent_runtime_export_evidence_pack` 现已把 `observabilitySummary` 直接返回到前端消费层，而不再只埋在导出文件里。
- `observabilitySummary.verificationSummary` 现已补充显式 outcome，以及失败 / 恢复焦点列表。
- `HarnessStatusPanel` 现已开始直接展示验证结果、失败焦点和恢复结果，不再只显示 `known_gaps`。
- `analysis handoff` 现已开始显式携带 verification failure / recovered outcomes，外部诊断不再只看到 gap signals。
- `review decision` 模板现已复用 analysis-context 里的 verification failure / recovered outcomes，人工审核不再只靠简报文字猜测。
- `runtime_review_decision_service` 现已补上定向回归测试，覆盖“非空 recovered outcomes 从 evidence / analysis 透传到 review decision”的主链守卫，避免 review 层退回空结果假绿。
- `harness-eval-runner` 现已把 `currentRecoveredObservabilityVerificationOutcomes` 与 `currentRecoveredVerificationCaseCount` 作为 summary 一级事实导出，trend / cleanup / dashboard 不再只能从 `currentObservabilityVerificationOutcomes` 二次筛 recovered。
- `harness-eval-history-record` 现已优先复用 `summary.breakdowns/totals` 与 `trend.classificationDeltas/latest.totals` 里的 verification facts 来写入 failure / recovered 摘要，只把 cleanup 保留为兼容兜底，不再让历史记录层反向依赖 cleanup 作为事实源。
- `scripts/lib/harness-verification-facts.mjs` 现已成为 cleanup core / history record / dashboard 共用的 verification role 判定边界，`blocking_failure / advisory_failure / recovered` 不再在多个脚本里各自维护一套常量与判断。
- `harness-dashboard-core` 现已优先直接消费 `trend.classificationDeltas/latest.totals` 与 `summary.breakdowns` 来渲染 verification 统计卡和 focus table，只把 cleanup 保留给 recommendations / governance / doc freshness 这些真正属于 cleanup 的派生面。
- `generated-slop-report-core` 现已把 verification focus 选择、current/degraded/recovered 切分和 summary 组合收回 `harness-verification-facts` 共享 helper，不再在 cleanup core 内部重复维护一套“从 trend classification deltas 推导 verification 视图”的本地逻辑。
- `generated-slop-report-core` 中原本私有的 verification follow-up 规则，现也已收回 `scripts/lib/harness-verification-facts.mjs` 共享 helper；cleanup recommendation 只负责编排 P0/P1/P2 动作，不再自己维护 `guiSmoke/browserVerification/artifactValidator` 的补证据与回归语义。
- `harness-eval-history-record` 现在也已改为复用 `scripts/lib/harness-verification-facts.mjs` 的共享推导来生成 failure focus、current recovered baseline 和 case counts；history-record 不再自己维护一套 failure/recovered 焦点挑选与 cleanup fallback 计数逻辑。
- `harness-dashboard-core` 现在也已改为复用 `scripts/lib/harness-verification-facts.mjs` 的共享推导来生成 verification focus rows、current recovered baseline 与说明文案；dashboard 不再自己维护一套“trend / summary / cleanup 三选一”的 verification 视图拼装逻辑。
- `generated-slop-report-core` 的 signals / text output 现在也已改为复用 `scripts/lib/harness-verification-facts.mjs` 的共享 compact formatter；cleanup report 不再自己手写 `signal (outcome)` 标签格式，避免 recommendation、signals、dashboard 三处名称再度漂移。
- `generated-slop-report-core` 的 verification summary signals 现在也已改为复用 `scripts/lib/harness-verification-facts.mjs` 的共享 summarizer；cleanup 不再自己维护 failure / advisory / recovered / degraded baseline 的摘要句式，避免 signals、review 口径和后续展示再次漂移。
- `generated-slop-report-core` 的 recommendation rationale 里涉及 verification 的 blocking / advisory / recovered 摘要片段，现也已改为复用 `scripts/lib/harness-verification-facts.mjs` 的共享 builder；cleanup recommendation 不再自己维护 verification 解释句模板。
- `generated-slop-report-core` 的 `observability-evidence-follow-up` 里原本混合 verification / observability 的 rationale 与 backlog 文案，现也已改为复用 `scripts/lib/harness-verification-facts.mjs` 的共享 builder；cleanup recommendation 进一步退回“只编排、不解释”的消费层角色。
- `src/lib/agentRuntime/harnessVerificationPresentation.ts` 现已成为前端 verification label / badge / description 的共享展示边界，`HarnessStatusPanel` 不再自己维护 `blocking_failure / advisory_failure / recovered` 的中文文案与说明句式。
- `analysis-brief.md` 现已直接从 `observability.summary.verificationSummary` 生成紧凑的结构化验证摘要，外部 AI 先读 brief 时就能看到 `Artifact / Browser / GUI Smoke` 的同源 outcome 与统计，不必等到再下钻 `analysis-context.json`。
- `runtime_review_decision_service` 现已把 `analysis-context.json` 中的 structured verification summary 一并透传到 review template / review-decision.json，review 面不再只剩 failure / recovered 文本列表。
- `runtime_review_decision_service` 现已开始基于 `verification_summary + failure/recovered outcomes` 预填 review template 的默认 `followup_actions / regression_requirements`；阻塞失败会直接回挂到 replay / evidence / browser / GUI smoke 等默认动作，而不是继续留空等人工从零编排。
- `runtime_review_decision_service` 现已把 review template 默认动作进一步收口到 verification facts 共享语义：Artifact / Browser / GUI Smoke 的 follow-up 与 regression requirement 现在直接镜像 cleanup helper 的动作链，review 不再继续维护另一套手写句式。
- 前端 tauri mock、API 归一化测试与 `HarnessStatusPanel` 现也已对齐这组 facts-based 默认动作，浏览器 mock / 本地 UI 回归不再停留在“review 模板始终空白动作”的旧语义。
- `HarnessStatusPanel` 的 review decision 区块现已与 evidence pack 区块复用同一段 verification summary 展示，不再在 review 面再维护一套独立的 verification UI 解释。
- `RuntimeReviewDecisionDialog` 现已直接复用同一份 `HarnessVerificationSummarySection`，reviewer 在真正填写审核结论时看到的 verification facts 与 evidence / review 面板保持同源，不再在对话框里丢失事实基线。
- `review-decision.md` 现已直接从 `verification_summary` 生成紧凑的结构化验证摘要，人工审核产物本身也能看到 `Artifact / Browser / GUI Smoke` 的同源 outcome 与统计，不再只剩 failure / recovered 文本列表。
这意味着 Phase A 已从“只有 evidence 文件里有事实”推进到“evidence、analysis、review、GUI 展示开始共享同一份 verification facts”。
---
## 7. 最关键的缺口，不要再发散
### 缺口 1：Verification 还没有真正控制后续动作
当前 Lime 已有：
- evidence pack
- replay case
- analysis handoff
- review decision template
- GUI smoke / contracts / quality workflow
但仍缺：
- 统一的 verification outcome 模型，直接控制 review / promote / cleanup 优先级
- 失败后默认回挂到“补验证 / 重放 / 修复 / 再验证”的固定动作链
- promote / queue continuation / runtime action executor 还没有直接消费这组 outcome，verification 仍未真正成为统一动作调度器
这意味着 Lime 已经能“看见问题”，但还没有完全做到“看见问题以后所有后续动作都按同一事实推进”。
### 缺口 2：Long-horizon completion loop 还不够硬
当前 Lime 已有：
- queue / resume
- subagent runtime
- provider continuation
- auto continue
- compact / overflow recovery
但仍缺：
- 明确的 completion goal 与 exit criteria
- 更强的“未完成不得退出”统一 runtime 纪律
- 长任务中计划、验证、恢复、交接的标准化闭环
这意味着 Lime 现在更像“支持长任务”，还不完全像“强约束地把长任务做完”。
### 缺口 3：Tool / Context 仍偏静态装配
当前 Lime 已有：
- tool surface profile
- skill progressive disclosure
- command runtime 场景分型
- scene / ServiceSkill / browser assist 等收口规则
但仍缺：
- per-turn 动态组装工具面
- 基于任务类型裁剪 detour tools 的统一机制
- evidence 驱动的动态上下文注入，而不是更多静态预配
这意味着 Lime 已经知道“哪些能力存在”，但还没有稳定做到“当前任务只拿到真正需要的那一组能力和上下文”。
---
## 8. 接下来只优先做这 3 件事
### P0：把 Verification Outcome 提升成 Harness 一级事实
目标：
- 让 `evidence pack -> replay -> analysis -> review -> cleanup -> dashboard -> UI` 全部消费同一份 verification outcome
最低动作：
- 统一 verification outcome 字段，不允许下游自己再拼第二套真假判断
- 区分 `current gap`、`degraded gap`、`not_applicable`
- 让 review / promote / cleanup 的推荐动作只基于同一份 outcome 计算
完成标准：
- 同一线程的 failure / recovered / advisory 状态，在 evidence、review、cleanup、UI 中不再出现语义漂移
### P1：把 Long-Horizon 执行从“支持”升级为“约束”
目标：
- 让 Lime 对复杂任务不只是“可以继续”，而是“默认会继续直到满足完成标准”
最低动作：
- 给复杂任务补 completion goal / done criteria
- 把 auto continue、provider continuation、queue resume、subagent handoff 接成统一策略
- 让中断、恢复、交接、继续执行都能回挂到同一条 runtime 事实链
完成标准：
- 长任务出现暂停、压缩、续跑、交接时，仍能在同一 session 语义内解释“还差什么、为什么继续、何时结束”
### P2：把 Tool / Context 装配从 catalog 驱动升级为 task 驱动
目标：
- 让 runtime 在发起 turn 时更像“装配能力包”，而不是“打开一个大工具箱”
最低动作：
- 按任务类型定义基础 tool surface 模板
- 对图片、浏览器、站点、分析、转写、研究等场景，建立 detour tool 剔除规则
- 把 skill、memory、browser preload、verification context 统一成更强的 JIT 注入模型
完成标准：
- 当前任务不再默认暴露明显无关的 tool，且上下文噪音可被稳定压低
---
## 9. 分阶段演进路线
| 阶段 | 目标 | 状态 | 备注 |
| ------- | ----------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Phase A | Harness 事实源收敛 | 进行中 | `evidence pack / replay / analysis / review` 已成链；verification summary 已回挂到前端导出结果、状态面板与 review template，`HarnessStatusPanel` 的 evidence / review verification 展示语义也已收敛到 `src/lib/agentRuntime/harnessVerificationPresentation.ts`，review decision 已补 structured summary 透传，eval runner 也已导出 current recovered verification 一级 breakdown |
| Phase B | Context rot 治理产品化 | 进行中 | compact、compression、offload 已有；下一步是让 UI、review、自动动作全部懂这些信号 |
| Phase C | Long-horizon 执行约束化 | 未完成 | continuation 能力存在，但 completion loop 还没成为平台纪律 |
| Phase D | JIT 装配与场景裁剪 | 未完成 | 现阶段仍偏 static catalog + 手工场景约束 |
| Phase E | Trace-driven self-improvement | 未完成 | 目前取证能力具备，但还没形成长期治理平台 |
---
## 10. 长期检查表
这部分不是“建议”，而是后续每轮治理都应该复查的口径。
### 10.1 每次改 Harness Runtime 都检查
1. 是否继续只有一个事实源，还是又在 UI / analysis / replay 里拼了第二套真相？
2. 新增信号是否区分了 `exported / not_applicable / degraded / missing`？
3. 新增能力是否落在 `current` 主链，而不是又扩了一条 compat 旁路？
4. prompt、tool、sandbox、runtime metadata、UI 展示是否仍是同一条 contract？
### 10.2 每周检查
1. evidence pack 与 review template 是否存在字段漂移
2. known gaps 是否还在错误地把 `not_applicable` 当缺口
3. `output_truncated` 与 `offload_file` 是否能在前端稳定消费
4. context compaction 是否仍能在 thread read / replay / analysis 中一致呈现
5. 子代理、queue、resume、handoff 是否仍按同一 session 语义工作
### 10.3 每月检查
1. 哪些工具在当前任务中是长期噪音源，应该被 JIT 剔除
2. 哪些验证已经真实发生，哪些只是文档里提到但没进入 evidence 主链
3. 哪些 replay case 无法稳定复现，需要补环境、artifact 或 telemetry
4. 哪些 compat / deprecated surface 仍在偷偷长新逻辑
5. 哪些 HarnessStatusPanel、cleanup report、dashboard 文案与后端事实不一致
### 10.4 每季度检查
1. 长任务完成率是否提高，而不是只提高“能力数量”
2. 验证失败后是否更快回挂到补证据、补回放、补修复、补回归
3. 工具面是否比上季度更轻，而不是更重
4. 取证与治理链是否减少了人工判断分歧
5. 是否还在新增并行事实源、旁路协议、临时兼容层
---
## 11. 平台治理红线
后续只要出现下面任一情况，都应视为 Harness Engine 治理倒退：
1. 在 `analysis / replay / review / UI` 各自重新拼装第二套 runtime 真相
2. 为了图省事，把所有线程都写成同一种 known gap 模板
3. 在 `compat / deprecated` 路径继续长新功能
4. 为了“多给模型一点能力”，默认暴露更多无关工具和上下文
5. verification 没真实发生，却在证据层假装发生过
6. evidence 已经修正，展示层和治理层仍沿用旧字段、旧语义
---
## 12. 对 Lime 的最终定位
Lime 后续不应该把自己建设成“更多工具的聊天壳”，而应该明确建设成：
**一个以 workspace、artifact、verification、evidence、review 和长期治理为中心的 Harness Engine 平台。**
换句话说，Lime 的长期竞争力不在“会不会调模型”，而在：
- 是否能把模型接入稳定的执行环境
- 是否能把任务过程沉淀成可追溯证据
- 是否能把失败变成可修复、可回放、可治理的工程对象
- 是否能在长期演进中减少而不是放大系统熵
这才是 Lime 后续对齐 Claude Code / Codex / LangChain Harness 思路时，真正应该抓住的主线。
docs/roadmap/harness-engine/diagrams.md
+146
View File
@@ -0,0 +1,146 @@
# Lime Harness Engine 架构图与流程图
> 状态：进行中
> 更新时间：2026-04-13
> 作用：把 Harness Engine 的关键结构、时序和治理闭环画成可复查的图，而不是只靠长文描述。
## 1. 总体架构图
```mermaid
flowchart TB
User[用户 / 人工审核] --> UI[前端工作台 UI]
UI --> RuntimeAPI[agent_runtime_* 命令边界]
RuntimeAPI --> Runtime[Aster / Lime Runtime]
Runtime --> Prompt[System Prompt / Memory Prompt]
Runtime --> ToolSurface[Tool Surface / Skills / MCP / Browser]
Runtime --> Policy[Sandbox / Approval / Restriction Policy]
Runtime --> Session[Session / Thread / Queue / Resume / Continuation]
Runtime --> Workspace[Workspace / Filesystem / Artifact]
Prompt --> Memory[AGENTS / Project Rules / Durable Memory]
ToolSurface --> Exec[Bash / File Tools / Browser Tools / Subagent Tools]
Workspace --> Artifact[Artifact / Timeline / Runtime Snapshot]
Session --> Evidence[Evidence Pack]
Artifact --> Evidence
Runtime --> Evidence
Evidence --> Replay[Replay Case]
Evidence --> Analysis[Analysis Handoff]
Evidence --> Review[Review Decision]
Evidence --> Dashboard[Cleanup / Dashboard / Trend]
Evidence --> StatusPanel[HarnessStatusPanel]
Replay --> Governance[治理与回归决策]
Analysis --> Governance
Review --> Governance
Dashboard --> Governance
StatusPanel --> Governance
```
## 2. 运行时与证据导出时序图
```mermaid
sequenceDiagram
participant U as 用户
participant F as 前端工作台
participant C as agent_runtime_submit_turn
participant R as Lime / Aster Runtime
participant T as Tools / Skills / Browser / Bash
participant W as Workspace / Artifact
participant E as agent_runtime_export_evidence_pack
participant P as HarnessStatusPanel
U->>F: 发送任务
F->>C: submit_turn(request_metadata + turn_config)
C->>R: 创建 / 恢复当前 turn
R->>T: 调用 tools / skills / browser / subagent
T-->>R: 返回输出 / metadata / offload / errors
R->>W: 写入 artifact / timeline / runtime state
R-->>F: 流式状态 / item / summary
U->>F: 导出问题证据包
F->>E: export_evidence_pack(session_id)
E->>R: 读取 session detail / thread read
E->>W: 汇总 runtime.json / timeline.json / artifacts.json / summary.md
E-->>F: 返回 evidence pack + observability summary + verification summary
F->>P: 渲染 known gaps / verification outcomes / focus lists
P-->>U: 展示证据事实与治理焦点
```
## 3. Evidence 驱动治理闭环
```mermaid
flowchart LR
A[Runtime Thread / Session] --> B[Evidence Pack]
B --> C[Observability Summary]
C --> D[Verification Outcomes]
D --> E[HarnessStatusPanel]
D --> F[Replay Case]
D --> G[Analysis Handoff]
D --> H[Review Decision]
H --> I[修复实现]
I --> J[回归验证]
J --> B
```
## 4. 长时任务执行闭环
```mermaid
flowchart TD
Start[用户任务进入主会话] --> Plan[计划 / Todo / Scene Binding]
Plan --> Execute[主代理执行]
Execute --> Tools[Tools / Skills / Browser / Bash]
Tools --> Check{是否完成?}
Check -- 否 --> Continue[Auto Continue / Provider Continuation / Queue Resume]
Continue --> Compact[必要时 Compact / Offload / Context Recovery]
Compact --> Execute
Check -- 需要拆分 --> Subagent[Spawn Subagent / Team Runtime]
Subagent --> Execute
Check -- 是 --> Verify[Verification / Replay / Review]
Verify --> Done[形成交付物与证据]
```
## 5. 事实源分层图
```mermaid
flowchart TB
RuntimeFact[Runtime Thread / Session / Timeline]
EvidencePack[Evidence Pack]
Derived[Replay / Analysis / Review / Dashboard]
View[UI / Prompt Copy / Status Cards]
RuntimeFact --> EvidencePack
EvidencePack --> Derived
EvidencePack --> View
Derived --> View
View -.禁止反向定义事实.-> EvidencePack
Derived -.禁止旁路重建真相.-> RuntimeFact
```
## 6. 当前最关键的治理关注点
### 6.1 已经成形的图上主链
- `User -> UI -> agent_runtime_* -> Runtime -> Tools / Workspace -> Evidence`
- `Evidence -> Replay / Analysis / Review / StatusPanel`
- `Continuation / Compact / Offload / Resume`
### 6.2 仍需继续加强的图上闭环
- `Verification Outcomes -> Review / Cleanup / Dashboard` 还要更强一致
- `是否完成 -> Continue / Compact / Resume` 还没完全约束化
- `任务类型 -> JIT Tool / Context Assembly` 还没完全平台化
## 7. 后续补图原则
后续如果 Harness Engine 再新增图纸，遵守三条规则：
1. 只画 current 主链，不为 compat / deprecated 画主图。
2. 图中节点必须能对应到仓库真实模块、命令或文档，不画空概念。
3. 如果实现已经改变事实源或时序，优先更新图，而不是只改 README 文案。