也来谈谈Harness

最近一段时间,Harness Engineering这个概念很火

说什么AI开发终于进化到了第三阶段,能搞大事情了(前两个阶段是Prompt Engineering \Context Engineering)

👉 那我可不能落后啊,连夜去查了资料

openai说:https://openai.com/zh-Hans-CN/index/harness-engineering/

Anthropic说:https://www.anthropic.com/engineering/harness-design-long-running-apps

B乎人士说:…………

终于有了一点理解,那么

👉 Harness 到底是什么,以及它为什么重要。


一、Harness 是什么?

Harness 原译是马具,马绳

那么通过泛化语义Harness Engineering 可以翻译为约束工程(为了好写,以下Harness Engineering 简作 Harness )

再向软件工程靠拢一点:

👉 Harness = 通过约束让 AI 能稳定干活的一整套工程系统

换句话说:

👉 模型负责“思考”,
👉 Harness 负责“让结果可靠”。

再展开一点:

Harness 主要做四件事:

  • 限制 AI 的行为(不乱来)
  • 提供 AI 的能力(能做事)
  • 判断结果是否正确(不自嗨)
  • 出错后自动修正(不重复犯错)

👉 本质就是一句话:

把不稳定的智能,变成可控的执行力


二、为什么需要 Harness?

因为模型本身是“不可靠”的。

它有几个很明显的问题:

  • 会犯错,而且还很自信
  • 会忘(没有长期记忆)
  • 会跑偏(任务一长就乱)
  • 不知道自己做得对不对

所以真正的问题不是:

👉 AI 会不会做?

而是:

👉 AI 怎么才能持续做对?

Harness 就是这个问题的答案。


三、Harness 的核心结构

如果把 Harness 拆开,其实可以归纳成四个核心部分:


1️⃣ 约束(Constraint)

👉 限制 AI 能做什么、不能做什么

比如:

  • 代码规范
  • 项目结构规则
  • 哪些文件可以改,哪些不能动

👉 作用:防止 AI “乱改一通”


2️⃣ 能力(Tools)

👉 给 AI 工具,让它真正能“做事”

比如:

  • 运行代码
  • 调接口
  • 操作文件

👉 否则 AI 只能“说”,不能“做”


3️⃣ 验证(Evaluation)

👉 判断结果是不是正确

比如:

  • 单元测试
  • 类型检查
  • 页面是否能正常打开

👉 关键点:

👉 不要让 AI 自己判断对不对


4️⃣ 反馈闭环(Feedback Loop)

👉 出错之后自动修正

典型流程:

改代码 → 跑测试 → 失败 → 修复 → 再跑 → 直到通过

👉 这一步决定了:

👉 AI 是“一次性输出”,还是“持续收敛”


四、Harness 在工程里的真实形态

讲到这里,如果还是停留在概念,其实是没用的。

真正重要的是:

👉 Harness 在项目里长什么样?


一个最小可用的 Harness,通常包括这些东西:


📦 1. 仓库结构

让 AI 知道:

  • 项目是怎么组织的
  • 哪些文档是“真相”
  • 从哪里开始改

🔧 2. 标准命令(工具系统)

比如:

npm run lint
npm run test
npm run dev

👉 关键点:

👉 不要让 AI 自己“猜命令”


✅ 3. 自动验证

至少要有:

  • 能跑通的测试
  • 基础检查(编译 / 类型)

👉 否则 AI 永远不知道自己做对了没有


👀 4. 可观测性

让 AI 能看到运行结果:

  • 日志
  • 页面
  • 返回结果

👉 否则它只能“盲改代码”


🔁 5. 执行循环(最关键)

一个完整流程通常是:

理解任务
→ 查代码
→ 修改
→ 自测
→ 自审
→ 修复
→ 输出

👉 这就是 Harness 的“运行机制”


五、一个非常重要的认知

👉 Harness 的目标不是让 AI 更聪明

👉 而是让 AI 更“可控”


很多人会下意识觉得:

👉 模型越强,一切都会变好

但实际情况是:

👉 模型越强,乱来也越强


所以真正的突破不是:

👉 更强的模型

而是:

👉 更好的 Harness


六、一个很好理解的比喻

👉 Harness = 马具

  • 模型 = 马(很强)
  • Harness = 缰绳 + 鞍具(控制它)

