1

InBox/AutoHarness-论文解读.md

@@ -0,0 +1,215 @@
+# AutoHarness 深度解读
+
+> 来源：https://zhuanlan.zhihu.com/p/2016839356833341880
+> 收藏时间：2026-03-25
+
+## 一句话总结
+
+用小模型（Gemini-2.5-Flash）自动写一段"规则检查代码"包裹在 LLM 外面，让它不再犯"非法操作"的低级错误，结果小模型+代码 > 大模型裸跑。
+
+---
+
+## 这篇论文到底在解决什么问题？
+
+### LLM 做 Agent 时的尴尬现实
+
+你可能已经知道，现在很多人在用 LLM 做 agent——让模型去完成一些需要"行动"的任务，而不是简单地回答问题。比如让 LLM 下棋、玩游戏、操控机器人等。
+
+**问题来了：LLM 经常做出"非法操作"。**
+
+论文举了一个非常生动的例子：在 Kaggle GameArena 的国际象棋比赛中，Gemini-2.5-Flash 78% 的失败不是因为下棋策略差，而是因为走了不符合规则的棋。比如让马走直线、让兵倒着走之类的。
+
+这就好比你请了一个非常聪明的人来帮你下棋，他对棋局分析得头头是道，但就是经常把棋子摆到不合法的位置上。
+
+### 为什么会这样？
+
+LLM 本质上是一个文本生成模型。它"知道"国际象棋的规则（因为训练数据里有大量棋谱），但它没有一个硬编码的规则引擎来确保输出的每一步都合法。它的"知道"是概率性的、模糊的，不是精确的。
+
+### 现有解决方案及其问题
+
+| 方案 | 怎么做 | 问题 |
+|------|--------|------|
+| Fine-tuning | 用大量合法游戏轨迹去微调模型 | 成本极高；可能降低模型在其他任务上的能力 |
+| 手写 Harness | 人工为每个游戏写一个规则检查器 | 费时费力，每换一个游戏就要重写 |
+
+**这篇论文的创新点是：让 LLM 自己写这个规则检查器。**
+
+---
+
+## 核心概念：什么是 "Harness"？
+
+### Harness 的直觉理解
+
+"Harness" 这个词在英文里是"挽具/马具"的意思，用来控制和约束马的行为方向。在这篇论文里，Harness 就是包裹在 LLM 外面的一层"安全壳"，确保 LLM 输出的动作是合法的。
+
+用工程的话说，这就是一个 wrapper / middleware / interceptor：
+
+```
+传统做法：
+用户请求 → LLM → 输出动作（可能非法）→ 环境报错
+
+加了 Harness 之后：
+用户请求 → LLM → Harness检查 → 合法? → 执行
+                      ↓ 不合法
+              告诉LLM"这步不行" → LLM重新生成 → 再检查...
+```
+
+### 三种 Harness 变体
+
+论文提出了三种不同"约束力度"的 harness：
+
+#### ① Harness-as-Action-Verifier（动作验证器）— 论文主要聚焦的方案
+
+```python
+while True:
+    action = LLM.generate(observation)  # LLM 提出一个动作
+    if code_harness.is_legal_action(obs, action):  # 代码检查是否合法
+        break  # 合法就执行
+    else:
+        # 不合法，告诉 LLM 这步不行，让它重新想
+        observation += f"\n警告：{action} 是非法操作，请重新选择"
+return action
+```
+
+类比：就像你写代码时 IDE 的实时语法检查——你写了不合法的代码，红线提示你改。
+
+#### ② Harness-as-Action-Filter（动作过滤器）
+
+```python
+legal_actions = code_harness.propose_action(obs)  # 代码先列出所有合法动作
+best_action = LLM.rank(legal_actions)  # LLM 从中选最好的
+return best_action
+```
+
+类比：就像下拉菜单——用户只能从合法选项中选，不可能输入非法值。
+
+#### ③ Harness-as-Policy（代码即策略）— 最激进的方案
+
+```python
+action = code_harness.propose_action(obs)  # 完全由代码决定动作
+return action  # 根本不需要 LLM
+```
+
+类比：你直接写了一个规则引擎/算法来玩游戏，LLM 只在"开发阶段"用来写这个算法。运行时零 LLM 调用，零成本。
+
+---
+
+## 核心方法：怎么让 LLM 自动写出 Harness？
+
+这是论文最核心的技术贡献。如果你熟悉 GRPO，你可以把这个过程理解为：用环境反馈来优化代码，而不是优化模型权重。
+
+### 整体流程
+
+```
+1. 初始化：LLM 写一版 harness 代码（propose_action + is_legal_action）
+2. 测试：用这个代码在游戏环境里跑 rollout
+3. 评估：记录哪些动作被判为非法，收集错误信息
+4. 反馈：把错误信息喂给 LLM（Critic 模块整理错误）
+5. 优化：LLM 基于错误反馈生成改进版代码（Refiner 模块）
+6. 重复 2-5，直到合法率达到 100% 或超时
+```
+
+### 和 GRPO 的对比
+
+| 维度 | GRPO | AutoHarness |
+|------|------|-------------|
+| 优化的对象 | 模型权重 θ | 代码文本（程序） |
+| 搜索空间 | 参数空间（连续） | 程序空间（离散） |
+| 反馈信号 | reward（标量） | 执行反馈（错误日志+reward） |
+| 优化方法 | 梯度下降 | LLM 当"突变算子"改代码 |
+| 探索策略 | 采样多个 response 对比 | Thompson sampling 做 tree search |
+| 类比 | 调参让模型更好 | 让 AI 写更好的代码 |
+
+**关键区别**：GRPO 改的是模型内部的权重，AutoHarness 改的是模型外部的代码。一个改"大脑"，一个改"工具"。
+
+### Tree Search + Thompson Sampling
+
+#### 为什么要用 Tree Search？
+
+简单的迭代优化（写代码 → 测试 → 改代码 → 测试…）有个问题：容易陷入局部最优。比如 LLM 沿着一个思路改了 5 版代码，发现这个方向走不通了，但已经回不去了。
+
+Tree search 的思路是：同时维护多个版本的代码，像一棵树一样分叉发展。
+
+```
+初始代码 v0
+    /       \
+  v1a       v1b  ← 两个不同的改进方向
+  /  \      |
+v2a  v2b   v2c   ← 继续分叉
+|
+v3a  ← 这个方向成功了！合法率100%
+```
+
+#### Thompson Sampling 是什么？
+
+你面对这棵树上的多个节点，每次迭代应该选哪个节点来继续优化？这就是经典的 exploration-exploitation（探索-利用）问题：
+
+- **利用（Exploitation）**：选当前表现最好的代码版本继续改进
+- **探索（Exploration）**：试试那些还没被充分优化的代码版本，也许潜力更大
+
+Thompson sampling 是一种概率性的选择策略：
+
+```
+对每个节点：
+1. 根据它历史的"合法率"数据，建一个概率分布（Beta 分布）
+2. 从这个分布中随机采样一个值
+3. 选采样值最高的节点来优化
+
+效果：表现好的节点被选中的概率更高（利用），
+      但表现差的节点也有机会被选中（探索）
+```
+
+工程类比：这和你做 A/B testing 时的 Multi-Armed Bandit 问题几乎一模一样。Thompson sampling 就是一种 bandit 算法。
+
+### Critic 和 Refiner 的分工
+
+**Critic（批评者）**：
+- 输入：rollout 中失败的步骤（最多 5 个）
+- 工作：整理和归纳各种错误类型
+- 输出：结构化的错误摘要
+- 类比：Code Review 时给你提 bug 的同事
+
+**Refiner（优化者）**：
+- 输入：当前代码 + Critic 的错误摘要
+- 工作：基于反馈生成改进版代码
+- 输出：新版本的 harness 代码
+- 类比：你根据 code review 意见改代码
+
+一个关键细节：如果 `is_legal_action()` 返回 True 但环境说动作非法（漏判），则两个函数都要改；如果 `is_legal_action()` 返回 False 且动作确实非法（检查器工作正常，只是 `propose_action` 提出了错误动作），则只改 `propose_action()`。这个区分很重要，避免了"改了不该改的代码"。
+
+---
+
+## 实验结果解读
+
+### 训练效率：多快能学会？
+
+- 平均 **14.5 次迭代**就能学会（即 LLM 改代码 14.5 次）
+- **19/32 个游戏**不到 10 次就搞定了
+- 最难学的游戏：GermanWhist（43次）、Chess（64次）、Othello（62次）
+
+直觉理解：简单游戏（如猜数字、骰子）规则简单，几次就能写对检查器；复杂游戏（如国际象棋）规则多样（王车易位、吃过路兵等），需要更多轮迭代。
+
+最终结果：**全部 145 个游戏都达到了 100% 合法动作率。**
+
+### 双人游戏：小模型+Harness vs 大模型
+
+| 对阵 | 我们的方法胜率 | 对手胜率 |
+|------|--------------|----------|
+| Flash+Harness vs Gemini-2.5-Pro | **56.3%** | 38.2% |
+| Flash+Harness vs Flash（原始） | **64.8%** | — |
+
+这意味着什么？**一个小模型（Flash）配上自动生成的规则检查代码，可以打败一个大几倍的模型（Pro）。**
+
+---
+
+## 核心启示
+
+1. **"代码即策略"可能是 LLM Agent 的终局形态** — 让 LLM 写代码，然后运行时零 LLM 调用
+2. **小模型+好代码 > 大模型裸跑** — 这打破了"模型越大越好"的迷信
+3. **Program Synthesis + RL 的结合** — 这可能是下一代 AI 系统的核心范式
+
+---
+
+## 标签
+
+#论文解读 #AutoHarness #LLM #Agent #ProgramSynthesis #GRPO #强化学习

