Zane/obsidian-notes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

inbox-update

Browse Source
This commit is contained in:
Build Bot
2026-05-07 01:13:24 +08:00
parent ff654b91f2
commit 53b0de51a2
12 changed files with 423 additions and 808 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
.obsidian/workspace.json vendored
View File

@@ -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",

50
.omx/context/scheduled-task-git-sync-gant-20260429T161523Z.md Normal file
View File

@@ -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

30
.omx/interviews/scheduled-task-git-sync-gant-20260429T161523Z.md Normal file
View File

@@ -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

69
.omx/plans/autopilot-impl.md Normal file
View File

@@ -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

25
.omx/setup-task.ps1 Normal file
View File

@@ -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"

85
.omx/specs/deep-interview-scheduled-task-git-sync-gant.md Normal file
View File

@@ -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)

320
InBox/Harness Engineering最佳实践_深度解析AgentHamness的底层原理_核心组件和实战应用 学不会我_BV1Hn9UBrEsH_P1_笔记.md
View File

@@ -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 的技术架构与工程实践。视频原版对三层架构有详细展开，读者可根据需要结合原视频深入理解各层级的技术细节。

66
InBox/Hermes编排Agent_Web可观测性方案.md
View File

@@ -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)*

114
InBox/Karpathy_harness_llm_wiki.md
View File

@@ -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

51
InBox/TMP字体Atlas内存优化实战.md Normal file
View File

@@ -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

80
InBox/基于Harness-SDD-多仓管理的AI全栈开发实践.md Normal file
View File

@@ -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全栈代码**

274
InBox/让AI真正读懂证据间的因果_深度验证框架解决逻辑断层_实现92.0_平衡准确率_BV1p9QnBtEMq_笔记.md
View File

@@ -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** | — | 逻辑规则引擎，用于自动构建训练样本 |