diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 6509ed6..07daa33 100644 --- a/.obsidian/workspace.json +++ b/.obsidian/workspace.json @@ -4,16 +4,16 @@ "type": "split", "children": [ { - "id": "4463cbe9dee439a2", + "id": "0ddfa9cb1742e1c8", "type": "tabs", "children": [ { - "id": "bf4a47cd3f5340ef", + "id": "54f7f9fc497f0e6c", "type": "leaf", "state": { "type": "markdown", "state": { - "file": "1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md", + "file": "InBox/未看的帖子.md", "mode": "source", "source": false, "backlinks": true, @@ -28,7 +28,7 @@ } }, "icon": "lucide-file", - "title": "离全自动发起PR有多远" + "title": "未看的帖子" } } ] @@ -202,44 +202,43 @@ "copilot:Open Copilot Chat": false } }, - "active": "bf4a47cd3f5340ef", + "active": "54f7f9fc497f0e6c", "lastOpenFiles": [ - "1Project/大富翁Demo/关于AI/护栏与AI.md", - "1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md", "笔记数据库.base", + "InBox/未看的帖子.md", + "InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md", + "InBox/Cursor 持续改进智能体框架 - 2026-04-30.md", + "InBox/Harness Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用 学不会我_BV1Hn9UBrEsH_P1_笔记.md", + "InBox/Hermes编排Agent_Web可观测性方案.md", + "InBox/Karpathy_harness_llm_wiki.md", + "InBox/知乎文章_2033520572144030920.md", + "1Project/大富翁Demo/未命名.md", + "1Project/大富翁Demo/甘特图.md", + "1Project/AI工程/AI for 测试/工作流.md", + "1Project/AI工程/AI for 测试/AirTest.md", + "1Project/AI工程/AI for 测试/单元测试.md", + "1Project/AI工程/AI for Fgui/工作流.md", + "1Project/AI工程/AI for Fgui/协议.md", + "1Project/AI工程/AI for 性能检测管线/未命名.md", + "1Project/大富翁Demo/关于AI/离全自动发起PR有多远.md", + "1Project/大富翁Demo/关于AI/护栏与AI.md", + "1Project/AI工程/AI for 测试", + "1Project/AI工程/AI for 性能检测管线", + "1Project/AI工程/AI for Fgui", + "1Project/AI工程", + "InBox/AutoHarness-论文解读.md", + "InBox/AGENTS.md_待看.md", + "InBox/Agent上下文管理策略_待看.md", + "InBox/介绍状态同步战斗玩法的设计和实现.md", + "InBox/测试笔记_共享转移_20250320.md", + "InBox/20260211-180200-VContainer-Unity-DI-文档笔记.md", + "InBox/v2ex_1196441_大模型变笨讨论.md", "1Project/大富翁Demo/关于AI", "1Project/大富翁Demo", "未命名 1.base", "未命名.base", "卡片数据库.base", "卡片盒skill.md", - "查询数据skill.md", - "00-Home.md", - "copilot-custom-prompts/Remove URLs.md", - "copilot-custom-prompts/Make shorter.md", - "copilot-custom-prompts/Explain like I am 5.md", - "copilot-custom-prompts/Emojify.md", - "1Project/GPU地形/地形优化.md", - "1Project/理财.md", - "1Project/GPU地形/Houdini PCG.md", - "1Project/GPU地形/GPU地形-目录.md", - "1Project/GPU地形/GPU Driven Terrain 跟学与实现.md", - "1Project/GPU地形/ComputeShader生成无限世界地形.md", - "1Project/海量渲染战斗/批量渲染gpu动画.md", - "1Project/外包/Project_城堡/_城堡.md", - "1Project/海量渲染战斗/基于GPU蒙皮动画的Spine实现.md", - "1Project/海量渲染战斗/基于GPU动画和ComputeShader的大批量动画渲染Demo（一）之GPU顶点动画.md", - "1Project/海量渲染战斗/海量渲染战斗-目录.md", - "1Project/海量渲染战斗/GPU动画工程/TODO转为Job组织数据.md", - "1Project/海量渲染战斗/GPU动画工程/TODO将Time存进buffer中，做成不同的实例可以使用不同的动画时间.md", - "1Project/海量渲染战斗/GPU动画工程/TODO不同动作存进Buffer中.md", - "1Project/海量渲染战斗/GPU动画工程/TODO 不同动作间的混合.md", - "1Project/海量渲染战斗/GPU动画工程/GPU蒙皮动画.md", - "1Project/海量渲染战斗/GPU动画工程/GPU顶点动画.md", - "skills/obsidian-markdown", - "skills/obsidian-bases", - "skills/json-canvas", - "skills", "渲染/软渲染/图片/9702b7cbafa93d6e3d0cd59e7cf37e31.png", "渲染/软渲染/图片/86aa46af36c4c3b1f1efef2a1ccc6310.png", "渲染/软渲染/图片/62ad22d3e981954fc083018fb850413a.png", diff --git a/.omx/context/scheduled-task-git-sync-gant-20260429T161523Z.md b/.omx/context/scheduled-task-git-sync-gant-20260429T161523Z.md new file mode 100644 index 0000000..8ab36f3 --- /dev/null +++ b/.omx/context/scheduled-task-git-sync-gant-20260429T161523Z.md @@ -0,0 +1,50 @@ +# Context Snapshot: scheduled-task-git-sync-gant + +## Task Statement +为该路径添加一个定时任务，每天晚上十点半的时候 git pull & push，然后把 inbox 中的内容使用 skill:gant + +## Desired Outcome +A nightly scheduled task at 22:30 that: +1. Syncs the repo via `git pull && git push` +2. Processes InBox markdown notes through the `gant-cli` skill + +## Stated Solution +Add a cron/scheduled task running at 22:30 daily + +## Probable Intent Hypothesis +User wants automated end-of-day sync of Obsidian notes to Gitee remote, plus automatic conversion of inbox notes into Gantt task manager entries. This suggests a daily capture → organize → sync workflow. + +## Known Facts +- Repo: `C:\app\unity_project\obsidian-notes` +- Remote: `https://gitee.com/zzzisfunnyboy/obsidian-notes.git` (Gitee) +- InBox currently contains 4 `.md` files +- Git has uncommitted changes: `.obsidian/workspace.json` (modified) + one untracked InBox file +- `gant-cli` skill: manages Gantt desktop tasks via `gant.exe`/`gantt-app.exe` CLI (list, add, update, delete, lock) +- Platform: Windows, shell: bash +- No existing `.omx/context/` snapshots +- Claude Code `CronCreate` tool exists for scheduling recurring tasks + +## Constraints +- Must use Claude Code's `CronCreate` (not Windows Task Scheduler or system cron) +- Git operations need to handle potential merge conflicts gracefully +- InBox processing: what exactly should happen to inbox files after processing? (Move? Delete? Leave?) + +## Unknowns / Open Questions +1. **What does "process InBox content with skill:gant" mean concretely?** Extract tasks from each markdown note into Gantt? Convert the whole note into a Gantt task? Something else? +2. **What should happen to InBox files after processing?** Delete them? Move them to an archive? Mark as processed? +3. **Should the scheduled task also commit local changes before push?** Currently there are uncommitted modifications. +4. **What's the relationship between Obsidian notes and Gantt tasks?** Is there a specific format or template? +5. **Error handling expectations?** What if git pull has conflicts? What if gantt-app isn't running? +6. **Is the gantt-app.exe path known and stable?** + +## Decision-Boundary Unknowns +- Whether to auto-commit changes or only pull/push +- How to handle InBox files post-processing (archive vs delete) +- Error notification strategy (silent fail? log? notify?) +- Whether this should be durable (persist across Claude sessions) + +## Likely Codebase Touchpoints +- Cron job: `CronCreate` tool or `.claude/scheduled_tasks.json` +- Git operations: bash commands +- Gantt integration: `gant-cli` skill invocation +- InBox: `C:\app\unity_project\obsidian-notes\InBox\` directory diff --git a/.omx/interviews/scheduled-task-git-sync-gant-20260429T161523Z.md b/.omx/interviews/scheduled-task-git-sync-gant-20260429T161523Z.md new file mode 100644 index 0000000..15d7451 --- /dev/null +++ b/.omx/interviews/scheduled-task-git-sync-gant-20260429T161523Z.md @@ -0,0 +1,30 @@ +# Interview Transcript: scheduled-task-git-sync-gant + +**Profile:** Standard +**Timestamp:** 20260429T161523Z +**Final Ambiguity:** 0.16 +**Threshold:** 0.20 +**Type:** Brownfield + +## Round Summary + +| R | Target | Focus | Key Finding | +|---|--------|-------|-------------| +| 1 | Intent | Why automate? | Goal: InBox notes auto-appear in Gantt chart, eliminating manual transfer | +| 2 | Outcome | Concrete format | Gantt task format: `待看:{文件名}` | +| 3 | Outcome | Post-processing | InBox files stay; deleted files → tasks removed from Gantt; de-duplicated | +| 4 | Scope | Git range | Only `PARA/` and `InBox/` folders | +| 5 | Scope | Auto-commit | Auto `add PARA/ InBox/ && commit -m "auto nightly sync"` before push | +| 6 | Constraints | Gantt offline | Silent skip, try next day | +| 7 | Decision Boundaries | Technical choices | abort on merge conflict; push failure → Windows toast notification | +| 8 | Non-goals | Persistence model | User wants system-level script, not Claude session-dependent | +| 9 | Constraints | Trigger mechanism | Windows Task Scheduler, self-chosen | +| 10 | Success Criteria | Verification | 10:30 PM: open Gantt chart, see expected "待看:xxx" tasks | +| 11 | Non-goals | Boundaries | Only PARA/InBox git, only "待看" task type, only .md files | +| 12 | Decision Boundaries | Remaining choices | Script alongside gantt-app.exe; toast notifications; no log; update existing | + +## Exposed Assumptions +- gantt-app.exe CLI supports add/delete/list/toggle-lock operations +- Windows Task Scheduler can trigger bash scripts +- Git merge conflicts are rare enough that abort is acceptable +- User's computer is on at 22:30 diff --git a/.omx/plans/autopilot-impl.md b/.omx/plans/autopilot-impl.md new file mode 100644 index 0000000..170fa6d --- /dev/null +++ b/.omx/plans/autopilot-impl.md @@ -0,0 +1,69 @@ +# Implementation Plan: InBox → Gantt Nightly Sync + +## Source of Truth +- Spec: `.omx/specs/deep-interview-scheduled-task-git-sync-gant.md` +- Context: `.omx/context/scheduled-task-git-sync-gant-20260429T161523Z.md` + +## Architecture + +``` +Windows Task Scheduler (22:30 daily) + └─ powershell.exe -ExecutionPolicy Bypass -File "sync-inbox-to-gantt.ps1" + ├─ 1. Git sync (pull, add, commit, push) + ├─ 2. Gantt bidirectional mirror (InBox ↔ Gantt "待看:*" tasks) + └─ 3. Notifications (push failure toast) +``` + +## Files to Create + +| File | Path | Purpose | +|------|------|---------| +| Sync script | `C:\Users\Zane\Desktop\Gantt App\sync-inbox-to-gantt.ps1` | Main nightly script | +| Setup script | `C:\app\unity_project\obsidian-notes\.omx\setup-task.ps1` | One-shot Task Scheduler registration | + +## Algorithm + +### Phase A — Git Sync +1. `cd C:\app\unity_project\obsidian-notes` +2. `git pull` — if conflict → `git merge --abort` → exit git phase +3. `git add PARA/ InBox/` +4. `git diff --cached --quiet` → if no changes, skip commit +5. `git commit -m "auto nightly sync"` +6. `git push` — if failure → Show-Toast "Git push failed" → continue + +### Phase B — Gantt Mirror +1. Call `gantt-app.exe --cli list-tasks` → parse JSON + - If Gantt not running (process error / non-zero exit) → skip phase B +2. Extract `"待看:*"` tasks → set `{baseName}` from task name +3. Scan `InBox\*.md` → set `{baseName}` from filename (strip .md) +4. **Add**: For each InBox file NOT in Gantt → `add-task --name "待看:{baseName}" --start {today} --end "" --progress 0` +5. **Delete**: For each Gantt "待看:*" NOT in InBox → `delete-task --id {id}` +6. **Existing matches**: No-op (already correct) + +### Error Handling Matrix + +| Failure | Behavior | +|---------|----------| +| Git pull conflict | `git merge --abort`, skip rest of git phase | +| Git push fails | PowerShell toast notification, continue to Gantt phase | +| Gantt CLI not found | Write-Error, exit 1 | +| Gantt not running | Skip Gantt phase silently | +| Gantt add/delete fails | Write-Error for that item, continue | +| Script not in gantt dir | Resolve gantt dir from script location dynamically | + +## Task Scheduler Registration + +```powershell +$action = New-ScheduledTaskAction -Execute "powershell.exe" ` + -Argument "-ExecutionPolicy Bypass -File `"C:\Users\Zane\Desktop\Gantt App\sync-inbox-to-gantt.ps1`"" +$trigger = New-ScheduledTaskTrigger -Daily -At 22:30 +Register-ScheduledTask -TaskName "InBox-Gantt-Nightly-Sync" ` + -Action $action -Trigger $trigger -RunLevel Highest ` + -Description "Nightly sync Obsidian InBox to Gantt tasks with git auto-commit" +``` + +## Implementation Tasks + +1. **Create sync-inbox-to-gantt.ps1** — the main sync script with all logic +2. **Create setup-task.ps1** — registers the scheduled task +3. **Manual dry-run test** — run script manually, verify Gantt tasks created diff --git a/.omx/setup-task.ps1 b/.omx/setup-task.ps1 new file mode 100644 index 0000000..0aa8367 --- /dev/null +++ b/.omx/setup-task.ps1 @@ -0,0 +1,25 @@ +# setup-task.ps1 +# Register the nightly InBox→Gantt sync task in Windows Task Scheduler. +# Run once, as Administrator. + +$taskName = "InBox-Gantt-Nightly-Sync" +$scriptPath = "C:\Users\Zane\Desktop\Gantt-App\sync-inbox-to-gantt.ps1" + +# Remove existing task if present +$existing = Get-ScheduledTask -TaskName $taskName -ErrorAction SilentlyContinue +if ($existing) { + Unregister-ScheduledTask -TaskName $taskName -Confirm:$false + Write-Host "Removed existing task: $taskName" +} + +$action = New-ScheduledTaskAction -Execute "powershell.exe" ` + -Argument "-NoProfile -ExecutionPolicy Bypass -WindowStyle Hidden -File `"$scriptPath`"" +$trigger = New-ScheduledTaskTrigger -Daily -At 22:30 +$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable + +Register-ScheduledTask -TaskName $taskName ` + -Action $action -Trigger $trigger -Settings $settings ` + -Description "Nightly: git sync PARA/InBox + mirror InBox .md files to Gantt '待看:*' tasks" + +Write-Host "Task '$taskName' registered. Next run: $(Get-Date -Format 'yyyy-MM-dd') 22:30" +Write-Host "Script: $scriptPath" diff --git a/.omx/specs/deep-interview-scheduled-task-git-sync-gant.md b/.omx/specs/deep-interview-scheduled-task-git-sync-gant.md new file mode 100644 index 0000000..17ad9b5 --- /dev/null +++ b/.omx/specs/deep-interview-scheduled-task-git-sync-gant.md @@ -0,0 +1,85 @@ +# Spec: Deep Interview — scheduled-task-git-sync-gant + +## Metadata +- **Profile:** Standard +- **Rounds:** 12 +- **Final Ambiguity:** 0.16 +- **Threshold:** 0.20 (met) +- **Type:** Brownfield +- **Context Snapshot:** `.omx/context/scheduled-task-git-sync-gant-20260429T161523Z.md` + +## Clarity Breakdown + +| Dimension | Weight | Score | Notes | +|-----------|--------|-------|-------| +| Intent | 0.25 | 0.85 | InBox notes visible in Gantt chart without manual steps | +| Outcome | 0.20 | 0.85 | New → added, deleted → removed, existing → de-duplicated | +| Scope | 0.20 | 0.85 | PARA/InBox git only; "待看" type only; .md files only | +| Constraints | 0.15 | 0.80 | Win Task Scheduler; gantt-app.exe; toast; abort on conflict; no logs | +| Success | 0.10 | 0.80 | At 22:30, Gantt shows "待看:xxx" for all InBox .md files | +| Context | 0.10 | 0.90 | Well-understood repo and tooling | +| **Weighted** | | **0.84** | Ambiguity = 0.16 | + +## Intent +用户希望每晚 22:30 自动将 InBox 中的待读笔记同步到甘特图软件中，消除手动搬运步骤。 + +## Desired Outcome +- 甘特图出现所有 InBox 中 `.md` 文件对应的 "待看:{文件名}" 任务 +- 已存在的不重复添加（更新） +- InBox 中已删除的文件对应任务也从甘特图中移除 +- Git 自动拉取/提交/推送 PARA/ 和 InBox/ 目录 + +## In-Scope +1. 每晚 22:30 通过 Windows Task Scheduler 触发 +2. `git pull && git add PARA/ InBox/ && git commit -m "auto nightly sync" && git push` +3. 扫描 InBox/*.md，为每个文件在甘特图创建/更新 "待看:{文件名}" 任务 +4. 检测甘特图中已存在的 "待看:xxx" 任务，若 InBox 中对应文件已删除则移除 +5. 去重：已在甘特图中的任务不重复创建，仅更新 +6. 脚本文件与 gantt-app.exe 放在同一目录 + +## Out-of-Scope / Non-goals +1. 不操作 PARA/ 和 InBox/ 之外的任何文件 +2. 不创建 "待看" 之外的甘特图任务类型 +3. 不处理非 `.md` 文件 + +## Decision Boundaries (OMX 可自行决定) +- 具体用哪个 Windows 通知 API（PowerShell toast / `msg` / 其他） +- Git commit 消息的具体格式 +- 脚本语言选择（bash / PowerShell / 混合） +- 甘特图 CLI 的 command/subcommand 细节（从 gant-cli skill 获取） + +## Constraints +- **触发机制:** Windows Task Scheduler（非 Claude session 依赖） +- **甘特图 CLI:** `gantt-app.exe` +- **脚本位置:** 与 gantt-app.exe 同目录 +- **Git 冲突:** abort（保留本地） +- **Push 失败:** Windows 右下角 toast 通知 +- **甘特图未运行:** 静默跳过，次日重试 +- **日志:** 不需要 +- **重名任务:** 更新而非跳过 +- **持久化:** 无 Claude session 依赖（系统级调度） + +## Testable Acceptance Criteria +- [ ] 晚上 22:30，打开甘特图能看到所有 InBox/*.md 对应的 "待看:{文件名}" 任务 +- [ ] 在 InBox 中新增一个 .md 文件 → 下次执行后甘特图出现对应任务 +- [ ] 在 InBox 中删除一个 .md 文件 → 下次执行后甘特图移除对应任务 +- [ ] 非 .md 文件被忽略 +- [ ] PARA/ 和 InBox/ 外文件不受 git 影响 +- [ ] Git 冲突时 abort 不丢数据 +- [ ] 甘特图未运行时脚本不崩溃 + +## Assumptions Exposed + Resolved +1. **gantt-app.exe CLI 能力:** 假设支持 add/delete/list 操作 → 实现时通过 gant-cli skill 确认 +2. **Session-only vs durable:** 初始误解为 Claude session 调度 → 澄清为系统级 Windows Task Scheduler +3. **文件处理后:** 最初未明确 → 澄清为保留文件、双向同步 + +## Pressure-Pass Findings +- Round 2 追问了具体格式（"到底长什么样"）→ 从模糊的"处理"收缩到 `待看:{标题}` +- Round 8 追问了 session-only 假设 → 推翻了 CronCreate 方案，转向系统级 Task Scheduler +- Round 11 追问了明确的 non-goals → 三条边界锁定 + +## Handoff Contract +This spec is the requirements source of truth. Downstream execution must preserve: +- Intent, non-goals, decision boundaries, and acceptance criteria +- The bidirectional mirror model (InBox ↔ Gantt) +- System-level scheduling (not Claude session-dependent) diff --git a/InBox/Harness Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用 学不会我_BV1Hn9UBrEsH_P1_笔记.md b/InBox/Harness Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用 学不会我_BV1Hn9UBrEsH_P1_笔记.md deleted file mode 100644 index 1211b26..0000000 --- a/InBox/Harness Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用 学不会我_BV1Hn9UBrEsH_P1_笔记.md +++ /dev/null @@ -1,320 +0,0 @@ -# Harness Engineering 最佳实践：Agent Harness 底层原理、核心组件与实战应用 - -## 目录 - -1. [AI 工程师的岗位分层体系](#1-ai-工程师的岗位分层体系) -2. [大模型应用的三层进化范式](#2-大模型应用的三层进化范式) -3. [Prompt Engineering：让模型"会说"](#3-prompt-engineering让模型会说) -4. [Context Engineering：解决上下文膨胀问题](#4-context-engineering解决上下文膨胀问题) -5. [Agent Harness 核心架构](#5-agent-harness-核心架构) -6. [Harness Engineering 的工程实践](#6-harness-engineering-的工程实践) - ---- - -## 1. AI 工程师的岗位分层体系 - -### 1.1 三层架构概述 - -在 2026 年，AI 工程师可分为三个层级，每个层级有明确的技术侧重点： - -| 层级 | 定位 | 核心职责 | 技术侧重 | -|------|------|----------|----------| -| **AI 产品化** | AI 产品经理、AI 解决方案架构师 | 发现 AI 价值场景，重塑业务流程 | 业务分析、产品设计 | -| **AI 应用层** | AI 应用工程师、大模型应用开发 | 业务方案落地，AI 赋能场景 | Prompt Engineering、Context Engineering、RAG | -| **AI 大模型算法层** | 模型研发工程师 | 提升模型垂直能力 | SFT 微调、RLHF 对齐、安全护栏 | - -### 1.2 各层级的核心差异 - -**AI 产品化层**： -- 聚焦于找到 AI 的价值场景 -- 重新定义业务产品线 -- 属于业务与产品方向 - -**AI 应用层**（Harness Engineering 的落地层）： -- 偏业务 + 方案落地 -- 利用开源模型构建垂直应用 -- 2026 年最稀缺、最具机会的方向 - -**AI 大模型算法层**： -- 不做基座模型（GPT-4、Qwen3.6 等基座由大厂完成） -- 聚焦于模型的**垂直能力提升** -- 包括： - - **SFT 微调**（Supervised Fine-Tuning） - - **RLHF**（Reinforcement Learning from Human Feedback） - - **对齐训练**（Alignment） - - **安全护栏**（Safety Guardrails） - -### 1.3 职业选择建议 - -``` -技术背景 → AI 应用层（最佳入场点） -产品背景 → AI 产品化层 → 可延伸至应用层 -算法背景 → AI 大模型算法层 -``` - -> **核心观点**：2026 年是**大模型应用落地**的关键年份，大多数人的机会在于 AI 应用层。 - ---- - -## 2. 大模型应用的三层进化范式 - -从时间维度看，AI 应用开发经历了三个阶段的范式转变： - -``` -2022-2024：Prompt Engineering 时代 - ↓ -2025：Context Engineering 时代 - ↓ -2026：Agent Harness / Harness Engineering 时代 -``` - ---- - -## 3. Prompt Engineering：让模型"会说" - -### 3.1 时间窗口 - -2022 年 11 月 ChatGPT 发布后成为焦点 - -### 3.2 核心问题 - -**解决"如何说"的问题**——如何更好地与模型沟通，让模型生成更高质量的回答。 - -### 3.3 技术特征 - -- 单对单对话模式 -- 用户输入一句话，模型返回一句话 -- 关注点：如何编写有效的 Prompt - -### 3.4 典型场景 - -``` -用户 → Prompt → LLM → Response -``` - ---- - -## 4. Context Engineering：解决上下文膨胀问题 - -### 4.1 时间窗口 - -2025 年 - -### 4.2 核心问题 - -随着 Agent 开发引入工具调用（如 MCP 协议），上下文窗口中的内容越来越多，导致模型能力反而下降、**幻觉（Hallucination）** 问题加剧。 - -### 4.3 核心目标 - -**解决"有什么"的问题**——让模型清楚地知道当前拥有哪些信息。 - -### 4.4 关键概念 - -**Context Window（上下文窗口）**： -- 多轮对话的执行过程中，所有历史信息都存储在上下文窗口中 -- 当内容越来越多时，模型会出现"迷失"现象 - -**迷失问题（Lost in Context）**： -- 模型在大量上下文中无法准确识别关键信息 -- 导致： - - 响应质量下降 - - 幻觉增加 - - 任务执行失败 - -### 4.5 Context Engineering 的职责 - -| 问题 | 解决方案 | -|------|----------| -| 上下文过长 | 上下文压缩、摘要 | -| 信息混乱 | 结构化组织、分类管理 | -| 关键信息被淹没 | 关键信息突出、检索增强 | - ---- - -## 5. Agent Harness 核心架构 - -### 5.1 官方来源 - -本文档基于 **LangChain 团队**发布的关于 Agent Harness 的官方博客，是全球最懂 Agent 的团队发布的系统性技术文档。 - -### 5.2 Agent Harness 的定位 - -**Harness** 的本意是"驾驭、利用"，Agent Harness 即对 Agent 的工程化驾驭框架。 - -### 5.3 核心架构体系 - -``` -┌─────────────────────────────────────────┐ -│ Agent Harness │ -├─────────────────────────────────────────┤ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 规划层 │ │ 执行层 │ │ -│ │ Planning │ │ Execution │ │ -│ └─────────────┘ └─────────────────┘ │ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 工具层 │ │ 记忆层 │ │ -│ │ Tools │ │ Memory │ │ -│ └─────────────┘ └─────────────────┘ │ -│ ┌─────────────┐ ┌─────────────────┐ │ -│ │ 感知层 │ │ 评估层 │ │ -│ │ Perception │ │ Evaluation │ │ -│ └─────────────┘ └─────────────────┘ │ -└─────────────────────────────────────────┘ -``` - -### 5.4 各层核心组件详解 - -#### 5.4.1 规划层（Planning） - -**职责**：将复杂任务分解为可执行的子任务 - -**关键技术**： -- **任务分解**（Task Decomposition） -- **思维链**（Chain of Thought, CoT） -- **子任务规划** - -#### 5.4.2 执行层（Execution） - -**职责**：执行规划层生成的子任务 - -**关键技术**： -- **工具调用**（Tool Calling） -- **动作执行**（Action Execution） -- **结果反馈** - -#### 5.4.3 工具层（Tools） - -**职责**：为 Agent 提供外部能力 - -**典型工具类型**： -- **MCP 工具**（Model Context Protocol） -- API 调用 -- 搜索引擎 -- 数据库查询 -- 文件系统操作 - -#### 5.4.4 记忆层（Memory） - -**职责**：存储和管理 Agent 的历史状态与上下文 - -**记忆类型**： -| 类型 | 说明 | 用途 | -|------|------|------| -| 短期记忆 | 当前对话上下文 | 处理即时任务 | -| 长期记忆 | 持久化存储 | 跨会话经验积累 | -| 工作记忆 | 工作过程中的临时状态 | 任务执行中间态 | - -#### 5.4.5 感知层（Perception） - -**职责**：接收和处理外部输入 - -**感知内容**： -- 用户指令 -- 文档输入 -- 多模态信息（图像、音频等） -- 环境状态 - -#### 5.4.6 评估层（Evaluation） - -**职责**：评估 Agent 执行结果的质量 - -**评估维度**： -- 输出正确性 -- 任务完成度 -- 安全性检查 -- 效率评估 - ---- - -## 6. Harness Engineering 的工程实践 - -### 6.1 定义 - -**Harness Engineering** 是系统性地构建、测试、优化 Agent 行为能力的工程学科。 - -### 6.2 与传统软件工程的区别 - -| 维度 | 传统软件工程 | Harness Engineering | -|------|-------------|---------------------| -| 不确定性 | 低（确定性逻辑） | 高（概率性输出） | -| 测试难度 | 可精确断言 | 需概率评估 | -| 调试方法 | 日志追踪 | 行为轨迹分析 | -| 质量保障 | 单元测试 + 集成测试 | 评估驱动开发 | - -### 6.3 核心工程实践 - -#### 6.3.1 评估驱动开发（Evaluation-Driven Development） - -``` -设计评估指标 → 开发 Agent → 持续评估 → 迭代优化 -``` - -#### 6.3.2 行为可复现性 - -- 通过种子（seed）控制随机性 -- 构建可测试的 Agent 行为 -- 建立回归测试机制 - -#### 6.3.3 多维度评测 - -- **任务完成率**：Agent 是否完成目标 -- **效率指标**：消耗的 Token 数量、执行时间 -- **质量评分**：输出的人力评估 -- **安全性检查**：有害内容过滤 - -### 6.4 LangChain Agent Harness 的工具链 - -``` -┌──────────────────────────────────────────┐ -│ LangChain 生态 │ -├──────────────────────────────────────────┤ -│ LangChain │ Agent 开发框架 │ -│ LangSmith │ 追踪与评估平台 │ -│ LangServe │ Agent 部署服务 │ -│ LangGraph │ Agent 工作流编排 │ -└──────────────────────────────────────────┘ -``` - ---- - -## 7. 补充：观众反馈中的有价值观点 - -> 本节整理自视频弹幕中观众的补充与讨论 - -### 7.1 关于 Context Engineering 的延伸 - -- Context Engineering 不仅解决"上下文膨胀"，还需要考虑**信息密度**问题 -- 有效上下文 = 去除噪音后的核心信息 -- 常用的压缩策略：LLM 摘要、关键信息提取、信息去重 - -### 7.2 关于 Agent 幻觉的处理 - -- 幻觉问题在单轮对话中已存在 -- 在多轮 Agent 执行中，幻觉会被**级联放大** -- 建议在每个关键步骤增加**自我校验**机制 - -### 7.3 关于实际落地的建议 - -- 不要过度追求 Agent 的自主性，**人机协同**往往更可靠 -- 初期应聚焦垂直场景，积累领域知识后再扩展 - ---- - -## 附录：关键术语表 - -| 英文术语 | 中文解释 | -|----------|----------| -| **Harness Engineering** | 驾驭工程，Agent 的系统工程化方法 | -| **Agent Harness** | Agent 框架的核心组件集合 | -| **Prompt Engineering** | 提示词工程，优化人机交互质量 | -| **Context Engineering** | 上下文工程，管理信息输入质量 | -| **Hallucination** | 幻觉，LLM 生成虚假或不准确内容 | -| **Chain of Thought (CoT)** | 思维链，引导模型展示推理过程 | -| **SFT** | Supervised Fine-Tuning，有监督微调 | -| **RLHF** | Reinforcement Learning from Human Feedback，基于人类反馈的强化学习 | -| **MCP** | Model Context Protocol，模型上下文协议 | -| **Agent** | 智能体，能够自主执行任务的 AI 系统 | - ---- - -> **笔记说明**：本笔记基于 LangChain 团队发布的官方博客整理，聚焦于 Agent Harness 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。 \ No newline at end of file diff --git a/InBox/Hermes编排Agent_Web可观测性方案.md b/InBox/Hermes编排Agent_Web可观测性方案.md deleted file mode 100644 index 823d9fb..0000000 --- a/InBox/Hermes编排Agent_Web可观测性方案.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Hermes 编排 Agent + Web 可观测性方案 -date: 2026-04-29 -tags: [Hermes, Agent编排, ttyd, tmux, 可观测性] ---- - -# Hermes 编排 Agent + Web 可观测性方案 - -## 背景 - -Hermes 作为母 Agent 编排不同的子 Agent（Codex、Claude Code 等），但全部在后台运行，无法直观看到每个 Agent 的实时输出和进度。需要将后台 tmux session 暴露到 Web 前端观察。 - -## 方案：ttyd + tmux - -**ttyd**（GitHub 31k+ stars）可以把任意终端程序变成 Web 页面，通过 WebSocket 实时推流。 - -### 架构 - -``` -Hermes (编排大脑) - │ - ├─ tmux session codex1 ─── ttyd :8080 ──► http://localhost:8080 - ├─ tmux session claude1 ─── ttyd :8081 ──► http://localhost:8081 - └─ tmux session codex2 ─── ttyd :8082 ──► http://localhost:8082 -``` - -### 使用方式 - -```bash -# 启动 Agent 的 tmux session -tmux new-session -d -s codex1 -x 140 -y 40 -tmux new-session -d -s claude1 -x 140 -y 40 - -# ttyd 暴露每个 session 到 web -ttyd -p 8080 tmux attach -t codex1 & -ttyd -p 8081 tmux attach -t claude1 & - -# 浏览器打开 -open http://localhost:8080 # 看 Codex -open http://localhost:8081 # 看 Claude Code -``` - -### 类似方案 -- **Wetty / Gotty** — 与 ttyd 类似 -- **LangFuse / AgentOps** — 专业 Agent trace 平台，但偏事后日志分析，非实时终端画面 - -### 文件握手通信 - -Agent 之间通过文件交换上下文： - -``` -/tmp/handoff.json # Codex 输出 → Claude Code 读取 -/tmp/instruction.md # Claude Code 重注入指令 → 拉起新 Codex -/tmp/next_prompt.txt # 下一步指令 -``` - -## 关键结论 - -1. **不要** 让 Agent 之间直接互相调用（失控） -2. **要** 用 Hermes 作为中央编排大脑 -3. **用文件作为 Agent 间通信协议** -4. **ttyd 解决实时观察问题**，浏览器多标签同时查看所有 Agent - ---- - -*来源：Hermes Agent 对话 (2026-04-29)* diff --git a/InBox/Karpathy_harness_llm_wiki.md b/InBox/Karpathy_harness_llm_wiki.md deleted file mode 100644 index fd81245..0000000 --- a/InBox/Karpathy_harness_llm_wiki.md +++ /dev/null @@ -1,114 +0,0 @@ -# Karpathy用「harness」彻底终结了RAG - -> 来源: https://mp.weixin.qq.com/s/ABzwrSGeFs1Wv2RUBjLtwg -> 抓取时间: 2025-04-10 - ---- - -假期的时候，Karpathy 大神发了一个llm.wiki的想法。 这条推文火爆了。 - -在LLM Agent时代，分享具体代码或应用的意义正在变弱，现在只需要分享想法，然后把它交给 Claude、Grok 等 Agent，它就可以根据你的需求，自动搭建一个属于你自己的个人知识库。 - -还有最近特别火的各种 personal skill ，同事.skill、前任.skill、自己的skill，甚至卡兹克把自己的创作skills都开源了。。。。 - -整体看下来我觉得它们都在做一件事情：把现实世界里原本只能"看"的东西，编译成 AI 可以持续操作的东西。 - -llm.wiki 在编译知识。创作 skill 编译方法论。persona skill 编译人格。 - -全网的博主都在分享理论。今天我们分享一下如何能跑通这种知识的编译。 - -llm.wiki这套理论虽然看起来就是又一次渐进式披露的实践。 - -但是很多人觉着，这不只是一个 AI 工具，而更像是一种元框架（meta-framework）。它并不依赖某个具体模型或技术栈，而是在尝试定义一种人类与 AI 协作管理知识的方式。随着模型不断迭代、框架持续演进，让 LLM 帮助编译并维护一个持续生长的 Wiki 这一模式，反而具备更长期的稳定性和适用性。 - -## 所以llm.wiki在干什么？ - -过去，大模型使用文档，都是用RAG。问一个要综合五份文档的问题，模型每次都要重新找、重新拼。没有积累。NotebookLM、ChatGPT 的文件上传，其实都是这个模式。 - -但是llm.wiki的模式是： 你丢一份新材料进去，模型不是索引它等着以后检索，而是立刻读它、提炼它、把关键信息编入已有的 wiki。更新实体页、修订概念页、标注新旧数据的矛盾。一份材料可能触及十几个 wiki 页面。 - -而且知识编译一次，然后持续维护。不是每次都从头来。 - -这个模式其实非常有意思，不止可以用在建个人wiki场景，还可以往很多场景拓展，比如记忆。 - -karpathy大佬举了一些场景case，如下图，也很实用。尤其是今天的ai发展的这么快。前脚龙虾，后脚就hermes。上个月的harness，可能这个月就要拆掉一些了。 这种知识的管理。不论是对个人，还是对自己的agent系统都非常重要。 - -正常情况下，如果想打通这种自动wiki工作流，很容易遇到各种奇形怪状的数据。但是llm.wiki 这些，都假设数据是干净的markdown，这还还挺不符合实际场景的。 - -所以，我找了一批更符合真实场景的数据，但是也没有精挑细选。主要是Anthropic、OpenAI关于harness的博客。还有新模型mythos的博客、智谱glm5.1的博客、以及智谱的招股书（本来准备下载财报的，好像下错了，不过这个500多页pdf，也有很多复杂的图表）。 - -然后就可以开始按照llm wiki的要求3层架构构建了。 - -把llm.wiki丢给agent，会自动构建好目录结构。 我用的 cursor + opus 4.6。raw 放原始材料，wiki 放 AI 维护的知识中间层，AGENTS.md 告诉 AI 这个 wiki 怎么组织。 - -整体的一个壳子大概长下面这个样子。 - -然后第一道坎就来了。 - -如果你的实际数据不是规整的txt，或者markdown，ai用pdfplumber转成的markdown就会变成这个样子。文字换行、缩进、表格、图片，这些都没法保留，甚至可能混乱。 - -不管是简单的博客，还是复杂的文档，解析成这个样子其实对模型都特别不友好。 - -还好我用的opus 4.6，对这些东西会鲁棒一些，如果用国产平替估计影响就比较大了。 - -但是。正好，我们最近有一些业务涉及到复杂的word格式文档处理，订阅了合合信息 TextIn 的 API，所以我顺手做了个对比。 - -比如，这是TextIn转写的博客结果，图片和格式排版这些都有保留。 - -TextIn对表格的表示用的是用的html形式的，所以它可以表示更复杂的无线表、合并单元格这些。 - -可以看下图。在招股书的解析里边，图表的结果也非常的不错。 - -最后，还附上TextIn api的耗时参考。目前，这套解析，在我们现在内部的一个业务上跑的还不错。可以在这里测试TextIn的解析：https://cc.co/16YSdj - -搞定预编译之后，开始走 ingest 流程。这里有一个很蠢的坑，模型喜欢偷懒，一次性看一点文档，然后ingest很多的文档。 - -结果每份材料都是浅读，生成的 wiki 页面跟目录没什么区别。信息密度极低。 - -所以这里我优化了一下默认的AGENTS.md，让它一份份处理，超过的还要分段来处理。 - -这个小优化会带来比较明显的数据处理质量的提升。 - -10 份材料全部 ingest 完之后，结构是这样的： - -大概的一个流程是，解析->然后模型会按照AGENTS.md 梳理每份内容的要点，文档要点示例如下： - -然后会整理出实体、概念。 以下是二者的示例。都会有明确的跟其他文件的link关系。 - -concept之间还会自动构建起对比，comparisons示例： - -最后，从结果来看，因为我已经用了最顶级的Opus4.6模型了，所以不论是不是最好的解析方式。 - -带来的wiki结构密度其实差异不大。但是信息密度差异比较大。用TextIn API解析的数据可以保留更多的原始信息，让整个库的信息密度更高。 - -所有有考虑搭建这种自动更新wiki的同学，可以考虑，尽量用最好的解析策略。 - -接下来就可以看出来这种关联wiki的魅力了。 - -比如Harness，我放了4篇博客，包含Ralph Wiggum的反对多Agent的博客，以及OpenAI、Anthropic的相关博客。 - -这样，在Agent Harness概念页就出现了同时容纳了正反两方的观点，还用表格对比了两种流派的差异。 - -这种跨文档的交叉引用和矛盾标注，RAG 是做不到的。RAG 能从单份文档里检索片段，但它不会主动发现两个人其实在用不同方式解决同一个问题。但是通过这种模式，构建的wiki 它就全都懂了。 - -或者需要结合多个跨文档综合的问题。比如「智谱跟 Anthropic 的商业化策略有什么不同」。 - -Agent就可以依据信息的链接跳转，自动的去探索需要的信息，找到最终的答案了。 - -而传统的利用单文档的longcontext chatbot 或者 RAG，其实很难做这些事情。但是wiki已经把他们编译好了。 - -## 写在最后 - -坦率的讲，跑完整个流程之后我有一个很强的感受。 - -llm.wiki 这个模式从理论上肯定是跑得通的。你在里面能看到 GraphRAG 的影子，能看到 Skills 的影子，能看到 Context Engineering 的影子。这些东西换了不同的名字，但做的事情有很大的重叠。 - -而在 Harness Engineering 爆火的今天，llm.wiki 其实又是在强调，过去那些手动维护知识库的包袱，可以扔了。一整套编译工作，交给模型就行。 - -但一个东西没变。 - -garbage in, garbage out。今天依然成立。 - -解析，仍然是很多项目真正的卡点。如果你现在还在被这个问题困扰，可以试试 TextIn，地址在这里：https://cc.co/16YSdj - -实验的完整目录结构、AGENTS.md、解析脚本均已开源。https://github.com/Nipi64310/llmwiki-test diff --git a/InBox/TMP字体Atlas内存优化实战.md b/InBox/TMP字体Atlas内存优化实战.md new file mode 100644 index 0000000..7e22192 --- /dev/null +++ b/InBox/TMP字体Atlas内存优化实战.md @@ -0,0 +1,51 @@ +--- +title: TMP字体Atlas内存优化实战 +source: https://mp.weixin.qq.com/s/iPSxQvg-riGh66efHlSyLA +author: 侑虎科技 +date: 2026-05-06 +tags: [Unity, TMP, 内存优化, Atlas, UWA] +--- + +# 【厚积薄发】从64MB降至5MB，TMP字体Atlas内存优化实战 + +> 来源：UWA公众号 - 第474篇UWA技术知识分享 + +## 实战案例一：字体Atlas双实例冗余 + RW动态图集内存过高 + +**问题：** GOT Online报告显示，项目游戏字体Atlas出现双实例冗余且开启RW动态图集内存占用过高。 + +**原因：** +- 字体Atlas实例数量为2，通常是因为该字体既在初始包中的初始场景中被引用，又在后续AssetBundle资源中重复引用 +- RW（Read/Write Enabled）开启导致CPU和GPU各存一份，内存翻倍 + +**解决方案：** +1. 将初始场景中使用的字符单独创建对应的小字体，避免初始场景中有大图集和大字体的引用 +2. 预先收集游戏的大部分字符集，将Atlas设置为**静态图集配置**，可减少16MB占用 +3. 不在静态图集中的字符，通过TMP的**Fallback机制**，设定一个小分辨率（如512×512）的动态Atlas进行字符补充 + +## 实战案例二：TMPAsset内嵌Atlas纹理无法压缩 + +**问题：** TMPAsset内嵌Atlas纹理属于子资源，无法单独进行纹理压缩参数配置。 + +**解决方案（Editor脚本改造）：** +1. 通过Editor编辑器脚本对该纹理进行独立复制 +2. 将TMPAsset材质球关联替换为复制后的新纹理 +3. 移除原TMPAsset内的内嵌纹理 +4. 剥离后的独立纹理可自由配置压缩格式（ASTC6×6、ASTC8×8等），进一步降低内存开销 +5. 真机测试：压缩后文字美术表现无明显差异 + +## 优化前后对比 + +| 项目 | 内存 | +|------|------| +| 优化前 | **64MB** | +| 优化后合计 | **4.75MB** | +| 初始场景 512×512 静态图集 | 0.25MB | +| 4096×4096 静态图集（ASTC8×8） | 4MB | +| Fallback兜底纹理 512×512（Alpha8） | 0.5MB | + +## 相关资源 +- UWA社区：community.uwa4d.com +- UWA官网：www.uwa4d.com +- UWA学堂：edu.uwa4d.com +- QQ群：793972859 diff --git a/InBox/基于Harness-SDD-多仓管理的AI全栈开发实践.md b/InBox/基于Harness-SDD-多仓管理的AI全栈开发实践.md new file mode 100644 index 0000000..0bed0d8 --- /dev/null +++ b/InBox/基于Harness-SDD-多仓管理的AI全栈开发实践.md @@ -0,0 +1,80 @@ +--- +title: 基于 Harness + SDD + 多仓管理模式的 AI 全栈开发实践 +source: https://mp.weixin.qq.com/s/ygQGSH5c7GHYDvkqWoQTXQ +author: 盖伦 / 得物技术 +date: 2026-05-06 +tags: [AI开发, 全栈, SDD, Harness, Cursor, Claude Code] +--- + +# 基于 Harness + SDD + 多仓管理模式的 AI 全栈开发实践｜得物技术 + +## 一、核心理念：Harness 思维 — 让 AI 模仿，而不是凭空创造 + +### 全栈AI开发最容易踩的坑 +让AI从零开始写代码产生"外星代码"：风格不一致、复用率低、采纳率低。AI生成了代码，但Review成本和返工成本反而更高了。 + +### Harness 思维的核心：给 AI 一个"模仿对象" +给AI一个已有的实现作为参照，让它照着复刻一份，而不是凭空创造。 + +**四条原则：** + +| 原则 | 说明 | 举例 | +|------|------|------| +| 找相似实现 | 在代码库中找到功能最相似的已有实现作为参照 | "结束语"参照"场景化欢迎语" | +| 复用优先 | 能复用的组件、接口封装、数据结构直接复用 | 复用greetingExtendInfo数据结构 | +| 模仿着复制 | "抄一份改一改"比用新方式好 | Controller/Service/Repository按已有模仿 | +| 约束生成范围 | 提示词中明确指定参考文件/参考接口 | 前端修改入口@FeatureTable/index.tsx:53-58 | + +### 提示词体现 Harness +- ❌ 不推荐：`请实现一个结束语管理的 CRUD 接口` +- ✅ 推荐：明确指定参考文件、数据结构和接口路径，如"参照场景欢迎语功能（后端/api/v1/feature/list，前端FeatureTable/index.tsx:53-58）实现" + +## 二、全栈工作区搭建与 Codebase Indexing + +将前后端代码放在同一个工作区下的三个核心价值： +1. **Codebase Indexing**：Cursor对工作区内所有代码进行向量化嵌入建立语义索引，AI能跨仓库理解代码关系 +2. **上下文完整**：AI同时能看到前后端代码，接口字段、命名风格自然对齐 +3. **SDD文档集中管理**：前后端SDD文档在同一工作区，便于接口契约对齐 + +### Cursor vs Claude Code 实测对比 + +| 功能维度 | Cursor | Claude Code | +|---------|--------|-------------| +| 代码库语义索引 | 支持grep+语义检索，速度快 | 仅支持grep，依赖模型能力 | +| 代码生成速度 | 极速，平均1-3分钟 | 中速，平均3-30分钟 | +| 代码采纳率 | 两者相当 | 两者相当 | +| 文件/代码段引用 | 快捷键、拖拽即可引用 | 需手动@文件路径，无法引用代码段 | +| 多Agent | 默认开启（多Tab并行） | 需手动注册子Agent | +| 费率模型 | 失败任务不收费 | 失败任务耗时长，容易浪费Token | +| 历史会话恢复 | 仅能查看当前项目会话记录 | 可查看全局会话记录 | +| 综合评价 | 快速迭代首选，推荐Composer2模式 | 长链路复杂任务可用 | + +## 三、SDD 驱动的全栈代码生成流程 + +- 全栈SDD需同时覆盖前后端 +- 提示词编写范式：明确需求、参考实现、数据结构、接口契约 +- 前后端需求点清单分工示例 +- SDD文档产出与指令使用说明 + +## 四、多 Agent 协作：前后端并行开发 + +- Cursor中使用多Tab并行（默认开启） +- Claude Code中使用Subagent能力（需手动注册） +- 建议：前端Agent专注UI/交互，后端Agent专注API/数据 + +## 五、前后端联调：Mock 数据与分阶段验证 + +- 三阶段验证策略 +- Mock数据编写要点 +- 后端独立构建验证 +- 前后端联调步骤 + +## 六、警惕 SDD 陷阱：测试如何介入全栈研发 + +- SDD不等于需求文档 +- 关注隐性功能（异常处理、边界情况、性能要求） +- 测试应尽早介入 + +## 七、综合效益与总结 + +核心公式：**Harness（约束） + SDD（规格） + 多仓（上下文） = 高质量AI全栈代码** diff --git a/InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md b/InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md deleted file mode 100644 index fb73266..0000000 --- a/InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md +++ /dev/null @@ -1,274 +0,0 @@ ---- -description: 从输出文本变成了输出并检验证据是否完整，RAG之后+VAG ---- - - -# 病例驱动证据验证框架：从表面匹配到可验证推理 - -## 研究背景与问题 - -### 当前 AI 证据引用的核心缺陷 - -现有 AI 模型在引用外部证据时存在严重的逻辑断层问题： - -| 缺陷类型 | 具体表现 | -| ---------- | --------------------- | -| **表面匹配依赖** | 过度依赖文本相似度，用文字重合度"走捷径" | -| **逻辑断层** | 未真正理解证据与主张之间的因果关系 | -| **虚假支撑** | 生成看起来合理但缺乏逻辑支撑的回答 | -| **高风险隐患** | 在医疗、法律等领域可能导致致命错误 | - -### 问题本质 - -模型并未真正"看懂"证据，而是利用文本重合度生成看似合理的回答。这种虚假的逻辑支撑在专业领域非常危险。 - ---- - -## 解决方案：三位一体验证框架 - -### 框架架构 - -研究团队提出**病例驱动验证框架（Case-Driven Evidence Verification）**，核心是三位一体结构： - -``` -┌─────────────────────────────────────────────────────┐ -│ 验证任务 │ -│ （转化为严苛的判断题） │ -├─────────────────────────────────────────────────────┤ -│ │ -│ ┌─────────┐ ┌──────────────┐ ┌───────────┐ │ -│ │ 具体情境 │ + │ 外部证据 │ + │ 结构化主张 │ │ -│ │ CASE │ │ EVIDENCE │ │ CLAIM │ │ -│ └─────────┘ └──────────────┘ └───────────┘ │ -│ │ -│ ↓ │ -│ 模型输出裁定结果 VERDICT │ -│ （支持 / 不支持） │ -└─────────────────────────────────────────────────────┘ -``` - -### 工作机制 - -1. **输入三元组**：同时输入具体情境（Case）、外部证据（Evidence）和结构化主张（Claim） -2. **判断题模式**：将任务转化为判断题，强制模型输出明确裁定 -3. **逻辑验证**：验证证据在当前情境下是否真实支撑主张 - ---- - -## 自动化数据生成方法 - -### 核心创新 - -**零人工标注成本**的自动化数据生成流水线，整合两大数据源： - -| 数据源 | 用途 | -|-------|------| -| **MIMIC-CXR**（真实影像报告） | 提取病例状态（Case） | -| **Radiopaedia**（医学知识库） | 抽取数万条证据（Evidence） | - -通过 **Refire Core** 逻辑规则智能重组，自动映射成数十万条正负样本。 - -### 四类训练样本 - -| 样本类型 | 特征 | 作用 | -|---------|------|------| -| **正样本** | 明确支持主张 | 学习正确关联模式 | -| **错误状态陷阱** | 高度相关但结论相反 | 封堵关键词匹配捷径 | -| **困难负样本** | 因果关系复杂 | 强化深层理解 | -| **简单负样本** | 明显不支持 | 基线学习 | - -### 反事实负样本（核心突破） - -- **语义特征**：与主张极度接近，包含所有核心关键词 -- **逻辑特征**：由于病例特征差异，推导方向与主张完全相反 -- **占比**：25% 的数据集专门用于封堵关键词匹配捷径 - -**目的**：逼迫模型放弃表面关联，深入理解文字背后的逻辑因果。 - ---- - -## 实验设计与结果 - -### 关键对比实验 - -#### 1. 病例深度关联的效果 - -| 配置 | AUPRC | 平衡准确率 | -|-----|-------|-----------| -| 纯证据验证 | 35.1% | — | -| **深度关联验证** | **87.8%** | **92.0%** | - -**结论**：单纯堆砌资料不能让 AI 变聪明，结合具体情境才能实现性能跨越。 - -#### 2. 关键词陷阱测试 - -**场景**：病例明确显示无胸腔积液，面对包含相同术语的干扰证据 - -| 模型 | 支持率 | -|-----|-------| -| 普通 AI | 99.1% | -| **深度验证模型** | **0.000%** | - -**结论**：框架能有效识破伪装，不再盲目信任语义相近但逻辑无关的信息。 - -#### 3. 物理干预测试（检验推理真实性） - -三种极端条件： - -| 测试条件 | 描述 | AUPRC | F1 分数 | -|---------|------|-------|---------| -| 正常关联证据 | 基线测试 | 87.8% | 高 | -| 清空证据 | 切断所有参考资料 | 大幅下降 | 大幅下降 | -| **交换证据** | 张冠李戴的专业文本 | **21.7%** | 显著缩水 | - -**结论**：性能急剧崩溃证明模型**高度依赖正确的外部证据**，而非死记答案。 - -#### 4. 证据数量与性能关系 - -| 证据数量 | AUROC | -|---------|-------| -| 1 句 | 较低 | -| **2 句** | **97.4%（巅峰）** | -| 10 句 | 基本持平 | - -**关键发现**：模型不需要翻阅数百页文档，只需抓准最关键的两句信息就能实现满血性能。过度堆砌资料反而引入背景干扰。 - -### 全维度性能对比 - -| 方法 | AUROC | AUPRC | BRI Score | -|-----|-------|-------|-----------| -| 纯情境推断 | 59.90% | — | 高 | -| 纯证据验证 | — | 35.11% | 高 | -| **三位一体深度关联** | **97.43%** | **87.8%** | **0.060** | - ---- - -## 泛化能力验证 - -### 陌生知识测试（Held-out Content） - -使用**从未参与训练**的全新医学百科文章： - -| 指标 | 结果 | -|-----|------| -| AUROC | 97.2% | -| F1 分数 | 77.9% | - -**结论**：模型学习到的是**通用验证逻辑**，而非对特定教材句式的死记硬背。 - -### 跨数据集迁移 - -将基于 MIMIC-CXR 训练的模型**直接空降**到 CheXpert Plus 数据集（6万+患者）： - -| 指标 | 结果 | -|-----|------| -| AUROC | 93.46% | -| 平衡准确率 | 87.45% | - -**结论**：即便面对截然不同的书写风格和病例分布，模型验证能力依然在线，展现极强落地适应性。 - -### 底层模型对比 - -| 模型 | 参数量 | AUPRC | 特点 | -|-----|-------|-------|------| -| **DeBERTa-v3-large** | **3.95亿** | **87.8%** | 综合最强，面对未知证据最稳 | -| FlanT5-large | — | 次之 | 经典大模型 | -| RoBERTa-large | — | — | 经典 baseline | - -**结论**：更现代的特征提取器能更敏锐地锁定微小的语义偏差。 - ---- - -## 应用场景 - -### 1. 临床问答护城河 - -``` -检索器 → 生成器 → 【验证框架】 → 医生 - ↓ - 输出置信度分数 - 拦截 99% 幻觉主张 -``` - -- 作为最后一道交叉质证 -- 有效拦截无依据方案 -- 辅助医生做出更稳健的决策 - -### 2. 自动化医疗报告审核 - -- 自动提取结构化结论 -- 与原始影像发现及医学标准逐一核对 -- 实时标注逻辑冲突，提示人工复核 -- 减轻高年资医生审核负担 -- 杜绝因疲劳引发的关键性疏漏 - -### 3. 跨领域泛化 - -| 领域 | 应用 | -|-----|------| -| 法律合规 | 核实法条是否真实适用于案件事实 | -| 科研验证 | 自动检查实验引用是否存在张冠李戴 | -| 企业知识库 | 核对工单与操作手册，拒绝随意发挥 | - ---- - -## 范式跃迁：从 RAG 到 VAG - -| 范式 | 特征 | 核心区别 | -|-----|------|---------| -| **RAG**（检索增强生成） | 只要检索文本看起来相似，就强行作为答案参考 | 区分**相关性**与**支撑性** | -| **VAG**（验证增强生成） | 只有存在明确逻辑因果的文本才被认定为有效证据 | 追求**确凿性** | - -**本质转变**：AI 从松散的文本拼接机器 → 严谨的逻辑推演中枢 - ---- - -## 当前局限与未来路线 - -### 技术边界 - -| 局限类型 | 具体问题 | -|---------|---------| -| **泛化损耗** | 面对截然不同的新证据时，AUPRC 指标仍会产生客观衰减 | -| **多状态扩展** | 目前主要验证二元主张，未来需向复杂多元连续图谱扩展 | -| **端到端噪声** | 引入全网实时检索后，对模型抗干扰能力提出更高要求 | - -### 演进路线 - -``` -第一阶段（已完成） 第二阶段（进行中） 第三阶段（愿景） - ↓ ↓ ↓ -三位一体验证框架 → 端到端动态检索 → 人类专家深度对齐 - + + - 非结构化长文本 证据链自我修剪 - 高噪声环境 自主思考 Agents -``` - ---- - -## 核心结论 - -| 指标 | 结果 | 意义 | -|-----|------|------| -| AUPRC | 87.8%（提升 52.6%） | 跨越性性能提升 | -| 平衡准确率 | 92.0% | 高可靠性 | -| BRI Score | 0.060 | 极低预测误差 | - -**核心启示**：真正的智能不仅在于调取知识，更在于懂得如何对证据负责。 - ---- - -## 术语表 - -| 术语 | 全称 | 解释 | -|-----|------|------| -| **AUPRC** | Area Under Precision-Recall Curve | 精确率-召回率曲线下面积，衡量不平衡数据集性能 | -| **AUROC** | Area Under Receiver Operating Characteristic Curve | ROC 曲线下面积，衡量分类器区分能力 | -| **BRI Score** | Brier Score | 预测误差的均方误差，越低越准确 | -| **RAG** | Retrieval-Augmented Generation | 检索增强生成 | -| **VAG** | Verification-Augmented Generation | 验证增强生成 | -| **DeBERTa** | Decoding-enhanced BERT with disentangled attention | 更现代的预训练语言模型架构 | -| **MIMIC-CXR** | Medical Information Mart for Chest X-ray | 公开胸部 X 光影像数据集 | -| **反事实负样本** | Counterfactual Negative Samples | 语义相似但逻辑结论相反的样本，用于测试模型是否真正理解因果关系 | -| **CheXpert Plus** | — | 斯坦福大学胸部 X 光数据集 | -| **Refire Core** | — | 逻辑规则引擎，用于自动构建训练样本 | \ No newline at end of file