小模型档位，正在顶替旗舰

过去处理长周期任务，开发者几乎没有选择，只能上旗舰模型、开最高推理强度——原因在于成本优化型模型在长上下文和工具调用上的差距太大。GPT-5.6 改变了这个格局。在同样的测试框架下，Luna 和 Terra 这两档较小的模型，往往能接近 GPT-5.4、5.5 的表现，价格却低得多。

几个数据很能说明问题。文档智能公司 Hypha 的工程师表示，Luna 在保持 GPT-5.5 约 98% 提取精度的同时，成本只有后者的十八分之一。在 BrowseComp 这项考察冷门事实检索能力的基准上，三个月前 GPT-5.5（超高推理）得分 84.36%、花费 33.27 美元；GPT-5.6 的 Luna（超高推理）得分 84.04%、花费仅 1.33 美元——性能几乎一致，成本差了约 25 倍。浏览器自动化公司 Browser Use 的联合创始人给出的数字更具体：他们用 Luna 跑了 106 个最难的浏览器任务，完成率 78%，总花费约 14 美元；而当前最强模型跑到 80% 要花大约 235 美元。

工程分析平台 PlayerZero 的创始人则报告，在一个关键的代码探索任务上，Luna 把推理成本降低了 64%，响应时间缩短 90%，F1 分数还提升了 5 个点。

推理强度，不是越高越好

指南里另一个反直觉的发现是：降低推理强度，有时反而得到更好的结果。在 Agents' Last Exam 测试中，当测试框架保持不变时，GPT-5.6 的 Sol 档在「低」推理强度下的表现，超过了 GPT-5.5 在「高」推理强度下的表现。生产环境里也有类似反馈——多家初创公司表示，把推理强度从默认值调低后，多种工作流都看到了明显的成本改善。

数据分析公司 Hex 的 AI 研究负责人描述得很形象：把 GPT-5.6 放进现有框架后，低推理强度反而给出了最好的结果——模型知道数据不存在时就停下来，不追错误线索，用更少的 token 得到正确答案。

三个接口原语，把确定性工作交给代码

除了模型本身，OpenAI 还给 Responses API 引入了三个新的架构原语，分别对应智能体工作流里的几类效率问题。

第一是推理复用与原生压缩：通过把推理结果跨模型轮次持久化保存，并对长对话做原生压缩，模型能在更长任务周期内保持连贯，而不必反复重建上下文。在 ARC-AGI-3 基准上，Sol 用标准框架得分 13.3%；开启推理持久化与压缩后，得分跃升至 38.3%，输出 token 只有标准框架的约六分之一。

第二是原生多智能体编排：对可并行的复杂任务，把行动和推理分发给多个智能体并行推进。这也是 ChatGPT 里「ultra」能力设置的运作方式。研究公司 Quadrillion 的创始人评价，GPT-5.6 的 Sol 在开放式研究问题的多智能体协作上表现突出，相比 5.5 有明显提升，完成速度也几乎是最快的。

第三是程序化工具调用：让 GPT-5.6 编写 JavaScript 来编排工具、并行执行独立调用，并在上下文窗口之外处理输出，模型只专注于真正需要判断力的部分。金融研究公司 Rogo 的负责人表示，在评估中，使用程序化工具调用的 GPT-5.6 在质量标准上达到同等水平，同时输入 token 减少了 21%——这正是「能讨论金融研究」和「能真正执行金融研究」之间的区别。

缓存窗口拉长，也能省一笔

在整个 GPT-5.6 模型家族里，提示缓存的存活时间已延长到至少 30 分钟，并且可以在上下文窗口内确定性地设置缓存断点。AI 工程公司 Ploy 的工程师报告，他们在一个共享的 2.9 万 token 提示里加入缓存断点和专属密钥，把未缓存输入减少了 28%；30 分钟的缓存窗口让智能体能在多次运行间复用同一段上下文，而不是每次从头开始。

指南传递的信号很清晰：企业客户对 token 成本的敏感，已经到了必须正面回应的程度。过去那种「每一步都用最强模型」的做法，正在被更精细的分层调度取代。对开发团队而言，真正可操作的做法有两条——把高频、简单的任务下沉到便宜档位，把旗舰留给最难的部分；以及在选型时，用「单位任务成本」而不是「单价」来做横向比较。

