mirror of
https://github.com/aiclientproxy/proxycast.git
synced 2026-09-24 23:10:56 +08:00
release: v1.10.0
This commit is contained in:
coso
@@ -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`，统一承接：
|
||||
|
||||
|
||||
@@ -213,6 +213,7 @@ lime/
|
||||
### 7. 多 Provider 与兼容层
|
||||
- OAuth 与 API Key Provider 并存
|
||||
- 凭证池、模型路由、协议兼容与 HTTP Server 作为底层支撑
|
||||
- Prompt Cache 等运行时能力按 ProviderType 判断；`anthropic-compatible` 只表示 Anthropic wire format 兼容，不等于自动 Prompt Cache 能力
|
||||
|
||||
### 8. 本地优先与可扩展
|
||||
- 桌面应用、本地工作区、插件与外部工具扩展
|
||||
|
||||
@@ -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 模型区会提示“模型真相源异常”，而不是静默显示空态
|
||||
|
||||
### 社媒内容工作流
|
||||
|
||||
|
||||
@@ -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 没发字段
|
||||
|
||||
排查这类问题时，优先确认三件事：
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
入口：
|
||||
|
||||
@@ -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 命令
|
||||
|
||||
|
||||
Reference in New Issue
Block a user