芹菜是高汤的基底菜:不放香,但决定一切味道的底。 模型是引擎,harness 是底盘。这里的理论决定底盘怎么焊。
一句话定位:给"概率性 AI 套确定性缰绳"这一工程,建立从第一性原理推导、由公式支撑的最佳实践 canon。
核心哲学:
Agent = Model + Harness
Harness = 不可靠执行体(模型) + 需要可靠性的目标 + 控制界面
控制界面只做三件事: 边界 → 评估 → 纠偏
为什么需要理论库:业界 harness 是工程实践爆炸(每个团队都有自己的 retry / budget / hook / self-consistency 启发式),但统一数学缺席——现状类比是"瓦特调速器时代":每个工厂都有自己的调速器,还没有调速器理论。本项目要补的,就是那条从工程经验通往可推导原则的路径。
| 文档 | 回答的问题 |
|---|---|
| theory/01-essence.md | harness 的本质是什么?机制(I/O 处理)和本质(闭环于误差)的分野在哪? |
| theory/02-core-model.md | 正确的建模单元是什么?为什么是"执行器-校验器"联合体? |
| theory/03-sequential-reliability.md | 长任务怎么可靠?检查点=再生器,为什么 β 支配长任务? |
| theory/04-math-foundations.md | 有什么数学支撑?裂缝在哪?判断组件可不可信的标准? |
| theory/05-industry-map.md | 业界坐标系:主流框架、前沿增量、香农视角的定位 |
| theory/06-attribution-framework.md | 实例失败归因到哪层?四层排查法 + 失败模式库 + 环境判据 |
- practices/README.md — 每条理论 → 设计判据 → 业界组件 → 待长实践 的映射表。理论是静态的,实践从这里长出。
- practices/blueprint.md — 最佳实现蓝图:三层校验器链 + 组件映射 + 五原则 + 运行循环 + 量化效果。
- prototype/README.md — 真实模型完整闭环(deepseek-v4-flash):blueprint 8 步全部落地, 验证校验器链接线/重试/检查点/标定/ratchet。
- prototype/sim.py — 四参数蒙特卡洛模拟, 自检验证理论四结论(精密度公式/重试作用域/β支配/检查点)。
- 降 ρ — 任务分段 + 检查点,把相关错误切成独立错误。否则投票/重试的数学全失效。
- 降 β — 校验器要悲观、要独立、要被校准。长任务里这是第一优先(β 的收益随剩余段长放大)。
- 拆到可验证区 — 把不可验证的大目标,转写成"一串可验证的子目标"。这是 harness 最深的一层动作。
- 预算按边际均等分配 — 重试投给 p₁ 低的,校验投给 β 高的。几何重试的边际收益指数衰减。
- 承认天花板 — 目标不可验证的部分,别用 harness 硬撑,直接设人工闸门。
不只是理论文档——本仓库含可直接运行的工程,全部实测:
| 能力 | 位置 | 验证 |
|---|---|---|
| 跨语言求解器 | opt-celery/solver.py |
Python/JS/C++ 三语言 Pass@1=1/1 |
| 校验器标定 | tools/beta_calibration.py 等 7 个 |
β/α/ρ/κ/p₁ 实测数字 |
| 理论自检 | prototype/sim.py |
公式 vs 模拟 Δ<0.01 |
| 使用指南 | USAGE.md |
五场景逐步命令 |
| 实战心得 | practices/lessons-learned.md |
踩坑沉淀 |
完整使用见 USAGE.md。需要 LLM 的工具读
~/.config/claude-code/auth.env凭据(不提交)。
| 项目 | 层 | 与 celery 的关系 |
|---|---|---|
claude-workspace/harness_obs/ |
实现层(观测底座) | celery 是它的理论依据;validation / uncertainty_budget / value 是该理论的具体实例化 |
claude-workspace/loop-engineering/ |
实现层(循环工程) | 同为实现层,celery 不与之竞争 |
celery: 从"纸上数学"到"可测工程"——四参数实测、公式验证、跨模型/跨语言通过。