来源：OpenAI 官方博客《The builder’s guide to GPT-5.6》

一、下载安装并选择模型

1. 到 GitHub 的 eigent-ai/eigent 仓库下载安装包，按提示完成安装。它采用 Electron 前端加 Python 后端的架构，开箱即用，无需自己搭环境。
2. 打开设置页选模型：本地方案可选 Ollama、LM Studio、vLLM、SGLang、LLaMA.cpp；云端则填入自备密钥，支持 Gemini、Anthropic、OpenAI、Grok、Qwen、DeepSeek、Moonshot 等。切换只是下拉框里选一下，小显卡跑本地模型卡顿时也能随时退回云端。

二、用内置智能体与技能干活

1. 开箱自带五类专用智能体：Developer（拥有终端、代码执行、文件操作）、Search、Document、Multi-Modal、Social Media，各自带着工具箱，不必从零搭工作流。
2. 系统内置 200 多个 MCP 工具（Notion、Google Calendar、Slack、GitHub 等），也能自行接入更多。
3. 用 Skills 沉淀个人流程：新建一个文件夹，写入 SKILL.md 描述触发条件与行为（结构与 Claude Skills 一致），之后一条命令就能触发。例如写一个读取心愿单、比价本地零售商并生成带日期报告的任务。

三、隔离浏览器与访问本机文件

1. 浏览器工具会在应用内通过 Playwright 拉起独立的 Chromium 实例，每次任务都从全新无痕会话开始，不携带本机浏览器的 Cookie、登录态和历史，避免身份泄露。
2. 默认每个任务被沙箱到自己工作目录；若要操作目录外的文件夹，在应用里新建一个指向该文件夹的 Space（下拉一次即可），否则会拒绝访问。

注意事项：Eigent 基于 CAMEL-AI 多代理框架，适合做知识管理、调研和自动化，并非只给开发者用。首次访问沙箱外目录记得先建 Space，否则任务会被拒。

来源：XDA Developers

从「虚拟实验室」到「虚拟药企」

这个项目的起点规模很小。Zou 最初搭建的「虚拟实验室」只有 5 到 8 个智能体，结构完全对照他在斯坦福的真实实验室：一个 AI 教授担任项目负责人，若干各有专长的 AI 学生，定期召开组会。团队还为智能体复制了一所「斯坦福」——一个智能体学校，让它们在其中接受监督微调，提升各自领域的专业能力。

「我们为智能体建了一所斯坦福的复制品，一所智能体学校，它们可以在那里上学，通过监督微调来提升自己在特定领域的专业水平。」Zou 这样描述。

这个小规模系统交出的第一份成果，是针对新近新冠变异株设计的纳米抗体蛋白。「真正让我们兴奋的是，这些由 AI 设计的纳米抗体在结合近期几种病毒方面，表现远好于此前由人类设计的版本。」Zou 说。这一结论经过了湿实验验证。

有了实验室层面的验证，团队把目标从模拟一个研究组，扩大到模拟一家公司。由此诞生的系统被称为「虚拟生物科技公司」，由数万个专业智能体组成，顶层是一个首席科学官智能体，下设与真实药企对应的各个部门——靶点发现、分子设计、临床试验等。部门内部还会进一步细分：「在靶点发现部门下面，会有一个智能体专门看所有遗传学数据，另一个专门看基因组学和单细胞数据，以此类推。」

为什么不是一个更强的模型

随着基础模型能力不断提升，开发者面临一个核心的架构选择：为什么要把任务拆给数万个专业智能体，而不是把算力全部投给一个无所不知的大模型？

Zou 团队用同一个科研难题做了对照实验，让多智能体团队与单个智能体正面对决。结果显示，多智能体生态中产生的摩擦与互动，反而带来了更好的方案，也更能抵抗误差的层层累积。

「在这些科研虚拟实验室里，智能体之间真的会争论、会产生分歧。它们必须说服其他 AI 科学家接受自己的想法，而这一切激发出的推理，比单个模型独自从零解决问题要更有创造性、也更稳健。」Zou 说。

卡点不在模型，在数据接口

规模一旦扩大到数万个智能体，真正的瓶颈就变成了编排。系统需要一个统一的上下文层，让智能体能够从各种工具、数据集和历史记录中整合知识。