👉 重点不是让马更强,而是:

👉 让它按你想要的方向跑


七、为什么这是未来的核心能力

AI 编程已经在发生一个很明显的变化:

Prompt → Agent → Harness
  • Prompt:让 AI 开始写代码
  • Agent:让 AI 能执行任务
  • Harness:让 AI 能稳定交付

👉 未来的差距不会在:

  • 谁用哪个模型
  • 谁用哪个工具

👉 而在:

👉 谁能设计出更好的 Harness


八、最后的总结

如果让我用一句话收尾:

👉 Harness = 让 AI 在你的工程里,自己干活、自己检查、自己修正的那套系统


👉 模型决定上限
👉 Harness 决定你能不能把它用出来


(完)

当散户都用AI选股 机构都用量化交易 会怎么样

这是一个很有意思的问题,而且在金融界已经讨论很多年了。简单说一句结论:

如果所有人都用同样的AI/量化策略,收益会被迅速“套利掉”,市场反而会变得更难赚钱。

我从金融机制角度给你解释会发生什么。


一、市场会变得更“有效”

金融学里有一个经典理论:

Efficient Market Hypothesis

核心意思是:

市场价格会迅速反映所有可获得的信息

如果越来越多交易由 AI 和量化模型完成:

结果是:

任何明显的机会
都会被几毫秒内消灭

举个例子:

过去可能出现:

某公司利好新闻
→ 股价过一会儿才涨

现在:

AI读新闻
→ 1毫秒下单
→ 价格立刻反映

所以普通散户更难捡到“明显便宜的股票”。


二、策略会迅速失效

量化交易的一个规律是:

一个策略越多人用 → 越快失效

例如曾经很火的:

  • 动量策略
  • 价值投资模型
  • 统计套利

一旦被大量资金使用:

收益 → 被套利

很多大型量化基金都经历过这个过程。

例如:

Renaissance Technologies

他们的核心策略非常保密,因为:

一旦公开 → 就会失效

三、市场波动可能更大

如果很多 AI 使用类似策略,会产生一种现象:

同一信号
→ 大量模型同时交易

可能导致:

瞬间大涨
瞬间暴跌

历史上已经发生过类似事件,例如:

2010 Flash Crash

在几分钟内:

美股暴跌约9%

原因之一就是:

算法交易互相触发

四、市场可能出现“AI对AI”

未来很可能变成:

AI策略
vs
AI策略

就像一个博弈系统。

例如:

AI A 发现动量
AI B 专门反向交易
AI C 做流动性

最后市场变成:

算法博弈

人类反而很难理解。


五、散户用AI其实未必有优势

很多散户以为:

用AI选股 → 就能赚钱

但现实是:

机构的优势不在AI,而在:

1 数据

机构可以买:

卫星数据
信用卡消费数据
物流数据

散户拿不到。


2 速度

机构交易延迟:

微秒级

散户:

毫秒甚至秒级

3 成本

大型基金交易成本极低。

例如:

  • Citadel
  • Two Sigma

他们的基础设施非常强。


六、最终市场会变成什么样

如果 AI 交易越来越普遍,长期可能会出现几个趋势。

1 alpha 越来越少

所谓 alpha:

超额收益

会越来越难获得。


2 长期投资可能反而更有优势

很多研究发现:

如果短期交易完全被算法占据:

长期基本面投资
反而可能更有效

例如:

  • Warren Buffett

这种策略其实很难被短期算法复制。


3 市场越来越像“生态系统”

未来市场更像:

捕食关系

例如:

高频套利
↓
中频量化
↓
长期投资

不同策略互相依赖。


七、一个很多人忽略的现实

AI 在股票上最大的用途,其实可能不是:

预测涨跌

而是:

信息处理

例如:

  • 读财报
  • 分析新闻
  • 监控行业变化

这其实更接近:

超级研究员

而不是:

预测机器

从“龙虾盒子”聊到 AI NAS:和 ChatGPT 一次意外的产业链挖掘

最近在研究深圳的一条政策,本来只是想看看有没有炒股的机会,结果没想到和 ChatGPT 聊着聊着,竟然挖出了一条可能的新产业链:AI NAS

事情的起点,是一篇公众号文章。

一、深圳的“龙虾十条”

