标题: 各位佬，我也来分享一下机场订阅2T，使劲蹬
作者: #果灯
板块: #福利羊毛
编号: 1967424
帖子: https://linux.do/t/topic/1967424
时间: 2026-04-14 22:12:15
摘要:

各位佬，我也来分享一下机场订阅2T，使劲蹬
https://zhuzhuzhu.whtjdasha.com/dazhutou/dc41c98db736fcdabbdc4927b68be2ca
还望各位佬，点赞评论一下，争取尽快升2级

标题: oh-my-opencode如何卸载
作者: #WillAppear
板块: #开发调优
编号: 1967429
帖子: https://linux.do/t/topic/1967429
时间: 2026-04-14 22:12:27
摘要:

我之前安装了这个软件配置完毕了每个agent的模型后，这边openai有了新的模型它好像没有自动更新配置，我是不是需要把这个包完整卸载掉才能重新像第一次安装那样选择配置（第一次安装选择了claude后续被禁掉了一部分功能）

标题: 和claude说过自己是中国的，结果给我提示了
作者: #飞飞鱼
板块: #搞七捻三
编号: 1967435
帖子: https://linux.do/t/topic/1967435
时间: 2026-04-14 22:13:25
摘要:

这应该没事吧..我让他给我一些不用梯子的工具，然后就给我这个提示了

标题: 警惕：5.4用了错误的脚本，形同与删库
作者: #huo0
板块: #开发调优
编号: 1967436
帖子: https://linux.do/t/topic/1967436
时间: 2026-04-14 22:13:42
摘要:

让他增量编译，结果直接运行旧的脚本进行了惨无人道的：
全量编译（脚本第一步是，删除旧的源码产物）
发现时为时已晚了啊
幸亏是晚上，可以开着编译挂机回家睡觉

标题: 我的omc为什么不会调用haiku去读代码？
作者: #langchou
板块: #搞七捻三
编号: 1967447
帖子: https://linux.do/t/topic/1967447
时间: 2026-04-14 22:14:21
摘要:

全在用opus，用量变得很大！有佬知道是需要啥配置吗？

标题: 请教佬们有无类似mammouth.ai的模型全家桶网站
作者: #LGG G
板块: #开发调优
编号: 1967492
帖子: https://linux.do/t/topic/1967492
时间: 2026-04-14 22:20:49
摘要:

Mammouth AI
  

  
    

Stay at the top of AI

  The best GenAI models in one subscription. Access GPT, Claude, Gemini, Mistral, Llama, Nano Banana, GPT-image, FLUX, and stay up to date with AI.


  

  
    
    
  

  


他这是10基础版，有没有类似的全家桶网站，能有team功能一起用就更好了

标题: 关于prompt,context,以及harness的一点想法
作者: #babyfacedassassin
板块: #开发调优
编号: 1967498
帖子: https://linux.do/t/topic/1967498
时间: 2026-04-14 22:21:14
摘要:

之前做过一些AI应用的项目。踩过一些坑。最近整理了一些想法。贴出来跟大家交流一下。
过去几年，AI 应用工程的关注重点发生了一次非常清晰的迁移。早期开发者最关心的是，怎样写 prompt，才能让模型更稳定地理解指令、输出正确格式、减少跑题和幻觉。随后，随着长上下文、检索增强、工具调用和多轮状态管理逐渐成熟，问题转向了另一个方向：怎样为模型提供它在当前任务中真正需要的信息。再往前一步，当模型开始具备跨步骤执行复杂任务的能力，一个更深层的挑战浮现出来：即使模型已经理解任务，也拿到了足够的信息，怎样才能让它持续、可靠、可验证地把工作做完。
如果把这三个阶段放在一起看，就会发现它们并不是零散技巧的更替，而是 AI 应用工程的三层递进问题。第一层是 Prompt Engineering，解决的是如何表达意图；第二层是 Context Engineering，解决的是如何供给信息；第三层是 Harness Engineering，解决的是如何约束行为、验证结果并维持系统可靠性。它们共同构成了 AI Agent 从“能回答”走向“能工作”的一条演化路径。
Prompt关心的是接口，Context关心的是认知环境，Harness关心的是系统约束。理解这三层之间的关系，不仅能帮助我们解释行业讨论为何会从“提示词”转向“上下文”，再进一步转向“agent harness”，也能帮助团队在实践中更准确地判断：一个问题究竟应该在 prompt 层解决，在 context 层解决，还是必须上升到 harness 层解决。
Prompt Engineering 是最早出现、也最容易被大家感知的一层。原因很简单：在大模型开放 API 的早期，开发者最直接、往往也是唯一能控制的变量，就是输入给模型的那段文本。无论是最初的文本补全接口，还是后来的对话式界面，开发者首先面对的问题都是“怎么说，模型才更容易照着做”。因此，Prompt Engineering 的兴起并不神秘，它几乎是由交互形态本身决定的。模型能力尚不稳定时，表达方式自然成为第一控制杠杆。
Prompt 的作用，就是在人类意图与模型生成行为之间建立一个尽可能清晰、低歧义、可重复的接口。角色设定、示例提供、格式约束、分步指令，这些常见技术本质上都在做同一件事：让模型更准确地映射人的意图。但 Prompt Engineering 的边界也始终存在。它擅长解决的是“怎么表达”带来的偏差，却无法凭空补齐模型没有看到的信息，更无法独立解决跨轮次记忆、多工具协作、长任务验证和系统级恢复这些问题。当任务复杂度提升到一定程度，仅靠 prompt 写得更好，往往已经不够。
这正是 Context Engineering 兴起的背景。随着模型的上下文窗口扩大、工具调用能力增强、RAG 和各类记忆机制逐渐成熟，开发者开始越来越明显地感受到：很多失败并不是因为 prompt 写得不够好，而是因为模型没有在当下看到正确的信息。它可能不知道最新政策，不了解企业内部知识，不记得前几轮对话已经确认的决定，也可能虽然拿到了信息，却因为注入方式混乱而无法有效使用。到了这个阶段，问题的重心就从“如何提问”转向了“模型该看到什么”。
Context Engineering 的核心，不是简单地往上下文里塞更多内容，而是系统性地设计模型的认知环境。检索哪些材料、保留哪些历史、怎样压缩长文档、如何组织工具描述、哪些状态需要长期持久化、哪些信息应该在当前轮动态注入，这些都属于 Context Engineering 的范畴。它解决的是信息供给问题：在上下文窗口有限的前提下，如何在正确的时刻把正确的信息放进模型可见范围内。
这一层之所以重要，是因为大模型的很多“不会”，本质上不是能力缺失，而是信息缺席。模型在很多任务中并非不具备推理能力，而是推理所依赖的事实、状态和材料没有被正确供给。随着 AI 应用从聊天问答走向文档助手、代码代理、企业知识系统和工具增强型 agent，Context Engineering 逐渐从辅助环节变成主导环节，也就不难理解了。
但即便如此，一个拿到了正确信息的agent，仍可能在长任务中偏离目标，可能在没有验证结果的情况下过早宣布完成，可能持续复制代码库中的坏模式，可能在多次操作中悄悄积累错误，最终把本来局部可控的问题放大成系统性风险。到了这里，问题已经不再是信息供给，而是行为约束和系统可靠性。
Harness Engineering 之所以成为新的焦点，正是因为 agent 的失败模式已经超出了 prompt 和 context 两层能够单独解决的范围。Harness 所指向的，不是更多提示词，也不是更大的上下文，而是一整套包裹模型工作的外部系统：项目规则、状态文件、架构约束、自动化测试、静态检查、任务分解、反馈回路、回滚机制、子智能体编排，以及让错误能被发现、被反馈、被修正的全部工程设施。
如果说 Prompt 是告诉模型你要什么，Context 是让模型看到完成任务所需的信息，那么 Harness 做的就是让模型在真实系统里以可接受的方式把事情做成。它不是替代前两者，而是在前两者之上增加了一层对行为的调控。这个变化之所以关键，是因为一旦模型开始长时间自主工作，“回答对一个问题”就不再是核心标准，“能否持续在边界内完成一项任务”才是。
这也是为什么越来越多关于 agent 的高价值讨论，不再把注意力集中在单次输出质量，而是开始关注智能体的工作环境。没有测试的 agent 会自信地交付未验证结果，没有状态管理的 agent 会在跨会话中失忆，没有结构约束的 agent 会在代码库里不断扩散局部最优，没有反馈回路的 agent 即使犯了同一种错也会反复重演。换句话说，agent 的问题越来越像软件工程问题，而不再只是模型调用问题。

标题: 传统Java开发，不知道在AI怎么办。
作者: #7he-milo
板块: #搞七捻三
编号: 1967519
帖子: https://linux.do/t/topic/1967519
时间: 2026-04-14 22:24:43
摘要:

从事java大概10年了，对Spring那一套、还有Java EE规范还是熟悉，现在总感觉有一天会被淘汰。硬要混，其实也能混下去，但是不想被时代淘汰。
看了看BOSS，也看了L站帖子，说实话，感觉往AI靠拢，就还有前途；但就是不知道怎么学、学什么能工资高点。
也不知道现在热门是做什么的？做agent？还是训练模型？搞蒸馏？
训练模型、蒸馏，我觉得学习成本太高了。苹果的那什么MINI3，一台要5万多。

标题: 老黄即将上线GLM-5.1
作者: #北极之大
板块: #前沿快讯
编号: 1967527
帖子: https://linux.do/t/topic/1967527
时间: 2026-04-14 22:25:33
摘要:

该 API 将于 2026 年 4 月 20 日被弃用。2026 年 4 月 20 日之后将不再支持。请改用 z-ai/glm-5.1。欲了解更多信息，请访问我们的 API 参考页面。

标题: 分析一个本地运行 CPA 服务后，无法直接登陆 Codex 客户端的问题 http://localhost:1455/auth/callback?code
作者: #无糖酸奶
板块: #开发调优
编号: 1967535
帖子: https://linux.do/t/topic/1967535
时间: 2026-04-14 22:26:59
摘要:

环境 macOS，本地 Docker 运行 CPA 容器。
今天 Free token 用完了，开了个 Plus 号，准备直接登录账号使用。
输入账号验证码确认都没问题，最后一步跳转到此页面：http://localhost:1455/auth/callback?code=...，提示：页面显示无法访问此网站 localhost 拒绝了我们的连接
正常这里会唤起 Codex 客户端完成授权，但是没有。经排查是 1455 端口被占用。
解决办法：退出 CPA 容器，释放 1455 端口。
╰─$ lsof -i :1455
COMMAND     PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
OrbStack   7876   yz   84u  IPv4 0x550d075199c69765      0t0  TCP *:esl-lm (LISTEN)
OrbStack   7876   yz  112u  IPv6 0xb8730682aa89d6c5      0t0  TCP *:esl-lm (LISTEN)
OrbStack   7876   yz  120u  IPv6 0x38dedb38be5d2f05      0t0  TCP localhost:esl-lm->localhost:54588 (FIN_WAIT_2)
codex     95550   yz   25u  IPv4 0x8f4b80db84217eec      0t0  TCP localhost:esl-lm (LISTEN)

参考: 分享今天windows登录Codex时遇到一个坑及解决方法，http://localhost:1455/auth/callback?code=ac_Tu.....，无法访问此网站 localhost 拒绝了我们的连接请求