不少企业团队试图用给现有数据库套一层 MCP（模型上下文协议）的方式解决数据打通问题，但 Zou 认为这治标不治本——老系统对智能体并不友好。比如把一篇论文的 PDF 直接丢进智能体的上下文窗口，效率极低，而标准文本模型很难读懂复杂的图和表，进而产生幻觉。

「即使你在现有数据库和 API 外面包一层 MCP，也没有解决底层问题：这些接口和 API 本来就不是为智能体设计的。」Zou 表示。它们的服务对象，是人类或者前 AI 时代的算法。

团队为此开发了名为 Paperclip 的平台。它利用了当代大模型的一项固有强项——写代码和操作文件系统的能力。Paperclip 不再强迫智能体去调用脆弱且各不相同的数据库 API，而是把非结构化数据数字化，并将分散的数据库映射成一个统一的、面向 AI 的虚拟文件系统。智能体由此可以用标准的文件系统操作，去访问数百万篇论文中的知识。

「结果表明，用了 Paperclip 准确率会高得多，同时相比没有这类 AI 原生科研基础设施的智能体，时间和成本能降低一个数量级以上。」Zou 说。

默克独立做出了同一套方案

为检验这套架构的实际产出，虚拟生物科技公司启动了 3.7 万个「临床试验智能体」，用于整合零散的临床试验数据。这些智能体识别出了一批可预测试验成功率的单细胞特征——有这些特征支撑的药物靶点，最终走向市场的概率比同类药物高出约 50%。

随后，系统自主设计了一款靶向 CD276 蛋白的抗体偶联药物，用于治疗肺癌。整个设计过程由智能体独立完成，且只依赖 2025 年 1 月之前公开发表的数据。

数月之后，制药公司默克（Merck，在中国大陆的商号为默沙东）独立开发并验证了同样的治疗方案，该方案后来获得了美国食品药品监督管理局的突破性疗法认定。Zou 将此称为「对虚拟生物科技智能体所给出的治疗设计的第三方外部验证」。

管理对象从流程变成环境

当多智能体系统的规模持续扩大，管理这批数字劳动力的方式也需要重新思考。Zou 主张从设计刚性工作流，转向搭建开放环境。工作流规定智能体每一步该做什么，更像是在管理一名初级员工；而环境提供的是基础设施、护栏和激励机制，让智能体围绕开放式问题自行协作。

「在工作流里，我们试图告诉智能体该做什么、该怎么做。但在环境里，我们提供基础设施、激励和护栏，其余部分保持开放，用激励促成智能体之间的协作。」Zou 说。

这也意味着规模化的优化对象发生了转移——不再是微调单个模型，而是设计整个环境。单个智能体固然可以通过强化学习或在智能体学校里做监督微调来提升，但大规模多智能体系统能否成功，取决于调整那些支配协作的参数。

「在多智能体这一侧，我们其实不再微调和改动单个模型了，而是在优化环境。」Zou 解释道，「环境本身就是我们用来提升智能体的优化对象。」

来源：VentureBeat

针对这个问题，Coral AI Labs 与多所高校的研究者提出了 AgentRadio——一个异步消息传递层，让智能体在各自的执行步骤之间互相传话，同时又不打断手头的正事。在一项针对生产环境代码仓库的长周期问答基准测试中，用上 AgentRadio 的四个智能体团队，把任务准确率提升到了独立作业时的近两倍，并且超过了单个智能体搭载更强模型时的成绩。这项研究由 VentureBeat 记者本·迪克森（Ben Dickson）报道，论文已公开在预印本平台 arXiv 上。

单个智能体为什么会卡住

理解代码库是长周期任务中最极端的一种。智能体需要把软件构建起来、运行它、跨多个文件追踪执行路径，还要在很长的时间跨度内把证据综合到一起。在这种条件下，单智能体系统通常会栽在”覆盖问题”上。

论文的三位共同作者任新星（Xinxing Ren）、凯勒姆·福德（Caelum Forder）和彼得·卡罗尔（Peter Carroll）向 VentureBeat 解释说，单个智能体只能沿着仓库里的一条串行路径往下走，随着上下文不断膨胀，最初制定的计划越来越难修改，调查后期的新发现也未必能反向传导回去。模型执行单个步骤通常没问题，难点在于”让每一项待办、每一处依赖、每一条互相矛盾的证据，在漫长的调查过程中始终保持活跃”。

