Hi, 请登录     我要注册     找回密码

Codex CLI 原生支持会话间协作，多 Agent 协同无需第三方编排

分类：未分类 阅读() 评论(0)

OpenAI 的 codex-cli/">Codex CLI 近期更新引入了一套原生的会话间协作工具 codex-tui，使多个终端会话之间可以直接通信与协作。该工具集包含九个指令：create_thread 创建并启动新任务，fork_thread 分叉任务但不自动开启新一轮，list_threads 与 list_archived_threads 分别列出近期活跃和已归档任务，read_thread 读取任务消息与状态，send_message_to_thread 向既有任务发送后续指令，wait_threads 等待任务完成、请求审批或用户输入，set_thread_title 修改任务标题，set_thread_archived 用于归档或恢复任务。其工作原理是让所有会话连接到一个共享 daemon 上，从而实现消息互通。该功能实际已上线约两周，但使用 codex -c 自定义配置启动的用户可能一直未察觉，源码中 -c 启动方式默认使用内嵌的 app-server，并不接入共享 daemon。用户可通过 /status 命令检查，若显示 Server: Local background server 即表示已连接共享守护进程，也可直接询问模型是否具备 codex-tui 工具。更稳定的启动方式是 codex agents，该方式对 -c 参数同样适用，可支持跨 provider 的对话协作，例如 codex -c “model_provider=’any’” agents。此前桌面端用户正是看中会话协作功能，如今 CLI 端也具备了原生互发消息能力。

事件分析

多 Agent 协同正从概念走向工程落地，Codex CLI 的做法是绕开复杂的编排框架，直接以共享守护进程为底座，让各会话具备互发消息、等待、分叉等原语，本质上是把 CLI 从单一交互界面升级为轻量级多智能体运行时。与社区常见的 MCP 桥接或外部编排脚本方案相比，这一原生路径减少了中间层损耗，也降低了使用门槛。从行业视角看，终端正在成为 Agent 编排的重要入口，Anthropic 的 Claude Code 也在探索类似的子任务与协同机制，两大主流 AI 编程工具的竞争焦点已从单轮代码生成转向任务调度与协同能力。后续值得关注的方向包括：跨 provider 协作时的状态一致性保障、共享 daemon 的权限与安全隔离设计，以及任务编排能力是否会进一步延伸到 GUI 桌面端与 CI 流水线场景。

核心观点：AI 编程工具的竞争已从单次代码生成转向多 Agent 协同调度，终端正成为智能体编排的新战场。

原文链接：Linux.do

C code80.ai · AI 编码 API 聚合 Claude / GPT 多模型统一接入,稳定不限速,按量计费,几行配置接入 Claude Code。 了解一下 ›

相关推荐

抢沙发

评论前必须登录！

立即登录   注册

易安
易安作者
长期关注 AI Agent、软件工程、自动化工作流与个人生产力系统。喜欢把复杂技术拆成普通人也能上手的实践教程,也记录自己在工具链、编程、内容创作和知识管理上的真实折腾。
  • 分享 AI 工具、Agent 工作流与提示词工程的实战经验
  • 记录从想法到产品、从代码到上线的完整实践过程
  • 关注普通人如何用 AI 放大能力,而不是被工具牵着走
