应该还不太能，当前模型的能力和成本，还不能当作一个纯粹的许愿机，使用者本身的 context 还是有一定的价值的。

当然不反对有特例，借助于大模型，可以达到之前完全陌生的领域，特别是对于触类旁通能力越强的人越有效。其实非常类似搜索引擎时代的搜索能力，人在陌生领域最大的问题是没有问题、没有关键词，要通多很多次的的搜索迭代才能拿到领域内人员熟知的问题和关键词，模型降低了这个过程的成本，但本质还是自身要有迭代能力。

“水管脱离主管道，通过破裂小孔顺利排水.jpg”

是是是，好好好，句句有回应，事事没着落。
拿多少钱干多少活，有基本的职业道德即可，甚至不用多高。
当前时代，耗材自我加压几乎没有任何性价比了。

一口馒头，一口炸花生米。碳水和油脂，极简的满足感。

- 首先，它是开发者预览版，没必要这么吹
- 其次，它是开发者预览版，没必要这么喷

再次证明网络对喷的核心逻辑是“你的情绪激动导致了我的情绪激动，先不要管实际情况了，让我们先喷起来吧”

主贴描述的现象是事实，但不应表示“Agent 缓存命中率”这个指标无效。原因应该是语义含糊问题，Agent 缓存命中率应该是一个受多场景多变量影响的指标，自媒体良莠不齐，含糊的描述，导致了传播层面的困惑。
稍微严肃一点的定义，对比多个 Agent 在相同的 codebase 、环境、链路、模型、提示语等因素，处理同一个相对复杂的业务场景，来比对缓存明中率，这样的指标应该是有意义的。因为 Agent 实现上的确有影响这个指标的因素，所以用于评估 Agent 是有效的。只是要严肃对比可能要有较为严格的测试设计。
那么 Agent 间的横向对比，和个人实际使用的纵向推进场景，有什么参考价值吗？除了来回拉扯的场景，其它可能差那么一点命中率没有太大关系，但的确是可以省钱的。

用了不到一个月，速度还可以。就是前两天不可用，以为就是常规跑路了，又临时买了个备用的。看到你发帖再试试才发现恢复了。
建议官网挂个公告通知什么的，官网大部分可以直连，群却基本无法直连，导致没有备用链路的话，完全不清楚故障情况。

各种贴牌、严选类的都在向南极人靠拢。

现状是正确的，归因是错误的。
OP 的结论是厂家故意把消费者骗进来杀，实际上产品厂家和安装服务是 2 个独立的利益主体，甚至有点冲突。安装服务本身就是一个非标的场景，OP 的意思应该是厂家应该提高售价，把这个非标环节包含进去，这个其实去买高端品牌应该可以缓解。走量的低端品牌，每个环节都要精打细算，不会算的都被市场淘汰了。

个人感觉还挺好用，最近 hy3 免费，基本常开了。比较适合干一些运维杂活，最近的 2 个会话：
- 在 2 个内网自建的 Nexus 实例间迁移 maven snapshots 制品，弄了十来分钟，算是一次性完成。
- 从 AzureDevOpsServer 中迁移 git 仓库到 gitea 实例，几百个仓库，半个小时迁移完成。
都是些零碎脏活，自己弄要翻 API 写脚本，怎么都要半天一天的，免费的 hy3 还没碰到排队，还要什么自行车。

@NealLason 从 gitlab runner 迁移到 Jenkins 还是挺更新我的认识的，以前总认为这是个反向操作。

感谢分享。
说一个我用此类工具的痛点，关于 DNS-01 验证的权限问题。涉及到和域名解析服务商 API 交互，几乎没有工具明确说明自己需要哪些权限，如何精细化控制权限。把整个域名解析能力交给一个第三方应用是很大的风险点，没有强背书的话，很难忽略这个风险。当然，可以自己根据服务商 API 文档自行摸索出一个最小权限，但真的很繁琐，甚至你看了半天文档，然后确认 API 权限不支持，无法缩小最小权限。如果工具本身有明确的说明，或更进一步对主流服务商有一个各自的权限配置示例，体验会好很多，可以节省很多风险评估时间。
上面只是说签发层面，全流程的话，第三方应用直接更新生产环境证书也是个风险点，各个环节都要认真评估才好。

选择一个合适的、不那么黑的争议点，很容易让普通人自发的“宣传”，争议点本身会自动的创造所谓的“自来黑”和“自来水”。争议点爆炸半径符合预期的话，这些曝光流量都算白赚的了。

easytier 还是更好用一些，在项目质量和信任背书层面，可能和商业公司支持的项目有些差距，但个人使用已经足够了，似乎也有很多基于这些开源项目做商业产品的。


@5261 是的，最简单的理解就是多点跨公网组成一个虚拟二层网络，这个基本就满足了大部分使用了。在这之上增加各种使用场景比如 DNS 、路由什么的。

还是有一些变通方案的，要从服务端和客户端两方面分析。
- 服务端就是缓存服务本身，比如 registry:2 ，是可以正常代理缓存非 docker.io 的上游仓库，配置环境变量即可。麻烦的是如果要缓存多个上游就要启动多个 registry ，还需要考虑前面放个反向代理和域名路由问题。也可以考虑 zot 、Harbor 类的方案。
- 客户端就比较多了，docker 的 mirror 配置仅对 docker.io 这个默认仓库生效。一个方法就是把其它仓库配置为 insecure-registries ，然后本地 hosts 劫持到上面部署的 registry 缓存代理上。如果是 nerdctl+containerd 就方便多了，自身的 mirror 配置比较丰富。可能还会涉及到 k3s 或 k8s 场景，mirror 配置上可能会多一层考虑，或直接使用底层的 containerd 。其它客户端 podman 、skopeo 、crane 等需要根据情况自行研究了。

看上去能解决问题，实际上的确是复杂了一些。这个场景目前的确没有一个共识的最佳实践，只能根据自己具体场景来摸索调整。

每个阶段有每个阶段的难处，但只要生一次病你就明白了，只要不生病，都算好带😂