衡量这类能力的一个基准是 SWE-Atlas QnA，题目全部是针对真实生产仓库提出的长周期自然语言问题。这些题不是靠读代码就能答出来的，智能体必须把软件跑起来、执行多条命令才能找到答案。研究团队的实验显示，单个搭载 Opus 4.6 的编码智能体只能解决其中 32.3% 的任务；换成更先进的 Opus 4.8，成功率也只有 57.2%。

把工作量分摊给多个智能体，让每个智能体面对更小、更干净的上下文，是顺理成章的下一步。问题在于，多智能体方案带来显著收益的前提是任务”可以干净地拆分”——各部分能独立解决、最后合并即可。代码库理解恰恰很少满足这个前提，子任务之间高度互相依赖：某个智能体挖出的一个关键配置文件或一个缺陷，可能会彻底改写另一个智能体的整条探索路线。

研究者指出，现有多智能体系统大体落进三种有缺陷的模式：

• 并行但彼此隔离：智能体同时开工，全程零沟通。
• 并行但按轮同步：能沟通，但只能在严格对齐的轮次边界上进行。这迫使智能体停下来等同伴跑完一轮，才能交换中间发现。轮次制隐含了一个昂贵的假设——重要发现可以等到下一个通信阶段再说。
• 有名无实的异步：只提供有限的异步能力，比如自上而下派活，没有智能体之间的横向点对点通道，共享记忆也需要智能体主动暂停工作去读取更新。

按照论文的说法，当前多智能体系统的主要瓶颈就一句话：一个正在干活的智能体，没办法同时在听。研究者写道，就他们所知，还没有哪个系统能让并发工作的智能体通过一条横向的自然语言通道，获得对彼此的被动感知。

AgentRadio 怎么运作

为了打破”干活”与”倾听”之间的互斥，研究者做出了 AgentRadio。它是一层异步消息传递机制，可以直接插进现有的编码智能体框架里，为智能体提供三个原语：

• create_thread：在参与的智能体之间开启一个会话线程。
• send_message：向线程追加一条消息，发出后立即返回，不阻塞发送方。
• wait_for_mention：阻塞进程，直到收到一条提及调用方的消息；消息送达时会附带所有线程的完整快照，让智能体立刻拿到上下文。

三者组合起来，智能体就进入了一种”被动感知”状态：可以继续做主线任务，同时在后台收发消息、更新自己掌握的信息。

AgentRadio 的代码以 Apache 2.0 协议开源在 GitHub 上，设计上足够轻量，不需要改动底层的 Claude Code、Codex CLI 等智能体框架。架构分两部分：一是消息服务器，作为独立进程充当中心枢纽，存放所有活跃线程、消息和提及记录；二是框架侧集成，智能体通过三个简单的 shell 脚本与服务器交互，每个脚本对应一个原语。

系统运行的唯一硬性要求，是智能体框架能把 shell 命令作为后台任务运行。智能体会在系统提示词里被要求常驻一个监听进程，并通过提供的脚本发消息。把 wait_for_mention 脚本放到后台跑，智能体就能一边继续工作一边异步收到通知。要接进现有技术栈，团队仍需写一个”轻量适配层，负责启动工作进程、分配身份、连接共享服务器并管理最终综合”，但这部分工作位于编码智能体的外围，不必改动底层模型。

实测：翻倍的准确率，和翻了六倍的账单

研究者在 SWE-Atlas QnA 基准的 124 个任务上验证了这套框架，覆盖系统设计、根因分析、安全和接口集成等领域。骨干模型选用 Claude Opus 4.6 和 DeepSeek V4 Pro，框架配置从单个编码智能体（B0）、经典分工的智能体团队（L1），一直排到使用 AgentRadio 异步协同的团队（L3）。

结果是：Opus 4.6 单智能体只解决 32.3% 的任务，完整的 AgentRadio 配置把这个数字提到 62.1%，接近翻倍，并且越过了 Opus 4.8 单智能体 57.2% 的成绩；DeepSeek V4 Pro 的成绩也从 29.0% 提升到 50.8%。

