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

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