文章说的是深圳龙岗区推出的一项新政策,市场上很多人把它叫做 “龙虾十条”。政策的核心其实是围绕一个生态:

  • OpenClaw
  • AI Agent
  • 一人公司(OPC)

简单理解就是:
一个人 + AI Agent = 一家公司

政府希望通过补贴,让更多人用 AI 创业。

但让我注意到的不是这些,而是一条很具体的补贴:

购买“龙虾盒子”补贴 30%

我当时就有点好奇:

龙虾盒子到底是什么?

于是我直接去问 ChatGPT。

二、龙虾盒子到底是什么

ChatGPT给我的第一条信息其实很关键:

龙虾盒子本质上是 AI NAS

也就是:

AI NAS
= NAS存储
+ 本地大模型
+ AI Agent运行环境

换句话说,它其实就是一台 本地 AI 服务器

为什么需要这个东西?

因为 OpenClaw 是一个 Agent平台,它需要运行模型、执行任务、访问知识库。

所以理论上它可以跑在:

  • PC
  • 服务器
  • AI NAS

而深圳这次政策,直接补贴 AI NAS硬件

这就有意思了。

三、为什么政府要补贴 AI NAS

继续和 ChatGPT 深挖之后,我突然意识到一个问题:

很多公司其实不敢用云端 AI。

原因很简单:

  • 数据安全
  • 商业机密
  • 数据出境

所以未来很可能会出现一种架构:

公司内部
   ↓
AI NAS
   ↓
本地模型
   ↓
AI Agent

也就是说:

每家公司都有一台本地 AI 服务器。

这其实就是一种新的形态:

私有 AI 云

四、现实中已经出现 AI NAS 了

再往下挖,发现这个市场其实已经有人在做。

ChatGPT给我列了几个比较有意思的玩家。

绿联

国内 NAS 市场增长很快的一个品牌。

他们已经发布过 AI NAS,主打:

  • 本地大模型
  • 本地知识库
  • 私有 GPT

这和 OpenClaw + AI Agent 的场景其实非常接近。

极空间

这是 NAS 圈子里的黑马。

创始团队来自迅雷,产品定位是:

“傻瓜NAS”

用户增长很快,而且也在开始做 AI 能力。

可惜目前还没上市。

华为

华为其实早就有企业级存储产品,比如:

OceanStor

如果再叠加:

  • 昇腾算力
  • AI推理

其实就是企业级 AI NAS。

五、如果用炒股的视角看

这里就变成一个比较典型的产业链问题。

NAS 本身很多公司没上市,但它的 上游供应链 是在 A 股的。

比如:

存储

NAS 本质就是存储设备。

相关公司包括:

  • 江波龙
  • 佰维存储
  • 兆易创新

逻辑很简单:

AI NAS
→ 本地数据
→ SSD需求增加

AI服务器

AI NAS 其实就是小型 AI 服务器。

相关公司:

  • 浪潮信息
  • 中科曙光
  • 紫光股份

AI芯片

如果 NAS 要跑模型,就需要推理芯片。

相关方向:

  • 寒武纪
  • 海光信息
  • 景嘉微

六、真正有意思的地方

这次聊天让我意识到一个更大的趋势。

过去几十年,计算架构其实经历了几个阶段:

PC时代
↓
云计算
↓
AI时代

但 AI 时代可能会出现一个新的形态:

AI NAS

也就是:

本地数据
+ 本地模型
+ Agent

未来可能会出现一种设备:

AI NAS
= 私有云
+ 本地GPT
+ Agent平台
+ 数据库

也许过几年,每家公司机房里都会有一台。

甚至家庭也可能会有。

七、一次聊天带来的启发

一开始我只是想看看深圳政策里有没有什么股票机会。

结果和 ChatGPT 聊着聊着,从:

龙虾盒子
→ AI NAS
→ 私有 AI 云
→ AI服务器产业链

一路挖了下来。

有时候 AI 不只是回答问题。

它更像是一个 思维放大器

你给它一个问题,它会帮你把整个逻辑链条展开。

这也是我最近越来越喜欢和 AI 聊产业的原因。

有时候一条政策,背后可能就是一个新行业的开始。

OpenClaw 用 Brave Search 还是 SearXNG?

最近在折腾 openclaw 的时候,我发现一个挺有意思的变化。