论文里有一个 MinIO 系统的真实案例很能说明问题。解题需要逐请求检查服务器日志，而智能体在初始规划阶段没预料到这一点。在只能协作、不能异步通信的 L2 配置下，两个智能体在执行命令时各自意识到需要这些日志，但因为无法在执行中途共享发现，一个默默放弃了，另一个也没向团队提出；到了评审阶段，整个团队一致同意了错误答案，丢掉五个评分项。启用 AgentRadio 之后，智能体做出了同样的中途发现，但其中一个立刻把服务端日志证据广播到共享工作日志上，其余智能体因为处在被动监听状态，马上吸收了这条新证据。最终这道题从不及格变成了 16 分满分。

研究者对此的总结是，关键差别在于时机：团队不需要多一个智能体，也不需要多一轮评审，它需要的只是让某个智能体的发现在其操作价值过期之前传到该传的人手里。

代价也是真金白银。固定规模的多智能体团队必然成倍推高 token 开销，研究者承认”这笔税是实实在在的”：平均每个任务的接口调用花费，从单个 Opus 智能体的 2.96 美元涨到 AgentRadio 完整方案的 19.45 美元。

不过更关键的对照实验证明，这不是单纯靠砸钱换来的。当研究者用 17.76 美元跑六次独立的 Opus 任务做算力对齐时，模型只解决了 37.9% 的任务，远低于 AgentRadio 的 62.1%。这说明 AgentRadio 的收益来自架构本身，而不是暴力堆规模。

什么时候该上多智能体

研究者同时给出了明确的边界：固定的多智能体团队不该成为所有工程任务的默认答案。判断是否需要多智能体，更有效的标准是任务里有没有”责任断点”——也就是那些”一名称职的工程师会主动叫上另一个人”的位置：工作跨越了归属边界、需要一个独立假设，或者风险高到值得单独验证。

按照他们的说法，当任务可以被拆解、拆出来的部分之间仍然互相依赖、单智能体成功率不稳定，而且答案不完整会带来实质的下游代价时，协同机制就非常合适。典型场景包括仓库级架构问题、陌生的遗留系统、跨服务的事故排查、安全分析、依赖迁移和多模块重构。反过来，对”边界清晰、影响局部、可以回滚”的活——比如一处已知的单文件改动或样板代码生成——单个智能体依然是更干净的选择。研究者的建议是：只要一份上下文还能诚实地扛住整个问题，就继续用一个智能体；只有当现有智能体不得不压缩掉证据、跨越独立的归属边界，或者需要自己验证自己的高影响结论时，才引入新的责任方。

未解的难题集中在”注意力治理与验证”上。被动感知让通信在执行期间随时可用，但它并不决定应该存在哪些智能体、哪条发现值得打断别人、该通知谁、证据强到什么程度才可以推翻原计划。如果每个智能体都收到每一条更新，通信层就退化成噪声；如果几个智能体本来就共享同一个错误假设，更快的通信只会让错误扩散得更快。

论文中一个基于 Grafana 平台的案例正好印证了这个局限：九项评分标准中有四项需要得出否定性结论，比如观察到某个数据源选择器不会自动选中。智能体跑完了相关测试，却没有一个形成那个缺失的否定假设，两种配置都在这四项上失分。研究者的评价是，被动感知能扩散某个人已经提出的想法，但它没法凭空供给一个团队里从未出现过的构想。

按照研究者的判断，下一代系统需要的是自适应的责任分配、基于证据的路由、冲突解决机制、明确的成本上限、权限管理、故障恢复，以及清晰的人工升级节点；最重要的是可追溯的来源记录，好让工程负责人能查清是哪个智能体给出了某项断言、某个动作为何被采纳。用他们的原话说：运行时间越长的智能体，让沟通变得越重要，也让追责变得更难作假。

AgentRadio 目前仍是一个使用固定四智能体团队和五阶段协议的受控研究实现，其中的原理正被改造成一款名为 Coral Code 的商业产品，思路从自上而下的刚性协议转为自下而上——工程师从自己现有的编码智能体起步，只有当证据本身需要时，才引入仓库范围的调查、专职责任分工和通信机制。

来源：VentureBeat《Four AI agents coordinating in real time outperformed Claude Opus 4.8 on enterprise coding tasks》，作者 Ben Dickson；论文数据来自 arXiv 预印本