开发背景

了解Harness的运行机制以后,我找了个小东西练练手.我选择了浏览器插件.

1. 我固执的认为,后续的AI很大概率会以插件的方式存在,而浏览器是一个非常重要的工具.
2. 完全了解Harness的原理,冲入一个完全陌生的领域,能检测AI对我的提升.

基于上述2点,我选择了为浏览器开发一个AI插件.

这个是源码,有心人自取.

AI操作系统

还记得OpenClaw推出的时候,有人说,这个东东是AI操作系统.

如果真的是操作系统,那么我可以这么推断:

• 大模型就是运行操作系统的CPU
• 大模型的上下文就是运行操作系统的内存
• 大模型的记忆就是运行操作系统的磁盘

Harness,正是操作系统的cpu调度理论和内存清理理论.

说句题外话,Deepseek4的发布,就像它的发布标题一样,这套操作系统的运行内存,从200k的时代进入到了1M时代,虽然国外早就到2M了.

要知道,现在的计算机,也是从64k内存开始起步的.

最近这段时间，我在深度使用各种AI编程工具的过程中，脑子里一直冒出一个念头——我们是不是把注意力放错地方了？

所有人都在讨论"哪个模型最强"、"谁的推理能力碾压了谁"，但我越用越觉得，问题根本不在模型本身。今天这篇文章，想和大家聊聊我在Agentic编程这个方向上的一些思考，不装，不端，就是一个码农的真实体感。

一、Harness：被忽略的真正战场

模型不是瓶颈，驾驭才是

我先说一个可能颠覆很多人认知的事情：当前AI编程的真正瓶颈，不是模型，而是驾驭模型的方式。

这个观点不是我的原创，而是来自安全研究员Can Bölük在2026年2月发布的一篇文章——《The Harness Problem》（驾驭框架问题）。这篇文章在AI编程圈子里引发了很大的讨论，而我读完之后的感受就是：这不就是我一直想说但没说清楚的话吗？

将你的个人介绍和档案放置在此处。

我的乐趣,你看着就好.

技术乱搞

• 家庭网络折腾 - 2023-01-20
• 打印机的研究 - 2022-03-28
• 手机变成服务器 - 2021-11-03

技术方案的首要前提是,能不能落地?有不能纯粹的考虑技术方案能不能落地,就会陷入技术人员用自己熟悉的技术的局限内.

技术方案还需要使用场景,使用场景不一定要是对现有系统全方位的改造,可以是针对当前的方案的改造.

技术方案的创新不一定要体现推翻原有系统.任何的推翻意味着对前面的否定,推翻的越多,阻力也就越大,况且,是否真正明白当时方案的选择和妥协???

从A->B中间加个C,变成A->C->B是一种创新,从A->C->B,中间去掉一个C也是一种创新.

针对微服务的架构来说,方案都能说清楚,但是面临的系统在业务中的解释是不一样的.

spring-cache提供了很好的调用接口,对于开发人员在使用cache的时候,可以做到很简单.但是spring-cache有下面几点做的很不好,而且在短时间内,看不到spring有优化的可能

• 没有提供过期时间设置,这是一个很严重的问题
• 没有针对cache的防穿透处理

qilu-cache仿照spring-cache的api,支持上述2种场景,缓存数据存储使用fastjson做数据序列化.和一般的cache封装不太一样,除了提供原始介质的set,get操作,还提供cacheService的高级封装操作,可以有效避免缓存穿透.

因为工作原因,看了一下动态数据源的东东,从开源的东西上看,动态数据源都是基于spring的AbstractRoutingDataSource进行扩展,spring内部还是认为一个数据源,管理的还是一个连接.

但是外部大量的开源的内容,都没考虑到动态数据源在项目使用过程中的意义.这边有必要说明下.

所谓的动态数据源,主要有2种场景

1. 内部管理类场景,因为执行和管理分离,而且执行单元有自己的数据库,管理单元也有自己的数据库,但是管理一般是要访问执行单元的数据库.这就给管理单元提出了一个问题,到底是管理单元接入多个数据源还是把其他的数据同步到管理单元的数据库?

当看到Feign的源码,我就想到我曾经写的HttpService,在springCloud还没有流行的时候,我曾经开发的HttpService的中间件就已经在使用类似的机制来实现远程调用了.

在差不多12年的时候,当时设计的初衷就是不想使用Dubbo,因为dubbo太重量级,如果直接通过http进行远程服务的调用,会更加轻量级.而早在spring1.x的年代,spring就已经推出HttpInvoker,使用Http协议进行远程调用了.当时我们看到HttpInvoker非常不好用,就自己写了HttpService.

所以直到目前为止,我对于springCloud中广为吹牛的ribbon,hytrix等功能,都不是太感冒,中间整了那么多概念,本质上就是通过java来实现了NGINX的功能,非常华而不实.

logTrace是在排错的时候,查询服务器日志的时候冒出来的需求.一旦一个应用被部署到服务器上以后,在应用的手段内,就只能看到日志情况,而日志本身会受到多线程并发的影响,在并发比较大的情况下,排查一个线程的执行情况,如果没有一个traceKey作为查询条件的话,会面临一种很无力的局面.

logTrace最大的想法,是结合linux的grep命令,在最小侵入开发的情况下,最大程度的提供日志查询的简洁---通过2组grep命令,来实现查看某一个线程的所有日志.

代码集成

maven依赖

logback集成请引入

<dependency>
	<groupId>com.9istock.base</groupId>
	<artifactId>qilu-logtrace-logback</artifactId>
	<version>1.0.0</version>
</dependency>