我最开始用的team版本的chatgpt账号通告codex插件帮我创建了一个项目，但是由于额度不够了，我替换到了用站里大佬的chatgpt2api项目跑注册机注册了一些gpt free账号，然后转化成api之后通告cc-switch配置到了codex里，同样都是gpt5-5的模型，为什么直接登陆账号和这种api效果不一样呢？这种api的貌似没办法直接操作文件系统，是我哪里配置的不对吗？求教各位大佬 4 个帖子 - 2 位参与者 阅读完整话题
我一直是用IDE的，对这种已经看不到源代码和文件系统的编辑器还是不太习惯 是现在的许多程序员都已经完全不审代码也不关心源码了吗，只关心抽象逻辑，还是说连抽象逻辑也不关心了呢？完全用口语化的自然语言描述需求，出了问题就再让AI去改？ 可能是我太保守了，对现在的这种疑似把代码当黑盒的趋势感到迷茫，我当然也是Vibe Coding可我自己还是全部自己review的，提示词也会把详细的逻辑掰碎写出来，整体的思路也是我提或者至少我是过目了的 如果完全用口语化自然语言描述需求，把代码，抽象逻辑，架构都视作一种黑盒，然后自己只负责优化prompt和配置skills，那为什么还需要程序员呢，公司直接全权AI好了，成本低多了 10 个帖子 - 7 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 Agent文件系统检索核心：Grep和Glob工具 今天看到一篇文章，说在Harness的定义组件中，Agent的文件系统是核心之一 在文件系统的帮助下，Agent表现出来的搜索能力是非常出色的，用户和开发者不定义搜索路径，只提供输入驱动，而具体的搜索路径是由Agent根据每一次的工具调用动态决定的 Agent的文件检索能力的实现关键，就来源于基础工具：Grep和Glob 最近也在仔细读ClaudeCode的源码，具体的代码实现中有更多“补丁设计”，感觉对于新手不是很友好，读的时候，我觉得opencode或者gemini-cli的实现或许更友好一些，设计和实现都比较干净，如果有相同困惑的佬可以考虑看看 grep和glob这两个工具在很多Agent SDK都是自带的，一方面你可以不用从0开发，可以直接使用框架自带的方法，另外一方面也说明该工具的重要性，我觉得可以成为大模型一样开发claw模式下的基础设施工具 附加一张claudecode的SDK的图说明一下 本文节选自「大模型应用开发 - 上下文工程与运行空间实践指南」 上下文工程是设计原则，Agent Harness 是构建目标。完整内容已发布在 GitHub，欢迎查看 GitHub - WakeUp-Jin/Practical-Guide-to-Context-Engineering: 大模型应用开发的方向，上下文工程是设计原则，Agent Harness 是构建目标，本项目的目标，是为开发者和研究者提供一份大模型应用开发的骨架思路 · GitHub 一、Glob 工具实现 glob 工具是存在降级策略的，为了提高执行效率和降低运行占用量 实现 glob 工具有两种方式，这两种方式“各有各的”好处 glob 依赖包 ：返回的是完整的文件的信息(存在文件元信息等，例如文件大小，文件修改时间)，所以不需要额外的操作，并且 glob 依赖包是天然的 Node 环境的包 ripgrep 命令 ：返回的是文件路径，没有任何文件元信息，所以需要在操作读取文件信息的操作， stat 方法，但是 ripgrep 检索的速度是比 glob 快的，但是 ripgrep 是 Rust 实现的，所以运行时需要加载一个二进制文件 关于 glob 工具执行的总时间，这里有一个形象的公式： 总时间=检索时间+ N*单文件的处理时间 glob 依赖包的实现方式，后面的那个单文件处理时间完全可以忽略不计，所以其检索时间就约等于总时间 ripgrep 命令的实现方式，检索时间是比 glob 依赖包的方式更快的，但是其需要单文件的处理时间，也就是 stat 方法的调用时间 我的建议和总结是： 如果是追求开发方便 ，那么我是建议直接使用 glob 实现，会快很多，并且不需要考虑外部文件的执行 如果是追求可操作的检索效率 ，那么是可以考虑使用 ripgrep 来实现，检索工具不可能只实现 glob，也会考虑使用 grep 的，要实现 grep，ripgrep 这个命令是优先考虑的，这么一看也不算是另外单独引入一个外部依赖 如果是追求稳定 ，那么可以考虑降级策略，先使用 ripgrep，如果 ripgrep 这个环境不存在或者下载失败，那么就可以降级为 glob，保证了程序或者项目可以运行 二、Grep 工具的实现 目前 grep 有四种的方式实现，按照优先级排序，保证系统的稳定的可用性，使用降级策略保证 grep 工具执行成功，我们会先验证这些策略的可用性，再考虑优先级高的先使用 ripgrep：是使用 Rust 编写的二进制文件，检索速度非常非常快 git grep 命令：这个是直接读取.git/index 中已缓存的文件列表，跳过耗时的目录遍历操作 系统的 grep 命令：大部分是传统的 C 实现的，单线程递归搜索，速度还可以，大部分 Unix 系统都有，不过 windows 系统是没有的 js 实现的 grep 命令：是纯 JS 实现的，是一个保底方案，用 glob 获取文件列表，逐个读取文件内容，逐行正则匹配，速度最慢 三、Ripgrep 自动下载机制 ripgrep 命令的执行需要完整的路径，在 Node 子进程中使用 spawn 的时候，需要完整的路径才可以成功执行命令 async function grepWithRipgrep(pattern, cwd, options) { // 获取 ripgrep 路径 const rgPath = await Ripgrep.filepath(options.binDir); // 返回：/usr/bin/rg 或 ~/.reason/bin/rg // 使用路径执行命令 const proc = spawn(rgPath, [ '--line-number', '--no-heading', pattern, ], { cwd }); } 所以目前的判断获取的策略是这样的： 先看看内存缓存中是否存在，如果没有就进入下一级，有就返回 再看看系统是否有安装 ripgrep，如果有就返回并且赋值给缓存，下一次就可以直接缓存取啦，如果没有就下一级 然后在看看本地路径是否安装了 ripgrep 的二进制文件，要是有安装的话，和上面同理，如果没有就开始进行下载文件到相应的目录中 四、超时控制 实现这个需求，在 Node 中会使用到中止控制器 AbortController/AbortSignal ，这里有一个简单的例子： const controller = new AbortController(); function customTask(signal: AbortSignal): Promise<string> { return new Promise((resolve, reject) => { //初始状态的检查 if (signal.aborted) { reject(new Error('Task aborted')); return; } const timer = setTimeout(() => resolve('done'), 5000); // 使用 { once: true } 自动清理监听器 const abortHandler = () => { clearTimeout(timer); reject(new Error('Task aborted')); }; signal.addEventListener('abort', abortHandler, { once: true }); // 或者手动清理（如果需要在 resolve 时也清理） const cleanup = () => { signal.removeEventListener('abort', abortHandler); }; // 修改 timer 回调 const timerCallback = () => { cleanup(); resolve('done'); }; setTimeout(timerCallback, 5000); }); } customTask(controller.signal); // 3秒后取消 setTimeout(() => { controller.abort(); }, 3000); AbortController ：这个是控制器，用来发送“取消”信号 AbortSignal ：这个是信号，传递给异步操作，让它们可以被取消 关于 AbortSignal 这个对象，有一些属性是值得理解一下的，会让你在异步操作使用更加熟练 interface AbortSignal{ readonly aborted:boolean //是否已经被取消 readonly reason:any //取消的原因 //监听取消事件 addEventListener( type:'abort', listener:(event:Event)=>void, options?:{once?:boolean} ):void //移除取消事件监听器 removeEventListener( type:'abort', listener:(event:Event) => void ):void //用于检查信息是否已取消 throwIfAborted():void } 那我们开始整理超时控制的函数式如何写的，主要就是三步： 封装取消函数，这个函数返回信号对象 创建一个包装器，传入要取消的函数操作，用于包装任何的异步操作 传入参数给异步操作 //完整的核心代码如下 //1、创建取消函数，返回信号对象 export function createTimeoutSignal( timeoutMs: number, externalSignal?: AbortSignal ): { signal: AbortSignal; cleanup: () => void; isTimeout: () => boolean; } { const controller = new AbortController(); let timedOut = false; // 超时定时器 const timeoutId = setTimeout(() => { timedOut = true; controller.abort(); }, timeoutMs); // 监听外部中止信号 const abortHandler = () => { clearTimeout(timeoutId); controller.abort(); }; externalSignal?.addEventListener('abort', abortHandler, { once: true }); // 清理函数 const cleanup = () => { clearTimeout(timeoutId); externalSignal?.removeEventListener('abort', abortHandler); }; return { signal: controller.signal, cleanup, isTimeout: () => timedOut, }; } //2、创建异步操作包装器 export async function withTimeout<T>( promiseFactory: (signal: AbortSignal) => Promise<T>, timeoutMs: number, operation: string, externalSignal?: AbortSignal ): Promise<T> { // 1. 提前检查 if (externalSignal?.aborted) { throw createAbortError(); } // 2. 创建超时信号 const { signal, cleanup, isTimeout } = createTimeoutSignal(timeoutMs, externalSignal); try { // 3. 执行操作，传入信号 const result = await promiseFactory(signal); // 4. 成功完成，清理资源 cleanup(); return result; } catch (error) { // 5. 失败，清理资源 cleanup(); // 6. 如果是超时导致的中止，抛出 TimeoutError if (isTimeout() && isAbortError(error)) { throw createTimeoutError(operation, timeoutMs); } // 7. 其他情况原样抛出 throw error; } } //3、传递取消信号为进程执行的异步函数 - 简化版 function spawnAsync(command: string, args: string[], signal?: AbortSignal): Promise<void> { return new Promise((resolve, reject) => { const proc = child_process.spawn(command, args); // 监听取消信号 signal?.addEventListener('abort', () => { proc.kill(); reject(new Error('Aborted')); }, { once: true }); proc.on('close', (code) => { code === 0 ? resolve() : reject(new Error(`Exit code ${code}`)); }); proc.on('error', reject); }); } await withTimeout( (signal) => spawnAsync('long-command', [], { signal }), 5000, // 5秒超时 'command execution', userCancelSignal // 用户可手动取消 ); 1 个帖子 - 1 位参与者 阅读完整话题
IT之家 4 月 13 日消息，不出所料，稳定版 Linux 7.0 内核已于今日正式发布，开启了这一全新内核版本的篇章。Linux 7.0 这一版本的推出，源于林纳斯 · 托瓦兹（Linus Torvalds）的惯例 —— 在次版本号达到 X.19 后便提升主版本号，而非因某项重大变革才升级。尽管如此，这一新内核版本仍带来了大量出色的改进与更新。即将发布的 Ubuntu 26.04 LTS 系统，也将搭载 Linux 7.0 内核。 IT之家注意到，Linux 7.0 包含众多新特性与改动，例如对英特尔 Nova Lake 平台的更多支持、英特尔 Crescent Island 加速器的进一步适配、新增对 AMD 新一代图形 IP 模块的支持、XFS 文件系统的自修复能力、多项性能优化、英特尔 TSX 指令集默认设为自动模式，以及 Linux 内核终于实现标准化的通用 I/O 错误上报机制等。 在今日 Linux 7.0 正式发布前，一系列临期补丁曾让外界一度怀疑 v7.0 稳定版能否如期推出。这些最后关头的修复包括：解决 AMD Zen 3 处理器上部分虚假硬件报错问题，以及修复 X.509 证书代码中一处越界访问漏洞，该漏洞可被非特权用户触发，且已在主线内核中存在三年之久。本周还为 Armoury 驱动新增了多款华硕设备 ID，并为即将上市的笔记本电脑新增了用于 AI 助手交互按键的 HID 编码。 Linux 7.0 现已正式发布，接下来将进入 Linux 7.1 合并窗口，预计会有更多新特性登场，开源开发这一美好且永不停歇的循环仍在继续。