阅读作者的全部文章 ›
文章目录

    置顶推荐

    Code80 · AI 编程巴士

    前沿哨所

    • ChatGPT秒变Manus？开源项目用GitHub Actions让AI直接操作电脑

      Linux.do社区用户发布开源项目Agent Computer（desktop-bridge），目标是让普通ChatGPT账号获得类似Muse、Grok Bot、Dots等热门AI智能体的电脑操作能力。由于这些产品存在注册限制，不少用户难以体验，该项目借助MCP协议和OAuth授权，将ChatGPT接入一个可操作浏览器、执行命令、读写文件的云端桌面环境。具体使用流程为：Fork仓库并启用GitHub Actions，在GitHub设置中配置登录密码，通过GitHub Actions启动项目容器，在ChatGPT网页版添加插件并填入MCP地址，最后在授权界面输入密码完成连接。项目默认就绪后运行60分钟，结束后文件与浏览器状态将被删除，用户需提前下载结果；用量受GitHub账户配额与Actions条款约束。对于需要长期运行的用户，项目另提供Docker自托管方案。该项目定位为自托管的计算机使用MCP网关，支持共享桌面、人工接管和可复现的Docker测试。模型推理与任务推进仍由ChatGPT负责，项目本身只提供电脑与工具环境。项目代码完整开源在GitHub上，作者表示欢迎社区Star支持。

      事件分析

      该项目的技术亮点在于将MCP协议、OAuth授权与GitHub Actions的临时算力结合，以近乎零成本搭建计算机使用环境，印证MCP正在成为大模型接入外部工具的事实标准。ChatGPT开放MCP插件接入后，社区围绕「模型+工具网关」的创新明显加速，模型能力与执行环境解耦的分工模式日趋清晰，智能体产品的竞争焦点正从模型本身转向工具链与执行环境。该方案也存在明显约束：GitHub Actions对免费额度与使用条款有严格限制，60分钟临时会话难以支撑长任务；将浏览器与文件系统交给模型操作存在凭据泄露与误操作风险，项目的人工接管机制属于针对性缓解。后续值得关注的变量包括ChatGPT官方是否推出原生计算机使用功能，以及微软对Actions承载此类负载的政策态度。

      核心观点：模型与工具解耦后，智能体竞争焦点正从模型能力转向执行环境，MCP让闭源模型也能长出手脚，民间方案与官方功能的赛跑已经开始。

      原文链接：Linux.do

    • OpenAI推出AI隐形文本水印：欧盟ChatGPT默认启用，检测仅限机构

      OpenAI推出面向文本生成的隐形水印技术，核心目标是对齐欧盟AI法案的合规要求。该技术通过在模型输出的文本中嵌入人眼不可见的统计特征，标记内容由AI生成，帮助区分人工撰写与机器生成内容，从源头遏制抄袭、学术造假与虚假信息传播。根据OpenAI公布的规则，该功能对不同用户群体采取差异化策略：API开发者默认不启用水印，可根据自身需求手动开启；位于欧盟地区的普通ChatGPT用户，其生成内容将自动附带隐形水印。在检测端，OpenAI采取严格的准入控制，水印检测器仅对合作机构与研究人员开放，普通用户无法随意查询一段文本是否由AI生成。这一安排意味着水印将成为OpenAI履行欧盟合规义务的基础设施之一，而检测权限的封闭设计也反映出其对误判风险与技术滥用持谨慎态度。对于依赖ChatGPT进行写作、翻译、代码生成等工作的欧盟用户而言，其获得的内容将在元数据层面新增AI生成标识，相关文本在学术查重、内容审核、版权认定等场景下的处理方式可能随之发生变化。

      事件分析

      从技术路径看，文本水印通常在token采样阶段注入可控偏置，对文本质量影响微小但具备统计可检测性，其鲁棒性仍面临改写、翻译、同义替换等对抗手段的考验。检测权限仅向机构开放，一方面规避了公众随意查验引发的误判争议与隐私纠纷，另一方面也使检测标准缺乏第三方监督，公信力取决于OpenAI自身的透明度承诺。产业层面，此举或推动谷歌、Meta等厂商跟进类似的合规标记方案，欧盟AI法案正从立法文本转化为实际的产品设计约束。后续值得关注三点：水印在长文本与代码场景的检出率、API侧开发者的实际启用率，以及欧盟之外市场是否会出台类似的AI生成内容强制标识标准。

      核心观点：OpenAI用水印回应监管，却把检测权锁进机构，合规易做，可信的中立检测才是真正的门槛。

      原文链接：Linux.do

    • 开发者打造免费 RAG 学习站：场景化学习路线与 AI 工程面试题一站整理

      一位开发者近日在 V2EX 分享了其搭建的 AI 学习站点 SaveMyToken.com，该站点聚焦 AI 应用开发领域的知识整理，主打 RAG（检索增强生成）学习路线与 AI 工程面试题两大板块。在 RAG 学习方面，站点采用场景化设计，学习者可先选择目标场景，如客服知识库或企业内部文档检索，再按照步骤浏览资料并完成练习。技术细节层面，内容覆盖了文档切分、检索策略、效果评测以及回答出错后的排查定位等 RAG 工程化全流程环节，帮助学习者建立完整的技术认知框架。面试题板块面向 AI 工程求职者，支持按 RAG、Agent、向量库等主题分类刷题，此外还收录了 FDE（前线部署工程师）场景题，贴合当前企业 AI 落地岗位的实际考察方向。该站点内容目前为英文，采取免费、免登录的开放模式，降低了使用门槛，作者表示希望收集用户反馈以持续改进体验。这类站点反映出当前 AI 应用开发领域的真实学习需求：RAG 已成为企业级 AI 落地的主流技术方案，学习者需要体系化的入门路径；同时 AI 工程师岗位竞争加剧，求职者对针对性面试准备资料的需求旺盛，社区开发者自发整理的结构化资源为碎片化的 AI 技术学习提供了新的补充选择。

      事件分析

      技术看点方面，该站点将 RAG 工程化流程拆解为场景选择、切分、检索、评测、错误排查等环节，体现出 RAG 技术正从概念演示走向可度量、可调试的工程学科。FDE 场景题的收录值得关注，这一岗位类型源于 OpenAI、Anthropic 等公司近年大规模招聘的 Forward Deployed Engineer，强调在客户现场交付 AI 解决方案的能力，其考察方式与传统后端面试差异明显。产业层面，此类站点的出现反映 AI 应用层人才市场供需两旺：企业需要能落地 RAG、Agent 项目的工程师，而系统化学习资料仍分散于论文、博客与开源项目之中，结构化整理存在真实需求。后续走向上，若站点能持续维护并考虑多语言支持，有机会成长为社区型 AI 工程知识库；但其价值高度依赖内容更新节奏能否匹配 RAG 技术栈的快速演进。

      核心观点：RAG 与 Agent 工程岗位需求爆发，碎片化 AI 知识的结构化整理正成为开发者生态的新基建。

      原文链接：V2EX 分享发现

    • Codex CLI 原生支持会话间协作，多 Agent 协同无需第三方编排

      OpenAI 的 Codex CLI 近期更新引入了一套原生的会话间协作工具 codex-tui，使多个终端会话之间可以直接通信与协作。该工具集包含九个指令：create_thread 创建并启动新任务，fork_thread 分叉任务但不自动开启新一轮，list_threads 与 list_archived_threads 分别列出近期活跃和已归档任务，read_thread 读取任务消息与状态，send_message_to_thread 向既有任务发送后续指令，wait_threads 等待任务完成、请求审批或用户输入，set_thread_title 修改任务标题，set_thread_archived 用于归档或恢复任务。其工作原理是让所有会话连接到一个共享 daemon 上，从而实现消息互通。该功能实际已上线约两周，但使用 codex -c 自定义配置启动的用户可能一直未察觉，源码中 -c 启动方式默认使用内嵌的 app-server，并不接入共享 daemon。用户可通过 /status 命令检查，若显示 Server: Local background server 即表示已连接共享守护进程，也可直接询问模型是否具备 codex-tui 工具。更稳定的启动方式是 codex agents，该方式对 -c 参数同样适用，可支持跨 provider 的对话协作，例如 codex -c “model_provider=’any'” agents。此前桌面端用户正是看中会话协作功能，如今 CLI 端也具备了原生互发消息能力。

      事件分析

      多 Agent 协同正从概念走向工程落地，Codex CLI 的做法是绕开复杂的编排框架，直接以共享守护进程为底座，让各会话具备互发消息、等待、分叉等原语，本质上是把 CLI 从单一交互界面升级为轻量级多智能体运行时。与社区常见的 MCP 桥接或外部编排脚本方案相比，这一原生路径减少了中间层损耗，也降低了使用门槛。从行业视角看，终端正在成为 Agent 编排的重要入口，Anthropic 的 Claude Code 也在探索类似的子任务与协同机制，两大主流 AI 编程工具的竞争焦点已从单轮代码生成转向任务调度与协同能力。后续值得关注的方向包括：跨 provider 协作时的状态一致性保障、共享 daemon 的权限与安全隔离设计，以及任务编排能力是否会进一步延伸到 GUI 桌面端与 CI 流水线场景。

      核心观点：AI 编程工具的竞争已从单次代码生成转向多 Agent 协同调度，终端正成为智能体编排的新战场。

      原文链接：Linux.do

    • 开发者开源AI Agent双向翻译插件：用中文流畅对话Claude

      一位开发者在V2EX分享了一款面向AI编程场景的开源浏览器插件parrot-agent-extensions，用于实现用户与AI Agent之间的双向翻译。项目源于开发者的实际观察：社区普遍建议使用英文与AI Agent沟通以获得更好效果，近期甚至有传言称使用中文对话可能提高Claude账号被封禁的概率。尽管传言未经官方证实，但语言门槛确实是中文用户使用海外AI工具的普遍痛点。基于此，开发者决定制作一款翻译插件，让中文用户能够以母语与AI Agent交互。其工作方式为双向翻译：用户输入的中文内容自动转换为英文发送给Agent，Agent返回的英文回复则被翻译成中文呈现，用户无需在多个翻译软件之间来回切换。目前插件已发布Claude版本，作为浏览器扩展安装后可直接在网页端使用，开发者表示将在近期补充对其他平台的适配支持。项目代码已托管在GitHub并开源发布，开发者坦承制作较为仓促，后续将持续迭代优化，欢迎社区用户试用并提供反馈建议。这类工具的出现，反映了中文开发者社区对AI编程工具本地化体验的实际需求。

      事件分析

      从技术角度看，这类插件的核心价值在于将翻译能力嵌入工作流本身，省去在输入框与翻译软件之间反复切换的操作成本。但其局限也很明显：提示词场景对语义精确性要求极高，双向翻译引入的偏差可能直接影响Agent的理解与输出质量，上下文一致性是后续迭代的关键挑战。从产业层面看，该项目侧面反映了中文用户使用海外AI工具的两个现实问题：多语言体验优化不足，以及账号风控传闻带来的使用焦虑。尽管封号传言未被证实，但已在社区形成实际行为影响，催生了这类衍生工具。后续走向上，若主流AI厂商完善中文支持与本地化，此类插件的需求会自然消退，短期内它更可能作为过渡性方案存在，其生命力取决于官方产品的演进速度。

      核心观点：封号传言催生翻译插件，折射出中文开发者对AI工具的刚需与官方本地化的长期缺位。

      原文链接：V2EX 分享发现

    • 7天烧掉24亿token：用户在谷歌Antigravity中发现疑似Gemini 3.8灰度模型

      Linux.do 论坛一位用户发帖称，其在谷歌 AI 编程工具 Antigravity 上注册了三个账号并高强度使用，七天累计消耗约 24 亿 token，直言免费额度不够用。更值得关注的是，该用户发现上游返回的模型标识为 gemini-3.8-flash-n，与官方公开的 Gemini 3 系列命名不一致，推测谷歌正在进行灰度测试。Antigravity 是谷歌随 Gemini 3 一同推出的智能体编程平台，面向开发者提供较为慷慨的免费额度，自上线以来吸引了大量用户高强度使用。历史上，谷歌等厂商曾多次通过生产环境或竞技场渠道以匿名版本号测试未发布模型，例如此前 LMArena 上出现的匿名模型后来被证实为新版本，因此此类发现常被视为新品泄露的前兆。若 gemini-3.8-flash-n 命名属实，意味着 Gemini 3.8 Flash 或已进入小范围验证阶段。不过，该发现目前仅为单一用户的观察结果，模型标识也可能是内部实验分支、缓存异常或路由策略所致，尚未获得谷歌官方证实，仍需更多独立证据佐证。

      事件分析

      从技术视角看，通过生产环境流量捕捉未公开模型版本已成为社区考古的常见手段，模型标识字符串往往早于官方公告泄露新品的开发进度。Antigravity 作为谷歌押注智能体编程的旗舰产品，慷慨的免费额度本身就是争夺开发者心智的获客策略，但 7 天 24 亿 token 的消耗也暴露出智能体编程对推理算力的巨大胃口，持续的成本压力可能迫使谷歌收紧配额政策。若 gemini-3.8-flash-n 属实，说明谷歌正以快节奏迭代 Gemini 系列，在中端性价比模型市场与竞品持续拉锯。后续可关注谷歌是否官方确认该版本、免费额度是否调整，以及社区是否出现更多独立的版本捕获证据。

      核心观点：免费额度是谷歌争夺开发者的获客筹码，而泄露的模型版本号则暴露了灰度迭代已成大厂模型发布的行业常态。

      原文链接：Linux.do

    最新文章

    热门专题

    热门标签

    AI编程claude大模型AIAI Agent人工智能开源项目Gemini开发者工具开源GitHubClaude Code开源工具AI工具开发工具谷歌openaideepseek提示词工程cursor网络安全anthropicAI应用ChatgptAI开发agentAI安全自动化智能体AI智能体

    网站统计

    • 日志总数：28894
    • 评论总数：7
    • 标签总数：17915
    • 用户总数：3675
    • 最后更新：2026-10-06