IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:OpenAI

共 3 篇相关文章

IT 累计浏览 115

使用 CLIProxyAPI, 让最新的 Codex 能够支持国内的各大模型

CLIProxyAPI 是一个轻量级 AI API 代理服务器,核心功能是实现 OpenAI Responses API 与 Chat Completions API 之间的双向格式转换,从而解决 OpenAI Codex CLI 仅支持 Responses API 而国内模型如 DeepSeek、GLM、Kimi 等仅提供 Chat Completions API 的兼容性问题。工作原理涉及请求方向的格式映射(如将 instructions 转换为 system message)和响应方向的流式 SSE 数据支持。安装通过 Git 克隆和 Go 编译完成,配置灵活,支持多 Provider 和模型别名设置,配置文件采用 YAML 格式并支持热加载。路由机制允许通过 prefix 前缀或 alias 自动匹配指定 Provider,避免重名冲突。文章提供了详细的配置示例,包括添加新 Provider 和模型,以及关键配置项说明。此工具简化了 Codex CLI 与国内 AI 模型的集成,适用于有 API 代理需求的开发者。

IT 累计浏览 97

Kakapo:使用 Wails v3、Go 和 Echo 构建一个本地翻译工作台

Kakapo 是一个本地桌面翻译工作台,基于 Wails v3、Go 和 Echo 构建,集成多个 OpenAI 兼容模型如 Kimi、DeepSeek 和 OpenAI,支持多模型并行翻译、结果比较、回译、系统朗读和本地历史记录。项目配置存储在 settings.json,API Key 通过 macOS Keychain 安全保存,历史记录存储在 history.json。文章详细记录了从零开始实现 Kakapo 的过程,探讨了 Wails v3 框架如何结合 Go 语言和系统 WebView 构建跨平台桌面应用,以及 Echo Web 框架在处理后端逻辑和 API 集成中的作用。文中分析了在桌面工具场景下使用 OpenAI 兼容接口进行多模型翻译的实践,包括并行处理模型响应、比较翻译结果、实现回译功能和集成系统朗读的实现方式。同时,讨论了数据存储策略、安全性考虑(如使用 Keychain 管理敏感信息)以及在实际开发中遇到的技术取舍和优化方案。通过本文,读者可以了解如何利用现代技术栈构建功能丰富的本地 AI 辅助工具,获取设计和实现方面的经验。

IT 累计浏览 169

万字长文推演:手机不再从 App 开始,Agent OS 如何接管任务入口

该文从OpenAI手机产业链传闻切入,探讨了手机操作系统从以App为中心向以AI Agent任务为中心演进的系统性变革。核心观点在于,当用户目标从“打开App”转向“完成任务”时,手机OS需进行深层次的结构迁移:前台从App网格变为任务流,后台从App独占能力变为可授权能力,系统从管理进程窗口转向管理任务、上下文与责任。 文章指出,Agent OS需解决五个关键问题:持续理解用户状态、App转为后台能力提供者、建立可恢复审计的任务运行时、端云按需分工、明确跨边界执行的权限与回滚机制。针对Android平台,作者分析了其作为Agent OS基座的优劣,认为短期更可能从现有系统服务、能力声明框架(如AppFunctions)和Agent协议(如A2A、MCP)中渐进演化,而非彻底重构。变革的关键在于系统层需新增一套对象模型来管理任务(Task)、能力(Capability)、上下文(Context)、权限授权(Grant)和审计记录(Audit),从而将App封装为可调度的能力单元。 最终,这场变革旨在让用户从管理App图标转为管理任务状态,推动手机成为真正的智能任务执行中心。