之前版本在配置联网搜索时,需要自己去申请 Brave Search API Key,然后填到配置里。也就是说,如果你想让 openclaw 的 Agent 能够联网查资料,基本默认是走 Brave Search

但最近更新的版本里,情况变了 —— openclaw 直接内置了 SearXNG

这就带来一个问题:

openclaw 到底用 Brave Search 好,还是 SearXNG 更好?

我自己折腾了一圈之后,整理了一些实际体验。


一、两者本质就不是一类东西

很多人第一次看到这两个名字,会以为它们是同一种服务,但其实完全不同。

Brave Search

  • 一个独立搜索引擎
  • 有自己的网页索引
  • 需要 API Key
  • 官方托管

SearXNG

  • 一个开源的搜索聚合器
  • 本身不做搜索
  • 只是聚合多个搜索引擎结果
  • 可以自己部署

简单理解:

Brave Search = 搜索引擎

SearXNG = 搜索引擎聚合器

所以 openclaw 从 Brave 改成内置 SearXNG,其实是架构上的一个变化。


二、为什么旧版 openclaw 用 Brave

最早 openclaw 默认推荐 Brave Search,原因其实很现实:

1、质量比较稳定

Brave 是少数拥有 自己网页索引 的搜索引擎之一。

相比一些隐私搜索引擎(例如 DuckDuckGo),Brave 的结果通常更稳定一些。


2、API 非常简单

配置只需要:

BRAVE_SEARCH_API_KEY=xxxx

然后 Agent 就可以直接调用。

对开发者来说,这是最省事的方式。


3、速度比较快

Brave Search 只有一个数据源。

不像聚合搜索那样需要请求多个引擎。

所以延迟通常更低。


三、新版 openclaw 为什么改成 SearXNG

新版 openclaw 直接把 SearXNG 集成进来了,我猜背后的原因主要有三个。

1、避免 API Key

很多用户第一次部署时会卡在这里:

  • 不知道去哪里申请
  • 有免费额度限制
  • 有些地区申请比较麻烦

而 SearXNG:

不需要 API Key

直接就能用。


2、可以聚合更多信息源

SearXNG 最大的优势是:

可以同时查多个来源。

比如:

  • Google
  • Bing
  • Brave
  • DuckDuckGo
  • GitHub
  • Reddit
  • StackOverflow

Agent 的搜索结构会变成这样:

Agent
   ↓
SearXNG
   ↓
多个搜索引擎

信息覆盖面更大。


3、开源生态更喜欢 SearXNG

很多 AI 项目都用它做联网搜索,比如:

  • OpenWebUI
  • LibreChat
  • Flowise
  • OpenDevin

原因很简单:

SearXNG 有完整 API,而且完全开源。


四、实际使用体验

我简单总结一下两者的实际感受。

Brave Search

优点:

  • 搜索结果比较干净
  • API 简单
  • 速度快
  • 稳定

缺点:

  • 需要 API Key
  • 免费额度有限
  • 信息来源单一

SearXNG

优点:

  • 不需要 Key
  • 可自托管
  • 可聚合多个搜索源
  • 非常适合 AI Agent

缺点:

  • 速度可能慢一点
  • 有时排序不太稳定
  • 依赖后端搜索源

五、哪个更适合 openclaw

如果只是 普通搜索能力

我其实更喜欢 Brave Search

结果更稳定。


但如果是 AI Agent 联网搜索

我觉得 SearXNG 更合适

原因很简单:

信息来源越多
Agent 幻觉越少

尤其是当你把 GitHub、Reddit、StackOverflow 这些技术社区也加入搜索源之后,AI 找资料的能力会明显变强。


六、我现在的配置

我现在比较推荐的方案是:

openclaw
   ↓
SearXNG
   ↓
Brave + Google + Bing + GitHub

这样:

  • Brave 负责稳定搜索
  • Google/Bing 补充索引
  • GitHub 提供技术内容

基本算是比较均衡的配置。


七、一个挺明显的趋势

其实从 openclaw 这次更新也能看出来一件事:

AI 工具正在从「单搜索源」走向「搜索聚合」。

因为对 Agent 来说:

信息覆盖面
比
单一搜索质量
更重要

未来很多 AI IDE、AI Agent,很可能都会内置类似 SearXNG 这样的搜索聚合层。


如果你也在折腾 openclaw,或者在搭自己的 AI Agent,我的建议是:

