feat(github-copilot-sdk): release v0.10.0 with native prompt restoration and live todo widget

- Restore native Copilot CLI prompts for authentic Plan Mode behavior - Add SQLite-backed session management for state persistence via system prompt - Implement Adaptive Autonomy (Agent chooses planning vs direct execution) - Fix OpenWebUI custom tool context injection for v0.8.x compatibility - Add compact Live TODO widget synchronized with session.db - Upgrade SDK to github-copilot-sdk==0.1.30 - Remove legacy mode switch RPC calls (moved to prompt-driven orchestration) - Fix intent status localization and widget whitespace optimization - Sync bilingual READMEs and all documentation mirrors to v0.10.0
2026-03-07 04:30:15 +08:00
parent 35dec491de
commit f5a983fb4a
44 changed files with 5993 additions and 489 deletions
--- a/docs/.!55042!.DS_Store
+++ b/docs/.!55042!.DS_Store
--- a/docs/development/gh-aw-integration-plan.md
+++ b/docs/development/gh-aw-integration-plan.md
@@ -0,0 +1,426 @@
+# gh-aw Integration Plan
+
+> This document proposes a safe, incremental adoption plan for GitHub Agentic Workflows (`gh-aw`) in the `openwebui-extensions` repository.
+
+---
+
+## 1. Goals
+
+- Add repository-aware AI maintenance without replacing stable script-based CI.
+- Use `gh-aw` where natural language reasoning is stronger than deterministic shell logic.
+- Preserve the current release, deploy, publish, and stats workflows as the execution backbone.
+- Introduce observability, diagnosis, and long-term maintenance memory for repository operations.
+
+---
+
+## 2. Why gh-aw Fits This Repository
+
+This repository already has strong deterministic automation:
+
+- `/.github/workflows/release.yml`
+- `/.github/workflows/plugin-version-check.yml`
+- `/.github/workflows/deploy.yml`
+- `/.github/workflows/publish_plugin.yml`
+- `/.github/workflows/community-stats.yml`
+
+Those workflows are good at exact execution, but they do not deeply understand repository policy.
+
+`gh-aw` is a good fit for tasks that require:
+
+- reading code, docs, and PR descriptions together
+- applying repository conventions with nuance
+- generating structured review comments
+- diagnosing failed workflow runs
+- keeping long-term maintenance notes across runs
+
+This matches the repository's real needs:
+
+- bilingual documentation synchronization
+- plugin code + README + docs consistency
+- release-prep validation across many files
+- issue and PR maintenance at scale
+
+---
+
+## 3. Non-Goals
+
+The first adoption phase should not:
+
+- replace `release.yml`
+- replace `publish_plugin.yml`
+- replace MkDocs deployment
+- auto-merge or auto-push code changes by default
+- grant broad write permissions to the agent
+
+`gh-aw` should begin as a review, diagnosis, and preflight layer.
+
+---
+
+## 4. Adoption Principles
+
+### 4.1 Keep deterministic workflows for execution
+
+Existing YAML workflows remain responsible for:
+
+- release creation
+- plugin publishing
+- documentation deployment
+- version extraction and comparison
+- stats generation
+
+### 4.2 Add agentic workflows for judgment
+
+`gh-aw` workflows should focus on:
+
+- policy-aware review
+- release readiness checks
+- docs drift analysis
+- CI failure investigation
+- issue triage and response drafting
+
+### 4.3 Default to read-only behavior
+
+Start with minimal permissions and use safe outputs only for controlled comments or issue creation.
+
+### 4.4 Keep the blast radius small
+
+Roll out one workflow at a time, verify output quality, then expand.
+
+---
+
+## 5. Proposed Repository Layout
+
+### 5.1 New files and directories
+
+```text
+.github/
+├── workflows/
+│   ├── release.yml
+│   ├── plugin-version-check.yml
+│   ├── deploy.yml
+│   ├── publish_plugin.yml
+│   ├── community-stats.yml
+│   ├── aw-pr-maintainer-review.md
+│   ├── aw-pr-maintainer-review.lock.yml
+│   ├── aw-release-preflight.md
+│   ├── aw-release-preflight.lock.yml
+│   ├── aw-ci-audit.md
+│   ├── aw-ci-audit.lock.yml
+│   ├── aw-docs-drift-review.md
+│   └── aw-docs-drift-review.lock.yml
+├── gh-aw/
+│   ├── prompts/
+│   │   ├── pr-review-policy.md
+│   │   ├── release-preflight-policy.md
+│   │   ├── ci-audit-policy.md
+│   │   └── docs-drift-policy.md
+│   ├── schemas/
+│   │   └── review-output-example.json
+│   └── README.md
+└── copilot-instructions.md
+```
+
+### 5.2 Naming convention
+
+Use an `aw-` prefix for all agentic workflow source files:
+
+- `aw-pr-maintainer-review.md`
+- `aw-release-preflight.md`
+- `aw-ci-audit.md`
+- `aw-docs-drift-review.md`
+
+Reasons:
+
+- clearly separates agentic workflows from existing handwritten YAML workflows
+- keeps `gh-aw` assets easy to search
+- avoids ambiguity during debugging and release review
+
+### 5.3 Why not replace `.yml` files
+
+The current workflows are production logic. `gh-aw` should complement them first, not absorb their responsibility.
+
+---
+
+## 6. Recommended Workflow Portfolio
+
+### 6.1 Phase 1: PR Maintainer Review
+
+**File**: `/.github/workflows/aw-pr-maintainer-review.md`
+
+**Purpose**:
+
+- review PRs that touch plugins, docs, or development guidance
+- comment on missing repository-standard updates
+- act as a semantic layer on top of `plugin-version-check.yml`
+
+**Checks to perform**:
+
+- plugin version updated when code changes
+- `README.md` and `README_CN.md` both updated when required
+- docs mirror pages updated when required
+- root README badge/date update needed for release-related changes
+- i18n and helper-method standards followed for plugin code
+- Conventional Commit quality in PR title/body if relevant
+
+**Suggested permissions**:
+
+```yaml
+permissions:
+  contents: read
+  pull-requests: write
+  issues: write
+```
+
+**Suggested tools**:
+
+- `github:` read-focused issue/PR/repo tools
+- `bash:` limited read commands only
+- `edit:` disabled in early phase
+- `agentic-workflows:` optional only after adoption matures
+
+### 6.2 Phase 1: Release Preflight
+
+**File**: `/.github/workflows/aw-release-preflight.md`
+
+**Purpose**:
+
+- run before release or on manual dispatch
+- verify release completeness before `release.yml` does packaging and publishing
+
+**Checks to perform**:
+
+- code version and docs versions are aligned
+- bilingual README updates exist
+- docs plugin mirrors exist and match the release target
+- release notes sources exist where expected
+- commit message and release draft are coherent
+
+**Output style**:
+
+- summary comment on PR or issue
+- optional checklist artifact
+- no direct release creation
+
+### 6.3 Phase 2: CI Audit
+
+**File**: `/.github/workflows/aw-ci-audit.md`
+
+**Purpose**:
+
+- inspect failed runs of `release.yml`, `publish_plugin.yml`, `community-stats.yml`, and other important workflows
+- summarize likely root cause and next fix steps
+
+**Why gh-aw is strong here**:
+
+- it can use `logs` and `audit` via `gh aw mcp-server`
+- it is designed for workflow introspection and post-hoc analysis
+
+### 6.4 Phase 2: Docs Drift Review
+
+**File**: `/.github/workflows/aw-docs-drift-review.md`
+
+**Purpose**:
+
+- periodically inspect whether plugin code, local README files, mirrored docs, and root indexes have drifted apart
+
+**Checks to perform**:
+
+- missing `README_CN.md`
+- README sections out of order
+- docs page missing after plugin update
+- version mismatches across code and docs
+
+### 6.5 Phase 3: Issue Maintainer
+
+**Candidate file**: `/.github/workflows/aw-issue-maintainer.md`
+
+**Purpose**:
+
+- summarize unreplied issues
+- propose bilingual responses
+- group repeated bug reports by plugin
+
+This should come after the earlier review and audit flows are trusted.
+
+---
+
+## 7. Mapping to Existing Workflows
+
+| Current Workflow | Keep As-Is | gh-aw Companion | Role Split |
+|------|------|------|------|
+| `/.github/workflows/release.yml` | Yes | `aw-release-preflight.md` | `release.yml` executes; `gh-aw` judges readiness |
+| `/.github/workflows/plugin-version-check.yml` | Yes | `aw-pr-maintainer-review.md` | hard gate + semantic review |
+| `/.github/workflows/deploy.yml` | Yes | none initially | deterministic build and deploy |
+| `/.github/workflows/publish_plugin.yml` | Yes | `aw-ci-audit.md` | deterministic publish + failure diagnosis |
+| `/.github/workflows/community-stats.yml` | Yes | `aw-ci-audit.md` | deterministic stats + anomaly diagnosis |
+
+---
+
+## 8. Tooling Model
+
+### 8.1 Built-in tools to enable first
+
+For early workflows, prefer a narrow tool set:
+
+```yaml
+tools:
+  github:
+    toolsets: [default]
+  bash:
+    - echo
+    - pwd
+    - ls
+    - cat
+    - head
+    - tail
+    - grep
+    - wc
+    - git status
+    - git diff
+```
+
+Do not enable unrestricted shell access in phase 1.
+
+### 8.2 MCP usage model
+
+Use `gh aw mcp-server` later for:
+
+- workflow `status`
+- workflow `compile`
+- workflow `logs`
+- workflow `audit`
+- `mcp-inspect`
+
+This is especially valuable for `aw-ci-audit.md`.
+
+### 8.3 Safe output policy
+
+In early adoption, only allow safe outputs that:
+
+- comment on PRs
+- comment on issues
+- open a low-risk maintenance issue when explicitly needed
+
+Avoid any automatic code-writing safe outputs at first.
+
+---
+
+## 9. Repo Memory Strategy
+
+`gh-aw` repo memory is a strong fit for this repository, but it should be constrained.
+
+### 9.1 Recommended first use cases
+
+- recurring CI failure signatures
+- repeated docs sync omissions
+- common reviewer reminders
+- issue clusters by plugin name
+
+### 9.2 Recommended configuration shape
+
+- store only `.md` and `.json`
+- small patch size limit
+- one memory stream per concern
+
+Suggested conceptual layout:
+
+```text
+memory/review-notes/*.md
+memory/ci-patterns/*.md
+memory/issue-clusters/*.json
+```
+
+### 9.3 Important caution
+
+Do not store secrets, tokens, or unpublished sensitive data in repo memory.
+
+---
+
+## 10. Rollout Plan
+
+### Phase 0: Preparation
+
+- install `gh-aw` locally for maintainers
+- add a short `/.github/gh-aw/README.md`
+- document workflow naming and review expectations
+
+### Phase 1: Read-only semantic review
+
+- introduce `aw-pr-maintainer-review.md`
+- introduce `aw-release-preflight.md`
+- keep outputs limited to summaries and comments
+
+### Phase 2: Diagnostics and memory
+
+- introduce `aw-ci-audit.md`
+- enable `agentic-workflows:` where useful
+- add constrained `repo-memory` configuration for repeated failure patterns
+
+### Phase 3: Maintenance automation
+
+- add docs drift patrol
+- add issue maintenance workflow
+- consider limited code-change proposals only after trust is established
+
+---
+
+## 11. Local Maintainer Setup
+
+For local experimentation and debugging:
+
+### 11.1 Install CLI
+
+```bash
+curl -sL https://raw.githubusercontent.com/github/gh-aw/main/install-gh-aw.sh | bash
+```
+
+### 11.2 Useful commands
+
+```bash
+gh aw version
+gh aw compile
+gh aw status
+gh aw run aw-pr-maintainer-review
+gh aw logs
+gh aw audit <run-id>
+```
+
+### 11.3 VS Code MCP integration
+
+A future optional improvement is adding `gh aw mcp-server` to local MCP configuration so workflow introspection tools are available in editor-based agent sessions.
+
+---
+
+## 12. Recommended First Deliverables
+
+Start with these two workflows only:
+
+1. `aw-pr-maintainer-review.md`
+2. `aw-release-preflight.md`
+
+This gives the repository the highest-value upgrade with the lowest operational risk.
+
+---
+
+## 13. Success Criteria
+
+Adoption is working if:
+
+- PR review comments become more specific and repository-aware
+- release preparation catches missing docs or version sync earlier
+- CI failures produce actionable summaries faster
+- maintainers spend less time on repetitive policy review
+- deterministic workflows remain stable and unchanged in core behavior
+
+---
+
+## 14. Summary
+
+For `openwebui-extensions`, `gh-aw` should be adopted as an intelligent maintenance layer.
+
+- Keep current YAML workflows for execution.
+- Add agentic workflows for policy-aware review and diagnosis.
+- Start read-only.
+- Expand only after signal quality is proven.
+
+This approach aligns with the repository's existing strengths: strong conventions, bilingual maintenance, plugin lifecycle complexity, and growing repository operations.
--- a/docs/development/gh-aw-integration-plan.zh.md
+++ b/docs/development/gh-aw-integration-plan.zh.md
@@ -0,0 +1,424 @@
+# gh-aw 集成方案
+
+> 本文档用于为 `openwebui-extensions` 仓库设计一套安全、渐进式的 GitHub Agentic Workflows (`gh-aw`) 接入方案。
+
+---
+
+## 1. 目标
+
+- 在不替换现有稳定 CI 的前提下，引入具备仓库理解能力的 AI 维护层。
+- 将 `gh-aw` 用于更适合自然语言推理的任务，而不是机械脚本执行。
+- 保留当前发布、部署、发布插件和统计工作流作为执行骨架。
+- 为仓库维护引入可观测性、自动诊断和长期记忆能力。
+
+---
+
+## 2. 为什么这个仓库适合 gh-aw
+
+本仓库已经有一套很强的确定性自动化：
+
+- `/.github/workflows/release.yml`
+- `/.github/workflows/plugin-version-check.yml`
+- `/.github/workflows/deploy.yml`
+- `/.github/workflows/publish_plugin.yml`
+- `/.github/workflows/community-stats.yml`
+
+这些工作流擅长精确执行，但并不擅长理解仓库规范本身。
+
+`gh-aw` 更适合以下任务：
+
+- 联合阅读代码、文档和 PR 描述后再做判断
+- 带语义地应用仓库规范
+- 生成结构化的 review 评论
+- 自动分析失败的工作流运行
+- 在多次运行之间保存维护经验和模式
+
+这与当前仓库的真实需求高度匹配：
+
+- 双语文档同步
+- 插件代码、README 与 docs 一致性检查
+- 跨多个文件的发布前完整性核查
+- Issue 与 PR 的规模化维护
+
+---
+
+## 3. 非目标
+
+第一阶段不建议让 `gh-aw`：
+
+- 替换 `release.yml`
+- 替换 `publish_plugin.yml`
+- 替换 MkDocs 部署
+- 默认自动合并或自动推送代码
+- 一开始就拥有过宽的写权限
+
+第一阶段应把它定位为 review、诊断和 preflight 层。
+
+---
+
+## 4. 接入原则
+
+### 4.1 确定性执行继续由 YAML 工作流承担
+
+现有 YAML workflow 继续负责：
+
+- 创建 release
+- 发布插件
+- 部署文档
+- 提取和比较版本号
+- 生成社区统计
+
+### 4.2 Agentic workflow 只负责判断和总结
+
+`gh-aw` workflow 优先承担：
+
+- 基于规范的语义审查
+- 发布前完整性检查
+- 文档漂移巡检
+- CI 失败原因分析
+- Issue 分流与回复草稿生成
+
+### 4.3 默认只读
+
+优先使用最小权限，并通过 safe outputs 进行受控评论或低风险输出。
+
+### 4.4 逐步扩容
+
+一次只上线一个 agentic workflow，验证质量后再扩大范围。
+
+---
+
+## 5. 建议的仓库结构
+
+### 5.1 新增文件和目录
+
+```text
+.github/
+├── workflows/
+│   ├── release.yml
+│   ├── plugin-version-check.yml
+│   ├── deploy.yml
+│   ├── publish_plugin.yml
+│   ├── community-stats.yml
+│   ├── aw-pr-maintainer-review.md
+│   ├── aw-pr-maintainer-review.lock.yml
+│   ├── aw-release-preflight.md
+│   ├── aw-release-preflight.lock.yml
+│   ├── aw-ci-audit.md
+│   ├── aw-ci-audit.lock.yml
+│   ├── aw-docs-drift-review.md
+│   └── aw-docs-drift-review.lock.yml
+├── gh-aw/
+│   ├── prompts/
+│   │   ├── pr-review-policy.md
+│   │   ├── release-preflight-policy.md
+│   │   ├── ci-audit-policy.md
+│   │   └── docs-drift-policy.md
+│   ├── schemas/
+│   │   └── review-output-example.json
+│   └── README.md
+└── copilot-instructions.md
+```
+
+### 5.2 命名规范
+
+所有 agentic workflow 源文件统一使用 `aw-` 前缀：
+
+- `aw-pr-maintainer-review.md`
+- `aw-release-preflight.md`
+- `aw-ci-audit.md`
+- `aw-docs-drift-review.md`
+
+这样做的原因：
+
+- 可以和现有手写 YAML 工作流明确区分
+- 便于在仓库中快速搜索和定位
+- 方便调试和发布时识别来源
+
+### 5.3 为什么不直接替换 `.yml`
+
+当前 `.yml` 文件承担的是生产执行逻辑。第一阶段 `gh-aw` 的角色应该是补充，而不是接管。
+
+---
+
+## 6. 建议优先建设的 workflow 组合
+
+### 6.1 第一阶段：PR 维护者语义审查
+
+**文件**: `/.github/workflows/aw-pr-maintainer-review.md`
+
+**作用**:
+
+- 审查涉及插件、文档或开发规范的 PR
+- 对缺失的仓库标准更新给出评论
+- 作为 `plugin-version-check.yml` 之上的语义层
+
+**建议检查项**:
+
+- 插件代码修改后是否更新版本号
+- 是否同时更新 `README.md` 和 `README_CN.md`
+- 是否同步更新 docs 镜像页
+- 是否需要更新根 README 的日期 badge
+- 插件代码是否遵守 i18n 与 helper 规范
+- PR 标题或正文是否符合 Conventional Commits 精神
+
+**建议权限**:
+
+```yaml
+permissions:
+  contents: read
+  pull-requests: write
+  issues: write
+```
+
+**建议工具**:
+
+- 只读型 `github:` 工具
+- 只开放少量只读 `bash:` 命令
+- 第一阶段不开放 `edit:`
+- `agentic-workflows:` 可在后续成熟后再启用
+
+### 6.2 第一阶段：发布前预检
+
+**文件**: `/.github/workflows/aw-release-preflight.md`
+
+**作用**:
+
+- 在 release 前或手动触发时执行
+- 在 `release.yml` 打包和发布之前，先检查发布完整性
+
+**建议检查项**:
+
+- 代码版本号和文档版本号是否一致
+- 双语 README 是否完整更新
+- docs 插件镜像页是否存在并匹配当前发布目标
+- release notes 来源文件是否齐全
+- commit message 与 release 草案是否连贯
+
+**输出方式**:
+
+- 在 PR 或 issue 中写总结评论
+- 可附带 checklist artifact
+- 不直接执行正式发布
+
+### 6.3 第二阶段：CI 失败自动审计
+
+**文件**: `/.github/workflows/aw-ci-audit.md`
+
+**作用**:
+
+- 分析 `release.yml`、`publish_plugin.yml`、`community-stats.yml` 等关键 workflow 的失败运行
+- 输出根因判断和下一步修复建议
+
+**适合 gh-aw 的原因**:
+
+- 可以通过 `gh aw mcp-server` 使用 `logs`、`audit` 等能力
+- 原生支持对 workflow 执行痕迹进行事后分析
+
+### 6.4 第二阶段：文档漂移巡检
+
+**文件**: `/.github/workflows/aw-docs-drift-review.md`
+
+**作用**:
+
+- 定期检查插件代码、插件目录 README、本地 docs 镜像和根索引之间是否发生漂移
+
+**建议检查项**:
+
+- 是否缺少 `README_CN.md`
+- README 章节顺序是否偏离规范
+- 插件更新后 docs 页面是否缺失
+- 代码和文档中的版本号是否不一致
+
+### 6.5 第三阶段：Issue 维护助手
+
+**候选文件**: `/.github/workflows/aw-issue-maintainer.md`
+
+**作用**:
+
+- 汇总长期未回复的 issue
+- 生成英文或双语回复草稿
+- 按插件归类重复问题
+
+这个阶段建议在前面的 review 和 audit 流程稳定后再上线。
+
+---
+
+## 7. 与现有 workflow 的职责映射
+
+| 当前 Workflow | 是否保留 | gh-aw 搭档 | 职责划分 |
+|------|------|------|------|
+| `/.github/workflows/release.yml` | 保留 | `aw-release-preflight.md` | `release.yml` 负责执行，`gh-aw` 负责判断是否已准备好 |
+| `/.github/workflows/plugin-version-check.yml` | 保留 | `aw-pr-maintainer-review.md` | 硬性门禁 + 语义审查 |
+| `/.github/workflows/deploy.yml` | 保留 | 初期不加 | 确定性构建和部署 |
+| `/.github/workflows/publish_plugin.yml` | 保留 | `aw-ci-audit.md` | 确定性发布 + 失败诊断 |
+| `/.github/workflows/community-stats.yml` | 保留 | `aw-ci-audit.md` | 确定性统计 + 异常诊断 |
+
+---
+
+## 8. 工具模型建议
+
+### 8.1 第一阶段建议启用的内建工具
+
+建议从窄权限工具集开始：
+
+```yaml
+tools:
+  github:
+    toolsets: [default]
+  bash:
+    - echo
+    - pwd
+    - ls
+    - cat
+    - head
+    - tail
+    - grep
+    - wc
+    - git status
+    - git diff
+```
+
+第一阶段不要开放完全不受限的 shell。
+
+### 8.2 MCP 使用策略
+
+后续可通过 `gh aw mcp-server` 引入：
+
+- workflow `status`
+- workflow `compile`
+- workflow `logs`
+- workflow `audit`
+- `mcp-inspect`
+
+这对 `aw-ci-audit.md` 特别有价值。
+
+### 8.3 Safe output 策略
+
+第一阶段仅开放低风险 safe outputs：
+
+- 给 PR 写评论
+- 给 issue 写评论
+- 在明确需要时创建低风险维护 issue
+
+一开始不要让 agent 自动提交代码修改。
+
+---
+
+## 9. Repo Memory 策略
+
+`gh-aw` 的 repo memory 很适合本仓库，但必须加限制。
+
+### 9.1 第一批适合保存的内容
+
+- 重复出现的 CI 失败模式
+- 常见文档同步遗漏
+- 高频 review 提醒项
+- 按插件聚类的 issue 模式
+
+### 9.2 推荐配置思路
+
+- 只允许 `.md` 和 `.json`
+- 限制 patch size
+- 按主题拆成多个 memory stream
+
+建议的逻辑布局：
+
+```text
+memory/review-notes/*.md
+memory/ci-patterns/*.md
+memory/issue-clusters/*.json
+```
+
+### 9.3 重要提醒
+
+不要把 secret、token 或未公开敏感信息写入 repo memory。
+
+---
+
+## 10. 分阶段落地顺序
+
+### Phase 0: 准备阶段
+
+- 维护者本地安装 `gh-aw`
+- 添加一个简短的 `/.github/gh-aw/README.md`
+- 写清楚 workflow 命名规范和 review 预期
+
+### Phase 1: 只读语义审查
+
+- 上线 `aw-pr-maintainer-review.md`
+- 上线 `aw-release-preflight.md`
+- 输出先限制为总结和评论
+
+### Phase 2: 诊断与记忆
+
+- 上线 `aw-ci-audit.md`
+- 在需要的地方启用 `agentic-workflows:`
+- 为重复失败模式加入受限 `repo-memory`
+
+### Phase 3: 维护自动化
+
+- 增加文档漂移巡检
+- 增加 issue 维护 workflow
+- 只有在信号质量足够稳定后，再考虑有限度的代码修改建议
+
+---
+
+## 11. 维护者本地使用建议
+
+### 11.1 安装 CLI
+
+```bash
+curl -sL https://raw.githubusercontent.com/github/gh-aw/main/install-gh-aw.sh | bash
+```
+
+### 11.2 常用命令
+
+```bash
+gh aw version
+gh aw compile
+gh aw status
+gh aw run aw-pr-maintainer-review
+gh aw logs
+gh aw audit <run-id>
+```
+
+### 11.3 VS Code MCP 集成
+
+后续可选增强项是把 `gh aw mcp-server` 加入本地 MCP 配置，这样编辑器内的 agent 会直接具备 workflow 自省能力。
+
+---
+
+## 12. 最小可行落地建议
+
+建议第一步只做这两个 workflow：
+
+1. `aw-pr-maintainer-review.md`
+2. `aw-release-preflight.md`
+
+这样可以以最低风险获得最高价值的增强。
+
+---
+
+## 13. 成功标准
+
+如果接入有效，应该看到这些结果：
+
+- PR 评论更具体，更贴合仓库规范
+- 发布前能更早发现文档或版本同步遗漏
+- CI 失败后更快得到可执行的总结
+- 维护者花在重复性规范检查上的时间下降
+- 现有确定性 workflow 的核心行为保持稳定
+
+---
+
+## 14. 总结
+
+对 `openwebui-extensions` 来说，`gh-aw` 最合适的定位是智能维护层。
+
+- 现有 YAML workflow 继续负责执行。
+- agentic workflow 负责语义审查和诊断。
+- 第一阶段默认只读。
+- 等输出质量稳定后再逐步放权。
+
+这条路径和仓库现状是匹配的：规范密度高、双语维护复杂、插件生命周期长，而且已经具备成熟的 AI 工程上下文。
--- a/docs/development/image.png
+++ b/docs/development/image.png
--- a/docs/development/index.md
+++ b/docs/development/index.md
@@ -32,6 +32,14 @@ Learn how to develop plugins and contribute to OpenWebUI Extensions.

    [:octicons-arrow-right-24: Read the Plan](copilot-engineering-plan.md)

