mytharcher

最近 memory 工程很多做 Agent 都在搞，就看哪家的方案更高效，既能节省 token ，又能带上合理的上下文。如果 OpenHermit 存在数据库，是不是搞一下向量化后期检索更好？

可以同时接两个键盘的时候，不同键盘之间使用组合键，比如键盘 1 按 CMD ，键盘 2 按 C 就等于 CMD+C 。然而没有这个软件无论如何也做不到。

问我为什么要同时用两个键盘？因为分体键盘才更符合人体工学，两只手不用聚拢在一个键盘上，可以各自分开摆放，肘部弯曲更自然，减少神经损伤。

再进一步，讲个笑话，我去年被确诊为周围神经病。

试试 Chrome remote desktop ，用很久了，不需要内网穿透，但是要挂梯子。

所有这些问题都是对日期和时间描述精度的问题。以下举例：

1. 用户要查 2023 年的数据，此时精度是“年”，那么界面上只需要选年，但后端要执行的查询应该是 >= 2023-01-01 00:00:00 && < 2024-01-01 00:00:00 。
2. 用户要查 2023 年 11 月的数据，此时精度是“月”，界面上需要选年-月，但后端要执行的查询应该是 >= 2023-11-01 00:00:00 && < 2023-12-01 00:00:00 。
3. 用户要查 2023 年 11 月 5 日的数据，此时精度是“日”，界面上只需要选年-月-日，但后端要执行的查询应该是是 >= 2023-11-05 00:00:00 && < 2023-11-06 00:00:00 。
4. ...

时、分、秒、毫秒、微秒等精度类似，不再继续举例。

以上举例我们可以得到的结论是，要查什么精度，那么后端需要执行的区间范围就是其精度所在时间的起始（闭区间）到其精度 +1 单位后的时间结束（开区间）。所以传开闭区间的条件比较合理。如果 HTTP 接口上不支持开闭条件的描述（>= 和 <），那么就只能后端拿到查询参数串后根据提供的精度解析，比如传了 2023 ，就认为精度是年，传了 2023-11-05 则认为精度是日，传 2023-11-05 12:41:32 则认为是秒，均按此精度统一规则处理，查询就不会有问题了。

尤其避免一些传 23:59:59 却不包含最后一秒内数据的误解。

所以区别两者，最核心的是你的 HTTP 接口上是否能表达“>=”/“<”这些非相等的运算符，如果可以，那么前端可以按精确时间传闭开区间的表达。如果不行，那么只能按精度字符串传，由后端根据精度信息进行理解。

如果不是为了好看真不建议用面板，至少 TP 的容易发热而且信号差普通路由太多，甚至还有用坏的（用了一套 AC+AP 1202GI ）。

评测看过这个： https://www.acwifi.net/6915.html 比较符合。

我这有 32 位 CPU 的旧主机，能装 XP/wind/wn10 ，你要收么？

我的：



以及另一款：



详情在这： /t/847626

来看看我设计的吧： /t/847626

不知道你要配合妙控键盘的还是机械键盘的，我店里都有哈