先用默认的 SearXNG。

等玩熟了,再考虑把 Brave Search 也加进去。

效果会更好一点。

微调还是 RAG?

前几天在小红书上刷到一篇文章,标题挺炸的:《黄仁勋踢爆 AI 死胡同:你微调的 Kimi,全是智商税!》

文章核心观点就一个:别微调了,RAG 才是未来。

说实话,看到这种标题我第一反应是——又来个流量文。但里面讲的电商客服案例确实有点意思:花小十万微调了个模型,结果客服问什么它瞎编什么,连产品型号都能给你创造出来。

这我就来兴趣了。刚好最近在折腾 OpenClaw,也想搞清楚这个问题——2026 年了,微调和 RAG 到底该怎么选?

先说结论

我拿着这篇文章去问了 ChatGPT,它的回答挺直接:

这个观点一半对,一半过度简化。

微调和 RAG 根本不是替代关系,而是互补的。真实世界的 AI 产品架构是:

RAG + Agent + Tool + 微调

而不是文章说的那种非此即彼。

微调到底能学到什么?

文章说微调学不到知识,只能学风格。这个说法……只对一半。

2023 年的时候确实是这样。用几万条文档去微调 LLaMA,模型根本记不住,还容易产生幻觉。所以当时 RAG 火起来了。

但现在 2026 年了,微调技术已经升级了:

  • LoRA / QLoRA:低成本微调
  • Instruction tuning:提升任务能力
  • Preference tuning:控制行为
  • RAG-aware training:结合检索一起训练

你看现在的 AI 产品——ChatGPT、Claude、Cursor、Perplexity、Kimi——哪个没有微调?

所以文章说”没有微调的 AI 应用基本不存在”,这点是对的。但它前面又说别微调了,这就自相矛盾了。

RAG 也不是万能药

文章把 RAG 描述成零成本、无幻觉的银弹。但真正做过 RAG 项目的人都知道——

这玩意儿是工程地狱。

一个能用的 RAG 系统,你要解决:

  1. 文档切块:切不好就找不到答案,语义还丢失
  2. Embedding 选型:BGE、E5、GTE、OpenAI,差别很大
  3. 检索策略:不是简单 topK,要 hybrid search、rerank、multi-query
  4. 上下文长度:检索错了,1M context 也救不了
  5. 更新问题:文档一变,重新 embedding,rebuild index

我有个朋友在公司搞 RAG 客服,他说维护成本比预期高了至少三倍。

那到底该怎么选?

如果面试官问我这个问题(毕竟我最近在准备跳槽),我会这么回答:

RAG 解决的是”知识更新问题”,微调解决的是”能力和行为问题”。

举个例子:

  • 要做企业客服 AI,产品文档经常变 → 用 RAG
  • 要模型稳定输出 JSON 格式,或者学会特定 API 调用 → 用微调
  • 想要效果好 → 两个一起用

真实架构一般是这样:

User Question → RAG 检索 → LLM 推理 → 微调模型保证输出格式 → Response

前端视角

作为前端开发,其实我们更多做的是 AI 应用层的集成,而不是直接训练模型。

比如我最近在搞的 OpenClaw:

  • 聊天 UI
  • 知识库检索界面
  • Agent workflow 配置
  • 流式响应处理
  • Tool call 的交互设计

这些东西比”会不会微调”更重要。因为前端在 AI 时代的位置,是连接用户和模型的桥梁。

一点感悟

文章最后有个问题:未来 5 年,对普通人来说更有价值的是”学会一个新 AI 工具的操作”,还是”建立一个属于自己的结构化知识库”?

ChatGPT 给的答案是:都不是。

真正值钱的是——用 AI 构建解决问题的系统。

这点我挺认同的。像我最近在弄的:

  • OpenClaw 多 Agent 配置
  • 股票监控智能体
  • 自动化工作流

其实都是在做这件事:不是学工具,而是构建自己的 AI workflow。

AI 抹平的是执行层面的技能鸿沟。以后拼的不是谁的算力更强,而是谁的认知结构更清晰,谁的知识体系更独特,谁更能提出一个好问题。

所以回到标题——微调还是 RAG?

我的答案:别站队,哪个能解决问题用哪个。实在不行,两个一起上。

毕竟工程世界不是非黑即白,能跑的代码就是好代码。🦞