+-   :material-source-branch:{ .lg .middle } **gh-aw Integration Plan**
+
+    ---
+
+    Adoption plan for using GitHub Agentic Workflows as a semantic review and diagnostics layer in this repository.
+
+    [:octicons-arrow-right-24: Read the Plan](gh-aw-integration-plan.md)
+
 -   :material-github:{ .lg .middle } **Contributing**

    ---
--- a/docs/development/index.zh.md
+++ b/docs/development/index.zh.md
@@ -32,6 +32,14 @@

    [:octicons-arrow-right-24: 阅读文档](copilot-engineering-plan.md)

+-   :material-source-branch:{ .lg .middle } **gh-aw 集成方案**
+
+    ---
+
+    面向本仓库的 GitHub Agentic Workflows 渐进式接入设计，重点覆盖语义审查、发布预检与 CI 诊断。
+
+    [:octicons-arrow-right-24: 阅读文档](gh-aw-integration-plan.zh.md)
+
 -   :material-github:{ .lg .middle } **贡献指南**

    ---
--- a/docs/plugins/pipes/github-copilot-sdk.md
+++ b/docs/plugins/pipes/github-copilot-sdk.md
@@ -1,6 +1,6 @@
 # GitHub Copilot SDK Pipe for OpenWebUI

-**Author:** [Fu-Jie](https://github.com/Fu-Jie) | **Version:** 0.9.1 | **Project:** [OpenWebUI Extensions](https://github.com/Fu-Jie/openwebui-extensions) | **License:** MIT
+**Author:** [Fu-Jie](https://github.com/Fu-Jie) | **Version:** 0.10.0 | **Project:** [OpenWebUI Extensions](https://github.com/Fu-Jie/openwebui-extensions) | **License:** MIT

 This is a powerful **GitHub Copilot SDK** Pipe for **OpenWebUI** that provides a unified **Agentic experience**. It goes beyond simple model access by enabling autonomous **Intent Recognition**, **Web Search**, and **Context Compaction**. It seamlessly reuses your existing **Tools, MCP servers, OpenAPI servers, and Skills** from OpenWebUI to create a truly integrated ecosystem.

@@ -20,13 +20,14 @@ This is a powerful **GitHub Copilot SDK** Pipe for **OpenWebUI** that provides a

 ---

-## ✨ v0.9.1: Autonomous Web Search & Reliability Fix
+## ✨ v0.10.0: Native Prompt Restoration, Live TODO Widget & SDK v0.1.30

- **🌐 Autonomous Web Search**: `web_search` is now always enabled for the Agent (bypassing the UI toggle), leveraging the Copilot SDK's native ability to decide when to search.
- **🛠️ Terminology Alignment**: Standardized all references to **"Agent"** and **"Context Compaction"** (for Infinite Session) across all languages to better reflect the technical capabilities.
- **🌐 Language Consistency**: System prompts mandate that Agent output language remains strictly consistent with user input.
- **🐛 Fixed MCP Tool Filtering**: Resolved a critical issue where configuring `function_name_filter_list` (or selecting specific tools in UI) would cause all tools from that MCP server to be incorrectly hidden due to ID prefix mismatches (`server:mcp:`).
- **🔍 Improved Filter Stability**: Ensured tool-level whitelists apply reliably without breaking the entire server connection.
+- **⌨️ Authentic Prompt Restoration**: Most native Copilot CLI prompts have been restored to ensure authentic behavior and enhanced capabilities across the Agentic workflow.
+- **📋 Live TODO Widget**: Added a compact real-time task tracking widget synchronized with `session.db`, keeping in-progress work visible without cluttering the chat history.
+- **🧩 OpenWebUI Tool Call Fixes**: Fixed custom tool invocation by syncing injected context with OpenWebUI 0.8.x expectations, including `__request__`, `request`, `body`, `__messages__`, `__metadata__`, `__files__`, `__task__`, and session/chat/message IDs.
+- **🔒 SDK v0.1.30 + Adaptive Workstyle**: Upgraded the pipe to `github-copilot-sdk==0.1.30`, moving workflow logic into the system prompt for autonomous "Plan-vs-Execute" decisions.
+- **🐛 Intent + Widget UX Fixes**: Fixed `report_intent` localization and cleaned up TODO widget layout for a more professional look.
+- **🧾 Better Embedded Tool Results**: Improved HTML/embedded tool outcomes and synchronized documentation surface.

 ---

@@ -39,6 +40,7 @@ This is a powerful **GitHub Copilot SDK** Pipe for **OpenWebUI** that provides a
  - **OpenAPI Bridge**: Connect to any external REST API as an Agent tool.
  - **OpenWebUI Native**: Zero-config bridge to your existing OpenWebUI tools and built-ins (Web Search, Memory, etc.).
 - **🧩 OpenWebUI Skills Bridge**: Transforms simple OpenWebUI Markdown instructions into powerful SDK skill folders complete with supporting scripts, templates, and data.
+- **🧭 Adaptive Planning and Execution**: The Agent decides whether to respond with a planning-first analysis or direct implementation flow based on task complexity, ambiguity, and user intent.
 - **♾️ Infinite Session Management**: Advanced context window management with automatic "Compaction" (summarization + list persistence). Carry out weeks-long projects without losing the core thread.
 - **📊 Interactive Artifacts & Publishing**:
  - **Live HTML/JS**: Instantly render and interact with apps, dashboards, or reports generated by the Agent.
@@ -49,7 +51,7 @@ This is a powerful **GitHub Copilot SDK** Pipe for **OpenWebUI** that provides a
 > [!TIP]
 > **💡 Visualization Pro-Tip**
 > To get the most out of **HTML Artifacts** and **RichUI**, we highly recommend asking the Agent to install the skill via its GitHub URL:
-> "Install this skill: https://github.com/nicobailon/visual-explainer".
+> "Install this skill: <https://github.com/nicobailon/visual-explainer>".
 > This skill is specifically optimized for generating high-quality visual components and integrates perfectly with this Pipe.

 ---
@@ -81,7 +83,6 @@ Administrators define the default behavior for all users in the function setting
 | `ENABLE_MCP_SERVER` | `True` | Enable Direct MCP Client connection (Recommended). |
 | `ENABLE_OPENWEBUI_SKILLS` | `True` | Enable bidirectional sync with OpenWebUI Workspace > Skills. |
 | `OPENWEBUI_SKILLS_SHARED_DIR` | `/app/backend/data/cache/copilot-openwebui-skills` | Shared cache directory for skills. |
-| `GITHUB_SKILLS_SOURCE_URL` | `""` | Optional GitHub tree URL for batch skill import (e.g., anthropic/skills). |
 | `DISABLED_SKILLS` | `""` | Comma-separated skill names to disable in SDK session. |
 | `REASONING_EFFORT` | `medium` | Reasoning effort level: low, medium, high. |
 | `SHOW_THINKING` | `True` | Show model reasoning/thinking process. |
@@ -107,7 +108,6 @@ Standard users can override these settings in their individual Profile/Function
 | `MAX_MULTIPLIER` | Maximum allowed billing multiplier override. |
 | `EXCLUDE_KEYWORDS` | Exclude models containing these keywords. |
 | `ENABLE_OPENWEBUI_SKILLS` | Enable loading all active OpenWebUI skills readable by you into SDK `SKILL.md` directories. |
-| `GITHUB_SKILLS_SOURCE_URL` | Optional GitHub tree URL for batch skill import in your own session. |
 | `DISABLED_SKILLS` | Comma-separated skill names to disable for your own session. |
 | `BYOK_API_KEY` | Use your personal OpenAI/Anthropic API Key. |

--- a/docs/plugins/pipes/github-copilot-sdk.zh.md
+++ b/docs/plugins/pipes/github-copilot-sdk.zh.md
@@ -1,6 +1,6 @@
 # GitHub Copilot Official SDK Pipe

-**作者:** [Fu-Jie](https://github.com/Fu-Jie/openwebui-extensions) | **版本:** 0.9.1 | **项目:** [OpenWebUI Extensions](https://github.com/Fu-Jie/openwebui-extensions) | **许可证:** MIT
+**作者:** [Fu-Jie](https://github.com/Fu-Jie/openwebui-extensions) | **版本:** 0.10.0 | **项目:** [OpenWebUI Extensions](https://github.com/Fu-Jie/openwebui-extensions) | **许可证:** MIT

 这是一个将 **GitHub Copilot SDK** 深度集成到 **OpenWebUI** 中的强大 Agent SDK 管道。它不仅实现了 SDK 的核心功能，还支持 **智能意图识别**、**自主网页搜索** 与 **自动上下文压缩**，并能够无缝读取 OpenWebUI 已有的配置进行智能注入，让 Agent 能够具备以下能力：

@@ -21,13 +21,14 @@

 ---

-## ✨ 0.9.1 最新更新：自主网页搜索与可靠性修复
+## ✨ v0.10.0 最新更新：原生提示词恢复、Live TODO 小组件与 SDK v0.1.30 完善

- **🌐 强化自主网页搜索**：`web_search` 工具现已强制对 Agent 开启（绕过 UI 网页搜索开关），充分利用 Copilot 自身具备的搜索判断能力。
- **🛠️ 术语一致性优化**：全语种同步将“助手”更改为 **"Agent"**，并将“优化会话”统一为 **"压缩上下文"**，更准确地描述 Infinite Session 的技术本质。
- **🌐 语言一致性**：内置指令确保 Agent 输出语言与用户输入严格对齐，提供无缝的国际化交互体验。
- **🐛 修复 MCP 工具过滤逻辑**：解决了在管理员后端配置 `function_name_filter_list`（或在聊天界面勾选特定工具）时，因 ID 前缀（`server:mcp:`）识别逻辑错误导致工具意外失效的问题。
- **🔍 提升过滤稳定性**：修复了工具 ID 归一化逻辑，确保点选的工具白名单在 SDK 会话中精确生效。
+- **⌨️ 原生提示词恢复**：恢复了大部分 Copilot CLI 原生提示词，确保 Agent 在处理复杂任务时具备最正宗的行为逻辑与增强能力。
+- **📋 Live TODO 小组件**：新增基于 `session.db` 实时任务状态的紧凑型嵌入式 TODO 小组件，任务进度常驻可见，无需在正文中重复显示全部待办列表。
+- **🧩 OpenWebUI 工具调用修复**：修复自定义工具调用时上下文注入不完整的问题，完全对齐 OpenWebUI 0.8.x 所需的系统级上下文（`__request__`、`body`、`__metadata__` 等）。
+- **🔒 SDK v0.1.30 与自适应工作流**：升级到 `github-copilot-sdk==0.1.30`，将规划与执行逻辑移至系统提示词，让 Agent 根据任务复杂度自主决策工作流。
+- **🐛 意图与体验优化**：修复 `report_intent` 国际化问题，优化 TODO 小组件的视觉布局，减少冗余空白。
+- **🧾 嵌入结果与文档更新**：改进 HTML/嵌入式工具结果处理，同步中英 README 与 docs 镜像页，确保发布状态一致。

 ---

@@ -40,6 +41,7 @@
  - **OpenAPI 桥接**: 将任何外部 REST API 一键转换为 Agent 可调用的工具。
  - **OpenWebUI 原生桥接**: 零配置接入现有的 OpenWebUI 工具及内置功能（网页搜索、记忆等）。
 - **🧩 OpenWebUI Skills 桥接**: 将简单的 OpenWebUI Markdown 指令转化为包含脚本、模板 and 数据的强大 SDK 技能文件夹。
+- **🧭 自适应规划与执行**: Agent 会根据任务复杂度、歧义程度和用户意图，自主决定先输出结构化方案，还是直接分析、实现并验证。
 - **♾️ 无限会话管理**: 先进的上下文窗口管理，支持自动“压缩”（摘要提取 + TODO 列表持久化）。支持长达数周的项目跟踪而不会丢失核心上下文。
 - **📊 交互式产物与发布**:
  - **实时 HTML/JS**: 瞬间渲染并交互 Agent 生成的应用程序、可视化看板或报告。
@@ -67,32 +69,81 @@

 ---

-## 🚀 快速开始 (Quick Start)
+## ⚙️ 核心配置 (Valves)

-1. **安装本插件**: 在 OpenWebUI 管道管理界面添加并启用。
-2. **安装 [Files Filter](https://openwebui.com/posts/403a62ee-a596-45e7-be65-fab9cc249dd6)** (必须): 以获得文件处理能力。
-3. **配置凭据**:
-   - **官方模式**: 默认即可。确保环境中安装了 `github-copilot-sdk`。
-   - **BYOK 模式**: 填入 OpenAI/Anthropic/DeepSeek 的 Base URL 与 Key。
-4. **选择模型**: 在聊天界面选择 `GitHub Copilot Official SDK Pipe` 系列模型。
-5. **开始对话**: 直接上传文件或发送复杂指令。
+### 1. 管理员设置（全局默认）
+
+管理员可在函数设置中为所有用户定义默认行为。
+
+| Valve | 默认值 | 描述 |
+| :--- | :--- | :--- |
+| `GH_TOKEN` | `""` | 全局 GitHub Fine-grained Token，需要 `Copilot Requests` 权限。 |
+| `COPILOTSDK_CONFIG_DIR` | `/app/backend/data/.copilot` | SDK 配置与会话状态的持久化目录。 |
+| `ENABLE_OPENWEBUI_TOOLS` | `True` | 启用 OpenWebUI Tools 与 Built-in Tools。 |
+| `ENABLE_OPENAPI_SERVER` | `True` | 启用 OpenAPI Tool Server 连接。 |
+| `ENABLE_MCP_SERVER` | `True` | 启用 MCP Server 连接。 |
+| `ENABLE_OPENWEBUI_SKILLS` | `True` | 启用 OpenWebUI Skills 到 SDK 技能目录的同步。 |
+| `OPENWEBUI_SKILLS_SHARED_DIR` | `/app/backend/data/cache/copilot-openwebui-skills` | Skills 共享缓存目录。 |
+| `DISABLED_SKILLS` | `""` | 逗号分隔的禁用技能名列表。 |
+| `REASONING_EFFORT` | `medium` | 推理强度：`low`、`medium`、`high`、`xhigh`。 |
+| `SHOW_THINKING` | `True` | 是否显示思考过程。 |
+| `INFINITE_SESSION` | `True` | 是否启用无限会话与上下文压缩。 |
+| `MAX_MULTIPLIER` | `1.0` | 允许的最大账单倍率。`0` 表示仅允许免费模型。 |
+| `EXCLUDE_KEYWORDS` | `""` | 排除包含这些关键词的模型。 |
+| `TIMEOUT` | `300` | 每个流式分片的超时时间（秒）。 |
+| `BYOK_TYPE` | `openai` | BYOK 提供商类型：`openai` 或 `anthropic`。 |
+| `BYOK_BASE_URL` | `""` | BYOK Base URL。 |
+| `BYOK_MODELS` | `""` | BYOK 模型列表，留空则尝试从 API 获取。 |
+| `CUSTOM_ENV_VARS` | `""` | 自定义环境变量（JSON 格式）。 |
+| `DEBUG` | `False` | 启用浏览器控制台/技术调试日志。 |
+
+### 2. 用户设置（个人覆盖）
+
+普通用户可在个人资料或函数设置中覆盖以下选项。
+
+| Valve | 描述 |
+| :--- | :--- |
+| `GH_TOKEN` | 使用个人 GitHub Token。 |
+| `REASONING_EFFORT` | 个人推理强度偏好。 |
+| `SHOW_THINKING` | 是否显示思考过程。 |
+| `MAX_MULTIPLIER` | 个人最大账单倍率限制。 |
+| `EXCLUDE_KEYWORDS` | 个人模型排除关键词。 |
+| `ENABLE_OPENWEBUI_TOOLS` | 是否启用 OpenWebUI Tools 与 Built-in Tools。 |
+| `ENABLE_OPENAPI_SERVER` | 是否启用 OpenAPI Tool Server。 |
+| `ENABLE_MCP_SERVER` | 是否启用 MCP Server。 |
+| `ENABLE_OPENWEBUI_SKILLS` | 是否加载你可读的 OpenWebUI Skills 到 SDK 技能目录。 |
+| `DISABLED_SKILLS` | 逗号分隔的个人禁用技能列表。 |
+| `BYOK_API_KEY` | 个人 BYOK API Key。 |
+| `BYOK_TYPE` | 个人 BYOK 提供商类型覆盖。 |
+| `BYOK_BASE_URL` | 个人 BYOK Base URL 覆盖。 |
+| `BYOK_BEARER_TOKEN` | 个人 BYOK Bearer Token 覆盖。 |
+| `BYOK_MODELS` | 个人 BYOK 模型列表覆盖。 |
+| `BYOK_WIRE_API` | 个人 BYOK Wire API 覆盖。 |

 ---

-## ⚙️ 配置参数 (Configuration Valves)
+## 🚀 安装与配置

-| 参数 | 默认值 | 描述 |
-| :--- | :--- | :--- |
-| `github_token` | - | GitHub Copilot 官方 Token (如果您有官方订阅且不方便本地登录时填入)。 |
-| `llm_base_url` | - | BYOK 模式的基础 URL。填入后将绕过 GitHub 官方服务。 |
-| `llm_api_key` | - | BYOK 模式的 API 密钥。 |
-| `llm_model_id` | `gpt-4o` | 使用的模型 ID (官方、BYOK 均适用)。 |
-| `workspace_root` | `./copilot_workspaces` | 所有会话沙盒的根目录。 |
-| `skills_directory` | `./copilot_skills` | 自定义 SDK 技能文件夹所在的目录。 |
-| `show_status` | `True` | 是否在 UI 显示 Agent 的实时运行状态和思考过程。 |
-| `enable_infinite_session` | `True` | 是否开启自动上下文压缩和 TODO 列表持久化。 |
-| `enable_html_artifacts` | `True` | 是否允许 Agent 生成并实时预览 HTML 应用。 |
-| `enable_rich_ui` | `True` | 是否启用进度条和增强型工具调用面板。 |
+### 1. 导入函数
+
+1. 打开 OpenWebUI，进入 **Workspace** -> **Functions**。
+2. 点击 **+**（Create Function），粘贴 `github_copilot_sdk.py` 内容。
+3. 保存并确保已启用。
+
+### 2. 获取 Token
+
+1. 访问 [GitHub Token Settings](https://github.com/settings/tokens?type=beta)。
+2. 创建 **Fine-grained token**，授予 **Account permissions** -> **Copilot Requests** 权限。
+3. 将生成的 Token 填入 `GH_TOKEN`。
+
+### 3. 认证要求（必填其一）
+
+必须至少配置一种凭据来源：
+
+- `GH_TOKEN`（GitHub Copilot 官方订阅路线），或
+- `BYOK_API_KEY`（OpenAI / Anthropic 自带 Key 路线）。
+
+如果两者都未配置，模型列表将不会显示。

 ---

@@ -104,7 +155,13 @@

 ## ⚠️ 故障排除 (Troubleshooting)

- **工具无法使用?** 请检查是否安装了 `github-copilot-sdk`。
- **文件找不到?** 确保已启用配套的 `Files Filter` 插件。
- **BYOK 报错?** 确认 `llm_base_url` 包含协议前缀（如 `https://`）且模型 ID 准确无误。
- **卡在 "Thinking..."?** 检查后端网络连接，流式传输可能受某些代理拦截。
+- **工具无法使用?** 请先确认 OpenWebUI Tools / MCP / OpenAPI Server 已在对应设置中启用。
+- **文件找不到?** 确保已启用配套的 `Files Filter` 插件，否则 RAG 可能会提前消费原始文件。
+- **BYOK 报错?** 确认 `BYOK_BASE_URL` 包含正确协议前缀（如 `https://`），且模型 ID 准确无误。
+- **卡在 "Thinking..."?** 检查后端网络连接，或打开 `DEBUG` 查看更详细的 SDK 日志。
+
+---
+
+## Changelog
+
+完整历史请查看 GitHub 项目主页：[OpenWebUI Extensions](https://github.com/Fu-Jie/openwebui-extensions)
--- a/docs/plugins/pipes/index.md
+++ b/docs/plugins/pipes/index.md
@@ -15,7 +15,7 @@ Pipes allow you to:

 ## Available Pipe Plugins

- [GitHub Copilot SDK](github-copilot-sdk.md) (v0.9.1) - Official GitHub Copilot SDK integration. Features **Workspace Isolation**, **Zero-config OpenWebUI Tool Bridge**, **BYOK** support, and **dynamic MCP discovery**. **NEW in v0.9.1: MCP filter reliability fix** for `server:mcp:{id}` chat selection and function filter consistency. [View Deep Dive](github-copilot-sdk-deep-dive.md) | [**View Advanced Tutorial**](github-copilot-sdk-tutorial.md) | [**View Detailed Usage Guide**](github-copilot-sdk-usage-guide.md).
+- [GitHub Copilot SDK](github-copilot-sdk.md) (v0.10.0) - Official GitHub Copilot SDK integration. Features **Workspace Isolation**, **Zero-config OpenWebUI Tool Bridge**, **BYOK** support, and **dynamic MCP discovery**. **NEW in v0.10.0: Native Prompt Restoration (Plan Mode & SQLite session management), Live TODO Widget integration, and SDK v0.1.30 alignment**. [View Deep Dive](github-copilot-sdk-deep-dive.md) | [**View Advanced Tutorial**](github-copilot-sdk-tutorial.md) | [**View Detailed Usage Guide**](github-copilot-sdk-usage-guide.md).
 - **[Case Study: GitHub 100 Star Growth Analysis](star-prediction-example.md)** - Learn how to use the GitHub Copilot SDK Pipe with Minimax 2.1 to automatically analyze CSV data and generate project growth reports.
 - **[Case Study: High-Quality Video to GIF Conversion](video-processing-example.md)** - See how the model uses system-level FFmpeg to accelerate, scale, and optimize colors for screen recordings.

--- a/docs/plugins/pipes/index.zh.md
+++ b/docs/plugins/pipes/index.zh.md
@@ -15,7 +15,7 @@ Pipes 可以用于：

 ## 可用的 Pipe 插件

- [GitHub Copilot SDK](github-copilot-sdk.zh.md) (v0.9.1) - GitHub Copilot SDK 官方集成。具备**工作区安全隔离**、**零配置工具桥接**与**BYOK (自带 Key) 支持**。**v0.9.1 更新：MCP 过滤可靠性修复**，修正 `server:mcp:{id}` 聊天选择匹配并提升函数过滤一致性。[查看深度架构解析](github-copilot-sdk-deep-dive.zh.md) | [**查看进阶实战教程**](github-copilot-sdk-tutorial.zh.md) | [**查看详细使用手册**](github-copilot-sdk-usage-guide.zh.md)。
+- [GitHub Copilot SDK](github-copilot-sdk.zh.md) (v0.10.0) - GitHub Copilot SDK 官方集成。具备**工作区安全隔离**、**零配置工具桥接**与**BYOK (自带 Key) 支持**。**v0.10.0 更新：原生提示词恢复（原生计划模式与 SQLite 会话管理）、新增紧凑型 Live TODO 小组件，并对齐 SDK v0.1.30**。[查看深度架构解析](github-copilot-sdk-deep-dive.zh.md) | [**查看进阶实战教程**](github-copilot-sdk-tutorial.zh.md) | [**查看详细使用手册**](github-copilot-sdk-usage-guide.zh.md)。
 - **[实战案例：GitHub 100 Star 增长预测](star-prediction-example.zh.md)** - 展示如何使用 GitHub Copilot SDK Pipe 结合 Minimax 2.1 模型，自动编写脚本分析 CSV 数据并生成详细的项目增长报告。
 - **[实战案例：视频高质量 GIF 转换与加速](video-processing-example.zh.md)** - 演示模型如何通过底层 FFmpeg 工具对录屏进行加速、缩放及双阶段色彩优化处理。