InBox/CLIProxyAPI.md

@@ -0,0 +1,29 @@
+# CLIProxyAPI
+
+**GitHub**: https://github.com/router-for-me/CLIProxyAPI  
+**添加时间**: 2026-03-24  
+**提醒时间**: 2026-03-25 10:00  
+**标签**: #代理 #CLI #工具
+
+---
+
+## 项目简介
+
+(待补充 - 明天落实时填写)
+
+## 主要功能
+
+(待补充)
+
+## 安装使用
+
+(待补充)
+
+## 备注
+
+- 用户要求：无风险的情况下落实
+- 提醒已设置：明天（3月25日）10:00
+
+---
+
+**原始链接**: https://github.com/router-for-me/CLIProxyAPI

InBox/v2ex_1196441_大模型变笨讨论.md

@@ -0,0 +1,36 @@
+# 大家有没有感觉最近大模型变笨了
+
+**来源**: https://www.v2ex.com/t/1196441#reply25  
+**保存时间**: 2026-03-24  
+**标签**: #AI #大模型 #讨论
+
+---
+
+## 帖子摘要
+
+楼主提问：大家有没有感觉最近大模型变笨了？
+
+主要讨论点：
+- 用户感觉 GPT-4、Claude 等大模型最近回复质量下降
+- 有人认为是心理作用或期望值提高
+- 也有人提到可能是模型更新导致的风格变化
+- 讨论涉及多个主流大模型：GPT-4、Claude、Gemini 等
+
+---
+
+## 关键回复观点
+
+1. **心理作用论**: 用多了之后对模型能力边界更清楚，所以感觉"变笨"
+2. **模型更新论**: OpenAI 等厂商确实会调整模型，可能影响某些任务的表现
+3. **任务复杂度**: 随着使用深入，提出的问题更难，模型显得力不从心
+4. **对比效应**: 新模型出来后，旧模型相对显得弱了
+
+---
+
+## 个人思考
+
+(待补充)
+
+---
+
+**原始链接**: https://www.v2ex.com/t/1196441#reply25

InBox/未命名.md

@@ -1,8 +0,0 @@
-- 需要验证Editor preview
-- 需要验证战斗
-- 需要验证地图
-	- 需要验证行军线
-		- 前端表现
-
-- android
-- 性能分析

InBox/测试笔记_共享转移_20250320.md

@@ -0,0 +1,20 @@
+---
+title: 测试笔记 - 共享目录转移
+date: 2026-03-20
+tags: [测试, 共享目录]
+---
+
+# 测试笔记
+
+这是一篇测试笔记，用于验证共享目录转移流程。
+
+## 创建信息
+- 创建时间: 2026-03-20 03:01
+- 来源: Mac mini 共享目录
+- 目标: zanepc Obsidian InBox
+
+## 测试内容
+如果这篇笔记能成功转移到 zanepc 的 Obsidian 中，说明流程配置正确。
+
+---
+*自动创建用于测试共享目录转移*